Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review

["Roy T. Fielding" <[e-mail]>]

> 
> On Apr 9, 2015, at 8:20 PM, Peter Saint-Andre - &yet <[e-mail]> wrote:
> 
>> On 4/9/15 1:13 PM, Roy T. Fielding wrote:
>> On Apr 9, 2015, at 7:41 AM, John C Klensin wrote:
>> 
>>>> For the specific case of urnbis, consensus on 2141bis would
>>>> allow it to specify how urn: registrations work, independent
>>>> of what's said here.  I would say that if 2141bis specifically
>>>> contradicts something here, it should explicitly call that
>>>> out, to be absolutely clear about it.
>>> 
>>> That is fine.  I would appreciate it if you and/or others who
>>> are relevant would figure out, now, if 2141bis said something
>>> contradictory to what is said in
>>> draft-ietf-appsawg-uri-scheme-reg whether it should be noted as
>>> updating this document.   I don't care what the answer is; I
>>> just do not want to have a time-consuming late-stage controversy
>>> about the issue.
>>> 
>>> More important, neither the changes nor your note address the
>>> particular issue that caused my review and concerns about
>>> draft-ietf-appsawg-uri-scheme-reg.  The issue was the claim that
>>> this document imposed additional constraints or requirements in
>>> addition to those of RFC 3986, requirements that could (or did)
>>> invalidate what the URNBIS WG is trying to do with
>>> draft-ietf-urnbis-semantics-clarif.
>>> 
>>> I believe the key issue is that, as far as the _syntax_
>>> specified in RFC 3986 is concerned, there is a syntax component,
>>> given the name "fragment" in the defining production, that,
>>> informally, is delimited by the first appearance of "#" in a URI
>>> and that extends to the end of the URI.  Anything more --
>>> bindings to schemes, relationships to media types, even the
>>> binding of the term "fragment" to anything one might find in a
>>> dictionary-- are matters of semantics (or maybe something else)
>>> but not syntax.
>> 
>> They are a product of what it is to be a URI.  Whether you call that
>> syntax or semantics is irrelevant.
>> 
>>> Consequently, when this document says, in the second paragraph
>>> of Section 3,
>>> 
>>>    "A scheme definition cannot override the overall syntax
>>>    for URIs.  For example, this means that fragment
>>>    identifiers cannot be re-used outside the generic syntax
>>>    restrictions, and fragment identifiers are not
>>>    scheme-specific."
>>> 
>>> we have at statement that is at least confusing (if not a
>>> logical fallacy) and one that creates an opportunity for
>>> arguments about what an effort to specify or update a URI scheme
>>> (even a standards-track one associated with at WG) attempts to
>>> do.
>> 
>> No, it is a statement of fact.  Wherever a URI might be used as a
>> protocol element, there is an explicit role assigned to the fragment
>> portion of the syntax that cannot be redefined by any scheme.
> 
> My understanding of "role" here is that you probably intend it to denote a specific semantic meaning.

No. It is a piece of syntax reserved for a specific role in the processing of hypertext references. It might gain semantics when used in a certain way, but it doesn't have semantics in and of itself (or at least no more semantics than any other name).

> 
>> Any claim to the contrary, whether that be by an individual or
>> by IETF standards track working group consensus, is wrong.
>> 
>> This does not, however, have any impact on the ability of the urn
>> scheme to define identifiers that exclude a fragment, nor on the
>> use of urn identifiers with arbitrary fragments as defined by 3986.
>> The fragment is part of the overall identifier -- it just isn't
>> dependent on the scheme and cannot be forbidden by a scheme.
> 
> If I understand this correctly, it means that no scheme can say that URIs in general cannot contain fragment identifiers. But no scheme definition tries to do that, AFAIK.

The fragment doesn't have anything to do with the scheme, period. This is a layer violation as obvious as defining TLS within HTTP. Yes, we do that some times, but that doesn't make it right. If you don't want that role to be in effect, then don't use fragment.

> 
>> The semantics, if any, for a fragment depend entirely on how the
>> identifier is used.  If it is used as an HTTP request-target, the
>> fragment portion will not be sent, regardless of the URI scheme.
>> The same is true for other retrieval protocols.  If the identifier
>> is never used for retrieval, the fragment's semantics are unbounded.
>> 
>> Now, you might claim that "urn" schemes are not intended for retrieval.
>> Even if that were true (it isn't), it still wouldn't matter.  Given any URI,
>> an HTTP request can be used to attempt retrieval of a representation,
>> which means that any URI (sans fragment) can be used for retrieval
> 
> What does it mean to make an HTTP request for, say, a SIP URI?

What does it mean to make a Web request for a SIP URI? It doesn't have to be using HTTP. If you can define what it means for SIP, then it can be represented via HTTP as well. If not, then the attempt will fail. Nevertheless, the attempt will exclude the fragment because that information is reserved for client-side processing (if any).  

If such a URI is never used in that fashion, then no semantics are assumed for the fragment. This does not mean a scheme like sip can redefine or disallow fragments, since it doesn't control how its identifiers might be used.

>> if it is possible to configure a suitable service for such resolution,
>> where "suitable" is judged by the provider and users of that service,
>> not by the working group that defines the identifiers.
>> 
>> No scheme definition can escape those facts, which is why both 3986
>> and the scheme registration document say so explicitly.
> 
> I don't see anything in RFC 3986 that says a URI must be "resolvable" via HTTP.

There is no need for it to say anything like that. It does not change the fact that the fragment has a specific role when present in a URI. It is a uniform syntax for a reason.

> 
>> This does
>> not prevent anyone from using (or not using) fragments with some
>> urn identifiers.  It only prevents them from escaping how they are
>> processed when used as a URI protocol element, since that processing
>> is independent of scheme.
> 
> But IMHO it doesn't always make sense to use URIs with any random URI scheme in any given URI protocol slot. What does it mean to place a 'sip' or 'data' or 'iax' or 'msrp' (etc.) URI in the 'xmlns' protocol slot in XML? What does it mean to place an 'http' URI in the Request-URI protocol slot in SIP? (In fact, RFC 3261 says that only a SIP or SIPS URI is allowed there.) To say that every protocol slot in which a URI can appear must accept URIs from all schemes seems off-base to me.

It doesn't matter. To the extent that some use is not allowed or simply doesn't make sense, the fragment remains free of any semantics and can be used as a name. It can therefore be used with such URIs even if the scheme is completely unaware of its possible existence.

>>>   In addition to whatever was intended, the statement could
>>> be read as "fragments are required to be allowed with all URI
>>> schemes and no individual scheme can prohibit them".  I'm fairly
>>> confident that is not what the authors of either this document
>>> or 3986 intended, but, if that sort of ambiguity exists, it is
>>> unreasonable to claim that there is informed community consensus
>>> about this document.
>> 
>> Of course that is what 3986 intended.  We have archived history of
>> the URI protocol discussions.  None of this should be a surprise.
> 
> No scheme can prohibit fragments in that scheme as a matter of "local policy" (as it were), or no scheme can prohibit fragments in general?

No scheme can prohibit fragments. They are not part of the scheme's syntax.

....Roy