Subject: Re: [Uri-review] [apps-discuss] Provisional URI registrations

From: Alfred Hönes <[email-masked]>
Date: Mon, 22 Nov 2010 21:34:33 +0100 (MEZ)

Graham Klyne wrote:

> Having made a very quick review of that discussion (w.r.t. tn3270),
> I feel there is a consensus that the appropriate response to to say
> "that's fine, it has a definition, let's leave it there".

Well, that's been one of the points where opinions seem to differ.
I could not find a definition, only RFC 1738 "reserving the name for
future definition".  The users of TN3270 service so far have claimed
there would be a definition, but nobody has shown it so far, and
some indications have been reported of different, non-interoperable
definitions as well.  I don't want to take a position on that now.

> There is no explicit provision for time-out of provisional
> registrations - the general idea (at least in the formulation
> of the header registry, from which I believe this registry was
> derived) was to provide a place where schemes could be documented
> for the community without having to meet the properly high standards
> of IETF consensus.

I would not have challenged "tn3270" as a provisional URI scheme
if there had been evidence that the procedures of RFC 4395 for such
scheme had been followed.

> One option in this case would be to move the tn3270 scheme to
> historic - I'm not sure if that's been suggested.

Exactly that was the starting point of the discussion.   :-)

I had suggested to add this status change to Alexey's draft that
aims at making 'mailserver' Historic, simply for the sake of
saving resources in drafting, draft approval, and RFC publication.
But i'm fine with defering that, doing that later, if still no spec
has be provided by that time.

> That's something I would support in this case.

Thanks.  I'll count on you when (and if) it turns sensical to retry.

John said:

>>   (2) Not having a Reserved category from the beginning appears to
>>   be an error on IANA's part, not something the IETF specified in
>>   any way.   If that is correct, it should be possible to deal
>>   with it as correcting an error, which is (or should be) an
>>   extremely lightweight procedure.

and you responded:

> Well, as Martin says, if it's an error it's not one on IANA's part.
> In this case, they follow what we (the IETF) asked of them.
> So I suppose we should be careful what we ask for :)

I disagree on the first two statements.

Actually, before the change of the URI Scheme registry triggered
by RFC 4395, 'afs', 'mailserver', and 'tn3270' had been listed
as "reserved".  I could not find instructions in RFC 4395 telling
IANA to convert these entries to "provisional" URI schemes,
and I observe that neither of these previously "reserved" keywords
would have qualified under the criteria for such registration in
RFC 4395.
So, since there apparently haven't been conversion rules; arguably,
something went wrong; achieving at consensus *now* that it likely
was a clerical error would allow us to perform a very lightweight
procedure to restore the 'status quo ante' (with three reserved
keywords), before Alexey's draft is published, or during that
process (but logically before 'mailserver' is made Historic).

Kind regards,
  Alfred.

---

From: "Michael Wojcik" <[email-masked]>
Date: Tue, 23 Nov 2010 06:48:43 -0800

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Alfred HÎnes
> Sent: Monday, 22 November, 2010 15:35
> 
> Graham Klyne wrote:
> 
> > Having made a very quick review of that discussion (w.r.t. tn3270), I
> > feel there is a consensus that the appropriate response to to say
> there would be a definition, but nobody has shown it so far, and some
> indications have been reported of different, non-interoperable

As far as I can tell, the situation is this:

- There is no definition of the tn3270 scheme.

- There are applications which interpret tn3270 URIs, by starting a client that implements some flavor of TN3270.

- There is no single definition of a TN3270 service, which is what the scheme presumably refers to. There are definitions of various pieces of Classic TN3270, definitions of "best practices" for Classic TN3270, and a definition of TN3270E.

- There are various implementations of TN3270 service (client and server), most or all of which are probably not fully compliant with the various definitions.

- Those implementations are generally interoperable, but sometimes with caveats (eg reduced functionality).

So I think it's fair to say that:

1) There is no definition of the tn3270 scheme.

2) While there's a working understanding of what specifications contribute to a "standard" implementation of TN3270 service, there is no single definition of that service. That makes defining the scheme more difficult.

I'd also suggest that while a single definition of the TN3270 service, and a definition and proper registration of the tn3270 scheme, are desirable, in practice I don't believe they'd have much effect. IBM hasn't shown any inclination to bring its client implementation into conformance with the extant TN3270E specification (RFC 2355), for example.

