URL vs URI (RFC 3986) inconsistency about websub HOT 16 CLOSED

Thanks for raising this inconsistency. We should be referencing the URL Standard, as modern W3C specifications are now doing, which supercedes the RFCs, and using the term "URL" as has been noted.

https://url.spec.whatwg.org/

from websub.

Most of the identifiers in the spec actually have to be URLs, not URIs. I believe only the "topic" can be a URI.

The topic URL can otherwise be free-form following the URI spec [RFC3986].

I would be curious if any implementations actually use anything other than URLs for the topic, and if not, we could consider requiring that topic is always a URL to avoid using URIs anywhere in the spec.

from websub.

On 2016-10-25 17:15, Aaron Parecki wrote:

Most of the identifiers in the spec actually have to be URLs, not URIs.
I believe only the "topic" can be a URI.

the point i wanted to make is that the terminology of the spec is that these identifiers are URIs. URL is a loosely defined colloquial term.

from the spec writing perspective, i would consider saying "URI" and "dereferencable URI" if you want to differentiate.

from websub.

The spec seems a bit contradictory on this.

1. During discovery, "a potential subscriber initiates discovery by retrieving ... the topic" (section 3)
2. But apparently, occasionally "the hub re-fetches a topic feed" (section 2)
3. And yet "the topic URL can otherwise be free-form following the URI spec" (section 4.1.1)

For (1), the relevant URL is any old ad-hoc retrievable URL. For (2), the URL that the hub would fetch would be the canonical topic URI (?) from the rel=self link discovered in case 1. But (3) seems to contradict (2), since (2) demands retrievability.

Perhaps explicitly documenting the currently merely implied expected chaining/delegation behaviour of hubs would help clarify?

from websub.

Good point. I know there is a specific reason that some hubs/publishers need to advertise a topic URL that might be different from the URL that was fetched in the first place. But you're right that the rest of the spec implies that the topic URL is also retrievable. In that case, it would seem to make sense to require that the topic is also an http or https URL.

-1 on using "dereferencable URI" instead of "URL" since that just seems like jargon for jargon's sake.

from websub.

-1 on using "dereferencable URI" instead of "URL" since that just seems like jargon for jargon's sake.

not really. URL is not a well-specified term and even if you assume that people think that an HTTP URI is a URL, it's easy to come up with HTTP URIs that do not resolve (such as http://iamneverusingthisdomain.com/demo). saying "dereferencable URI" actually says what i think you were referring to earlier: using an HTTP URI that you can dereference.

from websub.

That doesn't seem quite right: RFC 3986 defines URLs in section 1.1.3 as "the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network 'location')."

from websub.

same section: "Instances of URIs from any given scheme may have the characteristics of names or locators or both, often depending on the persistence and care in the assignment of identifiers by the naming authority, rather than on any quality of the scheme."
they had to mention URL/URN because such an amount of noise was made about those early on, before people realized that creating this dichotomy is neither helpful nor possible.

from websub.

Perhaps, then, they're saying that whether a given string is a URN or URL is not a property of the string, but a property of the context in which the string is interpreted. If this is true, then using "URL" would be appropriate in this spec, since the spec aims to use the string to denote not only a name, but also a location.

from websub.

Thanks for raising this inconsistency. We should be referencing the URL Standard, as modern W3C specifications are now doing, which supercedes the RFCs, and using the term "URL" as has been noted.

that's not what i've been saying and that's not what should be happening, but i guess you knew that i would say that. ;-)

from websub.

On 2016-10-25 17:15, Aaron Parecki wrote:

Most of the identifiers in the spec actually have to be URLs, not URIs.
I believe only the "topic" can be a URI.

the point i wanted to make is that the terminology of the spec is that
these identifiers are URIs. URL is a loosely defined colloquial term.

from the spec writing perspective, i would consider saying "URI" and
"dereferencable URI" if you want to differentiate.

from websub.

I am not sure what the right action is here. If you think we need a better consistency, I opt for using https://url.spec.whatwg.org/ and if so, feel free to submit a PR.

from websub.

my initial point stands. if you reference the current RFC, then using URI is the appropriate terminology. if you switch to the WHATWG spec, then URL is probably the better choice. which of the two specs you consider to be the one that you should be using is a matter of preference.

from websub.

I personally do not have a preference. @aaronpk do you?

from websub.

I would prefer to use the more modern WHATWG-URL reference. I've created a PR (#78) which makes the appropriate changes.

from websub.

This has been merged to I am closing. If anyone still feels strongly about the issue, feel free to re-open.

from websub.