Subject: Comments on draft-eastlake-additional-xmlsec-uris-07.txt

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 06 Feb 2013 12:40:42 +0100

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,
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
would Obsolete RFC 4051. Just to illustrate, I did not review them all
myself.

The Abstract does not english.

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.

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.

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.

regards,
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 6 Feb 2013 21:48:15 -0500

Hi Bjoern,

Thanks for your review and comments.

See below.

> 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?

> 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

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.

> the Introduction as an exception while most other documents put it near

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.

> meant to be "xml-exc-c14n-20020718" ("enc" vs "exc"). I've not checked

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/

> 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
 [email-masked]

---

From: SM <[email-masked]>
Date: Wed, 06 Feb 2013 23:25:33 -0800

Hi Donald,
>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.

>OK. I will move the Errata to the Informational references.

See above.

>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.

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."

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 7 Feb 2013 10:37:41 -0500

Hi,

Thanks for your comments.

See below.

On Thu, Feb 7, 2013 at 2:25 AM, SM <[email-masked]> wrote:
> [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.
>
> 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.

As I say, although I frequently put them near the front of my Internet
Drafts, the RFC Editor always moves them to the end.

> I don't know whether it is relevant but John Klensin mentioned this a few
> days ago:
>

I believe there may be some legal requirement to acknowledge those
whose contributions have resulted in change in the document, unless
they ask not to be listed. Anyway, my practice is not because anyone
has asked to be listed nearer the beginning of the document but
because I think they deserve to be so listed.

> 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.

Well, I could rename Section 5 to be "Allocation Considerations" and
provide two subsection, one "5.1 IANA Considerations" and one "5.2 W3C
Allocation Considerations" or the like and perhaps also move some of
the material at the beginning of Section 2 down to 5.2.

> 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:
>

RFC4648 is Informational, so that would cause yet another downref. RFC
2045 has not bee obsoleted and seems fine to me for this purpose.

Thanks,
Donald

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 Feb 2013 17:22:56 +0100

On 2013-02-07 03:48, Donald Eastlake wrote:
> ...
> ...

Indeed. But maybe it's time to restate that the "format the RFC Editor 
likes" is sub-optimal. The format *readers* like is a link that actually 
gets you directly to the erratum.

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Feb 2013 08:52:05 -0800

On Feb 7, 2013, at 8:22 AM, Julian Reschke <[email-masked]> wrote:

> Indeed. But maybe it's time to restate that the "format the RFC Editor likes" is sub-optimal. The format *readers* like is a link that actually gets you directly to the erratum.

Further, it is probably not correct to say that the RFC Editor "likes" it, just that they got used to using it. It would be better to submit the Internet Draft with the obviously-more-useful URL and then let them make it less useful, if they want.

--Paul Hoffman

---

From: SM <[email-masked]>
Date: Thu, 07 Feb 2013 12:19:42 -0800

Hi Heather,
At 11:00 07-02-2013, Heather Flanagan (RFC Series Editor) wrote:
>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.

It does not matter that the format for the reference has not been 
properly documented as long as you know about it as I know about it. :-)

There was a discussion about errata in September 2008.  The RFC 
Editor posted a message about errata.  If I am not mistaken the 
original idea wasn't about having an erratum as a reference.  I 
suggest having a discussion on the relevant mailing list about 
whether they should be used a references.

There is a message which mentions "living" standard at 
http://www.ietf.org/mail-archive/web/ietf/current/msg75085.html  and 
the W3C angle at http://www.w3.org/QA/2012/09/the_flowing_standard.html

>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.

Well, BoFs are meetings in disguise, bar BoFs are the real BoFs. 
:-)  IETF culture is confusing for me too.  It is a bit about 
extracting sun-beams out of cucumbers.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Thu, 07 Feb 2013 17:41:48 -0800

Hi Donald,
>Drafts, the RFC Editor always moves them to the end.

I understood. :-)

>because I think they deserve to be so listed.

I like the practice.

>the material at the beginning of Section 2 down to 5.2.

The IANA Considerations will be removed on publication.  You could 
move it to 5.2 and do the above.

>2045 has not bee obsoleted and seems fine to me for this purpose.

I forgot about the Informational status.  It's easier to avoid the down-ref.

Regards,
-sm

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Thu, 07 Feb 2013 11:00:45 -0800

> 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.

-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:
>
> forgotten, whether intentionally or not, the "MUST" wars continued. 
> Dave Crocker once raised the question of complexity of a