Martin, Thank you for the information below. Regarding the missing reference to XML, you are correct: Given that "the principal syntax is XML", a normative reference to http://www.w3.org/TR/2008/REC-xml-20081126/ is required. This will be added to the next version of the DSKPP I-D. Andrea -----Original Message----- From: keyprov-bounces@xxxxxxxx [mailto:keyprov-bounces@xxxxxxxx] On Behalf Of "Martin J. Dürst" Sent: Tuesday, July 13, 2010 6:55 AM To: ietf@xxxxxxxx Cc: keyprov@xxxxxxxx; IETF-Announce Subject: Re: [KEYPROV] Second Last Call: draft-ietf-keyprov-dskpp (Dynamic Symmetric Key Provisioning Protocol (DSKPP)) to Proposed Standard Dear IESG, On 2010/05/27 6:48, The IESG wrote: > The IESG has received a request from the Provisioning of Symmetric Keys > WG (keyprov) to consider the following document: > > - 'Dynamic Symmetric Key Provisioning Protocol (DSKPP) ' > <draft-ietf-keyprov-dskpp-11.txt> as a Proposed Standard > > This is a second Last Call and is intended to confirm community > support for publication with respect to two specific issues: > > (1) As a result of IESG evaluation, an informative reference to RFC 2781, > "UTF-16, an encoding of ISO 10646", was changed to a normative > reference. RFC 2781 was published as an Informational RFC; the IESG > would like to determine whether the community believes RFC 2781 is > sufficiently mature for a normative downref. I'm only commenting on this point, not on point (2). RFC 2781 was done as informational mainly to make clear that the default encoding for Unicode in the IETF is UTF-16. The main thing that RFC 2781 does is point to Unicode and ISO 10646 as the definitive reference for UTF-16. RFC 2781 also defines the labels UTF-16, UTF-16BE, and UTF-16LE for labeling streams of UTF-16-encoded text. These labels come with very specific provisions for endianness and for use of the BOM (byte order mark). From the context of using 'UTF-16' in draft-ietf-keyprov-dskpp-11.txt, I think it is amply clear that this refers to text that always starts with a BOM, because otherwise, it wouldn't be well-formed XML. So I think the way this is done is fine. However, I do not think that a reference to UTF-16 (and for that, to UTF-8) was strictly needed, because these are defined indirectly by XML. On the other hand, I was VERY surprised to not find XML as a normative reference! Regards, Martin. > (2) IPR notice #332 may apply to this document, but is not explicitly > linked to this draft. Since this was not highlighted in the Last Call, > the IESG would like to determine whether this affects community > consensus. For additional information, see: > > https://datatracker.ietf.org/ipr/332/ > > 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@xxxxxxxx mailing lists by 2010-06-09. Exceptionally, > comments may be sent to iesg@xxxxxxxx instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-11.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16358&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf-announce > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@xxxxxxxxxxxxxxx _______________________________________________ KEYPROV mailing list KEYPROV@xxxxxxxx https://www.ietf.org/mailman/listinfo/keyprov _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf