eap Mailing List: RE: Re: Issue 281: Backward compatibility problem

[Bernard Aboba (aboba]

> I agree with you that the current restriction of placing NAIRealms at
> the end is not necessary.  At the same time, I am not clear what
> practical benefit your suggested grammar brings.

The "suggested grammar" is already in use, so this isn't a
greenfield design.  Unless there is a good reason, why are we
changing the separator from a comma to a NULL character?  It seems quite
unusual to use the NULL character this way.

> advantage of the current grammar is that it provides an unambiguous way
> to handle the case where the proprietary data for some reason includes
> the string "\0NAIRealms=".

To my knowledge, no existing implementation utilizes the "NAIRealms"
string, so I'm not sure why an ambiguity would exist, except perhaps
that the existing "networkid" string already serves a similar function.
However, since this is typically used to advertise a flat name such as an
SSID rather than an FQDN, I don't think this overlaps with the proposed
"NAIRealms" functionality.

> Anyhow, going forward, I see two options:
>
> 1) Leave the ABNF as it is, and make the following clarification
> (enclosed in **) to the last paragraph in 2.1:
>
> Some existing systems are known to use EAP-Request/Identity messages to
> send proprietary information to the peer.  This proprietary information
> is considered to be part of the displayable-string *(which can contain
> any octets including NULs)* in the ABNF shown above.  In other words,
> the NUL character followed by the NAIRealms list MUST be placed at the
> end.

I think this part of the spec is in conflict with RFC 3748 Section 5.1:

      This field MAY contain a displayable message in the Request,
      containing UTF-8 encoded ISO 10646 characters [RFC2279].  Where
      the Request contains a null, only the portion of the field prior
      to the null is displayed.

So RFC 3748 seems to imply that the "displayable string" is the portion
prior to the first null, not that portion prior to the last null.  That's
how current implementations operate anyway, and I don't think it's
appropriate for this specification to modify that.

> 2) Modify the grammar to allow the NAIRealms to be placed anywhere after
> displayable message.

I'd prefer this.  It's more consistent with RFC 3748, as well as existing
implementations.