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@xxxxxxxx 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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf