Subject: RE: [eap] Issue with draft-adrangi-eap-network-discovery-and-sele ction-00.txt

From: "Mark Watson" <[email-masked]>
Date: Tue, 9 Dec 2003 11:50:41 -0000

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:[email-masked]] 
Sent: 08 December 2003 14:41
To: [email-masked]
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
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: nagi reddy jonnala <[email-masked]>
Date: Tue, 09 Dec 2003 14:40:40 +0100

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
>
> 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.
>
> 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.
>