Re: [art] Question regarding RFC 8089

This bit that HTTP can be used by a proxy to resolve any URLs, not just http: and https: ones, is weakly supported by a passing MAY.
There isn't sufficient evidence of independent interoperable implementations (based on specification) for such a major extension to the "range of the HTTP dereference function".
Yes, theoretically, something like this COULD be specified without breaking HTTP, but that's different from saying that scheme registrations can't restrict the use of fragment identifiers with URLs of that scheme.    I think that if you want to allow fragments in URLs of a given scheme, the scheme definition should define how it should be treated by fetch, and if such use requires generation of "some metadata document", how those metadata documents work with fragment identifiers should be defined (by their MIME type's registration, I suppose).

So I'd say no, you can't use a fragment identifier with a "mailto:" URL. Or a "sip:" one. But ok with "data:", and even "ftp" and "file".

In any case, perhaps a document update to BCP 35 guidelines might be called for, and possibly a clarification in  3986 (URI).

Larry
--
https://LarryMasinter.net

> -----Original Message-----
> From: art <art-bounces@ietf.org> On Behalf Of Roy T. Fielding
> Sent: Friday, January 18, 2019 10:18 AM
> To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
> Cc: art@ietf.org; Dale R. Worley <worley@ariadne.com>
> Subject: Re: [art] Question regarding RFC 8089
> 
> > On Jan 18, 2019, at 12:31 AM, Martin J. Dürst <duerst@it.aoyama.ac.jp>
> wrote:
> >
> > On 2019/01/18 12:29, Dale R. Worley wrote:
> >> "Roy T. Fielding" <fielding@gbiv.com> writes:
> >>> For example, HTTP can be used to dereference sip identifiers and the
> >>> media type of the response does support fragment ids.
> >>
> >> I must admit I'm not following your example.
> >
> > I'm not familiar with sip, but I can easily imagine a http server
> > returning some metadata documents for some specific sip: URIs, the
> > same way it could for some specific mailto: URI.
> >
> > The only thing you have to do to make such a server work is to set it
> > up so that it responds to requests of the form
> >
> > GET mailto:abc@example.com HTTP/1.1
> >
> > or some such. This is allowed by http, it's how proxying works. The
> > responses are not authoritative, but they have mime types and may work
> > with fragment identifiers.
> 
> Right, a proxy server can be configured so that any given full URI passed via
> an HTTP request has a response that is effectively a hypertext client for a
> service capable of resolving the given identifier and presenting something
> useful to the user. What that might be is controlled by the proxy service, not
> the identifier being used (i.e., the proxy server might only be for metadata,
> or it might be a Skype proxy, or it might be a webrtc Rickroll, etc.).
> Within that context, a fragment identifier can be defined by the media types
> for processing hypertext even if it was not anticipated by the scheme.
> 
> Hence, fragment is an optional component of a URI reference, not part of a
> URI scheme's definition.
> 
> ....Roy
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art