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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 01 Dec 2006 16:09:46 +0100

Hi Jean-Francois,

Thanks for the review.

Jean-Francois Mule skrev:
> 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? 

So you want an extended blurb about what PSS and MBMS is? We can do 
that, even if it isn't how I really would like to spend my time. We will 
do a shot at doing something at least in regards to MBMS which is very 
thin here.

> Is it possible to provide more formal grammar definitions (even
> informative ones) for the attributes?

I don't think this would be a good idea. There is one and only one 
definition of these attributes. And that is in the 3GPP specs. Having 
something that looks like a real definition in this document will only 
result in people not going to the 3GPP specs. Which in my opinion is a 
bad thing.

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

So you want the 3-5 sentence explanation to the words. Yet again it is 
of course something that can be done. However will it really help. I 
think most of the terms are will known in IETF. I guess it is primarily 
PSS, MBMS, 3GP, QoE that may need some more explanation. And I think 
that can rather be provided when the term is used or in the introduction.

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

Yes, this is a good idea. We will add this section. In general I would 
say that the applicability is limited to the exact same scenarios as 
they are used in 3GPP. For example the a=framesize attribute as all the 
other is not defined for offer/answer usage. Which is probably something 
that needs to be clear up front.

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

Okay, we can look at these examples you provide. However as I stated 
before. It is extremely important from my perspective that it is 
impossible to implement these attributes from this document rather then 
the technical specification.

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

I am a more than a little confused by these two comments. If you refer 
to our internet draft, then I don't see them being applicable. This 
draft is not the definition of these attributes. That is done in the 
3GPP specifications. If it is in relation to the 3GPP specification you 
are 2-3 years at least to late. We can't change the names of these 
attributes today. In fact the feedback I received from other non-IETF 
forums is that they are annoyed that we included 3GPP in some of them. 
Because they wan't to borrow them, but are the reluctant based on the 
name. I do agree that some of these attributes would be have been better 
to specify in IETF and do have general applicability. This happens when 
you don't have the understanding well enough ahead of time to start 
working on the attributes in IETF to be certain enough that work will 
conclude in the time frame you need them. It is unfortunate, but I don't 
see an easy resolution to that issue.

I do think 3GPP can persuaded to move the control of some of these to 
IETF and with a generalized definition and applicability as long as they 
aren't change compared to what 3GPP currently use them for. I will not 
do that but if someone is interested they should start an dialog with SA4.

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

Yes, this is only a warning.

> Shouldn't this be about registering the 'trackID' RTSP URI extension for
> 3GP files?

First of all the RTSP URI is currently not registered. Thus there exist 
no registry to update. Secondly, this is only limitation applicable for 
when the URI path elements point inside an 3GP file. I don't see how 
that can be registered. It is a valid URI with a volunteer restriction.

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

We certainly can add an example. I will look into the terminology. 
However it might in fact be better to remove this than to confuse 
people. The URI usage has no impact on any clients, it only affects 
servers supporting 3GP files.

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

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
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