[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: paradox



Barney Wolff <> supposedly scribbled:

> On Tue, Jul 11, 2006 at 10:28:52AM -0700, Glen Zorn (gwz) wrote:
>> 
>>>> Just to be clear, I don't think I've claimed that there is a
>>>> document, just that there are known methods that (slightly
>>>> extended) to deal with the problem.  Off the top of my head, RFC
>>>> 2868 specifies an (admittedly unsophisticated) method to group
>>>> related attributes together using "tags".  Although that document
>>>> only uses tags to group attributes of different types, I don't see
>>>> why a similar technique would not work with attributes of the same
>>>> type with the addition of the rule that all instances of the same
>>>> attribute with the same tag be concatenated in order.  A problem
>>>> would arise if you wanted to group long attributes with others but
>>>> I didn't think that we were talking about that...
>>> 
>>> Well yes, I suppose that would work, for long attributes restricted
>>> to ASCII printable strings.
>> 
>> Actually, I'm not sure why that restriction is necessary?
> 
> You need to know whether the first byte is a tag or not.  

I see.  I was actually thinking that we might add an real tag field to the attribute instead of stealing a byte from the payload.  This couldn't be done in RFC 2868 (on the grounds that it would be an "extension" to RADIUS & extensions were prohibited.  OTOH, this is the RADIUS Extensions WG, so maybe it would be possible now.  Perhaps we could even put in _two_ 1 octet fields to eliminate the problem with XL attributes not being allowed as members of other groups (though splitting the single octet into a couple of bit-fields would probably suffice).

> I suppose
> one could instead require that any attribute of length 253 always
> have a tag.  But in that case the actual tag is irrelevant.  

??

> So
> here's an alternative proposal for overcoming the 253 byte limit:   
> 
> If value length <253, entire value in one AVP.
> If value length >=253, first 252 bytes in first AVP, suffixed with
> ignored byte.  Repeat until the entire value has been consumed. 
> In other words, a length field of 255 becomes special, indicating
> both that the last byte of the value is to be ignored and that the
> next instance of the same attribute type is a continuation.  There is
> a backwards compatibility risk, that an old sender will generate an
> AVP with length field 255 for a 253-byte value.    
> 
> --
> Barney Wolff         I never met a computer I didn't like.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>