RE: new format

["Glen Zorn" <glenzorn@comcast.net>]

 [gwz] 
Actually, I've convinced myself that a) this idea was not quite baked & b) I
was wrong about making the Ext-Type field just one octet.  If we make the
Ext-Type field 16 bits in length _and_ start numbering the new attributes at
0x100, that would seem to solve a couple of problems nicely.

[BA]  Could you elaborate on the new design and the issues this would solve?


[gwz] 
Making the Ext-Type field 16 bits instead of 8 basically eliminates the
prospect of running out of attribute numbers.  Starting the Ext-Type
numbering at 0x100 instead of 1 eliminates any conflict between the extended
attribute types and existing standard attributes; because the type spaces do
not conflict and it's easy to differentiate between extended and standard
attributes encapsulated in the new format (the most significant octet is
always zero for standard attributes & never zero for extended types), this
open the possibility of including standard attributes in the new format &
getting the benefits of grouping, etc. for them as well as newly defined
attributes.  My motivation for suggesting this change is that it just
occurred to me that all these groovy new capabilities defined for the
extended attributes are nice but not especially useful (how many new
standard attributes will we define? 5? 10? 20?) unless they could be applied
to existing attributes, too.
[/gwz]


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