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

[<[e-mail]>]

Thanks, Keith,

I was not sure why the public network would add its idea of the user location if it has received one from the corporate network already, but I can't see why it would not be allowed to do so either.

So it seems your are right.

BR,
Hannu Hietalahti
3GPP TSG CT Chairman
tel: [phone]
 

>-----Original Message-----
>From: ext DRAGE, Keith (Keith) [mailto:[e-mail]] 
>Sent: 02 November, 2010 01:04
>To: Hietalahti Hannu (Nokia-CIC/Oulu); [e-mail]; 
>[e-mail]
>Cc: [e-mail]
>Subject: RE: [sipcore] Location Conveyance -04 submitted, 
>here's the changes
>
>If in 3GPP we look at subscription based business trunking arrangement.
>
>The end terminal includes one location.
>
>The enterprise network supporting the UE adds its own view of 
>where the UE is.
>
>The public network adds its own view of the location.
>
>That makes three.
>
>regards
>
>Keith 
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] 
>> Sent: Monday, November 01, 2010 11:46 AM
>> To: DRAGE, Keith (Keith); [e-mail]; [e-mail]
>> Cc: [e-mail]
>> Subject: RE: [sipcore] Location Conveyance -04 submitted, 
>> here's the changes
>> 
>> Hi Keith,
>> 
>> yes, I remember you made this comment at Maastricht already, 
>> and I agree with you that from 3GPP viewpoint we need 
>> encoding that allows *more than one* piece of location information.
>> 
>> In 3GPP case those would be typically the one obtained from 
>> the terminal and the one added by the serving network if it 
>> thinks it knows better. 
>> 
>> But my imagination runs out after these two. Are you saying 
>> we need more than 2?
>> 
>> BR,
>> Hannu Hietalahti
>> 3GPP TSG CT Chairman
>> tel: [phone]
>>  
>> 
>> >-----Original Message-----
>> >From: [e-mail]
>> >[mailto:[e-mail]] On Behalf Of ext DRAGE, 
>> Keith (Keith)
>> >Sent: 28 October, 2010 16:01
>> >To: Richard L. Barnes; James M. Polk
>> >Cc: [e-mail]
>> >Subject: Re: [sipcore] Location Conveyance -04 submitted, 
>here's the 
>> >changes
>> >
>> >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: [e-mail]
>> >> [mailto:[e-mail]] On Behalf Of Richard L. Barnes
>> >> Sent: Thursday, October 28, 2010 1:19 PM
>> >> To: James M. Polk
>> >> Cc: [e-mail]
>> >> 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
>> >> >>> [e-mail]
>> >> >>> https://www.ietf.org/mailman/listinfo/sipcore
>> >> >
>> >> > _______________________________________________
>> >> > sipcore mailing list
>> >> > [e-mail]
>> >> > https://www.ietf.org/mailman/listinfo/sipcore
>> >> 
>> >> _______________________________________________
>> >> sipcore mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/sipcore
>> >> 
>> >_______________________________________________
>> >sipcore mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/sipcore
>> >