Comments (16)
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.
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.
- During discovery, "a potential subscriber initiates discovery by retrieving ... the topic" (section 3)
- But apparently, occasionally "the hub re-fetches a topic feed" (section 2)
- 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.
Related Issues (20)
- use of Link header HOT 2
- hub vs subscriber in section 8 HOT 5
- High Level Architecture HOT 5
- At risk: limiting the use of HTML <link> to the HTML <head> HOT 16
- Add Acknowledgments section HOT 1
- Temporary vs Permanent Redirect HOT 1
- Diffing for HTML with <article> HOT 3
- Alternative protocols for callbacks HOT 4
- Content Distribution topic clarification HOT 3
- How to handle removals from a list HOT 2
- https://websub.net is not available due to certificate issues HOT 1
- discovery of hub url order and https vs http HOT 2
- GitHub Code Scanning Alerts on hub.challenge when using Express.js
- Example 4 has wrong Content-type HOT 1
- Let's stop treating URLs as secrets: the removal of hub.verify_token in prior draft 0.3
- protocol diagram is hard to read HOT 1
- How to ensure publisher and subscriber data remains private when transmitted through hubs?
- Consistency Issues with WebSub HOT 4
- Expiration time is still defined as optional in section 1.
- Changing callbacks in renewal requests? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from websub.