Draft:  draft-josefsson-rfc3548bis-02
Reviewer: Elwyn Davies [elwynd@dial.pipex.com]
Review Date:  Monday 4/10/2006 4:46 AM
IETF LC Date:  1 May 2006

Summary: This is almost ready for PS.  I suspect (but don't know on account of 
not being an IPR lawyer) that, in trying to do the 'right thing', the 
author may have created an impossible (or maybe just excessively 
complicated) copyright position regarding the code in s11.  The document 
now contains three different statements that are intended to apply to 
the code: BCP78, the GNU copyright statements embedded in the code and 
s15. Help!

Aside from this there are a couple of minor issues (below) and a number of
editorial fixes that would be desirable.

Minor issues:
s11/s15: potential IPR (statement) issue: Is there any interaction
between the overall BCP78 copyright position, the GNU copyright
positions mentioned in the code sections and the author's statements in
s15?  BCP78 seems to indicate that s11 could be freely copied and
wouldn't need any copyright statements.

s3.4, last para:
> In this document, we document and *name* some currently used alphabets.
Names are not explicitly given to all the alphabets.

s11: Would be worth noting that it is assumed that the encoded input has
been stripped of embedded line feeds (if the specification needs them)
before applying the decoding functions.

s3.3, 2nd para:
> Furthermore, such specifications may
> consider the pad character, "=", as not part of the base alphabet
> until the end of the string.  If more than the allowed number of pad
> characters are found at the end of the string, e.g., a base 64 string
> terminated with "===", the excess pad characters could be ignored.
I wasn't absolutely sure what was intended here.  I think this could be
improved (If this is not the sense that is intended than it should be
'differently' improved):
Furthermore, such specifications MAY consider the pad character, "=", as
not part of the base alphabet when found at the end of a string of
encoded data.  In this case if more than the allowed number of pad
characters are found at the end of the string, e.g., a base 64 string
terminated with "===", the excess pad characters MAY be ignored.


Editorial:

General: Consistent Capitalization of Section Titles is required.

s3.3: Consistent use of 'non-alphabet' rather then 'non alphabet' - 4
instances in the body.

General: Several instances of '(non-)alphabet' s/b '(non-)alphabetic':
including Abstract (1st instance), s1 (both instances), s3.3 (title,
2nd, 3rd and 4th instances in para 1 and 3rd instance in para 2), s11.1
(comment before function base64_decode), s12 (1st instance in para 2.

s1: Expand MIME acronym
s3: Expand PEM acronym.

s3.2: Useful to point to sections which tell how much padding (ss4 and 6).

s3.3, para 2, 1st sentence: s/reject the encoding/reject the encoded data/
s3.3, 2nd para:
Need to expand the CRLF acronym.('adjacent carriage return/line feed
(CRLF) characters')

s3.4, bullet 1: s/are easily interchanged, as well/are easily confused,
as well as/, s/is not present/are not present/

s3.4, bullet 2: s/place/mandate/

s4, s6, : s/a single digit in the xxx alphabet/s single character in the
xxx alphabet/

s4, s6 and s7, para 1 in each case: s/due to/is derived from/

s4, para 2: I think 'requires case sensitivity' is not the right
phrase.  I take it it should be something like 'allows the use of both
upper- and lowercase letters' or 'preserves case sensitive encodings'.

s5: s/understrike/underscore/