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

From: Paul Kyzivat ^lt;pkyzivat@cisco.com>
Date: Tue Jul 27 2004 - 11:17:10 EDT

James - comments inline.

        Paul

James M. Polk wrote:
> 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).

Well, the notifier is always in charge. It could choose to only send the
location once (or not at all) even though the subscriber has implicitly
asked to be notified of each change.

It can do this by terminating the subscription after the first
notification and refusing further subscriptions, or it can leave the
subscription active and just fail to send further notifications.

>> - 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).

I think there is a difference here. Conveying the location in INVITE or
UPDATE is IMO an intent to associate it with the dialog state. It
doesn't imply anything specific about how (or if) it is presented - only
that it is available.

Sending it in MESSAGE implies to me that the location information would
be formatted and displayed in a chat window, just as if it had been sent
as a text message. I think that could be a very valid thing to do, but
it is semantically different.

I can imagine all sorts of automated processes being driven off the
location state of the dialog. But I would not expect those same things
to happen *implicitly* as a result of a MESSAGE.

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

Lets see if we can get some other opinions on this subject.

>> 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.

This is the key point. If the location information is viewed as part of
dialog state, then any of the ways of updating dialog state should be
viewed as appropriate. Otherwise, this location conveyance is just extra
behavior defined for certain methods and your desire to minimize the
number of choices is appropriate.

Note that there is another draft (draft-elwell-sip-state-update-02.txt)
that is seeking clarification of dialog state information.

>> (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).

See above. I think it makes sense to send location info this way, but
think it means something subtly different.

There is another aspect (unmentioned in your draft) that may affect
this. It says nothing about content-disposition. But content-disposition
does matter - it provides a context regarding how this content is to be
treated.

In the absence of saying anything, the default is "render". This would
make sense for MESSAGE. And I think it would not suggest that it receive
any special treatment. But it isn't at all clear what "render" means in
the context of an INVITE.

Another possibility might be "attachment" - this does suggest something
that just sits there as an extra resource available for access. Another
possibility is "alert" when it comes in an INVITE - then it might indeed
be considered part of the info presented while alerting.

*IF* some content-disposition other than "render" were used, and it was
sufficiently suggestive about its intended semantics, then it might make
more sense to consider MESSAGE for carrying location info and having it
processed specially (as if it came in an INVITE) rather than just
displaying it in the chat window.

The whole subject of content-disposition semantics is underspecified for
sip, so we are effectively making this up as we go along.

> 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 want to see what others think. I personally think we should
declare this to be added dialog state, and specify which
content-disposition it should have in order to be considered as such.
Then it doesn't matter what message it travels in.

>> 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)

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 27 Jul 2004 11:17:10 -0400

This archive was generated by hypermail 2.1.8 : Wed Jul 28 2004 - 09:43:44 EDT