Subject: Re: [Uri-review] [Fwd: I-D Action:draft-melnikov-mailserver-uri-to-historic-00.txt]

From: Alfred Hönes <[email-masked]>
Date: Wed, 17 Nov 2010 21:49:36 +0100 (MEZ)

My apologies for cross-posting, but this should perhaps reach a
broader audience.   I suggest to send feedback to the uri-review
at ietf.org mailing list, because Alexey sent his I-D announcement
there as well.

At Wed, 17 Nov 2010 17:26:32 +0000 , Alexey Melnikov wrote:

> FYI. I've asked on Apps-discuss about deprecating the mailserver:
> URIs and I've heard several voices in favor of doing that.
>
> I will be asking Peter Saint-Andre to sponsor this document.
>
> ...
>
>    Filename        : draft-melnikov-mailserver-uri-to-historic-00.txt
> ...

There are two more, apparently natively orphaned URI schemes listed
as 'provisional' in the IANA registry, both mentioned in RFC 1630
for the first time, and later again in RFC 1738, but never formally
registered and, AFAICS, still lacking any publicly available
specification:

   a)  tn3270

   b)  afs

A quick Google search does not reveal any hints on definitions and/or
actual use.  Some W3C web pages consider these as "reserved" names.

Apparently none of the various RFCs on Telnet extensions for TN3270
and the somehow related MIB module specifications mention the 'tn3270'
URI scheme.
Even stronger, for 'afs', archived mail (from 1993) seems to confirm
that 'afs' as a URI scheme was a very poor idea from its beginning
(see "afs: considered harmful",
<http://wwwwbs.cs.tu-berlin.de/html/urls/0148.html> ).

I suggest to consider deprecating these reserved URI scheme names
as well, in a single draft together with the 'mailserver' scheme
(to save work in the process).

Thereby, the registrations would be moved to "Historic", which,
according to the definition of that RFC status, does not immediately
invalidate existing use cases (if any), but serves to clarify that
new implementations should not try to support the subject.
The scheme names would remain in the registry, thus keeping the names
"reserved", i.e. out of availability for incompatible new use.

So there are a few questions, for both cases:

1)  Is anybody aware of a specification for the above provisional
    URI schemes ?

2)  If "yes" for 1), are there interoperable implementations?

3)  Are these URI schemes in actual use anywhere
    (even if only intended for interpretation by brainware) ?

4)  Do the answers to the above questions support deprecation?

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:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 18 Nov 2010 18:33:28 +0200

Hello all,

Some notes on discussed topic. At the moment
there are some implementatiom of AFS mentioned
below. One of them is in the Linux kernel starting
from 2.6.10, but it is incomplete. There are some
other implemenations. You can find some information
on this topic here:

http://en.wikipedia.org/wiki/Andrew_file_system

As for tns3720 it is a telnet scheme for access to
IBM 3720 terminal. As this terminal were started to
be produced in 1972, so now it is OK to
move it to 'Historic'. This service is not
being used any more.

As for AFS, I think it shouldn't be moved to
'Historic' - there are some implementation
and it remains been used somewhere.

As for 'mailserver', it really needs to be
moved to 'historic' as there are really no specifications
of use.

Thank you for your time.

All the best,
Mykyta Yevstifeyev

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 18 Nov 2010 18:53:29 +0100 (MEZ)

Mykyta,
thanks for your contribution.  A few comments inline below.

> http://en.wikipedia.org/wiki/Andrew_file_system

Yes, I'm well aware of implementations of AFS that reach far beyond
the original proprietary range.  However the question here is ...

a)  whether it makes sense to use a special URI scheme to access AFS
    related resources.

    All I could find is that due to the way AFS is used and the
    variability in the mount points et al., using an identifier that
    refers to the AFS server does not help in practice; 'file' URIs
    can be used on AFS clients for mounted AFS volumes since the
    mounted volumes are intended to behave transparently, like local
    file system volumes -- same as for NFS, e.g.

b)  in case the above is answered afffirmative, whether there is an
    accepted specification for afs: URIs, with interoperable usage.

AFAICS, neither the page you point to above nor the references
quoted in the recent RFC 5864 (on DNS SRV Records for AFS) contain
indications that would lead me to evidence that the above questions
have affirmative answers.

> move it to 'Historic'. This service is not

Well, AFAIK, 3270 emulation is still in some limited use in commercial
legacy mixed-platform environments, but I've never heard of practical
usage of the 'tn3270' URI scheme in that context -- all such business
applications are likely to operate based on tightly controlled local
configuration of the access points and not driven by some kind of
browser software operating on 'tn3270' URIs.

There's a single RFC (RFC 3049) that contains a few embedded examples
of 'tn3270' URIs, but it remains rather vague and does not give a
reference for the definition of such scheme either.

