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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
ietf@xxxxxxxx mailing lists by 2012-02-24. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]