Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes

"Ali C. Begen (abegen)" <abegen@cisco.com> Sun, 30 December 2012 00:45 UTC

Return-Path: <abegen@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DE921F86A5 for <mmusic@ietfa.amsl.com>; Sat, 29 Dec 2012 16:45:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.363
X-Spam-Level:
X-Spam-Status: No, score=-9.363 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyW0ykzPluyU for <mmusic@ietfa.amsl.com>; Sat, 29 Dec 2012 16:45:15 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1196321F8610 for <mmusic@ietf.org>; Sat, 29 Dec 2012 16:45:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11082; q=dns/txt; s=iport; t=1356828315; x=1358037915; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=twpNCIIkp8fxYJ1L7as60P/WcTFbCIT2TrVCMGG8uEE=; b=fZahgKyC8sSkC99IU4HO+Q1CjBsy7tJLPuDDV2rNLV/5XkL9UMqHbWli S2kI763d8mFoa/piUqqfvtJo7mgnu/w0PootM/NMfa7APs+l61i/7Uz+q ZZImsVlhB2GEZNzwKQWuVxkLhjYhQWEYxSU0V0rlpt43cS3DsjVD6LFtH E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAJON31CtJXHB/2dsb2JhbAA6Cg6CXoNOtjJ0FnOCHgEBAQMBAQEBMTQGFwYBCA4DAwEBAQEEBh0FBCULFAkIAgQBEgiIBQYBC4snmm0GkFQEgRyLOwIPBYMUOGEDplSCNj6BaT0
X-IronPort-AV: E=Sophos;i="4.84,379,1355097600"; d="scan'208";a="157180964"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 30 Dec 2012 00:45:14 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBU0jEMQ008311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 30 Dec 2012 00:45:14 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Sat, 29 Dec 2012 18:45:13 -0600
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
Thread-Index: AQHN5ibtjKlj+bwH1kq6U0T1+4e24g==
Date: Sun, 30 Dec 2012 00:45:13 +0000
Message-ID: <C15918F2FCDA0243A7C919DA7C4BE9940CDE1948@xmb-aln-x01.cisco.com>
In-Reply-To: <50DF8C9A.5040603@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.5.121010
x-originating-ip: [10.86.245.254]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <87080664EB3F7A4F86FAC96A7020BD37@cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Dec 2012 00:45:16 -0000


-----Original Message-----
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Date: Saturday, December 29, 2012 7:36 PM
To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05:
session-level	attributes

>On 12/29/12 6:03 PM, Ali C. Begen (abegen) wrote:
>> I don¹t remember us reaching a consensus regarding the text proposed by
>> Brett. One thing certain is that we don't wanna break anything that
>> complies with 4566 but we should also make the text as clear as
>>possible.
>>
>> I am OK with Brett's suggestion as I don't recall an attribute like what
>> Paul might have seen. But, even if such an attribute exists, the current
>> text would be incorrect, too (This would indicate a problem with that
>> particular attribute not 4566 or 4566bis).
>
>I found one: a=maxprate in RFC3890.

Well, I still don't see a problem in replacing the current text with the
proposed text. Do you?

