[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issues with draft-ietf-radext-extended-attributes-05.txt
Alan DeKok said:
"I was thinking also API's. Some systems have internal API's that
add/delete/lookup attributes based on a key. The key is (vendor-id,
attribute). The problem is that looking up traditional RFC attributes
is often done by setting vendor-id=0.
If we allow vendor-id to be zero, AND allow attributes 1..255 to mean
something new, this will cause problems for many implementations.
Using 1..255 also prevents the grouping of standard RFC attributes
into the extended-attribute format, which was one of Glens goals."
There are multiple issues here, I think:
a. Whether existing implementations will have a problem with a vendor-id
of zero, regardless of the size of the type code space, and the attribute
b. Whether the *combination* of a vendor-id of zero along with attribute
usage 1-255 can cause problems;
If we have problem a, then the fix would be to assign the IETF a non-zero
Vendor-Id; merely prohibiting attributes 1-255 would not do the trick.
If we only have problem b, then we could prohibit attributes 1-255 from
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.