Re: [Uri-review] Request for review

[Ted Hardie <[e-mail]>]

Hi Tim,

Thanks for sharing your thoughts on this.  Let me suggest a slightly
different formulation, which is not based on the colon itself, but on the
scheme.

The scheme indicates which type of URI a particular  example is and thus
governs a bunch of the behavior you describe below (whether it is used to
dereference resources and, if so, what protocol(s) are used, if there are
specific parameters and, if so, whether any are mandatory, and so on).  For
a URI parser, the method used to identify the scheme within any example is
basically: "it's the bit to the left of the colon".  If you don't have that
specific marker, then a standard URI parser won't find a scheme and thus
won't know what behavior to match to the example.

A common early metaphor for this was to identify the network retrieval
protocols as different parts of the plumbing of the Web, with the scheme
names as the labels on the taps.  That plumbing metaphor doesn't really
work with abstract identifiers and is stretched by schemes like HTTPS which
might have more than one set of underlying protocols.  But the labeling
still does--you can think of the schemes and the labels that tell the API
which branch of behavior to invoke.  The colon is the "end of label"
marker, and that's why folks are insisting on it here; without it, you
can't use the URI API to select a branch.

best regards,

Ted


On Fri, May 29, 2020 at 9:46 AM Timothy Mcsweeney <[e-mail]>
wrote:

