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 PROTECTED] > 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 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
