Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt

Mykyta Yevstifeyev
I've just uploaded a new version of draft-yevstifeyev-ftp-uri-scheme.  
Any further comments are welcome.  Mykyta

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> Title           : The'ftp' URI Scheme
> Author(s)       : Mykyta Yevstifeyev
> Filename        : draft-yevstifeyev-ftp-uri-scheme-04.txt
> Pages           : 22
> Date            : 2011-07-07
>
>     This document specifies the'ftp' Uniform Resource Identifier (URI)
>     scheme, which is used to refer to resources accessible via File
>     Transfer Protocol (FTP).  It updates RFC 959 and RFC 1738.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-yevstifeyev-ftp-uri-scheme-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-yevstifeyev-ftp-uri-scheme-04.txt

Reply | Threaded
Open this post in threaded view
|

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

Frank Ellermann-3
On 7 July 2011 16:54, Mykyta Yevstifeyev wrote:

>> draft-yevstifeyev-ftp-uri-scheme-04.txt

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.  In the security considerations please note
again and explicitly that user:pass (for user != anonymous) is
not more state of the art.

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.

In section 2.3 you apparently want IRIs, that would be RFC 3987
instead of 3986.

Somewhere you should explain that FTP URIs have no query part.
Any "?" or "#" meant to be used in the path has to be encoded.

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).

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

Reply | Threaded
Open this post in threaded view
|

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

John C Klensin

--On Friday, July 08, 2011 19:37 +0200 Frank Ellermann
<[hidden email]> wrote:

> On 7 July 2011 16:54, Mykyta Yevstifeyev wrote:
>
>>> draft-yevstifeyev-ftp-uri-scheme-04.txt
>...
> 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.

Disagree.  If I'm an FTP repository provider, I can ask you to
give up your email address in return for service if I want to.
Whether I trust the address you give me is another matter, but
that isn't a privacy issue.

>...

I've already expressed my concerns about a number of other
components of this scheme.

    john




Reply | Threaded
Open this post in threaded view
|

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

sm-7
In reply to this post by Frank Ellermann-3
Hi Frank,
At 10:37 08-07-2011, Frank Ellermann wrote:
>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.

   'Anonymous FTP is a means by which archive sites allow general access
    to their archives of information.  These sites create a special
    account called "anonymous".'

   'Providing an e-mail address is a courtesy that allows archive
    site operators to get some idea of who is using their services.'

That's from FYI 24.

Regards,
-sm



Reply | Threaded
Open this post in threaded view
|

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

Frank Ellermann-3
In reply to this post by John C Klensin
On 8 July 2011 19:46, John C Klensin <[hidden email]> wrote:

>> 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.

> Disagree.  If I'm an FTP repository provider, I can ask you to
> give up your email address in return for service if I want to.
> Whether I trust the address you give me is another matter, but
> that isn't a privacy issue.

Your server, your rules.  Nevertheless user agents such as web
browsers MUST NOT use valuable email accounts in anonymous FTP
connections without explicit consent of the user.  I don't think
that address harvesting by spammers on anonymous FTP servers is a
serious threat, but "anonymous" should be what the name says, as
long as the user didn't explicitly set something else.

If your FTP server does not accept anonymous:[hidden email]
it is fine, I'd know how to use another FTP client where I can
add one of the addresses you know.  But exactly these addresses
should not be used in anonymous connections with arbitrary FTP
servers, unless I explicitly confirmed it for a given server.

-Frank

Reply | Threaded
Open this post in threaded view
|

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

Frank Ellermann-3
In reply to this post by sm-7
On 8 July 2011 19:57, SM <[hidden email]> wrote:

>| Providing an e-mail address is a courtesy that allows archive
>| site operators to get some idea of who is using their services.

> That's from FYI 24.

RFC 1635, vintage 1994.  Apparently something that should go the
way of the Dodo together with the long obsolete "netiquette RFC".

In this millennium security and privacy and i18n are IMO not
optional, it is not more the same internet as in 1994 (when I
was still mostly using FidoNet and Videotex, or rarely NetNews).

I vaguely recall that "privacy considerations" (in addition to
the existing "IANA" / "i18n" / "security" considerations) were
proposed, or was that a "privacy directorate"?

I'd like to have "privacy considerations" in all future I-Ds -
it could be merged with the "security considerations" or even
omitted as beside the point depending on the final RFC, but an
indication in I-Ds that the authors "considered privacy" like
"security" or "i18n" or "IANA" would be good.  If authors then
decide that this is bureaucratic nonsense to be ignored for
their purposes it worked as designed:  At least they spent the
milliseconds to think about it.

-Frank

Reply | Threaded
Open this post in threaded view
|

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

Mykyta Yevstifeyev
In reply to this post by Frank Ellermann-3
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
>


Reply | Threaded
Open this post in threaded view
|

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

Frank Ellermann-3
On 9 July 2011 05:34, Mykyta Yevstifeyev wrote:

Skipping the i18n and security considerations until I see
a new I-D one quick addition:

>> an unencoded "#" starts the fragment and is interpreted
>> (or ignored) by clients depending on the document.
[...]
> This will also be included in the draft.

Thanks.  My comment almost missed the point, the fragment
depends on the document <add> type, it does not depend on
the URI scheme </add>.  In the times of "hashbang URIs" it
might be necessary to be as clear as possible about this:

Fragments are one of the subtle differences between STD 66
and its predecessors (incl. RFC 1738).

For my privacy concerns pick something that does not upset
John or SM -- I'm almost sure that we want the same thing
from different points of view (server admin vs. FTP user,
with "popular" browsers hiding or not offering any choice).

Reply | Threaded
Open this post in threaded view
|

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

Mykyta Yevstifeyev
09.07.2011 13:58, Frank Ellermann wrote:

> On 9 July 2011 05:34, Mykyta Yevstifeyev wrote:
>
> Skipping the i18n and security considerations until I see
> a new I-D one quick addition:
>
>>> an unencoded "#" starts the fragment and is interpreted
>>> (or ignored) by clients depending on the document.
> [...]
>> This will also be included in the draft.
> Thanks.  My comment almost missed the point, the fragment
> depends on the document<add>  type, it does not depend on
> the URI scheme</add>.  In the times of "hashbang URIs" it
> might be necessary to be as clear as possible about this:
>
> Fragments are one of the subtle differences between STD 66
> and its predecessors (incl. RFC 1738).
OK, this will be clarified.
>
> For my privacy concerns pick something that does not upset
> John or SM -- I'm almost sure that we want the same thing
> from different points of view (server admin vs. FTP user,
> with "popular" browsers hiding or not offering any choice).
I think I'll find corresponding approach to address these concerns in -05.

Thanks,
Mykyta Yevstifeyev
>