Re: Issue with draft-ietf-radext-fixes-01.txt section 2.3.2

[Alan DeKok <aland@nitros9.org>]

Avi Lior wrote:

> Section 2.3.2 is attempting to fix a problem with Acct-Session-Id which
> is not really a problem.

  It's more a clarification of the language in RFC 2865.  It says
Acct-Session-Id is "Text" in the ASCII art, but "String" in the body,
and defines "String" as having the same contents as the type "Text"
defined in RFC 2865.

  Acct-Multi-Session-Id is similar.  It defines the attribute as
"Acct-Session-Id" just before the ASCII art (which has type "String"),
and then also defines "String" as having the same contents as the type
"Text" defined in RFC 2865.

> Infact, the proposed change will break existing RADIUS server
> implemenations, Accounting Correlation and Mediation systems and other
> backoffice systems.

  That was not out intention.

> Requested change:
> 
> Delete this section.
> 
> Alternatively, you can reinforce that Acct-Session-Id is of type TEXT.

  How about the following text:

[RFC2866] Section 5.5 describes Acct-Session-Id as Text within the
figure summarizing the attribute format, but then goes to state that
"The String field SHOULD be a string of UTF-8 encoded 10646
characters."

[RFC2865] defines the "Text" type as "containing UTF-8 encoded 10646
characters", which is compatible with the description of
Acct-Session-Id.  Since other attributes are consistently described as
"Text" within both the figure summarizing the attribute format, and
the following attribute definition, it appears that this is a
typographical error, and that Acct-Session-Id is of type Text, and not
of type String.

The definition of the Acct-Multi-Session-Id attribute also has
typographical errors.  It says

   A summary of the Acct-Session-Id attribute format ...

This text should read

  A summary of the Acct-Multi-Session-Id attribute format ...

The Acct-Multi-Session-Id attribute is also defined as being of type
"String".  However, the language in the text strongly recommends that
implementors consider the attribute as being of type "Text".  It is
unclear why the type "String" was chosen for this attribute when the
type "Text" would be sufficient.
...

  I would like to recommend treating it as type "Text", which would be
compatible with most implementations I've seen.  i.e. I can't recall one
which treats it as opaque octets.

  Alan DeKok.


--
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/>