Re: [apps-discuss] [Uri-review] tn3270

"t.petch" <ietfc@btconnect.com> Fri, 19 November 2010 19:27 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81BA728C12F; Fri, 19 Nov 2010 11:27:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLKyQDjahNRN; Fri, 19 Nov 2010 11:27:21 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by core3.amsl.com (Postfix) with ESMTP id 245183A6907; Fri, 19 Nov 2010 11:26:59 -0800 (PST)
Received: from host81-156-207-177.range81-156.btcentralplus.com (HELO pc6) ([81.156.207.177]) by c2beaomr07.btconnect.com with SMTP id AUG12839; Fri, 19 Nov 2010 19:26:06 +0000 (GMT)
Message-ID: <003701cb8816$f6470a60$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Alfred HÎnes <ah@TR-Sys.de>
References: <201011191844.TAA17983@TR-Sys.de>
Date: Fri, 19 Nov 2010 19:24:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CE6CF4B.0343, actions=tag
X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4CE6CF50.01F5, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] tn3270
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2010 19:27:44 -0000

----- Original Message -----
From: "Alfred HÎnes" <ah@TR-Sys.de>
To: <Michael.Wojcik@microfocus.com>
Cc: <uri-review@ietf.org>; <apps-discuss@ietf.org>
Sent: Friday, November 19, 2010 7:44 PM

> Michael, all,
>
> nobody (ehem, at least almost nobody) doubts that TN3270 service
> is in use today.  But that isn't the question being discussed in
> this thread.
>
> The questions of interest are:
>
> a)  Are 'tn3270' URIs used ?
>
> b)  Where is the specification and a registration document ?
>
>     Or is there only a semi-secret oral tradition that nobody has
>     deemed worth being written up in a URI scheme registration
>     document brought to IANA ?
>
> and secondary to a), conditional under b) :
>
> c)  Is it expected that new implementations of software making
>     use of 'tn3270' URIs will be done ?
>
> d)  Does the IETF want to encourage new URI implementations to support
>     the 'tn3270' URI scheme (if it has been actually defined) ?
>
> [ And I personally would like to add:
>   If there actually is demand, why is there no specification that would
>   allow an independent, yet interoperable, new implementation?
>   But that's also not the basic question.
> ]
> Unless all of a) through d) can be answered in an affirmative manner,
> the correct conclusion to draw indeed would be to move the reserved
> scheme name to Historic.
>
> There seems to be some sublime, unspecific FUD about "Historic".
> "Historic" for an RFC or an IANA registry entry does not mean
> "no implementations" or "not used"; it is an indication that the
> specification or technology
> -  has been or is going to be superseded by something newer
>    (you just have confirmed e.g., that indeed for "System i" there
>    is a preferred, more recent successor technology for TN3270 service,
>    and if 'tn3270' URIs were needed, there might be something other
>    for use with TN5250 as well, isn't it?), and
> -  the IETF does not recommend any more general implementation of
>    the older technology.

A very IETF-centric view of the world.

Shock, horror; there are other people and places who produce and use
interoperable software without making it an RFC.  Some may have started here and
taken there custom elsewhere.  Which makes your arguments specious; you give no
valid reason to change the status of tn3270 and, in the absence of this, we
should leave well alone - we have no idea whose toes we might be treading on and
it would be presumptuous of us to assume that we know everything about this
topic (and if I knew more, I would reveal it).

Tom Petch





>
> Anybody is free to implement a Historic specification, but they should
> not expect everybody to do so; and everybody is free to [continue to]
> use implementations of a specification that has been moved to Historic
> status.
> (To reinforce it, "technology" here means use of 'tn3270' URIs,
> not use of TN3270 service.)
>
> I also rely in my work on lots of protocols that now are considered
> Historic; this does not cause a disease; it's simply that neither
> I myself nor my customers have an expectation that these are
> implemented in common new hardware/firmware/software.
> (E.g., RTELNET, RFC 818, comes to mind -- still used with numerous
> factory floor devices -- but Status: HISTORIC.)
>
> A short note on IANA processing:  Since a while, IANA can manage
> timed processes; this hasn't been so in the past.  In more recent
> IANA registries that make use of this capability, "provisional"
> entries are bound to an expiry date, and without updates of such
> entries or conversion to regular entries, they automagically
> disappear from the registry after the time-out.
> Conceptionally, this apparently was the idea in RFC 1738, where it
> talked about "reserving the name, waiting for future specification"
> (which had been expected to be provided in a reasonable timeframe).
>
>
> To repeat my recommendation to stakeholders from my previous posting:
>
> If there _is_ an agreed-upon spec for 'tn3270' URIs, write it up in a
> short URI scheme registration draft (that should be possible in no
> more than half a dozen of pages) and pursue publication as an RFC
> (I assume that our APP ADs would support this in the same manner they
> offered support for "blindly" moving to Historic a non-specified
> scheme, via a dedicated memo).
>
> If such effort doesn't happen, this will be taken as a strong
> indication that there is no sustained interest in the provisionally
> registered 'tn3270' URI scheme name and it actually SHOULD be moved
> to Historic.
>
>
> Kind regards,
>   Alfred.
>
> --
>
> +------------------------+--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
> | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
> | D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
> +------------------------+--------------------------------------------+
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss