Re: [Uri-review] Request for review

[Timothy Mcsweeney <[e-mail]>]

Ok thank you Thomas, I will have another look at the RFCs.

On May 29, 2020 at 7:01 PM Thomas Fruin <thomasfruin=[e-mail]> wrote:

The usefulness of this mailing list is clear, when needing the help of the community in difficult or ambiguous situations that are not covered in the RFCs.

For these recently posted, very simple and unambiguous questions, may I kindly suggest reading the RFCs, because that is what they are for.

>> 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".

> Is it basically this, or exactly this?

>> 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

> Is the colon the only "end of label" marker?

Thomas Fruin

On May 29, 2020 at 2:22 PM Ted Hardie < [e-mail]> wrote:

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]>; [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]>>;

>> [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/" target="_blank" rel="noopener nofollow">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" target="_blank" rel="noopener nofollow">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" target="_blank" rel="noopener nofollow">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" target="_blank" rel="noopener nofollow">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" target="_blank" rel="noopener nofollow">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" target="_blank" rel="noopener nofollow">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" target="_blank" rel="noopener nofollow">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" target="_blank" rel="noopener nofollow">https://www.ietf.org/mailman/listinfo/uri-review

_______________________________________________
Uri-review mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/uri-review" target="_blank" rel="noopener nofollow">https://www.ietf.org/mailman/listinfo/uri-review

 

_______________________________________________
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