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

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:01:43 -0500 (EST)

text version:

Hello everyone,

This is a request for a review of the 'drop' URI scheme.  The draft can be found here < https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>.  Thank you.

Sincerely,

Tim McSweeney

On 05/18/2020 9:21 PM Timothy Mcsweeney <[email-masked]> wrote:

Hello everyone,

This is a request for a review of the 'drop' URI scheme.  The draft can be found here < https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>.  Thank you.

Sincerely,

Tim McSweeney

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:03:22 -0500 (EST)

text version:

Hi Henry,
I apologize for anything that was misleading as that was certainly not my intent. I will separate those two statements. The only similarity I wanted to point out was that 'tel' and 'leaptofrogans' use less than all five scheme components. Perhaps 'geo:' would have been a better example?

For the syntax, I wasn't sure exactly how much info was needed. I thought that only the scheme and path were required. Maybe I could change the reference to [RFC3986] section 2.2? If you think it would be better, should I write it out more like this?

path = / path-noscheme ; begins with a non-colon segment
          / path-rootless ; begins with a segment
          / path-empty ; zero characters

path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0<pchar>

segment = *pchar
segment-nz = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                       ; non-zero-length segment without any colon ":"

pchar =      unreserved / pct-encoded / sub-delims / ":" / "@"

Hi Martin,
I know at first glance it might look out of place but the #fg34htx part isn't a fragment. I think the "drop" part will be recognized as the scheme name because of its dereferencing.

> On 05/19/2020 11:47 AM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> Hi Henry,
> I apologize for anything that was misleading as that was certainly not my intent. I will separate those two statements. The only similarity I wanted to point out was that 'tel' and 'leaptofrogans' use less than all five scheme components. Perhaps 'geo:' would have been a better example?
> 
> For the syntax, I wasn't sure exactly how much info was needed. I thought that only the scheme and path were required. Maybe I could change the reference to [RFC3986] section 2.2? If you think it would be better, should I write it out more like this?
> 
> path = / path-noscheme ; begins with a non-colon segment
> / path-rootless ; begins with a segment
> / path-empty ; zero characters
> 
> path-noscheme = segment-nz-nc *( "/" segment )
> path-rootless = segment-nz *( "/" segment )
> path-empty = 0<pchar>
> 
> segment = *pchar
> segment-nz = 1*pchar
> segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
> ; non-zero-length segment without any colon ":"
> 
> pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
> 
> 
> Hi Martin,
> I know at first glance it might look out of place but the #fg34htx part isn't a fragment. I think the "drop" part will be recognized as the scheme name because of its dereferencing.
> 
> 
> > On May 19, 2020 at 5:40 AM "Henry S. Thompson" < [email-masked]> wrote:
> > 
> > 
> > Timothy Mcsweeney writes:
> > 
> > > This is a request for a review of the 'drop' URI scheme. The
> > > draft can be found here
> > > https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/
> > Without commenting on any other aspect of the proposed scheme, and
> > mostly just to save people time, I found the following aspect of the
> > proposal somewhat misleading:
> > 
> > "Similar to the previously registered 'tel' [RFC3966] and
> > 'leaptofrogans' [RFC8589] URIs, the 'drop' URI scheme is
> > syntactically correct but does not need to use all 5 of the
> > parse-able components available to it. The 'drop' scheme uses the
> > number sign '#' as a general delimiter as seen in Appendix
> > A. Collected ABNF [RFC3986]. The scheme syntax is as follows:
> > 
> > " drop-uri = 'drop#' character string
> > 
> > drop # fg34htx
> > \__/ \_/ \_____/
> > | | |
> > <scheme> | <scheme-specific-part>
> > <gen-delim>
> > "
> > 
> > I read this as implying that
> > 
> > 1) 'tel' and 'leaptofrogans' URIs did not begin "tel:" and
> > "leaptofrogans:";
> > 2) The 3986 ABNF for URIs recognises "drop#fg34htx" as a URI.
> > 
> > Neither of these is in fact that case. The two referenced schemes
> > require ':' after the 'scheme' component, and the 'URI' production does
> > _not_ recognise the above example. (The 'URI-reference' production does,
> > but not using the 'scheme' production to cover the "drop" part.)
> > 
> > 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.
> > 
> > _______________________________________________
> > Uri-review mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/uri-review

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:04:31 -0500 (EST)

text version:

Hi Martin,

I followed your instructions and I could not recreate what you wanted me to see.
Here are the two pages I made:

<http://www.soupsdeli.com/base.html>
<http://www.soupsdeli.com/drop>

