요약

  • RFC 3059는 SLPv2 사용자 에이전트가 반환되는 모든 서비스 URL에 전체 등록 속성 목록이 함께 실리도록 요청할 수 있게 했다. 요청은 의도적으로 비워 둔 확장으로 이루어졌고, 응답은 URL마다 하나의 확장으로 이를 채웠다.
  • 확장 0x0002는 선택 사항이며 무시 가능했기 때문에, 확장이 없는 응답은 속성 집합이 비어 있다는 증거가 아니라 대체 경로 신호였다. 응답자가 요구된 인증 블록을 제공할 수 없는 경우, 요청된 SLP SPI 때문에 확장이 생략될 수도 있었다.

지름길은 의도적인 공백에서 시작되었다

서비스 검색에는 그 안에 서로 다른 두 가지 질문이 숨어 있다. 어떤 서비스가 조건에 맞는가? 그리고 어떤 사실들이 매칭되는 서비스들을 서로 구별하는가? SLPv2는 원래 이 질문들에 서로 다른 메시지로 답했다. 사용자 에이전트는 서비스 요청을 보내 서비스 URL을 받았고, 그다음 선택한 URL이나 서비스 유형에 붙은 속성들을 얻기 위해 속성 요청을 사용했다.

2001년 2월 제안 표준(Proposed Standard)으로 공개된 RFC 3059는 그 두 수령물을 서로 다른 사실로 취급하지 않으면서 하나로 연결했다. 사용자 에이전트는 서비스 요청에 속성 목록 확장을 삽입했다. 요청 측 형태에서 서비스 URL 길이와 속성 목록 길이는 모두 0이었고 두 필드 모두 생략되었다. 이 공백은 작동하는 문법이었다. 즉, 서비스 에이전트나 디렉터리 에이전트에게 응답에 속성 데이터를 붙여 달라는 요청이었다.

이 세부 사항은 유혹적이지만 심각한 오류를 막아 준다. 요청의 길이 0 필드는 서비스에 URL이나 속성이 없다는 뜻이 아니었다. 더 풍부한 출력에 대한 요청을 표현한 것이었다. 의미는 필드의 시각적 비어 있음이 아니라 메시지 방향과 맥락에서 나왔다.

URL 하나, 속성 수령 하나

확장을 지원하는 응답자는 서비스 응답의 모든 URL 항목마다 하나의 속성 목록 확장을 반환했다. 각 확장에는 해당 서비스 URL과 그 서비스의 전체 등록 속성 목록이 담겼다. 문서는 확장들이 URL 항목과 같은 순서를 따라야 한다고 명시했지만, URL을 각 확장 내부에도 넣었다.

따라서 URL이야말로 견고한 조인 키였다. 순서는 기형적이거나 의외의 응답을 드러낼 수 있었지만, 순서만으로는 관계의 식별자가 아니었다. 두 배열을 짝지어 묶고 명시적 URL을 버리는 구현은 프로토콜 식별자를 로컬 편의로 대체하는 것이다.

"전체 속성 목록"에도 경계가 있었다. 이는 서비스 요청이 지시한 언어로 응답하는 SA나 DA가 그 서비스에 대해 보유한 목록을 의미했다. 실행 중인 엔드포인트에 관한 모든 사실을 뜻하지 않았다. 등록은 수명이 끝날 때까지 오래되어 있을 수 있었고, 속성이 광고에 없을 수도 있었으며, 검색 이후 서비스에 도달할 수 없을 수도 있었다. RFC 3059는 실행 상태의 관찰이 아니라 등록된 설명의 전달을 최적화했다.

선택 사항인 번호가 중요했다

IANA는 속성 목록 확장에0x0002식별자를 할당했다. RFC 2608에 따라0x0000부터0x3FFF까지의 ID는 구현이 선택 사항이고 인식되지 않으면 무시되는 표준화된 확장을 지칭했다. 이 선택 덕분에 이 최적화는 구형 피어와도 호환 가능했다. 확장을 모르는 구현이라도 여전히 평범한 서비스 응답을 반환할 수 있었다.

