[Geopriv] Re: [Ecrit] LoST -02 and error handling

At 02:37 PM 10/27/2006 -0400, Andrew Newton wrote:
>James M. Polk wrote:
>>>Single word text string? You mean that stuff we call XML?
>>no
>>I mean "forbidden" and "notFound" and "serverTimeout" and etc...
>
>Each one of these is an XML element name in the draft. So yes, that is
>what you are talking about.

tomato, tomato, whatever

The error code numbers:

400 Bad Request
403 Forbidden
404 Not Found
414 Location Error
500 Server Internal Error
501 Service Not Implemented
504 Server Time-Out

were there in LoST-01, now they're gone - I'm asking why, cuz I
didn't/don't/haven't seen or read that explained anywhere

>>ahem... now that this is a WG item - don't you authors need WG consensus
>>to make this type of change? At least with a message to the list asking
>>if folks agree? I may have missed that message since the SDO conference
>>(which I don't believe I did at the moment), but I think it is
>>appropriate procedure to do it this way.
>
>I don't remember much discussion on this list about switching to error
>numbers away from the XML. In essence, we are putting things back the way
>they were.

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.

>Of course, you and I could snipe at each other all day on the mechanics of
>how a draft changes, or we could address issues that really matter...

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.

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.

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

I think there are a few of the LoST errors that are similar to the SIP
Reason errors offered by this new ID.

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.

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.

>such as which method is best for protocol interoperability and readability
>of the specification.

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

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.

How this is translated can be easier or harder depending on how we all look
at this as an architecture, not a series of solo specs.

James

>-andy

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 27 Oct 2006 16:40:20 -0500