RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

["David B. Nelson" <d.b.nelson@comcast.net>]

Glen Zorn writes...

>    M (More)
> 
>       The More Flag is one (1) bit in length and MUST be present.  When
>       a value to be transmitted exceeds 246 octets in length it is
>       fragmented over two or more Extended Attributes.  If the More Flag
>       is set (1), this indicates that the Value field of the Extended
>       Attribute contains a fragment of a larger value, which is
>       continued in the next Extended Attribute of the same Ext-Type.
>       When the More Flag is clear (0), the final (or only) fragment of
>       the value is contained in the Extended Attribute.  Any Extended
> 	 Attributes containing multiple fragments of the same value MUST be
> 	 in order and MUST be consecutive attributes in the packet.

It's the last sentence that I claim adds new requirements to RADIUS.  This
is not required for EAP-Message Attributes, nor any others that I'm aware
of.  I'm stopping short of claiming that this new requirement isn't backward
compatible.  I can easily envision implementations where this would not be
any sort of burden to enforce.  I'm just wondering if there are any
implementations where it would be a burden?  I also see the advantage in
terms of ease of implementation of parsing and reconstruction.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>