> Hi Graham,
>
> I would never treat suggestions from this list as arbitrary, quite the
> contrary.
> I want to change the format of this reply just for a minute to express my
> deductions.
>
> This is an excerpt from the conversation in my head:
>
>
> If you take away all the components and subcomponents of a URI, what's
> leftover?
> The colon.
> And what governs the colon?
> The dereferencing algorithm.
> Does http use a colon in its dereferencing?
> It does.
> What about a URN?
> It does.
> FTP and Mailto?
> Yup the same.
> So If you change the colon to a number sign would you get them same
> output?
> Yes.
> All of them?
> Yes.
> Can you prove it?
> Yes.
> Why do all the delimiters have quotes around them?
> Because they are interchangeable.
> Interchangeable everywhere?
> No, just within the scope of their placement.  That's why URNs can use a
> bunch of colons and not interfere with the first colon after the URN scheme
> name.
> But it says the colon is required doesn't it?
> I can not pinpoint the sentence that says that.
> But section 3, the colon is in the generic syntax, you can see that right?
> Yes but the title of section 3 is "Syntax Components" and the colon is not
> a component.
> Wait, what does generic mean?
> Not specific.
> So the generic syntax is not specific?
> That's right.
> So [RFC3986] is a specification that is defining something that is not
> specific?
> Yup, says it right there in the abstract.
>
> From here my mental conversation took a left turn.  But I wanted to put
> this out here so that the members of this list didn't think my intent was
> for purely self interest reasons but that we can all use what's here.
>
> Tim
>
> On May 29, 2020 at 6:01 AM Graham Klyne < [e-mail]> wrote:
>
>
> Hmmm... I find that bit of RFC3986 isn't immeditely clear. But on closer
> study,
> I think it's simply saying that the characters are "safe" in the sense
> that
> they are protected from change by URI normalization, hence that when used
> as
> delimiters there is no risk that the interpretation of the URI is affected
> by
> URI normalization (see also section 6 of RFC 3986).
>
> But some of these reserved characters already have defined purposes in URI
> structure, and any scheme-dependent use needs to take care not to
> interfere with
> such use. For example, using "#" as a delimiter within a URI path would
> interfere with it's already-defined purpose to delimit a fragment.
>
> Also, current URI structure *requires* that the ":" is used to delimit the
> scheme name from the rest of the URI. Suggestions by others on this list
> to use
> ":" rather than "#" are not entirely arbitrary.
>
> As a rule of thumb, I would suggest that if you do need scheme-specific
> delimiters (and it's not clear to me that you do), then using one from the
> "sub-delims" set is more likely to avoid conflicts with generic URI syntax
> and
> interpretation.
>
> #g
> --
>
>
> On 28/05/2020 02:06, Timothy Mcsweeney wrote:
>
> Hi Dave,
>
> By "safe" I meant like ".....
>
> safe to be
> used by scheme-specific and producer-specific algorithms for
> delimiting data subcomponents within a URI"
>
> Like it says in section 2.2 of RFC3986.
>
> Tim
>
> On May 27, 2020 at 8:48 PM Dave Thaler < [e-mail]> wrote:
>
> >> s/URL/URI/ in both cases in my response J
> >>
> >> *From:*Uri-review < [e-mail]> *On Behalf Of *Dave
> Thaler
> >> *Sent:* Wednesday, May 27, 2020 5:47 PM
> >> *To:* Timothy Mcsweeney < [e-mail]>gt;; [e-mail]
> >> *Subject:* Re: [Uri-review] Request for review
> >>
> >>
> >> I don’t understand your question.   The URL syntax is fixed by that
> RFC.
> >>
> >> I don’t know what you mean by “safe” or “valid”.
> >>
> >> If by “valid” you mean “allowed by RFC 3986”, the answer is that they
> may only
> >> appear in a URL literally
> >>
> >> if they have the exact meaning in the RFC, otherwise they must be
> pct-encoded.
> >>
> >> *From:*Uri-review < [e-mail]
> >> <mailto: [e-mail]>> *On Behalf Of *Timothy
> Mcsweeney
> >> *Sent:* Wednesday, May 27, 2020 5:05 PM
> >> *To:* [e-mail] <mailto: [e-mail]>
> >> *Subject:* Re: [Uri-review] Request for review
> >>
> >>
> >> Hi Dave,
> >>
> >>
> >> If the other six gen-delims from the reserved set were safe and valid,
> would
> >> you oppose their use in URIs?
> >>
> >>
> >> Tim
> >>
> >>
> >>
> >>
> >> On May 24, 2020 at 6:08 PM Dave Thaler < [e-mail]
> >> <mailto: [e-mail]>> wrote:
> >>
> >> Hi Tim,
> >>
> >> Correct the colon is not part of the hier-part, the hier-part is what
> >> comes after the colon.  RFC 3986 says:
> >>
> >> URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
> >>
> >> Only strings that conform to the above are URIs.
> >>
> >> So “drop#sd54g54” is not a URI because it does not conform to the above
> >> syntax, as it has no “:”
> >>
> >> “drop:sd54g54” on the other hand would be a valid URI.
> >>
> >> This is what folks are saying when they say if you just change the “#”
> to
> >> a “:” in your draft then it becomes legal.
> >>
> >> Dave
> >>
> >> *From:*Uri-review < [e-mail]
> >> <mailto: [e-mail]>> *On Behalf Of *Timothy
> Mcsweeney
> >> *Sent:* Sunday, May 24, 2020 11:26 AM
> >> *To:* Erik Wilde < [e-mail] <mailto: [e-mail]>>t;>;
> >> [e-mail] <mailto: [e-mail]>
> >> *Subject:* Re: [Uri-review] Request for review
> >>
> >>
> >> Hi Erik,
> >>
> >>
> >> Thank you, I will have another look at my reference to section 3.
> >>
> >> Would you agree that in " https://ietf.org
> >> < "" rel="noopener"
> target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fietf.org%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339204192&sdata=UJ7TQnKfGZMnWkBKZCVozZQhn%2BGir1saiPQoNGV2C9M%3D&reserved=0>"
> >> the colon is not part of the hier-part?
> >>
> >> On May 24, 2020 at 12:02 PM Erik Wilde < [e-mail]
> >> <mailto: [e-mail]>> wrote:
> >>
> >>
> >>
> >> hey tim.
> >>
> >>
> >> On 2020-05-24 17:53, Timothy Mcsweeney wrote:
> >>
> >> Yes, I agree and understand that the same way as you.   But when
> >> the "#"
> >>
> >> leaves the client it is not leaving as a fragment,
> >>
> >> what people are telling you is that "#" and anything following it never
> >>
> >> leaves the client, by definition..
> >>
> >>
> >> it is leaving as a
> >>
> >> way to separate the URI components, <scheme> and <path> or for http it
> >>
> >> would be separating <scheme> and <authority>.  It is this that
> >> makes me
> >>
> >> believe that even if the colon is required for http resolution, it is
> >>
> >> not necessarily required for all URI.
> >>
> >> this discussion could be more productive if you had a brief look at the
> >>
> >> specs you're depending on. the very first rule shown in
> >>
> >> https://tools.ietf.org/html/rfc3986#section-3
> >> <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf..org%2Fhtml%2Frfc3986%23section-3&data=02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339214150&sdata=upZbOkALJ8SuEk%2FpLLqhdDDUNMhdpSmjWqpMAyITzc8%3D&reserved=0
> <https://nam06.safelinks.protection.outlook..com/?url=https%3A%2F%2Ftools.ietf..org%2Fhtml%2Frfc3986%23section-3&data=02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339214150&sdata=upZbOkALJ8SuEk%2FpLLqhdDDUNMhdpSmjWqpMAyITzc8%3D&reserved=0>>
>
> >> is
> >>
> >>
> >> URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
> >>
> >>
> >> each URI is defined like this and must have a colon.
> >>
> >>
> >> cheers,
> >>
> >>
> >> dret.
> >>
> >>
> >> --
> >>
> >> erik wilde | mailto: [e-mail] <mailto: [e-mail]>
> |
> >>
> >> | http://dret.net/netdret
> >> <
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdret.net%2Fnetdret&data=02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339214150&sdata=hq8QVDrXxRmV3iS6DF7R%2FeXFtDKntMcYOHnLSMqx5zo%3D&reserved=0
> <https://nam06.safelinks.protection.outlook..com/?url=http%3A%2F%2Fdret.net%2Fnetdret&data=02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339214150&sdata=hq8QVDrXxRmV3iS6DF7R%2FeXFtDKntMcYOHnLSMqx5zo%3D&reserved=0>>
>
> >> |
> >>
> >> | http://twitter.com/dret
> >> <
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fdret&data=02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339224105&sdata=9V5l2cgygLF2GJbT9Eh0ptd2mv4YRbvZm6oaYSrf8fE%3D&reserved=0
> <https://nam06.safelinks.protection.outlook..com/?url=http%3A%2F%2Ftwitter.com%2Fdret&data=02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339224105&sdata=9V5l2cgygLF2GJbT9Eh0ptd2mv4YRbvZm6oaYSrf8fE%3D&reserved=0>>
>
> >> |
> >>
> >>
>
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>