RE: Last Call On draft-yevstifeyev-tn3270-uri-12

> From: uri-request@w3.org [mailto:uri-request@w3.org] On Behalf Of
> t.petch
> Sent: Tuesday, 11 January, 2011 11:31
> To: uri@w3.org
> Subject: Fw: Last Call On draft-yevstifeyev-tn3270-uri-12
> 
> from the ietf list, FYI
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "t.petch" <daedulus@btconnect.com>
> To: "Mykyta Yevstifeyev" <evnikita2@gmail.com>; "IETF Discussion"
> <ietf@ietf.org>
> Cc: "iesg" <iesg@ietf.org>
> Sent: Tuesday, January 11, 2011 5:29 PM
> 
> > tn3270 is a widely used protocol but also a venerable one, so it is a
> > little surprising that the IETF is to register a provisional URI for
> > it at this stage.

It is? If there's no standard URI scheme, then a provisional scheme would appear to be appropriate. I don't see how the age of the "protocol" (TN3270 is not a protocol, properly speaking) makes any difference.

> > I have always seen it as an IBM protocol, and while that is no bar to
> > being an RFC - there are plenty of Cisco or Microsoft parallels - I am
> > somewhat surprised that the I-D contains no hint thereof; it does seem
> > discourteous for IBM not to appear in some guise, or perhaps I am
> > missing something.

Calling TN3270 "an IBM protocol" is misleading and technically and historically inaccurate.

First, it's not a protocol. It's a loose and inconsistent collection of Telnet options. Telnet is the protocol; TN3270 is a label for various conventions for Telnet use. Classic TN3270 is simply Telnet with the BIN and EOR options (and possibly others) enabled, and if necessary character set translation (which is outside the scope of Telnet) performed by the client. It was later augmented with TN3270-specific Telnet options, but it remains an agglutination of Telnet behaviors. TN3270E is a Telnet option in its own right - and a pretty complicated one - but it's still Telnet.

Second, IBM does not own TN3270; they are not the only providers of TN3270 implementations (they may not even be the dominant provider of client implementations, though I don't know of any reliable market data here); and they did not invent it. The options that define most of the behavior of Classic TN3270 come from Postel & Reynolds Telnet RFCs like 856 and 885. Later TN3270 RFCs come from various authors, mostly not IBM employees - typically they worked for firms selling TN3270 clients, such as FTP Software (RFC 1091) and DCA (RFC 1576).

Today there are a number of TN3270 client applications, including Micro Focus Rumba, Attachmate's products, offerings from smaller firms such as QWS3270, and free implementations like c3270, in addition to IBM's Personal Communications.

While TN3270 is mostly used to connect to IBM servers, there are non-IBM server implemenations, notably ours (Micro Focus Server EE and Server EO).

> > The provenance of the editor is unknown to me - and of course, once an
> > RFC has been through the IETF processes, then the editorship is an
> > irrelevance - but I am concerned that I have no awareness of the
> > contact provided as the scheme 'Author/Change controller', no track
> > record, no affiliation, a gmail address.  This seems more than
> > discourtesy, this seems wrong.

It is true that typically RFCs include a small amount of information about the editor, such as an employer. However, whether you or I or anyone else on any of these mailing lists knows, or knows of, the author / editor of an I-D seems rather irrelevant to its status. Mykyta Yevstifeyev has engaged at length in discussions on this list (uri@w3.org) about the status of URI schemes. Applying some other gatekeeping rubric - in particular, whether you or I or anyone else knows him - seems unnecessary and an unfortunate precedent.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus




This message has been scanned for viruses by MailController - www.MailController.altohiway.com

Received on Wednesday, 12 January 2011 14:44:30 UTC