Subject: Re: [Uri-review] Request for review

From: Thomas Fruin <[email-masked]>
Date: Fri, 29 May 2020 19:01:17 -0400

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 <[email-masked]> 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 < [email-masked] <mailto:[email-masked]>> 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 < [email-masked] <mailto:[email-masked]>> 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 < [email-masked] <mailto:[email-masked]>> wrote:
>> >> s/URL/URI/ in both cases in my response J
>> >>
>> >> *From:*Uri-review < [email-masked] <mailto:[email-masked]>> *On Behalf Of *Dave Thaler
>> >> *Sent:* Wednesday, May 27, 2020 5:47 PM
>> >> *To:* Timothy Mcsweeney < [email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> >> *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 < [email-masked] <mailto:[email-masked]>
>> >> <mailto: [email-masked] <mailto:[email-masked]>>> *On Behalf Of *Timothy Mcsweeney
>> >> *Sent:* Wednesday, May 27, 2020 5:05 PM
>> >> *To:* [email-masked] <mailto:[email-masked]> <mailto: [email-masked] <mailto:[email-masked]>>
>> >> *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 < [email-masked] <mailto:[email-masked]>
>> >> <mailto: [email-masked] <mailto:[email-masked]>>> 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 < [email-masked] <mailto:[email-masked]>
>> >> <mailto: [email-masked] <mailto:[email-masked]>>> *On Behalf Of *Timothy Mcsweeney
>> >> *Sent:* Sunday, May 24, 2020 11:26 AM
>> >> *To:* Erik Wilde < [email-masked] <mailto:[email-masked]> <mailto: [email-masked] <mailto:[email-masked]>>>;
>> >> [email-masked] <mailto:[email-masked]> <mailto: [email-masked] <mailto:[email-masked]>>
>> >> *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 <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 < [email-masked] <mailto:[email-masked]>
>> >> <mailto: [email-masked] <mailto:[email-masked]>>> 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://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: [email-masked] <mailto:[email-masked]> <mailto: [email-masked] <mailto:[email-masked]>> |
>> >>
>> >> | http://dret.net/netdret <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 <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
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/uri-review <https://www.ietf.org/mailman/listinfo/uri-review>_______________________________________________ 
> Uri-review mailing list 
> [email-masked] <mailto:[email-masked]> 
> https://www.ietf.org/mailman/listinfo/uri-review <https://www.ietf.org/mailman/listinfo/uri-review> 

_______________________________________________
Uri-review mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/uri-review

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 4 Jun 2020 16:13:44 -0400 (EDT)

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

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

Thomas Fruin

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

Hi Tim,

best regards,

Ted

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

Hi Graham,

The colon.

It does.

What about a URN?

It does.

FTP and Mailto?

Yup the same.

Yes.

All of them?

Yes.

Can you prove it?

Yes.

Not specific.

That's right.

Tim

On May 29, 2020 at 6:01 AM Graham Klyne <
[email-masked]> wrote:

interpretation.

#g

--

Hi Dave,

safe to be

Tim

>> *From:*Uri-review <
[email-masked]> *On Behalf Of *Dave Thaler

>> *To:* Timothy Mcsweeney <
[email-masked]>;
[email-masked]

>> *From:*Uri-review <
[email-masked]

>> <mailto:
[email-masked]>> *On Behalf Of *Timothy Mcsweeney

>> *To:*
[email-masked] <mailto:
[email-masked]>

>> On May 24, 2020 at 6:08 PM Dave Thaler <
[email-masked]

>> <mailto:
[email-masked]>> wrote:

>> *From:*Uri-review <
[email-masked]

>> <mailto:
[email-masked]>> *On Behalf Of *Timothy Mcsweeney

>> *To:* Erik Wilde <
[email-masked] <mailto:
[email-masked]>>;

[email-masked] <mailto:
[email-masked]>

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

>> On May 24, 2020 at 12:02 PM Erik Wilde <
[email-masked]

>> <mailto:
[email-masked]>> wrote:

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>

>> erik wilde | mailto:
[email-masked] <mailto:
[email-masked]> |

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>

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>

Uri-review mailing list

[email-masked]

Uri-review mailing list

[email-masked]

Uri-review mailing list

[email-masked]

_______________________________________________ Uri-review mailing list [email-masked] https://www.ietf.org/mailman/listinfo/uri-review

---

From: Timothy Mcsweeney <[email-masked]>
Date: Mon, 15 Jun 2020 16:08:17 -0400 (EDT)

Hello,

I have given things a lot of thought over the last two weeks and I have a question for the group.  Lets say, even with the objections on the number sign, what harm can come from trying it?

From what I gather from the feedback, the parsers wont parse it correctly.  Is that so bad?  I mean, if my idea only work sometimes, or somewheres, is that bad for everyone, or just bad for me?

Thomas Fruin

Hi Tim,

best regards,

Ted

Hi Graham,

The colon.

It does.

What about a URN?

It does.

FTP and Mailto?

Yup the same.

Yes.

All of them?

Yes.

Can you prove it?

Yes.

Not specific.

That's right.

Tim

interpretation.

#g

--

Hi Dave,

safe to be

Tim

[email-masked]>;
[email-masked]

[email-masked]

[email-masked]>> wrote:

https://ietf.org

[email-masked]

[email-masked]>> wrote:

http://dret.net/netdret

http://twitter.com/dret

Uri-review mailing list

[email-masked]

Uri-review mailing list

[email-masked]

Uri-review mailing list

[email-masked]

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 16 Jun 2020 10:05:48 +0900

On 16/06/2020 05:08, Timothy Mcsweeney wrote:
> Hello,
> 
> I have given things a lot of thought over the last two weeks and I have a
> question for the group.  Lets say, even with the objections on the number sign,
> what harm can come from trying it?
> 
>   From what I gather from the feedback, the parsers wont parse it correctly.  Is
> that so bad?  I mean, if my idea only work sometimes, or somewheres, is that bad
> for everyone, or just bad for me?

Apologies for putting it in the following way:

I think it's only bad for you.
Everyone else just won't care, they won't use your "drop" non-scheme.

Regards,   Martin.

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

---

From: Timothy Mcsweeney <[email-masked]>
Date: Tue, 16 Jun 2020 09:57:56 -0400 (EDT)

Does anyone disagree with Martin?

On June 15, 2020 at 9:05 PM "Martin J. Dürst" <
[email-masked]> wrote:

Hello,

Regards, Martin.

>> On May 29, 2020 at 7:01 PM Thomas Fruin <
thomasfruin=[email-masked]>

>> wrote:

---

From: "Henry S. Thompson" <[email-masked]>
Date: Tue, 16 Jun 2020 15:19:39 +0100

>    Does anyone disagree with Martin?

I agree that no-one will use your non-scheme.  If you meant by your
question to suggest that you should be allowed to register it as an
experiment, then I don't agree with that at all.

You cannot register a URI scheme that does not conform to the RFCs which
govern URIs.  Many people have explained to you that your proposal does
not conform, and given helpful advice on what changes you need to make
to make a conformant proposal.

End of story.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

---

From: "Daniel R. Tobias" <[email-masked]>
Date: Tue, 16 Jun 2020 21:12:00 -0400

On 15 Jun 2020 at 16:08, Timothy Mcsweeney wrote:

> From what I gather from the feedback, the parsers wont parse it
> correctly.  Is that so bad?  I mean, if my idea only work sometimes,
> or somewheres, is that bad for everyone, or just bad for me?

Pretty much just you. You'll never get such a nonstandard scheme 
registered, but nobody can force you not to implement it anyway in 
whatever software or hardware you create, but you're unlikely to get 
anybody else to use it and other systems won't be able to 
interoperate with it.

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/