Subject: Re: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu

From: Magnus Westerlund <[email-masked]>
Date: Wed, 2 May 2012 15:22:42 +0200

Hi Ted,

Thanks for the review.

On 2012-04-27 16:40, Ted Hardie wrote:
> Howdy,
> 
> The registrations below note that there were changes in URI syntax.  I
> could not find a summary of
> them in 2326bis; can you provide a pointer?

The changes section in the I-D says the following that applies to the URI.

      *  Added a fragment part to the RTSP URI.  This seemed to be
         indicated by the note below the definition, however, it was not
         part of the ABNF.

Which is clearly not the whole story. Thus I have also checked the
Syntax differences between the two specs.

RFC2326 defines the URI as:

   rtsp_URL  =   ( "rtsp:" | "rtspu:" )
                 "//" host [ ":" port ] [ abs_path ]
   host      =   <A legal Internet host domain name of IP address
                 (in dotted decimal form), as defined by Section 2.1
                 of RFC 1123>
   port      =   *DIGIT

   abs_path is defined in [H3.2.1].

>From RFC 2068:

          abs_path       = "/" rel_path
          rel_path       = [ path ] [ ";" params ] [ "?" query ]

          path           = fsegment *( "/" segment )
          fsegment       = 1*pchar
          segment        = *pchar

          params         = param *( ";" param )
          param          = *( pchar | "/" )

          scheme         = 1*( ALPHA | DIGIT | "+" | "-" | "." )
          net_loc        = *( pchar | ";" | "?" )

          query          = *( uchar | reserved )
          fragment       = *( uchar | reserved )

          pchar          = uchar | ":" | "@" | "&" | "=" | "+"
          uchar          = unreserved | escape
          unreserved     = ALPHA | DIGIT | safe | extra | national

          escape         = "%" HEX HEX
          reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
          extra          = "!" | "*" | "'" | "(" | ")" | ","
          safe           = "$" | "-" | "_" | "."
          unsafe         = CTL | SP | <"> | "#" | "%" | "<" | ">"
          national       = <any OCTET excluding ALPHA, DIGIT,
                           reserved, extra, safe, and unsafe>

While draft-ietf-mmusic-rfc2326bis-29 defines it as:

   RTSP-URI       =  schemes ":" URI-rest
   RTSP-REQ-URI   =  schemes ":" URI-req-rest
   RTSP-URI-Ref   =  RTSP-URI / RTSP-Relative
   RTSP-REQ-Ref   =  RTSP-REQ-URI / RTSP-REQ-Rel
   schemes        =  "rtsp" / "rtsps" / scheme
   scheme         =  < As defined in RFC 3986>
   URI-rest       =  hier-part [ "?" query ] [ "#" fragment ]
   URI-req-rest   =  hier-part [ "?" query ]
                     ; Note fragment part not allowed in requests
   hier-part      =  "//" authority path-abempty

   RTSP-Relative  =  relative-part [ "?" query ] [ "#" fragment ]
   RTSP-REQ-Rel   =  relative-part [ "?" query ]
   relative-part  =  "//" authority path-abempty
                     / path-absolute
                     / path-noscheme
                     / path-empty

   authority      =  < As defined in RFC 3986>
   query          =  < As defined in RFC 3986>
   fragment       =  < As defined in RFC 3986>

   path           =  path-abempty    ; begins with "/" or is empty
                     / path-absolute ; begins with "/" but not "//"
                     / path-noscheme ; begins with a non-colon segment
                     / path-rootless ; begins with a segment
                     / path-empty    ; zero characters

   path-abempty   =  *( "/" segment )
   path-absolute  =  "/" [ segment-nz *( "/" segment ) ]
   path-noscheme  =  segment-nz-nc *( "/" segment )
   path-rootless  =  segment-nz *( "/" segment )
   path-empty     =  0<pchar>

   segment        =  *pchar [";" *pchar]
   segment-nz     =  ( 1*pchar [";" *pchar]) / (";" *pchar)
   segment-nz-nc  =  ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc)
                     ; non-zero-length segment without any colon ":"

   UPALPHA         =  %x41-5A ; any US-ASCII uppercase letter "A".."Z"
   LOALPHA         =  %x61-7A ;any US-ASCII lowercase letter "a".."z"
   ALPHA           =  UPALPHA / LOALPHA
   DIGIT           =  %x30-39 ; any US-ASCII digit "0".."9"
   safe            =  "$" / "-" / "_" / "." / "+"
   extra           =  "!" / "*" / "'" / "(" / ")" / ","
   unreserved      =  ALPHA / DIGIT / safe / extra
   pct-encoded    =  < As defined in RFC 3987>

   pchar          =  unreserved / pct-encoded / sub-delims / ":" / "@"
   pchar-nc       =  unreserved / pct-encoded / sub-delims / "@"

   sub-delims     =  "!" / "$" / "&" / "'" / "(" / ")"
                     / "*" / "+" / "," / "="

