Subject: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Aug 2008 19:06:24 -0700 (PDT)

This is a reminder of the RADEXT WG Last Call on "Extended 
RADIUS Attributes", prior to requesting that the IESG publish it as a Proposed Standard. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt
 
WG Last Call was originally to have completed on August 10, 2008.   
However, due to lack of response to the RADEXT WG last call, 
we will be extending the WG last call to August 31, 2008.  Please 
review the document and post your comments to the RADEXT WG mailing list 
([email-masked]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Aug 2008 11:28:01 +0200

> RADIUS Attributes", prior to requesting that the IESG publish it as a Proposed Standard. 

Submitter name: Alan DeKok
Submitter email address: [email-masked]
Date first submitted: Aug 14 2008
Reference:
Document: [EXTEN]
Comment type: T
Priority: 2

Section 4:
...
   o  The final octet of the header contains the More flag and Tag
      field.  If the one bit More flag is set (1) this indicates that
      the encapsulated TLV is continued in the following Extended
      Attribute; if the More flag is clear (0) then all of the
      encapsulated TLVs fit into the current Extended Attribute.  The
      More flag MUST NOT be set if the Extended Attribute contains more
      than one TLV.

  To be clear: this means that the Extended-Attribute can encapsulate
multiple TLV's if they're short, or only one TLV if it's long.

Section 5:

   M (More)

      The More Flag is one (1) bit in length and MUST be present.  When
      a value to be transmitted exceeds 246 octets in length it is
      fragmented over two or more Extended Attributes.  If the More Flag
      is set (1), this indicates that the Value field of the Extended
      Attribute contains a fragment of a larger value, which is
      continued in the next Extended Attribute of the same Ext-Type.

  Can we add a MUST?  i.e. If the More Flag is set, the next attribute
MUST be an Extended-Attribute of the same Extended-Type.

  Inserting *other* attributes in between a fragemented attribute is
annoying and pointless.  It's better to forbid this, and to declare that
packets failing this test are malformed, and SHOULD be silently discarded.

   Ext-Type

      Two (2) octets.  Up-to-date values of the Ext-Type field are
      specified in the most recent "Assigned Numbers" [IANA].  Values
      XXXX-YYYY are reserved.

  I would suggest reserving the top 1K: 64512-65535

6.  Examples

   Consider an attribute called Foo of type String.  Foo has been
   allocated an Extended-Type 0f 257 by IANA.  The following figure
   shows the encoding of Foo(0,4) = "Hello":

  What does "Foo(0,4)" mean?  This is the first reference in that
document to that attribute naming scheme.  (I presume it's an attribute
naming scheme).  Why not just refer to it as "Foo"?

  The diagram also has Ext-Type (16 bits) of 257 split between two bytes
(8 bits) of 0 and 257.  I welcome the novel ability to count to 257 in
an 8-bit field, but perhaps this could be corrected. :)

  The examples should use numbers from the reserved space (i.e. 64512),
and not from the IANA allocated space (257).  The examples also use the
attribute name "Foo" multiple times.  It should instead use unique names.

   Figure 2 below
   illustrates the encoding of the first 7 octets of the first Extended
   Attribute (Foo(0,6) = "Hello W"), while Figure 3 shows how the second
   attribute (Foo(246,250) = "e end.") is encoded.

  Hmm... So Foo(N,M) is a reference to the fragments?  I don't see why
this is necessary.  We don't do it for EAP-Message.  I would suggest
just referring to it as "Foo", and "the first fragment (octets 0 through
245)", and "the second fragment (octets 246 through 250).

...
   Consider the following structure:

     struct
       Integer a;
       String  b;
       Integer c;
     endStruct

  What syntax is this?  I think I understand it, but I'm not sure
everyone will come to a shared understanding.  Maybe instead the example
can be given by reference to existing RADIUS data types.  e.g. A
structure of RADIUS data types (integer, text, integer) would previously
have to be encoded as three separate and independent attributes.  Here,
it can be encoded as 3 attributes sharing a common tag.

  Reading the rest of the example, I find the b(4,5) syntax very
