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
- Submitted as ID Mike StJohns
- Re: Submitted as ID Peter Eriksson
- Re: Submitted as ID Mike StJohns
- Re: Submitted as ID Dave Crocker
- Re: Submitted as ID Mike StJohns
- Re: Submitted as ID Anders Andersson
- Re: Submitted as ID Peter Eriksson
- Re: Submitted as ID Daniel J. Bernstein