RFC: 1413
Оригинал: Identification Protocol
Предыдущие версии: RFC 912, RFC 931
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 1413, Страница 5 из 6

Формальный синтаксис

<request> ::= <port-pair> <EOL>
<port-pair> ::= <integer> "," <integer>
<reply> ::= <reply-text> <EOL>
<EOL> ::= "015 012"  ; CR-LF End of Line Indicator
<reply-text> ::= <error-reply> | <ident-reply>
<error-reply> ::= <port-pair> ":" "ERROR" ":" <error-type>
<ident-reply> ::= <port-pair> ":" "USERID" ":" <opsys-field>
                  ":" <user-id>
<error-type> ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR"
                 | "HIDDEN-USER" |  <error-token>
<opsys-field> ::= <opsys> [ "," <charset>]
<opsys> ::= "OTHER" | "UNIX" | <token> ...etc.
            ;  (See "Assigned Numbers")
<charset> ::= "US-ASCII" | ...etc.
              ;  (See "Assigned Numbers")
<user-id> ::= <octet-string>
<token> ::= 1*64<token-characters> ; 1-64 characters
<error-token> ::= "X"1*63<token-characters>
                  ; 2-64 chars beginning w/X
<integer> ::= 1*5<digit> ; 1-5 digits.
<digit> ::= "0" | "1" ... "8" | "9" ; 0-9
<token-characters> ::=
               <Any of these ASCII characters: a-z, A-Z,
                - (dash), [email protected]
#$%^&*()_=+.,<>/?"'~`{}[]; >
                            ; upper and lowercase a-z plus
                            ; printables minus the colon ":"
                            ; character.
<octet-string> ::= 1*512<octet-characters>
<octet-characters> ::=
               <any octet from  00 to 377 (octal) except for
                ASCII NUL (000), CR (015) and LF (012)>

Примечания:

  1. Для обеспечения интероперабельности различных реализаций в части трактовки символов пробела следует придерживаться общего принципа: "будь консервативным при передаче и либеральным на приеме". Клиентам и серверам не следует генерировать избыточных пробелов, но они должны воспринимать строки с лишними пробелами от других. Избыточные пробелы могут встречаться везде, кроме собственно маркеров (token). В частности, дополнительные пробелы могут встречаться в начале и в конце строк запросов и откликов. Однако дополнительные пробелы недопустимы в отклике с идентификатором пользователя после двоеточия вслед за именем операционной системы, поскольку в этом случае они будут трактоваться как часть имени пользователя (именем пользователя считается вся последовательность символов от двоеточия до символов завершения строки CR/LF). Символы CR/LF не должны рассматриваться как часть идентификатора пользователя.
  2. Вопреки сказанному выше, серверам следует ограничивать число пробелов между элементами (маркерами) до минимально возможного (полезного). Клиент может разорвать соединение, получив более 1000 символов без сигнала завершения строки <EOL>.
  3. Размер идентификатора пользователя следует ограничивать 512 символами, а размер маркера - 64 символами, поскольку: a) новые маркеры (т. е., OPSYS или ERROR-TYPE) будут иметь размер не более 64 символов и b) серверу не следует передавать более 512 октетов идентификатора пользователя, а клиент должен принимать первые 512 октетов идентификатора пользователя. Вследствие этих ограничения сервер должен возвращать наиболее важную часть идентификатора пользователя в первых 512 октетах.
  4. Следует использовать только те наборы символов и идентификаторы этих наборов, которые указаны в RFC 1340, "Assigned Numbers" и более новых вариантах этого документа. Идентификаторы набора символов применимы только к полям идентификации пользователя, а все остальные поля должны использовать набор символов US-ASCII.
  5. Хотя поле <user-id> было определено выше как <octet-string> (строка октетов), оно должно соответствовать по формату и набору символов значению поля <opsys-field>; описанного выше.
  6. Идентификатор набора символов обеспечивает для клиента контекст, позволяющий печатать или сохранять строку идентификации пользователя. Если клиент не может распознать или использовать указанный набор символов, ему следует трактовать строку идентификации как строку октетов (OCTET), со храняя вместе с ней идентификатор использованного набора символов. Строку октетов в таких случаях следует печатать, сохранять и обрабатывать с 16- ричном представлении (0-9a-f) в дополнение к используемому клиентской реализацией представлению (это обеспечивает возможность стандартного представления в различных реализациях).

Страница 5 из 6

2007 - 2022 © Русские переводы RFC, IETF, ISOC.