Subject: [Geopriv] Loc-Filters: Error Codes

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Sep 2009 12:00:09 +0300

Hi all, 

as requested during the GEOPRIV virtual interim meeting conference call,
I looked at SIP Location Conveyance regarding the error codes because
there were claims that they already cover the functionality needed. I
look at the following document version: 
http://tools.ietf.org/html/draft-ietf-sip-location-conveyance-09#section
-3.3

3.4.1 Geolocation-Error Code 100 Location Not Understood
3.4.2 Geolocation-Error Code 101 Coordinate-location Format Desired
3.4.3 Geolocation-Error Code 102 Civic-location Format Desired
3.4.4 Geolocation-Error Code 103 Cannot Parse Location Supplied
3.4.5 Geolocation-Error Code 104 Cannot Find Location Information
3.4.6 Geolocation-Error Code 105 Conflicting Locations Supplied
3.4.7 Geolocation-Error Code 106 Incomplete Location Supplied
3.4.8 Geolocation-Error Code 107 Cannot Dereference
3.4.9 Geolocation-Error Code 108 Dereference Denied
3.4.10 Geolocation-Error Code 109 Dereference Timeout
3.4.11 Geolocation-Error Code 110 Cannot Process Dereference
3.4.12 Geolocation-Error Code 120 Unsupported Scheme - SIP desired
3.4.13 Geolocation-Error Code 121 Unsupported Scheme - SIPS desired
3.4.14 Geolocation-Error Code 122 Unsupported Scheme - pres desired

There is also a separate document that discusses similar error codes:
http://ftp.roedu.net/mirrors/ftp.ietf.org/internet-drafts/draft-polk-geo
priv-location-based-error-registry-00.txt
(It was created when we discussed how to relay LoST error codes.)

As the headlines already indicates these error codes refer to the
functionality when location (or a reference to it) gets sent to some
location recipient and he then responds with an error. This is a
different use case!

The error codes I would need are the following based on Section 6.3 of
http://www.ietf.org/id/draft-ietf-geopriv-http-location-delivery-16.txt.

   xmlError:  This code indicates that the XML content of the filter
      was either badly formed or invalid.
   generalLisError:  This code indicates that an unspecified error
      occurred at the LIS.
   locationUnknown:  This code indicates that the LIS could not
      determine the location of the Device.  The same request can be
      sent by the Device at a later time.  Devices MUST limit any
      attempts to retry requests.
   unsupportedMessage:  This code indicates that an element in the XML
      filter document was not supported or understood by the
      LIS. This error code is used when a filter  contains a
      document element that is not supported by the receiver.
   cannotProvideLiType:  This code indicates that the LIS was unable to
      provide LI of the type or types requested.  This code is used when
      the "exact" attribute on the "locationType" parameter is set to
      "true".
   notLocatable:  This code indicates that the LIS is unable to locate
      the Device, and that the Device MUST NOT make further attempts to
      retrieve LI from this LIS.  This error code is used to indicate
      that the Device is outside the access network served by the LIS.

So, why cannot we re-use these error codes? 

As an approach I would suggest to follow two principles:
* keep it simple
* wait for implementers feedback to improve the quality (and then
re-submit a new RFC updating the old one)

Is there anyone with ideas on how we can also turn the task of defining
new error codes into rocket science and spread the work over many
different IETF documents so that implementers get totally confused? 

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 17 Sep 2009 12:29:03 -0500

comments below

>location recipient and he then responds with an error. This is a

Hannes - I didn't claim the above covered every case you wanted; just 
that there seemed to be several already proposed that covered what I 
heard on the call yesterday.

when looking at the list below (that you want to include) -- I 
believe 5 out of 6 are covered already (more on this below)

>So, why cannot we re-use these error codes?

I think we need to agree on what errors need to be sent, then someone 
(you, I presume) will write that into the draft.  This can start 
simply by looking at the list above and see if there are other errors 
that are needed *or* are already in Conveyance.

