Subject: RE: [Sip] Location-conveyance: ISSUE #3 - multiple locations

From: "Brian Rosen" <[email-masked]>
Date: Tue, 1 May 2007 11:53:48 -0400

Proposed text for this subject:

Sending multiple locations (multiple Geolocation headers, or multiple
locationValues in a single Geolocation header is confusing to the UAS.  It
has no way to decide what these mean, and how to use them.  There are a few
exceptions to this general statement.  The UAC may have both a reference and
a value, and may wish to send them together.  The value is the current
location of the UAC when sent, and the reference may be used to obtain a
more current (and possibly more accurate) location later.  Also, a proxy
server may assert location even if the UAC provided location.  In this case,
the inserted-by value would be different.  Finally, applications of location
may specify specific behavior for multiple locations and thus blanket
prohibition of such is ill advised.

Therefore:

A UAC or proxy wishing to supply both a reference and a value, representing
the location of the UAC from the same source, MUST provide a single
Geolocation header, with two locationValues, and an inserted-by value.

Otherwise, and in the absence of application specific guidance, multiple
Geolocation headers and multiple locationValues with the same inserted-by
value SHOULD NOT be used.

Brian

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Saturday, April 28, 2007 4:00 PM
> To: IETF SIP List
> Subject: [Sip] Location-conveyance: ISSUE #3 - multiple locations
> 
> (As SIP WG chair)
> 
> During the review of the WGLC comments, we have identified some issues
> where we need consensus calls on the list. These are in one call per
> message.
> 
> We had a number of comments that it was not clear whether a message
> could contain multiple locations, and if they were, what were the
> procedures.
> 
> On the call we identified what we believe the way forward in this area,
> which is summarised by the following statements:
> 
> -	location conveyance should support the delivery of multiple
> locations;
> 
> -	the document will make no recommendations as to how the
> recipient chooses
> which location to use. This is regarded as specific to the using
> application,
> and therefore beyond the scope of the protocol extension;
> 
> -	the recipient should attempt to make use of all the locations
> given, and
> should only respond with a 424 response if it is unable to use any of
> those
> locations. This includes resolving all and any locations by reference;
> 
> -	as a result of the above, any 424 response is a collective
> statement about
> all the locations given in the request rather than any specific location
> in the
> request.
> 
> We will assume that this represents WG consensus unless we hear
> otherwise from the WG in 7 calendar days from the posting of this
> message.
> 
> Obviously if the WG has an alternative view, some proposal of the
> alternative way forward and the expected impact on the text would be
> entirely appropriate.
> 
> Regards
> 
> Keith
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 1 May 2007 12:47:48 -0400

> the inserted-by value would be different.  Finally, applications of  

different from what?

Do you mean that they differ from each other?

> Geolocation header, with two locationValues, and an inserted-by value.

That doesn't work, unless I'm misunderstanding what you mean.

Geolocation: x
Geolocation: y

is exactly the same (syntactic transformation) as

Geolocation: x, y

---

From: [email-masked]
Date: Tue, 1 May 2007 13:33:03 -0400

From: Henning Schulzrinne <[email-masked]>

   Geolocation: x
   Geolocation: y

   Geolocation: x, y

What it must mean is:

	A UAC or proxy wishing to supply both a reference and a value,
	representing the location of the UAC from the same source,
	MUST provide two locationValues, both containing inserted-by
	geloloc-params with the same value.

For example:

   Geolocation: <cid:[email-masked]>;inserted-by=endpoint
   Geolocation: <sips:[email-masked]>;inserted-by=endpoint 

or

   Geolocation: <cid:[email-masked]>;inserted-by=endpoint,
       <sips:[email-masked]>;inserted-by=endpoint 

Dale

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 1 May 2007 14:13:28 -0400

Yeah, I wanted to limit options.  I wanted two representations of the same
location as a single header.  I'm not really stuck on that, but cutting down
on options is good.

Brian
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2007 1:33 PM
> To: [email-masked]
> Subject: Re: [Sip] Location-conveyance: ISSUE #3 - multiple locations
> 
>    > representing

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 May 2007 19:21:45 -0400

> location as a single header.  I'm not really stuck on that, but cutting down

The general approach of allowing multiple valued headers to appear by 
repeating the header or using comma separated values is quite deeply 
embedded. Making an exception for one header would IMO be far worse than 
being consistent with all the other multivalued headers.

The stacks I know of handle this internally. An exception will require 
more code, not less.

	Paul

---

From: Richard Barnes <[email-masked]>
Date: Tue, 01 May 2007 20:58:49 -0400

Also, it seems like an abuse of syntax to use groupings of header values 
(which traditionally have no meaning) to indicate groupings of location 
URIs.  If you want to do that, do something like add an 
inserter-tag=rand12345 parameter.

In any case, I don't think we need to go into this much detail for a 
generic conveyance mechanism.  If I may suggest text:

"
Sending multiple locations in a SIP message (i.e., multiple Geolocation 
headers, or multiple locationValues in a single Geolocation header) can 
be confusing to the UAS.  Based on the information in the SIP message, 
the UAS may have no way to make a meaningful choice as to which 
locations to use, and how to use them.  This document defines only one 
mechanism to distinguish among multiple locations, the inserted-by URI 
parameter, which is used to differentiate proxy-inserted and 
endpoint-inserted locations when both a proxy and and endpoint assert 
locations.  Future documents may define additional parameters to express 
other differences.

Beyond these parameters, however, this document provides no other 
mechanisms for distinguishing among multiple locations included in a SIP 
message.  Thus, it is NOT RECOMMENDED that locations be added to a SIP 
message that have the same values for these parameters as locations 
already in the SIP message.  For example, if a proxy receives a message 
that contains a location with inserted-by=server, the proxy SHOULD NOT 
insert additional locations into the message.  For endpoints, this 
recommendation means that a UAC SHOULD NOT include multiple locations in 
a SIP request.  Should a UAC choose to include multiple locations, all 
locations MUST indicate the same physical location, namely that of the 
endpoint.
"

To sum up: This document gives you inserted-by; might be others in the 
future.  Beyond that, there be dragons!

I don't think message-routed-on-this-uri is right to include here, since 
that tag should be applied to all locations to which it applies.

--RB

---

From: [email-masked]
Date: Wed, 2 May 2007 22:37:02 -0400

From: "Brian Rosen" <[email-masked]>

Permit me to exercise one of my peeves -- though it appears that
limiting the syntax of the header is beneficial, it is in fact
harmful.  You want as much uniformity in header syntax as possible, so
that implementations can use generic parsers to do the low-level
conversion of the character stream to a data structure of
names/values/whatever.  You also want to allow generic "un-parsing" to
convert the data structure to the character stream.  But if you make
ideosyncratic declarations that a particular header does things
*slightly differently* than all similar headers, implementations are
reduced to using custom code to generate every header.

Dale

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 3 May 2007 14:57:57 -0400

Paul made that point already.  

I'll reword so either two locations in one header or two headers with one
location is acceptable.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, May 02, 2007 10:37 PM
To: [email-masked]
Subject: Re: [Sip] Location-conveyance: ISSUE #3 - multiple locations

   Yeah, I wanted to limit options.  I wanted two representations of the
same
   location as a single header.  I'm not really stuck on that, but cutting
down
   on options is good.

Dale