awkward.  I suggest discarding it, and just referring to the diagrams.

  The examples could also given broken-out hex encoding of the
attributes, which may be clearer than the ASCII art diagrams.  e.g.

  1a 0f 00 00 00 00 00 01 01 08 48 65 6c 6c 6f

7.  Security Considerations

   I suggest adding a note that a new attribute encoding is an
opportunity for buffer overflows, inadequate checks, etc.  Implementors
SHOULD take care to validate the lengths, etc. before decoding the
contents of the attributes.

8.  IANA Considerations
...
   It also requires that IANA set up a new registry for the RADIUS
   Extended Attribute Types.

  I suggest leaving the first 0..255 attributes as unallocated, in order
to avoid confusion with legacy RADIUS attributes.

9.  Open Issues

   What is the numbering scheme for attributes that will be used by RFC
   writers going forward?  For example today we write user-name(1).

  Uh... We do?  I've never seen that in an RFC.  I suggest deleting this
section entirely.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Thu, 14 Aug 2008 11:56:39 +0200

Hello,

a few comments:

TLV encoding and M flag: All examples stuff the maximum payload into the first fragment, set the M bit and put the remainder into the next fragment. This is fine and sensible, but not enforced in the description.
One might also do any other split of the data, like if there is a 300 byte data to be transmitted, 150 in the first fragment, 150 in the second.
There also is no clarification whether fragmenting should only occur when it is needed. Without requiring this, a compliant implementation could as well split the 5-byte data "Hello" into five fragments. I suggest to add a bit of wording to strongly discourage that.

TLV encoding rules: Ext-Length field misses its unit ... (in octets)...

Example in Figure 3: VSA Length. 7 + 9 = 16, not 15.

Figure 4: 

- is it worth mentioning that this encoding is not the only one possible, since the order of the struct members doesn't need to be preserved during marshalling? 

- There is a one-off in the encoding of String b. b is 251 octets, i.e. comprised of b[0] thru b[250].
The first fragment can (correct in the figure) hold up to 245 characters, i.e b[0] thru b[244]. Six(!) characters remain, b[245] thru b[250]. The encoding of the second fragment needs to be changed for a TLV data length of 6, which also changes Ext-Length to 3 + 6 = 9 and VSA-Length to 7 + 9 + 7 = 23. The byte-order of the last integer is odd, it looks like the last two bytes are swapped. This is neither big- not little-endian, and I suspect it's an error.
A corrected figure is below:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type (26)   |    Length     |          Vendor-Id
   |               |  (7+9+7=23)   |             (0)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)        |M|    Tag      |    Ext-Type
                 (0)               |0|    (42)     |      (0)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Ext-Type (cont)|   Ext-Length  |     Value     |               |
         (259)     |   (3 + 6 = 9) |      (e)      |      ( )      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |               |               |    
   |      (e)      |      (n)      |      (d)      |      (.)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Ext-Type (cont) Ext-type (cont)|   Ext-Length  |               |
         (0)             (271)     |   (3 + 4 = 7) |    (0x12)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |               |               |
   |    (0x34)     |     (0x56)    |     (0x78)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Some nitbits: 

- Intro: "101 or so have been". Or so sound a bit colloquial.
- first example: "Extended-Type *of* 257 by IANA." ( not 0f)

Finally, Security Considerations: This section is rather short, I suggest to expand the "TBD" :-)

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Thu, 14 Aug 2008 12:07:35 +0200

> A corrected figure is below:

Oh well. Add a line-break at the obvious place.

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Aug 2008 12:39:28 +0200

Stefan Winter wrote:
> One might also do any other split of the data, like if there is a 300
> byte data to be transmitted, 150 in the first fragment, 150 in the second.
> There also is no clarification whether fragmenting should only occur
> when it is needed. Without requiring this, a compliant implementation
> could as well split the 5-byte data "Hello" into five fragments. I
> suggest to add a bit of wording to strongly discourage that.

  I would say:

  The More Flag MUST NOT be set if the Length is less than 255.

