Subject: RE: (radius) Zero-length strings

From: "Beadles, Mark A." <[email-masked]>
Date: Thu, 25 Feb 1999 16:27:20 -0500

From: Glen Zorn [mailto:[email-masked]]
>So therefore the only
>> possible choice is to EITHER allow a NAS to send a null attribute, or to
>> allow that it NOT SEND an attribute that is otherwise required by the 
>> protocol.  So I would say that zero-length attributes are in.
>
>I disagree.  Given a choice between a bad hack to work around a protocol
>deficiency and fixing the protocol, I'd pick the latter every time.

OK, fine, I'm easy.  Therefore the protocol must allow packets that 
do not contain User-Name and User-Password attributes, if the user
sends empty strings to the NAS.  I'm just saying you can't have it both
ways; we can't design the protocol so that the NAS has to decide policy.

+ Mark Anthony Beadles +       MCI WorldCom      +
+  [email-masked]   +    http://www.wcom.net  +
+  Voice 614.723.1941  +      Fax 614.723.8407   +

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Heath Partington" <[email-masked]>
Date: Thu, 25 Feb 1999 16:38:32 -0500

It sounds to me like there are some valid reasons for sending an attribute
length of 2 (username) and some reasons that don't sound valid at all.
Doesn't sound like the RFC can/should exclude it. Perhaps a note regarding
what makes sense when we say that an attribute length of 2 is valid.

>     -----Original Message-----
>     From: [email-masked]
>     [mailto:[email-masked]]On Behalf Of Beadles, Mark A.
>     Sent: Thursday, February 25, 1999 4:27 PM
>     To: 'Glen Zorn'
>     Cc: 'Richard S. Conto'; Dale E. Reed Jr.; [email-masked];
>     Carl Rigney
>     Subject: RE: (radius) Zero-length strings
>
>

-

---

From: Glen Zorn <[email-masked]>
Date: Thu, 25 Feb 1999 13:50:33 -0800 (PST)

> ways; we can't design the protocol so that the NAS has to decide policy.

Agreed.

-