[register] Request to change the NAPTR record for ftp.uri.arpa
Hello, I'm currently working in 'ftp' URI scheme specification. Having found the following message: http://www.iana.org/protocols/archives/register-uri/msg00005.html I noticed the inconsistence of recorded NAPTR record with the actual deployed scheme syntax (and including that I'm trying to document in http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-04). What I mean is that substitution expression like:
!^ftp://([^:/?#]*).*$!\\1!i
Additionally to host-name extracts the userinfo part of an URI, so that <ftp://exmaple:foo@exmaple.com:523/bar> will result in "exmaple:foo@exmaple.com" extracted from an URI as a next key. This isn't a valid DNS name. Therefore, I'm planning to request IANA to change this expression to
!^ftp://([^@]*)([^:/?#]*).*$!\\2!i
in my next revision of the draft. This document will undergo IESG approval, so there is no concerns with change controller with this NAPTR record. However, prior to this I'd like to request community feedback on this change. I'm citing the corresponding Appendix of the draft which intends to make this change as well as IANA considerations with this respect.
Appendix A. Dynamic Delegation Discovery System (DDDS) and 'ftp' URIs
Dynamic Delegation Discovery System (DDDS) is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. The comprehensive DDDS specification consists of 5 documents, which are defined in RFC 3401 [RFC3401].
RFC 3404 [RFC3404] specified a DDDS Application for resolving URIs using DDDS Algorithm defined in RFC 3402 [RFC3402]. A corresponding second-level domain has been delegated in the "arpa" zone [RFC3172] - "uri.arpa" [RFC3405] - for use with this Application. RFC 3404 specified that First Well Known Rule for the aforementioned DDDS Application is to append the URI scheme name to ".uri.arpa". According to the provisions of RFC 3405 [RFC3405], the 'ftp' URI scheme was previously approved for inclusion in this zone [MSG-REG] in order to allow its resolving using DDDS. Correspondingly, the following substitution expression was recorded in the NAPTR DNS resource record [RFC3403]:
!^ftp://([^:/?#]*).*$!\1!i
using the syntax defined in Section 3.2 of RFC 3402. However, taking the syntax specified in this document, IANA is asked to record the following new substitution expression in the NAPTR record for ftp.uri.arpa domain:
!^ftp://([^@]*)([^:/?#]*).*$!\2!i
This substitution expression extracts the hostname from a given URI, forming the next Key.
Refer to RFC 3404 for detailed description of DDDS Application for resolving URIs and RFC 3402 for generic DDDS Algorithm.
Please note that while there is a possibility to resolve 'ftp' URIs using DDDS, not every given 'ftp' URI may be resolved using this technique. A specific "hint" is required in order to denote this; for instance, "the URI <ftp://exmaple.org/foo/bar.txt> refers to the very valuable information; it is mirrored at a number of servers which are to be discovered using DDDS".
Here [MSG-REG] refers to the above-referenced message. Corresponding IANA considerations are:
5.3. Maintaining ftp.uri.arpa Domain
As primarily requested by [MSG-REG] per RFC 3405 [RFC3405], IANA will continue maintaining the ftp.uri.arpa domain for use of DDDS with 'ftp' URIs (see Appendix A). Moreover, IANA is requested to change the existing substitution expression in the NAPTR record for this domain as described in Appendix A.
Any comments from DDDS experts are invited and welcome. Thanks in advance, Mykyta Yevstifeyev
On 10 July 2011 11:33, Mykyta Yevstifeyev wrote:
!^ftp://([^@]*)([^:/?#]*).*$!\\2!i
Yes, the regexp apparently could be improved, but I don't understand the syntax details. Or rather, I see that your syntax should be okay if there is a valid "@" in the URI. Why does it also work if there is no "@" at all? BTW, I think the total number of users reading this list is two. -Frank
10.07.2011 12:53, Frank Ellermann wrote:
On 10 July 2011 11:33, Mykyta Yevstifeyev wrote:
!^ftp://([^@]*)([^:/?#]*).*$!\\2!i Yes, the regexp apparently could be improved, but I don't understand the syntax details. Or rather, I see that your syntax should be okay if there is a valid "@" in the URI. Yes, there probably is a mistake here. I think the following expression will be better:
!^ftp://(([^@]*)@)?([^:/?#]*).*$!\\3!i This will also eliminate your concern below.
Why does it also work if there is no "@" at all? BTW, I think the total number of users reading this list is two. Probably that's true.
Mykyta
-Frank
"MY" == Mykyta Yevstifeyev <evnikita2@gmail.com> writes:
MY> Yes, there probably is a mistake here. I think the following MY> expression will be better:
!^ftp://(([^@]*)@)?([^:/?#]*).*$!\\3!i
That can be simplified to: !^ftp://([^@]*@)?([^:/?#]*).*$!\\2!i -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
10.07.2011 17:19, James Cloos wrote:
"MY" == Mykyta Yevstifeyev<evnikita2@gmail.com> writes: MY> Yes, there probably is a mistake here. I think the following MY> expression will be better:
!^ftp://(([^@]*)@)?([^:/?#]*).*$!\\3!i That can be simplified to:
!^ftp://([^@]*@)?([^:/?#]*).*$!\\2!i I agree with you here. Yet, actually this may be simplified far to !^ftp://(.*@)?([^:/?#]*).*$!\\2!i as "@" chars are not generally allowed in in <userinfo> without percent encoding, as well as in other parts of the URI. It is in <gen-delims>. So, I think the aforementioned expression will be requested in my document.
If there are no objections, I'll notify the consensus to apps-discuss list. Mykyta Yevstifeyev
-JimC
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
!^ftp://(.*@)?([^:/?#]*).*$!\\2!i
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. After all mailto: and news: URLs use '@' for their purposes outside of <userinfo>. Therefore we might need something in the direction of... !^ftp://([^@/?#]*@)?([^:/?#]*).*$!\\2!i ...matching '@' only before any path or query or fragment. [^@/?#]* should match the colon in a user:pass <userinfo>. -Frank
participants (3)
-
Frank Ellermann -
James Cloos -
Mykyta Yevstifeyev