As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.
(1) This is to be an information RFC as is the document it is updating (RFC
5485). This is indicated in the header.
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
Technical Summary
This document provides a set of updates to the existing RFC on producing
detached digital signatures for Internet draft documents that reflect the
changes to the character sets being permitted in Internet drafts. Content
types and canonicalization rules are specified that deal with documents
containing non-ASCII UTF-8 characters.
Working Group Summary
This document is an individual submission that is being AD sponsored through
the General Area.
Document Quality
RFC 5485 has been implemented and is in regular use by the IETF today. The
changes that this document makes are very straight forward and it should be
very easy to modify the current code.
Personnel
Document Shepherd: Jim Schaad
Responsible AD: Alissa Cooper
(3) I have read through the document and sketched out the set of changes to a
hypothetical implementation. The changes from an existing signature creation
program are minimal. The changes for a validator are slightly more complicated
but still very reasonable. I provided input on several of the changes during
the writing process so it says nothing that I found to be surprising.
(4) I believe that the document has had adequate review.
(5) The document is very straight forward and does not introduce any new
issues from the base document. No particular area reviews are needed for this
document.
(6) The current document deals only with the normalization issues that are
encountered by differences between operating systems and thus does not deal
with those special problems. This is the class of problems that arises from
transferring a file from the IETF servers to a users machine. This document
does not deal with errors that can be introduced by programs which are UNICODE
aware and thus might do such operations as decomposing or composing characters
before writing the text back out again. Given that these signatures are
targeted toward dealing with archival questions I do not believe that this is
an issue.
(7) The author has confirmed that all appropriate IPR has been disclosed.
(8) There are currently no IPR disclosures filed.
(9) This document has only been reviewed by a few individuals, however that
group has no problems with the document.
(10) I am unaware of any discontent on this document. If any arises in the
future it will be on the UNICODE canonicalization issue.
(11) The document has two very minor nits - The format of the updates string
is non-standard and there is a reference which was copied from the previous
version of the document and not removed ([PDF]).
(12) No formal review criteria is needed for this document.
(13) All references are either normative or informative.
(14) All normative references have already been published.
(15) There are no downward references.
(16) This document updates RC 5485. All appropriate markers of this fact are
in place.
(17) IANA has been asked to assign new new OIDs. These are the new OIDs
defined in the text of the document with a place in the document for the newly
assigned value to be placed.
(18) No new IANA registries have been created.
(19) Document contains no formal language sections.