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
