RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-00 - ErrorReporting

From: Winterbottom, James ^lt;James.Winterbottom@andrew.com>
Date: Tue Jun 19 2007 - 03:14:30 EDT

In so far as it makes sense to do this mapping I don't see a problem. I notice for example that in the current LoST specification only one HTTP error code is mapped, and this is for the Forbidden case. Is there a plan to add other mapping, say for the timeout case, to LoST also? Cheers James > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, 19 June 2007 4:46 PM > To: Cullen Jennings > Cc: GEOPRIV > Subject: Re: [Geopriv] draft-ietf-geopriv-http-location-delivery-00 - > ErrorReporting > > I'm not sure I understand your comment. As written, HELD uses 3-digit > numeric status codes that look like HTTP codes and have some > resemblance in the first digit, but otherwise have nothing to do with > the HTTP number space. I consider that another reason not to do that. > (RELO was able to avoid this by relying only on HTTP status codes, > but I digress.) > > A separate issue, left unaddressed currently, is which HTTP status > codes go along with which HELD error messages, however coded. > > On Jun 18, 2007, at 10:23 PM, Cullen Jennings wrote: > > > > > (splitting thread) > > > >> We should probably revisit some of the discussions we've had for > >> LoST, which have led us to abandon the concept of status codes in > >> favor of "real" XML. I won't repeat the arguments (Andy can chime > >> in...), but the basic idea was that this makes debugging and > >> validation easier and seems much more in the spirit of XML. Using > >> codes that are almost, but not quite, the same as HTTP (or SIP) seems > >> to be an invitation for confusion or creative extensions where HTTP > >> codes are "borrowed". > >> [MB] It does seem reasonable to consider the approach you suggest. > >> But, > >> unless someone > >> strongly disagrees, we can make that change. [/MB] > > > > Webdav has a model where some of the error codes end up in the HTTP > > response and some in an XML body. As an ex-chair of that wg, I can > > say that this was hard to get right. I'm not sure what advice to > > give but I think it is well worth careful attention to figuring out > > the semantics of if you need two places for errors, how to keep > > them from contradicting, and the semantics of what type of error > > gets reported where. > > > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.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://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 19 Jun 2007 02:14:30 -0500

This archive was generated by hypermail 2.1.8 : Tue Jun 19 2007 - 03:14:44 EDT