Perhaps it had something to do with the hosting provider??  I'm not sure what's wrong here.  

Anyways, I'm glad to be here doing this.  Being an outsider, I was very nervous about a review on this proposed scheme because everyone on this mailing list is 1000X more knowledgeable than me.  I thought for sure that this review process was going to be a good way for the IETF crowd to blast my ignorance and be rid of me for a long while.

Just getting past the nits checker was a bit of a challenge for me.  But I have come to realize the real value in airing things out early is the advantage of perspective.  I suspected I already knew the outcome of your experiment, but not wanting to discount other ideas too quickly is something I could use more practice with.  And I'm glad I tried it.  Seeing things with a more open mind helped me find an error in this first draft that I haven't been called out on yet! (will be fixing that in draft-01).  So I am already grateful.

Maybe we could do a different experiment?  Maybe you know of a way for me to try out my dereferencing and test the "#" as a delimiter?

Sincerely, 
Tim

> On 05/20/2020 5:38 PM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> Hi Martin,
> 
> I followed your instructions and I could not recreate what you wanted me to see.
> Here are the two pages I made:
> 
> <http://www.soupsdeli.com/base.html>
> <http://www.soupsdeli.com/drop>
> 
> Perhaps it had something to do with the hosting provider?? I'm not sure what's wrong here.
> 
> Anyways, I'm glad to be here doing this. Being an outsider, I was very nervous about a review on this proposed scheme because everyone on this mailing list is 1000X more knowledgeable than me. I thought for sure that this review process was going to be a good way for the IETF crowd to blast my ignorance and be rid of me for a long while.
> 
> Just getting past the nits checker was a bit of a challenge for me. But I have come to realize the real value in airing things out early is the advantage of perspective. I suspected I already knew the outcome of your experiment, but not wanting to discount other ideas too quickly is something I could use more practice with. And I'm glad I tried it. Seeing things with a more open mind helped me find an error in this first draft that I haven't been called out on yet! (will be fixing that in draft-01). So I am already grateful.
> 
> Maybe we could do a different experiment? Maybe you know of a way for me to try out my dereferencing and test the "#" as a delimiter?
> 
> Sincerely,
> Tim
> 
> 
> 
> > On May 20, 2020 at 2:25 AM "Martin J. Dürst" < [email-masked]> wrote:
> > 
> > 
> > Hello Timothy,
> > 
> > On 20/05/2020 00:47, Timothy Mcsweeney wrote:
> > > Hi Henry,
> > > I apologize for anything that was misleading as that was certainly not my
> > > intent. I will separate those two statements. The only similarity I wanted to
> > > point out was that 'tel' and 'leaptofrogans' use less than all five scheme
> > > components. Perhaps 'geo:' would have been a better example?
> > > 
> > > For the syntax, I wasn't sure exactly how much info was needed. I thought that
> > > only the scheme and path were required. Maybe I could change the reference to
> > > [RFC3986] section 2.2? If you think it would be better, should I write it out
> > > more like this?
> > In the extreme, only the scheme is needed. "dav:" is an example. But
> > without a colon, it's not a scheme.
> > 
> > I'm not sure what these parts of the grammar are supposed to do here,
> > but you can't just start in the middle of the grammar and claim that you
> > get an URI.
> > 
> > 
> > > Hi Martin,
> > > I know at first glance it might look out of place but the #fg34htx part isn't a
> > > fragment.
> > By the definitions of RFC 3986, it is a fragment (identifier). This is
> > independent of what you want to call it.
> > 
> > > I think the "drop" part will be recognized as the scheme name because
> > > of its dereferencing.
> > Please do the following, as an easy experiment:
> > 
> > - Create a simple Web page somewhere, e.g. called base.html,
> > and in it, include the following part:
> > <a href='drop#fg34htx'>Link to drop URI</a>
> > - In the same directory, create another Web page, with the file name
> > simply being 'drop' (without extension). Way down in that Web page,
> > include the following:
> > <a id='#fg34htx' name='#fg34htx'>Fragment fg34htx</a>
> > - Activate the link in the first page, and observe how it goes to the
> > fragment in the second page.
> > [If you set up the pages on the server, you may have to take some care
> > that the 'drop' file is really served with an HTML media type; this may
> > be a bit tricky.]
> > 
> > If my explanations don't help, maybe doing this experiment will show you
> > what I mean.
> > 
> > Regards, Martin.
> > 
> > P.S.: The solution is simple. If you change "drop#fg34htx" to
> > "drop:fg34htx", then you actually match the URI production and no longer
> > have a fragment id.
> > 
> > >> On May 19, 2020 at 5:40 AM "Henry S. Thompson" < [email-masked]
> > >> <mailto: [email-masked]>> wrote:
> > >>
> > >>
> > >> Fax: (44) 131 650-4587, e-mail: [email-masked] <mailto: [email-masked]>
> > >> [email-masked] <mailto: [email-masked]>
> > Prof. Dr.sc. Martin J. Dürst
> > Department of Intelligent Information Technology
> > College of Science and Engineering
> > Aoyama Gakuin University
> > Fuchinobe 5-1-10, Chuo-ku, Sagamihara
> > 252-5258 Japan

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:05:05 -0500 (EST)