> - is it worth mentioning that this encoding is not the only one
> possible, since the order of the struct members doesn't need to be
> preserved during marshalling?

  Yes.  Attributes don't have order in RADIUS.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 14 Aug 2008 18:10:19 +0700

Stefan Winter <mailto://[email-masked]> writes:

> Hello,
> 
> a few comments:
> 
> TLV encoding and M flag: All examples stuff the maximum payload into
> the first fragment, set the M bit and put the remainder into the next
> fragment. This is fine and sensible, but not enforced in the
> description.

Maybe just put a note like "If you are a total moron, stop reading now." in
the Abstract?

...

> suggest to expand the "TBD" :-)

Text is welcome.

...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 14 Aug 2008 13:32:59 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Glen Zorn
> Sent: Thursday, August 14, 2008 2:10 PM
> To: 'Stefan Winter'
> Cc: [email-masked]
> Subject: RE: REMINDER: RADEXT WG Last call on "Extended 
> RADIUS Attributes"
> 

...

> Maybe just put a note like "If you are a total moron, stop 
> reading now." in the Abstract?
> 
> ...

There certainly should be some other ways to say it. 

Dan

---

From: Stefan Winter <[email-masked]>
Date: Thu, 14 Aug 2008 13:40:56 +0200

Hi,

> There certainly should be some other ways to say it. 

Alan's wording "The More Flag MUST NOT be set if the Length is less than 
255." sounds good to me.

Stefan

-- 

Stefan WINTER
Ingenieur de Recherche

Tel: +352 424409 1
Fax: +352 422473

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 14 Aug 2008 13:27:42 -0400

Alan DeKok writes...

>   Inserting *other* attributes in between a fragemented attribute
> is annoying and pointless.  It's better to forbid this, and to 
> declare that packets failing this test are malformed, and SHOULD
> be silently discarded.

I think this would introduce a new, non-backwards-compatible requirement.
Today, RADIUS requires that attributes of the same type not be re-ordered in
the PDU, e.g. by proxies. There is no such requirement for attributes of
differing types.

>   What does "Foo(0,4)" mean?

I suppose it means the TLV with Type Code 4, assigned within the IETF
allocation, i.e. Attribute 26, Vendor-ID 0.

Why not just refer to it as "Foo"?

