Re: [MMUSIC] Question about 3388bis-04
"Jean-Francois Mule" <jf.mule@cablelabs.com> Fri, 20 November 2009 14:38 UTC
Return-Path: <jf.mule@cablelabs.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50A6628C164 for <mmusic@core3.amsl.com>; Fri, 20 Nov 2009 06:38:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.463
X-Spam-Level:
X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTlbeQR5-1MQ for <mmusic@core3.amsl.com>; Fri, 20 Nov 2009 06:38:45 -0800 (PST)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 812833A69D1 for <mmusic@ietf.org>; Fri, 20 Nov 2009 06:38:45 -0800 (PST)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id nAKEcUiI018001; Fri, 20 Nov 2009 07:38:30 -0700
Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 20 Nov 2009 07:38:30 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 20 Nov 2009 07:38:28 -0700
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C602645926@srvxchg3.cablelabs.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540AA68228@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MMUSIC] Question about 3388bis-04
Thread-Index: Acpj9f7fhjhxFCzBQ+qt0MDhRQromAF9+ZIw
References: <04CAD96D4C5A3D48B1919248A8FE0D540AA68228@xmb-sjc-215.amer.cisco.com>
From: Jean-Francois Mule <jf.mule@cablelabs.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, Gonzalo.Camarillo@ericsson.com
X-Approved: ondar
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Question about 3388bis-04
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 20 Nov 2009 14:38:46 -0000
Ali asked: > The new version has a "SHOULD" language saying that: > > In Section 12: > > o Token to be used within the group attribute. This token may > be of > any length, but SHOULD be no more than four characters long. > > Any particular reason why this was added? I screened the IESG comments recently received on the draft since I recalled some comments that led to the reference of RFC 5234 and 4566 for the definition of token in aBNF. I did not find any justifications though for recommending the token length be no more than 4 chars. One reason might be to limit the variable type to optimize the implementations but that seems far reaching given the SDP parsers I know. Jean-Francois.
- [MMUSIC] Question about 3388bis-04 Ali C. Begen (abegen)
- Re: [MMUSIC] Question about 3388bis-04 Jean-Francois Mule
- Re: [MMUSIC] Question about 3388bis-04 Gonzalo Camarillo