So I'm also in support of declaring that provisional URI scheme
Historic.

> and it remains been used somewhere.

See my remarks above.
Do you have more information on definition and use of 'afs' URIs?
The thread I had pointed to yesterday seemed to indicate that active
AFS users didn't like the idea at all (already 17 years ago!).

> As for 'mailserver', it really needs to be moves
> to 'historic' as there are really no specifications of use.

Indeed.

The IETF process is very fast in this case.  IETF LC already has been
announced today for draft-melnikov-mailserver-uri-to-historic-00.

So I conclude that we both are in support of that draft. :-)

Kind regards,
  Alfred.

>
> Thank you for your time.
>
> All the best,
> Mykyta Yevstifeyev
>
> 17.11.2010 22:49, Alfred Hönes wrote:

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 19 Nov 2010 09:37:29 +0200

Hello all,

An only note is if we move to 'Historic' the 'tns3720'
URI scheme, we need to move the corresponding RFC
(RFC 3049 and other if are) to 'Historic' too.

IMO it would be OK to create the I-D on this topic and
publish them simulteneously.

Best regards,
Mykyta Yevstifeyev

2010/11/18, Alfred HÎnes <[email-masked]>:
>> 17.11.2010 22:49, Alfred HÎnes wrote:

---

From: "Lyndon Nerenberg (VE6BBM/VE7TFX)" <[email-masked]>
Date: Thu, 18 Nov 2010 21:57:49 -0800

> browser software operating on 'tn3270' URIs.

That's an awfully presumptive generalization to make about how other
people's businesses operate.  That aside, "must be accessible to the
global Internet" isn't a criteria for (or against) standardization (or
registration).  Standards can also apply inside walled gardens.

> reference for the definition of such scheme either.

I strongly suspect that's because the community of users for this scheme
are painfully aware of what the service represents, and therefore didn't
see a need to write it up.  It wouldn't take much effort to document it
in an RFC.

> So I'm also in support of declaring that provisional URI scheme

What is gained by doing this?  tn3270 is a very distinct service from
the NVT-ASCII terminal presumed by telnet:, even though both are
served over the TELNET protocol.  And the TN3270 service is far from
dead (e.g.  there are more than a few AS/400 systems connected to the
Internet).

Someone mentioned the tn3270 scheme made no sense being typed into a
browser.  URIs are used in *many* places other than browsers.  (On the
terminal I'm typing this on, right-clicking on any string prefixed
with 'tn3270://' will launch a tn3270 terminal emulator connection to
the specified host.)  While there's no formal specification for the
tn3270 scheme, it's pretty obvious what to do with the URI if you're
handed one in a context where you can establish the connection.

So let me turn this around and ask: what harm is actively being caused
by the tn3270 scheme that requires us to kick it to the curb?

--lyndon

---

From: John C Klensin <[email-masked]>
Date: Fri, 19 Nov 2010 03:11:26 -0500

While I'm no fan of the 3270 (and wasn't back when I was doing
programming that depended on them), I have to agree with Lyndon.
There is almost certainly no harm in keeping the URI definition
and probably some harm in getting rid of it.   One could argue
that the spec should be retired because it is inadequate and
obsolete, but inventing and applying that criterion is IMO
unreasonable unless we intend to start applying the "time out
and die" provisions of RFC 2026 for the first time in history.

    john

--On Thursday, November 18, 2010 21:57 -0800 "Lyndon Nerenberg
(VE6BBM/VE7TFX)" <[email-masked]> wrote:

>> Well, AFAIK, 3270 emulation is still in some limited use in
>> commercial legacy mixed-platform environments, but I've never
>> heard of practical usage of the 'tn3270' URI scheme in that
>> context -- all such business applications are likely to
>> operate based on tightly controlled local configuration of
>> the access points and not driven by some kind of browser
>> software operating on 'tn3270' URIs.
> 
> That's an awfully presumptive generalization to make about how
> other people's businesses operate.  That aside, "must be
> accessible to the global Internet" isn't a criteria for (or
> against) standardization (or registration).  Standards can
> also apply inside walled gardens.
>...

---

From: Claudio Allocchio <[email-masked]>
Date: Fri, 19 Nov 2010 09:31:26 +0100 (CET)

> and die" provisions of RFC 2026 for the first time in history.

+1 John!

never assume anything about obsolete applications in general. Unless we 
really need to deprecate some, because it creates serious dangers to the 
network security, let the old stuff there. You will find a still non 
neglegible amount of use around.

... I still by time to time receive e-mails originated in X.400 via a 
gateway... and I still have a PDP 11 running incredibly fast on a virtual 
machine on my laptop mac. :-)

claudio
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 19 Nov 2010 16:14:41 +0200

John,