There is a long-standing typographical tradition of listing attributes as
Attribute-Name (##).

>   What syntax is this?

Pseudo-code?  Maybe actually using ANSI C would be more universal.  I think
the RADIUS data types are not a good way to express this concept, as
witnessed by confusion in various drafts over the years. 

> awkward.

I think that's part of Glen's [potential] issue.

> opportunity for buffer overflows, inadequate checks, etc. 
> Implementors SHOULD take care to validate the lengths, etc. 
> before decoding the contents of the attributes.

How is that different from good coding guidelines for *any* implementation
of *any* protocol?  What about the on-the-wire protocol involved raises
these risks?

>   Uh... We do?

Yes, we do.  I can cite numerous examples.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 15 Aug 2008 00:33:40 +0700

> Alan's wording "The More Flag MUST NOT be set if the Length is less

My point was that making these kinds of rules is pointless: if someone wants
to split "Hello" into 5 separate attributes they either have a very good
reason to do so that none of us can foresee or they will soon be finding
gainful employment in a different field.  In any case, it's not possible to
protect people from their own stupidity (besides, they could still do it
with tags).

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Aug 2008 20:36:58 +0300

Bernard,

why is there is a working group last call on this document given that it 
still has an open issue section giving me the impression that the 
document is far from being ready?

Ciao
Hannes

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Aug 2008 21:23:32 +0200

> the PDU, e.g. by proxies. There is no such requirement for attributes of

  That's not *quite* what I meant.

  What I meant was interspersing attributes of disparate types.  I'm not
aware of any implementation that does this (e.g. for EAP-Message).  But
I've learned to be paranoid about RADIUS specifications.

> allocation, i.e. Attribute 26, Vendor-ID 0.

  Nope.  Read the rest of the doc.  It means "octets 0 through 4 of
attribute Foo".

> There is a long-standing typographical tradition of listing attributes as

  References?

[ struct ]
> witnessed by confusion in various drafts over the years. 

  I'm just asking for a definition of the terminology and concepts
referred to in the draft.  What's an "Integer", or a "String"?  Do these
relate to C definitions?  RADIUS?

> of *any* protocol?  What about the on-the-wire protocol involved raises

  Er... nothing.

> Yes, we do.  I can cite numerous examples.

  Where?

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Aug 2008 21:26:52 +0200

> protect people from their own stupidity (besides, they could still do it

  It's only one sentence.  And it will stop the stupid people from
afflicting everyone else.

  RFC 2865 has comments saying:

      The secret MUST NOT be empty (length 0) since this would allow
      packets to be trivially forged.

  Which were inserted because of real-world exposure to implementations
having *no* configuration for shared secrets. (i.e. they were always NUL).

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 14 Aug 2008 15:47:23 -0400

> > Yes, we do.  I can cite numerous examples.

Section 7.1 of RFC 2865.  Section 2.1 of RFC 3580.  Section 2.2 of RFC 5176.
Section 2.1.1 of RFC 5080.  Section 6 of RFC 5090.

This is not an exhaustive list, but rather a sampling.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 15 Aug 2008 13:49:14 +0700

> the PDU, e.g. by proxies. There is no such requirement for attributes

I believe that he meant that all fragments of a given attribute must be
contiguous in the original packet...

> allocation, i.e. Attribute 26, Vendor-ID 0.

This would be a perfectly reasonable interpretation, but it actually means
"octets 0-4 of attribute Foo".

...

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 15 Aug 2008 17:10:33 +0700

> document is far from being ready?

1) As you know, the issues list is not an official WG document, but a tool
for the use of the Chairs & as such its state has no bearing on the status
of a document.
2) All 3 of the issues assigned to the extended attributes document appear
to actually refer to RFC 5080.

---

From: "Greg Weber" <[email-masked]>
Date: Fri, 15 Aug 2008 09:44:51 -0400

> to actually refer to RFC 5080.

