Hi Alan, Diego,
Hi Alan,
On 4 Jan 2012, at 15:19 , Alan DeKok wrote:
That won't work. The type/ext-type is used to uniquely identify an
attribute. As the RFC6158 says, the interpretation of the attribute is
based solely on the type code(s). What you're doing above is changing
the meaning of the attribute based on its length.
That's difficult, if not impossible, to do correctly.
I'm afraid there is a misunderstanding. The Chunked-Atrribute is an attribute
on its own that contains only a reference to the attribute being chunked. It
has to appear in all the packets containing chunks of attributes, as many as
attributes they refer to. Chunks are intended to be encoded following the usual
encoding methods.
It is true that the layout and the field names used in it are misleading (instead of "Ext-Type" we
should call it "Type-ID" or "Attribute-ID" or something similar), and you are right in
that the way of specifying this identifier should be better aligned with the way of coding types and extended
types.
You are right. Maybe the name was not the best. We gave it 2 bytes in
order to be able to refer not only to "standard" RADIUS attributes, but
also to extended attributes. But after your explanation, I think that we
could either include both references (Type/Ext-Type, 3 bytes in total)
or just refer only to the Type (1 byte). From the point of view of
fragmentation, it could be enough to know that the attribute (e.g.
Vendor-Specific) is fragmented, no matter the kind of Vendor Specific
attribute we are dealing with.
Attributes can also occur multiple times in a packet, with different
values. e.g. Proxy-State.
You are right. That should be addressed. A simple proposal could follow these
rules:
* Chunked-Attribute must appear before the attribute it refers to in the packet
Right.
* If an attribute occurs multiple times in a request/response (we cannot speak here of
"a packet") chunks for only one of the occurrences, associated to the
corresponding Chunked-Attribute, are allowed in a given packet
I don't see why. If you find something line (CHUNKED, X, X, X, CHUNCKED,
X, X) you can easily assumed that the first [X,X,X] is one attribute
(X1) and the second [X,X] a different one (X2), as the five Xs do not
appear in sequence.
Note that this situation can only occur in the packet where the last
CHUNK of the first attribute coincide with the first CHUNK of the second
attribute.
In the example, X1 and X2 are different attributes of type X.
PACKET1: CHUNCKED, X1, X1, X1, X1, X1, X1, X1, X1, X1
PACKET2: CHUNCKED, X1, X1, CHUNCKED, X2, X2, X2, X2
PACKET3: CHUNCKED, X2, X2
* Non-fragmented values for this attribute can appear in any packet, but always
before the Chunked-Attribute that refers to it
I kinda don't like this one. We could force the inclusion of the
CHUNCKED attribute in these situations, even when no needed. Example:
CHUNCKED(type=X, total_length=200, start_pos=0, end_pos=199). As
explained above, this would insert an attribute (the CHUNCKED attribute)
between both occurrences of attribute X, thus breaking the misleading
sequence.
* As many Chunked-Attribute (and referred attributes) may appear in a given
packet as necessary.
Right, as depicted in the examples above.
Best regards,
Alejandro
If this document is published soon after the extensions document, then
it has a better likelihood of being implemented.
Good point!
Be goode,
--
"Esta vez no fallaremos, Doctor Infierno"
Dr Diego R. Lopez
Telefonica I+D
e-mail: [email protected]
Tel: +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
