Re: [sipcore] draft-barnes-sipcore-rfc4244bis

Paul Kyzivat <pkyzivat@cisco.com> Thu, 09 July 2009 22:30 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4128328C287 for <sipcore@core3.amsl.com>; Thu, 9 Jul 2009 15:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.586
X-Spam-Level:
X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 H7Fk+KN1o1jD for <sipcore@core3.amsl.com>; Thu, 9 Jul 2009 15:30:43 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0C6B828C27D for <sipcore@ietf.org>; Thu, 9 Jul 2009 15:30:43 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,375,1243814400"; d="scan'208";a="211879756"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2009 22:31:11 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n69MVBJ4016378; Thu, 9 Jul 2009 15:31:11 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n69MVAJg006160; Thu, 9 Jul 2009 22:31:11 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jul 2009 18:31:10 -0400
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jul 2009 18:31:10 -0400
Message-ID: <4A566FAE.4030901@cisco.com>
Date: Thu, 09 Jul 2009 18:31:10 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Francois Audet <audet@nortel.com>
References: <1246556981.10099.65.camel@victoria-pingtel-com.us.nortel.com> <4A4CFEF1.1000006@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EE8ABC1@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EE8ABC1@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Jul 2009 22:31:10.0359 (UTC) FILETIME=[F56D1270:01CA00E4]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4976; t=1247178671; x=1248042671; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20[sipcore]=20draft-barnes-sipcore-rfc424 4bis |Sender:=20; bh=hMvZoyBIFQPYeaYnxCjyEM4bNx8aDt5y8+2u9idL6jk=; b=Gm8UqyHTUlSGPkvR4+cJgLztlvZ+CPGztrGJDYuL+PThTlFq0GSw8DIb5n IW0XVbgjMBnJmGr8hnl6kyv9PqehqryI12Trr/4pgosPt5KMG+kyUTGyJCpn yRGRL2H/3z;
Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
Cc: SIPCORE <sipcore@ietf.org>, Dale Worley <dworley@nortel.com>
Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2009 22:30:44 -0000

Francois Audet wrote:
> Dale, Paul,
> 
> Good catch.
> 
> The intent was not to impose an ordering requirement: the intent was
> to impose that the hi-index parameter be present.
> 
> Paul: in RFC4244 there was NO ordering requirement.

Yeah. Dale pointed that out. I just assumed it had been carried over.

> What we are trying to achieve with the ABNF is:
> 
> - No ordering requirement
> - There MUST be exactly ONE hi-index
> - There MUST be 0 or 1 hi-target parameter
> - There MUST be 0 or 1 hi-aor parameter
> - There MAY be any number of hi-extension

Its already a restriction that parameters (in general) may appear only 
once. It gets asked about from time to time. I forget where it says that.

So you might not even need to say it. Certainly most of the other header 
parameter syntaxes don't say it but clearly intend it.

But it probably would be helpful to put it in the text.

> I now see the current ABNF fails miserably to do this...
> But I don't think it's trivial to express in ABNF.

As I started to show, it is technically possible. But as Dale responded, 
and I generally agree, it does make the abnf complex. Also, once you 
introduce generic-param all bets are off, since syntactically you can 
match one occurrence against the explicit name and another occurrence 
against generic-param.

> So I think then that Dale's semantic is better, and we
> just need to clearly state that index must be present, and
> that there can be only 0 or 1 of each of hi-target and hi-aor.

I agree.

	Paul

>> -----Original Message-----
>> From: sipcore-bounces@ietf.org 
>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat
>> Sent: Thursday, July 02, 2009 11:40
>> To: Worley, Dale (BL60:9D30)
>> Cc: SIPCORE
>> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis
>>
>> Dale,
>>
>> I agree with your concern about the BNF. A requirement about 
>> the ordering of the params is problematic.
>>
>> OTOH, this is a revision to an existing RFC which had that 
>> ordering requirement. Its possible that relaxing it might 
>> lead to interop problems.
>>
>> Perhaps the best one can do is put in a recommendation to 
>> make the index first.
>>
>> Regarding indicating that the index is required: it can be 
>> done in text, but it can also be done in the BNF, as follows:
>>
>>     History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
>>
>>     hi-entry = hi-targeted-to-uri hi-param-list
>>
>>     hi-targeted-to-uri = name-addr
>>
>>     hi-param-list = *(SEMI hi-option) SEMI hi-index *(hi-option)
>>
>>     hi-option = hi-target / hi-aor / hi-extension
>>
>>     hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT)
>>
>>     hi-target = "rc" / "cc" / "mp" / "rt"
>>
>>     hi-aor = "aor"
>>
>>     hi-extension = generic-param
>>
>>
>> 	Thanks,
>> 	Paul
>>
>>
>> Dale Worley wrote:
>>> Regarding the BNF for the History-Info header (section 4.1 in the 
>>> draft version of -02):
>>>
>>> The current BNF requires that the "index" parameter appear 
>> immediately 
>>> after the URI, whereas other parameters appear after it:
>>>
>>>    History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
>>>
>>>    hi-entry = hi-targeted-to-uri SEMI hi-index *(SEMI hi-param)
>>>
>>>    hi-targeted-to-uri = name-addr
>>>
>>>    hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT)
>>>
>>>    hi-param = hi-target/hi-aor/hi-extension
>>>
>>>    hi-target = "rc" / "cc" / "mp" / "rt"
>>>
>>>    hi-aor = "aor"
>>>
>>>    hi-extension = generic-param
>>>
>>> IMHO, this is not a good way to organize the grammar, as it 
>> makes it 
>>> difficult to generate hi-entry's with generic code (there 
>> needs to be 
>>> some way to constrain the "index" parameter to be first), 
>> and violates 
>>> the general rule that the order of parameters is not significant.
>>>
>>> I propose to adjust the BNF to:
>>>
>>>    History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
>>>
>>>    hi-entry = hi-targeted-to-uri *(SEMI hi-param)
>>>
>>>    hi-targeted-to-uri = name-addr
>>>
>>>    hi-param = hi-index / hi-target / hi-aor / hi-extension
>>>
>>>    hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT)
>>>
>>>    hi-target = "rc" / "cc" / "mp" / "rt"
>>>
>>>    hi-aor = "aor"
>>>
>>>    hi-extension = generic-param
>>>
>>> Of course, the "index" parameter is still mandatory per the 
>> semantic 
>>> constraints listed earlier in section 4.1.
>>>
>>> I've also inserted into the hi-index BNF some spaces around the 
>>> instances of "/" for better readability.
>>>
>>> Dale
>>>
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>