Subject: RE: [AAA-WG]: No value strings

From: Avi Lior <[email-masked]>
Date: Mon, 9 Jun 2003 16:25:53 -0400

Hi,
Perhaps I can give you one repsonse to this. In RADIUS RFCs there are no
attributes that have zero length.  However, there are some vendors that we
know of that have zero length vendor attributes.  Therefore, to provide
backwards compatiblity with RADIUS, I would think we would need to support
such a concept.

As of being a new type, no sure.  It would appear that these attributes act
as a indication (or a flag).  The presence of an attribute is sufficient to
indicate something.  This may suggest a "flag" type or a zero length boolean
not sure.  

But there could be other uses.  Perhaps when sent by the server it indicates
something to the NAS such as measure volume.  The NAS would then return the
attribute with some value say in this case the number of octets.

Does this help?

> -----Original Message-----
> From: Murtaza S. Chiba [mailto:[email-masked]] 
> Sent: Monday, June 09, 2003 2:59 PM
> To: [email-masked]
> Subject: [AAA-WG]: No value strings
> 
> 
> Hello,
> 	The current version of the base protocol defines that 
> an attribute may 
> have 0 or more data bytes.  Wanted to understand the need for an 
> attribute with no value and should it be a new type something 
> other than 
> string?  Is an attribute with no data still a string?  Maybe it is 
> better to define a new type for no data?
> 
> Thanks,
> Murtaza
> 
>

---

From: "Murtaza S. Chiba" <[email-masked]>
Date: Mon, 09 Jun 2003 14:06:16 -0700

Not really, my problem is how to ensure a correct value is being sent as 
opposed to a missing value?  Maybe a distinction between 0+ and 1+?

---

From: Jari Arkko <[email-masked]>
Date: Tue, 10 Jun 2003 00:12:21 +0300

> opposed to a missing value?  Maybe a distinction between 0+ and 1+?

That, and following the content rules for the given attribute.

--Jari