Subject: [Geopriv] New ID on Location specific Error cause codes

From: "James M. Polk" <[email-masked]>
Date: Thu, 26 Oct 2006 19:37:38 -0500

GEOPRIV WG

I've written a new individual ID creating a registry of Location specific 
error cause codes, to be used (mainly) by text based protocols that error a 
message in the protocol based on something wrong with the location within 
the message. Here is the URL:

http://www.ietf.org/internet-drafts/draft-polk-geopriv-location-based-error-registry-00.txt

An easy example of this is Alice provides her location to Bob (say, in a 
SIP INVITE), but his UA has a problem with the location within that SIP 
request.  This reqistry provides a granular error cause code list that can 
by carried in the SIP response message (in a Reason header) back to Alice 
indicating there was a "location error" with the request message, and what 
type of error it was.  Perhaps Bob only understands civic and Alice's 
PIDF-LO was only Geo.  Perhaps Alice provided an incomplete location, or 
two conflicting locations or something else that was wrong with the 
location within the original message.

This registry is NOT limited to SIP, and after talking to Henning, I 
believe this can be used for LoST, and other protocols.

The intent is to have a common set of location specific error cause codes 
to be conveyed within and across protocols so that each protocol doesn't 
invent their own versions of error cause codes, leading to 
interoperability/confusion by elements attempting to figure out what 
actually happened.

Comments would be appreciated

Thanks
James

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Oct 2006 08:58:25 -0400

Three quick comments:

- I don't think it's a good idea to try to define LoST error codes in  
the document. These are currently being defined, like error behavior  
for most protocols, within the document itself. Indeed, they are  
likely to look very different from what you have in Section 10.

- For the same reason, for LoST, I see the list as being more of an  
inspiration of possible error conditions to consider than anything  
like a syntax guidance. Each protocol is also likely to have other  
error conditions or omit some that are on your list. (For example,  
the encryption ones don't make a whole lot of sense for LoST, nor do  
the by-reference ones.)

- There doesn't seem to be any way to say "I got the location data,  
but the data is invalid", such as failing civic validation or being a  
point outside the legal coordinate limits or a point above  
geostationary orbit or below the earth's center.

This may still be useful, but I would suggest simply folding these  
into the SIP conveyance draft, rather than striving for generality  
with unknown "customers". At minimum, I'd suggest restricting this to  
defining SIP Warning codes.

Henning

On Oct 26, 2006, at 8:37 PM, James M. Polk wrote:

> GEOPRIV WG
>
> I've written a new individual ID creating a registry of Location  
> specific error cause codes, to be used (mainly) by text based  
> protocols that error a message in the protocol based on something  
> wrong with the location within the message. Here is the URL:
>
> An easy example of this is Alice provides her location to Bob (say,  
> in a SIP INVITE), but his UA has a problem with the location within  
> that SIP request.  This reqistry provides a granular error cause  
> code list that can by carried in the SIP response message (in a  
> Reason header) back to Alice indicating there was a "location  
> error" with the request message, and what type of error it was.   
> Perhaps Bob only understands civic and Alice's PIDF-LO was only  
> Geo.  Perhaps Alice provided an incomplete location, or two  
> conflicting locations or something else that was wrong with the  
> This registry is NOT limited to SIP, and after talking to Henning,  
> I believe this can be used for LoST, and other protocols.
>
> The intent is to have a common set of location specific error cause  
> codes to be conveyed within and across protocols so that each  
> protocol doesn't invent their own versions of error cause codes,  
> leading to interoperability/confusion by elements attempting to  
> figure out what actually happened.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Oct 2006 09:34:29 -0400

I agree with James.

We have a number of protocols that have location in them.
There is a class of errors that are common with respect to the location
components
We should have common errors among all the protocols that use location

This doesn't mean that every protocol won't have other errors that are
protocol specific, it just means that if you get a location that is
erroneous in some way, all the protocols have the same definition of what
the error means.

As nearly every protocol of interest here uses numeric error codes with
explanatory strings, I think specifying the code and the string is
appropriate.  Agree that we shouldn't get into any other syntax issues.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, October 27, 2006 8:58 AM
> To: James M. Polk
> Cc: [email-masked]
> Subject: Re: [Geopriv] New ID on Location specific Error cause codes
> 
> Three quick comments:
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Oct 2006 10:39:36 -0400

> We have a number of protocols that have location in them.

Such as? I'm only aware of SIP conveyance and LoST. HELD, RELO and such 
use location, but most of the error conditions don't apply.

> appropriate.  Agree that we shouldn't get into any other syntax issues.

For clarity: LoST is not one of them, as you can see by looking at the 
latest draft.

Henning

---

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

Henning Schulzrinne wrote:
> This may still be useful, but I would suggest simply folding these into 
> the SIP conveyance draft, rather than striving for generality with 
> unknown "customers". At minimum, I'd suggest restricting this to 

Perhaps instead of an IANA registry, what we need is just a BCP or similar 
on meaningful error semantics for location conveyance protocols, and leave 
up to each protocol spec to map those semantics into their documents, 
including documenting which are not applicable.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Oct 2006 13:27:51 -0400

It's not a bad idea.  It's not as flexible as a registry, especially if you
allow private entries, but it does really meet the goals I have for the
proposal.

Brian

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Friday, October 27, 2006 1:20 PM
> To: Henning Schulzrinne
> Cc: [email-masked]; James M. Polk

---

From: Ted Hardie <[email-masked]>
Date: Fri, 27 Oct 2006 10:28:30 -0700

At 1:19 PM -0400 10/27/06, Andrew Newton wrote:
>>This may still be useful, but I would suggest simply folding these into the SIP conveyance draft, rather than striving for generality with unknown "customers". At minimum, I'd suggest restricting this to defining SIP Warning codes.
>
>Perhaps instead of an IANA registry, what we need is just a BCP or similar on meaningful error semantics for location conveyance protocols, and leave up to each protocol spec to map those semantics into their documents, including documenting which are not applicable.
>
>-andy
>

That sounds like a good idea to me; having similar semantics will make it easy
enough to map among protocols when there is a need to.
			
				Ted

---

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

>use location, but most of the error conditions don't apply.

I'm having a hard time thinking you want to create the situation in which a 
location based error coming back from the LoST server must be translated 
into a new SIP location error code "every time".  Implementors will always 
be having to update to the latest set of errors, some of which we cannot 
foresee at this time.

Having a minimum set of common error codes seems like it aids 
interoperability as well as consistency across protocols.

Diameter, RADIUS, DNS, and other protocols use location. In fact, anything 
that can carry a PIDF-LO can use location specific error codes (MEGACO, 
MGCP, etc)

Geopriv wasn't created just for SIP and LoST, and we can't assume the 
protocol list ends there.

>For clarity: LoST is not one of them, as you can see by looking at the 

well, this ID was published before the -02 version of LoST, so one can't be 
expected to keep up with the unknown

Especially since I talked to you about this earlier this month (at your SDO 
conference) and you said "...as long as the numeric error values remained 3 
digits..." you were OK with putting the LoST errors in this Registry ID.

Shifting positions this quickly is hard to keep up with at a distance, k?

---

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

At 01:19 PM 10/27/2006 -0400, Andrew Newton wrote:
>>unknown "customers". At minimum, I'd suggest restricting this to defining 
>>SIP Warning codes.
>

there is no SIP WG consensus to add these error codes to the SIP Location 
Conveyance ID, and wanting SIP to spin up a new ID will have to go through 
the SIPPING WG (months to years) and have them move it over to SIP (months 
to years) before we can have an RFC. Maybe we can be spared the second 
phase of this by the SIPPING chairs willingness to talk with the RAI ADs to 
have this RFC out of SIPPING.

Any location specific error registry doc should be in Geopriv. Are the 
geopriv chairs ready to have an individual registry RFC per protocol? 
Henning believes there will be only two, and I believe there will be more.

