Hi Bjoern, Thanks for your review and comments. See below. On Wed, Feb 6, 2013 at 6:40 AM, Bjoern Hoehrmann <derhoermi@xxxxxxx> wrote: > Hi, > > In http://www.ietf.org/id/draft-eastlake-additional-xmlsec-uris-08.txt > the References have to be checked and updated. For example, the document > has a normative reference to http://www.w3.org/TR/2002/WD-xptr-20020816/ > which is a "Superceded" work-in-progress that's over 10 years old. Also, Well, the reference is to the most recent document with the title "XML Pointer Language (XPointer)". After that it seems to have fissioned into a few different documents The only more recent XPointer things are only from 2003 and seem to be "XPointer element() Scheme", "XPointer Framework", and "XPointer xmlns() Scheme". What do you think this reference should point to? > it references "RFC Errata, Errata ID 191, RFC 4051" without linking the > errata item, and does so normatively even though the document as a whole 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. > would Obsolete RFC 4051. Just to illustrate, I did not review them all > myself. OK. I will move the Errata to the Informational references. > The Abstract does not english. How about the following change: OLD This document expands and updates the list of URIs specified in RFC 4051 and intended for use with XML Digital Signatures, Encryption, Canonicalization, and Key Management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051. NEW This document obsoletes RFC 4051, expanding and updating the list of URIs intended for use with XML Digital Signatures, Encryption, Canonicalization, and Key Management. These URIs identify algorithms and types of information. > I don't think it's a good idea to have the Acknowledgements precede even > the Introduction as an exception while most other documents put it near > the end. 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. > The "XCANON" reference does not work, "xml-enc-c14n-20020718" is perhaps > meant to be "xml-exc-c14n-20020718" ("enc" vs "exc"). I've not checked > other references. http://www.w3.org/TR/REC-xml-enc-c14n-20020718/ is still there from RFC 4051 which this document obsoletes. Reference should be http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/ > The document makes reference to Canonical XML 1.0 without referencing, > e.g. http://www.w3.org/TR/C14N-issues/ (and RFC 3076 does not seem to > have any Errata filed to hint at the problems with it). I'm not sure > that's a problem, but it might be better to mention the problems with > Canonical XML 1.0 in some form. Well, I would have thought that the issues in C14N-issues would be resolved in Canonical XML 1.1 which is dated later. In any case, problems in Canonical XML 1.0 seem irrelevant to this document which is just about what URIs represent what algorithms or data items. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@xxxxxxxxx > regards, > -- > Björn Höhrmann · mailto:bjoern@xxxxxxxxxxxx · http://bjoern.hoehrmann.de > Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de > 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/