Subject: Re: [APPS-REVIEW] Fwd: Re: [xml-dir] XML Directorate Review Request for draft-ietf-ecrit-lost-sync-08.txt

From: Mark Baker <[email-masked]>
Date: Fri, 12 Mar 2010 18:57:58 -0500

I've had a read through the whole document now, and the only major
problem I've identified with it, which I mentioned before, is that it
uses HTTP as if it were a transport protocol.  It's particularly
problematic here because the motivating scenarios described in the
introduction seem very well suited to HTTP as designed; as a transfer
protocol.

Concretely, what I mean is that when one node wants to request
mappings from another node, it should use HTTP GET instead of
tunneling a "getMappingsRequest" request inside an HTTP POST request.
Also, the response need not contain the "getMappingsResponse" wrapper
because it will be obvious what the response is by its media type.

For similar reasons, the use of "pushMappingsRequest" is redundant;
HTTP POST *is* the correct method to use to submit data, but the
receiving node needs no more information than the URI and the set of
mappings (with media type).  And as with "getMappingsResponse", the
"pushMappingsResponse" wrapper is redundant.

This would also provide for cleaner layering between media type and
the transfer semantics, permitting the media type to evolve
independently of those semantics.  As is, the media type has two
different ways to represent the same set of mappings; wrapped with
"getMappingsResponse" and with "pushMappingsRequest".  A clear
layering violation, if ever I saw one.

I also note the draft makes no reference to BCP 56.

Note that I'm on vacation next week so won't have the opportunity to
respond to comments until the 22nd at the earliest.

Mark.