Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt

Mykyta Yevstifeyev <> Sat, 09 July 2011 03:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A75911E8090 for <>; Fri, 8 Jul 2011 20:33:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.924
X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LGGT+FOZsXcF for <>; Fri, 8 Jul 2011 20:33:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 48AC411E8089 for <>; Fri, 8 Jul 2011 20:33:37 -0700 (PDT)
Received: by fxe4 with SMTP id 4so3275229fxe.27 for <>; Fri, 08 Jul 2011 20:33:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TdRC1WngBCInOiE8lDJ780IXOKdg0TJSBVvFX5+HV8E=; b=gswLuunbURk4n9T+xYXYqrUXO19FbbnXpHdQ6sa1yWyIt5HCZ3bA89XEjS/ks+h3EY 5MHI1upjPDP0zhp+QFaLfUrqQhNa0kLBhWlByFqs+G4UvUb0u89hZl/x5L0Sf756EeF5 +cIoOZlKLbHHTabd91iLcuG8+Ubz38bC+je0Y=
Received: by with SMTP id o3mr4078286faa.53.1310182416313; Fri, 08 Jul 2011 20:33:36 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id b3sm7742357fao.44.2011. (version=SSLv3 cipher=OTHER); Fri, 08 Jul 2011 20:33:34 -0700 (PDT)
Message-ID: <>
Date: Sat, 09 Jul 2011 06:34:20 +0300
From: Mykyta Yevstifeyev <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Frank Ellermann <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: URI <>, Apps-discuss list <>
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 09 Jul 2011 03:33:38 -0000

08.07.2011 20:37, Frank Ellermann wrote:
> On 7 July 2011 16:54, Mykyta Yevstifeyev wrote:
>>> draft-yevstifeyev-ftp-uri-scheme-04.txt

Thanks for your comments.  My responses are in-line.
> Hi, this draft is apparently very near to ready.  Hopefully that
> is also the case for the normative reference to an FTP extension,
> otherwise a published FTP URI RFC would be better than a blocked
> I-D waiting for the extension.
> The "motd" example in RFC 1738 is very instructive, please adopt
> it in this draft.
I'll mention this.
>    In the security considerations please note
> again and explicitly that user:pass (for user != anonymous) is
> not more state of the art.
I've mentioned this.  The following new paragraph was added:

    Because of some concerns RFC 3986 did deprecate the use of
    "user:pass" format of <userinfo>, as stated in Section 2.1; it only
    applies to 'ftp' URIs because of historical reasons.  Obviously,
    those URIs which contain the password "in the clear" should be kept
    and transmitted securely (for example, using Transport Layer Security
    (TLS) [RFC5246]).
> The anonymous:mail construct is also not more state of the art
> for privacy reasons, unless it is a mail address in TLD invalid
> or similar.
OK.  The following paragraph was added:

    The "anonymous FTP" [RFC1635] has a number of security implications,
    too.  When transmitting the email address as a password, if it is
    required by the server, there is a risk of email address harvesting
    by "middle-boxes" (man-in-the-middle attacks) and the ultimate
    server.  As servers usually do not pay attention to such passwords,
    clients are encouraged to transmit email addresses with the domain
    names which are those described in RFC 2606 [RFC2606].

> In section 2.3 you apparently want IRIs, that would be RFC 3987
> instead of 3986.
To address this comment, I've replaced the 1st paragraph with:

    The parts of 'ftp' URIs may contain characters from ASCII character
    set which are allowed in the corresponding parts.  Those characters
    which are excluded from the allowed characters for a particular part
    SHALL be encoded within this part.

    A valid 'ftp' IRI [RFC3987] may contain characters from Universal
    Character Set (UCS) [UCS], first encoded using UTF-8 [RFC3629].  In
    order such characters may be present in 'ftp' URIs, a valid 'ftp' IRI
    should be mapped to the URI as described in Section 3.1 of RFC 3987.
> Somewhere you should explain that FTP URIs have no query part.
> Any "?" or "#" meant to be used in the path has to be encoded.
I'll add a section on queries and fragments in the 'ftp' URIs.
> OTOH FTP URIs do have fragments, an unencoded "#" starts the
> fragment and is interpreted (or ignored) by clients depending
> on the document.  Just repeating what RFC 3986 already says
> might be boring, but you could offer examples (encoded "?",
> encoded "#", fragment "#" - if you like RFC 5147 use it in a fragment example).
This will also be included in the draft.

Mykyta Yevstifeyev
> JFTR, I can confirm that Mykta tried the arguably required
> good faith effort to post to the very obscure list.
> Maybe the IESG could subscribe an "archive account" to get a
> public archive of this obscure IANA list.
> -Frank