Subject: [Geopriv] Re: draft-polk-geopriv-location-based-error-registry-00

From: "James M. Polk" <[email-masked]>
Date: Sun, 05 Nov 2006 14:39:35 -0600

At 06:50 PM 10/17/2006 -0700, Randall Gellens wrote:
>Hi James,
>
>Thanks for doing this draft.  I agree it is useful.

wow, did I miss this one

sorry for the extremely late response

Since you sent this, others have chimed in, not thinking this is useful as 
a generic means for location errors across protocols, but that each Geopriv 
Using Protocol should identify their own in their respective doc(s).

I think this will force a interworking doc to be written in the cases, for 
example, in which the location error is from a LoST server, but it needs to 
go back to the phone/UAC to fix.  This example crosses two protocols with 
decidedly different error schemes (one XML, one a single value header).

We'll see in the session this week...  :-/

>------------------------------
>Comments:
>
>Regarding the editor's question in Section 3.4 (Unsupported Schema) about 
>communicating the desired schema by using unique error codes, what about 
>when the recipient is capable of handling a number of schemas, just not 
>the one supplied?  It might be better to stick with one error code for 
>'unsupported schema', and maybe include a list of supported schemas.

I think I was postulating of possibly separate location error codes saying 
basically

         Unsupported Schema, now send (X)

for each of the foreseen schemas (sip, sips, pres, http(once approved), 
https(once approved), etc).  To get a list of possible receiver supported 
schemas we can send several in the same response, such as

         Unsupported Schema, now send (X),       Unsupported Schema, now 
send (Y),
         Unsupported Schema, now send (Z)

In SIP, these would be comma separated Reason header values.

It's not like there is a limit to the number we define here.

If acceptable, I'll move all the known schemas to be together, say starting 
at 20, making it (something like this):

20 Unsupported Schema, now send (sip)
21 Unsupported Schema, now send (sips)
22 Unsupported Schema, now send (pres)
etc

earmarking the 20s for the schemas that are added (like http and https once 
Geopriv approves those schemas)

>The using protocol is likely to have its own mechanism for communicating 
>this,

exactly

>but it might be good to have it in the response as well, if there is a way 
>to do so.
>
>------------------------------
>Some suggestions:
>
>In Section 1 (Introduction), delete "other" in "other transport protocols".

done

>In Section 2, the text:
>    including a malformed Location Object which
>    couldn't be parsed by the server to make a routing decision upon
>
>If the server couldn't parse it, that's reason enough.  So you might want 
>to delete "to make a routing decision upon" or perhaps add "use for a 
>routing decision" as another example.

done

>In Section 3, should 'location generator' be 'location sender'?

I think the generator is the sender from 3693, but I can change this to 
make it clearer to newer readers.

>In Section 3.5, I think it would read better to move "in a request" 
>earlier in the sentence, to just after "provided".

done

>In Section 3.9, maybe say "include a more complete or precise position" 
>instead of "verify it has a complete position to convey"?

done

>------------------------------
>Some typos:
>
>In Section 2, "by" should be "by a" in "by message routing server".

done

>Also in Section 2, delete "a" in "a Alice's".

done

>In Section 3.6, need "the" in "means location" (should be "means the 
>location").

done

>Also in 3.6, the text:
>    location
>    sender to verify it has indeed included location in the new request
>
>Does this mean the location sender should verify that it did in fact 
>include a location in the request?  Or does it mean the sender should send 
>a new request, and verify that it (sent in response to the error) includes 
>a location?  Either way, the use of "verify" seems odd, since we're 
>talking about software behavior.

verify is a bad word here - I'll fix this

>In Section 3.7, the text:
>    or the
>    referencable server some other error
>
>Seems garbled.

it is - I'll fix this

>In Section 3.9, the text:
>    A typical reaction to receiving this message is of the sender to
>    verify it has a complete position to convey.
>
>"of the" should be "for the".

done

Thanks!!

James

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