Ident/931 review
"David A. Borman" <dab@berserkly.cray.com> Mon, 21 September 1992 19:21 UTC
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15064; 21 Sep 92 15:21 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa15060; 21 Sep 92 15:21 EDT
Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa23346; 21 Sep 92 15:25 EDT
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15028; 21 Sep 92 15:21 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa15024; 21 Sep 92 15:20 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa23225; 21 Sep 92 15:24 EDT
Received: from handel.cray.com by cray.com (4.1/CRI-MX 2.2) id AA14603; Mon, 21 Sep 92 14:24:31 CDT
Received: by handel.cray.com id AA07033; 5.57/CRI-5.5; Mon, 21 Sep 92 14:24:16 -0500
Date: Mon, 21 Sep 1992 14:24:16 -0500
X-Orig-Sender: ident-request@ietf.nri.reston.va.us
Sender: ietf-archive-request@IETF.NRI.Reston.VA.US
From: "David A. Borman" <dab@berserkly.cray.com>
Message-Id: <9209211924.AA07033@handel.cray.com>
To: ident@NRI.Reston.VA.US, iesg@NRI.Reston.VA.US
Subject: Ident/931 review
Here is a comparison of interoperability issues between RFC-931, Ident, and TAP. This is a slightly updated version of what I sent to the iesg mailing list a week or two ago. -David Borman, dab@cray.com Summary ======= The main question that this review is intended to answer is whether or not Ident should be assigned a new TCP port number, distinct from the port number assigned in RFC-931. The only reason for assigning a new port number would be if Ident implementations would not interoperate with existing implementations. It seems to me that the potential interoperability problems are pretty easy to fix. Suggestions ----------- To increase interoperability of Ident with RFC-931 (and TAP), the Ident spec should be modified to: 1) disallow white space at the beginnings and ending of lines. 2) Disallow white space before and after the "," that separates <opsys> from <charset>. 3) The item on case insensitivity in section 6 should be removed, or clarified to state that all tokens must be sent as upper case. The latter would also make the comment on case insensitivity comparisons unneeded. Also, the ability of an Ident client to do multiple queries is of questionable value in most situations where I would imagine Ident being used (because normally there will only be one query...). However, removing this feature at a later date would not cause interoperability problems, so I don't think it is enough of an issue to worry about at this time. I would want to see this issue revisited before the document could go to Draft status, and either flushed out in greater detail or removed. Besides, it would be easier to remove it at Draft if it is not needed, rather than adding it at Draft if it is needed. To increase interoperability of TAP with RFC-931 and Ident, the TAP spec should be modified to: 1) Not allow white space before the <conn-info> part of a USERID reply. Specific details of interoperability analysis ============================================= Character quoting: ------------------ RFC-931 includes the use of a quoting character to allow ":", ",", white space, and the quoting character itself ("\") to be included in tokens. Neither Ident or TAP contain this. Potential Interoperability problem: An Ident or TAP client will not correctly parse a response from an RFC-931 server that includes quoted characters. An RFC-931 server will not correctly parse a request from an RFC=931 client that includes quoted characters. Possible rectification: There isn't really anything that can be done about this issue. It does seem that existing implementations do not support character quoting, if this is the case then there is no interoperability issue. Client query to Server format: ------------------------------ The only issue here is on white-space. All three allow white-space between the tokens. Ident also specifically allows white space at the beginning and the end of the line. RFC-931 <Server-port><WS>,<WS><Client-port><CR><LF> Ident <WS><Server-port><WS>,<WS><Client-port><WS><CR><LF> TAP <Server-port><WS>,<WS><Client-port><CR><LF> Potential Interoperability problem: An Ident client that sends white-space at the beginning or end of the request may confuse an RFC-931 or TAP server. Possible rectification: Eliminate beginning and trailing white-space from Ident. Server response to Client format: --------------------------------- RFC-931 <Server-port><WS>,<WS><Client-port><WS>:<WS>USERID<WS>:<WS> <opsys><WS>:<info><CR><NL> <Server-port><WS>,<WS><Client-port><WS>:<WS>ERROR<WS>:<WS> <error-type><WS><CR><NL> Ident <WS><Server-port><WS>,<WS><Client-port><WS>:<WS>USERID<WS>:<WS> <opsys>[<WS>,<WS><charset>]<WS>:<info><CR><NL> <WS><Server-port><WS>,<WS><Client-port><WS>:<WS>ERROR<WS>:<WS> <error-type><WS><CR><NL> TAP <Server-port><WS>,<WS><Client-port><WS>:<WS>USERID<WS>:<WS> <opsys><WS>:<WS><info><CR><NL> <Server-port><WS>,<WS><Client-port><WS>:<WS>ERROR<WS>:<WS> <error-type><CR><NL> Potential Interoperability problems: An Ident Server that sends white-space at the beginning of either an ERROR or USERID response, or that sends white-space at the end of an ERROR response, may confuse an RFC-931 or TAP client. Possible rectification: Eliminate beginning and trailing white-space from Ident replies. Potential Interoperability problems: An Ident Server that includes the optional <charset> information will have it be taken as part of the <opsys> by an RFC-931 or TAP client. (Also, see below for more issues dealing with <charset>.) Possible rectification: Ident Servers should not include the optional <charset> information if OCTET will suffice for the <charset> designation. Potential Interoperability problems: A TAP Server that includes white-space between the : and the <info> will be included as part of the <info> by an RFC-931 or an Ident client. Possible rectification: TAP Servers should not send white-space before the <info>, unless it is to be included as part of <info>. Error types: ------------ RFC-931 Ident TAP ================ ================ ================ INVALID-PORT INVALID-PORT INVALID-PORT NO-USER NO-USER NO-USER UNKNOWN-ERROR UNKNOWN-ERROR UNKNOWN-ERROR HIDDEN-USER HIDDEN-USER X<non-standard> X<non-standard> Potential Interoperability problems: None. The values are only suggested values in RFC-931, hence a compliant RFC-931 client should be able to deal with other error types than the 3 types explicitly listed in the document. Operating system types: ----------------------- RFC-931 Ident TAP ================ ================ ================ <from Assigned #s> <from Assigned #s> <from Assigned #s> OTHER OTHER OTHER TAC In addition, an Ident <opsys> may be followed by <WS>","<WS><charset> before the ":" field separator. Potential Interoperability problems: Ident and TAP clients may receive TAC, and not recognize it as a valid operating system type. Possible rectification: None needed. The list of operating system types in Assigned numbers can grow, so any client must be able to deal with unknown operating system types. Potential Interoperability problems: RFC-931 and TAP clients may receive ","<charset> as part of the operating system types when talking to an Ident server. Also, if white-space is included before or after the ",", an RFC-931 or TAP client may not be able to successfully parse the rest of the line, as it would be expecting a ":" to be the next character. Possible rectification: An Ident server should not be allowed to insert white-space before or after the "," separating the <opsys> and the <charset>. An RFC-931 or TAP client would then treat <opsys>","<charset> as the <opsys>, and not recognize the operating system type, and would just treat it as an unknown operating system type, which they both need to be able to do now. Token character sets: --------------------- The Ident spec says that field comparison is done case independent, so that, for example, "Error" and "ERROR" will compare as being equal. This is true for all fields except for the <info> field in a USERID reply. Currently, all tokens listed in all three of the documents are all upper-case. The list of operating system types in Assigned Numbers is limited to upper-case letters. Potential Interoperability problems: If an Ident server were to send out a token in a reply with lower case letters in a token, it may not be recognized by either an RFC-931 or a TAP client, when an Ident client would recognize it. If an RFC-931 or TAP client sent out a reply with lower case letters in a token that was different from another known token only in its case, then an Ident client would incorrectly treat it as the all upper case token. Possible rectification: Ident servers must not send out tokens with lower case letters. RFC-931 and TAP servers must not send out tokens with lower case letters. The latter is not a problem, because currently none of the three documents specify any tokens with lower case letters. Number of queries per connection: --------------------------------- RFC-931 and TAP specify that the client sends one query, and the server sends one reply. Ident allows the client to send multiple queries, but allows the server to close the connection after sending one reply, or wait for additional queries. Potential Interoperability problems: If an Ident client wishes to do multiple queries, it may find that connection is closed, even when talking to an Ident server. Thus, the client has to deal with this situation, and should not have any problems dealing with an RFC-931 or TAP server that will always close the connection after giving one reply, so this is not a problem. If an Ident server receives a request from an RFC-931 or TAP client, it will process the one request. If it then closes the connection, there is no problem. If it waits for additional queries, it will be notified that there is no more data coming when the client closes the connection. This is also not a problem. Possible rectification: Clarification of client actions in Ident would be useful. Some possible suggestions: 1) An Ident client should not send a second request until it has received a response from the first request. (Allows the connection to close down from single shot servers, so that the second request will fail at the sender side.) 2) An Ident server should only use closing the connection as a response to the initial request. If it sends a response to the first request and accepts the second request, it should respond to the second request. 3) An ident client that gets a closed TCP connection as a response to a second query should retry that query on a new TCP connection, rather than treating it as an error. (It must do this anyway to deal with single-shot servers...) Other issues: ------------- The BNF code in Ident is missing "HIDDEN-USER".
- Ident/931 review David A. Borman