RFC violations (was Re: \000 in "octets" attribute? )

[Alan DeKok]

=?iso-8859-1?Q?Bj=F8rn_Mork?= <bjorn at mork.no> wrote:
> Stripping NULs off the end of a string is interpreting them as string
> terminators.  The RFC forbids this.

  No, it doesn't.  And even if it did, who cares?

>  It demands that implementations deal with embedded NULs.  If
> FreeRADIUS strips any NULs, anywhere in the string, then FreeRADIUS
> is violating the RFC.  IMHO.

  Perhaps you could try understand what the server actually does, and
why.

  a) type "octets" is treated as opaque binary blobs
  b) type "string" can't have embedded NUL's, because they are used
     in C as end-of-string markers.  This is perfectly compatible with
     the RFC's, because FreeRADIUS used type "string" for printable
     data, and NUL isn't printable.

  The RFC's use type "text" for printable and "string" for octets,
because the original RFC's used "string" for both, which was wrong.
FreeRADIUS used "string" for printable, and "octets" for
non-printable, because it was started before the RFC's were fixed.

  And as for RFC violations, the RFC's document a recommended way to
do things.  Nothing more.  You can violate them at will if they're
wrong.  (As seen in the "string" -> "string, text" change above.)  If
the original RFC was perfect, why was it changed?

  FreeRADIUS violates a number of other recommendations in the RFC's,
because time has shown those recommendations to be wrong or
inefficient.  e.g. the RFC 3579, section 2.6.1.  It recommends keeping
track of EAP sessions through some convoluted and fragile method.

  When Raghu did the original EAP implementation, he came up with a
much better scheme.  So much better, in fact, the there will be a new
RFC within a year documenting his method as used in FreeRADIUS, and
suggesting that it's probably a better way to do things.

  So don't get picky about RFC violations.  Blind adherence to a
specification is counter-productive.

  And if nothing else, the collective RADIUS experience of the
FreeRADIUS developers is approaching the century mark.  I'd be careful
about arguing with people who have more experience than you in a field.

  Alan DeKok.