text version:
hmm, it looks like my email client made it into a link.  I fixed it and it works perfectly!  Thank you Daniel.

> On 05/21/2020 12:08 AM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> hmm, it looks like my email client made it into a link. I fixed it and it works perfectly! Thank you Daniel.
> > On May 20, 2020 at 11:34 PM "Daniel R. Tobias" < [email-masked]> wrote:
> > 
> > 
> > On 20 May 2020 at 17:38, Timothy Mcsweeney wrote:
> > 
> > > I followed your instructions and I could not recreate what you wanted
> > > me to see. Here are the two pages I made:
> > > < http://www.soupsdeli.com/base.html>
> > > < http://www.soupsdeli.com/drop>
> > This is the content of your first page:
> > 
> > <!doctype html>
> > <html>
> > <head><meta charset="us-ascii">
> > <title>test link</title>
> > 
> > </head>
> > <body>
> > <div> <h2><a href=' http://drop#fg34htx' target="_blank"
> > rel="noopener">Link to drop URI</a></div>
> > </body>
> > </html>
> > 
> > 
> > As you can see, the "href" value doesn't have "drop#fg34htx" by
> > itself as requested; it has a " http://" (http://) before it. This transforms it
> > into a http URI with "drop" as its domain, which my browser
> > "helpfully" converts into a link to drop.com. It would presumably
> > then go to the fragment #fg34htx in that page if such a fragment
> > existed.
> > 
> > --
> > == 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/
> >

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:06:01 -0500 (EST)

text version:
Hello everyone, 

The second draft of the 'drop' URI scheme is available and can be found here <  https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>.  Thank you. 

Sincerely, 
Tim McSweeney

> On 05/22/2020 5:29 PM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> Hello everyone,
> 
> The second draft of the 'drop' URI scheme is available and can be found here < https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>. Thank you.
> 
> 
> Sincerely,
> Tim McSweeney

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:06:37 -0500 (EST)

Hi Daniel, 

I think I know what you're saying but I want to make sure so, when you say 'mandatory colon' do you mean for all URIs or for just http?

Tim

> On 05/23/2020 11:37 PM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> Hi Daniel,
> 
> I think I know what you're saying but I want to make sure so, when you say 'mandatory colon' do you mean for all URIs or for just http?
> 
> Tim
> > On May 23, 2020 at 7:31 PM "Daniel R. Tobias" < [email-masked]> wrote:
> > 
> > 
> > On 22 May 2020 at 17:29, Timothy Mcsweeney wrote:
> > 
> > > The second draft of the 'drop' URI scheme is available and can be
> > > found here <
> > > " rel="noopener" target="_blank" data-mce-href="https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>">https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/> (https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/). Thank
> > > you.
> > This doesn't seem to resolve any of the issues people have raised; it
> > still omits the mandatory colon after the scheme, and puts its main
> > content, used for resource resolution and retrieval, in a fragment
> > identifier, which is intended for client-specific post-processing
> > after a document is retrieved.
> > 
> > --
> > == Dan ==

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:07:22 -0500 (EST)

text version:
Hi Dan, 

For the browser example, it is going to leave the client as 'drop#fg234' but come back to the client as 'fg234.dropexample.com'. 

Looking at the second sentence of section 2.2 of rfc3986 it give three choices for defining delimiters:
by using general syntax
by each scheme-specific syntax
by the implementation-specific syntax of a URI's derefrencing algorithm.

The 'drop' scheme uses the last one.  I was thinking of a way to show this being done with http but didn't thing anyone really wanted to see that.

Tim

> On 05/24/2020 8:31 AM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> Hi Dan,
> 
> For the browser example, it is going to leave the client as 'drop#fg234' but come back to the client as 'fg234.dropexample.com'.
> 
> Looking at the second sentence of section 2.2 of rfc3986 it give three choices for defining delimiters:
> by using general syntax
> by each scheme-specific syntax
> by the implementation-specific syntax of a URI's derefrencing algorithm.
> 
> The 'drop' scheme uses the last one. I was thinking of a way to show this being done with http but didn't thing anyone really wanted to see that.
> 
> Tim
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:08:21 -0500 (EST)

text version:
Hi Dan,

Yes, I agree and understand that the same way as you.   But when the "#" leaves the client it is not leaving as a fragment, 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.

Tim  

> On 05/24/2020 11:53 AM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> Hi Dan,
> 
> Yes, I agree and understand that the same way as you. But when the "#" leaves the client it is not leaving as a fragment, 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.
> 
> Tim
> 
> 
> > On May 24, 2020 at 10:54 AM "Daniel R. Tobias" < [email-masked]> wrote:
> > 
> > 
> > On 24 May 2020 at 8:31, Timothy Mcsweeney wrote:
> > 
> > > For the browser example, it is going to leave the client as
> > > 'drop#fg234' but come back to the client as 'fg234.dropexample.com'.
> > As I understand it, fragment identifiers don't leave the client, but
> > are used when processing the returned data from the server at the
> > client side.
> > 
> > --
> > == Dan ==

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:09:16 -0500 (EST)

text version:
Hi Erik, 

Thank you, I will have another look at my reference to section 3.   
Would you agree that in "https://ietf.org" the colon is not part of the hier-part? 

> On 05/24/2020 2:25 PM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> Hi Erik,
> 
> Thank you, I will have another look at my reference to section 3.
> Would you agree that in "https://ietf.org" the colon is not part of the hier-part?
> > On May 24, 2020 at 12:02 PM Erik Wilde < [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 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] |
> > | http://dret.net/netdret |
> > | http://twitter.com/dret |

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:10:39 -0500 (EST)

text version:
Just putting this conversation up here to show that Ted brought up some good points that I have fixed in the second draft.

> On 05/27/2020 7:42 PM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> Just putting this conversation up here to show that Ted brought up some good points that I have fixed in the second draft.
> > On May 21, 2020 at 7:18 PM Timothy Mcsweeney <[email-masked]> wrote: 
> > 
> > 
> > Hi Ted,
> > I have a question for you. In your last couple emails when you said the words "permanent identifier", did you mean:
> > 
> > the string always matches the same object forever
> > -or-
> > the string will always be an identifier for these particular types of objects
> > -or-
> > the string is disposable and there will never be another string like it again.
> > 
> > Thanks,
> > Tim
> > > On May 20, 2020 at 6:42 PM Ted Hardie < [email-masked]> wrote:
> > > 
> > > 
> > > On Tue, May 19, 2020 at 6:32 PM Timothy Mcsweeney < [email-masked]> wrote:
> > > >
> > > > Ted,
> > > > Thank you very much for the feedback. Would I be correct in deducing from your reply that if the 'drop' scheme remained a locator that you would recommend it remain a URI over a URN?
> > > > Tim
> > > 
> > > Because you can use the DDDS to get from a URN to the a retrieval
> > > step, I'm not sure that's the critical property for me. I think for
> > > me the difference is whether the drop-string is unique or not. As an
> > > example, a URN with a NBN
> > > ( https://en.wikipedia.org/wiki/National_Bibliography_Number) can go
> > > through a resolver to identify a specific resource. In cases like
> > > NBNs (or RFC numbers, for which there are also URNs), the number is
> > > never reassigned; the issuer guarantees that the NBN will change if
> > > the resource changes.
> > > 
> > > If you are constructing an identifier that is unique but will have
> > > internal references which change (e.g. if the telephone number or
> > > address associated with it change), you can still use a URN, but it
> > > will be associated will be a meta-identifier for the collection of
> > > changing versions. That's how vCard's CLIENTPIDMAP works, for
> > > example. It sort-of sounds like drop-strings would be dereferenable
> > > versions of this, via something like
> > > CLIENTPIDMAP.well-known-domain.example. The usefulness of that gets
> > > back to the question we discussed before,of whether these are mnemonic
> > > or not; discovering the right drop-string to use becomes a major part
> > > of the exercise.
> > > 
> > > In general, I think the vCard case might be a useful one for you to
> > > spend some time with, because it may be easier to communicate what
> > > drop-string will do if you relate it to an existing case.
> > > 
> > > regards,
> > > 
> > > Ted Hardie
> > > 
> > > 
> > > >
> > > > Hi Tim,
> > > > On Tue, May 19, 2020 at 3:40 PM Timothy Mcsweeney < [email-masked]> wrote:
> > > > Hi Ted,
> > > > Thank you for taking the time to have a look at the draft. I had not considered the use of more than one domain. I will be sure to clarify that there will only be one second level domain used for http. Because I am limited to four flags in the DDDS, at this time I would say my intent would be the same as listed. You are probably right when saying that section will need a rewrite.
> > > > Your statement about the drop-string functioning as a permanent identifier with the current telephone number, address, or other contact methods being available as a retrieved resource is spot on but in my head it is a locator. I'm going to give that some more thought. Generally speaking, is this draft something that you would personally find appealing to use?
> > > > If this intended to be a permanent identifier and you intend to use the DDDS, I would suggest you consider either a URN or, if you want to look outside the IETF, at an implementation of the handle system, which is currently maintained by the DONA foundation. If you stick with a URN, the result would be a string like this:
> > > > urn:drop:nss-specific-string
> > > > Drop is the namespace identifier (NID) in this case. The issuer assigned that NID is the issuer of names-specific-strings and has to maintain certain guarantees related to uniqueness, which may or may not work for you depending on your application model. There is, however, already a specification for how to use the DDDS to retrieve URNs (RFC 3402) as well as some experience with S-NAPTR (RFC 3958), which may simplify your deployment.
> > > > Your question about whether or not I feel this would be appealing to use is a little hard to answer without knowing more about the construction of the resources it returns and the creation of the strings. If they are essentially random, the deployment model is hard to get going because the users are trading a series of mnemonic strings for an opaque one. vCards (RFC 6350), for example, can contain a UUID in URN form; this is unique, but not memorable. Systems can use it to confirm that a vCard is a new entry in a contacts database, but the URN UUIDs do not really replace any of the entries in the vCard in other contexts. If the strings are not random, then you get markets in the names, along with risks of squatting and so on. Even for the opaque strings there have been such markets (sales of mnemonic telephone numbers, for example, where either keypad mapping or repeating numbers are valued as easy to remember). Those markets (for domain names, twitter handles, and so on) ten
 d to produce a lot of work in balancing the needs of those trying to maintain trademarks and those wishing to create new marks and identifiers.
> > > > regards,
> > > > Ted Hardie
> > > >
> > > > Sincerely,
> > > > Tim
> > > > On May 19, 2020 at 11:45 AM Ted Hardie < [email-masked]> wrote:
> > > > Hi Tim,
> > > > Thanks for the pointer to the draft. I think there are two issues here which are large enough that you may wish to think about the implied architecture. The first is a syntactic issue: the use of "#" as the only delimiter in the proposed URIs. As RFC 3986 describes it, the "#" delimiter is used for identifying fragments and is thus dependent on the MIME type of the retrieved object:
> > > > The fragment's format and resolution is therefore
> > > > dependent on the media type [RFC2046] of a potentially retrieved
> > > > representation, even though such a retrieval is only performed if the
> > > > URI is dereferenced.
> > > > This does not appear to match your usage. The usage you appear to be seeking is a transposition of the string to a subdomain of a well-known domain, so that a client can attempt retrieval via the three methods you enumerate; it is not clear from the document whether there will ever be more than one permitted domain here. A simpler implementation would appear to be drop:drop-string.well-known-domain.example.
> > > > Second, your document appears to imply that the drop string is used to augment existing telephone numbers and addresses, but it is not terribly clear how it does this. One interpretation might be that the drop-string functions as a permanent identifier with the current telephone number, address, or other contact methods being available as a retrieved resource. This section:
> > > > Primarily functioning as a locator there are three ways to get to a
> > > > 'drop' URI resource, http, srv records, and private resolution for
> > > > anything not found using the previous two methods. The first, or
> > > > default, action is when an application invokes the 'drop' URI it will
> > > > cause a lookup for matching application information starting with an A
> > > > record [RFC1035], then on to Service records [RFC2782], and then on to
> > > > other available records that may offer a new rule set for resolution.
> > > > raises a problem with this approach: the records returned by SRV are fundamentally different, in that they are onward pointers to other domains and resolutions. If the implication is that HTTP is always used to retrieve drop records and the appropriate server is discovered by either using an A record, an SRV record, or private resolution, then this section needs a major re-write (to include AAAA records and to clarify the intent). It's also not clear what long lived utility a new scheme serves here if the result is always https://some-string.discovered-domain.example/ .
> > > > If there were a different guarantee of uniqueness than the DNS, this would seem closer to a URN than other URI forms, or possibly an implementation of the handle system (as DOIs are). There is, unfortunately, not enough detail in the draft on the overall system to be confident of that.
> > > > regards,
> > > > Ted Hardie
> > > >
> > > > On Mon, May 18, 2020 at 6:21 PM Timothy Mcsweeney < [email-masked]> wrote:
> > > > Hello everyone,
> > > > This is a request for a review of the 'drop' URI scheme. The draft can be found here < " rel="noopener" target="_blank" data-mce-href="https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>">https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/> (https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/). Thank you.
> > > > Sincerely,
> > > > Tim McSweeney

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:11:19 -0500 (EST)

text version:

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 05/27/2020 8:05 PM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> 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]> 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:
> > 
> > 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]> On Behalf OfTimothy Mcsweeney
> > Sent: Sunday, May 24, 2020 11:26 AM
> > To: Erik Wilde <[email-masked]>; [email-masked]
> > Subject: Re: [Uri-review] Request for review
> > 
> > Hi Erik,
> > 
> > > 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%7C301845b79f34417b8da108d8000ffe6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637259415988523425&sdata=8SdFPIQPmfPOefEYg%2Fy13BK0AMhxkW6g55TE5MAJ2pY%3D&reserved=0) is
> > > 
> > > | http://dret.net/netdret (https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdret.net%2Fnetdret&data=02%7C01%7Cdthaler%40microsoft.com%7C301845b79f34417b8da108d8000ffe6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637259415988523425&sdata=AsAJT%2BzCdftgNtsB3tJr7Yj7hTBe8%2BES%2BHLi7QMUudg%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%7C301845b79f34417b8da108d8000ffe6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637259415988533419&sdata=P%2FHldqxET0s4Ka1%2BYCw9xaHlCrItXJ9ko8rwHa%2B0Mag%3D&reserved=0) |
> 
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:12:01 -0500 (EST)

text version:
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 05/27/2020 9:06 PM Timothy Mcsweeney <[email-masked]> 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]> wrote: 
> > 
> > 
> > s/URL/URI/ in both cases in my responseJ
> > 
> > From:Uri-review <[email-masked]> On Behalf OfDave Thaler
> > Sent: Wednesday, May 27, 2020 5:47 PM
> > To: Timothy Mcsweeney <[email-masked]>; [email-masked]
> > 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.
> > 
> > 
> > Sent: Wednesday, May 27, 2020 5:05 PM
> > To: [email-masked]
> > > Would you agree that in "https://ietf.org (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?
> > > > leaves the client, by definition..
> > > > 
> > > > > it is leaving as a
> > > > 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) is
> > > > 
> > > > | 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) |
> > 
> > 
> 
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:21:15 -0500 (EST)

text version:

Hi Ted,

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

Tim

On 05/29/2020 2:54 PM Timothy Mcsweeney <[email-masked]> wrote:

Hi Ted,

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

Tim

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

safe to be

Tim

On May 27, 2020 at 8:48 PM Dave Thaler < [email-masked]> wrote:

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

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

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

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

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

>> If by “valid” you mean “allowed by RFC 3986”, the answer is that they may only

>> appear in a URL literally

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

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

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

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

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

