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,

First of all, I need to apologize for this very late answer.

Many of your comments have already been addressed end of Feb. However
here are the few remaining open points. I wanted to let you know before updating
the document.


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

[VR] I've been through your RFC and agree it can be used. However I'd
prefer not to change current text since it would suggest another mechanism
for carrying the filename that is not part of the current FDT Schema.


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

[VR] The XML Schema already clarifies how to behave in front of an undefined
element:

 <xs:any namespace="##other" processContents="skip"
                 minOccurs="0" maxOccurs="unbounded"/>

Basically, this is authorized and an XML validator will not try to check it.
However I have extended the text as follows:

NEW: 

   This way FDT
   provides extensibility to support private elements and 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 elements and
   attributes SHOULD be silently ignored by a FLUTE receiver.


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

[VR] As I understand, "message header field" is the appropriate term.
See below for new text.


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

[VR] We do not want to limit FLUTE extensibility. Removing "or another well-known
specification" would limit the RECOMMENDED places to define attributes to those
listed. Other SDOs (3GPP, ETSI, etc.) are not in the list. 


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

[VR] Above all, I have the feeling that adding the [IANAmediatypes] reference to:
		http://www.iana.org/assignments/media-types/
was a big mistake. I've removed it since we are not concerned here by media types
but by the message header fields. So new text is:

NEW:

   It is RECOMMENDED that the new attributes applied in the FDT are in the
   format of message header fields and are either defined in the
   HTTP/1.1 specification [RFC2616], or another well-known
   specification, or in an IANA registry [IANAheaderfield].

with:

   [IANAheaderfields]
              IANA, "Permanent and Provisional Message Header Field
              Names registries", URL: http://www.iana.org/assignments/
              message-headers/perm-headers.html, URL: http://
              www.iana.org/assignments/message-headers/
              prov-headers.html.


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

[VR] done. We are now requesting the registry of 6 items, including:
   1. Registration of the FDT Instance XML Namespace.
   2. Registration of the FDT Instance XML Schema.
   3. Registration of the application/fdt+xml Media-Type.


>>>> 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)?

[VR] this has been done a few weeks ago. Thanks for the suggestion.


Thanks a lot for your feedback.
Cheers,

   Vincent