Re: [sipcore] Location Conveyance -04 submitted, here's the changes

"Peterson, Jon" <jon.peterson@neustar.biz> Thu, 28 October 2010 17:16 UTC

Return-Path: <jon.peterson@neustar.biz>
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 129133A6855 for <sipcore@core3.amsl.com>; Thu, 28 Oct 2010 10:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.198
X-Spam-Level:
X-Spam-Status: No, score=-102.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JjLffKwevg01 for <sipcore@core3.amsl.com>; Thu, 28 Oct 2010 10:15:52 -0700 (PDT)
Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by core3.amsl.com (Postfix) with ESMTP id 4B0BC3A677C for <sipcore@ietf.org>; Thu, 28 Oct 2010 10:15:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1288286178; x=1603633418; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=izV8G32GseALs1d9bqeRyPulTP+twzSX9hTsnOgyBG4=; b=dadxQr30YAF8zLc4oDW8DSOzf3ri/eg0RQ7/gFI2b1LeAPM9yKaA2tRyRjKcvb hO2QK/8MXySGKhtkIGWfdUEQ==
Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.31451583; Thu, 28 Oct 2010 13:16:16 -0400
Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 28 Oct 2010 13:16:15 -0400
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>, "Richard L. Barnes" <rbarnes@bbn.com>, "James M. Polk" <jmpolk@cisco.com>
Date: Thu, 28 Oct 2010 13:16:12 -0400
Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes
Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAAmpfmM=
Message-ID: <C8EEFDEC.4757B%jon.peterson@neustar.biz>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE219707BC9@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA==
x-ems-stamp: pX0zfVa8X8WX7CW/ysWJ5w==
Content-Type: multipart/alternative; boundary="_000_C8EEFDEC4757Bjonpetersonneustarbiz_"
MIME-Version: 1.0
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes
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, 28 Oct 2010 17:16:03 -0000

Reducing this issue to a process argument trivializes (as usual) any technical question about what location means in a SIP request. At the last working group meeting, I very reluctantly conceded to the (somewhat weak in my opinion) backwards-compatibility argument for allowing more than one Geolocation header field value. To be clear, the previous version of the draft never took away the ability to have multiple locations in a request - you could always put in multiple PIDF-LO MIME bodies with different or similar locations in the last version of the draft (and yes, with Content-Indirection or whatever if you wanted it by reference). You could also put multiple locations in the same PIDF-LO body, as both the presence data model and the relevant GEOPRIV RFCs recommend even. The contention that the previous version "reduced to one" the number of locations that a SIP request could carry is simply false.

The real issue is what semantic role we expect the Geolocation header to play when it points to more than one PIDF-LO body. While I think plenty of people have the intuition that this should be meaningful, I haven't heard a lot of people step up to explain what it should mean exactly. If you want to stuff ten locations into multipart MIME bodies of a SIP request, this document does not prevent you from doing so. As I've said before, it's kind of like stuffing ten SDP bodies into a SIP request, which RFC3261 also allows. You may mean something by those ten SDP bodies, but I have no idea what it is, and neither will anyone else who receives your request. The only argument (aside from rough-loc) I've heard for multiple locations is that there may be some application-specific agreement about their meaning. That's fine, but that sort of statement simply has no place in standards, as it is completely anathema to interoperability. If we seriously tried to design SIP in such a way that we relied on application-specific behavior to handle ten SDP bodies in one request with no further guidance to the implementers, we'd never set up a single call.

The high-level argument of the previous version of the draft was that when there were multiple PIDF-LO bodies associated with a SIP request, the job of the Geolocation header would be to designate one of them as the one the recipient was supposed to act on as if it were coupled to the sender of the request. If it indicated a PIDF-LO body with multiple locations within it, presumably the consuming application would be able to tell from the data model markup which location it should consume. I do understand the argument from rough-loc, or the backwards-compatibility argument that some applications today simply bandy these Geolocation values around in an application-specific manner. I didn't, however, walk away from either discussion with the impression that we ever needed the Geolocation header to indicate more than two PIDF-LO bodies for any of the use cases in question.

This draft is so tardy that I can't countenance delaying it over a deadlock on an issue like this, so I won't be stubborn on the text that goes in there. Honestly, though, we're a long way from understanding what coupling multiple locations to a SIP request is supposed to mean.

Jon Peterson
NeuStar, Inc.


On 10/28/10 6:01 AM, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> wrote:

To be more specific - we had a document that allowed multiple locations. It was reduced to one without any decision in that direction being made by the working group. It needs to go back to multiple values.

In my view there are clear use cases where multiple values are required.

regards

Keith

