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

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 07 Jul 2011 17:54:13 +0300

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&#39;ftp&#39; URI Scheme
> 	Author(s)       : Mykyta Yevstifeyev
> 	Filename        : draft-yevstifeyev-ftp-uri-scheme-04.txt
> 	Pages           : 22
> 	Date            : 2011-07-07
>
>     This document specifies the&#39;ftp&#39; 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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 8 Jul 2011 19:37:18 +0200

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Jul 2011 13:46:32 -0400

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

>...

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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 8 Jul 2011 21:29:05 +0200

> 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:[email-masked]
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

---

From: SM <[email-masked]>
Date: Fri, 08 Jul 2011 10:57:06 -0700

Hi Frank,
>for privacy reasons, unless it is a mail address in TLD invalid

   '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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 8 Jul 2011 22:04:54 +0200

On 8 July 2011 19:57, SM <[email-masked]> 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

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 09 Jul 2011 06:34:20 +0300

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

Thanks for your comments.  My responses are in-line.
> it in this draft.
I'll mention this.
>    In the security considerations please note
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]).
> for privacy reasons, unless it is a mail address in TLD invalid
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
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.
> 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.
> encoded "#", fragment "#" - if you like RFC 5147 use it in a fragment example).
This will also be included in the draft.

Mykyta Yevstifeyev

---

From: SM <[email-masked]>
Date: Sat, 09 Jul 2011 02:15:31 -0700

Hi Frank,

It's nice to see you back.

>proposed, or was that a "privacy directorate"?

There is a privacy directorate.

Regards,
-sm

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 9 Jul 2011 12:58:09 +0200

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

---

From: SM <[email-masked]>
Date: Sat, 09 Jul 2011 10:09:09 -0700

Hi Frank,

I added a Cc to the ietf-privacy mailing list.  I suggest using that 
mailing list for further discussion.

>milliseconds to think about it.

draft-morris-policy-cons-00 discusses about Policy Considerations for 
Internet Protocols.  There is another I-D, 
draft-morris-privacy-considerations-03, that discusses about  Privacy 
Considerations for Internet Protocols.

The term "Network Access Identifier" is used in RFC 4282; it is the 
user identity submitted by the client during network access 
authentication.  A common identifier which is picked for user 
authentication is an email address as it offers uniqueness and it is 
easy for the user to remember.  That has privacy 
implications.  Disallowing "anonymous" (FTP) as the user name and the 
email address as the password does not solve the problem as 
credentials are required to access a protected resource.

Reality check, some users will:

  (i)   provide their email address

  (ii)  use [email-masked]

  (iii) pick a random email address which does not belong to them

The is ongoing work in the OAUTH WG on access to a protected resource 
using an intermediary which provides the access token.  That's one 
way to deal with the question of providing credentials to an unknown party.

draft-mayer-do-not-track-00 discusses about a HTTP header-based 
mechanism for users to express their preferences about 
tracking.  draft-vandergaast-edns-client-ip defines an EDNS0 
extension to carry relevant (client) network range information.

If you do not provide information within the layer, the information 
will be gleaned from other layers.  There are times when user consent 
is an explicit decision about the information to provide (see reality 
check) and there are times when it is an implicit decision; e.g. the 
terms of service that the user did not read.

If you would like to have "privacy considerations" in all future 
I-Ds, the above could get you started.

Regards,
-sm

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 09 Jul 2011 21:03:03 +0300

09.07.2011 13:58, Frank Ellermann wrote:
> depends on the document<add>  type, it does not depend on
> the URI scheme</add>.  In the times of "hashbang URIs" it
OK, this will be clarified.
> 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

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 11 Jul 2011 20:27:12 +0300

Hello,

You should have noticed the Appendix A of this document regarding use of 
DDDS with 'ftp' URIs.  After some discussions on [email-masked] list, 
which I managed to arrange (which can be confirmed by Frank Ellermann as 
messages are not archived there), we have reached a consensus (at least 
no-one objected) to change the substitutions expression in NAPTR record 
for ftp.uri.arpa domain from

> !^ftp://([^:/?#]*).*$!\\1!i

to

> !^ftp://(.*@)?([^:/?#]*).*$!\\2!i 

This message is to notify folks on apps-discuss (the number of which I 
believe is much more numerous) about this "consensus".  However, any 
further comments are welcome.

Mykyta Yevstifeyev

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 14 Jul 2011 03:48:33 +0200

>> !^ftp://(.*@)?([^:/?#]*).*$!\\2!i

Sorry, I sent my comment to the uri.arpa list before I saw your
summary here.  Here's my proposal based on the discussion there:

   !^ftp://([^@/?#]*@)?([^:/?#]*).*$!\\2!i

-Frank

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 14 Jul 2011 06:29:47 +0300