>> If the other six gen-delims from the reserved set were safe and valid, would

>> you oppose their use in URIs?

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

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

>> Correct the colon is not part of the hier-part, the hier-part is what

>> comes after the colon.  RFC 3986 says:

>> So “drop#sd54g54” is not a URI because it does not conform to the above

>> syntax, as it has no “:”

>> This is what folks are saying when they say if you just change the “#” to

>> a “:” in your draft then it becomes legal.

>> *From:*Uri-review < [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]>>;

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

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

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

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

>> Yes, I agree and understand that the same way as you.   But when

>> the "#"

>> would be separating <scheme> and <authority>.  It is this that

>> makes me

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

>> is

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

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:23:27 -0500 (EST)

text version:
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 05/30/2020 8:20 AM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> 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 < [email-masked]> 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).
> > 
> > (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,
> > > 
> > > 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.
> > > 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:
> > >>
> > >>>> On May 27, 2020 at 8:48 PM Dave Thaler < [email-masked]
> > >> <mailto: [email-masked]>> *On Behalf Of *Dave Thaler
> > >> >> *To:* Timothy Mcsweeney < [email-masked] <mailto: [email-masked]>>;
> > >> <mailto: [email-masked]>
> > >> >> <mailto: [email-masked] <mailto: [email-masked]>>>
> > >> *On Behalf Of *Timothy Mcsweeney
> > >> >> *To:* [email-masked] <mailto: [email-masked]> <mailto:
> > >> [email-masked] <mailto: [email-masked]>>
> > >> <mailto: [email-masked]>
> > >> >> <mailto: [email-masked] <mailto: [email-masked]>>> wrote:
> > >> >>
> > >> >> Hi Tim,
> > >> >>
> > >> <mailto: [email-masked]>
> > >> >> <mailto: [email-masked] <mailto: [email-masked]>>>
> > >> *On Behalf Of *Timothy Mcsweeney
> > >> >> *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]>>
> > >> >> < "" 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>"
> > >>
> > >> <mailto: [email-masked]>
> > >> >> <mailto: [email-masked] <mailto: [email-masked]>>> wrote:
> > >> >>
> > >> >>
> > >> >>
> > >> >> hey tim.
> > >> >>
> > >> >>
> > >> >> <
> > >> 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
> > >> >>
> > >> >>
> > >> >> erik wilde | mailto: [email-masked] <mailto: [email-masked]>
> > >> <mailto: [email-masked] <mailto: [email-masked]>> |
> > >> >>
> > >> >> <
> > >> 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%2Ftwitter.com%2Fdret&data=02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339224105&sdata=9V5l2cgygLF2GJbT9Eh0ptd2mv4YRbvZm6oaYSrf8fE%3D&reserved=0>
> > >>
> > >> >> |
> > >> >>
> > >> >>
> > >>>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:24:07 -0500 (EST)

