Subject: Re: [MMUSIC] SDP 'gpmd' (General Purpose Media Descriptor) attribute

From: Rajesh Kumar <[email-masked]>
Date: Wed, 09 Oct 2002 09:04:54 -0700

Tom,

At 10:45 AM 9/30/2002 -0700, Tom Marshall wrote:
>I question the need for this when the a= line is freefrom and you are free
>to put whatever information in whatever format you like.

That is precisely not the case. The value is not free-form.  The gpmd 
attribute is a list of sub-parameters, whose values need to be crisply 
defined and registered with the IANA.  The text and ABNF provide the 
format, for example:

                 gpmd-value = 1*(gpmd-subparameter)
                 gpmd-subparameter = gpmd-subparameter-name "=" 
gpmd-subparameter-value

                 etc.

Even if implementers use unregistered, experimental sub-parameters with a 
"X-" prefix, these would have to be coherently defined within their private 
domain.

>An application
>that does not understand a particular entry/parameter will be no better off
>because it cannot use the information, and one that already understands the
>current form gains nothing either.

Again,  the information being conveyed is the value of the subparameter. An 
application that understands the 'gpmd' attribute and a particular 
subparameter does not necessarily know what value is assigned by the other 
party. If this value can be changed on a session-by-session basis, then 
there is merit to indicating it via SDP. For instance, the ITU V.150 
standardization group has found it necessary to use this mechanism to 
indicate whether an RTP payload type is associated for a specific 
call/session with voiceband data. The default is that it is not associated 
for that specific call or session even if it might be for other calls and 
sessions.
>
>Of course, you are free to use this convention in your SDP.  Our system also
>has a convention for passing generic key/value pairs with datatype info.

In this context, the emphasis of the ITU V.150 standardization group is to 
publicly define and register the unassociated subparameters and possible 
values that may be optionally used to qualify media formats. (For 
associated parameters you already have the 'fmtp' construct.) We are not 
defining the gpmd mechanism a a means to tunnel secretive free-form strings 
via SDP.

Rajesh

>On Mon, Sep 30, 2002 at 10:21:34AM -0700, Rajesh Kumar wrote:
> > Dear MMUSIC colleagues,
> >
> > A while back, I sent this request for discussion on  the qualification 
> of media
> > formats with generic parameters. There have been no comments on the 
> issue, or
> > on the referenced internet draft. Please do provide me with your 
> feedback.  If
> > approved, this will impact the representation of media formats in SDP.
> >
> > My original email is below...
> >
> > There is a need for an SDP attribute that allows the qualification of media
> > formats with generic parameters. By "generic" we mean that these parameters
> > are not part of the standard  (e.g. MIME) definition of the media 
> format. In
> > general, the media format may be RTP or non-RTP.
> >
> > Please take a look at the internet draft,
> > 
> _h_t_t_p_:_/_/_w_w_w_._i_e_t_f_._o_r_g_/_i_n_t_e_r_n_e_t_-_d_r_a_f_t_s_/_d_r_a_f_t_-_r_a_j_e_s_h_k_u_m_a_r_-_m_m_u_s_i_c_-_g_p_m_d_-_0_0_._t_x_t,
> > which defines such an attribute. It is meant to replace the internet draft
> > 
> _h_t_t_p_:_/_/_w_w_w_._i_e_t_f_._o_r_g_/_i_n_t_e_r_n_e_t_-_d_r_a_f_t_s_/_d_r_a_f_t_-_r_a_j_e_s_h_k_u_m_a_r_-_m_m_u_s_i_c_-_g_f_m_t_p_-_0_4_._t_x_t.
> > We withdrew the other internet draft because we changed the parameter name
> > to gpmd. Although the basics remain unchanged, there older internet draft
> > had inconsistencies which we have corrected based on feedback from Colin
> > Perkins.
> >
> > At the parser level, this attribute is completely optional. However, some
> > applications might require the use of this attribute and one or more 
> generic
> > parameters. The format of this attribute is:
> >
> >
> >      a=gpmd:<format><generic parameter list>
> >
> > For example,
> >
> >
> >     m=audio 3456 RTP/AVP 0 15
> >     a=gpmd:0 vbd=yes
> >
> > and
> >
> >      m=application 3456 udp wb
> >      a=gpmd:wb someParameter=someValue
> >
> > As an example, we have defined the generic parameter 'vbd' (Voiceband data)
> > in the internet draft. Unfortunately, we did not limit ourselves to the
> > semantics of the generic parameter. We specified an implementation. We will
> > be removing all implementation-specific information from the RFC that might
> > come out of this internet draft. Thanks, Colin, for pointing out the need
> > to, in this case, limit the discussion to the semantics of this parameter.
> >
> > Of course, generic parameters that do not being with the experimental 
> prefix
> > "X-" will need to be registered with the IANA. We have stated the need for
> > an IANA registry for this purpose.
> >
> > A predecessor of this internet draft have been reviewed at the London and
> > Minneapolis IETF's. Another predecessor of this internet draft was reviewed
> > on this mailing list and commented on. All comments provided are factored
> > in.
> >
> > Please do provide me with your comments!!  I look forward to a cycle of
> > fruitful discussion on why this attribute should or should not be
> > standardized in the IETF, and if standardized, what changes might be
> > appropriate. On a tangential note, please note that the TIA TR.30.1 MoIP
> > standardization group is actively using this attribute (albeit under its
> > older name, 'gfmtp', something that needs to be fixed).
> >
> > Thanks for your attention, help, and suggestions,
> >
> > Rajesh
> >
> >
>
>--
>Nothing will dispel enthusiasm like a small admission fee.
>         -- Kim Hubbard

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

