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

[Sean Leonard <[e-mail]>]

On Apr 10, 2015, at 8:44 PM, Roy T. Fielding <[e-mail]> wrote:

>> On Apr 10, 2015, at 8:38 AM, Barry Leiba <[e-mail]> wrote:
>> 
>>> No scheme can prohibit fragments. They are not part of the scheme's syntax.
>> 
>> We continue to have a confusion between syntax and semantics here.
>> 
>> I absolutely agree that no scheme can say that fragments are
>> syntactically invalid, because the schemes do not control the syntax
>> of a URI.
>> 
>> But a scheme can certainly say that fragments make no semantic sense
>> within that scheme, and that if a URIs uses that scheme and contains a
>> fragment, it is not a well formed URI within that scheme.
> 
> No, they can't, or at least they cannot say that truthfully.
> 
>> It's rather like saying that English words are composed of characters
>> from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the string
>> "qwx" is a valid piece of an English word (syntax)... but that, in
>> fact, no valid English words contain "qwx" (semantics).
> 
> Sorry, you've lost me.
> 
> It is more like saying that, because host and port are adjacent to each other in
> the syntax, it is therefore possible for DNS to specify what ports are allowed.
> 
>> That's not a layering violation at all -- it has to be up to the
>> scheme to say what the semantic meaning of a fragment is within that
>> scheme, or whether fragments have any meaning at all.
> 
> It has nothing to do with the scheme. Nothing whatsoever. It is true that there
> are many resources, regardless of scheme, for which a fragment identifier wouldn't
> have much practical purpose other than as a name, but that's only because
> nobody has found a reason to resolve them yet. In most cases, this is because
> deployment of the scheme is so small that it isn't worth anyone's bother to create
> a gateway for information about its identified resources.

I agree with Barry.

The scheme transitively defines the semantic meaning of fragments because the scheme defines the kinds of resources (if any) that are identified by it. Those resources may or may not have Internet media types, and those resources may or may not assign semantic meanings to fragments.

mailto: defines a URI scheme that does not identify representations of anything; it is used to launch a compose window to create new mail. (Arguably a mailto: URI identifies a mailbox.) Therefore fragment identifiers have no semantic meaning in mailto: because mailto: doesn’t use them.

[RFC6068] says:
   Note that this specification, like any URI scheme specification, does
   not define syntax or meaning of a fragment identifier (see [STD66]),
   because these depend on the type of a retrieved representation.  In
   the currently known usage scenarios, a 'mailto' URI cannot be used to
   retrieve such representations.  Therefore, fragment identifiers are
   meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be
   ignored upon resolution.  The character "#" in <hfvalue>s MUST be
   escaped as %23.


This text is entirely consistent with Barry’s point. The scheme may not define the semantics of the fragment directly, but it defines the resources (representations), which in turn define the fragments.

Sean

PS I could be wrong but [RFC3966] looks like it permits the # character in the tel: URI in the path part. Is there a legacy reason for that, or just an oversight?