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
Paul Kyzivat wrote:
Brian Rosen wrote:
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.
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
Brian
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 01, 2007 1:33 PM
To: [email protected]
Subject: Re: [Sip] Location-conveyance: ISSUE #3 - multiple locations
From: Henning Schulzrinne <[EMAIL PROTECTED]>
> 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.
>
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
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 protected]>;inserted-by=endpoint
Geolocation: <sips:[EMAIL PROTECTED]>;inserted-
by=endpoint
or
Geolocation: <cid:[email protected]>;inserted-by=endpoint,
<sips:[EMAIL PROTECTED]>;inserted-by=endpoint
Dale
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
