Re: [apps-discuss] sftp Re: Request for Review - draft-yevstifeyev-rlogin-uri-00

John C Klensin <> Thu, 03 February 2011 19:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B8873A67EB for <>; Thu, 3 Feb 2011 11:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.92
X-Spam-Status: No, score=-102.92 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y7MPuERZyvRT for <>; Thu, 3 Feb 2011 11:36:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 439D03A67B0 for <>; Thu, 3 Feb 2011 11:36:35 -0800 (PST)
Received: from [] (helo=localhost) by with esmtp (Exim 4.34) id 1Pl525-000FQB-GL; Thu, 03 Feb 2011 14:39:57 -0500
Date: Thu, 03 Feb 2011 14:39:56 -0500
From: John C Klensin <>
To: "t.petch" <>
Message-ID: <FD39FCAE4F422F0292959EC6@PST.JCK.COM>
In-Reply-To: <012101cbc3c1$bda06120$>
References: <> <F53A46A23D8CBE34742675AB@PST.JCK.COM> <012101cbc3c1$bda06120$>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [apps-discuss] sftp Re: Request for Review - draft-yevstifeyev-rlogin-uri-00
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Feb 2011 19:36:36 -0000

--On Thursday, February 03, 2011 17:45 +0100 "t.petch"
<> wrote:

> John
> A propos sftp, there was a joint ssh/sftp I-D in the secssh WG
> but it fell by the wayside for lack of support in the WG.  The
> ssh part made it to IETF Last Call last November and, 50 days
> later, the status is revised I-D needed.

And so?

If I ran the IETF, a lot of priorities would probably be
different.  I don't, and that is probably a good thing for all
of us, myself included.   

I was only trying to make one point, which is that I think we
should be a lot more concerned about URIs for older protocols
that retrieve or deliver things than about URIs that merely
start interactive sessions.   Simply having a URI for the FooBar
protocol is unlikely to cause even one more user-level system to
implement the underlying protocol.  Worse, it might even cause
what I think is the worst case -- a half-baked, insecure, and
sloppy implementation to conform to a checklist.

So, for old protocols, I think we should be asking the questions:

	(1) Does anyone care about the underlying protocol any
	(2) Do we want to encourage the implementation and use
	of that protocol on the public Internet and is the URI
	definition satisfactory for that purpose?
	(3) Would the URI actually enable some useful
	functionality rather than just providing an alternate
	syntax for starting some command or subsystem?

For sftp and its close relatives, I think the answer to all
three questions is "yes", even if the secssh WG either doesn't
agree or doesn't see there as being work on it that the IETF
needs to do.

For rlogin, I'd give a weak "yes" to the first question
--certainly the thing is in active use on a lot of LANs-- but
I'd give a negative answer to the other two.

But those are just my opinion.