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

[Larry 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: uri-review-***@ietf.org on Behalf of Magnus Westerlund
Sent: Thursday, April 26, 2012 8:15 AM
To: uri-***@ietf.org
Cc: mmusic-***@tools.ietf.org
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, ***@ericsson.com

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, ***@ericsson.com

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, ***@ericsson.com

Author/Change controller: IETF

References: RFC 2326
--
Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone [phone]
Färögatan 6 | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: ***@ericsson.com
----------------------------------------------------------------------

[Julian Reschke]

Post by Larry Masinter
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

[Bjoern Hoehrmann]

Post by Larry Masinter
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.

[Larry 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:***@gmx.net]
Sent: Wednesday, May 02, 2012 5:01 PM
To: Larry Masinter
Cc: public-***@w3.org; Magnus Westerlund
Subject: Re: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu

Post by Larry Masinter
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.

[Julian Reschke]

Post by Larry 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==

Sounds good to me.

[Dave Thaler]

Post by Larry Masinter

Post by Larry Masinter
I think it is in scope to fix the registration guidelines to clarify the registration

process, in areas where registrants often make mistakes.

Post by Larry Masinter
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.

Post by Larry Masinter
==end proposed add==

Sounds good to me.

That looks good to me too.

-Dave