Re: [art] Question regarding RFC 8089

Hi John,

I think that's correct -- and a worthy clarification for existing schemes.

Cheers,

> On 18 Dec 2018, at 7:17 pm, John C Klensin <john-ietf@jck.com> wrote:
> 
> However, Mark, it seems to me to be entirely appropriate, and
> consistent with 3986, for a scheme definition to state whether
> or not a fragment identifier is permitted.  That is very
> different from specifying the details of the syntax or semantics
> of that identifier if it is allowed and it is not clear to me
> from reading 3986 whether the default, if the scheme definition
> doesn't say anything, is "yes" or "no".
> 
>     john
> 
> 
> --On Tuesday, December 18, 2018 09:09 +1100 Mark Nottingham
> <mnot@mnot.net> wrote:
> 
>> To add a bit -
>> 
>> URI scheme definitions are supposed *not* to define fragment
>> identifiers, since their interpretation is dependent upon the
>> media type, not the scheme.
>> 
>> This has caused confusion in the past; see
>> <https://github.com/httpwg/http-core/issues/103>. 
>> 
>> Cheers,
>> 
>> 
>>> On 18 Dec 2018, at 9:04 am, Julian Reschke
>>> <julian.reschke@gmx.de> wrote:
>>> 
>>> On 2018-12-17 22:57, Matthew Kerwin wrote:
>>>> On Tue, 18 Dec 2018 at 03:15, Stephan Bergmann
>>>> <sbergman@redhat.com> wrote:
>>>>> 
>>>>> Is it intentionally so that file URIs do not support
>>>>> neither a query nor a fragment part?  At least, that is how
>>>>> I read RFC 8089 section 2 in combination with RFC 3986
>>>>> section 3.
>>>>> 
>>>> I would say: a bit yes, a bit no. There was definitely no
>>>> support for query or fragment in RFC 1630 nor 1738, and we
>>>> never explicitly *added* support in 8089.
>>>> The two goals of RFC 8089 were: to publish an RFC for file
>>>> URIs with unambiguous status, and to align the
>>>> syntax/definition with RFC 3986. According to the letter of
>>>> the law (i.e. RFC 3986): "The query component contains
>>>> non-hierarchical data that, along with data in the path
>>>> component, serves to identify a resource..."  So as far as
>>>> aligning with that definition, it wouldn't have made sense
>>>> to add a query component.  Files are identified by purely
>>>> hierarchical data. As to the fragment, it's a bit murky, but
>>>> the way I read RFC 3986, section 3.5, "The fragment's format
>>>> and resolution is ... dependent on the media type of a
>>>> potentially retrieved representation..." Since the resource
>>>> representation retrieved by dereferencing a file URI doesn't
>>>> have a media type (heuristics notwithstanding) it doesn't
>>>> make sense to include a fragment component in the URI
>>>> scheme, since it would always be undefined.
>>>> All that said, file URI syntax is now a subset of the
>>>> generic syntax, so you're technically able to parse a file
>>>> URI with query and/or fragment components.  If that's useful
>>>> for you -- e.g. if you are confident that your media type
>>>> heuristics are good enough to make fragment components
>>>> workable -- then nothing stops you.  Clearly the browsers
>>>> support it; although I don't know what it would mean for
>>>> something like cURL or urllib to have to deal with a query
>>>> component, so I don't know how it could be added to the
>>>> scheme definition.  You could always just go with
>>>> https://url.spec.whatwg.org/ instead... A little bit of
>>>> whataboutism occurs to me: what about data URIs?  They *do*
>>>> have media type information, but don't define fragments in
>>>> the URI scheme.
>>>> ...
>>> 
>>> URI schemes do not *need* to define fragment handling. It's
>>> inherent once the media type has been determined.
>>> 
>>> Best regards, Julian
>>> 
>>> _______________________________________________
>>> art mailing list
>>> art@ietf.org
>>> https://www.ietf.org/mailman/listinfo/art
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
>> _______________________________________________
>> art mailing list
>> art@ietf.org
>> https://www.ietf.org/mailman/listinfo/art
> 
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/