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

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

> On Apr 15, 2015, at 11:54 PM, Sean Leonard <[e-mail]> wrote:
> 
> 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.

You are confusing resources with representations.  Resources do not have media types,
though they might have representations that are consistently the same media type.
Resources don't even need to have representations.

Regardless, the scheme does not define the kinds of representations. It only defines the
rules for name allocation within a uniform syntax for that name.  What kinds of
representations are so named depends *entirely* on how the identifiers are used, not on
the scheme.  For example, a VIN (physical identifier assigned to a vehicle by its
manufacturer) is clearly intended to uniquely identify a car.  However, its primary
uses are to indirectly identify registration records, odometer readings, and insurance
policies.  If a urn namespace for vin is assigned and a urn:vin: is used in HTTP for a
GET of a representation, the response will not be a car.

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

Actually, what it identifies is a pre-defined template for an email message.
Fragment identifiers are rarely used here because implementations are inconsistent,
not because there is anything unusual about the scheme.  Note that mailto is *also*
used for other things, like mailbox identifiers, in which the context of use clearly
does not support the use of fragments (just like they don't support subject or body
definitions within query).  That's fine.

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

Obviously, that is a bug in that spec.  An errata should be attached to it.
For example,

   mailto:[e-mail]#cc

is a valid use of fragment for the mailto URI (it instructs the user agent to
place the input context on the cc field after presentation of the template).

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

The text violates the requirements of STD66, the standard upon which it is
supposed to be entirely dependent.  It is an obvious bug,

> Sean
> 
> PS I could be wrong but [RFC3966] looks like it permits the # character in the tel: URI in the path part.

It does not.  Read the text around gen-delims in section 2.2.

....Roy