Re: Submitted as ID

[Peter Eriksson <[e-mail]>]

Mike writes:

>   connection.  The server may then either shut the connection down or
>   it may continue to read/respond to multiple queries.  The server
>   should close the connection down after a configurable amount of
>   time with no queries - a 60-180 second idle timeout is recommended. 

I think this sounds good.

>      The character set (if present) is seperated from the operating
>      system name by "///".  The character set identifier is used to
>      indicate the character set of the identification string.  If a
>      character set identifier is omitted, the identification string
>      is assumed to be in "NVT-ASCII" (exception - see OCTET below).
...
>   <opsys-field> ::= <opsys> [ "///" <charset>]

There is a potential problem with this... If one allows spaces between
the <opsys> token and the "///" delimiter (and between the "///" and
the <charset token), than it may create problems for old (and current)
implementations of client libraries that assumes that there is just
going to be one single token between the two ":" characters. (Of course
*new* libraries can be written to handle this, but it would be nice to
not break code currently in use.)

Here I quote from RFC1060:

-   A system name may be up to 40 characters taken from the set of upper-
-   case letters, digits, and the two punctuation characters hyphen and
-   slash.  It must start with a letter, and end with a letter or digit.

Perhaps it would be better to choose another character that isn't
a valid member of a system name? (Although it isn't very likely that an
operating system will have three slashes in a row..). How about a single
comma (",") character? (And I like single-character delimiters for two
reasons, it "looks" better, and is easier to parse...)

>      This document defines a user identifier format only for one
>      operating system type - "UNIX".  A "UNIX" identifier consists of
>      up to 8 printable characters (in the specified character set)
>      not including white space (SPC, TAB) or carriage motion
>      characters (CR, LF, FF).  Other formats will be published later
>      as necessary.

If we should have this in the document, the perhaps we should include the
format for the TOPS-20 operating system, since there now exists a server
implementation for it? (The source code can be FTP'd from the machine
"ftp.lysator.liu.se", in the directory "pub/ident/TOPS-20" as "IDENTD.MAC".
It is written in MACRO-10 assembly language by Anders Andersson,
with email address <[e-mail]>).

>      type.  The main difference between "OCTET" and "OTHER" is that
>      an "OTHER" identification string is expected to be printable in
>      the character set identified, or in the NVT-ASCII character set
>      if not explicitly identified.

Ok, this sounds better. Now one atleast knows which character set we
are talking about.. :-)

>   In addition, the server is allowed to drop the query connection
>   without responding.  Any close, whether graceful or an abort should
>   be considered to have the same meaning as "ERROR : UNKNOWN-ERROR".

I'm a little curious what effect this will have to multi-query
clients. They could interpret this as a timeout and retry the connection.
On the other hand, they should have a limit on the number of connection
retrys so this shouldn't be any problem. Ok, forget that I said this. :-)

Another minor issue is also that in some places in the text you talk
about the "Identity Protocol" and in other places the "Identification
Server Protocol". Perhaps it should be the same text in all occurances?

/Peter



Peter Eriksson                                              [e-mail]
Lysator Academic Computer Society                 ...!uunet!lysator.liu.se!pen
University of Linkoping, Sweden                           I'm bored. Flame me.