On 2/6/13 11:25 PM, SM wrote:
Hi Donald,
At 18:48 06-02-2013, Donald Eastlake wrote:
I'm not sure exactly what you mean here. The errata does appear in the
references as
[Errata191] - RFC Errata, Errata ID 191, RFC 4051, http://www.rfc-
editor.org
I have been told by an Area Director that this it the format that the
RFC Editor likes. You can certainly find the Errata starting with that
link and by just linking to the main ref-editor.org web page, it does
not constrain the other structure of that web site.
[Errata191] was a normative reference. Referencing errata in an
intended Proposed Standard might be a trivial matter. There are side
effects to that. That may only be apparent in the long term. I hope
that the RFC Editor does not plan to turn Standard Track RFCs into
"living" standards.
The format for the reference is what the RFC Editor suggests, but it
hasn't been properly documented yet. There is still open discussion
about what the appropriate URL should be which in turn impacts that part
of the reference. Having errata as normative references does not seem
like a good idea to me, so I'm glad to see it has been shifted to an
informative reference. I admit, I am unclear what you mean by turning
Standard Track RFCs in to "living" standards; think the process for
updating RFCs as new information is developed by creating new RFCs to
update or obsolete the older ones is a perfectly reasonable approach.
OK. I will move the Errata to the Informational references.
See above.
I disagree. I believe acknowledgments are very important and should be
at the front. I commonly (but not always) put them there in my drafts.
I am also not aware of any IETF rule prescribing where
Acknowledgements go in Internet Drafts. It is true that the RFC Editor
always move them to the end, but that's the way it goes.
I noticed that you are one of the rare authors who has the
Acknowledgements at the beginning of their document. It was a
practice followed in some of the three-digit RFCs. There isn't any
requirement in the RFC Style Guide which prohibits the
Acknowledgements from being at the front of the document.
Since one of the broadest guidelines we work under states "make current
RFCs look like the previous ones", we do generally put the
Acknowledgements and Contributes towards the end of the document. No,
it is not absolutely required but we do think it makes more sense. The
guidance on section ordering is something that will be discussed as part
of the revised Style Guide.
I don't know whether it is relevant but John Klensin mentioned this a
few days ago:
"One might even suggest that one of the reasons early
ARPANET/ Internet developments worked better than the IETF
process of today is that there was wide recognition that it was
necessarily a collaborative effort with many people contributing
ideas and no one wanting to seize credit."
This has been an area of personal confusion for me as I try to
understand IETF culture, but I'll leave discussing it to a bar BoF or
something.
-Heather Flanagan, RSE
Section 5 mentions that "This document requires no IANA actions".
However, there is another paragraph in the IANA Considerations section
which is not even actionable by IANA folks. I am not sure whether the
text should go into that
section.
In Section 1:
"Note that raising XML Digital Signature to Draft Standard [RFC3275]
in the IETF required removal of any algorithms for which there was
not demonstrated interoperability from the Proposed Standard
document. This required removal of the Minimal Canonicalization
algorithm, in which there appears to be continued interest. The URI
for Minimal Canonicalization was included in [RFC4051] and is
included here."
That was the historic rationale for the different levels in the
Standards Track. Rumor has it that although the rationale was
forgotten, whether intentionally or not, the "MUST" wars continued.
Dave Crocker once raised the question of complexity of a
specification. Advancement along the Standards could have been used
to make a specification less complex by trimming stuff which has not
been implemented (see quoted text above).
In Section 2.1.1:
"The content of the DigestValue element shall be the base64 [RFC2045]
encoding of this bit string viewed as a 16-octet octet stream."
RFC 4648 could be reference instead of RFC 2045.
Regards,
-sm