Subject: [apps-discuss] APP Area Review of draft-ietf-ecrit-lost-sync-09

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Sep 2010 15:32:45 +0200

I have been selected as the Applications Area Review Team reviewer for 
this draft (for background on apps-review, please see 
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-ietf-ecrit-lost-sync-09
Reviewer: Julian Reschke
Review Date: 2010-09-27
IETF Last Call Date: -
IESG Telechat Date: -

Summary: This draft is almost ready for publication as an Experimental 
RFC (*) but has a few issues that should be fixed before publication

(*) The draft doesn't state the intended status, but this is what the WG 
charter says.

Major Issues:

It appears that this protocol essentially uses HTTP POST as a tunnel. As 
this also is used for *retrieval*, the message format re-invents certain 
mechanisms that are already available in HTTP (such as conditional 
requests, and state tokens). I'd like to encourage the Working Group to 
consider making the retrieval requests pure GET requests.

In LoST Sync Relax NG Schema Registration:

This registers a Relax NG schema in a registry for XML Schemas (not in 
general, but the W3C ones). I sympathize with the use of Relax NG over 
XML Schema, but this is not going to work unless we revise RFC 3688 first.

Minor Issues:

The spec doesn't seem to define ESRP and "forest", nor could I find 
those in RFC 5222 (at least no explanations).

The XML example in Figure 2 needs a namespace declaration for the prefix 
"p2".

In the examples, <displayName> sometimes uses leading/trailing 
whitespace. If this WS is supposed to be ignored, it should be stated 
(maybe this is a problem with the base format, though).

It's not clear to me why some examples use an empty <uri> element 
instead of leaving this out. Is this a funny constraint in the base syntax?

In the media type registration:

"Encoding considerations: Uses XML, which can employ 8-bit characters, 
depending on the character encoding used." - this is a bit misleading; 
did you mean to say something like "non-US-ASCII"?

"Security considerations: This content type is designed to carry LoST 
Syncronization protocol payloads." - how is that a security 
consideration? (also note the typo in "Syncronization").

In LoST Synchronization Namespace Registration:

   <meta http-equiv="content-type"
         content="text/html;charset=iso-8859-1"/>

I recommend dropping the meta/@http-equiv: (a) it's not needed, (b) 
it'll be harmful if the file actually gets served in a different 
encoding, such as UTF-16 :-)

Nits:

Section 6: did you consider using the RNC syntax instead?

IANA considerations:

For reviewers it would be easier if each section stated which registry 
is being used (with a ref to the the registration procedure RFC).

In References:

REC-xmldsig-core-20020212: [FirstEdition] obsoleted by 
REC-xmldsig-core-20080610 -- please update.

Note: I did not check all XML examples for well-formedness; I assume the 
document shepherd will do this.

Best regards, Julian