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

[Vincent Roca <[e-mail]>]

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.

---
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.

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?


>> "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).


>> 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.

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].

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?


>> 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.