Subject: [Geopriv] Last (Geopriv) Open Issue with Location Conveyance

From: "James M. Polk" <[email-masked]>
Date: Tue, 30 Oct 2007 15:38:41 -0500

Geopriv WG

I presented the Geopriv specific open issues in SIP Location 
Conveyance (-08) at the last IETF.

There were 4 items in question, with one to be moved to the list - 
which I am now doing (late).

Background here -- version-08 created the Geolocation-Error header, 
this was in place of the Reason header and then the Warning header - 
which included a the response the specific reason for the error. It 
also includes which location-inserting element the header is intended 
for.  This makes sure elements in the signaling path don't misread 
the error as something they caused, and try to correct something they 
didn't break. It also specifically addresses the case in which a 
proxy inserts location that is bad in some way, and the response gets 
back to the UA (which is natural in SIP) and the UA doesn't know 
anything about why there was an error, and attempts to do something 
about what it doesn't know it didn't cause.

I proposed in the meeting that the next version of the ID (-09) 
include a new header parameter in Geolocation-Error that includes 
specifically what part of the supplied location was in error.  This 
is easiest done in Civic, by including the CATypes in the response 
(but *NOT* the CAType values) that were in error as deemed by the 
location erroring entity.

Hannes and James W. suggested this wasn't good enough, and that 
something similar ought to be included when Geo location were in the 
message.  I don't know exactly how to do that.  Does this mean a 
point of a linear ring that the Location Recipient considers bad 
ought to be included? I'm not sure how that can be achieved, or sent 
(without sending the value -- which I don't think is a good idea).

I believe including any CAType in error, as determined by the 
Location Recipient, is a good information exchange back to the 
location inserter (so they know specifically what to correct).

Does anyone have a suggested solution here how to include something 
similar in Geo, or is this suggestion to include Geo not easily (or 
realistically) attainable?

Since I don't know how to achieve this, as a compromise, I could 
include something like "...MAY be defined for Geo in a future 
effort." This specifically says the idea is there, and thought of, 
but not refined enough at the time to include in *this* document.

Sorry for not getting this out sooner, but I need to finish this item 
to get the last version out before I request a WGLC.

Thanks

James

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv