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

From: Vincent Roca <[email-masked]>
Date: Wed, 29 Feb 2012 16:53:56 +0100

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 [email-masked] 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.

---

From: SM <[email-masked]>
Date: Wed, 29 Feb 2012 08:53:01 -0800

At 07:53 29-02-2012, Vincent Roca wrote:
>I didn't see you initial email (I'm not not on the [email-masked] 
>mailing list), which explains why you didn't receive any feedback.

That explains why the authors did not respond to the comments.  It 
does not explain why the working group asked the IETF Community to 
review the draft.  Or is the working group using ietf@ as a 
unidirectional transport? :-)

 From the Introduction Section:

   "This document defines FLUTE version 2, a protocol for unidirectional
    delivery of files over the Internet.  This specification is not
    backwards compatible with the previous experimental version defined
    in [RFC3926]"

The Write-up mentions that this draft represents the solid consensus 
of the working group.  It also mentions that "The document is of high 
quality and has been subject to extensive review in its Internet 
Draft and Experimental RFC forms.  The revised draft represents a 
modest set of changes from the original Experimental RFC 3926.  These 
changes are clearly described in the document".  This "modest set of 
changes" affects the IPR status of the document.  The question which 
one might ask is why do a modest set of changes then.

Regards,
-sm

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Feb 2012 22:18:20 +0100

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

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

> =>  Co-authors, do you agree?

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

> is probably too limited).

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

> well-known specification" part of the sentence, since removing it might

Such as?

>     IANA registry [IANAmediatypes].

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

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

Best regards, Julian