Re: [Uri-review] Request for review

[Timothy Mcsweeney <[e-mail]>]

Hi Graham, 

>>A short answer here is that you need the colon after the scheme name

because that's what the URI specification, which represents a community

consensus, says.

Yes, the entire 3986 represents a community consensus , even the parts some

don't like, including the parts I want to use. The community that ratified that

RFC still exists.

And if people want to make parsers that don't work with the spec it doesn't become the spec's problem.

Tim

On May 30, 2020 at 5:24 AM Graham Klyne < [e-mail]> wrote:

Hi Tim,

A short answer here is that you need the colon after the scheme name because

that's what the URI specification, which represents a community consensus, says.

A pragmatic response is that many contexts allow either a URI or a relative

reference to be used (e.g. HTML <a href="...">). So it's important for a

processor to be able to distinguish between these cases. The colon after the

sceme name is what makes that possible

( https://tools.ietf.org/html/rfc3986#section-4.1)" rel="noopener nofollow" target="_blank">https://tools.ietf.org/html/rfc3986#section-4.1).

(BTW, I wasn't suggesting you were treating anything as arbitrary. But in

practice, some choices *are* arbitrary, and for interoperability we need to

agree some such choices.)

#g

--

On 29/05/2020 17:45, Timothy Mcsweeney 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]

<mailto: [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]

>>>> <mailto: [e-mail]>> wrote:

>> >> s/URL/URI/ in both cases in my response J

>> >>

>> >> *From:*Uri-review < [e-mail]

>> <mailto: [e-mail]>> *On Behalf Of *Dave Thaler

>> >> *Sent:* Wednesday, May 27, 2020 5:47 PM

>> >> *To:* Timothy Mcsweeney < [e-mail] <mailto: [e-mail]>>;

>> [e-mail] <mailto: [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]>

>> >> <mailto: [e-mail] <mailto: [e-mail]>>>

>> *On Behalf Of *Timothy Mcsweeney

>> >> *Sent:* Wednesday, May 27, 2020 5:05 PM

>> >> *To:* [e-mail] <mailto: [e-mail]> <mailto:

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

>> >> <mailto: [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]>

>> >> <mailto: [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]>

>> <mailto: [e-mail] <mailto: [e-mail]>>>;

>> >> [e-mail] <mailto: [e-mail]> <mailto:

>> [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 nofollow" target="_blank">https://ietf.org

>> >> < "" rel="noopener"

>> target="_blank"> "" 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]>

>> >> <mailto: [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" rel="noopener nofollow" target="_blank">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" rel="noopener nofollow" target="_blank">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]>

>> <mailto: [e-mail] <mailto: [e-mail]>> |

>> >>

>> >> | http://dret.net/netdret" rel="noopener nofollow" target="_blank">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" rel="noopener nofollow" target="_blank">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" rel="noopener nofollow" target="_blank">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" rel="noopener nofollow" target="_blank">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] <mailto: [e-mail]>

>>> https://www.ietf.org/mailman/listinfo/uri-review" rel="noopener nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/uri-review