For example, "locationUnknown" will likely be known when the 
SUBSCRIBE is received, meaning this can be a SIP level error, and 
isn't necessary in XML (which keeps it simple).

I don't understand the difference between "locationUnknown" and 
"notLocatable" from the list above, other than "'''MUST NOT make 
further attempts to retrieve LI from this LIS'. The difference 
between these two appears to also be covered by the current error 
codes in Conveyance - so they are clearly redundant, and therefore 
not necessary - right?

I think "xmlError" can be covered at least partly by the error 
already in Conveyance.

What's the difference between a "badly formed filter" and a filter 
that's "unsupported or understood". What's the receiver of this error 
to do with this distinction? I believe the reaction is to do the same 
thing -- omit that filter and send the rest over again. This is also 
covered by one of the error categories in Conveyance already.

By my count, I've just shown that 5 of the 6 errors above are (or 
their actionable categories are) already in Conveyance. Making me 
question the need for complicated XML errors just for 1 unique error 
code.  I find it ironic that this particular error 
"cannotProvideLiType" was bashed out of Conveyance-09 in a special 
bar-bof on Conveyance, yet being proposed here as a good idea.

>As an approach I would suggest to follow two principles:

I agree with this

>re-submit a new RFC updating the old one)

this sounds great, but we have to start somewhere, and that appears 
to be under contention -- specifically with the placement of the 
error indication (in SIP or in a message body (at least)).

>different IETF documents so that implementers get totally confused?

interesting attitude (or was that sarcasm?)... given that this 
Filters doc doesn't really work without Conveyance, does it?

Given that error indications already exist in Conveyance, why make 
things more complicated by introducing another set of error 
indications that at least partially contradict those in Conveyance, 
which are necessary.

It seems appropriate that, at least, if there needs to be two places 
for error indications (and I agree there probably are unique filter 
based errors), that the two docs would work together - and not fight 
each other on this.

That said, Conveyance has its error indications categorized into what 
the conveyer (or subscriber) is to do with the error upon receipt of 
it.  It seems to me that within those 5 actionable responses, most or 
all of the filter errors could be place as well - which could be 
placed into unique specific error codes, yet still within the same 5 
actionable categories.  I think this likely will remain true for 
errors experienced during the NOTIFY phase of location updates.

James

>Ciao
>Hannes
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 17 Sep 2009 21:24:26 -0500

Hi Hannes,

In the case that is most applicable, we should investigate whether SIP already provides equivalent mechanisms.

For instance, there is a way that a presence server can indicate the absence of a particular piece of information.  I believe that's achieved by either omitting the presence document or providing an empty presence document.  That's probably enough to cover a number of those error conditions.

That might leave a lot to be desired, but I'd rather have any problems addressed at the presence layer (i.e. 3265, 3856), rather than to provide more location-specific mechanisms.  After all, it is a more general problem.

Some of the HELD responses don't have a SIP analogue, and in others an analogue might not be necessary.  How about we identify and address specific problems instead.

My opinion is that Geolocation-Error goes too far in specifying different error codes - only those errors that are directly actionable should be included.  At its root, there is only one actionable outcome: "the location (or absence there of) in your request couldn't be used" which has an associated action of "provide another location (which might be the same with modified access permissions)".  

The additional information can rarely be used by an automated process.  My view is that defining this extra info could be useful, but it would have and should have been done as a separate effort.

But this isn't sipcore, nor do I care to further delay sip-location-conveyance.  My point is that we don't need to burden ourselves unnecessarily in our loc-filters work.

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Thursday, 17 September 2009 7:00 PM
> To: GEOPRIV
> Subject: [Geopriv] Loc-Filters: Error Codes
> 
> Hi all,
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 18 Sep 2009 09:25:15 +0300

I agree with Martin that the SIP location conveyance document has taken
already far too long and the attempt to let more functionality sneak in
is doomed to fail (given that the main parts of the spec are not even
solid). 

Additionally, I would like to point to the layer violation. Please
consider the HTTP case where errors in the application are still
answered with a 200 OK (and then with the corresponding error messages
within the application context). 

Ciao
Hannes

