Re: [Geopriv] Loc-Filters: Error Codes

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

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


>-----Original Message-----
>From: ext Thomson, Martin [mailto:[e-mail]] 
>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
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] 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,
>> 
>> 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
>> 
>> _______________________________________________
>> Geopriv mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/geopriv
>
>---------------------------------------------------------------
>---------------------------------
>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]
>