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

[Alfred Hönes <[e-mail]>]

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.

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: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+