>From: ext Thomson, Martin [mailto:[email-masked]] 
>Sent: 18 September, 2009 05:24
>To: Tschofenig, Hannes (NSN - FI/Espoo); GEOPRIV
>Subject: RE: [Geopriv] Loc-Filters: Error Codes
>
>Hi Hannes,
>
>In the case that is most applicable, we should investigate 
>whether SIP already provides equivalent mechanisms.
>
>For instance, there is a way that a presence server can 
>indicate the absence of a particular piece of information.  I 
>believe that's achieved by either omitting the presence 
>document or providing an empty presence document.  That's 
>probably enough to cover a number of those error conditions.
>
>That might leave a lot to be desired, but I'd rather have any 
>problems addressed at the presence layer (i.e. 3265, 3856), 
>rather than to provide more location-specific mechanisms.  
>After all, it is a more general problem.
>
>Some of the HELD responses don't have a SIP analogue, and in 
>others an analogue might not be necessary.  How about we 
>identify and address specific problems instead.
>
>
>My opinion is that Geolocation-Error goes too far in 
>specifying different error codes - only those errors that are 
>directly actionable should be included.  At its root, there is 
>only one actionable outcome: "the location (or absence there 
>of) in your request couldn't be used" which has an associated 
>action of "provide another location (which might be the same 
>with modified access permissions)".  
>
>The additional information can rarely be used by an automated 
>process.  My view is that defining this extra info could be 
>useful, but it would have and should have been done as a 
>separate effort.
>
>But this isn't sipcore, nor do I care to further delay 
>sip-location-conveyance.  My point is that we don't need to 
>burden ourselves unnecessarily in our loc-filters work.
>
>Cheers,
>Martin
>
>
>> as requested during the GEOPRIV virtual interim meeting conference 
>> call, I looked at SIP Location Conveyance regarding the error codes 
>> because there were claims that they already cover the functionality 
>> needed. I look at the following document version:
>> 3.4.9 Geolocation-Error Code 108 Dereference Denied 3.4.10 
>> Geolocation-Error Code 109 Dereference Timeout
>> Is there anyone with ideas on how we can also turn the task of 
>> defining new error codes into rocket science and spread the 
>work over 
>> many different IETF documents so that implementers get 
>totally confused?
>> 
>> Ciao
>> Hannes
>>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 18 Sep 2009 10:36:00 +0300

Hi James, 
 
~snip~

>isn't necessary in XML (which keeps it simple).

Might sound simple from a protocol document writer but quite likely not
for an implementer since this is a layer violation. 

>codes in Conveyance - so they are clearly redundant, and therefore 

This is indeed the difference between the two. If it was acceptable in
the HELD specification then why isn't it here? 

>I think "xmlError" can be covered at least partly by the error 

But these are different type of XML things. We are not talking about a
PIDF-LO error or a SIP presence related error. Here we mean an error
related to the filter. 

While it appears that this is all just XML these are different specs.
Knowning where the error happened is useful 

>that's "unsupported or understood".

"badly formed filter" means that there is a problem with the XML
elements in the filter. 
This requires that you understand it to figure out whether it is badly
formed. 

"unsupported or understood" means that you don't understand an
extension. 

> What's the receiver of this error 
>thing -- omit that filter and send the rest over again.

That very much depends on the specific aspect. With badly formed you
will hardly have a chance to fix it automatically. With "unsupported or
understood" you might be able to omit the extension if it is not so
important for what you want to accomplish. 

> This is also 

SIP location conveyance should not describe errors for filters. Ideally,
the filters document should have defined errors for that matter. 

SIP Location conveyance talks about errors that the LR sends back when
it receives something. This is a different semantic about a different
object. 

>bar-bof on Conveyance, yet being proposed here as a good idea.

For whatever reason you want to move every possible functionality into
SIP Location Conveyance. 

>>As an approach I would suggest to follow two principles:

But we have a disagreement of what that means. 

>Filters doc doesn't really work without Conveyance, does it?

If the filters document does not work without sip location conveyance
then we have failed. 

