RFC 5797

Материал из Wikilivres.ru
Перейти к навигацииПерейти к поиску

RFC 5797 (Реестр команд и расширений FTP)
авторы: J. Klensin, A. Hoenes, пер. StLeutnant
Язык оригинала: английский. Название в оригинале: RFC 5797 (FTP Command and Extension Registry). — Опубл.: март 2010 года. Источник: RFC 5797


Internet Engineering Task Force (IETF)

Request for Comments: 5797
Updates: 959
Category: Standards Track
ISSN: 2070-1721

J. Klensin


A. Hoenes
TR-Sys
March 2010

Реестр команд и расширений FTP


Аннотация

Каждая последующая спецификация FTP добавляла несколько новых команд к изначально перечисленным в RFC 959. RFC 2389 представил механизм регистрации расширений и извещения о поддержке дополнительных команд протокола FTP. Количество расширений продолжает расти, но не все из них поддерживают этот механизм. Данная спецификация учреждает реестр имен команд и расширений FTP, зарегистрированных IANA, для снижения вероятности конфликтов имен и, как следствие, неоднозначности команд.


Статус данного документа

Документ относится к семейству Стандартов Интернета (Internet Standarts Track).

Он разработан специальной комиссией интернет-разработок (Internet Engineering Task ForceIETF) и представляет собой результат согласованных усилий сообщества IETF. Документ подвергся публичному обсуждению и был одобрен для публикации группой по выработке инженерного регламента Интернета (Internet Engineering Steering GroupIESG). Дополнительная информация о Стандартах Интернета доступна в разделе 2 RFC 5741.

Информацию о текущем статусе этого документа, о любых его изменениях и о том, как обеспечить обратную связь, можно получить на странице http://www.rfc-editor.org/info/rfc5797.


Уведомление об авторских правах

Copyright (C) 2010. Все права принадлежат IETF Trust и лицам, определенным как авторы документа. Все права защищены.

