요약

  • 10월 28일 IETF 개인 초안은 mDNS와 DNS-SD로 가까운 A2A 에이전트와 MCP 서버를 찾은 뒤, 상세 설명을 받거나 세션을 여는 두 단계를 제안한다.
  • 공유 링크의 모든 호스트는 서비스 항목을 알릴 수 있다. 표시 이름, 설명 주소와 해시는 알린 쪽의 주장이고, 실제 서버 신원은 연결 단계에서 확인한다.

명찰을 달아 주는 직원은 없다

연구실과 지점의 도구 서버는 켜졌다 꺼지고 주소도 바뀐다. 주소 목록을 사람이 계속 고치는 대신 주변 서비스를 조회하는 방법이 Jakab과 Brockners의 개정안이다. DNS-SD로 후보를 찾고 호스트와 포트를 알아낸 다음 A2A 카드나 MCP 연결로 세부 사항을 얻는다. 10월 판은 MCP와 공통 발견 매개변수, 원래 링크 밖으로 나가는 광고까지 다룬다. 문서는 아직 IETF 개인 초안이다.

첫 단계의 문은 넓다. 같은 링크에 있는 호스트라면 서비스 항목을 알리고 TXT 값을 임의로 넣을 수 있다고 초안은 쓴다. 다른 에이전트와 비슷한 표시 이름을 달 수도 있다. desc-ref는 설명을 가리키지만 운영자를 증명하지 않는다. 새로 들어간 desc-ref-digest는 설명의 변경을 알아채는 단서다. 해시도 인증되지 않은 광고 속에 있으므로 설명의 무결성 보증이 되지 않는다. 등록 신청서와 도장을 한 사람이 들고 오는 셈이다.

그다음 클라이언트는 SRV의 호스트와 포트, 경로 단서를 조합해 URL을 만든다. 주소의 재료는 광고자의 영향을 받았다. 초안은 허용할 주소 방식과 대역, 포트, 리디렉션, 자격 증명, 도메인 간 요청을 클라이언트 정책으로 걸러야 한다고 적는다. 이어 전송 계층과 에이전트 프로토콜에 따라 서버를 인증한다. 기본값으로 https를 채워 넣어도 그 서버의 신원이 저절로 확인되지는 않는다.

MCP 서버를 찾았다면 연결 뒤에 도구, 리소스, 프롬프트 목록이 온다. 로컬 명부에 있었다는 이유만으로 그 목록에 일을 맡길 수는 없다. 게이트웨이가 광고를 다른 링크로 전달해도 믿을 근거가 늘어나는 것이 아니라 보는 사람이 늘어난다. RFC 9665의 선착순 이름 등록은 뒤늦은 탈취를 막지만, 첫 등록자의 실제 운영자를 증명하지는 않는다.

광고 자체도 정보를 드러낸다. 같은 링크의 다른 기계는 어떤 서비스가 있는지 볼 수 있다. A2A와 MCP 하위 유형은 검색 결과를 좁힐 뿐 목록을 숨기지 않는다. 운영자는 어느 인터페이스와 구역에서 무엇을 알릴지 정하고, 클라이언트는 연결할 상대와 사용할 도구를 따로 판단한다. 편리한 명부를 쓰더라도 문을 여는 열쇠까지 넘길 이유는 없다.

출처: 개정 01, 이전 00, IETF 문서 상태, mDNS RFC 6762, DNS-SD RFC 6763, 서비스 등록 RFC 9665.