Re: [sipcore] Summary: number of location headers

["James M. Polk" <[e-mail]>]

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