Данный документ подпадает под действие BCP 78 и Правовых Положений IETF Trust в Отношении Документов IETF (http://trustee.ietf.org/license-info), действующих на дату публикации этого документа. Пожалуйста, тщательно просмотрите эти документы, так как они описывают ваши права и ограничения в отношении настоящего документа. Компоненты кода, извлеченные из этого документа, должны включать текст Упрощенной Лицензии BSD, как описано в Разделе 4.e «Trust Legal Provisions», и предоставляются без гарантии, согласно условий Упрощенной Лицензии BSD.

Введение

Каждая последующая спецификация FTP добавляла несколько новых команд к изначально перечисленным в RFC 959 [RFC0959]. RFC 2389 [RFC2389] представил механизм регистрации расширений и извещения о поддержке дополнительных команд протокола FTP, изложенного в RFC 959, с помощью «ключевых фраз»[перевод 1], идентифицирующих расширения, поддерживаемые сервером FTP, и информирующих о них клиентов в ответе на команду FEAT. Количество расширений продолжает расти, но не все из них поддерживают механизм FEAT. Данная спецификация учреждает реестр имен команд и расширений FTP, зарегистрированных IANA, для снижения вероятности конфликтов имен и, как следствие, неоднозначности команд, а также для поощрения обмена информацией.

Описание реестра

Название реестра

Рассматриваемый реестр назван «Команды и расширения FTP».

Формат реестра

Как указано в настоящем документе RFC, IANA учредила реестр команд и расширений FTP. Запросы на регистрацию и записи в реестре должны включать в себя следующие данные:


Имя Команды

Команда FTP — новая, либо измененная, используемая в расширении или та, с которой будет использовано расширение.
Следуя многолетней практике записывать имена команд FTP в нормативных документах прописными буквами, имена команд приводятся в верхнем регистре. Для расширений, улучшающих работу команды, к имени команды добавляется знак плюс («+»). Однако, если расширение влияет на общую обработку параметров команды и/или обрабатывает транзакции, вместо того, чтобы быть связанным с одной командой (или с небольшим количеством команд), в реестр вносится строка «-N/A-».
Записи реестра сортируются по этой колонке по возрастанию в порядке кодировки ASCII (включая знак «+», если суффикс присутствует).


Имя Расширения

Наименование расширения FTP.
Расширения FTP, предшествовавшие RFC 2389 [RFC2389], и некоторые расширения, опубликованные после него, не задавали ключевые слова для идентификации расширения в ответе FEAT. В более поздних спецификациях в качестве ключевых слов для ответа FEAT использованы имена определяемых в спецификации команд. Поэтому, в целях обеспечения будущих спецификаций готовым списком ключевых слов, данный документ резервирует существующие имена компонентов, уже используемые в ответах FEAT, за «заместителями ключевых фраз»[перевод 2] (далее — «заместители») для последующей стандартизации. Кроме того, заместители используются и для имен основных команд FTP, указанных в RFC 959 [RFC0959], и тех их предшественников, которые все ещё применяются. Такие заместители размещаются в реестре для удобства; они не предназначены для возврата в ответе FEAT. Чтобы компенсировать эту особенность, колонка в реестре озаглавлена «Код FEAT», а также проводится четкое различие между двумя случаями: когда в колонке размещаются ключевые слова, то они перечисляются в верхнем регистре, в то время как заместители, не предназначенные для ответа FEAT (далее называемые «псевдокоды FEAT»), перечисляются в нижнем регистре. Будущим спецификациям разрешено «повышать»[перевод 3] заместителей до истинных ключевых слов, если они ниже отдельно не заявлены «неизменными». В остальном же IANA поддерживает уникальность наименований компонентов (кодов FEAT) на основе регистронезависимого сравнения.


Описание

Краткое описание расширения и, при необходимости, команды.


Ключевая фраза (в запросе на регистрацию в IANA; необязательна)

Строка, которая, как ожидается, будет включена в ответ на команду FEAT [RFC2389], если расширение поддерживается.
Во многих случаях, ключевая фраза, необходимая для идентификации расширения, будет состоять только из кода FEAT (см. Имя Расширения), что делает этот пункт излишним. Таким образом, данный пункт должен быть указан только тогда, когда он предназначен для регистрации ключевой фразы, которая содержит другие обязательные элементы, кроме самого кода FEAT.
Из-за ограничений размеров таблицы, чтобы позволить заявителям размещать дополнительную информацию, IANA обязуется представлять в реестре этот пункт регистрации (если Вы его укажете) в пронумерованных сносках к таблице, а не в дополнительном столбце таблицы.


Тип Команды

Тип (или вид) команды.
В разделе 4.1 RFC 959 [RFC0959] было введено разделение команд FTP на три типа:
  • Управление Доступом (Access control),
  • Параметры Передачи (transfer Parameter, настройки),
  • Обслуживание (Service, обработка).
В реестре это разделение распространено на все зарегистрированные команды FTP. В колонку реестра, озаглавленную «Тип», помещается характерный инициал типа команды: 'a' (Access), 'p' (Parameter) или 's' (Service); допускаются комбинации типов, например, 'p/s'.


Потребность

Ожидаемость поддержки команды в реализациях.
RFC 959 определяет классы обязательных к реализации команд (Mandatory) и дополнительных команд (Optional). Эта классификация ведется в реестре по всем зарегистрированным командам в колонке под названием «Потребность». Обязательные к реализации команды отмечены символом 'm' (Mandatory), дополнительные — символом 'o' (Optional). Кроме того, устаревшие или исторические записи оставлены в реестре, чтобы избежать конфликтов с развернутыми реализациями. Эти записи отмечены символом 'h' (Historic). Помимо Раздела 3 «Начальное содержимое реестра» данной спецификации, для регистрации новых «обязательных» записей или перемещения записей в «исторические» необходимо ознакомиться с [RFC5226].


Справка

Ссылка на RFC или другое определение расширения и/или реализации его поддержки (см. следующий раздел).

Критерии регистрации

Данный реестр предназначен прежде всего для того, чтобы помочь предотвратить конфликты использования одинаковых имен команд и расширений для различных целей, а вовсе не для демонстрации того, что расширение-то «утверждено». При рассмотрении заявок будет использоваться метод «Экспертной Оценки», но приглашённым экспертам, как ожидается, необходимо будет проверить лишь то, что соблюдается, по крайней мере, один из двух критериев, изложенных ниже:

  • Расширение описано в легко и постоянно доступной публичной спецификации (то же самое требование учетной политики определено в разделе «Обязательная Спецификация» RFC 5226 [RFC5226]).
  • Расширение действительно реализовано в доступных системах FTP (не обязательно свободных или бесплатных, но есть).

Для расширений или команд, которые будут отмечены как «обязательные» ('m' в колонке «Потребность»), требуется спецификация в семействе Стандартов IETF (IETF Standarts Track). Правила управления стандартами IESG позволяют IANA напрямую изменять потребность, относящуюся к любой записи.

Базовые команды FTP

Следующие команды являются частью базовой спецификации FTP [RFC0959] и перечислены в реестре с неизменным псевдокодом FEAT «base».

Обязательные команды:

ABOR, ACCT, ALLO, APPE, CWD, DELE, HELP, LIST, MODE, NLST, NOOP, PASS, PASV, PORT, QUIT, REIN, REST, RETR, RNFR, RNTO, SITE, STAT, STOR, STRU, TYPE, USER

Дополнительные команды:

CDUP, MKD, PWD, RMD, SMNT, STOU, SYST

Примечание: в STD 3 [RFC1123] уточнены и обновлены статусы, а также требования по реализации этих стандартных команд FTP. Там же содержится важная дополнительная информация по следующим командам:

LIST, NLST, PASV, REST, SITE, STOU

Устаревшие команды

Следующие команды были определены в качестве экспериментальных в расширении ранней версии спецификации FTP [RFC0775], но позже признаны устаревшими в RFC 1123 [RFC1123], потому что Стандарт FTP [RFC0959] определяет их стандартных преемников. Они перечислены в реестре с неизменным псевдокодом FEAT «hist»:

XCUP, XCWD, XMKD, XPWD, XRMD

Примечание: существующие клиенты FTP могут по-прежнему использовать устаревшие команды, так как большинство серверов FTP поддерживают их в качестве псевдонимов стандартных команд.

Следующие команды были указаны как часть достижений «FOOBAR» IPng в RFC 1545 [RFC1545], а затем и в RFC 1639 [RFC1639], и больше не используются. Они перечислены в реестре с неизменным псевдокодом FEAT «hist»:

LPRT, LPSV

Начальное содержимое реестра

Для более полного удовлетворения потребностей пользователей реестра и авторов существующих спецификаций, в реестр при создании сразу были включены все команды и расширения, опубликованные в RFC за время, прошедшее от публикации STD 3 [RFC1123] до времени написания этой статьи.

В соответствии с Разделом 2 были назначены следующие псевдокоды FEAT:

Имя команды Код FEAT Описание Тип Потребность Ссылки на RFC и примечания
ABOR base Прервать выполнение команды s m RFC 959
ACCT base Аккаунт пользователя a m RFC 959
ADAT secu Аутентификация/ Данные о безопасности a o RFC 2228, RFC 2773, RFC 4217
ALLO base Зарезервировать место на диске s m RFC 959
APPE base Добавить в конец файла (с созданием) s m RFC 959
AUTH secu Аутентификация/ Механизм безопасности a o RFC 2228
AUTH+ AUTH Аутентификация/ Механизм безопасности a o RFC 2773, RFC 4217[2]
CCC secu Очистить канал команд a o RFC 2228
CDUP base Перейти в родительский каталог a o RFC 959
CONF secu Команда, защищенная по уровню «Конфиденциальность» a o RFC 2228
CWD base Сменить рабочий каталог a m RFC 959
DELE base Удалить файл s m RFC 959
ENC secu Команда, защищенная по уровню «Приватность» a o RFC 2228, RFC 2773, RFC 4217
EPRT nat6 Установить активный режим для IPv6 (расширенное задание порта данных) p o RFC 2428
EPSV nat6 Установить пассивный режим для IPv6 (расширенный запрос порта данных) p o RFC 2428
FEAT feat Согласование функций a m[1] RFC 2389
HELP base Показать справку s m RFC 959
LANG UTF8 Задать язык (для сообщений сервера) p o RFC 2640
LIST base Получить список содержимого каталога s m RFC 959, RFC 1123
LPRT hist Установить активный режим (задание порта данных, FOOBAR) p h RFC 1545, RFC 1639
LPSV hist Установить пассивный режим (запрос порта данных, FOOBAR) p h RFC 1545, RFC 1639
MDTM MDTM Получить время модификации файла s o RFC 3659
MIC secu Команда, защищенная по уровню «Целостность» a o RFC 2228, RFC 2773, RFC 4217
MKD base Создать каталог s o RFC 959
MLSD MLST Получить список объектов каталога с характеристиками (для машины) s o RFC 3659
MLST MLST Получить характеристики одного объекта s o RFC 3659
MODE base Задать режим передачи данных p m RFC 959
NLST base Получить список имён содержимого каталога s m RFC 959, RFC 1123
NOP base Нет операции s m RFC 959
OPTS feat Установить опции функции p m[1] RFC 2389
PASS base Пароль пользователя a m RFC 959
PASV base Установить пассивный режим (запрос порта данных) p m RFC 959, RFC 1123
PBSZ secu Установить размер буфера защиты p o RFC 2228
PBSZ+ PBSZ Установить размер буфера защиты p o RFC 4217
PORT base Установить активный режим (задать порт данных) p m RFC 959
PROT secu Установить уровень защиты канала данных p o RFC 2228
PROT+ PROT Установить уровень защиты канала данных p o RFC 4217
PWD base Показать рабочий каталог s o RFC 959
QUIT base Завершить сеанс a m RFC 959
REIN base Начать сессию заново a m RFC 959
REST base Возобновить передачу файла s/p m RFC 959, RFC 1123
REST+ REST Возобновить передачу файла (для режима STREAM) s/p m RFC 3659[3]
RETR base Получить файл s m RFC 959
RMD base Удалить каталог s o RFC 959
RNFR base Переименовать из (имя) s/p m RFC 959
RNTO base Переименовать в (имя) s m RFC 959
SITE base Управление параметрами сайта (сервера) s m RFC 959, RFC 1123
SIZE SIZE Показать размер файла s o RFC 3659
SMNT base Подключить структуру данных файловой системы a o RFC 959
STAT base Показать состояние s m RFC 959
STOR base Сохранить файл s m RFC 959
STOU base Сохранить файл с присвоением уникального имени s[перевод 4] o RFC 959, RFC 1123
STRU base Указать характеристику файловой структуры p m RFC 959
SYST base Показать идентификацию операционной системы s o RFC 959
TYPE base Задать режим представления данных p m RFC 959[4]
USER base Имя пользователя a m RFC 959
XCUP hist (предшественник CDUP) s h RFC 775, RFC 1123
XCWD hist (предшественник CWD) s h RFC 775, RFC 1123
XMKD hist (предшественник MKD) s h RFC 775, RFC 1123
XPWD hist (предшественник PWD) s h RFC 775, RFC 1123
XRMD hist (предшественник RMD) s h RFC 775, RFC 1123
-N/A- TVFS Тривиальная виртуальная файловая система p o RFC 3659
Таблица 1.

Примечания:

  1. 1,0 1,1 1,2 С помощью Процедуры Стандартизации IETF механизм FEAT [RFC2389] необходимо было сделать обязательным, ведь реализация этого механизма расширений ясно требуется в сочетании с любым расширением или компонентом, которые зависят от него.
  2. Ключевая фраза для [RFC4217]: AUTH TLS
    Ключевая фраза для [RFC2773]: AUTH KEA-SKIPJACK
  3. Ключевая фраза: REST STREAM
  4. Ключевая фраза: TYPE {список поддерживаемых типов, разделенных точкой с запятой}

Благодарности

Любые работы по обновлению или расширению FTP зависят от базовой спецификации в RFC 959. Вклад его редакторов, Jon Postel и Joyce Reynolds, заслуживает особой благодарности. Механизм регистрации расширений и извещения о поддержке дополнительных команд протокола FTP, изложенный в RFC 2389 (и, как следствие, накопление компонентов), сделал возможным создание этого реестра; нельзя не выразить признательность авторам этого документа.

Barry Leiba и Alexey Melnikov сделали несколько предложений для более ранних версий этого документа, большинство из которых были включены.

Anthony Bryan заметил несколько опечаток.

Scott Bradner предложил текст разъяснения метода «Экспертной Оценки».

Авторы высоко оценивают комментарии и поддержку этой работы, полученные от разработчиков систем FTP и многих участников IETF. Комментарии от IESG помогли сформировать этот документ и реестр, повысив его полезность.

Роль IANA

IANA явлется учредителем реестра, представленного в разделе 2, с первоначальным содержимым, перечисленным в разделе 3, а так же с содержимым разделов 2.4 и 2.5, как пояснительного текста в предисловии реестра[перевод 5].

Новые записи будут добавляться в этот реестр, когда расширение FTP утверждается или определяется в RFC, или когда идентифицируется расширение, которое уже используется и хорошо документировано. Иными словами, требование регистрации — это слегка ослабленная версия «Обязательной Спецификации» [RFC5226], соединённая с «Экспертной Оценкой». Смотри раздел 2.3 для понимания специфики и исключений.

Вопросы безопасности

Создание этого реестра улучшает документацию и защиту от проблем взаимодействия. Реестр не создаёт новых проблем безопасности.

Список литературы

Нормативные документы

[RFC0959] Postel, J. and J. Reynolds, «File Transfer Protocol», STD 9, RFC 959, October 1985.
[RFC2389] Hethmon, P. and R. Elz, «Feature negotiation mechanism for the File Transfer Protocol», RFC 2389, August 1998.
[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

Дополнительная литература

[RFC0775] Mankins, D., Franklin, D., and A. Owen, «Directory oriented FTP commands», RFC 775, December 1980.
[RFC1123] Braden, R., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, October 1989.
[RFC1545] Piscitello, D., «FTP Operation Over Big Address Records (FOOBAR)», RFC 1545, November 1993.
[RFC1639] Piscitello, D., «FTP Operation Over Big Address Records (FOOBAR)», RFC 1639, June 1994.
[RFC2228] Horowitz, M., «FTP Security Extensions», RFC 2228, October 1997.
[RFC2428] Allman, M., Ostermann, S., and C. Metz, «FTP Extensions for IPv6 and NATs», RFC 2428, September 1998.
[RFC2773] Housley, R. and P. Yee, «Encryption using KEA and SKIPJACK», RFC 2773, February 2000.
[RFC4217] Ford-Hutchinson, P., «Securing FTP with TLS», RFC 4217, October 2005.

Примечания переводчика

  1. В оригинале «FEAT Strings».
  2. В оригинале «placeholder keywords».
  3. В оригинале «upgrade».
  4. В оригинале 'a'. Однако в списке замеченных опечаток отмечено, что RFC 959 относит эту команду к типу 's', что послужило основанием для исправления этой опечатки при переводе.
  5. Местоположение самого реестра нигде в тексте документа не указано, что впрочем попытался исправить автор одного из замечаний в списке замеченных опечаток, отметив, что сам реестр располагается по адресу http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.xml.