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

["Elwell, John" <[e-mail]>]

Yes, I agree that replacing an enterprise-provided location is very bad. The problem with adding locations to locations already present is how the PSAP chooses between 2 or even 3 locations. From my reading of the draft, we don't have any normative statement on the order in which locations are placed in the header. If we had a rule that the first locationValue within a single or multiple Geolocation header fields is nearest to the source of the request, and so on, it might help. Then it would be clear that the service provider-provided location would be the least reliable, but it would still be there, e.g., for use if the other locations are bogus.

John

> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:[e-mail]] 
> Sent: 05 November 2010 04:37
> To: Elwell, John; [e-mail]; 
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: [sipcore] Location Conveyance -04 submitted, 
> here's the changes
> 
> Exactly, that is why I am saying you need multiples.
> 
> Otherwise the scenario is that the PBX puts one in, and the 
> public network then replaces it because it says the regulator 
> tells the network to always provide a location. At least with 
> my approach, all the locations are there, and the PSAP then 
> sorts it out.
> 
> Keith
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:[e-mail]] 
> > Sent: Thursday, November 04, 2010 5:48 PM
> > To: DRAGE, Keith (Keith); [e-mail]; 
> > [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: [sipcore] Location Conveyance -04 submitted, 
> > here's the changes
> > 
> > Keith,
> > 
> > Be very careful with this sort of approach. The trend is 
> > towards fewer SIP-PBXs and fewer "SIP trunks" serving an 
> > enterprise, with often a single SIP-PBX and a single entry 
> > into the SIP Service Provider for a whole country or even 
> > multiple countries. Even for the single country case, the 
> > service provider network is unlikely to have a clue as to 
> > where, in the country, the caller might be located (or even 
> > where the PBX is located if there are two geographically 
> > separate servers). Caller ID isn't likely to help either, 
> > since users can move around within the enterprise network.
> > 
> > John
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of DRAGE, 
> Keith (Keith)
> > > Sent: 01 November 2010 23:04
> > > To: [e-mail]; [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
> > > > >
> > > _______________________________________________
> > > sipcore mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/sipcore
> > >