[Geopriv] Re: [Sipping] New Location Conveyance ID posted

From: James M. Polk ^lt;jmpolk@cisco.com>
Date: Mon Jul 26 2004 - 20:30:24 EDT

Paul

comments in-line

At 03:42 PM 7/26/2004 -0400, Paul Kyzivat wrote:
>James,
>
>Couple of potential issues:
>
>- the inclusion of location info may force the use of a multipart/mixed
>container.

I think it will for INVITE

>This in turn could result in a failed call attempt if the recipient
>doesn't support multipart/mixed. In some cases, such as emergency calls,
>this isn't a problem, because the recipient can be presumed to be
>expecting location information and to have the necessary support. Whether
>this is a good expectation in other cases depends on how the UAC decides
>that location info should be included. At the very least, if the UAC gets
>a 415 error response indicating lack of support for multipart/mixed, then
>the UAC should probably try again without the location information. This
>may be worth pointing out.

will do

>- There is a brief mention in section 7 of the problems in returning UAS
>location in the 2xx response. I see no mention of returning it in a
>reliable 1xx response. That seems like a potentially useful thing to do.
>It could provide extra information for the caller to decide among multiple
>early dialogs.

fair, I will add this.

But, as is pointed out in the ID, there is not way (yet) for a UAC to ask
for location from the UAS (see below)

>- you note the open question about mechanism to request transmission of
>location info. This may be important for non-emergency uses at least for
>the reason I mention above.

I agree, and I think if a mechanism is to be specified to request location
in a response, I believe we might want to think of the request specifying
which format of location (coordinate or civil) should be in the response. I
don't know if we want to get into the details of "what is your room number"
in a subsequent request (to one that didn't include a detail that was
desired in the first location reply).

>Otherwise, how will the UAC ever know to include it? This isn't something
>the UAC, or even the user, can figure out based on just the called address,

we state this is the case for sos@, but no other called addresses, so I
agree in general

>and it isn't something the UAC will always want to include.

definitely not

>The speculation about SUB/NOT may come into play here. Maybe when I call
>sip:pizzasRUs.com, it could subscribe back for my location info.

yes again, and this has the potentially unfortunate side effect of having
the ability to SUB/NOT for refreshing the UAC's location either when it
moves or just as a periodic poll. This can be useful if requested, and a
problem if not foreseen (creating the ability to track the UAC and user).

>- Section 8.2 notes preference for MESSAGE over UPDATE for transmitting
>location after a dialog has been established. I think this takes too
>narrow a view of UPDATE. It MAY be used in a dialog when no INVITE is in
>progress, such as for refreshing a session timer.

I hadn't considered session timer...(sorry)... but wanted to reduce the
number of seemingly parallel choices for certain usages to INVITE or
MESSAGE at message origination (plus PUBLISH to a service), UPDATE before a
final response and MESSAGE when location is independent of a dialog
(meaning also when a dialog is already established between the two UAs).

>Using it for conveyance of location info appears appropriate to me, as
>does using reINVITE for this purpose.

You're suggesting using reINVITE with the same CallID and just an
incremented CSeq for that method just for conveying location? This behavior
is appropriate for requesting a parameter change to an existing dialog
(generally thought of as requesting a new codec for an existing dialog) -
but I didn't consider it appropriate for changing of completely non-dialog
parameters, as I am not sure I even consider location to be a parameter.

I can change that stance if you want

>This is largely a matter of point of view - I would be inclined to view
>location information as additional (but optional) state of a dialog. (I
>view the use of MESSAGE for this purpose as at least as much an abuse of
>its intended purpose as using UPDATE or reINVITE.)

hmmmm ... see, I don't consider it an abuse of MESSAGE, as I see me wanting
to send you my location (and saying as much in text) as a perfect fit for
MESSAGE. I can see a (soft) button on a (mobile) phone/IM device that is
just for that purpose with a generic text string stating "this is James's
location" that's included in the single location conveyance message when I
hit that button. I see teenagers using this a lot. And when I am in a
dialog with you, I can access my phone options and send you my location
during that dialog simply by activating that option (pushing a button).

I would like to know if you (and others) are flexible or firm on this... I
think MESSAGE reduces the number of choices to be supported (therefore less
code to be written), unless you see the number of choices as enabling more
capabilities (which I do not yet).

>I also don't see the point of the restriction in 8.3 of using UPDATE to
>send location info only if it had previously been send in an INVITE.

If I change 8.2 as you suggest, I will change 8.3 to open up the usage -
I'd like to read/hear your response first (you've moved me to the fence though)

> Paul

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon, 26 Jul 2004 19:30:24 -0500

This archive was generated by hypermail 2.1.8 : Mon Jul 26 2004 - 20:35:52 EDT