I don't have strong feelings about whether the "tn3270" scheme is labelled "provisional" or "historic". Again, I don't think it will make any difference to implementors, who will treat tn3270-scheme URIs however they like. (I'm an implementor myself, but thus far I've only dealt with the server side, which never sees such URIs, so it hasn't come up.)

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus

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

---

From: Graham Klyne <[email-masked]>
Date: Tue, 23 Nov 2010 15:45:32 +0000

Michael, thanks for the clarification.  I clearly skimmed the discussion too 
quickly - I didn't pick up that the scheme was lacking a definition.  I think my 
latest response to Alfred applies.

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Tue, 23 Nov 2010 15:40:43 +0000

> process (but logically before 'mailserver' is made Historic).

Ah, I wasn't of the prior "reserved" status (sorry if I skimmed over the prior 
discussion too quickly).  I think these 3 are an exceptional case.

In the circumstances described, as reviewer, my inclination would probably have 
been to recommend provisional registration (I don't recall being asked about 
these - I suspect they were grandfathered in when the registry was initially 
created, by some ad-hoc means; after all, provisional is very similar in its 
effect to reserved).  If the general consensus is that the provisional status is 
unlikely to be further developed, then moving to historic seems a reasonable 
course, allowing that in this case the precise requirements may not be perfectly 
satisfied.

#g
--

---

From: "t.petch" <[email-masked]>
Date: Tue, 23 Nov 2010 18:19:34 +0100

----- Original Message -----
From: "Michael Wojcik" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: "Alfred HÎnes" <[email-masked]>
Sent: Tuesday, November 23, 2010 3:48 PM

- There are applications which interpret tn3270 URIs, by starting a client that
implements some flavor of TN3270.

- There is no single definition of a TN3270 service, which is what the scheme
presumably refers to. There are definitions of various pieces of Classic TN3270,
definitions of "best practices" for Classic TN3270, and a definition of TN3270E.

- There are various implementations of TN3270 service (client and server), most
or all of which are probably not fully compliant with the various definitions.

<tp>
Looking at recent IBM announcements, I found one from this year announcing
support for TN3270 over IPv6, which makes it more progressive, and likely to be
around longer, than some IETF protocols.

Tom Petch
</tp>

- Those implementations are generally interoperable, but sometimes with caveats
(eg reduced functionality).

2) While there's a working understanding of what specifications contribute to a
"standard" implementation of TN3270 service, there is no single definition of
that service. That makes defining the scheme more difficult.

I'd also suggest that while a single definition of the TN3270 service, and a
definition and proper registration of the tn3270 scheme, are desirable, in
practice I don't believe they'd have much effect. IBM hasn't shown any
inclination to bring its client implementation into conformance with the extant
TN3270E specification (RFC 2355), for example.

I don't have strong feelings about whether the "tn3270" scheme is labelled
"provisional" or "historic". Again, I don't think it will make any difference to
implementors, who will treat tn3270-scheme URIs however they like. (I'm an
implementor myself, but thus far I've only dealt with the server side, which
never sees such URIs, so it hasn't come up.)

This message has been scanned for viruses by MailController -
www.MailController.altohiway.com
_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 24 Nov 2010 11:20:09 +0200

Hello all,

I think we just need a formal specification
of tn3270 scheme. This will stop discussions
about moving or not moving it to 'Historic' as
it would be moved to 'Permanent'. We won't
have to specify the service - fust the URI
scheme. I think I'll make a corresponding
draft in a week to stop all these discussions
and put a point in this problem.

Mykyta Yevstifeyev

2010/11/23, t.petch <[email-masked]>:
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: "t.petch" <[email-masked]>
Date: Wed, 24 Nov 2010 09:40:23 +0100

----- Original Message -----
From: "Graham Klyne" <[email-masked]>
To: "Michael Wojcik" <[email-masked]>
Cc: <[email-masked]>; "Înes" <[email-masked]>; <[email-masked]>;
<Alfred [email-masked]>
Sent: Tuesday, November 23, 2010 4:45 PM

<tp>
Who needs a definition?  I did a quick 'literature search' and found plenty of
references to tn3270 as a URI but no definition; the examples were all of the
form
scheme :// host : port
No parameters, queries, fragments or anything fancy.  On reflection, this seems
right; tn3270 is more sophisticated than many IETF protocols and if it wants
something, it negotiates it, so no need for a complex URI to specify things in
advance.

One could write a universal URI definition for such schemes
scheme host port
means set up a connection of protocol 'scheme' to 'host', default port from
IANA, but, arguably, we already have all we need in RFC3986.

Tom Petch
</tp>

#g
--

>
> - There are various implementations of TN3270 service (client and server),
most or all of which are probably not fully compliant with the various
definitions.
> 2) While there's a working understanding of what specifications contribute to
a "standard" implementation of TN3270 service, there is no single definition of
that service. That makes defining the scheme more difficult.

---

From: "Michael Wojcik" <[email-masked]>
Date: Wed, 24 Nov 2010 07:30:01 -0800

