RE: Persistent applications-level identifiers, the DNS, and RFC 2428

--On Thursday, 02 October, 2003 10:31 -0700 Michel Py 
<michel(_at_)arneill-py(_dot_)sacramento(_dot_)ca(_dot_)us> wrote:
> John,
>
> > John C Klensin wrote:
> > My ambitious in raising these questions are _very_ limited
> > and, in particular, I don't see this as a back door to
> > solving the non-DNS, topology-independent, persistent
> > identifier problem. (It seems to me that needs to be solved
> > through the front door, or not at all.).
> I'm with you here. So, we know we need something more
> universal, but in the meantime we band-aid FTP to keep going.
> Because of its special status and the fact that it is
> widespread, FTP might justify doing the work for only one
> protocol. It is clear that to be worthy of the effort, this
> should be deployed way before a persistent identifier solution
> is rolled out though.
> As long as I'm not the one doing the work I don't have a
> problem with it :-D
>
> However, I do have a concern: when later a generic identifier
> mechanism is deployed, we will have two standards. Have you
> had any thoughts on the possible collisions there?
My goal is precisely to avoid ending up with either two 
standards or eight verbs.  Explanation of the latter:
     IPv4      IPv6 & self-referent  DNS    StableID
    address       address

RFC    959           2428           ???        ???
Verb  PORT,PASV    EPRT,EPSV     ?DPRT,DPSV? ?IPRT,IPSV?

That seems to me excessive, if we can avoid it.  So the 
suggestion is whether, given that 2428 is at Proposed, maybe it 
would be worth revising it, and the syntax for EPRT and EPSV, to 
_permit_ use of a DNS name now and to provide a clear extension 
path for a generic/stable identifier.
Too many DNS implementations are still having to support the "X" 
forms of the directory changing and modifying commands, and it 
has been a very long time.   All of them will need to support, 
esentially forever, PORT and PASV.  Ending up with eight verbs 
seems to me to be poor architecture, worse interface design, and 
a magnet for poor implementations.
--On Thursday, 02 October, 2003 13:39 -0400 Mark Allman 
<mallman(_at_)icir(_dot_)org> wrote:
> ...
> I think my hit to your narrow question is "no".  Sort of.
>
> It seems to me that the mechanisms defined in rfc2428 are
> working just fine.  Why go monkeying around with them?
I do not want to monkey around with those _mechanisms_.  I am 
objecting only to the syntax, which is extensible only by adding 
more verbs (see below).
>  It
> seems to me that the practical benefits of doing so would be
> quite small.  You may add a bit of flexibility in some cases,
> but you're also going to run up against a raft of new
> problems.  What are the practical benefits that we're going to
> get out of this exercise (i.e., how does this make FTP somehow
> better and not just "prettier" under the hood?).
In the, admittedly rare, situations in which the transfer is 
really third-party, and not even bound tightly to one of the 
other two, passing the domain name of the third host (one that 
is not at either end of the command connection) would seem more 
consistent with general architectural principles.  That seems to 
me to be especially true because, for those cases, the command 
connection host(s) are likely to get the pointer to that host in 
DNS name or URI form, not as an address.  In a world of NATs and 
split-horizon DNS setups (not that I like either), it seems far 
preferable to have the DNS name resolved from the host that is 
going to use the results to open a connection.   Again, this is 
a rare case but one that has occasionally been important with 
the IPv4 (and NCP) implementations of FTP.
> Now, if you had asked the question a little differently I
> might have answered differently.  If the question is:
>
>     Should we *add* a couple more verbs to FTP that are to be
> more     generic than the current verbs and allow for DNS
> names and other     "labels" we may come up with the in the
> future?  (With the     intent that the new verbs and the old
> verbs could co-exist.)
>
> Then I'd certainly be fine with that (assuming someone has the
> energy).  If these new commands end up taking over in the
> future then that's great and we can think about moving rfc2428
> to historic at that time.  But, I think the key here is that,
> IMO, we should *add*, not *replace*.
Aha.  Then we are having a difference of opinion about 
architecture and aesthetics, not function.  Putting in a new 
verb for the same function each time one wants to provide what 
is logically the same information in a different form impresses 
me as a bad idea.  You prefer it.  I don't know how to resolve 
that difference of aesthetic convictions other than with some 
"beauty is in the mind of the beholder" platitude... and that 
doesn't produce a resolution.
    john