Subject: RE: [MMUSIC] [Fwd: I-DACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt]

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 24 Oct 2006 17:10:31 -0600

Hi,

   Here are a few comments on
draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt. 

  I've read this ID with fresh eyes, so please disregard some of these
comments/questions if have been discussed and answered before.

--- General comments and questions:

1.1/
Based on a quick read, this I-D seems to be an IETF "doc wrapper" for
SDP and RTSP attributes defined in 3GPP. It gives very minimal
information on the PSS/MBMS services those attributes are used in, and
the reader is forced to fetch the 3gpp specs.
=> questions:
would it be possible to describe the context in which those attributes
were defined in a little bit more details? 
Is it possible to provide more formal grammar definitions (even
informative ones) for the attributes?

1.2/ Terminology section
It would help the readability of the document to have a terminology
section where some of the terms are defined (rather than a bare bone
glossary in section 1)

1.3/ Applicability Statement
Some of the proposed parameters may be applicable beyond 3gpp's use;
this is particularly true attributes like the video frame size
(a=framesize:).
Given that the normative references and change control process live in
3GPP, should there be some kind of applicability statement for all the
attributes declared in this document?
Something like:
x. Applicability Statement
   This document describes private extensions to SDP [] and RTSP [] and
   registers attributes that are normatively defined in 3GPP
   specifications x, y and z.
   The use of these extensions is only applicable inside a 3GPP
   Connectivity Network...

The above seems appropriate given:
	- most of the attributes start with x- or 3GPP (and I understand
the fact that these were defined in release 5 and that rfc 4566
discourages those x- uses)
	- this statement:
"  In the process of defining these services, there has occasionally
   been the need to extend both SDP and RTSP functionality. These
   extensions have mostly been in the form of SDP attributes and RTSP
   headers. The purpose of this informational document is to register
   these SDP and RTSP extensions, in order to avoid future conflicts,
   and also to raise the awareness of their existence within IETF. "

1.4/ attribute definitions:
I don't find it useful to have docs that register attributes but don't
even provide the syntax of the attribute, or even the unit of the
attribute values.

I will take one example of this with the media line attribute
a=X-predecbufsize but this is a general comment:

In section 3.1, the Internet-Draft states:
"The "a=X-predecbufsize" attribute provides the size of the pre-
decoder buffer.", and,
in section 7.1:
   SDP Attribute ("att-field"):

   Attribute name:     X-predecbufsize
   Long form:          Pre-decoder buffer size
   Type of name:       att-field
   Type of attribute:  Media level only
   Subject to charset: No
   Purpose:            See Section 3.1
   Reference:          3GPP TS 26.234, Section 5.3.3.2
   Values:             See Reference".

Yet, 26.224 R5.7.0 states:
- 	"a=X-predecbufsize:<size of the hypothetical pre-decoder
buffer>"
This gives the suggested size of the Annex G hypothetical pre-decoder
buffer in bytes.

And 26.224 R7 states:
- 	"a=X-predecbufsize:<size of the hypothetical pre-decoder
buffer>"
If the field is an attribute for an H.263 or MPEG-4 Visual stream and
rate adaptation (see clause 10.2) is not in use, this gives the
suggested size of the Annex G hypothetical pre-decoder buffer in bytes.
   ==> this seems to imply that when the rate adaptation is in use, this
attribute is not well defined or its values should be interpreted
differently if present?

===> it seems to me that the draft should provide details:
	- explain the attribute's purpose in a more details than just
pointing to Annex G and 3GPP spec sections, 
	- provide syntax for the value (even informative, you do that
for some like 'a=framesize:')
	- indicate units for the values
	- give an example
A good example of what "more details" may mean here is RFC 3455: the
reader can understand how those private SIP headers are defined and get
24.229 to know more.

--- 2. 3gpp-specific or more general RTSP/SDP attributes?

2.1/ naming and declaration of "a=framesize:<payload type number>
<width>-<height>"
We can't call this an attribute definition, it is a declaration at best.
On this one, I wonder the applicability of the attribute:
	- if it is meant for broader applicability that the 2 3GPP
services named in the draft (and I think it should), then this
declaration is not enough;
	- if it is meant for 3gpp only, please name the attribute 3GPP-
In either case, I really think you have to provide more information in
this draft. 

2.2./ same comments as above for alt*

3/ section 6.7 - RTSP URI extension

I'm not sure what this whole section means or what it is intended for.
The first paragraph is purely descriptive and the second is using a
normative verb without pointing to any registration.

Is the intent of this section to warn implementers that some URIs for
3GP files may contain a track number and that to be valid, it should be
the last URI segment? 
Shouldn't this be about registering the 'trackID' RTSP URI extension for
3GP files?
Why not re-use the terminology (track-ID, stream_id_token, stream_id,
etc.) as in the referenced 26.234 section 5.3.3.1?
An example would help, like 
   a=control:rtsp://mediaserver.com/movie.3gp/trackID=1
In short, this seems confusing to me and I'm not sure what to get out of
this text.

Hope this helps. Note that I have only done a partial review of the
document.

Jean-Francois.

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Tuesday, October 24, 2006 7:30 AM
> To: mmusic (E-mail)
> Subject: [MMUSIC] [Fwd: I-DACTION:draft-westerlund-mmusic-3gpp-sdp-
> rtsp-04.txt]
> 
> Hi,
> 
> Me and my co-author has done a bit of review and updates on this
> document. We think it is ready to published. We intend to request AD
> sponsored publication for informational status after the IETF meeting.
> So please review the document, comments are solicited.
> 
> Cheers
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic