IETF Logo Mail Archive

Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts-02.txt> (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard

Mykyta Yevstifeyev <evnikita2@gmail.com> Sat, 25 June 2011 04:31 UTC

Return-Path: <evnikita2@gmail.com>
X-Original-To: ftpext@ietfa.amsl.com
Delivered-To: ftpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B811121F84F8; Fri, 24 Jun 2011 21:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.47
X-Spam-Level:
X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDa11LNb0elr; Fri, 24 Jun 2011 21:31:54 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 780EE21F84F7; Fri, 24 Jun 2011 21:31:53 -0700 (PDT)
Received: by fxe6 with SMTP id 6so200502fxe.31 for <multiple recipients>; Fri, 24 Jun 2011 21:31:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GF1rzVnsRBczTDx6kW8TaPZOfwy7Yi9gn0dMt4AdoMQ=; b=TaaEWxHBNi64psZ6g9H5CTx6FvPqropt9J22QBf3mb/X8SElIwEIXSZaqjO6+D2AIJ /NDnexpq/H6sAF99a5BTtA4UbKJHvdkRoGDx+ahwhBQdboCX9EkE9Xky8w6aaTkVH5qm GsAg2Fia78XnfIEHd+0Oq/vb6T3Q/KWG4l8tA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gmqVZvIbj4tn27vQgA8e5duDEnotcAArMBJZBoY7iaKsIM6vcwfqd0tbqPlGXntOT8 z6bl8fc6zMGihBgPcpW0F3ra3HRV0ldwWRJKwwG1VKN+317iGLHEQmIo9j9bD5c8OaNR t3Te7/8+s770/dVdzFJ1xyN1as97FnKXv3/CQ=
Received: by 10.223.2.205 with SMTP id 13mr5423912fak.138.1308976312554; Fri, 24 Jun 2011 21:31:52 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id m26sm2031357fab.34.2011.06.24.21.31.50 (version=SSLv3 cipher=OTHER); Fri, 24 Jun 2011 21:31:51 -0700 (PDT)
Message-ID: <4E0564E4.9010200@gmail.com>
Date: Sat, 25 Jun 2011 07:32:36 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Robert McMurray <robmcm@microsoft.com>
References: <20110616130503.4854.51928.idtracker@ietfa.amsl.com> <4E04C0CE.1030807@gmail.com> <01AA9EC92749BF4894AC2B3039EA4A2C1949D19E@CH1PRD0302MB131.namprd03.prod.outlook.com>
In-Reply-To: <01AA9EC92749BF4894AC2B3039EA4A2C1949D19E@CH1PRD0302MB131.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "ftpext@ietf.org" <ftpext@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts-02.txt> (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jun 2011 04:31:54 -0000

24.06.2011 22:08, Robert McMurray wrote:
> Thanks, Mykyta.
>
> Section 3.3 already addresses that scenario in the second paragraph - and the server behaviors are exactly what you were suggesting:
>
>     As discussed in section 3 of this document, if a HOST command is sent
>     after a user has been authenticated the server SHOULD do one of the
>     following:
>
>     a.  Send a 503 reply for an invalid sequence of commands.
>
>     b.  Treat the HOST command as though a REIN command was sent and
>         reset the user-PI to the state that existed after the previous
>         HOST command was sent and before the user had been authenticated,
>         and then return the appropriate reply for the HOST command.
OK, and if HOST is sent for the second time when the user hasn't got 
authenticated, eg.

S> 220 Server ready
C> HOST example.com
S> 220 HOST OK
C> HOST example.org
S> ???

I suppose it may be 503 reply or switching to the identified host with 
220 reply.  This situation isn't mentioned in your document.

Mykyta Yevstifeyev
> Thanks again!
>
> Robert McMurray
>
> -----Original Message-----
> From: Mykyta Yevstifeyev [mailto:evnikita2@gmail.com]
> Sent: Friday, June 24, 2011 9:53 AM
> To: ietf@ietf.org; ftpext@ietf.org
> Subject: Re: [ftpext] Last Call:<draft-ietf-ftpext2-hosts-02.txt>  (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard
>
> Hello,
>
> This document is well written; I'm strongly for its publication on Standards Track.  I have an only remark.  This document doesn't seem to mention what is the behavior of the server if HOST command is sent after one HOST has already been sent.  Eg.
>
> C>  HOST example.com
> S>  220 Host OK
> C>  USER foo
> S>  331 Specify password
> C>  PASS bar
> S>  230 Logged in
> C>  HOST example.org
> S>  ????
>
> I suppose the server may treat this as REIN and then switching to specified host, if the user is authenticated, and just switch to such host if the user isn't already logged in.  Another option is sending 503 reply, as invalid sequence of commands.
>
> Thanks,
> Mykyta Yevstifeyev
>
>
>

v2.23.0 | Report a Bug | By Email