組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：王安鵬（anpengwang    anpengwang@263.net）
譯文發布時間：2001-8-2
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但
必須保留本文檔的翻譯及版權信息。


Network Working Group                                         E. Guttman
Request for Comments: 3059                              Sun Microsystems
Category: Standards Track                                     February 2001


服務定位協議的屬性列表擴展
（RFC3059——Attribute List Extension for the Service Location Protocol）

本備忘錄的狀態
本備忘錄為Internet協會描述了一種Internet標準跟蹤協議，需要討論和建議以便改
進。請參考“Internet正式協議標準”（STD1）了解本協議的標準化進程和狀態。本備忘錄
的發布不受限制。
版權公告
   Copyright (C) The Internet Society (2001).  All Rights Reserved.
摘要
服務定位協議第二版（SLPv2）提供了一種機制，可以通過一次信息交換揭示某項服務。
這一信息交換目前不包含任何服務屬性。本文檔描述了一種SLPv2擴展機制，可以把用戶代
理（UA）對服務屬性的請求作為服務應答消息的擴展信息包含進來。這樣做可以減少UA為了
獲得全部服務信息而進行消息往返的次數。

           
目錄
1	簡介	2
1.1	術語	2
1.2	符號約定	2
2	屬性列表擴展	2
3	IANA方面的問題	3
4	國際化方面的問題	3
5	安全性的問題	3
6	感謝	3
7	參考	4
8	作者地址	4
9	版權聲明	4
10  鳴謝	5

1	 簡介
服務定位協議第二版提供了一種機制，可以通過一次信息交換解釋某項服務。UA發送一
個服務請求消息，DA或者SA（視具體情況而定）則發送服務應答消息。
如果能夠一次獲取全部服務信息顯然是有利的。服務定位協議對取得不同類型信息的消
息進行了區分。這里描述的擴展機制可以優化基本的消息交換，這種交換目前在服務應答消
息中不包含服務屬性。
本文檔描述的SLPv2擴展機制允許服務應答消息中包含UA請求的服務屬性。這樣有助于
減少UA為了獲取全部服務信息進行的消息往返的次數。
如果DA或者SA不支持這種屬性列表擴展，則僅僅返回服務應答（不包含擴展信息）。對
這一擴展的支持是可選的。現有的實現將忽略屬性列表擴展，因為它所分配的標識號所在的
范圍表明接收方必須忽略無法識別的擴展（參見RFC 2608[3]）。
如果UA受到的服務應答消息不含屬性列表擴展信息，則應假定SA或者DA不支持這種擴
展。這種情況下，UA必須對在服務應答消息中得到的每個URL發送屬性請求以取得這些服務
的屬性。   
1.1	 術語
   用戶代理（User Agent，UA）
在用戶方運行以便與某些服務建立聯系的進程。UA從服務代理或目錄代理獲取服
務信息。
   服務代理（Service Agent，SA）
       在一個或多個服務方運行以提供服務信息的進程。
   目錄代理（Directory Agent，DA）
       搜集服務廣告信息的進程，在一個給定的主機上只能有一個DA。 
1.2	 符號約定
本文檔中的關鍵字“必須”、“不得”、“要求”“應”、“不應”、“將”、“不必”、“建議”、
“可以”和“可選”的解釋參見RFC 2119[2]。

2	 屬性列表擴展
屬性列表的擴展如下所示：
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      擴展 ID = 0x0002         |     下一擴展的偏移量          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   續偏移量    |      服務URL的長度           |  服務URL     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     屬性列表長度              |            屬性列表           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |# of AttrAuths |(if present) Attribute Authentication Blocks...|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
擴展ID為 0x0002.
下一擴展偏移表示下一擴展信息的位置，從SLP消息的開始計算偏移量。如果下一擴展
偏移值為0，則說明消息中再沒有其他的擴展信息系了。
UA在服務請求中發送屬性列表擴展，此時服務URL長度和屬性列表長度兩個字段被設為
0，并忽略服務URL和屬性列表字段。因此，通過在服務請求中包括這樣的“空”屬性列表擴
展，UA可以向SA或者DA請求在其服務應答消息中加入屬性列表擴展。
支持屬性列表擴展的SA或者DA為服務應答消息中的每個URL項返回一個屬性屬性擴展。
屬性列表擴展。屬性列表擴展的順序應該應該與服務應答中URL相出現的順序一致。
服務URL[4]標志相應的URL項。
屬性列表字段是服務的全部屬性列表。
這些屬性必須使用服務請求消息指定的語言。
如果服務請求消息包含SLP SPI字符串，屬性列表擴展必須包含驗證塊。如果服務請求
包含SLP SPI，而SA或者DA不支持或者無法返回驗證塊，那么SA或者DA不能返回屬性列
表擴展。驗證塊的格式與屬性應答或者服務注冊消息中的驗證塊完全一樣。

3	 IANA方面的問題
IANA已經為屬性列表擴展分配了擴展ID號 0x0002。

4	 國際化方面的問題
服務定位協議第二版包含一種機制，允許在傳輸屬性時包含明確的語言標簽[6]。該機制
同樣適用于這一協議擴展。

5	安全性的問題
服務定位協議第二版包含一種機制，可以把驗證碼與屬性列表一起返回，從而使UA能夠
對取得的屬性中的數字簽名進行驗證。帶有屬性列表擴展的SLPv2并不會降低其安全性。   
6	 感謝
   作者在與Charlie Perkins就這一擴展的初步交談中受到啟發。

7	參考
   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
       9, RFC 2026, October 1996.
   [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.
   [3] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
       Location Protocol, Version 2", RFC 2608, June 1999.
   [4] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
       service: Schemes", RFC 2609, June 1999.
   [5] Narten, T and H. Alvestrand, "Guidelines for Writing an IANA
       Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
   [6] Alvestrand, H., "Tags for the Identification of Languages", BCP
       47, RFC 3066, January 2001.
8	作者地址
   Erik Guttman
   Sun Microsystems
   Eichhoelzelstr. 7
   74915 Waibstadt
   Germany
   Phone:    +49 6227 356 202
   EMail:    Erik.Guttman@sun.com

9	  版權聲明
   Copyright (C) The Internet Society (2001).  All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

10	  鳴謝
  Funding for the RFC Editor function is currently provided by the
  Internet Society.

RFC3059——Attribute List Extension for the Service Location Protocol
 服務定位協議的屬性列表擴展

RFC中文翻譯計劃