Subject: [Ecrit] LoST -02 and error handling

From: "James M. Polk" <[email-masked]>
Date: Fri, 27 Oct 2006 12:43:57 -0500

Authors of LoST -02

Please remind me again why were the -01 error codes removed (for a single 
word text string)?

Thanks
James

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

---

From: Andrew Newton <[email-masked]>
Date: Fri, 27 Oct 2006 14:06:31 -0400

James M. Polk wrote:
> Please remind me again why were the -01 error codes removed (for a 
> single word text string)?

Single word text string?  You mean that stuff we call XML?

We moved away from the error numbers because certain errors required certain 
syntax, which meant we were no longer defining this XML based protocol with 
an XML based schema language.  Additionally, some of them were not mutually 
exclusive.

Within the author team, we are looking to overhaul it once more because we 
believe that the current way is still confusing, and we have discussed a 
simpler, more concise idea.  But we are not looking at going back to error 
numbers.

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 27 Oct 2006 13:24:08 -0500

>Single word text string?  You mean that stuff we call XML?

no

I mean "forbidden" and "notFound" and "serverTimeout" and etc...

Which is different than the 400, 401, 404, 503, etc that -01 had in it.

I checked with a member of your author team - who confirmed this was to be 
maintained wrt to the Registry ID he was told about.

>We moved away from the error numbers because certain errors required 
>certain syntax, which meant we were no longer defining this XML based 
>protocol with an XML based schema language.  Additionally, some of them 
>were not mutually exclusive.
>
>Within the author team,

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.

>we are looking to overhaul it once more because we believe that the 
>current way is still confusing, and we have discussed a simpler, more 
>concise idea.  But we are not looking at going back to error numbers.
>
>-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 27 Oct 2006 14:37:31 -0400

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

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

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... such 
as which method is best for protocol interoperability and readability of the 
specification.

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 27 Oct 2006 16:40:20 -0500

At 02:37 PM 10/27/2006 -0400, Andrew Newton 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

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

>numbers away from the XML.  In essence, we are putting things back the way 

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.

>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

---

From: Andrew Newton <[email-masked]>
Date: Fri, 27 Oct 2006 19:09:48 -0400

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