On Oct 27, 2006, at 5:40 PM, James M. Polk wrote:
>> Each one of these is an XML element name in the draft. So yes,
>> that is what you are talking about.
>
> tomato, tomato, whatever
It's only XML, it can be that important to an XML-based protocol. :)
> I'm asking why, cuz I didn't/don't/haven't seen or read that
> explained anywhere
See section 10 of -02.
> this isn't how -00 was, nor -01, so I don't have a reference to
> what you're referring to when you make the statement: "...back the
> way they were..." <when>....? Which version of which ID had it this
> way.
See Section 10, Page 22 of -00.
> this is where we apparently differ, cuz I thought I was doing this
> by creating the Registry (asked for by YOUR co-chair BTW) of common
> location specific error cause codes, such that all protocols that
> have errors specific to a location value/reference provided, can
> use a common set of errors with generally agreed upon meanings.
I believe this is already been addressed in another thread on the
GEOPRIV list. Shall I forward to you the relevant emails for reference?
> For example,
>
> - Alice calls for 911/112 help, the INVITE arrives at the P/E-CSCF
> (or just ESRP), if there is a problem with just the location
> provided in that INVITE, the server will respond to Alice's UA with
> a SIP error. SIP needs to be extended to provide a more granular
> location-error.
That sounds about right to me.
> - take the above same example, but the P/E-CSCF (ESRP) needs to
> derefence the URI. This isn't a SIP error anymore if the LoST
> server cannot service that LoST request, it's a LoST error. Does
> this need to be communicated back to Alice? In this case probably
> not. But, if the URI was bad, then it probably does. Now there are
> two errors (one from LoST in your XML only, and one in SIP in a
> Reason header) or there is one error (to be used by both protocols,
> though the form may be different).
Why would there be LoST generated error if the ESRP cannot
dereference a location? LoST would not be invoked at all in the
scenario you just described because the dereference occurs first.
Now, what about expressing both <serviceSubstitution> and
<locationProfileError> simultaneously in SIP, as we need to do in LoST.
> Me thinks this makes things easier, and I'm getting the impression
> you don't want to discuss that being possible, or are opposed to
> this idea in general, or something else.
Again, this has been covered in another thread on the GEOPRIV list.
> Also, if Alice's UA ever does a LoST request her(its?)self, the UA
> will have to have been coded with all the LoST errors, and a nearly
> duplicative set of Reason errors that are important to SIP entities
> whenever Location is conveyed.
Probably. But an IANA registry is a long, long way from both those
pieces of code being the same.
> "the specification"? this isn't a one stop shop my friend, and you
> well know LoST is only a piece of the puzzle, and a dependant one
> at that. More than one spec is needed to make any of htis work, and
> this Registry is an attempt to make some of those pieces work more
> commonly (in harmony?).
Just how would you have pulled this off if ECRIT had adopted DNS-
SOS? This goes to Henning's point (in that other thread) about
protocols and their basic nature.
> Now, I can take the XML element names that are in LoST-02 and make
> them newly numbered error codes in the Registry, or we can define a
> translation of a
>
> LoST <notFound> element
> to
> SIP
> Reason: location; cause=9; "Incomplete Location Supplied"
>
> or something along these lines whenever this is appropriate,
> because there are situations in which the LoST server produces an
> error that the UA needs to get via the ESRP_P/E-CSCF.
or you can go with the suggestion made in that other thread.
-andy
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 27 Oct 2006 19:09:48 -0400
This archive was generated by hypermail 2.1.8 : Fri Oct 27 2006 - 19:21:41 EDT