Re: [sipcore] draft-ietf-sipcore-location-conveyance-04

Paul Kyzivat <pkyzivat@cisco.com> Wed, 27 October 2010 12:51 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 9859D3A69D4 for <sipcore@core3.amsl.com>; Wed, 27 Oct 2010 05:51:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.485
X-Spam-Level:
X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 bM1WAfSvnQSV for <sipcore@core3.amsl.com>; Wed, 27 Oct 2010 05:51:53 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 903273A694A for <sipcore@ietf.org>; Wed, 27 Oct 2010 05:51:53 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.58,246,1286150400"; d="scan'208";a="175534889"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 27 Oct 2010 12:53:43 +0000
Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9RCrgPC020262; Wed, 27 Oct 2010 12:53:43 GMT
Message-ID: <4CC820D6.3090207@cisco.com>
Date: Wed, 27 Oct 2010 08:53:42 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "Thomson, Martin" <Martin.Thomson@andrew.com>
References: <20101025195020.1DA5A3A68E5@core3.amsl.com> <4CC78202.6090700@cisco.com> <8B0A9FCBB9832F43971E38010638454F03F31EB0D7@SISPE7MB1.commscope.com>
In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F31EB0D7@SISPE7MB1.commscope.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04
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: Wed, 27 Oct 2010 12:51:54 -0000

I was going to suggest alternative ABNF in my prior posting, but I ran 
out of time and wanted to send it. So here is a proposal:

    Geolocation-header = "Geolocation" HCOLON Geolocation-value
			*( COMMA Geolocation-value)
    Geolocation-value  = locationValue / routing-param
    locationValue      =  LAQUOT locationURI RAQUOT
                           *(SEMI geoloc-param)
    locationURI        =  sip-URI / sips-URI / pres-URI
                           / http-URI / HTTPS-URI
                           / cid-url ; (from RFC 2392)
                           / absoluteURI ; (from RFC 3261)
    geoloc-param       =  generic-param;  (from RFC 3261)
    routing-param      =  "routing-allowed" EQUAL "yes" / "no"

This syntax is consistent with 3261 section 7.3:

    Specifically, any SIP header whose grammar is of the form

       header  =  "header-name" HCOLON header-value *(COMMA header-value)

    allows for combining header fields of the same name into a comma-
    separated list.

(That means there is an equivalence between multiple occurrences of the 
header, and a single header with multiple fields.)

(I would prefer to have a separately named header for the routing-param, 
but I think we are too far down the river to make that change now.)

The above is overly forgiving, in that it permits zero or more 
locationURIs and zero or more routing-params. That then needs to be 
tightened up with text. I think the text needs to say, more or less:

- if there are any locationURIs in a sip request,
   then a routing-param MUST be present in the request
- there MUST NOT be more than one routing-param present in a
   sip request.
- there MUST NOT be more than two locationURIs in a sip request
   (if there is really a reason for such a restriction)

Actually the MUST requirement on the routing-param also seems 
unmotivated to me. Why not just a default of routing-allowed=no?

	Thanks,
	Paul

On 10/27/2010 12:06 AM, Thomson, Martin wrote:
> On 2010-10-27 at 12:36:02, Paul Kyzivat wrote:
>> I have never understood why the routing-param is required to be last.
>> And as my examples show, its difficult/impossible to enforce this in
>> ABNF.	
>
> If "routing-allowed" is mandatory, it IS possible:
>
>      Geolocation-header = "Geolocation" HCOLON Geolocation-value
>      Geolocation-value  = [ locationValue [ COMMA locationValue ] COMMA ]
>                           routing-param
>
> It's a little strange, but it does work.  Especially if you also add text that states there can be only one GeoLocation header?
>
> (The other thing that I find strange is the fact that there can be zero, one or two locationValue parts.  This is confusing for computer scientists who can only count: zero, one, many.)
>
> --Martin