So actual changes for the rtsp scheme I have found are:

- Fragments added with syntax. As the previous change comments says
there are discussion of URI fragments in RFC2326 but no syntax defined.
However, fragments are not allowed in request URIs.

- Support for IPV6 literal in host part and future IP literals through
RFC 3986 defined mechanism.

- It defines a relative format to use in RTSP protocol elements that is
not required to start with "/". This was not allowed in RFC2326 due to
the syntax definition.

There might be more but I have reviewed the syntax fairly careful. But

In addition the URI related changes the ID does are:

- Defining the syntax for the rtsps scheme which is in use but not defined.

- Register the rtspu scheme defined in RFC 2326 but not registered.

> 
> rtsp was already registered in the URI Schemes registry as permanent;
> significant changes to the syntax
> would probably require minting a new scheme to avoid the
> interoperability problems you note below.

I agree that if we would have significant changes it would be
problematic. At the same time introducing a new scheme for rtsp would
also have been problematic. I consider the above changes to be minor and
to extend the functionality of the old definition, not change what has
existed since RFC 2326. The new extended functionality can cause failure
if you try to use these. Thus the documentation of these changes needs
to be improved. I will take it as WG last call comment.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Larry Masinter <[email-masked]>
Date: Mon, 7 May 2012 16:27:53 -0700

Please note that the URI/IRI registration guidelines (4395bis) have a proposed "fix":

http://wiki.tools.ietf.org/wg/iri/trac/ticket/125

to add the sentence:

"However, the registration defines <scheme> and the syntax and semantics of <fragment>  depends only on the media type of the representation accessed. New scheme definitions MUST NOT define syntax or semantics of fragment identifiers; that is, registration specifications should define the syntax of <scheme-specific-part> and its meaning for each <scheme> defined."

That is, the recommendation is that scheme registrations do *not* specify the syntax or meaning of fragment identifiers.

So "Added a fragment part to the RTSP URI.  " might not be considered an improvement.

Regards,

Larry
--
http://larry.masinter.net

-----Original Message-----
From: [email-masked] On Behalf Of Magnus Westerlund
Sent: Wednesday, May 02, 2012 6:23 AM
To: Ted Hardie
Cc: [email-masked]; [email-masked]
Subject: Re: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu

Hi Ted,

Thanks for the review.

          abs_path       = "/" rel_path

          escape         = "%" HEX HEX

Cheers

Magnus Westerlund

_______________________________________________
Uri-review mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/uri-review

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 8 May 2012 11:45:18 +0200

On 2012-05-08 01:27, Larry Masinter wrote:
> "However, the registration defines <scheme> and the syntax and
> semantics of <fragment>  depends only on the media type of the
> representation accessed. New scheme definitions MUST NOT define
> syntax or semantics of fragment identifiers; that is, registration
> specifications should define the syntax of <scheme-specific-part> and
> its meaning for each <scheme> defined."
> 
> That is, the recommendation is that scheme registrations do *not*
> specify the syntax or meaning of fragment identifiers.
> 

Larry,

Can you please clarify something for me. What I have done is that I have
made it clear in the URI syntax that the fragment ABNF construct from
RFC 3986 MAY occur in an valid rtsp URI syntax. Are you saying that this
is not the right thing to do? How could I then indicate the appropriate
syntax  when the fragment identifier occur with the URI scheme being
defined? Can't I even say that fragments is not allowed for a scheme?
This appear to be the case if one would implicitly define the fragment
in an URI scheme.

Cheers

Magnus Westerlund

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 May 2012 12:15:13 +0200

> is not the right thing to do? How could I then indicate the appropriate

It's pointless, as a URI scheme definition can't override RFC 3986, and 
parsing of scheme name and fragment are already defined by RFC 3986.

Optimally, a new scheme definition just defines the scheme-specific part.

> defined? Can't I even say that fragments is not allowed for a scheme?

No.

> This appear to be the case if one would implicitly define the fragment

Exactly :-)

Best regards, Julian

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 8 May 2012 13:48:07 +0200

