Re: [ftpext] I-D Action: draft-ietf-ftpext2-typeu-01.txt

[John C Klensin <[e-mail]>]

--On Monday, July 04, 2011 07:39 +0300 Mykyta Yevstifeyev
<[e-mail]> wrote:

> John,
> 
> Sorry for being a bit curious, but did my comments
> (http://www.ietf.org/mail-archive/web/ftpext/current/msg00353.
> html) arrive to you?  Are you going to consider some (if any)
> of them?

I hadn't gotten to it -- I've been preoccupied with a few other
things as those who follow the rfc-interest list may have
figured out.

Thanks for the comments and the reminder.   A new version is now
in the posting queue. 

I don't think I've made any of the changes exactly as you
suggested, but think I've now addressed most of them.

As an example of the reasons for the difference between what you
suggested and what I did, "data type" is a horribly ambiguous
term.  RFC 959 carefully distinguishes between "Representation
Type" and "File Structure" either of which could be considered
"data type" information.  So I tried to clarify things as you
suggested while staying very close to traditional FTP
terminology.

I haven't taken out the user-PI, etc., terms because the text
says "if used here".  They might be worth taking out when the WG
is otherwise finished with the document, but not now.


> Why not completely replace server-FTP process and user-FTP
> process with server and client, respectively, within the whole
> document at all?

Well, because I learned several things in the transition from
RFC 821 (which, like FTP, used Jon Postel's terminology and BNF)
to RFC 2821 (which used ABNF).   One of them was that Jon wrote
protocol specifications with a much higher degree of precision
than is typical in the iETF today.  In 2821 (and 5321), it was
sometimes necessary to use Jon's historical "sender" and
"receiver" terminology because client-server terminology can get
confusing or ambiguous when one is talking, e.g., about relay
hosts who act as both.   With FTP, the separation of control and
data connections will sometimes require careful identification
of USER-PI, SERVER-PI, server-DTP and user-DTP, and so on.  The
fact that I've managed to construct a draft for TYPE U without
needing those distinctions is no guarantee that we won't need
them before the specification is approved.  And, if I were to
give general advice to the WG at this point, it would be to try
to stick to the terminology of RFC 959 rather than trying to
retrofit "modern" terminology.  If I were writing this draft for
the first time today, I would not have bothered with that
sentence about convenience at all, but I acknowledge that it is
somewhat a matter of taste.


> For the reader's convenience, the reference to some material
> concerning EBCDIC could be provided

The sentence refers to RFC 959, which ought to be sufficient.
While it doesn't provide references for EBCDIC the reality today
is that anyone who doesn't know what it means almost certainly
doesn't care and will never care.  Worse, the authoritative
references are hard to find and access today, so incorporating
them in the document wouldn't do much good.


>>         If it does, the server MAY

> Probably SHOULD or SHALL is more appropriate here; what is an
> other way to indicate that U data type isn't supported, in
> this case? 

The sentence is correct as written.  Support for the feature is
optional, so the server MAY support it.  If it doesn't, or
doesn't want to provide that service to a particular user, it
returns 504.  Otherwise, there is a firm requirement ("MUST")
about what it does.

best,
  john