eap Mailing List: RE: Issue with draft-adrangi-eap-network-discovery-and-sel ection-00.txt

[Mark Watson (mwatson]

Title: Message

Well, the text is ambiguous, so it is hard to make definitive statements about the intention. At least rfc2284bis-07 now states explicitly in the description of the Type-Data field in an EAP identity request/response:

 

"     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.  If the Identity is unknown, the
      Identity Response field should be zero bytes in length.  The
      Identity Response field MUST NOT be null terminated.  In all
      cases, the length of the Type-Data field is derived from the
      Length field of the Request/Response packet.

 

Regards,

 

Mark

-----Original Message-----
From: nagi reddy jonnala [mailto:Nagi_Reddy.Jonnala [at] alcatel.be]
Sent: 09 December 2003 13:41
To: Watson, Mark [MOP:EP10:EXCH]
Cc: 'eap [at] frascone.com'
Subject: Re: [eap] Issue with draft-adrangi-eap-network-discovery-and-selection-00.txt

Mark,

I believe it is applicable to *Identity request* as well.  See the text below.

"The length of this field is derived  from the Length field of the Request/Response packet and hence a null is not required."

I guess the intention was to recommend the use of length fileld rather than NULL in both Request and Response.

Regards
Nagi.

PS : I undetstand that RFC-2284bis-07 also makes the same assumption. I think it is better to start a new thread on this issue.
 

Mark Watson wrote:

 

Nagi,

Although it is very unclear when stated out of context, I believe the field which MUST NOT be null terminated is the Identity provided in the *response*. I understand that the displayable message in the *Request* is null terminated. It is after this displayable message in the request that we have suggested placing the network advertisement information. I believe there are already APs on the market which place some proprietary information in this space.
 

Regards...Mark

-----Original Message-----
From: nagi reddy jonnala [mailto:Nagi_Reddy.Jonnala [at] alcatel.be]
Sent: 08 December 2003 14:41
To: eap [at] frascone.com
Subject: [eap] Issue with draft-adrangi-eap-network-discovery-and-selection-00.txt

I was going through this draft to find more discussion about network discovery and selection topic.  So I ended up in this solution space issue :-)

In a couple of places, the draft appears to make the assumption that the displayable message is terminated by a null character.  Based on the assumption, It is also mentioned that Network Information MUST be placed after the null character.

RFC-2284 disagrees with this. See the below text from RFC-2284, Section 3.1 - Identity.

     "This field MAY contain a displayable message in the Request.  The
      Response uses this field to return the Identity.  If the Identity
      is unknown, this field should be zero bytes in length.  The field
      MUST NOT be null terminated.  The length of this field is derived
      from the Length field of the Request/Response packet and hence a
      null is not required."

I guess the Option-1 of  Delivery mechanism is completely ruled out. But then how can AP initiated EAP-Identity/Request message carries the network info?

Regards
Nagi.

_______________________________________________
eap mailing list
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap