Review of application/lost+xml

[Ted Hardie]

At 2:46 PM -0500 11/22/07, Mark Baker wrote:
>On 11/13/07, Ted Hardie <hardie at qualcomm.com> wrote:
>> This is a request for review application/lost+xml, which is
>> described  in http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt .
>> Comments to the authors or the working group mailing list (ecrit at ietf.org)
>> would be welcome; cc'ing any comments to the AD (Jon Peterson,
>> jon.peterson at neustar.biz) would also be welcome since this is currently
>> also in his review queue.
>
>The media type registration itself is pretty straightforward, though
>the security considerations section needs work.
>
>I have some other comments too, while I'm here.
>
>It's unfortunate that HTTP continues to be referred to, and used as, a
>"transport" protocol.  This draft isn't as bad as some others in that
>respect, but I have some concerns.  Chief amoungst these is that LoST
>errors are returned with HTTP success status codes, which they should
>not be: even SOAP managed to get this one right 8-). 

Some further clarification on that will be coming; Jon also pointed out
the issue in his AD review.    Essentially, the HTTP responses should be
set without any reference to LoST server logic.   The redirect case is
the confusing one, since HTTP provides a redirect which might be used
where the LoST service as a whole has moved, and LoST also provides
a redirect, invoked after the recipient server has examined the
incoming LoST request. 


>Also, the names
>of the root XML elements seem to conflate data and protocol, i.e.
>"findService" and "findServiceResponse".  It's the application
>protocol that determines what constitutes a request and a response, as
>well as whether the operation is "find" or not (it's not, it's POST).
>If I were doing this, I'd use "serviceDescription" and "service" or
>something like that.  This is largely aesthetic right now, but in my
>experience such a change can prevent problems down the line, such as
>suggesting the use of new root elements for new services that might be
>added in the future, instead of the proper HTTP-friendly way, new
>URIs.
>
>More generally, I think it would be useful to show evidence that BCP
>56 has been consulted in the preparation of the HTTP binding.

We'll likely talk about this further in Vancouver; thanks for your review.

			regards,
				Ted Hardie



>Mark.
>--
>Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
>Coactus; Web-inspired integration strategies  http://www.coactus.com