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:Martin.Thomson@andrew.com]
>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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] 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
>> Geopriv@ietf.org
>> 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]
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
