In WG last call review of URI Schemes rtsp, rtsps and rtspu

[Larry Masinter]

Note that the URNbis working group has been discussing fragment identifiers for URNs.
If you say a URN is merely a URI using the "urn:" scheme, then perhaps whether
URNs allow fragment identifiers should be out of scope for the URNbis working group.

Larry


-----Original Message-----
From: Ted Hardie [mailto:***@gmail.com]
Sent: Tuesday, May 08, 2012 10:11 AM
To: ***@gmx.de
Cc: Magnus Westerlund; Larry Masinter; mmusic-***@tools.ietf.org; uri-***@ietf.org
Subject: Re: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu

Can't I even say that fragments is not allowed for a scheme?
No.

I'm not sure I agree with this. If a registration is intended to
create an identifier that has no associated resource (and thus no
media type), it could say that fragments are not permitted. This is a
restatement of something that can be inferred from 3986, but I think
it's a useful thing to reinforce.

regards,

Ted

[Martin J. Dürst]

Well, perhaps a less theoretical distinction would be whether or not
what a URI is associated can have a media type. A media type for
not really sensible; a fragment for that identifier is thus not sensible.

No, fragments have nothing to do with the definition of schemes.
They occasionally have something to do with how schemes are used,
such as
could be used, for example, to refer to either the owner of that mailbox
in the To field and the active cursor placed in an input field named
subject. We don't know its true definition, if any, until someone
builds a system that happens to use the identifier in that fashion.

This is what both http://tools.ietf.org/html/rfc6068 ("The 'mailto' URI
Scheme") and http://tools.ietf.org/html/draft-duerst-eai-mailto-03 (an
update to include EAI) currently say on this topic:

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 seems to be fully in line with the discussion up to here, including
Roy's comment above, but if anybody thinks it needs to be changed,
please send some new proposed wording.

Taking the above text, and adopting it for the rtsp situation, might
lead to something like:

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. For
'rtsp', 'rtsps', and 'rtspu' URIs, care has to be taken that a
fragment identifier designates equivalent subresources across the
media types that can be returned when resolving the URI.


In terms of syntax, I think that as things stand, Magnus has a point.
Scheme definition specs that use rules in the way this is done in
http://tools.ietf.org/html/rfc6068#section-2, i.e. without adding an
optional fragment part, are technically wrong. On the other hand, specs
such as the XMPP URI/IRI spec, which includes #(i)fragment (see
http://tools.ietf.org/html/rfc5122#page-6), are technically correct.

The fact that e.g. the mailto: spec gets this wrong seems to be a
leftover of the change from RFC 2396, where fragments were not
considered to be part of an URI, but together with an URI formed what
was called an URI reference (see
http://tools.ietf.org/html/rfc2396#appendix-A), and RFC 3986
(http://tools.ietf.org/html/rfc3986#appendix-A), where URIs
syntactically included fragment identifiers. This was the right change
for a lot of reasons, but as we are finding out now somehow seems to
leave URI scheme designers in a tough place because syntactically, they
should mention the fragment, but semantically, they better wouldn't.

I think we need to look at some more URI/IRI registrations from this
point of view to see what's best for RFC 4395bis.

Regards, Martin.

[Roy T. Fielding]

Post by Martin J. Dürst

Well, perhaps a less theoretical distinction would be whether or not
what a URI is associated can have a media type. A media type for
not really sensible; a fragment for that identifier is thus not sensible.

No, fragments have nothing to do with the definition of schemes.
They occasionally have something to do with how schemes are used,
such as
could be used, for example, to refer to either the owner of that mailbox
in the To field and the active cursor placed in an input field named
subject. We don't know its true definition, if any, until someone
builds a system that happens to use the identifier in that fashion.

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 seems to be fully in line with the discussion up to here, including Roy's comment above, but if anybody thinks it needs to be changed, please send some new proposed wording.

The second to last sentence is wrong. That spec cannot make
normative requirements about something that is out of scope;
any fragment is completely outside the scope of a URI scheme
specification. Just remove the "Therefore, ... resolution."
sentence -- it serves no useful purpose.

....Roy

[Martin J. Dürst]

Post by Roy T. Fielding

Post by Martin J. Dürst
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 seems to be fully in line with the discussion up to here, including Roy's comment above, but if anybody thinks it needs to be changed, please send some new proposed wording.

The second to last sentence is wrong. That spec cannot make
normative requirements about something that is out of scope;
any fragment is completely outside the scope of a URI scheme
specification. Just remove the "Therefore, ... resolution."
sentence -- it serves no useful purpose.
....Roy

Thanks, fixed in my internal copy.

Regards, Martin.

[Ted Hardie]

  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 seems to be fully in line with the discussion up to here, including Roy's comment above, but if anybody thinks it needs to be changed, please send some new proposed wording.

The second to last sentence is wrong.  That spec cannot make
normative requirements about something that is out of scope;
any fragment is completely outside the scope of a URI scheme
specification.  Just remove the "Therefore, ... resolution."
sentence -- it serves no useful purpose.
....Roy

Would you still object if it simply said "Therefor fragment
identifiers are meaningless in current email contexts."? I think this
remains useful and it eliminates the normative language.

regards,

Ted

[Roy T. Fielding]

Post by Ted Hardie

Post by Roy T. Fielding

Post by Martin J. Dürst
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 seems to be fully in line with the discussion up to here, including Roy's comment above, but if anybody thinks it needs to be changed, please send some new proposed wording.

The second to last sentence is wrong. That spec cannot make
normative requirements about something that is out of scope;
any fragment is completely outside the scope of a URI scheme
specification. Just remove the "Therefore, ... resolution."
sentence -- it serves no useful purpose.
....Roy

Would you still object if it simply said "Therefor fragment
identifiers are meaningless in current email contexts."? I think this
remains useful and it eliminates the normative language.

I wouldn't object, but I personally don't like talking about
"current contexts" in a spec that will live for decades.
I don't see why it matters -- if it is meaningless, nobody
will use them; if they use them, they won't be meaningless.

....Roy

[Martin J. Dürst]

Post by Roy T. Fielding

Post by Ted Hardie

Post by Roy T. Fielding

Post by Martin J. Dürst
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 seems to be fully in line with the discussion up to here, including Roy's comment above, but if anybody thinks it needs to be changed, please send some new proposed wording.

The second to last sentence is wrong. That spec cannot make
normative requirements about something that is out of scope;
any fragment is completely outside the scope of a URI scheme
specification. Just remove the "Therefore, ... resolution."
sentence -- it serves no useful purpose.

Would you still object if it simply said "Therefor fragment
identifiers are meaningless in current email contexts."? I think this
remains useful and it eliminates the normative language.

I wouldn't object, but I personally don't like talking about
"current contexts" in a spec that will live for decades.
I don't see why it matters -- if it is meaningless, nobody
will use them; if they use them, they won't be meaningless.

I agree that "current contexts" is the wrong wording. What about
something like:
"Therefore, at the time of publication of this document, fragment
identifiers are meaningless in current email contexts."

Regards, Martin.