>indications that at least partially contradict those in Conveyance, 

The errors do not exist in location conveyance. They are different
errors with different semantics. You can map them in some way but I
doubt that it makes a lot of sense. 

>based errors), that the two docs would work together - and not fight 

These are different errors. So, there shouldn't be a conflict between
them at all. 

There is a document that defines largely how to move location to a LR.
That's something you have to get right. 

Then, there is a presence event package with filters. When there is
something wrong with the filters then that should not impact the other
documents. 

>errors experienced during the NOTIFY phase of location updates.

I don't want to put error codes into a different document just because
of "what" (I don't even know what would be a good argument for doing
that). 

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 18 Sep 2009 19:25:06 -0500

>for an implementer since this is a layer violation.

I don't believe this is a layer violation at all.

If I subscribe to a Nokia LS for your location, the SIP SUBSCRIBE 
will either be accepted or rejected.  If it is accepted (200 OK), 
then there is an expectation that this Nokia LS has your location, or 
can get it. SIP rules state that there is an immediate NOTIFY sent to 
me from the Nokia LS with the current status of the query for your 
location. If it has your location, this first NOTIFY will send that 
to me. If not, a subsequent NOTIFY will contain your PIDF-LO.

However, if the Nokia LS knows it doesn't know your location, and/or 
knows it will never know your location - it will either blanket 
reject my subscription request (mostly based on policy), or with a 
legitimate reason why (i.e., because it doesn't know your 
location).  This will occur in the response to my SUBSCRIBE, which 
won't be a 200 OK (ever!) - because that 200 OK would mean that the 
subscription was accepted even knowing it cannot ever fulfill the 
subscription. The response would be a 4XX level rejection message - 
likely containing a GeolocationError header value, containing a error 
code indicating your location was not known.

>the HELD specification then why isn't it here?

That's not a good justification.

Further, we aren't talking about HELD, wew're talking about SIP.  Use 
SIP errors that already exist when using SIP.  It's fine to use HELD 
errors when using HELD.

>Knowning where the error happened is useful

I'll grant you that knowing the error was in the XML filters is more 
granular, but I believe those filters will be in a SIP SUBSCRIBE 
request.  Meaning the XML needs to be acceptable to accept the 
subscription, right?  (I believe the answer is yes)  Given that fact, 
this becomes a SIP level response that determines where the error 
indication should exist *because* this is the basis for accepting or 
rejecting the SUBSCRIBE.

Taking this up a higher --  what is the UAC's action you want to get 
when the UAC receives this error (regardless where it is)?  Do you 
want the UAC to

1 - resend a new SUBSCRIBE with the same filters?
2 - resend a new SUBSCRIBE with different filters?
3 - figure out what's really wrong with the filters and send those in 
a new SUBSCRIBE?
4 - not try and send a new SUBSCRIBE (i.e., give up)?

this is what I'm trying to ask that we think about (wrt what you want 
the errors to cause).

>This requires that you understand it to figure out whether it is badly

ok - then how is "badly formed filter" different from "xmlError"?

You seemed to have explained both the same basic way.

>"unsupported or understood" means that you don't understand an

What is the expected UAC reaction to receiving this error message 
(regardless of where/how it receives it)?  Do you want the UAC to

1 - resend a new SUBSCRIBE with the same filters (hoping the filter 
recipient will understand this time)?
2 - resend a new SUBSCRIBE with different filters (by changing or 
deleting the extension that wasn't understood)?
3 - figure out what's really wrong with the filters and send those in 
a new SUBSCRIBE?
4 - not try and send a new SUBSCRIBE (i.e., give up)?
5 - (this is new from above) send the same filters to another entity 
hoping it understands this/these filter extensions?

this is what I'm trying to ask that we think about (wrt what you want 
the errors to cause).

>will hardly have a chance to fix it automatically.

ok - I think you used this justification in Conveyance to just drop 
this error code because there's nothing positive to be done, so the 
UAC can't do anything about fixing the filters so why have the error at all?

not so fun to have the shoe on the other foot, is it?

