Subject: [ftpext] I-D Action: draft-ietf-ftpext2-typeu-02.txt

From: [email-masked]
Date: Sun, 10 Jul 2011 22:01:27 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FTP Extensions, 2nd edition Working Group of the IETF.

	Title           : FTP TYPE Extension for Internationalized Text
	Author(s)       : John C Klensin
	Filename        : draft-ietf-ftpext2-typeu-02.txt
	Pages           : 11
	Date            : 2011-07-10

   The traditional FTP protocol includes a TYPE command to specify the
   data representation.  That command has values for ASCII and EBCDIC
   text, plus binary (&quot;IMAGE&quot;) transmission.  As the Internet becomes
   more international, there is a growing requirement to be able to
   transmit textual data, encoded in Unicode, in a way that is
   independent of the coding and line representation forms of particular
   operating systems.  This memo specifies a new FTP representation TYPE
   value for Unicode data.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ftpext2-typeu-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ftpext2-typeu-02.txt

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 11 Jul 2011 11:43:42 +0300

As I mentioned in my previous message, I have several comments on new 
IANA considerations, which follow.  The current Section 5 is:

> 5.  IANA Considerations
>
>     When this specification is approved, IANA is requested to add an
>     additional table to the FTP Extensions Registry established by RFC
>     5797 [RFC5797].  That table should be titled "TYPE command arguments"
>     and should include "A (m) RFC 959", "E (o) RFC 959", "I (o) RFC 959",
>     "L (o) RFC 959", and "U (o) RFCNNNN".

First, this sections doesn't mention clearly what is the new "table".  I 
suppose you wanted a new sub-registry.  In this case it really lacks a 
number of information required by RFC 5226.  This includes: (1) what is 
the format of the sub-registry (I guess this should be "TYPE parameter", 
"conformance" and "reference").  Probably we can also create the 
separate column entitled "2nd parameter" and corresponding possible 
values "allowed/not-allowed"; (2) what is the addition policy for the 
new entries (I suppose this should be "IETF Consensus" or "RFC 
Required"; I think the 1st is better). (3) see also bullet 2 of Section 
4.2 of RFC 5226.

Moreover, I think creating the registry should be done by the separate 
document, whereas your one should only register the corresponding value 
in it.  This will be clearer a bit, IMO.  Yet, I don't insist much on 
this particular issue.

Mykyta

---

From: John C Klensin <[email-masked]>
Date: Mon, 11 Jul 2011 06:59:37 -0400

--On Monday, July 11, 2011 11:43 +0300 Mykyta Yevstifeyev
<[email-masked]> wrote:

> As I mentioned in my previous message, I have several comments
> on new IANA considerations, which follow.  The current Section
> 5 is:
> 
>> 5.  IANA Considerations
>> 
>>     When this specification is approved, IANA is requested to
>>     add an additional table to the FTP Extensions Registry
>>     established by RFC 5797 [RFC5797].  That table should be
>>     titled "TYPE command arguments" and should include "A (m)
>>     RFC 959", "E (o) RFC 959", "I (o) RFC 959", "L (o) RFC
>>     959", and "U (o) RFCNNNN".
> 
> First, this sections doesn't mention clearly what is the new
> "table".  I suppose you wanted a new sub-registry.  In this
> case it really lacks a number of information required by RFC
> 5226.  This includes: (1) what is the format of the
> sub-registry (I guess this should be "TYPE parameter",
> "conformance" and "reference").  Probably we can also create
> the separate column entitled "2nd parameter" and corresponding
> possible values "allowed/not-allowed"; (2) what is the
> addition policy for the new entries (I suppose this should be
> "IETF Consensus" or "RFC Required"; I think the 1st is
> better). (3) see also bullet 2 of Section 4.2 of RFC 5226.

Given the time, other commitments, and closeness to the
deadline, I put something there that would clearly indicate a
direction without taking the time to check 5226 or laying out a
table that would have made the intent more clear.  That
represented a tradeoff between having an updated document the WG
could discuss in Quebec if it were so inclined and missing the
posting deadline.   I probably should have inserted a note in
the draft indicating awareness of those issues but didn't think
to do so.  Sorry.  Addressed in the next draft.

> Moreover, I think creating the registry should be done by the
> separate document, whereas your one should only register the
> corresponding value in it.  This will be clearer a bit, IMO.
> Yet, I don't insist much on this particular issue.

While I understand your concern, we create registries in
protocol specs fairly frequently.   In retrospect, we should
have make explicit provision in RFC 5797 for registry tables
("subregistries" if you will) for argument values to base FTP
commands as they are extended.   It seems to me that creating a
separate document either to create this particular registry or
to establish the general principle would be mostly a waste of
time.  YMMD, but that is how I intend to proceed until / unless
the WG tells me otherwise.

Again, thanks for the close reading. 

    john