Re: Submitted as ID

Mike StJohns <stjohns@umd5.umd.edu> Tue, 02 June 1992 19:36 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03732; 2 Jun 92 15:36 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00370; 2 Jun 92 15:43 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00342; 2 Jun 92 15:43 EDT
Received: from umd5.umd.edu by NRI.Reston.VA.US id aa00327; 2 Jun 92 15:42 EDT
Received: by umd5.umd.edu id <AA05179@umd5.umd.edu>; Tue, 2 Jun 92 15:43:51 -0400
Message-Id: <9206021943.AA05179@umd5.umd.edu>
To: Peter Eriksson <pen@lysator.liu.se>
Cc: ident@nri.reston.va.us, andersa@docs.uu.se
Subject: Re: Submitted as ID
In-Reply-To: Your message of Tue, 02 Jun 92 13:06:40 +0700. <CMM.0.90.0.707483200.pen@robert.lysator.liu.se>
Date: Tue, 02 Jun 1992 15:43:49 -0400
From: Mike StJohns <stjohns@umd5.umd.edu>
X-Mts: smtp

> Mike writes:
> >      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.)

Well - spaces are permitted between any token.  I hate to say this,
but we should just bite the bullet and change.

> 
> 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...)

Wow - I guess I should read the documents I reference sometimes.  Last
time I looked (approx 3-4 years ago) that wasn't there...

I'm not hot about comma for a seperator - its not "visual" (so sue me)
enough.  How about an "=" so the field would look something like:

"UNIX = SWEDISH"?



> >      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 <Anders.Andersson@docs.uu.se>).
I saw your announcement.  You write the definition, I'll include it. :)

> 
> >      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.. :-)

*sigh* I thought it was clear before.
> >   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. :-)

How about:

In addition, the server is allowed to drop the query connection
without responding.  Any server initiated close whether graceful or an
abort (TCP RESET) while waiting for a response to a query should be
considered to have the same meaning as "ERROR : UNKNOWN-ERROR"?

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

Hmm - I'll wordsmith a little - thought I had cleared up all the twiddles.


Mike