John-
> It seems appropriate to ask whether 2428 should be opened and
> given at least the capability of passing DNS names and maybe
> some syntax that would permit clean extension to future
> identifiers.
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? 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?).
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*.
allman
--
Mark Allman -- ICIR -- http://www.icir.org/mallman/