Re: Last Call: draft-ietf-rmt-flute-revised-13.txt (FLUTE - File Delivery over Unidirectional Transport) to Proposed Standard
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/
Re: Last Call: draft-ietf-rmt-flute-revised-13.txt (FLUTE - File Delivery over Unidirectional Transport) to Proposed Standard
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 ietf@ietf.org 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
Re: Last Call: draft-ietf-rmt-flute-revised-13.txt (FLUTE - File Delivery over Unidirectional Transport) to Proposed Standard
At 07:53 29-02-2012, Vincent Roca wrote: I didn't see you initial email (I'm not not on the ietf@ietf.org 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-rmt-flute-revised-13.txt (FLUTE - File Delivery over Unidirectional Transport) to Proposed Standard
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 ietf@ietf.org 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:
Re: Last Call: draft-ietf-rmt-flute-revised-13.txt (FLUTE - File Delivery over Unidirectional Transport) to Proposed Standard
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@ietf.org mailing lists by 2012-02-24. Exceptionally, comments may be sent to i...@ietf.org 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
