Review of application/lost+xml

[Mark Baker]

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-).  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.

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