text version:
Hi Michael, 

Before I reply to that, I want to be sure you and I are on the same page about
how my draft works.  Using the browser example, drop#mk34s is queried,
reponses given, the browser then goes to http://mk34s.dropexample.com  
and in the browser address bar it says http://mk34s.dropexample.com.

Is that how you understand my draft?

Tim

> On 05/30/2020 11:00 AM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> Hi Michael,
> 
> Before I reply to that, I want to be sure you and I are on the same page about 
> how my draft works. Using the browser example, drop#mk34s is queried, 
> reponses given, the browser then goes to http://mk34s.dropexample.com 
> and in the browser address bar it says http://mk34s.dropexample.com.
> 
> Is that how you understand my draft?
> 
> Tim
> 
> 
> 
> 
> > On May 30, 2020 at 10:01 AM Michael Wojcik < [email-masked]> wrote:
> > 
> > 
> > > From: Uri-review [mailto: [email-masked]] On Behalf Of Timothy Mcsweeney
> > > Sent: Saturday, May 30, 2020 06:20
> > > To: Graham Klyne; [email-masked]
> > That's not the issue here. The issue here is that you're misinterpreting RFC 3986.
> > 
> > 3986 section 3 is not ambiguous. The first production is:
> > 
> > The colon is explicit and not optional. A minimal URI consists of a scheme, a colon, and a hier-part. There's no wiggle room there, and no amount of casuistry regarding other parts of 3986 will change that.
> > 
> > Someone could also point to 1.2.3, where the language clearly notes that the colon is the scheme delimiter; or 3.5, which makes it clear that the hash symbol is always the fragment delimiter. But those arguments are redundant in light of the generic-URI top-level production that begins section 3.
> > 
> > To be honest, I don't understand why you're being so difficult about this. What's your motive for trying to find grounds in 3986 for repurposing the fragment identifier?
> > 
> > --
> > Michael Wojcik

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:24:53 -0500 (EST)

