Subject: Re: Last Call: <draft-ietf-rmt-flute-revised-13.txt> (FLUTE - File Delivery over Unidirectional Transport) to Proposed Standard

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Feb 2012 20:49:57 +0100

On 2012-02-11 01:48, The IESG wrote:
>
> The IESG has received a request from the Reliable Multicast Transport WG
> (rmt) to consider the following document:
> - 'FLUTE - File Delivery over Unidirectional Transport'
>    <draft-ietf-rmt-flute-revised-13.txt>  as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2012-02-24. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> ...

Here are a few comments, mainly of editorial nature:

Below my review notes; just mechanical checks, and some checks on the 
relation to HTTP header fields...:

Section 3:

"File name (usually, this can be concluded from the URI). In the above 
example: "file.txt"."

...or the Content-Disposition header field (RFC 6266).

"File type, expressed as MIME media type. In the above example: 
"text/plain"."

s/MIME media type/internet media type/

3.4.2:

"Where the MD5 message digest is described, the attribute "Content-MD5" 
MUST be used for the purpose as defined in [RFC2616]."

Note that Content-MD5 is gone from HTTPbis.

XML-Schema: I believe the spec should state what to do with invalid 
input. Are there extension points (like ignoring unknown elements in 
extension namespaces)?

"It is RECOMMENDED that the new attributes applied in the FDT are in the 
format of MIME fields and are either defined in the HTTP/1.1 
specification [RFC2616] or another well-known specification."

As this is a normative requirement it needs to be clarified what header 
fields are used? HTTP? MIME?

Also, well-known is irrelevant, we have a registry for header fields.

8.1:

Actually, what's requested is a URN for the XML namespace 
("urn:ietf:params:xml:ns:fdt"). That's fine; I don't think the XML 
schema needs to be registered. Otherwise, see 
<http://tools.ietf.org/html/rfc3688#section-3.2>.

8.2:

Has the media type registration been reviewed on ietf-types?

8.3:

You need to define the IANA procedure (see RFC 5226).

Appendix B:

The example contains a schemaLocation with a relative (URI) reference 
("ietf-flute-fdt.xsd"). That's misleading, right?

References:

Please cite W3C spec with their full details, like this:

<http://greenbytes.de/tech/webdav/rfc2629xslt/w3c-references.html#ref-REC-xmlschema-1-20010502>

Speaking of which; shouldn't you cite the Second Edition?

[RMT-SIMPLE-AUTH]: this should be cited using the default ID style, in 
which case xml2rfc will add the helpful "work-in-progress" label

Should RFC2357 be in the references?

You may want to cite RFC3986 (URI).

Formatting: I note that in-document links haven't been generated using 
xml2rfc's linking features; this way references to section numbers can 
break easily. I did not check those.

Best regards, Julian