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

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 <ietfc@btconnect.com>:
> ----- Original Message -----
> From: "Michael Wojcik" <Michael.Wojcik@microfocus.com>
> To: <uri-review@ietf.org>; <apps-discuss@ietf.org>
> Cc: "Alfred HÎnes" <ah@TR-Sys.de>
> Sent: Tuesday, November 23, 2010 3:48 PM
>
>> From: uri-review-bounces@ietf.org [mailto:uri-review-bounces@ietf.org]
>> 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
>> > "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.
>
> 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.
>
> <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).
>
> 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
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review
>