Frank,

I think I'll move the discussion here.  The following is your posting to 
[email-masked]:

> 2011/7/10 Mykyta Yevstifeyev:
>
>>> That can be simplified to:
>>>    !^ftp://([^@]*@)?([^:/?#]*).*$!\\2!i
>> I agree with you here.  Yet, actually this may be simplified
>> far to

I don't agree with such expression.  See justification below.

> Is "anything ending with '@'" (in your version) the same as
> "any non-'@' ending with the first '@'" (in JimC's version)?
> For clarity I'd prefer the first version, but maybe we are
> not yet ready:
>
>> "@" chars are not generally allowed in in<userinfo>  without
>> percent encoding, as well as in other parts of the URI.
> As soon as you are behind the<userinfo>  in an<authority>
> it is not more necessary to percent-encode '@'.  I'm too lazy
> to check it, but I guess that '@' is an ordinary<pchar>, and
> also allowed in query parts and fragments.

"@" is in <gen-delims>, so we can safely assume that it won't apper 
anywhere else except the authority non-percent-encoded.  As "@"s aren't 
allowed in <userinfo> as by RFC 3986 and my document, it is also assumed 
that there will be no "@" chars before the "@" delimiting userinfo from 
host (if, we can they assume that the second "@" is a part of <host>, 
which isn't allowed as well).  So, "@" will normally occur only 1 time, 
and won't occur in the <userinfo> itself, query or fragment identifier.

>
> After all mailto: and news: URLs use '@' for their purposes
> outside of<userinfo>.
>
> Therefore we might need something in the direction of...
> ...matching '@' only before any path or query or fragment.
> [^@/?#]* should match the colon in a user:pass<userinfo>.

This would make sense if "@" was in <sub-delims>.  See above.

So as a summary: The expression

> !^ftp://([^@]*@)?([^:/?#]*).*$!\\2!i

is sufficient enough to match RFC 3986 and this particular URI scheme.

Mykyta

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 15 Jul 2011 01:44:37 +0200

On 14 July 2011 05:29, Mykyta Yevstifeyev wrote:

> "@" is in <gen-delims>, so we can safely assume that it won't
> apper anywhere else except the authority non-percent-encoded.

Quoting RFC 3986 section 3.3, page 23:

 segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                   ; non-zero-length segment without any colon ":"

 pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

That allows an unencoded '@' in the <path>, not the '@' you are
interested in while trying to skip any <userinfo>@.

 query         = *( pchar / "/" / "?" )

Ditto, unencoded '@' in the <query> (section 3.4, page 24).

  fragment     = *( pchar / "/" / "?" )

Ditto, unencoded '@' in the <fragment> (section 3.5, page 24).

> it is also assumed that there will be no "@" chars before the
> "@" delimiting userinfo from host

ACK, all parts of the <authority> including odd beasts such as
a <reg-name> or <IPvFuture> do not permit unencoded '@' (apart
from the <userinfo>@ case).

> So, "@" will normally occur only 1 time, and won't occur in
> the <userinfo> itself, query or fragment identifier.

See above wrt <path>, <query>, and <fragment>.  I recall that
it took me more than a year to grok the fine print in STD 66.

-Frank

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 15 Jul 2011 06:44:29 +0300

15.07.2011 2:44, Frank Ellermann wrote:
>> "@" is in<gen-delims>, so we can safely assume that it won't
> That allows an unencoded '@' in the<path>, not the '@' you are
> interested in while trying to skip any<userinfo>@.
>
> Ditto, unencoded '@' in the<query>  (section 3.4, page 24).
>
> Ditto, unencoded '@' in the<fragment>  (section 3.5, page 24).
I see what you mean.  I'll correct the expression as you proposed.  
However, I actually don't understand why "@" is either in <gen-delims>, 
which is in <reserved> and doesn't allow it to be present in queries and 
fragments, and in <pchar>, which is OK with this?
> [ . . . ]
> See above wrt<path>,<query>, and<fragment>.  I recall that
Mykyta Yevstifeyev

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 15 Jul 2011 13:02:10 +0900

Hello Mykyta,

> fragments, and in <pchar>, which is OK with this?

It has to do with the fact that some software components processing URIs 
and their componests have no scheme-specific knowledge, whereas others 
do. Please read the text after the
     reserved    = gen-delims / sub-delims
ABNF rule in RFC 3986.

Regards,    Martin.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 16 Jul 2011 03:24:55 +0200

On 15 July 2011 06:02, "Martin J. Dürst" wrote:

> Please read the text after the

Okay, but it doesn't explain the "lost" <national> in RFC 1738:
 national = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`"
This "forbidden" set was later reduced to <unwise> in RFC 2396:
 unwise   = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"

Skipping RFC 2732 introducing IPv6 literals using "[" and "]"
RFC 3986 does not explain that some unencoded US-ASCII char.s
are never permitted in URIs: "{" | "}" | "|" | "\" | "^" | "`"

And the "new" unencoded <gen-delims> "[" / "]" are only allowed
for "IPvNot4" literals in the <host> part of the <authority>,
no matter what any specific URI schemes such as RFC 6068 or
specific fragment specifications such as RFC 5147 might wish.

Unrelated, it is rather annoying that the IE and Chrome folks
have not yet implemented RFC 5147, this nice feature should
take the proverbial "five minutes" for a developer.

-Frank

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 16 Jul 2011 16:57:24 +0900

On 2011/07/16 10:24, Frank Ellermann wrote:
> Okay, but it doesn't explain the "lost"<national>  in RFC 1738:

At that time, various versions of ISO 646 were still in use (or at least 
feared to still be in use) which would have meant that these codepoints 
would have shown up as different glyphs in some environments (e.g. 
äöüÄÖÜß in the German version of ISO 646). As time moved on, this kind 
of concern grew smaller and smaller.

> This "forbidden" set was later reduced to<unwise>  in RFC 2396:

Well, yes, it's the spec for URIs, not for "what's not allowed in URIs".

> And the "new" unencoded<gen-delims>  "[" / "]" are only allowed
> for "IPvNot4" literals in the<host>  part of the<authority>,

That "[" / "]" can only be used for IPv6 addresses and the like is 
definitely somewhat inconsistent. If there ever were an update of RFC 
3986, I can imagine that to be changed (but that's only a guess).

> take the proverbial "five minutes" for a developer.

Does that mean that it's implemented in Firefox and Opera? That would be 
great to hear. For Chrome, you could submit a bug or patch to webkit, I 
guess.

Regards,    Martin.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 16 Jul 2011 10:50:03 +0200

> Well, yes, it's the spec for URIs, not for "what's not allowed

Okay - but not very helpful for folks trying to "upgrade" older
spec.s based on RFC 1738 to something based on RFC 3986/3987, or for
developers trying to filter completely bogus URIs.

The older RFCs had a nice <uric> rule for this purpose.  My list
above was incomplete, I forgot (at least) "<" / ">" / SP / DQUOTE

> That "[" / "]" can only be used for IPv6 addresses and the like
> is definitely somewhat inconsistent. If there ever were an
> update of RFC 3986, I can imagine that to be changed (but that's
> only a guess).

For the pseudo-<path> in news://server/message-ID URIs that was
an obstacle.  But now I'm curious, there is no <path> in mailto:,
and that could allow square brackets in mailto: IPv6 literals...

Yes, RFC 6068 explicitly allows "[" ... "]" in a <domain>, good.

 [about RFC 5147]
> Does that mean that it's implemented in Firefox and Opera?

FF5 test with <http://www.postel.org/ien/txt/ien111.txt#line=1483>

No, sorry.  No opera on my box, that will be my last resort if I'm
ever annoyed with IE + Chrome + FF at the same time.  But I read
AvK's blog, just in case.

> For Chrome, you could submit a bug or patch to webkit, I guess.

Chromium issue 77024, waiting for "confirmation" since March.  For
IE9 a very complete issue report was closed as "not reproducible",
and I concluded that the IE9+ developers are not too interested
in contributions from IE9+ users.

-Frank

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 16 Jul 2011 12:13:17 +0300

Frank, all,

I've tested with Opera 11.5 - it doesn't seem to work.  Nor does Safari 
3.2.1 for Windows.

Regarding FF - I submitted Bug 662583 
(https://bugzilla.mozilla.org/show_bug.cgi?id=660583) a while ago 
reporting this issue.  I don't know whether and when it is going to be 
processed.

Mykyta

16.07.2011 11:50, Frank Ellermann wrote:
> FF5 test with<http://www.postel.org/ien/txt/ien111.txt#line=1483>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 16 Jul 2011 12:22:46 +0300

16.07.2011 10:57, "Martin J. Dürst" wrote:
> At that time, various versions of ISO 646 were still in use (or at 
> least feared to still be in use) which would have meant that these 
> codepoints would have shown up as different glyphs in some 
> environments (e.g. äöüÄÖÜß in the German version of ISO 646). As time 
> moved on, this kind of concern grew smaller and smaller.
BTW, I also recall something like this in RFC 20, eg.:

>     5/13        ]           Closing Bracket [3]
> [etc.]
> [...]
>     ------
>        3 These characters should not be used in international interchange
>     without determining that there is agreement between sender and
>     recipient.
Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Sat, 16 Jul 2011 11:30:20 +0200

> reporting this issue. I don't know whether and when it is going to be

"Patches welcome"?