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

From: "Michel Py" <[email-masked]>
Date: Thu, 2 Oct 2003 11:27:26 -0700

John,

> John C Klensin wrote:
> 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.

There is an issue with backwards compatibility here:
Let's say we have a source host that has an implementation that allows
EPRT and EPSV to use a name as well as an address. The destination host
is a legacy host (meaning, a host implementing only 2428 as it is today,
address only). How will the destination react when receiving an EPSV
with a name instead of an address?

More generically, how will a host react when receiving an EPSV with foo
when foo is unknown? I am curious about the mechanism you envision to
determine what kind of info is being passed.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Fri, 3 Oct 2003 09:12:49 -0700

Mark / John,

> Mark Allman wrote:
> 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*.

This makes sense to me. For the same reason we are stuck supporting PORT
and PASV forever, I think that we are stuck supporting EPRT and EPSV
forever as well and that two new verbs that would include the
functionality of EPRT and EPSV with extended semantics that would allow
passing names and foo is the way to go.

> John C Klensin wrote:
> given that 2428 is at Proposed 

I believe there is deployed EPRT/EPSV code based on 2428; IMHO you can't
assume that this code base will be upgraded to support names. It's too
late.

Michel.