[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: "Barney Wolff" <email@example.com>
- Subject: RE: paradox
- From: "Glen Zorn \(gwz\)" <firstname.lastname@example.org>
- Date: Thu, 13 Jul 2006 05:51:02 -0700
- Authentication-results: sj-dkim-5.cisco.com; header.Fromemail@example.com; dkim=pass ( sig from cisco.com verified; );
- Cc: <firstname.lastname@example.org>
- Dkim-signature: a=rsa-sha1; q=dns; l=2715; t=1152795065; x=1153659065; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; email@example.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20<firstname.lastname@example.org> |Subject:RE=3A=20paradox; X=v=3Dcisco.com=3B=20h=3Do5wsf6BR3aunX3djzC+R3qJ0ZBQ=3D; b=kFDKnS2Kc6cqLNCXowrlq883adAITod/+qyY3s6O8IsQPUHMcpIXvfjCzbuPBoB4VoIBv4EX Z7GsawV2Mr7tPAoL1GN5aHnmRN96it0Y62LSCUF243/objJVv08qdcso;
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.
> 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,
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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.