Re: [sipcore] Summary: number of location headers

[<[e-mail]>]

Thanks James,

I agree. Jon already gave me his explanation which was pretty similar to yours and therefore I am willing to withdraw my request to avoid the "SHOULD NOT". While saying SHOULD NOT, we might also want to give the reason to that strong recommendation, though?

We know at least one case where it will be mandatory for the terminal and the network to insert the user location. I hope the problem with correlating 424 reject to any of the multiple location objects does not stop us keeping the option of multiple location objects.

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

>-----Original Message-----
>From: ext James M. Polk [mailto:[e-mail]] 
>Sent: 11 November, 2010 08:15
>To: Hietalahti Hannu (Nokia-CIC/Oulu); 
>[e-mail]; [e-mail]
>Subject: Re: [sipcore] Summary: number of location headers
>
>Hannu
>
>One aspect you do not mention below is how erroring is handled with 
>multiple locations in the same SIP request. As the doc stands today, 
>there is no consideration for who receives the 424 as to which 
>location was in error. If there is only 1 location, this is simple to 
>correlate.
>
>I am sympathetic to the emergency services case, and I'm hesitant to 
>call that one case out as an exception because in the future there 
>might be an equally valid case that hasn't been called out - then 
>where are we (i.e., is the RFC then accurate?).
>
>Therefore, I think the emergency case can be an example of why 
>"SHOULD NOT" doesn't apply, but that it is justified in an emergency 
>document, and not here in the general purpose document (i.e., this is 
>better suited IMO for ECRIT phonebcp or ECRIT framework documents).
>
>With that logic, respectfully, I think SHOULD NOT is appropriate here.
>
>James
>
>At 11:45 PM 11/10/2010, [e-mail] wrote:
>>Thanks for summarising, Adam,
>>
>>being one of those requesting this change I of course support it, 
>>but could we please also re-word the warning against adding multiple 
>>locations from "SHOULD NOT" to giving a warning that adding more 
>>location objects does not guarantee better accuracy and any possible 
>>conflict resolution is left for the receiver of this information.
>>
>>The issue is real and I am not arguing to remove this warning. But 
>>in case of emergency calls just strongly recommending against 
>>multiple location objects with "SHOULD NOT" does not help much if 
>>both the terminal and the network *have to* insert their best 
>>understanding of the user's location.
>>
>>BR,
>>Hannu Hietalahti
>>3GPP TSG CT Chairman
>>tel: [phone]
>>
>>
>> >-----Original Message-----
>> >From: [e-mail]
>> >[mailto:[e-mail]] On Behalf Of ext Adam Roach
>> >- SIPCORE Chair
>> >Sent: 09 November, 2010 11:10
>> >To: SIPCORE (Session Initiation Protocol Core) WG
>> >Subject: [sipcore] Summary: number of location headers
>> >
>> >[as chair]
>> >
>> >I just wanted to summarize where it looks like the 
>discussion ended up
>> >on whether we constrain the number of location header 
>fields in a SIP
>> >message. From my review of the discussion, I believe that 
>four people
>> >have weighed in on the topic to voice support for an arbitrary
>> >number of
>> >location headers (albeit with a implementation warning that
>> >doing so is
>> >not advisable):
>> >
>> >Martin Thompson:
>> >http://www.ietf.org/mail-archive/web/sipcore/current/msg03576.html
>> >Richard Barnes:
>> >http://www.ietf.org/mail-archive/web/sipcore/current/msg03580.html
>> >Keith Drage:
>> >http://www.ietf.org/mail-archive/web/sipcore/current/msg03600.html
>> >Hannu Hietalahti:
>> >http://www.ietf.org/mail-archive/web/sipcore/current/msg03619.html
>> >
>> >And two people have agreed to go along with that direction, with
>> >expressed reservations:
>> >
>> >Jon Peterson:
>> >http://www.ietf.org/mail-archive/web/sipcore/current/msg03601.html
>> >James Polk:
>> >http://www.ietf.org/mail-archive/web/sipcore/current/msg03603.html
>> >
>> >If any other working group participants have comments on this topic,
>> >they are encouraged to make them quickly. Lacking any further
>> >input, the
>> >authors will be instructed to revise the document to allow an
>> >arbitrary
>> >number of location header fields, with an accompanying warning that
>> >doing so is not recommended.
>> >
>> >/a
>> >_______________________________________________
>> >sipcore mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/sipcore
>> >
>>_______________________________________________
>>sipcore mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/sipcore
>
>