Здравствуйте, Аноним, Вы писали:

А>Я не спорю о том как нужно называть: "основная информация" или "дополнительная информация". Спорность возникает потому,
А>что не тот и не другой термин не являются корректными. Вы пытаетесь на определенную синтаксическую конструкцию навесить
А>какой-то свой семантический смысл. Это неправильно. Во-первых, вы отдаляетесь от спецификации протокола, а во-вторых
А>тут нет взаимной однозначности.
А>И мне кажется не стоит так делать. Повторюсь, существуют различные уровни анализа, на синтакстическом уровне мы оперируем
А>такими понятиями как tagged/untagged, а на семантическом уже "Status response", "Server data", "Command continuation".
А>И если Вы это сможете объяснить студентам и научить писать нормальные парсеры, то это будет здорово (не обязательно Imap
А>протокола ).

Отвечу как "первый, начавший сближать синтаксис и семантику"

Во-первых, синтаксис и семантика должны быть близки. Иначе непонятно, зачем придуман синтаксис, не ествественный для предпологаемой семантики.
Во-вторых, это не полная спецификация, поэтому я пока не хочу вводить типы ответов status response и server data. Честно говоря, я их особо и не вижу (если вы чётко объясните, я буду благодарен и может быть изменю своё мнение). И в том и в другом случае передаётся информация с сервера на клиент, причём это может быть любая информация. В других типах ответов мы всегда получаем либо информацию о результате работы команды (tagged), либо информацию о том, что можно продолжать (+)
Во-третьих, RFC тоже писали люди, которые вполне могли сделать при этом дидактические ошибки при описании метериала. Поэтому просто пересказывать RFC имхо неверно. Это конечно упростит последующее тение RFC, но зато затруднит понимание протокола... Оптимум — написать, что RFC считает несколько иначе.

Предложенный Николаем термин "информационный ответ" мне понравился потому что в нём заключён как раз тот смысл — некотарая нетипизированная информация.

А>Звездочка

А>

А>111 FETCH 1:* (UID FLAGS)
А>

Супер! Но там даже хуже Посмотрел RFC, вот, что он говорит:

fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /
"FAST" / fetch_att / "(" 1#fetch_att ")")

sequence_num ::= nz_number / "*"
;; * is the largest number in use. For message
;; sequence numbers, it is the number of messages
;; in the mailbox. For unique identifiers, it is
;; the unique identifier of the last message in
;; the mailbox.

set ::= sequence_num / (sequence_num ":" sequence_num) /
(set "," set)
;; Identifies a set of messages. For message
;; sequence numbers, these are consecutive
;; numbers from 1 to the number of messages in
;; the mailbox
;; Comma delimits individual numbers, colon
;; delimits between two numbers inclusive.
;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,
;; 14,15 for a mailbox with 15 messages.

Т.е. можно даже так:

111 FETCH 1,2,5:8,23:* (UID FLAGS)

Здравствуйте, Odi$$ey, Вы писали:

OE>а че как неродной на pisem.net? давай doc-файлу

Думаешь стоит? Статья это серьёзно, это думать надо.. А я как-то решил на халяву Ладно, похоже вы меня уговорили, через неделю закончу со своими экзаменами, попробую переписать, в нынешнем варианте оно сыровато. Тогда и doc вышлю..

Ещё я тут неосторожно дал согласие на публикацию этого чуда на http://www.opennet.ru/opennews/art.shtml?num=7758 Там уже и покомментировали, да