Subject: [MMUSIC] RFC 5583 bug, fix in errata?

From: Stephan Wenger <[email-masked]>
Date: Sun, 06 Nov 2011 08:48:13 -0700

Hi,
Section 5.1 in RFC 5583 reads
>    The dependency signaling is only feasible between media descriptions
>    described with an "m="-line and with an assigned media identification
>    attribute ("mid"), as defined in [RFC3388
> <http://tools.ietf.org/html/rfc3388> ].  All media descriptions
>    grouped according to this specification MUST have the same media
>    type.  Other dependencies relations expressed by SDP grouping have to
>    be addressed in other specifications.  A media description MUST NOT
>    be part of more than one group of the grouping type defined in this
>    Specification.
The highlighted sentence ("All media descriptions [Š] MUST have the same
media type." for those using plaintext) imposes a restrictions that runs
contrary to the authors' intention.  Specifically, when writing up the
drafts that led to RFC 5583, we (that's Thomas Schierl and myself) had in
mind the use of an H.264 base layer (media type H264) and SVC enhancement
layer(s) (media type SVC).

Replacing "media type" with "media name" would make, to us, perfect sense.
There is no point in trying to signal a decoding dependency between a, say,
audio base layer and a video enhancement layer.  But the restriction of the
same media type does not make much sense.

So the proposed bug fix is to replace "media type" with "media name".

Can this issue be dealt with using the errata process or do we need an
RFC5583-bis draft?

Stephan

---

From: "Roy Yue(PeiYu)" <[email-masked]>
Date: Mon, 07 Nov 2011 08:01:22 +0000

Hi,

Not familiar with the process of IETF.  However the proposed term “media name” looks too vague to understand.
Another term “top-level media type” defined by RFC2046 can cope with your examples very well. What about using “top-level media type” instead?

Actually, in IANA(e.g. http://www.iana.org/cgi-bin/mediatypes.pl) and some RFCs (e.g. RFC4855), the difference between term “media type” and term “top-level media type” is not distinct.
Sometime “media type” means the top level media type while sometimes it means the whole media type.
So the sentence in RFC 5583 is even correct to some extent. But I agree it is better to update it for better understanding.

Best regard,
Roy(乐培玉)
Huawei Software Technologies Co., Ltd [huawei_logo]

N5, NO. 101, Huawei Base
Ruanjian Av, YuHua Dist
Nanjing, 210012, P.R.C
Tel: +86-25-56622058
Fax: +86-25-56624081
Mobile: +86-13809030401
Email: [email-masked]
http://www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
发件人: [email-masked] [mailto:[email-masked]] 代表 Stephan Wenger
发送时间: 2011年11月6日 23:48
收件人: [email-masked]
主题: [MMUSIC] RFC 5583 bug, fix in errata?

Hi,

   attribute ("mid"), as defined in [RFC3388<http://tools.ietf.org/html/rfc3388>].  All media descriptions

   Specification.

The highlighted sentence ("All media descriptions […] MUST have the same media type." for those using plaintext) imposes a restrictions that runs contrary to the authors' intention.  Specifically, when writing up the drafts that led to RFC 5583, we (that's Thomas Schierl and myself) had in mind the use of an H.264 base layer (media type H264) and SVC enhancement layer(s) (media type SVC).

Replacing "media type" with "media name" would make, to us, perfect sense.  There is no point in trying to signal a decoding dependency between a, say, audio base layer and a video enhancement layer.  But the restriction of the same media type does not make much sense.

Can this issue be dealt with using the errata process or do we need an RFC5583-bis draft?

Stephan

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Nov 2011 15:49:41 +0100

On 2011-11-06 16:48, Stephan Wenger wrote:
> Hi, Section 5.1 in RFC 5583 reads
>> The dependency signaling is only feasible between media
>> descriptions described with an "m="-line and with an assigned media
>> identification attribute ("mid"), as defined in [RFC3388
>> <http://tools.ietf.org/html/rfc3388>].  All media descriptions 
>> type.  Other dependencies relations expressed by SDP grouping have
>> to be addressed in other specifications.  A media description MUST
>> NOT be part of more than one group of the grouping type defined in
>> this Specification.
> 
> The highlighted sentence ("All media descriptions […] MUST have the
> same media type." for those using plaintext) imposes a restrictions
> that runs contrary to the authors' intention.  Specifically, when
> writing up the drafts that led to RFC 5583, we (that's Thomas Schierl
> and myself) had in mind the use of an H.264 base layer (media type
> H264) and SVC enhancement layer(s) (media type SVC).
> 

I think you are overreacting, Media Type is any audio or any video
format. The limiation does not apply on payload type level, like your
example with combing H.264 and SVC would be.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------