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

[Larry Masinter <[e-mail]>]

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: [e-mail] On Behalf Of Magnus Westerlund
Sent: Wednesday, May 02, 2012 6:23 AM
To: Ted Hardie
Cc: [e-mail]; [e-mail]
Subject: Re: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu

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  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------

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