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(_at_)ietf(_dot_)org
[mailto:keyprov-bounces(_at_)ietf(_dot_)org] On Behalf Of "Martin J. Dürst"
Sent: Tuesday, July 13, 2010 6:55 AM
To: ietf(_at_)ietf(_dot_)org
Cc: keyprov(_at_)ietf(_dot_)org; 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(_at_)ietf(_dot_)org mailing lists by 2010-06-09. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
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(_at_)it(_dot_)aoyama(_dot_)ac(_dot_)jp
_______________________________________________
KEYPROV mailing list
KEYPROV(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/keyprov
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf