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

[Adrangi, Farid (farid.adrangi]

Bernard, all

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba [at] internaut.com] 
> Sent: Wednesday, December 01, 2004 7:40 PM
> To: Adrangi, Farid
> Cc: eap [at] frascone.com
> Subject: RE: [eap] Re: Issue 281: Backward compatibility problem
> 
> 
> > Section 2.1 says:
> > "
> >    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 in the
> >    ABNF shown above.  In other words, the NUL character 
> followed by the
> >    NAIRealms list MUST be placed at the end.
> > "
> >
> > Please note the last sentence.  This means that the client 
> can always
> > start at the end of the string and extract realms until it 
> encounters a
> > "\0NAIRealms=".  Does this make sense?  Or am I missing 
> your point here?
> > BR,
> > Farid
> 
> I think you're proposing that a NULL be used as a separator.  Given
> current practice, I'm not sure why this is necessary.  Is 
> there a reason
> why an implementation couldn't just parse the data after a 
> NULL and look
> for "NAIRealms=" and then check whether the previous 
> character was a NULL
> or a comma?  This seems simple enough, and it would be 
> interoperable with
> existing implementations.
> 
> 


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.  And also, I am not
clear why the current grammar breaks interoperability with existing
implementation, and why it is not simple enough!   Please note that one
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=".   


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.   

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


My preference is (1).  It would also be nice to know other people's
opinion on this.

BR,
Farid