eap Mailing List: Re: Some (minor) editorial comments on RFC 3748b

[Henrik Levkowetz (henrik]

Hi Florent,

    You're rather impressive in your ability to see mistakes in details,
aren't you! :-)

On Thursday, 10 Jun 2004, Florent Bersani wrote:
...
> Comment #1
> 
> Section 1.2
> 
> Some entries start with a capital letter (e.g. Supplicant, Displayable 
> Message, ...) while others do not (authenticator, peer,...).
> Suggested change: adopt a constant behavior (namely start all entries 
> with a capital letter)
> 
> This capitalization problem is all the more shocking with 
> "authenticator" because this entry is written "authenticator" and in the 
> definition text we may read authenticator with a capital A ("The term 
> Authenticator is used in [IEEE-802.1X], 
> and has the same meaning in this document.")
> Suggested change: adopt a constant behavior for this term throughout the 
> document.

Proposed change:
Section 1.2, para. 2:
OLD:

   authenticator
      The end of the link initiating EAP authentication.  The term
      Authenticator is used in [IEEE-802.1X], and has the same
      meaning in this document.

NEW:

   authenticator
      The end of the link initiating EAP authentication.  The term
      authenticator is used in [IEEE-802.1X], and has the same
      meaning in this document.


> Comment #2
> 
> Section 1.2
> 
> I disagree with the RFC 3748 definition of MIC:
....

Someone else will have to take a position on this one, I can't argue
strongly either way.

> 
> Comment #3
> 
> Section 1.2
> 
> Rearrange section 1.2 with the entries sorted in alphabetical order to 
> improve readability

I'd rather not do this now...

> Comment #4
> 
> Section 5.1 2nd paragraph typo: replace "Some EAP implementations 
> piggy-back various options into the Identity Request after a 
> NUL-character" with "Some EAP implementations piggy-back various options 
> into the Identity Request after a NULL-character" (the typo is on NULL IINM)

Nope, here the name of the ASCII character is "NUL", not "NULL".  Other
places in the document the term "null" is used as a term in itself, and
then I've spelled it "null", indeed.  There's one place where I've missed
this distinction though, giving this correction:
 
Appendix A., para. 12:
OLD:
 
    o  It is now required in Section 5.1 that if the Type-Data field of
       an Identity Request contains a null character, only the part
       before the null is displayed.  RFC 2284 prohibits the Null
       termination of the Type-Data field of Identity messages.  This
       rule has been relaxed for Identity Request messages and the
       Identity Request Type-Data field may now be null terminated.
 
NEW:
 
    o  It is now required in Section 5.1 that if the Type-Data field of
       an Identity Request contains a NUL-character, only the part
       before the null is displayed.  RFC 2284 prohibits the null
       termination of the Type-Data field of Identity messages.  This
       rule has been relaxed for Identity Request messages and the
       Identity Request Type-Data field may now be null terminated.



> Hope this helps and you aren't upset by my being so particular about EAP 
> WG documents,

    Sooner (during last call, for instance :) would have been better,
but now is better than never, as far as I'm concerned.  No upsets.

        Regards,

                Henrik