> -----Original Message-----
> From: sipcore-bounces@ietf.org
> [mailto:sipcore-bounces@ietf.org] On Behalf Of Richard L. Barnes
> Sent: Thursday, October 28, 2010 1:19 PM
> To: James M. Polk
> Cc: sipcore@ietf.org
> Subject: Re: [sipcore] Location Conveyance -04 submitted,
> here's the changes
>
> >> I'm pretty comfortable with the document at this point,
> but have just
> >> one minor question: Why are you still limiting the number
> of location
> >> values?  Why are three values harmful, but not two?  This
> still seems
> >> like pointless ABNF legislation.
> >
> > we only added the ability to have a second locationValue because of
> > your rough-loc ID. Before that, we were firm in not
> allowing more than
> > one.  Given that choice, which do you like?
> >
> > Remember, this was Jon's proposal in SIPCORE in Anaheim, which it
> > seemed everyone and their brother was agreeable with, so ...
>
>
> As I recall, the proposal was to just remove the limit on the number
> of locations values, not to bump it up by one.  From the minutes:
>
> "Restore Geolocation header that has multiple URIs, even though we
> would not recommend it. Entities inserting persence are responsbile
> for any resulting errors. The header parameters distinguishing URIs
> would not be added back in."
>
> At least in my mind, multiple != 2.
>
> --Richard
>
>
>
>
>
>
>
> > james
> >
> >
> >> --Richard
> >>
> >>
> >>
> >>
> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote:
> >>
> >>> SIPCORE
> >>>
> >>> I've submitted the next version of Location Conveyance (-04)
> >>>
> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio
> n-conveyance-04.txt
> >>> and I believe this version has addressed each open item from the
> >>> mailing list, as well as what was discussed and agreed to in the
> >>> Maastricht meeting.
> >>>
> >>> I have attempted to identify each open issue with the specific
> >>> resolution here (in no particular order):
> >>>
> >>> - Martin wanted Section 3 to be broken up into subsections, each
> >>> revolving around each of the 4 diagrams. I have done this.
> >>>
> >>> - allowed a maximum of two (up from one) locationValues to be
> >>> present in the Geolocation header value. The text however
> recommends
> >>> against inserting a second value. This was agreed to in
> Maastricht.
> >>>
> >>> - Because we're allowing a max of two locationValues,
> they can be in
> >>> separate Geolocation headers in the SIP request. This scenario
> >>> necessitates bring a previous version's paragraph in
> stating that a
> >>> 'SIP intermediary MUST inspect all instances of each Geolocation
> >>> header before considering the routing-allowed parameter to be
> >>> considered =yes', to ensure there isn't a conflict in the 'other'
> >>> Geolocation header that states the policy is =no.
> >>>
> >>> - with the ability to add a second locationValue, it is
> necessary to
> >>> warn against doing this (confusion at the LRs).
> >>>
> >>> - Added the "you break it you bought it" philosophy to SIP
> >>> intermediaries that choose to insert a second location where one
> >>> already existed, especially for inserting a location URI in the
> >>> downstream SIP request.
> >>>
> >>> - Fixed the ABNF to handle zero, one or two (but no more)
> >>> locationValues according to the agreement in Maastricht.
> There is a
> >>> one-off use case which won't be in play very often, but
> is a WG item
> >>> in ECRIT that several wanted to allow the possibility for
> (involving
> >>> allowing one coarse and one highly accurate location in
> the same SIP
> >>> request).
> >>>
> >>> - Paul K. wanted the use-case in which a SIP intermediary
> inserts a
> >>> locationValue where one didn't exist previously, and
> received a 424
> >>> (Bad Location Information) to that inserted location, from having
> >>> the 424 propagate towards the UAC (as the UAC might not
> know what to
> >>> do with a 424). This is now covered in Section 4.3.
> >>>
> >>> - changed existing text to "MUST NOT" from "does not" about a 424
> >>> not terminating an existing dialog (just increased the strength of
> >>> this.
> >>>
> >>> - I added the 424 to the table 2 entry in which the Geolocation
> >>> header can be in only this response.
> >>>
> >>> - I added text stating the conditions for adding a Geolocation
> >>> header value to the 424, to make it clear what is and what isn't
> >>> allowed for this.
> >>>
> >>> - Martin wanted me to add back in the top level Geolocation-Error
> >>> codes 100, 200, 300 and 400, which I did in section 4.3.
> >>>
> >>> - rejected the idea that the geolocation option-tag hasn't been
> >>> justified.
> >>>
> >>> - Added RFCs 2616, 2818 and HELD Deref ID to the
> references section
> >>> because I added the ability to include HTTP: and HTTPS: URIs, and
> >>> stated if received, they should be dereferenced according to the
> >>> HELD Deref doc.
> >>>
> >>> - changed the Section 5 examples how Martin wanted them.
> >>>
> >>> - Stated that GEO-URIs are not appropriate for the SIP Geolocation
> >>> header, according to the discussion during the Maastricht Geopriv
> >>> meeting.
> >>>
> >>> - we changed the privacy section, and included a ref to
> the Geopriv
> >>> Arch doc, according to the agreement in Geopriv at Maastricht.
> >>>
> >>>
> >>> Comments are encouraged
> >>>
> >>> We plan to request (3rd?) WGLC during the SIPCORE meeting
> in Beijing
> >>> (to give folks a sense of our plans).
> >>>
> >>> James/Brian/Jon
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
>
> _______________________________________________
> 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