Re: Current status??

[Stephen D Crocker <[e-mail]>]

Peter,

Fair question.  I had hoped to have things farther along by now.

As you know, there has been a Last Call and various comments came in,
primarily about competitive use of port 113 and others aspects of
interoperability between existing implementations and future
implementations which conform to the Ident specs.  There was also some
internal review involving the IESG and the IAB regarding the
specification of the character sets.

Upon close examination, the compatibility issue turns out to have a
surprisingly clean answer.  In the notes following the syntax in the
Ident space, there is some guidance on the use of white space.  Some
interpreted the guidance as adding white space to the syntax.  What
was actually intended was an instance of the standard Internet slogan,
"Be liberal in what you accept and conservative in what you send."
(Let me introduce the acronym SCALE for "Send Conservatively, Accept
Liberally; Evolve.")

With respect to white space, a SCALE implementation of Ident is one
which never inserts white space in queries or replies but which
accepts white space in the places the notes suggest.  The good news is
that a SCALE implementation of an Ident client is compatible with all
known existing implementations of Ident server and its variations
(TAP, 931).  Similarly, a SCALE implementation of an Ident server is
compatible with all known existing implementations of an Ident client
and its variations (TAP, 931).  Thus, there is no conflict or
incompatibility, and all of those issue just disappear.

On the issue of character sets, there is a small glitch.  In keeping
with the modern requirements to support a wide range of character sets
in addition to USASCII, the Ident protocol includes a field to
explicitly specify the character set.  That part is fine.  The Ident
spec also specifies the default character set to be OCTET if the
character set is not specified.  There are two problems with this.
First, the notion of an OCTET character set is not completely well
defined.  The spec as written says three character codes are not
permitted within OCTET, 000, 012 and 015 (octal).  The reason to
prohibit these codes is clear enough, but it means that value in the
field can't be completely arbitrary, e.g. the a binary encrypted value
of the user's identity, and it also means that this field is not
really what one would expect with an "OCTET" designation.  Also, there
is clear guidance that the default has to be USASCII in keeping with
past practice on similar matters.

So far as I know, simply changing the wording to USASCII would not
cause any harm, as existing implementations conform to this practice.
I believe Mike had a slightly different way to fix this up which was a
bit more sophisticated and subtle than I could recall.

As part of the same internal review, the wording in the Ident MIB with
respect to character sets is also being reviewed and will be brought
into synch with the Ident spec's wording.

In my judgment, these details fall within the editorial process and
need not force a full scale cycle of review and comment.  However, the
changes do have to be visible to the working group, and they will be.
Also, this note contains the substance of the issues and thus makes
the issues visible to the WG.

Steve




>> Sender:      [e-mail]
>> From:    Peter Eriksson <[e-mail]>
>> To:      [e-mail]
>> Date:    Wed, 7 Oct 92 23:21:30 MET
>> Subject: Current status??
>> 
>> What's the current status of the IDENT protocol's way thru the 
>> bureaucracy? 
>> /Peter
>> 
>> Peter Eriksson                                              [e-mail]
>> Lysator Academic Computer Society                 ...!uunet!lysator.liu.se!pen
>> University of Linkoping, Sweden                           I'm bored. Flame me.