Subject: RE: [MMUSIC] Case the <transport> parameter in SDP

From: Thomas Zeng <[email-masked]>
Date: Fri, 6 Sep 2002 10:56:40 -0700

Rajesh:

RFC 2327 and draft-ietf-mmusic-sdp-new-10.txt both use Augmented BNF (ABNF)
for grammar 
definitions. ABNF is case insensitive.

Therefore I belive in "m=" line the "proto" token is case insensitive.

Cheers,
Thomas
PacketVideo Corp.
www.pv.com
[email-masked]
858 731 5465

-----Original Message-----
From: Rajesh Kumar [mailto:[email-masked]]
Sent: Wednesday, September 04, 2002 6:10 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [MMUSIC] Case the <transport> parameter in SDP

It seems that, per the definition in RFC 2327 and
draft-ietf-mmusic-sdp-new-10.txt  the value of the transport parameter in
the 'm' line is case-sensitive. This may also be inferred from the IANA
registry of its 'proto' values which shows the following, in different
cases:

proto           RTP/AVP                      [RFC2327]
                  vat                          [historic]
                  rtp                          [historic]
                  UDPTL                        [ITU-T Rec. T.38 (Section 9)]
                  TCP                          [RFC793]

However, ITU T.38 seems to use this parameter in a case-insensitive manner.
For example,

m=image 49170 udptl t38

So is the case of the <transport> parameter really insignificant? If so,
then this should be called out in draft-ietf-mmusic-sdp-new-10.txt (both in
the words and the ABNF). This draft/RFC 2327  indicate case sensitivity as
the general rule, unless explicitly indicated.

I note that Steve Casner has indicated case-insensitivity in the RTP mime
registrations.

Comments? Guidance?
--------------
Rajesh Kumar
Cisco Systems

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

---

From: "Rajesh Kumar" <[email-masked]>
Date: Fri, 6 Sep 2002 11:05:46 -0700

Thomas:
Does that apply to the values of all SDP fields? I know that the SDP
keywords are case-sensitive. The document says that case considerations for
individual fields need to be explicit for that field, otherwise it is case
sensitive.

Thanks,

Rajesh

 | -----Original Message-----
 | From: [email-masked] [mailto:[email-masked]]On Behalf Of
 | Thomas Zeng
 | Sent: Friday, September 06, 2002 10:57 AM
 | To: [email-masked]'; [email-masked]
 | Cc: [email-masked]; [email-masked]
 | Subject: RE: [MMUSIC] Case the <transport> parameter in SDP
 |
 |
 | Rajesh:
 |
 | RFC 2327 and draft-ietf-mmusic-sdp-new-10.txt both use Augmented
 | BNF (ABNF)
 | for grammar
 | definitions. ABNF is case insensitive.
 |
 | Therefore I belive in "m=" line the "proto" token is case insensitive.
 |
 | Cheers,
 | Thomas
 | PacketVideo Corp.
 | www.pv.com
 | [email-masked]
 | 858 731 5465
 |
 | -----Original Message-----
 | From: Rajesh Kumar [mailto:[email-masked]]
 | Sent: Wednesday, September 04, 2002 6:10 PM
 | To: [email-masked]
 | Cc: [email-masked]; [email-masked]
 | Subject: [MMUSIC] Case the <transport> parameter in SDP
 |
 |
 | It seems that, per the definition in RFC 2327 and
 | draft-ietf-mmusic-sdp-new-10.txt  the value of the transport parameter in
 | the 'm' line is case-sensitive. This may also be inferred from the IANA
 | registry of its 'proto' values which shows the following, in different
 | cases:
 |
 | proto           RTP/AVP                      [RFC2327]
 |                   vat                          [historic]
 |                   rtp                          [historic]
 |                   UDPTL                        [ITU-T Rec. T.38
 | (Section 9)]
 |                   TCP                          [RFC793]
 |
 | However, ITU T.38 seems to use this parameter in a
 | case-insensitive manner.
 | For example,
 |
 | m=image 49170 udptl t38
 |
 | So is the case of the <transport> parameter really insignificant? If so,
 | then this should be called out in
 | draft-ietf-mmusic-sdp-new-10.txt (both in
 | the words and the ABNF). This draft/RFC 2327  indicate case
 | sensitivity as
 | the general rule, unless explicitly indicated.
 |
 | I note that Steve Casner has indicated case-insensitivity in the RTP mime
 | registrations.
 |
 | Comments? Guidance?
 | --------------
 | Rajesh Kumar
 | Cisco Systems
 |
 | _______________________________________________
 | mmusic mailing list
 | [email-masked]
 | https://www1.ietf.org/mailman/listinfo/mmusic
 | _______________________________________________
 | mmusic mailing list
 | [email-masked]
 | https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Rajesh Kumar" <[email-masked]>
Date: Wed, 25 Sep 2002 18:30:58 -0700

Dear MMUSIC colleagues,

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,
http://www.ietf.org/internet-drafts/draft-rajeshkumar-mmusic-gpmd-00.txt,
which defines such an attribute. It is meant to replace the internet draft
http://www.ietf.org/internet-drafts/draft-rajeshkumar-mmusic-gfmtp-04.txt.
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