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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

masinter
Note on IRI working group document 4395bis:

I wonder if we should explicitly disallow documents that define new schemes from defining fragment identifier syntax within the scheme-specific syntax listed or referred to, in the scheme registration template.

See
http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-29#section-22.14.1

-----Original Message-----
From: [hidden email] on Behalf of Magnus Westerlund
Sent: Thursday, April 26, 2012 8:15 AM
To: [hidden email]
Cc: [hidden email]
Subject: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu

Hi,

There is currently an ongoing WG last call on RTSP 2.0.
The WGLC ends on May 16th, 2012.

https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/


22.14.  URI Schemes

   This specification defines two URI schemes ("rtsp" and "rtsps") and
   reserves a third one ("rtspu").  These URI schemes are defined in
   existing registries which are not created by RTSP.  Registrations are
   following RFC 4395[RFC4395].

22.14.1.  The rtsp URI Scheme

   URI scheme name:  rtsp

   Status:  Permanent

   URI scheme syntax:  See Section 20.2.1 of RFC XXXX.

   URI scheme semantics:  The rtsp scheme is used to indicate resources
         accessible through the usage of the Real-time Streaming
         Protocol (RTSP).  RTSP allows different operations on the
         resource identified by the URI, but the primary purpose is the
         streaming delivery of the resource to a client.  However, the
         operations that are currently defined are: DESCRIBE,
         GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, SETUP,
         SET_PARAMETER, and TEARDOWN.

   Encoding considerations:  IRIs in this scheme are defined and needs
         to be encoded as RTSP URIs when used within the RTSP protocol.
         That encoding is done according to RFC 3987.

   Applications/protocols that use this URI scheme name:  RTSP 1.0 (RFC
         2326), RTSP 2.0 (RFC XXXX)





Schulzrinne, et al.    Expires September 13, 2012             [Page 222]


Internet-Draft   Real Time Streaming Protocol 2.0 (RTSP)      March 2012


   Interoperability considerations:  The change in URI syntax performed
         between RTSP 1.0 and 2.0 can create interoperability issues.

   Security considerations:  All the security threats identified in
         Section 7 of RFC 3986 applies also to this scheme.  They need
         to be reviewed and considered in any implementation utilizing
         this scheme.

   Contact:  Magnus Westerlund, [hidden email]

   Author/Change controller:  IETF

   References:  RFC 2326, RFC 3986, RFC 3987, RFC XXXX

22.14.2.  The rtsps URI Scheme

   URI scheme name:  rtsps

   Status:  Permanent

   URI scheme syntax:  See Section 20.2.1 of RFC XXXX.

   URI scheme semantics:  The rtsps scheme is used to indicate resources
         accessible through the usage of the Real-time Streaming
         Protocol (RTSP) over TLS.  RTSP allows different operations on
         the resource identified by the URI, but the primary purpose is
         the streaming delivery of the resource to a client.  However,
         the operations that are currently defined are: DESCRIBE,
         GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, SETUP,
         SET_PARAMETER, and TEARDOWN.

   Encoding considerations:  IRIs in this scheme are defined and needs
         to be encoded as RTSP URIs when used within the RTSP protocol.
         That encoding is done according to RFC 3987.

   Applications/protocols that use this URI scheme name:  RTSP 1.0 (RFC
         2326), RTSP 2.0 (RFC XXXX)

   Interoperability considerations:  The change in URI syntax performed
         between RTSP 1.0 and 2.0 can create interoperability issues.

   Security considerations:  All the security threats identified in
         Section 7 of RFC 3986 applies also to this scheme.  They need
         to be reviewed and considered in any implementation utilizing
         this scheme.






Schulzrinne, et al.    Expires September 13, 2012             [Page 223]


Internet-Draft   Real Time Streaming Protocol 2.0 (RTSP)      March 2012


   Contact:  Magnus Westerlund, [hidden email]

   Author/Change controller:  IETF

   References:  RFC 2326, RFC 3986, RFC 3987, RFC XXXX

22.14.3.  The rtspu URI Scheme

   URI scheme name:  rtspu

   Status:  Permanent

   URI scheme syntax:  See Section 3.2 of RFC 2326.

   URI scheme semantics:  The rtspu scheme is used to indicate resources
         accessible through the usage of the Real-time Streaming
         Protocol (RTSP) over unreliable datagram transport.  RTSP
         allows different operations on the resource identified by the
         URI, but the primary purpose is the streaming delivery of the
         resource to a client.  However, the operations that are
         currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, PLAY,
         PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and TEARDOWN.

   Encoding considerations:  IRIs in this scheme are not defined.

   Applications/protocols that use this URI scheme name:  RTSP 1.0 (RFC
         2326)

   Interoperability considerations:  The definition of the transport
         mechanism of RTSP over UDP has interoperability issues.  That
         makes the usage of this scheme problematic.

   Security considerations:  All the security threats identified in
         Section 7 of RFC 3986 applies also to this scheme.  They needs
         to be reviewed and considered in any implementation utilizing
         this scheme.

   Contact:  Magnus Westerlund, [hidden email]

   Author/Change controller:  IETF

   References:  RFC 2326


--

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: [hidden email]
----------------------------------------------------------------------

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

Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
On 2012-05-02 18:00, Larry Masinter wrote:
> Note on IRI working group document 4395bis:
>
> I wonder if we should explicitly disallow documents that define new schemes from defining fragment identifier syntax within the scheme-specific syntax listed or referred to, in the scheme registration template.
>
> See
> http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-29#section-22.14.1
> ...

It appears that the document tries to do the right thing, but is
confused about whether it even needs to mention fragment identifiers.

Maybe the registration document should offer guidelines on how to handle
this properly (if it doesn't already)?

Such as: "just define the ABNF for the scheme-specific part (RFC 3986,
Section 3, hier-part production)"?

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Bjoern Hoehrmann
In reply to this post by masinter
* Larry Masinter wrote:
>Note on IRI working group document 4395bis:
>
>I wonder if we should explicitly disallow documents that define new
>schemes from defining fragment identifier syntax within the
>scheme-specific syntax listed or referred to, in the scheme registration
>template.

I think that is quite explicit already, but a reminder seems to be in
order, I've certainly complained about this in a number of registrations
and encountered a number people, and implementations, that had bizarre
ideas about fragment identifiers being specific to individual schemes.

The general idea would be to say something like URIs are

  <scheme>:<scheme-specific-part>#<fragment>

and schemes can only constrain the first two components. It might be a
good idea to ask people who got this wrong in the past what could be
done to avoid their confusion.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

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

masinter
I think it is in scope to fix the registration guidelines to clarify the registration process, in areas where registrants often make mistakes.

This is one of them.

== proposed add ==
"In general, a URI or an IRI can be thought of as   consisting of
    <scheme>:<scheme-specific-part>#<fragment>.

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.
==end proposed add==




-----Original Message-----
From: Bjoern Hoehrmann [mailto:[hidden email]]
Sent: Wednesday, May 02, 2012 5:01 PM
To: Larry Masinter
Cc: [hidden email]; Magnus Westerlund
Subject: Re: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu

* Larry Masinter wrote:
>Note on IRI working group document 4395bis:
>
>I wonder if we should explicitly disallow documents that define new
>schemes from defining fragment identifier syntax within the
>scheme-specific syntax listed or referred to, in the scheme registration
>template.

I think that is quite explicit already, but a reminder seems to be in
order, I've certainly complained about this in a number of registrations
and encountered a number people, and implementations, that had bizarre
ideas about fragment identifiers being specific to individual schemes.

The general idea would be to say something like URIs are

  <scheme>:<scheme-specific-part>#<fragment>

and schemes can only constrain the first two components. It might be a
good idea to ask people who got this wrong in the past what could be
done to avoid their confusion.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
On 2012-05-05 00:04, Larry Masinter wrote:

> I think it is in scope to fix the registration guidelines to clarify the registration process, in areas where registrants often make mistakes.
>
> This is one of them.
>
> == proposed add ==
> "In general, a URI or an IRI can be thought of as   consisting of
>      <scheme>:<scheme-specific-part>#<fragment>.
>
> 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.
> ==end proposed add==

Sounds good to me.


Reply | Threaded
Open this post in threaded view
|

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

Dave Thaler-2
Julian Reschke wrote:

> On 2012-05-05 00:04, Larry Masinter wrote:
> > I think it is in scope to fix the registration guidelines to clarify the registration
> process, in areas where registrants often make mistakes.
> >
> > This is one of them.
> >
> > == proposed add ==
> > "In general, a URI or an IRI can be thought of as   consisting of
> >      <scheme>:<scheme-specific-part>#<fragment>.
> >
> > 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.
> > ==end proposed add==
>
> Sounds good to me.

That looks good to me too.

-Dave


Reply | Threaded
Open this post in threaded view
|

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

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

On Tue, May 8, 2012 at 3:15 AM, Julian Reschke <[hidden email]> 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