Re: [Uri-review] Request for review

[Timothy Mcsweeney <[e-mail]>]

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 <[e-mail]> 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" < [e-mail]> 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.
> > 
> > > 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 / ":" / "@"
> > 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" < [e-mail]
> > >> <mailto: [e-mail]>> 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: [phone], e-mail: [e-mail] <mailto: [e-mail]>
> > >> 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
> > >> [e-mail] <mailto: [e-mail]>
> > >> https://www.ietf.org/mailman/listinfo/uri-review
> > > 
> > > _______________________________________________
> > > Uri-review mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/uri-review
> > > 
> > --
> > 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