> From: t.petch [mailto:[email-masked]]
> Sent: Wednesday, 24 November, 2010 03:40
> 
> Who needs a definition?  I did a quick 'literature search' and found
> plenty of references to tn3270 as a URI but no definition; the
examples
> were all of the form scheme :// host : port No parameters, queries,
> fragments or anything fancy.  On reflection, this seems right; tn3270
> is more sophisticated than many IETF protocols and if it wants
> something, it negotiates it, so no need for a complex URI to specify
> things in advance.

There are many things in TN3270 that can't simply be negotiated, and
that could usefully be represented in a URI. LU name, terminal type and
model, and printer association, for example; those are all things that
TN3270 clients typically let the user configure.

The tn3270 URI syntax might also conceivably let the user override the
default capability negotiation, for example to force Classic TN3270
rather than TN3270E, or request a non-default subset of TN3270E
functions. That would be useful for testing, among other things.

And while there's no obvious use for path, fragment, and query URI
components in the tn3270 scheme, I can easily imagine an implementor
using them for TN3270 extensions, such as using the path to select an
initial transaction.

> One could write a universal URI definition for such schemes scheme
host
> port means set up a connection of protocol 'scheme' to 'host', default
> port from IANA, but, arguably, we already have all we need in RFC3986.

I think we still need at least a basic tn3270 definition, if we're going
to consider the scheme well-defined. (Whether its status should be
changed from "provisional" to "historic" in the absence of such a
definition is another question; I have no strong feelings about that.)
There's a lot of variation among TN3270 implementations and the relevant
RFCs don't provide enough direction.

---

From: "t.petch" <[email-masked]>
Date: Wed, 24 Nov 2010 18:29:45 +0100

----- Original Message -----
From: "Michael Wojcik" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: "t.petch" <[email-masked]>
Sent: Wednesday, November 24, 2010 4:30 PM
examples

<tp>
Yes we could, but I would be averse to producing a specification to which
noone actually conforms.  That is, if TN3270 were new and we were embarking
on a URI, we would have a free choice, but instead, we have a decade of history,
and I do not know what that is; in a brief search.I could not find any
parameters
currently and would not want to create a specification that noone has
implemented or will implement.

I see the primary need at present to have an agreed basic definition so the
information stays available in a sensible category in our registries.

Tom Petch
</tp>

host

---

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

> scheme had been followed.

'tn3270:' usage predates RFC 4395 by at least a decade.

---

From: "t.petch" <[email-masked]>
Date: Fri, 26 Nov 2010 16:04:27 +0100

----- Original Message -----
From: "t.petch" <[email-masked]>
To: "Michael Wojcik" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, November 24, 2010 6:29 PM
> TN3270 clients typically let the user configure.

Michael

Nice try, but most people would regard RFC1646 and RFC1647 as giving
you precisely that, even if, colloquially, they are not called TN3270 but
TN3270E.

I stand by my first statement, that you can negotiate anything you need with
TN3270  and a URI needs no options.

Tom Petch

<snip>

---

From: "Michael Wojcik" <[email-masked]>
Date: Sat, 27 Nov 2010 07:30:10 -0800

> Sent: Friday, 26 November, 2010 10:04
> >
> > that could usefully be represented in a URI. LU name, terminal type
> > and model, and printer association, for example; those are all
things
> > that TN3270 clients typically let the user configure.
> 
> you precisely that, even if, colloquially, they are not called TN3270
> but TN3270E.

I'm afraid not.

First, LU name and printer association are determined by the user, and
so they can't be negotiated. The user agent and service provider have no
way of knowing what LU or printer name the user wishes to use, unless
the user's specified it. A URI would be one way of specifying it.
Similarly, extant TN3270 clients let users configure model information
precisely because they don't always want what the client and server
would otherwise negotiate; a URI could also specify that.

Second, 1646 is not part of TN3270E, even though it was defined by
members of the TN3270E Working Group. It's an informational RFC that
defines a pair of possible extension mechanisms to Classic TN3270.
TN3270E didn't even exist when 1646 was published (since it was first
defined by 1647), and 1646 explicitly describes Classic TN3270
negotiation and flows.

Third, 1647 is obsolete. TN3270E is currently defined by RFC2355. And
it, too, cannot negotiate that which is not negotiable.
 
> I stand by my first statement, that you can negotiate anything you
need
> with TN3270  and a URI needs no options.

And you're wrong. Have you implemented TN370? I have - client and
server, classic and enhanced. I also understand how LU names and printer
association work.

A trivial specification for the tn3270 URI scheme would be fine. It'd
provide a starting point for a real specification, if there is any
interest in creating one. But relegating it to a (hypothetical) new
category of "protocols with no possible URI parameters other than scheme
and authority" is inaccurate. There *are* other possible URI parameters
for a tn3270 URI scheme, and so it ought to have its own specification,
if it is to be specified at all.