>> This appear to be the case if one would implicitly define the fragment

But, then what I have done isn't wrong either as I haven't override the
rules for fragment, only made it clear how they interface with the URI
definition. From my perspective I can remove the fragment syntax
definition, but I would instead at least explicitly call out that
fragments may occur following RFC 3986 syntax. Personally I don't see
that as being better.

Secondly, when we are on this topic. Can someone answer how you
determine the media type for an rtsp URI? RTSP URI points to resources
that can provide controlled playback of the resource using any number of
media types in form of RTP payloads formats depending on what is
suitable for the resource. In fact from issuing an PLAY request on an
audio only resource you still can receive a media stream where the
format it is encoded my actually change during the playback operation.

To be clear I don't plan to define a fragment handling format for RTSP
URIs, but there has been discussion in the past the desire has been to
do something that is media format agnostic. The goal has been to have an
uri where you basically say: Play this resource from 5 min 10 seconds
until 9 min 37 seconds. The proposal is in this 2005 draft.
http://tools.ietf.org/html/draft-pfeiffer-temporal-fragments-03

But, if the above really isn't possible the question of fragments for
RTSP is really mote and is just a waste of time to discuss.

Cheers

Magnus Westerlund

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 May 2012 14:14:32 +0200

> fragments may occur following RFC 3986 syntax. Personally I don't see

+0.5.

I agree that what the spec does isn't wrong; it's just a bit misleading 
in that it implies that a URI scheme definition has *any* authority over 
the fragment identifier.

> ...

As Larry just mentioned: <http://www.w3.org/TR/media-frags/>

Best regards, Julian

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 May 2012 10:11:22 -0700

On Tue, May 8, 2012 at 3:15 AM, Julian Reschke <[email-masked]> wrote:

> 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

---

From: Larry Masinter <[email-masked]>
Date: Tue, 8 May 2012 10:14:06 -0700

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:[email-masked]] 
Sent: Tuesday, May 08, 2012 10:11 AM
To: [email-masked]
Cc: Magnus Westerlund; Larry Masinter; [email-masked]; [email-masked]
Subject: Re: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu

regards,

Ted

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 May 2012 19:47:15 +0200

On 2012-05-08 19:11, Ted Hardie wrote:
> On Tue, May 8, 2012 at 3:15 AM, Julian Reschke<[email-masked]>  wrote:
>

A URI has an associated resource *by definition*.

The interesting question is whether there's a way to retrieve a sequence 
of octets describing it...

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 May 2012 10:55:57 -0700

On Tue, May 8, 2012 at 10:47 AM, Julian Reschke <[email-masked]> wrote:
> The interesting question is whether there's a way to retrieve a sequence of
> octets describing it...

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
mailto:[email-masked] is
not really sensible; a fragment for that identifier is thus not sensible.

Ted

/who is not yet a sequence of octets

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 8 May 2012 11:36:24 -0700

> 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

   mailto:[email-masked]#subject

could be used, for example, to refer to either the owner of that mailbox
or to opening an email entry form with "[email-masked]" pre-filled
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.

....Roy

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 May 2012 13:56:21 -0700

> They occasionally have something to do with how schemes are used,

In the context of registration, I personally believe that a definition
of how a scheme is expected to be used is sensible.  In that context,
stating whether or not you'd expect to see fragments in the given
usage would be appropriate, provided it doesn't contradict the core
spec.  At a base level, the core spec says that fragments allow you to
identify secondary resources related to the main resource; if that's
not expected because of the semantics of the scheme, I think it's
useful to say so.

regards,

Ted Hardie

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 09 May 2012 10:42:28 +0900

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 8 May 2012 21:28:56 -0700

On May 8, 2012, at 6:42 PM, Martin J. Dürst wrote:
> 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:
> 
> 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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 09 May 2012 14:41:05 +0900

>>    ignored upon resolution.  The character "#" in<hfvalue>s MUST be
>>    escaped as %23.
>>

Thanks, fixed in my internal copy.

Regards,    Martin.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 9 May 2012 07:21:28 -0700

On Tue, May 8, 2012 at 9:28 PM, Roy T. Fielding <[email-masked]>

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

regards,

Ted

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 10 May 2012 10:44:21 -0700

> 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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 11 May 2012 15:14:39 +0900

On 2012/05/11 2:44, Roy T. Fielding wrote:
>> On Tue, May 8, 2012 at 9:28 PM, Roy T. Fielding<[email-masked]>

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