Subject: Re: [art] Question regarding RFC 8089

From: [email-masked] (Dale R. Worley)
Date: Wed, 16 Jan 2019 21:50:01 -0500

John C Klensin <[email-masked]> writes:
> 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.

I argue that the *scheme* does not define whether a fragment identifier
is permitted, but rather the media type of the referenced resource
defines it.

This does mean that if the scheme defines its URIs in such a way that
the referenced resource can never have a media type, or can never have a
media type that defines fragment identifiers, then the scheme
effectively forbids the use of fragment identifiers.  (sip: is an
example of such a scheme; its referenced resource can only be used
dynamically, and cannot be instantiated as a "media object".)

It may well be worth noting in a scheme definition whether one of these
cases hold, but it isn't *defining*.

Dale

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 17 Jan 2019 10:19:02 -0800

> On Jan 16, 2019, at 6:50 PM, Dale R. Worley <[email-masked]> wrote:
> 

That is a reasonable argument, but it isn't quite true. A resource that is not
dereferenced doesn't have an associated media type at that point in time, but
this doesn't prevent it from having one at some other point in time, or when
referenced within some other context, no matter what the scheme says.
For example, HTTP can be used to dereference sip identifiers and the media
type of the response does support fragment ids.

We say that the fragment is unconstrained by the scheme because that's
how indirect identifiers work.  I can identify my son without using his name,
and I can identify my daughter even though I don't have one.

The right thing to do is to simply admit that indirect identifiers exist, provide
them with a syntax that won't be confused with the direct identifier, and let
systems decide whether to use them or not based on their usefulness for
that system (not based on committee opinions).

....Roy

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 17 Jan 2019 22:29:05 -0500

> type of the response does support fragment ids.

I must admit I'm not following your example.

Dale

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 18 Jan 2019 08:31:51 +0000

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

Regards,   Martin.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 18 Jan 2019 10:18:15 -0800

> On Jan 18, 2019, at 12:31 AM, Martin J. Dürst <[email-masked]> wrote:
> 

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

---

From: Larry Masinter <[email-masked]>
Date: Fri, 18 Jan 2019 11:52:05 -0800

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 <[email-masked]> On Behalf Of Roy T. Fielding
> Sent: Friday, January 18, 2019 10:18 AM
> To: "Martin J. Dürst" <[email-masked]>
> Cc: [email-masked]; Dale R. Worley <[email-masked]>
> Subject: Re: [art] Question regarding RFC 8089
> 
> >>> For example, HTTP can be used to dereference sip identifiers and the
> >>> media type of the response does support fragment ids.
> >>
> > 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
> >
> Hence, fragment is an optional component of a URI reference, not part of a
> URI scheme's definition.
> 
> ....Roy
> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 18 Jan 2019 14:29:53 -0800

> On Jan 18, 2019, at 11:52 AM, Larry Masinter <[email-masked]> wrote:
> 

Hi Larry,

We deployed this in 1994.

   http://1997.webhistory.org/www.lists/www-talk.1994q1/0549.html

It is still implemented in many current proxying clients.

> Yes, theoretically, something like this COULD be specified without breaking HTTP,

It has been specified in HTTP/1.x since 1995.

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

It is not a question of "want" or "should be treated", nor even a question of whether
or not is is a good idea.  It is a fact.  That's how HTTP was designed to work.

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

I can. I still remember implementing it in libwww-perl.

....Roy

---

From: Graham Klyne <[email-masked]>
Date: Sun, 20 Jan 2019 16:19:04 +0000

FWIW, the EMWAC (Edinburgh Uni) web server implemented proxying of non-HTTP URIs 
back in about 1998.  I recall this capability being used by a company I worked 
for to implement content scanning of material accessed from FTP servers.

Generally, I think it was quite common back then to put ftp:... into a browser 
bar and have that retrieved via HTTP and a proxy server.

#g
--

On 18/01/2019 22:29, Roy T. Fielding wrote:
> .....Roy