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

[Julian Reschke <[e-mail]>]

On 2012-02-29 16:53, Vincent Roca wrote:
> Hello Julian,
>
>
>>> I note that draft-ietf-rmt-flute-revised is on the agenda. Just wanted
>>> to note that I haven't seen any feedback to my LC comments on the
>>> ietf-discuss mailing list...
>
> I didn't see you initial email (I'm not not on the [e-mail] mailing list), which explains
> why you didn't receive any feedback.

Well, you don't need to be on the mailing list, but you certainly should 
scan the mailing list archives. After all, this is the place where the 
Last Call asks for feedback.

> ---
> Co-authors: there are a few comments for which I'd appreciate to have your input.
> They are prefixed with: "=>  Co-authors".
> ---
>
>>> 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).
>
> VR: The sender can freely choose a solution to convey the filename. We
> suggest to use the URI to that purpose. What you suggest (Content-Disposition)
> is an alternative. Current text seems to be appropriate in the sense that:
> 1- it only suggests one solution;
> 2- it does not close the door, and using another solution remains valid;
> I'm also a little bit confused by what RFC6266 / RFC2616 say, namely that
> Content-Disposition is not part of HTTP/1.1.

RFC 6266 has registered Content-Disposition as header field for HTTP. As 
such, it overrides anything that 2616 said about it.

That being said; it's advisory only, but I thought it might be 
worthwhile to mention.

> My feeling is to let the text as it is today. If anybody else has a different opinion...
>
>
>>> "File type, expressed as MIME media type. In the above example:
>>> "text/plain"."
>>>
>>> s/MIME media type/internet media type/
>
> VR: okay, Internet media type is indeed the appropriate term. Corrected.
>
> NEW:
>            File type, expressed as Internet Media Types (often
>            referred to as "MIME Media Types"). In the above example: "text/plain".
>
>
>>> 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.
>
> VR: We are not using MD5 message digest to protect ourselves from
> deliberate attacks, but only as a reasonable way to be confident of the
> decoded object integrity WRT transmission or FLUTE/ALC processing
> errors. The probability of message digest collision is in that case so
> small it makes sense to still use it for that purpose.
>
> Additionally, "Content-MD5" is part of the 3GPP MBMS Rel.6 specifications.
> Removing it altogether from the FLUTE-revised document would be an
> error from a backward compatibility point of view, even if we know that
> this version is not backward compatible.
>
> My feeling is to leave it as it is to minimize differences WRT to RFC3926.
>
>
>>> 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)?
>
> VR: it seems reasonable, indeed. I'd like to hear other opinions.
> What about the following text (last sentence is added)?
>
> NEW:
>           Any valid FDT Instance MUST use the above XML Schema. This way
>            FDT provides extensibility to support private attributes within the
>            file description entries. Those could be, for example, the
>            attributes related to the delivery of the file (timing, packet
>            transmission rate, etc.). Unsupported private attributes SHOULD be
>            silently ignored by a FLUTE receiver.
>
> =>  Co-authors, do you agree?

So any undefined attributes should be ignored. What about undefined 
elements?

>>> "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?
>
> VR: Sorry, I don't understand the point (my HTTP/MIME understanding
> is probably too limited).

HTTP header fields and MIME header fields are not the same thing. Pick one.

>>> Also, well-known is irrelevant, we have a registry for header fields.
>
> VR: Right. I've added a pointer to the IANA Internet Media Type registry
> and an informative reference. However I prefer to keep the "or another
> well-known specification" part of the sentence, since removing it might
> create issues.

Such as?

> NEW:
>     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, or in
>     IANA registry [IANAmediatypes].

"MIME fields" isn't a term used in the IETF. (see above).

> NEW reference:
>     [IANAmediatypes]
>                IANA, "IANA Media Types registry",
>                URL: http://www.iana.org/assignments/media-types/.
>
>
>>> 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>.
>
> VR: So we keep it as it is. That's what you mean?

No, you need to rephrase the request. You're asking for a namespace 
name, not a schema URI.

>>> 8.2:
>>>
>>> Has the media type registration been reviewed on ietf-types?
>
> VR: I cannot answer.
> =>  Co-authors, can you say what has been done (or not)?
>
>
>>> 8.3:
>>>
>>> You need to define the IANA procedure (see RFC 5226).
>
> VR: We received several comments from IANA. I'll address them all
> globally.
>
>
>>> Appendix B:
>>>
>>> The example contains a schemaLocation with a relative (URI) reference
>>> ("ietf-flute-fdt.xsd"). That's misleading, right?
>
> VR: I cannot answer (not in my field of expertise).
> =>  Co-authors, what do you suggest to address this comment?
>
>
>>> 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?
>
> VR: Done, I've added URL for these two documents, and we now refer to the
> Second Edition. I think FLUTE usage of XML Schema is simple enough not
> to be broken by the Second Edition of these documents.
>
>
>>> [RMT-SIMPLE-AUTH]: this should be cited using the default ID style, in
>>> which case xml2rfc will add the helpful "work-in-progress" label
>
> VR: my Simple-Auth document is already in the RFC Ed Queue, so it will
> soon be assigned an RFC number...
>
>
>>> Should RFC2357 be in the references?
>
> VR: It makes sense since it is referenced. Added as an Informative Reference.
>
>
>>> You may want to cite RFC3986 (URI).
>
> VR: Added as an Informative Reference.
>
>
>>> 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
>
> Thanks a lot for your detailed review. That's helpful.
> Cheers,
>
>     Vincent
>
>
> NB: I've added Rod separately to the CC list. Please keep it since his previous
> email address is no longer valid and the draft-ietf-rmt-flute-revised alias will only
> be updated after I've submitted version -14 of this I-D.

Best regards, Julian