Кратко

  • RFC 3059 позволил User Agent с помощью намеренно пустого расширения попросить, чтобы каждая URL в Service Reply сопровождалась полным списком зарегистрированных атрибутов.
  • 0x0002 было необязательным и игнорируемым при неизвестности расширением. Его отсутствие запускало Attribute Request для каждой URL, а не подтверждало пустой список; такой же пробел возникал, если ответчик не мог предоставить блок для запрошенного SLP SPI.

Пустая конструкция выполняла действие

Найти службы и узнать их свойства — разные задачи. В базовом SLPv2 Service Request возвращал URL, а Attribute Request отдельно спрашивал атрибуты URL или типа службы. Чем больше результатов, тем больше могло потребоваться обменов.

Опубликованный в феврале 2001 года как Proposed Standard RFC 3059 предложил объединить доставки. User Agent включал Attribute List Extension в Service Request. В запросе длины Service URL и Attribute List равнялись нулю, а сами поля отсутствовали. Пустая оболочка означала просьбу вложить списки в ответ.

Нули не были наблюдением над службой. Их смысл задавали направление и тип сообщения. Прочитать их как отсутствие URL или атрибутов — значит превратить вопрос в ответ до получения данных.

Явная URL связывала объект с описанием

Поддерживающий SA или DA возвращал одно Attribute List Extension на каждую URL Entry. Расширение содержало соответствующую Service URL и полный список атрибутов. Порядок расширений должен был совпадать с порядком URL Entries, но URL присутствовала и внутри каждого расширения.

Поэтому прочным ключом связи была URL. Позиция помогала проверять согласованность, однако не заменяла идентичность. Соединить два массива только по индексам означало отбросить явное поле протокола.

«Полный список» оставался полным лишь в границах регистрации, языка запроса, scope и состояния ответчика. Он не описывал каждое свойство работающей службы. Регистрация могла ещё жить, когда конечная точка уже не отвечала. RFC ускорял передачу объявления, а не доказывал выполнение.

Необязательный диапазон задавал безопасный откат

IANA закрепила за расширением 0x0002. RFC 2608 относил 0x00000x3FFF к стандартизованным, но необязательным расширениям, которые следует игнорировать, если они неизвестны. Старый участник мог вернуть обычный Service Reply.

Цена совместимости оставалась у User Agent. Получив ответ без Attribute List Extension, он должен был предположить отсутствие поддержки и послать Attribute Request для каждой URL. Пропуск был незавершённым состоянием с известным продолжением, а не значением «ноль».

Позднейшие расширения могли вести себя иначе. Select и Sort в RFC 3421 использовали обязательный диапазон и OPTION_NOT_UNDERSTOOD; RFC 3224 и RFC 3082 описывали иные классы данных. Это различие не позволяло переносить их семантику назад на 0x0002.

Запрошенная аутентификация могла убрать расширение

Service Request мог содержать SLP Security Parameter Index. Тогда каждое возвращённое расширение атрибутов обязано было включать блок аутентификации для данного SPI. Если SA или DA не поддерживал или не мог вернуть такой блок, расширение возвращать запрещалось.

Одинаковая видимая картина могла скрывать не реализованный 0x0002 либо невозможность удовлетворить контекст аутентификации. RFC давал безопасное действие — перейти к отдельным запросам, — но не давал права выбирать причину из молчания.

Сам блок тоже подтверждал ограниченный факт. По RFC 2608 он позволял проверить неизменность покрытых данных и их отправку уполномоченным агентом с учётом ключей и срока SPI. Это не доказывало текущую достижимость службы, право пользователя на доступ или успех операции приложения.

Короче становился разговор, а не цепочка доказательств

Четыре URL могли потребовать одного Service Request и четырёх Attribute Request. При поддержке с обеих сторон зарегистрированное описание приходило в одном ответе. Менялись задержка и число сообщений, но не полномочия данных.

Потеря этой границы порождает ложные нули: интерфейс показывает отсутствие возможностей, потому что не получил обогащение; инвентарь сохраняет пустоту, потому что пропустил откат; селектор отбрасывает кандидата, принимая «не передано здесь» за «не существует». RFC 3059 требовал заметить недостающую квитанцию и спросить снова.

Источники