이 안전 메커니즘은 클라이언트에게 증거상의 의무를 만들었다. 확장 0x0002가 없는 응답은 속성에 대한 부정적 답이 아니었다. RFC 3059는 사용자 에이전트에게 응답자가 확장을 지원하지 않는 것으로 간주하고 서비스 응답의 각 URL에 대해 속성 요청을 발행하도록 지시했다. 호환성은 경계에서의 추가 작업으로 구입한 것이었다.

이는 식별자가 구현 의무 범위를 차지하고 알 수 없는 요청이OPTION_NOT_UNDERSTOOD를 낼 수 있는 이후의 SLP 확장들과는 다르다. RFC 3421의 Select 및 Sort 설계는 유용한 대조일 뿐, 소급 적용되는 규칙이 아니다. "어떤 SLP 확장"이 단일한 보편적 실패 동작을 묘사한 적은 없었다.

인증은 생략을 더 모호하게 만들었다

요청은 SLP 보안 매개변수 지수(SPI)를 담을 수 있었다. 그렇다면 반환되는 모든 속성 목록 확장은 그 SPI에 대한 인증 블록을 포함해야 했다. SA나 DA가 요구된 블록을 지원하지 않거나 반환할 수 없다면 확장을 생략해야 했다.

즉, 와이어에서 보이는 부재에는 적어도 두 가지 관련 경로가 있었다. 응답자가 확장 0x0002를 구현하지 않았거나, 요청된 인증 맥락을 충족할 수 없었을 수 있다. RFC 3059는 그럼에도 동일한 실용적 클라이언트 대응, 즉 속성 요청으로 대체하도록 규정했다. 클라이언트가 침묵으로부터 더 풍부한 진단을 만들어 낼 허가를 받은 것은 아니었다.

인증 블록은 가치 있었지만 한정되어 있었다. RFC 2608은 이를 SPI의 키 자료와 만료 조건에서, 피복된 내용이 수정되지 않았고 권한 있는 에이전트에 의해 전송되었음을 검증하는 수단으로 기술했다. 이 검사를 통과했다고 해서 광고된 서비스가 지금 도달 가능하거나, 사용자가 그것을 호출할 수 있거나, 애플리케이션 트랜잭션이 성공할 것임을 증명하지는 않았다.

더 빠른 목록도 여전히 목록이었다

확장은 대화를 압축했다. 이것이 없으면 네 개의 URL을 검색하고 그 속성을 학습하는 데 하나의 서비스 요청과 네 개의 속성 요청이 필요할 수 있었다. 상호 지원이 있는 경우 동일한 설명 묶음이 하나의 응답으로 도착할 수 있었다. 이것이 바꾼 것은 지연 시간과 메시지 수였지, 근본 데이터의 권위가 아니었다.

이 구별은 시스템이 누락된 보강을 0으로 취급할 때마다 중요하다. UI는 보강이 반환되지 않았기 때문에 아무 능력도 표시하지 않을 수 있다. 인벤토리는 호환성 경로가 건너뛰어졌기 때문에 속성이 없다고 셀 수 있다. 자동 선택기는 "여기에 실려 있지 않음"과 "없음이 확인됨"을 혼동해 사용할 수 있는 후보를 버릴 수 있다. RFC 3059의 대체 규칙은 이 세 가지 오류 모두에 대한 이른바 촘촘한 경고였다.

이 역사적 설계는 또한 비용을 마땅한 곳에 배치했다. 응답자는 이 최적화를 구현하지 않고도 호환을 유지할 수 있었다. 완전한 선택 정보를 원하는 사용자 에이전트는 누락된 수령을 인지하고 추가 왕복을 감당해야 했다. 프로토콜은 소비자가 절약된 작업을 발명된 확실성으로 바꾸는 것을 허락하지 않았다.

출처