[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADEXT charter for comment...
It was not clear to me (and may not be clear to other readers in the
future) that this line in the charter is intended to refer to the structure
of vendor specific attributes. In fact, in looking at 2865 for a context
for the line, the definition of VSAs was one part I assumed was not intended.
Joel M. Halpern
At 11:53 AM 3/11/2004 -0500, Nelson, David wrote:
> - Sub-attributes MUST be utilized only in a manner compatible with RFC
The relevant text from RFC 2865 is:
"It SHOULD be encoded as a sequence of vendor type / vendor length
/ value fields, as follows. The Attribute-Specific field is
dependent on the vendor's definition of that attribute. An
example encoding of the Vendor-Specific attribute using this
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Type | Length | Vendor-Id
Vendor-Id (cont) | Vendor type | Vendor length |
Multiple subattributes MAY be encoded within a single Vendor-
Specific attribute, although they do not have to be."
So the "SHOULD" (above) is being promoted to a "MUST" for work within
the scope of RADEXT, correct? Is it clear from this snippet of RFC 2865
that the nesting of sub-attributes is only one layer deep? That is my
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.