>
>	Thanks,
>	Paul
>
>> Brett's proposal does not make the text any worse. So, I am planning to
>> incorporate this change.
>>
>> Any objections?
>>
>> -acbegen
>>
>> -----Original Message-----
>> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
>> Date: Monday, August 27, 2012 12:03 PM
>> To: "mmusic@ietf.org" <mmusic@ietf.org>
>> Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05:
>> session-level attributes
>>
>>  >I've always thought this should be the way things work, for all
>>  >attributes. But somewhere I came across an attribute (sorry, don't
>>  >remember which one) where the attribute at session level means
>>something
>>  >different than the attribute at media level, and so can't be treated
>>as
>>  >a default for media level. (E.g. the session level is an aggregate
>>limit
>>  >for something, while the media level is a limit for a single m-line.)
>>  >
>>  >Am I just dreaming this? Or can someone identify specific attributes
>>  >that behave this way?
>>  >
>>  >If there are existing attributes that behave this way, then we can't
>>  >make a blanket statement like this. There will need to be an escape
>>  >hatch. For example:
>>  >
>>  >"The connection ("c=") information in the
>>  > session-level section applies to all the media of that session unless
>>  > overridden by connection information
>>  > in the media description. For instance, in the example
>>  > below, TBD..."
>>  >
>>  >"The attribute ("a=") information in the
>>  > session-level section applies to all the media of that session unless
>>  > overridden by connection information or an attribute of the same name
>>  > or choice in the media description, or the specification of that
>>  > attribute calls for a different treatment.
>>  > For instance, in the example
>>  > below, each media behaves as if it were given a "recvonly" attribute.
>>  > If the example had additionally contained a "sendrecv" media-level
>>  > attribute for audio, only the video media would behave as if it were
>>  > given a "recvonly" attribute."
>>  >
>>  >Even this could have some backward compatibility consequences. I think
>>  >there are some attributes that are only defined for media level. This
>>  >revision would mean that a session level value could override a
>>default
>>  >for media level. Implementations that aren't prepared for that might
>>  >break.
>>  >
>>  > Thanks,
>>  > Paul
>>  >
>>  >On 8/27/12 12:04 PM, Ali C. Begen (abegen) wrote:
>>  >> Brett suggested the following change in the SDP draft. Any
>>objections?
>>  >>
>>  >> -acbegen
>>  >>
>>  >> Current text:
>>  >>
>>  >> "The connection ("c=") and attribute ("a=") information in the
>>  >> session-level section applies to all the media of that session
>>unless
>>  >> overridden by connection information or an attribute of the same
>>name
>>  >> in the media description. For instance, in the example below, each
>>  >> media behaves as if it were given a "recvonly" attribute."
>>  >>
>>  >> Proposed text:
>>  >>
>>  >> "The connection ("c=") and attribute ("a=") information in the
>>  >> session-level section applies to all the media of that session
>>unless
>>  >> overridden by connection information or an attribute of the same
>>name
>>  >> or choice in the media description. For instance, in the example
>>  >> below, each media behaves as if it were given a "recvonly"
>>attribute.
>>  >> If the example had additionally contained a "sendrecv" media-level
>>  >> attribute for audio, only the video media would behave as if it were
>>  >> given a "recvonly" attribute."
>>  >>
>>  >>> -----Original Message-----
>>  >>> From: Brett Tate [mailto:brett@broadsoft.com]
>>  >>> Sent: Wednesday, August 08, 2012 7:54 AM
>>  >>> To: Ali C. Begen (abegen); mmusic@ietf.org
>>  >>> Subject: RE: Draft-ietf-mmusic-rfc4566bis-05: session-level
>>attributes
>>  >>>
>>  >>>>> Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the
>>  >>>>> following.
>>  >>>>>
>>  >>>>> "In general, session-level values are the default for all
>>  >>>>> media unless overridden by an equivalent media-level value."
>>  >>>>>
>>  >>>>> "The connection ("c=") and attribute ("a=") information
>>  >>>>> in the session-level section applies to all the media of
>>  >>>>> that session unless overridden by connection information
>>  >>>>> or an attribute of the same name in the media description.
>>  >>>>> For instance, in the example below, each media behaves
>>  >>>>> as if it were given a "recvonly" attribute."
>>  >>>>>
>>  >>>>> If the attributes are related but with different names
>>  >>>>> (such as "inactive" and "sendrecv"), does the attribute
>>  >>>>> at the media-level have precedence over the value at the
>>  >>>>> session-level? If so, I recommend that the draft be
>>  >>>>> updated to clarify the topic.
>>  >>>>
>>  >>>> I believe so. at least that is my understanding from the
>>  >>>> text. Does it really need clarification? Thoughts?
>>  >>>
>>  >>> I think that it should be clarified because it is unclear if "an
>>  >>>attribute of the same name" indicates the typical situation or only
>>  >>> situation concerning application of "unless overridden by an
>>  >>>equivalent media-level value". For instance if I sent "a=inactive"
>>  >>> at session-level and "a=sendrecv" at media-level, I'd be concerned
>>  >>>that the receiver may interpret the SDP as being
>>  >>> abnormal (such as including both values at media-level) instead of
>>  >>>allowing "a=sendrecv" to override "a=inactive".
>>  >>>
>>  >>> In case it matters from an extendibility perspective, requiring the
>>  >>>same name might make it easier to recognize the override.
>>  >>> However since section 6 already introduces complications with
>>  >>>defaulting to "sendrecv" if a new option is defined/used and
>>  >>> unknown, allowing the override even when the names are not the same
>>  >>>doesn't make things too much worse; it actually
>>  >>> allows communication of a backup attribute (such as "a=inactive")
>>if
>>  >>>they don't understand the preferred new attribute (such
>>  >>> as "a=foo").
>>  >>>
>>  >>> "If none of the attributes "sendonly", "recvonly", "inactive",
>>  >>> and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
>>  >>> default for sessions that are not of the conference type
>>  >>> "broadcast" or "H332" (see below)."
>>  >>>
>>  >>> Thanks for the response,
>>  >>> Brett
>>  >>
>>  >> _______________________________________________
>>  >> mmusic mailing list
>>  >> mmusic@ietf.org
>>  >> https://www.ietf.org/mailman/listinfo/mmusic
>>  >>
>>  >
>>  >_______________________________________________
>>  >mmusic mailing list
>>  >mmusic@ietf.org
>>  >https://www.ietf.org/mailman/listinfo/mmusic
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org
>https://www.ietf.org/mailman/listinfo/mmusic