At 04:00 AM 9/17/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>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!
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)
>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?
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:
>* keep it simple
I agree with this
>* wait for implementers feedback to improve the quality (and then
>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)).
>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?
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
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
