DIEGO LOPEZ GARCIA wrote: > 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.
IMHO, that kind of solution should be avoided. > * Chunked-Attribute must appear before the attribute it refers to in the > packet RADIUS doesn't impose ordering on attributes of different type. That's a strong reason to integrate chunking inside of the attribute format. > * 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 Why? RADIUS allows for multiple attributes of the same type, with different value. > * Non-fragmented values for this attribute can appear in any packet, but > always before the Chunked-Attribute that refers to it See comment about attribute ordering. > * As many Chunked-Attribute (and referred attributes) may appear in a given > packet as necessary. I think this document is intended to solve one *very* limited use-case. It doesn't address any more general case. It relies on fixed attribute ordering, which is explicitly not required. I gave comments on your approach. Do you have any comments on my proposed alternative? It would seem to (a) solve the same problem, and (b) have none of the limitations. Alan DeKok. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