text version:
Hi Michael,

Before I reply to that, I want to be sure you and I are on the same page about
how my draft works. Using the browser example, drop#mk34s is queried,
reponses given, the browser then goes to <http://mk34s.dropexample.com>
 and in the browser address bar it says <http://mk34s.dropexample.com>.

Tim

> On 05/30/2020 11:27 AM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> 
> Hi Michael,
> 
> reponses given, the browser then goes to <http://mk34s.dropexample.com>
> and in the browser address bar it says <http://mk34s.dropexample.com>.
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:25:48 -0500 (EST)

text version:
I am bringing a product to market.  In the draft it says dropexample.com and my email, as you know, my is dropnumber.com.  So its drop number, not drop colon.  Your struggle is over.

> On 05/31/2020 3:02 PM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> I am bringing a product to market. In the draft it says dropexample.com and my email, as you know, my is dropnumber.com. So its drop number, not drop colon. Your struggle is over.
> 
> 
> > On May 31, 2020 at 2:24 PM "Daniel R. Tobias" < [email-masked]> wrote:
> > 
> > 
> > On 30 May 2020 at 14:01, Michael Wojcik wrote:
> > 
> > > To be honest, I don't understand why you're being so difficult about
> > > this. What's your motive for trying to find grounds in 3986 for
> > > repurposing the fragment identifier?
> > I'm struggling to figure out what the guy's true agenda is, too; why
> > he's so wedded to the nonstandard syntax he is proposing. Maybe he's
> > got an implementation out there somewhere with the quirky syntax
> > embedded that he doesn't want to have to change?
> > 
> > --
> > == Dan ==

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:29:27 -0500 (EST)

