Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt

[John C Klensin <[e-mail]>]

FWIW,

This discussion of a series of connected questions such as:

 -- what elements of the RFC 3986 definition are expected
	to be used by all URI types, 
	
 -- whether 3968 specifies semantics for those elements
	or whether what appear to be its semantic definitions
	and restrictions are just examples that can be replaced
	on a per-scheme basis, 
	
 -- which elements can be eliminated by a per-scheme
	profile, and 
	
 -- under what circumstances delimiters that might be
	associated with a particular URI component (or element)
	type can be used for something else if that component is
	not used by that scheme,

dominated the discussions in URNBIS for some months, exploded
briefly onto the IETF list after the now-dead
draft-ietf-urnbis-urns-are-not-uris draft was posted as an early
attempt to deal with the disagreements, and has been the source
of a great many "it means X, no, it means Y and maybe not-X"
exchanges among normally reasonable people.

May I suggest that it would be desirable to avoid repeating that
discussion  here, either for the specific case of "file://" or
for the next URI proposal to come along that does not closely
align with the "http:" UNL model?  It seems to me that a review
of the URNBIS discussion archive for the last nine months (there
was less traffic there than one might have wished for) and
minutes of the Toronto (IETF 90) WG meeting might be in order,
as would be some leadership from WG Chairs and ADs?

As a more or less rhetorical question, if we really can't agree
on what 3986 says and means, is it time to freeze _all_ new and
revised URI definitions and registrations until it is possible
to develop and complete a clarification to that rather basic
document?

thanks,
   john


--On Friday, September 26, 2014 10:41 +0200 Daniel Stenberg
<[e-mail]> wrote:

> On Fri, 26 Sep 2014, "Martin J. Dürst" wrote:
> 
>>> The query part. It didn't exist in 1738, so introducing that
>>> now will break  a lot of old parsers (like mine) even if I
>>> recognize that 3986 says that it  should be supported
>>> globally. This, for just a vague extension model  without
>>> any clear purpose or use case.
>> 
>> It is the first time that I have seen somebody claim that RFC
>> 3986 says that  all URI schemes have to support query parts.
>> I'd like to know where in RFC  3986 you found that. Indeed my
>> understanding is that most schemes don't  understand or
>> include query parts. The main (but very important) exceptions 
>> as far as I'm aware of are http:/https: and mailto:.
> 
> Maybe this is just me, but that's my reading of RFC 3986
> section 3:
> 
>     3.  Syntax Components
> 
>     The generic URI syntax consists of a hierarchical sequence
> of
>     components referred to as the scheme, authority, path,
> query, and
>     fragment.
> 
> There exists language in 3986 suggesting that things differ
> between protocols but reading that section 3 doesn't make it
> obvious to me that the query part can be opted out (even if as
> I already mentioned by own parsers do). Not even 3.4 that
> details query mentions that.
> 
> Section 2.2 also lists '?' as a "Reserved character" also in a
> generic way and it is listed as a delimiter but then goes on
> to rather mysteriously say:
> 
>    "URI producing applications should percent-encode data
> octets that
>     correspond to characters in the reserved set unless these
> characters
>     are specifically allowed by the URI scheme to represent
> data in that
>     component."
> 
> ... but the file: section of RFC1738 doesn't mention what
> letters that are legal in the path part so it's not clear to
> me if '?' is a delimiter or part of the path, spec-wise.