I suspect Hannes was referring to the open issues section in the draft's
text,
not the list maintained by the chairs.  Regarding the latter, the issue that
I
filed (#250) was intended for your -00 draft, not RFC 5080.  I haven't read
your current draft version yet to see if these comments were addressed;
there was no response on the list -that I recall.

Greg

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 15 Aug 2008 22:01:38 +0700

Greg Weber [mailto:[email-masked]]  writes:

filed (#250) was intended for your -00 draft, not RFC 5080.  

Be that as it may, the link points to an issue raised by Bernard re: the
Fixes draft.

I haven't read 

Probably not, since it was an individual submission & last time I checked
the authors of such have no obligation to respond to the WG, which in turn
has no control over the work.  

Greg

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 15 Aug 2008 22:50:31 +0700

.

I haven't read 

Of course, since the draft is now a WG item I'd love to address your
comments (if I could only see them ;-).

.

---

From: "Greg Weber" <[email-masked]>
Date: Fri, 15 Aug 2008 12:00:59 -0400

On Fri, Aug 15, 2008 at 11:50 AM, Glen Zorn <[email-masked]> wrote:

>     …

These were my comments on the -00 WG draft:
  http://ops.ietf.org/lists/radiusext/2008/msg00095.html
Not sure if these have been addressed or obviated by now- or if they
were originally valid...

Greg

> …

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 15 Aug 2008 23:07:50 +0700

Alan DeKok <mailto://[email-masked]> writes:

...

> multiple TLV's if they're short, or only one TLV if it's long.

OK, are you saying that the existing text isn't clear?  It seems pretty
precise to me, should it be more vague (e.g., "long" & "short")?

> MUST be an Extended-Attribute of the same Extended-Type.

Fine

...

>   I would suggest reserving the top 1K: 64512-65535

Rationale?

...

> have to be encoded as three separate and independent attributes.  

Previously, such a structure was impossible to encode in RADIUS.

> Here,

Or as 3 TLVs in a single attribute (depending upon the length of the string.

> awkward.  I suggest discarding it, and just referring to the diagrams.

Actually, I'd just as soon discard the examples: this draft has way too much
flavor of a tutorial for my taste...

>   1a 0f 00 00 00 00 00 01 01 08 48 65 6c 6c 6f

You're joking, right?

> to avoid confusion with legacy RADIUS attributes.

Presumably the people who would get confused are those who have to be told
to protect against buffer overflows (& send "hello" as five separate
attributes), right?

...

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 15 Aug 2008 23:42:20 +0700

Stefan Weber <maito://[email-masked]> writes:

...

> TLV encoding rules: Ext-Length field misses its unit ... (in octets)...

OK

> Example in Figure 3: VSA Length. 7 + 9 = 16, not 15.

OK

...

> - first example: "Extended-Type *of* 257 by IANA." ( not 0f)

OK

...

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 15 Aug 2008 23:59:37 +0700

Alan DeKok [mailto:[email-masked]] writes:

>   It's only one sentence.  

A sentence here, a sentence there & pretty soon you're outlawing driving
while blindfolded (http://www.whatcar.com/news-article.aspx?NA=229117)...

> And it will stop the stupid people from

No, they can still do it (even more stupidly) with tags...

> having *no* configuration for shared secrets. (i.e. they were always

That may be stupid, or not, depending upon the level of other security in
the network...

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 16 Aug 2008 00:01:35 +0700

.

I haven't read 

Thanks!

were originally valid...

Greg 

.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 16 Aug 2008 08:10:26 +0200

> contiguous in the original packet...

  RFC 3579, Section 3.1:

      If multiple
      EAP-Message attributes are contained within an Access-Request or
      Access-Challenge packet, they MUST be in order and they MUST be
      consecutive attributes in the Access-Request or Access-Challenge
      packet.

  Requiring this for Extended-Attribute is a good idea.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 16 Aug 2008 17:13:42 +0700

>   Requiring this for Extended-Attribute is a good idea.

Alright, how about this?

   M (More)

      The More Flag is one (1) bit in length and MUST be present.  When
      a value to be transmitted exceeds 246 octets in length it is
      fragmented over two or more Extended Attributes.  If the More Flag
      is set (1), this indicates that the Value field of the Extended
      Attribute contains a fragment of a larger value, which is
      continued in the next Extended Attribute of the same Ext-Type.
      When the More Flag is clear (0), the final (or only) fragment of
      the value is contained in the Extended Attribute.  Any Extended 
	Attributes containing multiple fragments of the same value MUST be 
	in order and MUST be consecutive attributes in the packet.

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 16 Aug 2008 17:25:06 +0700

Alan DeKok <mailto://[email-masked]> writes:

>   I just wanted to be sure I understood it.

OK.

>   Numbers are better than XXXX-YYYY. :)  As for using the top 1K rather
> than 256, or 32, or 4.... it's small enough that we likely won't need
> the attribute numbers later, and large enough it gives a lot of room to
> work with.
> 
>   I'd say 32 may be too small, and anything over 1K is likely too
> large.

OK.  Any other opinions?

>   Sure.

Great!  Anybody married to section 6?  If not, it's gone...

>   Other RFC's have hex examples...

Sure, but I thought that we were writing not with any expectation of a
reasonable level of shared knowledge but for the LCD...

>   Yes.
>   I should put up a web page listing all of the "creative"
> interpretation of the RFC's.  Some people have put a lot of effort into
> doing the most inventive things.

"There is no end to the folly of men..."

---

From: "David B. Nelson" <[email-masked]>
Date: Sat, 16 Aug 2008 09:50:42 -0400

Glen Zorn writes...

> > > Actually, I'd just as soon discard the examples: this draft has
> > > way too much flavor of a tutorial for my taste...
> >
> >   Sure.
> 

I think examples sections (in this or any other document) are
extraordinarily helpful.  They help the reader to understand the details,
and the help the author by bringing to light incongruities in the normative
text.  I wouldn't be so quick to dispense with that section.  That fact that
it is raising issues tells me it has value.

---

From: "David B. Nelson" <[email-masked]>
Date: Sat, 16 Aug 2008 09:59:03 -0400

Glen Zorn writes...

> 	 in order and MUST be consecutive attributes in the packet.

It's the last sentence that I claim adds new requirements to RADIUS.  This
is not required for EAP-Message Attributes, nor any others that I'm aware
of.  I'm stopping short of claiming that this new requirement isn't backward
compatible.  I can easily envision implementations where this would not be
any sort of burden to enforce.  I'm just wondering if there are any
implementations where it would be a burden?  I also see the advantage in
terms of ease of implementation of parsing and reconstruction.

---

From: "David B. Nelson" <[email-masked]>
Date: Sat, 16 Aug 2008 10:15:45 -0400

Clarifying...

> It's the last sentence that I claim adds new requirements to RADIUS

I'm talking about the second MUST in that sentence.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 16 Aug 2008 16:26:36 +0200

David B. Nelson wrote:
>> ...   Any Extended
> is not required for EAP-Message Attributes,

  Nope.  See RFC 3579 Section 3.1:

       If multiple

  MUST be consecutive attributes would seem pretty clear.

> nor any others that I'm aware

  It's a PITA to root through the packet, looking for the next attribute
which *might* be the same... and which isn't consecutive.  I've done
this for the previous version of the Extended-Attributes.  It's awkward.
 It's much easier just to check: Next attribute is the same?  Nope?
Dump the packet as malformed.

  It makes for less code, and fewer chances for programming errors.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 16 Aug 2008 10:10:37 -0700 (PDT)

> to actually refer to RFC 5080.

Issues 225, 250 and 251 all refer to the Extended Attributes document. 

> text, not the list maintained by the chairs.  Regarding the latter, the 
> issue that I filed (#250) was intended for your -00 draft, not RFC 5080.  
> 

On Mozilla, the link does point to Issue 250.  What browser were you 
using? 

> I haven't read your current draft version yet to see if these comments were addressed;

---

From: "David B. Nelson" <[email-masked]>
Date: Sun, 17 Aug 2008 00:42:04 -0400

>   See RFC 3579 Section 3.1:
> 
>       If multiple

Damn.  When did that sneak in there?  :-)

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 17 Aug 2008 14:27:13 +0700

Bernard Aboba [mailto:[email-masked]] writes:

...

> On Mozilla, the link does point to Issue 250.  

IE 7.0.6.  Investigating further w/Opera & Safari, it appears that IE is not
handling references to internal points in the HTML file correctly: it just
opens radissues2.html & quits, leaving the pointer at the beginning (issue
#200).  Opera & Safari position the pointer correctly (after a (long) while
;-). 

...

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 17 Aug 2008 14:34:40 +0700

> Damn.  When did that sneak in there?  :-)

Well, let's see, it was in 2869, so about 10 years ago :-)

---

From: Alan DeKok <[email-masked]>
Date: Wed, 27 Aug 2008 14:25:50 +0200

> 	in order and MUST be consecutive attributes in the packet.

  Looks good to me.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 27 Aug 2008 20:16:09 +0700

> > 	in order and MUST be consecutive attributes in the packet.

OK, cool.  I'll just change the last sentence to say "Any Extended
Attributes containing fragments of the same value MUST be in order and MUST
be consecutive attributes in the packet." because an Extended Attribute
can't contain multiple fragments (my bad ;-).