As you say,
"There is almost certainly no harm in keeping the URI definition
and probably some harm in getting rid of it. ". So it should be asked -
what harm is there in moving the 'tns3270' URI scheme to
'Historic'. At the moment no acceptable definition seems to be
found. Some RFCs discussing issues connected with IBM 3270
Emulation are RFC 1041 and 2355, but they are Proposed and Draft
Standards. I should repeat that at the moment the technology
of IBM 3270 emulation is no longer used. It is not an acceptable
way for the Internet Community at all to remain any standards
no longer needed alive. Maybe this is harmful, but not revising
current standards to make them modern and needed.

So IMO there is no reason to leave the 'tns3270' URI scheme as current
as well as 'mailserver' one.

Best regards,
Mykyta Yevstifeyev

19.11.2010 10:11, John C Klensin wrote:
> (VE6BBM/VE7TFX)"<[email-masked]>  wrote:
>
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: "Michael Wojcik" <[email-masked]>
Date: Fri, 19 Nov 2010 07:10:45 -0800

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Lyndon Nerenberg (VE6BBM/VE7TFX)
> Sent: Friday, 19 November, 2010 00:58
> 
commercial
> > browser software operating on 'tn3270' URIs.

I don't know whom Lyndon was quoting here, but "limited use" is only
true for rather large values of "limited". Here at Micro Focus we
continue to have strong sales of our TN3270-based products, and most of
our customers who are migrating mainframe applications to other
platforms continue to use TN3270 as the front-end protocol.

> the NVT-ASCII terminal presumed by telnet:, even though both are
served
> over the TELNET protocol.  And the TN3270 service is far from dead
> (e.g.  there are more than a few AS/400 systems connected to the
> Internet).

True, though AS/400 (now System i) systems are more comfortably accessed
with TN5250 clients. But there are System z (IBM mainframe) systems that
are Internet-accessible too, eg at some educational institutions; and in
any case, as Lyndon pointed out, "Internet-accessible" isn't a criterion
for a URI scheme.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus

---

From: "Michael Wojcik" <[email-masked]>
Date: Fri, 19 Nov 2010 07:10:46 -0800

> On Behalf Of Mykyta Yevstifeyev
> Sent: Thursday, 18 November, 2010 11:33
> 
> As for tns3720 it is a telnet scheme for access to IBM 3720 terminal.

This is incorrect. The tn3270 scheme refers to TN3270, a loose set of recommendations for using Telnet with host systems that support IBM's 3270 protocol. (It can't be used "for access to IBM 3270 terminal", since 3270 terminals are not servers, and indeed it's intended as an alternative to a physical 3270 terminal and the SNA 3270 protocols.)

Note there is no single TN3270 specification; neither is it a distinct protocol. "Classic" or "Basic" TN3270 is Telnet with various options enabled, including Binary, EOR, and Terminal-type. As such, it is documented by a series of RFCs, including 854, 855, 856, 857, 885, and 1091. Additional RFCs (1041, 1576, 1646) add options and recommendations.

"TN3270 Enhanced" or "TN3270E" (RFC 2355) is an attempt to produce an improved TN3270 personality for Telnet. (There was an I-D to update 2355, but it expired without being adopted.) TN3270E is widely used, but has not displaced Classic TN3270 entirely.

> As this terminal were started to be produced in 1972, so now it is OK
> to move it to 'Historic'. This service is not being used any more.

This is completely incorrect. TN3270 is still in widespread use.

Frankly, I'm a bit baffled that someone could simply claim TN3270 was no longer in use without doing any research into the question.

---

From: "Michael Wojcik" <[email-masked]>
Date: Fri, 19 Nov 2010 07:14:13 -0800

> Sent: Friday, 19 November, 2010 09:15
>
> I should repeat that
> at the moment the technology of IBM 3270 emulation is no longer used.

No, you shouldn't, because that's completely false.

This sort of gross error throws the remainder of your argument into
considerable doubt, in my opinion.

---

From: John C Klensin <[email-masked]>
Date: Fri, 19 Nov 2010 13:29:55 -0500

> current standards to make them modern and needed.

Several of us -- including Lyndon, Michael, and myself -- have
observed counterexamples to your assertion that IBM 3270
emulation is no longer in use.  Can you explain the reasoning or
published research that supports your assertion in the light of
those counterexamples?

      john

---

From: "t.petch" <[email-masked]>
Date: Fri, 19 Nov 2010 09:58:03 +0100

----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: "Lyndon Nerenberg (VE6BBM/VE7TFX)" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, November 19, 2010 9:11 AM
Subject: Re: [apps-discuss] tn3270

> and die" provisions of RFC 2026 for the first time in history.

I agree; I would even offer to review an updated specification
(although I think that that would be overkill).

Tom Petch