Re: [MMUSIC] 4566bis outstanding issues

"Ali C. Begen (abegen)" <abegen@cisco.com> Mon, 07 July 2014 16:16 UTC

Return-Path: <abegen@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753CF1A0365 for <mmusic@ietfa.amsl.com>; Mon, 7 Jul 2014 09:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQsy4PFJk4YY for <mmusic@ietfa.amsl.com>; Mon, 7 Jul 2014 09:16:10 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C60F11A035A for <mmusic@ietf.org>; Mon, 7 Jul 2014 09:16:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4471; q=dns/txt; s=iport; t=1404749769; x=1405959369; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4auIsdHxuAwyHpRTX5+nJJbsRlnQrs/dcFtsoCpURK0=; b=GVMHs6w1bvfugQbnGI+FyvvkhhjHxRHYt8n95beAj9JemwFzy2KK9JLS pUIm15dMsn4xSA14HXghbsHhE+vr1clkxn2YyqD4eARWpAtg1p7kPP9aK JhQkrnFE38Ktl/3GgBGw6IXQef0gEo0TeS/XQc/QjiQNBr9b1AeMXQyHG 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEFAFTHulOtJA2F/2dsb2JhbABaDoJcJIEsxjsBgRcWdYQDAQEBAwF5BQsCAQgOCi4yJQEBBA4FiDoIAcoSF45OITMHgy2BFgWKF5BflAyDAUKCMA
X-IronPort-AV: E=Sophos;i="5.01,618,1400025600"; d="scan'208";a="338254562"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP; 07 Jul 2014 16:16:09 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s67GG9cg030819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 16:16:09 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 11:16:09 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] 4566bis outstanding issues
Thread-Index: Ac+By1gnkWozapFRScuYYj7YauRbWgASkPUAAUom8IAEqYhwgAAMaTqAAASrOQA=
Date: Mon, 7 Jul 2014 16:16:08 +0000
Message-ID: <EE893C03-926F-427C-B4ED-61EF7601130B@cisco.com>
References: <C15918F2FCDA0243A7C919DA7C4BE9940ECF6C11@xmb-aln-x01.cisco.com> <539263E2.8010802@alum.mit.edu> <281DBAD0-3E23-4F2C-ABD0-6F8D5CB47629@cisco.com> <E851980F-648E-41E1-A200-64BF720D91F5@cisco.com> <53BAA873.6050907@alum.mit.edu>
In-Reply-To: <53BAA873.6050907@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.247.95]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7CAD44A4CE59844CB84FEA3C70299BBF@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/BDZzYebAbx2ob2JZDf2XoiyDYtc
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] 4566bis outstanding issues
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 07 Jul 2014 16:16:12 -0000

On Jul 7, 2014, at 11:02 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 7/7/14 4:07 AM, Ali C. Begen (abegen) wrote:
>> Hi Paul,
>> 
>> OK, no one else seems to be paying attention to this. I have some comments inline and lets see whether we can reach an agreement:
> 
> OK.
> 
> I've trimmed to a few points to comment on...
> 
>>>> On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote:
> 
>>>>> 1) 4566bis needs to provide ABNF syntax for all of the attributes 4566 defined.
>>>>> Comments: This was discussed again in a side meeting in London and there was not a consensus whether we actually needed this.
>>>> 
>>>> IIRC the argument against doing this is that we might get it wrong.
>>>> 
>>>> But IMO we should do it because if we can't get it right how can we expect readers to get it right?
>> 
>> I personally don't wanna take on this task. It is a tedious task and I am not such an ABNF lover to get these definitions right. If you wanna volunteer, by all means, please do so.
> 
> I'm willing to contribute to this, but won't have time until after the Toronto meeting.

That is fine.

> Also, I'm not intimately familiar with all of the attributes.

Nobody is I am afraid.

> 
> I think I could probably produce a credible proposal for an ABNF description all of the attributes currently defined within 4566. This would then need to be carefully reviewed.

Thanks for volunteering.

> 
>> Also, dozens of attributes have been defined since 4566 w/o issues so I am not seeing this as a high priority issue (or an issue at all).
> 
> Like many things, the ones defined more recently tend to be more rigorous than those defined longer ago. But it is uneven, and tends to depend upon who does it and (lately) who from the SDP directorate reviewed it.
> 
>>>> There is an ongoing problem when SDP extensions are defined - lack of a consistent format for defining new attributes. Many people look to 4566 for examples of how to do this, but it provides bad examples.
>>>> 
>>>> IMO 4566bis should show the definition of all attributes in a style that complies with a recommended format for defining attributes.
>>>> 
>>>> (Of course that implies that we could agree on such a format.)
>> 
>> OK, this goes back to the issue #1. Personally, I suggest we do not define the abnfs for every sdp attribute in 4566, but then you have a good point. We can seek a format and provide a few good examples to show prospective authors.
>> 
>> To do this, obviously as you said, we need to agree on that format. Has there been a proposal in the past or does anyone have a good proposal to start with?
> 
> Not a formal one. There has been some discussion about this during review of individual attribute definitions. My take has been that there is not agreement.

If you can recall, can you point us to that proposal and maybe briefly explain the disagreements as well?

> 
> One question is whether the definition of a new attribute should:
> 1) define the full syntax of the line (starting with "a="),
> 2) should provide additional definitions of <attribute> (via "/=")
> 3) should provide additional definitions of <att-field> and <att-value>
>   (via "/=")
> 4) provide definitions of the name and value that are consistent with
>   <att-field> and <att-value> without formally extending the
>   definitions of those.
> 
> Note that 4566 loosely follows (4) but gives the definitions informally rather than via ABNF. So it gives no guidance on how to use ABNF for this. A number of drafts have chosen to follow (2). Some have started to do (1) but I don't know of any that ended up that way.
> 
> A question I have raised is: if (2) or (3) is followed, does that mean that the draft doing so must be considered as "updating" 4566?

I dont see why it should. Personally most of the attributes I defined followed (4). That seemed the easiest option. 

> 
> One thing that people sometimes forget when defining new attributes is that the syntax of the new attribute MUST also be valid when parsed by the "generic" attribute syntax. AFAIK there is no way in ABNF to specify that. I think that (4) comes closest.

Yes, but this must be checked during the last call by actual humans not some abnf parser. 

-acbegen

> 
> 	Thanks,
> 	Paul
>