> Old text:
>
> New attributes SHOULD NOT use this tagging method because of the
> limitations described above.
>
> New text:
>
> Where these limitations do not apply, new attributes MAY use this
> tagging method, though it is NOT RECOMMENDED. Where the above
> limitations apply, this tagging method SHOULD NOT be used.
Here is the original text of Section 2.1.2:
"2.1.2. Tagging Mechanism
[RFC2868] defines an attribute grouping mechanism based on the use of
a one octet tag value. Tunnel attributes that refer to the same
tunnel are grouped together by virtue of using the same tag value.
This tagging mechanism has some drawbacks. There are a limited
number of unique tags (31). The tags are not well suited for use
with arbitrary binary data values, because it is not always possible
to tell if the first byte after the Length is the tag or the first
byte of the untagged value (assuming the tag is optional).
Other limitations of the tagging mechanism are that when integer
values are tagged, the value portion is reduced to three bytes
meaning only 24-bit numbers can be represented. The tagging
mechanism does not offer an ability to create nested groups of
attributes. Some RADIUS implementations treat tagged attributes as
having additional data types tagged-string and tagged-integer. These
types increase the complexity of implementing and managing RADIUS
systems.
New attributes SHOULD NOT use this tagging method because of the
limitations described above.
"
How about this?
"2.1.2. Tagging Mechanism
[RFC2868] defines an attribute grouping mechanism based on the use of
a one octet tag value. Tunnel attributes that refer to the same
tunnel are grouped together by virtue of using the same tag value.
As stated in [RFC2868] Section 3.3:
The Tag field is one octet in length and is intended to provide a
means of grouping attributes in the same packet which refer to the
same tunnel. If the value of the Tag field is greater than 0x00
and less than or equal to 0x1F, it SHOULD be interpreted as
indicating which tunnel (of several alternatives) this attribute
pertains. If the Tag field is greater than 0x1F, it SHOULD be
interpreted as the first byte of the following String field.
This tagging mechanism has some drawbacks. There are a limited
number of unique tags (31). The tags are not well suited for use
with arbitrary binary data values, because it is not always possible
to tell if the first byte after the Length is the tag or the first
byte of the untagged value (e.g. where the first byte of the following
String field falls in the range of 0x00 through 0x1F).
Other limitations of the tagging mechanism are that when integer
values are tagged, the value portion is reduced to three bytes
meaning only 24-bit numbers can be represented. The tagging
mechanism does not offer an ability to create nested groups of
attributes. Some RADIUS implementations treat tagged attributes as
having additional data types tagged-string and tagged-integer. These
types increase the complexity of implementing and managing RADIUS
systems.
For these reasons, the tagging scheme described in RFC 2868 is
not suitable for use as a generic grouping mechanism. Where
a tagging scheme is required for use with arbitrary data types,
it is RECOMMENDED that:
* A fixed tagging field be used so as to remove potential
interoperability issues associated with determining whether
an optional tag is present;
* The design make no assumption about the content of the
data within tagged attributes."
|