---

From: Tom Marshall <[email-masked]>
Date: Wed, 9 Oct 2002 11:49:40 -0700

> defined and registered with the IANA.  The text and ABNF provide the 

Sorry, I apparently did not make myself clear.  The a= line is free from in
general.

> defining the gpmd mechanism a a means to tunnel secretive free-form strings 

I applaud the effort to publicize and standardize parameters.  I was only
questioning whether the SDP specification needs modified (vs. using existing
mechanisms).

-- 
Old timer, n.:
        One who remembers when charity was a virtue and not an organization.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Oct 2002 09:06:45 +0200

Hi Rajesh

I would just like to point out that the BNF you specify for gpmd is not 
parsable:
 From your draft:

For the 'gpmd' attribute, a special case of this ABNF syntax may be stated as 
follows: 
 
     gpmd-attribute-field = "a=" gpmd-attribute CRLF 
     gpmd-attribute = "gpmd" ":" gpmd-value 
     gpmd-value = 1*(gpmd-subparameter) 
     gpmd-subparameter = gpmd-subparameter-name "=" gpmd-subparameter-value 
     gpmd-subparameter-name = 1*(alpha-numeric)  
     gpmd-subparameter-value = byte-string 
     alpha-numeric = ALPHA / DIGIT 
                      ; external reference: 
                      ; ALPHA and DIGIT from RFC 2234 [4] 
     byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 
                      ;any byte except NUL, CR or LF 

The problem I see is that you specify gpmd-value as any number of 
gpmd-subparameters. But you don't specify what delimiter shall be used 
between gpmd-subparameters. Also as the gpmd-subparameter-value is a 
byte-string you have no character to use as a delimiter between each 
sub-parameter. So it is impossible to know when the sub-parameter-value 
ends and the next sub-parameter begins.

I propose that you think this over and decide on a single delimiter that 
is excluded from the value or use quoting of the value. The delimiter 
needs to be part of the BNF specification. 

Also in the examples you have made in emails and the draft you have an 
alpha-numeric format parameter like this "gpmd:<format> <parameters>". 
The format parameter is not defined in the BNF. 

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Rajesh Kumar <[email-masked]>
Date: Thu, 10 Oct 2002 10:59:55 -0700

Magnus,
You are right. My intention was to specify a semi-colon delimiter to be in 
sync with what Steve Casner has for the 'fmtp' attribute sub-parameters 
used in conjunction with RTP MIMEs. Through an oversight, I forgot to 
include this in the text and the ABNF of the draft.

A semicolon is already excluded from gpmd-subparameter-name, I will also 
exclude it from gpmd-subparameter-value

I will fix in the next draft this if this sounds OK to the group. Also, 
Steve, I think this is what you're doing for the fmtp in the RTP MIME 
context i.e. you are using a semicolon delimiter and excluding it from the 
values.

Rajesh

At 09:06 AM 10/10/2002 +0200, Magnus Westerlund wrote:
>For the 'gpmd' attribute, a special case of this ABNF syntax may be stated 
>as follows:
>     gpmd-attribute-field = "a=" gpmd-attribute CRLF     gpmd-attribute = 
> "gpmd" ":" gpmd-value     gpmd-value = 
> 1*(gpmd-subparameter)     gpmd-subparameter = gpmd-subparameter-name "=" 
> gpmd-subparameter-value     gpmd-subparameter-name = 1*(alpha-numeric)
>     gpmd-subparameter-value = byte-string     alpha-numeric = ALPHA / 
> DIGIT                      ; external reference:                      ; 
> ALPHA and DIGIT from RFC 2234 [4]     byte-string = 
> 1*(%x01-09/%x0B-0C/%x0E-FF)                      ;any byte except NUL, CR 
> or LF
>
>
>alpha-numeric format parameter like this "gpmd:<format> <parameters>". The 
>format parameter is not defined in the BNF.
>Regards
>
>Magnus Westerlund