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

[Mykyta Yevstifeyev <[e-mail]>]

11.07.2011 8:02, John C Klensin wrote:
>
> --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.
I see what you mean.
>
> Thanks for the comments and the reminder.   A new version is now
> in the posting queue.
Yes, I've seen the new revision of the document.  Please see my 
responses in-lime below.
>
> 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.
The current terminology seems mostly fine.  Those corrections which you 
have made with respect to "data type" etc. deal with my concern.
>
> 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.
I have no strong position/objections regarding this.
>
>
>> 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.
So I withdraw this concern.  If the reader is acquainted with RFC 959 
terminology, this won't be a problem for them.
>
>
>> 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.
Your arguments are quite reasonable here; so I don't insist.
>
>
>>>          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.
I personally think the sentence where these regulations are placed needs 
clarifying a bit, but I don't think it will be incorrect if left as-is.

I also have several comments to new IANA considerations which I'll send 
in a separate message.

Mykyta
>
> best,
>    john
>
>