>With "unsupported or

hmmm -- "...might be able to omit..." isn't really good guidance in a 
specification, so this error really should not exist either, as it 
will lead to interoperability problems with inconsistent implementations.

>the filters document should have defined errors for that matter.

I'm working with you, except... If location filters are the reason a 
SIP SUBSCRIBE request fails (from a dereference transaction), then 
this is within Conveyance's scope.

>it receives something. This is a different semantic about a different

this has me thinking  (be afraid!)

given that Conveyance is about Location Conveyance, and location can 
be conveyed indirectly (by sending a location URI instead of a 
PIDF-LO), perhaps I have the Section 4.5 message flow all wrong.

Here is Figure 4 now in Conveyance -01:

      Alice                 Location Server                      Bob
        |                                                         |
        |               INVITE w/ Location URI                    |
        |-------------------------------------------------------->|
        |                          |                              |
        |                       200 (OK)                          |
        |<--------------------------------------------------------|
        |                          |                              |
        |                          |  SUBSCRIBE to location URI   |
        |                          |<-----------------------------|
        |                          |  200 (OK)                    |
        |                          |----------------------------->|
        |                          |                              |
        |                          |  NOTIFY   w/ PIDF-LO         |
        |                          |----------------------------->|
        |                          |  200 (OK)                    |
        |                          |<-----------------------------|
        |                          |                              |

            Figure 4. Location-by-Reference and Dereferencing

But this lacks something you just (perhaps inadvertently) pointed 
out:  that the 200 OK to the INVITE means that location was received 
by Bob, when in fact Bob hasn't dereferenced Alice's location yet to 
know if he can get her location.  In other words, Bob can't error 
Alice's INVITE because of bad location information if he hasn't 
received it yet, can he?  The answer is no. Bob needs a means to be 
able to inform Alice that there was something wrong in Bob's learning 
her location. Therefore the 200 OK (or rejection) to the INVITE needs 
to move down in the flow - but I'm not sure if it needs to be after 
the 200 OK to the SUBSCRIBE or after the NOTIFY (which contains 
Alice's location (i.e., her PIDF-LO)).

I believe the Conveyance can move Bob's response to the INVITE after 
the response to the SUBSCRIBE (200 OK or an error) without 
substantial delay in call set-up, but I don't know yet if moving 
Bob's response to the INVITE after the NOTIFY will increase this too 
much.  Here's a visual of what I'm talking about with the 200 OK to 
the INVITE being after the 200 OK to the SUBSCRIBE:

      Alice                 Location Server                      Bob
        |                                                         |
        |               INVITE w/ Location URI                    |
        |-------------------------------------------------------->|
        |                          |                              |
        |                          |  SUBSCRIBE to location URI   |
        |                          |<-----------------------------|
        |                          |  200 (OK) (SUB)              |
        |                          |----------------------------->|
        |                          |                              |
        |                       200 (OK) (INV)                    |
        |<--------------------------------------------------------|
        |                          |                              |
        |                          |  NOTIFY   w/ PIDF-LO         |
        |                          |----------------------------->|
        |                          |  200 (OK) (NOT)               |
        |                          |<-----------------------------|
        |                          |                              |

(possible)  Figure 4. Location-by-Reference and Dereferencing

I'll generate a new message on the SIPCORE list asking about this 
timing issue to get feedback from the SIP savvy folks.

I'm glad you brought this up, Hannes - I think this is significant 
wrt the dereference transaction.

>For whatever reason you want to move every possible functionality into

not so, but since you are discussing a SIP based document, why do you 
want to emulate HELD in SIP - when SIP already has some of this covered?

>doubt that it makes a lot of sense.

If the errors accounted for within the filters doc can cause 
location-based errors  affecting SIP signaling, then a common ground 
needs to be reached. Much of that work is in Conveyance now.

If, however, the errors in the filters doc do not cause SIP signaling 
errors, then you are right to have them separate to Conveyance.

Can we agree to that?

>something wrong with the filters then that should not impact the other

see my point just above on this

James