RFC 5797
| RFC 5797 (Реестр команд и расширений FTP) , пер. StLeutnant |
| Язык оригинала: английский. Название в оригинале: RFC 5797 (FTP Command and Extension Registry). — Опубл.: март 2010 года (перевод). Источник: RFC 5797 |
| Internet Engineering Task Force (IETF)
Request for Comments: 5797 |
J. Klensin
|
| Реестр команд и расширений FTP |
Аннотация
Каждая последующая спецификация FTP добавляла несколько новых команд к изначально перечисленным в RFC 959. RFC 2389 представил механизм регистрации расширений и извещения о поддержке дополнительных команд протокола FTP. Количество расширений продолжает расти, но не все из них поддерживают этот механизм. Данная спецификация учреждает реестр имен команд и расширений FTP, зарегистрированных IANA, для снижения вероятности конфликтов имен и, как следствие, неоднозначности команд.
Статус данного документа
Документ относится к семейству Стандартов Интернета (Internet Standarts Track).
Он разработан специальной комиссией интернет-разработок (Internet Engineering Task Force — IETF) и представляет собой результат согласованных усилий сообщества IETF. Документ подвергся публичному обсуждению и был одобрен для публикации группой по выработке инженерного регламента Интернета (Internet Engineering Steering Group — IESG). Дополнительная информация о Стандартах Интернета доступна в разделе 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:
- base — стандартные команды FTP [RFC0959]
- hist — исторические экспериментальные команды [RFC0775], [RFC1639]
- secu — расширения системы безопасности FTP [RFC2228]
- feat — механизм регистрации и распознавания расширений FTP [RFC2389][1]
- nat6 — расширения FTP для NAT/IPv6 [RFC2428]
| Имя команды | Код 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,0 1,1 1,2 С помощью Процедуры Стандартизации IETF механизм FEAT [RFC2389] необходимо было сделать обязательным, ведь реализация этого механизма расширений ясно требуется в сочетании с любым расширением или компонентом, которые зависят от него.
- ↑ Ключевая фраза для [RFC4217]: AUTH TLS
Ключевая фраза для [RFC2773]: AUTH KEA-SKIPJACK - ↑ Ключевая фраза: REST STREAM
- ↑ Ключевая фраза: 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. |
Примечания переводчика
- ↑ В оригинале «FEAT Strings».
- ↑ В оригинале «placeholder keywords».
- ↑ В оригинале «upgrade».
- ↑ В оригинале 'a'. Однако в списке замеченных опечаток отмечено, что RFC 959 относит эту команду к типу 's', что послужило основанием для исправления этой опечатки при переводе.
- ↑ Местоположение самого реестра нигде в тексте документа не указано, что впрочем попытался исправить автор одного из замечаний в списке замеченных опечаток, отметив, что сам реестр располагается по адресу http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.xml.