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

[Mykyta Yevstifeyev <[e-mail]>]

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

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 uri.arpa list.
> Maybe the IESG could subscribe an "archive account" to get a
> public archive of this obscure IANA list.
> -Frank
>