Further, do we want a BCP (for something that is not created yet (BTW - 
isn't that exactly NOT what an IETF BCP is supposed to be)) to explain how 
to do a location registry per protocol when we have a starting ID already 
done for the two protocols we all agree will have use for this?

I'm confused... and looking for chair guidance

---

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

>allow private entries, but it does really meet the goals I have for the

yeah, and what doc in SIP will do this? SIP Location Conveyance? How much 
longer is that going to be delayed by this addition after the BCP is 
written and the SIP chairs agree that is the right way to go?

---

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

James M. Polk wrote:
> there is no SIP WG consensus to add these error codes to the SIP 
> Location Conveyance ID, and wanting SIP to spin up a new ID will have to 
> go through the SIPPING WG (months to years) and have them move it over 
> to SIP (months to years) before we can have an RFC. Maybe we can be 
> spared the second phase of this by the SIPPING chairs willingness to 
> talk with the RAI ADs to have this RFC out of SIPPING.

So the SIP working group is ok with error codes for location conveyance, 
they just don't care to specify them?  Or do you mean to say that they've 
never been asked to even consider this?

> Henning believes there will be only two, and I believe there will be more.

Why would we have an IANA registry per RFC?  What I was trying to say is 
that each RFC would specify its own errors in its own document.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Oct 2006 14:03:12 -0400

I don't see much of a problem James.  The registry takes an RFC in geopriv.
The BCP is an RFC in geopriv.  -conveyance would have to reference the
registry (for the reason codes) making it normatively dependent on that RFC.
With the BCP, there are more words in -conveyance, but the effect on process
is exactly the same.

Don't get me wrong.  I think the registry is preferred.  If it helps, the
registry can have a short number, a one word "title" and a string.  Then any
protocol could make use of any of the columns.  For example, they could make
a 400 series error code out of 420+short_number.

Brian

> From: James M. Polk [mailto:[email-masked]]
> Sent: Friday, October 27, 2006 1:46 PM
> To: Brian Rosen; 'Andrew Newton'; 'Henning Schulzrinne'
> Cc: [email-masked]
> Subject: RE: [Geopriv] New ID on Location specific Error cause codes
> 
> into

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Oct 2006 14:59:17 -0400

My general concern is that anticipating how protocols handle errors is a 
fool's errand. Different protocols have different styles, for good 
reasons. For HTTP/SMTP-inspired protocols, 4xx-style errors make sense, 
for XML, we have real name spaces and for binary protocols, you might 
want something different yet again. Also, as is clear even for the two 
protocol examples we have, the location-related error cases are not the 
same. Just as an example, the validation response in LoST consists of 
three XML elements (valid, invalid, unchecked); there is no such 
validation in the Warning list so far and Warning headers clearly would 
have a hard time expressing the equivalent of these three XML tag lists.

It might be slightly useful to discuss "here are some location-related 
error conditions that a new protocol might want to handle". One might 
differ in opinion whether that's such a surprising or 
hard-to-reconstruct set that it warrants a standards-track (BCP) 
document, but that's more a matter of taste than engineering.

I don't want future, unknown protocols get obligated to support numeric 
error codes, a specific set of text messages or a specific set of error 
conditions. However, if the set in the draft is not meant to be 
prescriptive, I'm somewhat at a loss of why it needs to be a BCP or 
anything similar.

Just to be clear: I'm supportive of defining SIP Warning codes for SIP 
conveyance and don't care one way or the other whether this is in a 
separate document or not. I'm with Andy that anticipating whether the 
SIP/SIPPING working group would object to the inclusion of this material 
without having asked is a bit dicey. Just chopping up drafts into pieces 
can sometimes make things move faster, but doesn't have to, particularly 
if, say, SIP conveyance has a normative dependency on the SIP location 
Warnings, which it probably does.

Henning

James M. Polk wrote:
>> Perhaps instead of an IANA registry, what we need is just a BCP or 
>> similar on meaningful error semantics for location conveyance 
>> protocols, and leave up to each protocol spec to map those semantics 
>> into their documents, including documenting which are not applicable.
> 
> isn't that exactly NOT what an IETF BCP is supposed to be)) to explain 
> how to do a location registry per protocol when we have a starting ID 
> already done for the two protocols we all agree will have use for this?
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 27 Oct 2006 17:22:11 -0500

>registry (for the reason codes) making it normatively dependent on that RFC.

To be clear, are you all suggesting -conveyance have a normative dependency 
on an individual ID that no WG has accepted yet?