text version
>The issue here is that you're misinterpreting RFC 3986.

I noticed two of the original authors are on the email list.  It would
be nice to hear what the original interpretation was.

>To be honest, I don't understand why you're being so difficult about this.
 
Having a different perspective is no being difficult. 
Imagine the first color blind person telling everyone the grass is dark gray.

> On 05/31/2020 3:15 PM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> >The issue here is that you're misinterpreting RFC 3986.
> 
> I noticed two of the original authors are on the email list. It would
> be nice to hear what the original interpretation was.
> 
> >To be honest, I don't understand why you're being so difficult about this.
> 
> Having a different perspective is no being difficult.
> Imagine the first color blind person telling everyone the grass is dark gray.
> 
> 
> 
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:30:15 -0500 (EST)

text version:
Hi Larry, 

Just so its crystal clear in my head, you're saying that the original intent of 3986
was that the colon, and only the colon, was to be used as the gen-delim between
scheme and path regardless of implementation specific sytanx?  I have that right?

> On 05/31/2020 5:53 PM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> Hi Larry,
> 
> Just so its crystal clear in my head, you're saying that the original intent of 3986
> was that the colon, and only the colon, was to be used as the gen-delim between
> scheme and path regardless of implementation specific sytanx? I have that right?
> > On May 31, 2020 at 5:16 PM Larry Masinter <[email-masked]> wrote: 
> > 
> > 
> >   * I noticed two of the original authors are on the email list. It would
> >   * be nice to hear what the original interpretation was.
> > 
> > I wasn’t going to respond, but if you want my opinion, it’s that
> > 
> > we should change the registration form for new URI schemes to make this more explicit,
> > And we should consider updates to BCP 35/BCP 115 (Guidelines and Registration Procedures for URI schemes to figure out a way to terminate this kind of discussion.
> > 
> > I note that this re-(mis-)use of fragment identifier isn’t so different from the URN wish to repurpose “#”.
> > That we never required media type registrations to explain their interpretation of fragment identifiers. We should.
> > I note that for HTTP we can say “the fragment identifier isn’t sent to the server, only the base full URL” but that is not actually required and isn’t true for “file” URLs since in that case there is no particular “server”.
> > I point out https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler
> > TheNavigator (https://developer.mozilla.org/en-US/docs/Web/API/Navigator)methodregisterProtocolHandler()lets web sites register their ability to open or handle particular URL schemes (aka protocols).
> > For example, this API lets webmail sites open mailto: URLs, or VoIP sites open tel: URLs.
> > Which allows you to define “drop” URLs (which of course start with “drop:”)
> > 
> > 
> > From: Uri-review <[email-masked]> On Behalf OfTimothy Mcsweeney
> > Sent: Sunday, May 31, 2020 12:16 PM
> > To: Michael Wojcik <[email-masked]>; [email-masked]

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:32:11 -0500 (EST)

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

> On 06/04/2020 4:13 PM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> 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: 
> > 
> > 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. 
> > 
> > 
> > 
> > Thomas Fruin
> > > On May 29, 2020 at 2:22 PM Ted Hardie < [email-masked]> wrote: 
> > > 
> > > 
> > > Hi Tim,
> > > 
> > > 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. 
> > > 
> > > > > >> 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>"
> > > > > >> < 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
> > > > > >>
> > > > > >>
> > > > > >> < 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)>
> > > > > >> |
> > > > > >>
> > > > > >> < 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] https://www.ietf.org/mailman/listinfo/uri-review
> 
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:32:57 -0500 (EST)

text version:
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?

> On 06/15/2020 4:08 PM Timothy Mcsweeney <[email-masked]> 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?
> 
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:33:38 -0500 (EST)

text version:
Does anyone disagree with Martin?

> On 06/16/2020 9:57 AM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> Does anyone disagree with Martin?
> 
> > On June 15, 2020 at 9:05 PM "Martin J. Dürst" < [email-masked]> wrote:
> > 
> > 
> > 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.
> > 
> > 
> > >> On May 29, 2020 at 7:01 PM Thomas Fruin < thomasfruin=[email-masked]>
> > >> 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".
> > >> >> 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