Dear Roni,
Thanks a lot for your comments. Here are my answers.
Document: draft-ietf-rmt-fcast-07
Reviewer: Roni Even
Review Date:2013–1–15
IETF LC End Date: 2013-1–22
IESG Telechat date:
Summary: This draft is almost ready for publication as Standard track RFC.
Major issues:
Minor issues:
1. I had some problem when reading the document about what is mandatory
to support. The distinction between what is required to be supported and
used is mentioned in section 5. Also section 3.3 discusses what compliant
implementation is, but section 5 provides the full information. I think that
it will be better to move section 5 before or at the beginning of section 3
or as part of 3.3. no need to have the information twice.
I agree. The new 3.3 section now explains the concepts, and the "mandatory to
implement" things are moved to
the "Requirements for Compliant Implementations" section.
This "compliant implementations" section is moved at the end of section 3 as
suggested by Joseph Yee.
The new ToC is therefore:
2. FCAST Data Formats
3. FCAST Principles
4. Requirements for Compliant Implementations
2. In section 3.3 “The support of GZIP encoding, or any other solution,
remains optional.” I think that support is mandatory.
You're right and there is also some confusion here between the GZIP use in
MDEnc, and the GZIP use in
Content-Encoding. It makes no sense to say GZIP is mandatory in MDEnc, and
optional in Content-Encoding.
This is now clarified in the "compliant implementations" section.
NEW item in "compliant implementations" section:
| Content-Encoding | MUST be supported. All FCAST |
| | implementations MUST support GZIP |
| | encoding [RFC1952] |
Additionally, I've moved text from Section 2.2 about Content-Length and
Content-Encoding (that includes lengthy discussion on GZIP usage)
to Section 3.3. There's now a single place to explain concepts with all
the details.
OLD item in 2.2:
o Content-Encoding: it specifies the optional encoding of the object
list, performed by FCAST. For instance:
Content-Encoding: gzip
indicates that the Object List field has been encoded with GZIP
[RFC1952]. If there is no Content-Encoding entry, the receiver
MUST assume that the Object List field is plain text (default).
The support of GZIP encoding, in addition to the plain text form,
is REQUIRED. The Content-Encoding entry MAY be used to indicate
other encoding types to support non-standard FCAST implementation
or future extended specifications.
NEW item in 2.2:
o Content-Encoding: it specifies the optional encoding of the object
list, performed by FCAST.
OLD item in 3.3:
o Content-Encoding: a string that contains the optional encoding of
the object performed by FCAST. If there is no Content-Encoding
entry, the receiver MUST assume that the object is not encoded
(default). The support of GZIP encoding, or any other solution,
remains optional.
NEW item in 3.3:
o Content-Encoding: a string that contains the optional encoding of
the object performed by FCAST. For instance:
Content-Encoding: gzip
indicates that the Object List field has been encoded with GZIP
[RFC1952]. If there is no Content-Encoding entry, the receiver
MUST assume that FCAST did not perform any encoding to the object
(default).
While doing that I realized that the Fcast-CID-Complete and Fcast-CID-ID
were not mentioned at all in the "compliant implementations" section. This
is now corrected as follows:
NEW item in "compliant implementations" section:
CID-specific Meta-data items (Section 2.2):
+-----------------------+-------------------+
| Feature | Status |
+-----------------------+-------------------+
| Fcast-CID-Complete | MUST be supported |
| Fcast-CID-ID | MUST be supported |
+-----------------------+-------------------+
Nits/editorial comments:
The following 4 comments have been resolved.
In section 5.1 at the end of first table “in-bound” should be “in-band”
In section 6 in the paragraph after the bullet points “possibly possibly”
In section 7 “This specification requires IANA to create two new registries”
I think there are three new registries.
In section 7.1 second paragraph “registry registry”
Thanks a lot for your comments.
Cheers,
Vincent