Network Working Group M. Handley
Request for Comments: 2974 ACIRI
Category: Experimental C. Perkins
USC/ISI
E. Whelan
UCL
October 2000
Network Working Group M. Handley
Request for Comments: 2974 ACIRI
Category: Experimental C. Perkins
USC/ISI
E. Whelan
UCL
October 2000
Session Announcement Protocol
会话公告协议
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors.
本文档描述了多播会话目录公告协议的版本2、会话公告协议（SAP）以及影响安全性和可伸缩性的相关问题，这些问题应由实现者考虑。
1 Introduction
1导言
In order to assist the advertisement of multicast multimedia conferences and other multicast sessions, and to communicate the relevant session setup information to prospective participants, a distributed session directory may be used. An instance of such a session directory periodically multicasts packets containing a description of the session, and these advertisements are received by other session directories such that potential remote participants can use the session description to start the tools required to participate in the session.
为了协助多播多媒体会议和其他多播会话的广告，并将相关会话设置信息传达给预期参与者，可以使用分布式会话目录。这样的会话目录的实例周期性地多播包含会话描述的分组，并且这些播发由其他会话目录接收，使得潜在的远程参与者可以使用会话描述来启动参与会话所需的工具。
This memo describes the issues involved in the multicast announcement of session description information and defines an announcement protocol to be used. Sessions are described using the session description protocol which is described in a companion memo [4].
此备忘录描述了会话描述信息的多播公告中涉及的问题，并定义了要使用的公告协议。使用会话描述协议描述会话，该协议在附带备忘录[4]中描述。
2 Terminology
2术语
A SAP announcer periodically multicasts an announcement packet to a well known multicast address and port. The announcement is multicast with the same scope as the session it is announcing, ensuring that the recipients of the announcement are within the scope of the session the announcement describes (bandwidth and other such constraints permitting). This is also important for the scalability of the protocol, as it keeps local session announcements local.
SAP播音员定期将公告数据包多播到已知的多播地址和端口。公告是多播的，其作用域与其所公告的会话相同，确保公告的接收者在公告所描述的会话的作用域内（带宽和其他此类约束允许）。这对于协议的可伸缩性也很重要，因为它使本地会话公告保持在本地。
A SAP listener learns of the multicast scopes it is within (for example, using the Multicast-Scope Zone Announcement Protocol [5]) and listens on the well known SAP address and port for those scopes. In this manner, it will eventually learn of all the sessions being announced, allowing those sessions to be joined.
SAP侦听器了解其所在的多播作用域（例如，使用多播作用域区域公告协议[5]），并侦听这些作用域的众所周知的SAP地址和端口。通过这种方式，它最终将了解所有正在宣布的会议，从而允许这些会议加入。
The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT', `SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this document are to be interpreted as described in [1].
本文件中的关键词‘必须’、‘不得’、‘必需’、‘应’、‘不应’、‘应’、‘不应’、‘建议’、‘可’和‘可选’应按[1]中所述进行解释。
3 Session Announcement
3会议公告
As noted previously, a SAP announcer periodically sends an announcement packet to a well known multicast address and port. There is no rendezvous mechanism - the SAP announcer is not aware of the presence or absence of any SAP listeners - and no additional reliability is provided over the standard best-effort UDP/IP semantics.
如前所述，SAP播音员定期向已知的多播地址和端口发送公告数据包。没有会合机制-SAP播音员不知道是否存在任何SAP侦听器-并且在标准的尽力而为UDP/IP语义上不提供额外的可靠性。
That announcement contains a session description and SHOULD contain an authentication header. The session description MAY be encrypted although this is NOT RECOMMENDED (see section 7).
该公告包含会话描述，并应包含身份验证标头。虽然不建议对会话描述进行加密（参见第7节）。
A SAP announcement is multicast with the same scope as the session it is announcing, ensuring that the recipients of the announcement are within the scope of the session the announcement describes. There are a number of possibilities:
SAP公告是多播的，其作用域与其所公告的会话相同，确保公告的收件人在公告所描述的会话的作用域内。有多种可能性：
IPv4 global scope sessions use multicast addresses in the range 224.2.128.0 - 224.2.255.255 with SAP announcements being sent to 224.2.127.254 (note that 224.2.127.255 is used by the obsolete SAPv0 and MUST NOT be used).
IPv4全局作用域会话使用范围为224.2.128.0-224.2.255.255的多播地址，SAP公告发送至224.2.127.254（请注意，已过时的SAPv0使用224.2.127.255，不得使用）。
IPv4 administrative scope sessions using administratively scoped IP multicast as defined in [7]. The multicast address to be used for announcements is the highest multicast address in the relevant administrative scope zone. For example, if the scope range is 239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used for SAP announcements.
IPv4管理作用域会话使用[7]中定义的管理作用域IP多播。用于公告的多播地址是相关管理范围区域中的最高多播地址。例如，如果范围为239.16.32.0-239.16.33.255，则239.16.33.255用于SAP公告。
IPv6 sessions are announced on the address FF0X:0:0:0:0:0:2:7FFE where X is the 4-bit scope value. For example, an announcement for a link-local session assigned the address FF02:0:0:0:0:0:1234:5678, should be advertised on SAP address FF02:0:0:0:0:0:2:7FFE.
IPv6会话在地址FF0X:0:0:0:0:0:2:7FFE上宣布，其中X是4位作用域值。例如，分配了地址FF02:0:0:0:0:0:1234:5678的链接本地会话的公告应在SAP地址FF02:0:0:0:0:2:7FFE上播发。
Ensuring that a description is not used by a potential participant outside the session scope is not addressed in this memo.
本备忘录不涉及确保会话范围外的潜在参与者不使用描述。
SAP announcements MUST be sent on port 9875 and SHOULD be sent with an IP time-to-live of 255 (the use of TTL scoping for multicast is discouraged [7]).
SAP公告必须在端口9875上发送，并且发送时的IP生存时间应为255（不鼓励在多播中使用TTL作用域[7]）。
If a session uses addresses in multiple administrative scope ranges, it is necessary for the announcer to send identical copies of the announcement to each administrative scope range. It is up to the listeners to parse such multiple announcements as the same session (as identified by the SDP origin field, for example). The announcement rate for each administrative scope range MUST be calculated separately, as if the multiple announcements were separate.
如果会话使用多个管理范围内的地址，播音员必须向每个管理范围发送相同的公告副本。由侦听器将多个公告解析为同一会话（例如，由SDP origin字段标识）。必须单独计算每个管理范围的公告率，就像多个公告是单独的一样。
Multiple announcers may announce a single session, as an aid to robustness in the face of packet loss and failure of one or more announcers. The rate at which each announcer repeats its announcement MUST be scaled back such that the total announcement rate is equal to that which a single server would choose. Announcements made in this manner MUST be identical.
多个播音员可以宣布一个会话，以帮助在一个或多个播音员出现数据包丢失和故障时增强健壮性。必须缩小每个播音员重复其播音的速率，以使总播音速率等于单个服务器将选择的速率。以这种方式发布的公告必须相同。
If multiple announcements are being made for a session, then each announcement MUST carry an authentication header signed by the same key, or be treated as a completely separate announcement by listeners.
如果一个会话有多个公告，则每个公告都必须包含一个由同一密钥签名的身份验证头，或者侦听器将其视为一个完全独立的公告。
An IPv4 SAP listener SHOULD listen on the IPv4 global scope SAP address and on the SAP addresses for each IPv4 administrative scope zone it is within. The discovery of administrative scope zones is outside the scope of this memo, but it is assumed that each SAP listener within a particular scope zone is aware of that scope zone. A SAP listener which supports IPv6 SHOULD also listen to the IPv6 SAP addresses.
IPv4 SAP侦听器应侦听IPv4全局作用域SAP地址及其所在的每个IPv4管理作用域区域的SAP地址。管理范围区域的发现不在本备忘录的范围内，但假定特定范围区域内的每个SAP侦听器都知道该范围区域。支持IPv6的SAP侦听器还应侦听IPv6 SAP地址。
The time period between repetitions of an announcement is chosen such that the total bandwidth used by all announcements on a single SAP group remains below a preconfigured limit. If not otherwise specified, the bandwidth limit SHOULD be assumed to be 4000 bits per second.
选择重复发布之间的时间段，以便单个SAP组上所有发布使用的总带宽保持在预配置的限制以下。如果未另行规定，则应假定带宽限制为每秒4000位。
Each announcer is expected to listen to other announcements in order to determine the total number of sessions being announced on a particular group. Sessions are uniquely identified by the combination of the message identifier hash and originating source fields of the SAP header (note that SAP v0 announcers always set the message identifier hash to zero, and if such an announcement is received the entire message MUST be compared to determine uniqueness).
每个播音员都需要收听其他广播，以确定特定组中广播的会话总数。会话通过消息标识符散列和SAP标头的原始源字段的组合进行唯一标识（请注意，SAP v0播音员始终将消息标识符散列设置为零，如果收到此类通知，则必须比较整个消息以确定唯一性）。
Announcements are made by periodic multicast to the group. The base interval between announcements is derived from the number of announcements being made in that group, the size of the announcement and the configured bandwidth limit. The actual transmission time is derived from this base interval as follows:
通过定期多播向组发布公告。公告之间的基本间隔源自该组中正在进行的公告数量、公告大小和配置的带宽限制。实际传输时间由该基本间隔得出，如下所示：
1. The announcer initializes the variable tp to be the last time a particular announcement was transmitted (or the current time if this is the first time this announcement is to be made).
1. 播音员将变量tp初始化为某个特定播音的最后一次传输时间（如果这是第一次发布此播音，则为当前时间）。
2. Given a configured bandwidth limit in bits/second and an announcement of ad_size bytes, the base announcement interval in seconds is
2. 给定以位/秒为单位的配置带宽限制和ad_大小字节的通知，以秒为单位的基本通知间隔为
interval =max(300; (8*no_of_ads*ad_size)/limit)
interval =max(300; (8*no_of_ads*ad_size)/limit)
3. An offset is calculated based on the base announcement interval
3. 根据基本公告间隔计算偏移量
offset= rand(interval* 2/3)-(interval/3)
offset= rand(interval* 2/3)-(interval/3)
4. The next transmission time for an announcement derived as
4. 导出为的公告的下一次传输时间
tn =tp+ interval+ offset
tn =tp+ interval+ offset
The announcer then sets a timer to expire at tn and waits. At time tn the announcer SHOULD recalculate the next transmission time. If the new value of tn is before the current time, the announcement is sent immediately. Otherwise the transmission is rescheduled for the new tn. This reconsideration prevents transient packet bursts on startup and when a network partition heals.
然后播音员将计时器设置为在tn过期并等待。在时间tn，播音员应重新计算下一次传输时间。如果tn的新值在当前时间之前，则立即发送公告。否则，将为新的tn重新安排传输。这种重新考虑可防止启动时以及网络分区恢复时出现瞬时数据包突发。
4 Session Deletion
4会话删除
Sessions may be deleted in one of several ways:
可以通过以下几种方式之一删除会话：
Explicit Timeout The session description payload may contain timestamp information specifying the start- and end-times of the session. If the current time is later than the end-time of the session, then the session SHOULD be deleted from the receiver's session cache.
显式超时会话描述负载可能包含指定会话开始和结束时间的时间戳信息。如果当前时间晚于会话的结束时间，则应从接收方的会话缓存中删除会话。
Implicit Timeout A session announcement message should be received periodically for each session description in a receiver's session cache. The announcement period can be predicted by the receiver from the set of sessions currently being announced. If a session announcement message has not been received for ten times the announcement period, or one hour, whichever is the greater, then the session is deleted from the receiver's session cache. The one hour minimum is to allow for transient network partitionings.
隐式超时对于接收方会话缓存中的每个会话描述，应定期接收会话公告消息。接收者可以从当前正在宣布的会话集合中预测宣布周期。如果会话公告消息在公告周期的十倍或一小时内（以较大者为准）未收到，则该会话将从接收方的会话缓存中删除。最短一小时是为了允许暂时的网络划分。
Explicit Deletion A session deletion packet is received specifying the session to be deleted. Session deletion packets SHOULD have a valid authentication header, matching that used to authenticate previous announcement packets. If this authentication is missing, the deletion message SHOULD be ignored.
显式删除收到指定要删除会话的会话删除数据包。会话删除数据包应具有有效的身份验证标头，该标头与用于对以前的公告数据包进行身份验证的标头相匹配。如果缺少此身份验证，则应忽略删除消息。
5 Session Modification
5会话修改
A pre-announced session can be modified by simply announcing the modified session description. In this case, the version hash in the SAP header MUST be changed to indicate to receivers that the packet contents should be parsed (or decrypted and parsed if it is encrypted). The session itself, as distinct from the session announcement, is uniquely identified by the payload and not by the message identifier hash in the header.
只需宣布修改的会话描述，即可修改预先宣布的会话。在这种情况下，必须更改SAP报头中的版本散列，以向接收者指示应该解析数据包内容（如果是加密的，则对其进行解密和解析）。与会话公告不同的是，会话本身由有效负载而不是报头中的消息标识符散列唯一标识。
The same rules apply for session modification as for session deletion:
会话修改和会话删除适用相同的规则：
o Either the modified announcement must contain an authentication header signed by the same key as the cached session announcement it is modifying, or:
o 修改后的公告必须包含由与其正在修改的缓存会话公告相同的密钥签名的身份验证标头，或者：
o The cached session announcement must not contain an authentication header, and the session modification announcement must originate from the same host as the session it is modifying.
o 缓存的会话公告不得包含身份验证标头，并且会话修改公告必须来自与其正在修改的会话相同的主机。
If an announcement is received containing an authentication header and the cached announcement did not contain an authentication header, or it contained a different authentication header, then the modified announcement MUST be treated as a new and different announcement, and displayed in addition to the un-authenticated announcement. The same should happen if a modified packet without an authentication header is received from a different source than the original announcement.
如果接收到包含身份验证标头的公告，而缓存的公告不包含身份验证标头，或者它包含不同的身份验证标头，则修改后的公告必须视为新的不同公告，并在未经身份验证的公告之外显示。如果从与原始公告不同的来源接收到没有身份验证标头的修改数据包，也会发生同样的情况。
These rules prevent an announcement having an authentication header added by a malicious user and then being deleted using that header, and it also prevents a denial-of-service attack by someone putting out a spoof announcement which, due to packet loss, reaches some participants before the original announcement. Note that under such circumstances, being able to authenticate the message originator is the only way to discover which session is the correct session.
这些规则可防止恶意用户添加了身份验证标头的公告，然后使用该标头将其删除，还可防止发布欺骗公告的人进行拒绝服务攻击，该欺骗公告由于数据包丢失而在原始公告之前到达某些参与者。请注意，在这种情况下，能够验证消息发起人是发现哪个会话是正确会话的唯一方法。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |A|R|T|E|C| auth len | msg id hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: originating source (32 or 128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional authentication data |
: .... :
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| optional payload type |
+ +-+- - - - - - - - - -+
| |0| |
+ - - - - - - - - - - - - - - - - - - - - +-+ |
| |
: payload :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |A|R|T|E|C| auth len | msg id hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: originating source (32 or 128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional authentication data |
: .... :
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| optional payload type |
+ +-+- - - - - - - - - -+
| |0| |
+ - - - - - - - - - - - - - - - - - - - - +-+ |
| |
: payload :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Packet format
图1：数据包格式
6 Packet Format
6数据包格式
SAP data packets have the format described in figure 1.
SAP数据包的格式如图1所示。
V: Version Number. The version number field MUST be set to 1 (SAPv2 announcements which use only SAPv1 features are backwards compatible, those which use new features can be detected by other means, so the SAP version number doesn't need to change).
V:版本号。版本号字段必须设置为1（仅使用SAPv1功能的SAPv2公告向后兼容，使用新功能的SAPv2公告可以通过其他方式检测到，因此SAP版本号无需更改）。
A: Address type. If the A bit is 0, the originating source field contains a 32-bit IPv4 address. If the A bit is 1, the originating source contains a 128-bit IPv6 address.
A:地址类型。如果A位为0，则原始源字段包含32位IPv4地址。如果A位为1，则发起源包含128位IPv6地址。
R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST ignore the contents of this field.
R:保留。SAP播音员必须将其设置为0，SAP侦听器必须忽略此字段的内容。
T: Message Type. If the T field is set to 0 this is a session announcement packet, if 1 this is a session deletion packet.
T：消息类型。如果T字段设置为0，则这是会话公告数据包；如果为1，则这是会话删除数据包。
E: Encryption Bit. If the encryption bit is set to 1, the payload of the SAP packet is encrypted. If this bit is 0 the packet is not encrypted. See section 7 for details of the encryption process.
E:加密位。如果加密位设置为1，则对SAP数据包的有效负载进行加密。如果该位为0，则数据包不加密。有关加密过程的详细信息，请参见第7节。
C: Compressed bit. If the compressed bit is set to 1, the payload is compressed using the zlib compression algorithm [3]. If the payload is to be compressed and encrypted, the compression MUST be performed first.
C：压缩位。如果压缩位设置为1，则使用zlib压缩算法压缩有效负载[3]。如果要压缩和加密有效负载，则必须首先执行压缩。
Authentication Length. An 8 bit unsigned quantity giving the number of 32 bit words following the main SAP header that contain authentication data. If it is zero, no authentication header is present.
验证长度。一个8位无符号量，给出包含身份验证数据的主SAP标头后面的32位字数。如果为零，则不存在身份验证标头。
Authentication data containing a digital signature of the packet, with length as specified by the authentication length header field. See section 8 for details of the authentication process.
包含数据包数字签名的身份验证数据，长度由身份验证长度标头字段指定。有关身份验证过程的详细信息，请参见第8节。
Message Identifier Hash. A 16 bit quantity that, used in combination with the originating source, provides a globally unique identifier indicating the precise version of this announcement. The choice of value for this field is not specified here, except that it MUST be unique for each session announced by a particular SAP announcer and it MUST be changed if the session description is modified (and a session deletion message SHOULD be sent for the old version of the session).
消息标识符散列。一种16位量，与原始源一起使用，提供一个全局唯一标识符，指示本公告的精确版本。此处未指定此字段的值选择，但对于特定SAP播音员宣布的每个会话，该字段必须是唯一的，并且如果会话描述被修改，则必须对其进行更改（对于旧版本的会话，应发送会话删除消息）。
Earlier versions of SAP used a value of zero to mean that the hash should be ignored and the payload should always be parsed. This had the unfortunate side-effect that SAP announcers had to study the payload data to determine how many unique sessions were being advertised, making the calculation of the announcement interval more complex that necessary. In order to decouple the session announcement process from the contents of those announcements, SAP announcers SHOULD NOT set the message identifier hash to zero.
早期版本的SAP使用零值表示应忽略哈希，并且应始终解析有效负载。这产生了一个不幸的副作用，即SAP播音员必须研究有效负载数据，以确定正在播发的唯一会话数，从而使播音间隔的计算变得更加复杂。为了将会话公告流程与这些公告的内容分离，SAP公告员不应将消息标识符哈希设置为零。
SAP listeners MAY silently discard messages if the message identifier hash is set to zero.
如果消息标识符哈希设置为零，SAP侦听器可能会自动丢弃消息。
Originating Source. This gives the IP address of the original source of the message. This is an IPv4 address if the A field is set to zero, else it is an IPv6 address. The address is stored in network byte order.
始发源。这将提供消息原始源的IP地址。如果A字段设置为零，则为IPv4地址，否则为IPv6地址。地址以网络字节顺序存储。
SAPv0 permitted the originating source to be zero if the message identifier hash was also zero. This practise is no longer legal, and SAP announcers SHOULD NOT set the originating source to zero. SAP listeners MAY silently discard packets with the originating source set to zero.
如果消息标识符散列也为零，则SAPv0允许原始源为零。这种做法不再合法，SAP播音员不应将原始源设置为零。SAP侦听器可以静默地丢弃原始源设置为零的数据包。
The header is followed by an optional payload type field and the payload data itself. If the E or C bits are set in the header both the payload type and payload are encrypted and/or compressed.
标头后面是可选的有效负载类型字段和有效负载数据本身。如果在报头中设置了E或C位，则有效负载类型和有效负载都将被加密和/或压缩。
The payload type field is a MIME content type specifier, describing the format of the payload. This is a variable length ASCII text string, followed by a single zero byte (ASCII NUL). The payload type SHOULD be included in all packets. If the payload type is `application/sdp' both the payload type and its terminating zero byte MAY be omitted, although this is intended for backwards compatibility with SAP v1 listeners only.
有效负载类型字段是一个MIME内容类型说明符，描述有效负载的格式。这是一个可变长度的ASCII文本字符串，后跟一个零字节（ASCII NUL）。有效负载类型应包含在所有数据包中。如果有效负载类型为“application/sdp”，则可以省略有效负载类型及其终止零字节，尽管这仅用于与SAP v1侦听器的向后兼容性。
The absence of a payload type field may be noted since the payload section of such a packet will start with an SDP `v=0' field, which is not a legal MIME content type specifier.
可以注意到没有有效负载类型字段，因为这样的分组的有效负载部分将以SDP`v=0'字段开头，该字段不是合法的MIME内容类型说明符。
All implementations MUST support payloads of type `application/sdp' [4]. Other formats MAY be supported although since there is no negotiation in SAP an announcer which chooses to use a session description format other than SDP cannot know that the listeners are able to understand the announcement. A proliferation of payload types in announcements has the potential to lead to severe interoperability problems, and for this reason, the use of non-SDP payloads is NOT RECOMMENDED.
所有实现必须支持“应用程序/sdp”类型的有效负载[4]。尽管由于SAP中没有协商，选择使用SDP以外的会话描述格式的播音员无法知道听众能够理解该播音，但也可以支持其他格式。公告中有效负载类型的激增有可能导致严重的互操作性问题，因此，不建议使用非SDP有效负载。
If the packet is an announcement packet, the payload contains a session description.
如果数据包是公告数据包，则有效负载包含会话描述。
If the packet is a session deletion packet, the payload contains a session deletion message. If the payload format is `application/sdp' the deletion message is a single SDP line consisting of the origin field of the announcement to be deleted.
如果该分组是会话删除分组，则有效负载包含会话删除消息。如果有效负载格式为“应用程序/sdp”，则删除消息为单个sdp行，由要删除的公告的原始字段组成。
It is desirable for the payload to be sufficiently small that SAP packets do not get fragmented by the underlying network. Fragmentation has a loss multiplier effect, which is known to significantly affect the reliability of announcements. It is
希望有效负载足够小，以使SAP数据包不会被底层网络分割。碎片化会产生损失乘数效应，这会显著影响公告的可靠性。它是
RECOMMENDED that SAP packets are smaller than 1kByte in length, although if it is known that announcements will use a network with a smaller MTU than this, then that SHOULD be used as the maximum recommended packet size.
建议SAP数据包的长度小于1kByte，但如果已知公告将使用MTU小于1kByte的网络，则应将其用作最大建议数据包大小。
7 Encrypted Announcements
7加密公告
An announcement is received by all listeners in the scope to which it is sent. If an announcement is encrypted, and many of the receivers do not have the encryption key, there is a considerable waste of bandwidth since those receivers cannot use the announcement they have received. For this reason, the use of encrypted SAP announcements is NOT RECOMMENDED on the global scope SAP group or on administrative scope groups which may have many receivers which cannot decrypt those announcements.
通知将被发送到的范围内的所有侦听器接收。如果对公告进行了加密，并且许多接收者没有加密密钥，则会造成相当大的带宽浪费，因为这些接收者无法使用他们收到的公告。因此，不建议在全局范围SAP组或管理范围组上使用加密的SAP公告，因为这些组可能有许多接收者无法解密这些公告。
The opinion of the authors is that encrypted SAP is useful in special cases only, and that the vast majority of scenarios where encrypted SAP has been proposed may be better served by distributing session details using another mechanism. There are, however, certain scenarios where encrypted announcements may be useful. For this reason, the encryption bit is included in the SAP header to allow experimentation with encrypted announcements.
作者的观点是，加密SAP仅在特殊情况下才有用，并且提出加密SAP的绝大多数场景都可以通过使用另一种机制分发会话细节来更好地服务。但是，在某些情况下，加密公告可能会很有用。因此，SAP标头中包含了加密位，以允许对加密公告进行实验。
This memo does not specify details of the encryption algorithm to be used or the means by which keys are generated and distributed. An additional specification should define these, if it is desired to use encrypted SAP.
本备忘录未详细说明要使用的加密算法或生成和分发密钥的方法。如果希望使用加密的SAP，则应使用其他规范来定义这些。
Note that if an encrypted announcement is being announced via a proxy, then there may be no way for the proxy to discover that the announcement has been superseded, and so it may continue to relay the old announcement in addition to the new announcement. SAP provides no mechanism to chain modified encrypted announcements, so it is advisable to announce the unmodified session as deleted for a short time after the modification has occurred. This does not guarantee that all proxies have deleted the session, and so receivers of encrypted sessions should be prepared to discard old versions of session announcements that they may receive. In most cases however, the only stateful proxy will be local to (and known to) the sender, and an additional (local-area) protocol involving a handshake for such session modifications can be used to avoid this problem.
请注意，如果加密公告是通过代理发布的，那么代理可能无法发现该公告已被取代，因此它可能会在新公告之外继续转发旧公告。SAP不提供链接修改的加密公告的机制，因此建议在修改发生后短时间内将未修改的会话宣布为已删除。这并不保证所有代理都删除了会话，因此加密会话的接收者应该准备放弃他们可能收到的旧版本的会话通知。然而，在大多数情况下，唯一的有状态代理将是发送方本地的（并且是发送方所知道的），并且可以使用一个额外的（本地）协议来避免这个问题，该协议涉及到会话修改的握手。
Session announcements that are encrypted with a symmetric algorithm may allow a degree of privacy in the announcement of a session, but it should be recognized that a user in possession of such a key can pass it on to other users who should not be in possession of such a key. Thus announcements to such a group of key holders cannot be
使用对称算法加密的会话公告可能允许在会话公告中具有一定程度的隐私，但是应该认识到，拥有该密钥的用户可以将其传递给不应该拥有该密钥的其他用户。因此，向这样一组密钥持有者发布的公告不能
assumed to have come from an authorized key holder unless there is an appropriate authentication header signed by an authorized key holder. In addition the recipients of such encrypted announcements cannot be assumed to only be authorized key holders. Such encrypted announcements do not provide any real security unless all of the authorized key holders are trusted to maintain security of such session directory keys. This property is shared by the multicast session tools themselves, where it is possible for an un-trustworthy member of the session to pass on encryption keys to un-authorized users. However it is likely that keys used for the session tools will be more short lived than those used for session directories.
假设来自授权密钥持有人，除非有授权密钥持有人签署的适当身份验证标头。此外，不能假定此类加密公告的接收人仅为授权密钥持有人。除非所有授权密钥持有者都被信任来维护此类会话目录密钥的安全性，否则此类加密公告不会提供任何真正的安全性。此属性由多播会话工具本身共享，其中会话的不可信成员可以将加密密钥传递给未经授权的用户。但是，用于会话工具的键可能比用于会话目录的键寿命更短。
Similar considerations should apply when session announcements are encrypted with an asymmetric algorithm, but then it is possible to restrict the possessor(s) of the private key, so that announcements to a key-holder group can not be made, even if one of the untrusted members of the group proves to be un-trustworthy.
当使用非对称算法对会话通知进行加密时，也应考虑类似的因素，但可以限制私钥的拥有者，这样即使组中不受信任的成员之一被证明不可信，也无法向密钥持有者组发布通知。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |P| Auth | |
+-+-+-+-+-+-+-+-+ |
| Format specific authentication subheader |
: .................. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |P| Auth | |
+-+-+-+-+-+-+-+-+ |
| Format specific authentication subheader |
: .................. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of the authentication data in the SAP header
图2:SAP头中身份验证数据的格式
8 Authenticated Announcements
8经认证的公告
The authentication header can be used for two purposes:
身份验证标头可用于两个目的：
o Verification that changes to a session description or deletion of a session are permitted.
o 验证是否允许更改会话描述或删除会话。
o Authentication of the identity of the session creator.
o 会话创建者的身份验证。
In some circumstances only verification is possible because a certificate signed by a mutually trusted person or authority is not available. However, under such circumstances, the session originator may still be authenticated to be the same as the session originator of previous sessions claiming to be from the same person. This may or may not be sufficient depending on the purpose of the session and the people involved.
在某些情况下，由于相互信任的人员或机构签署的证书不可用，因此只能进行验证。然而，在这种情况下，会话发起人仍然可以被认证为与声称来自同一个人的先前会话的会话发起人相同。这可能是不够的，也可能是不够的，这取决于会议的目的和参与人员。
Clearly the key used for the authentication should not be trusted to belong to the session originator unless it has been separately authenticated by some other means, such as being certified by a trusted third party. Such certificates are not normally included in an SAP header because they take more space than can normally be afforded in an SAP packet, and such verification must therefore take place by some other mechanism. However, as certified public keys are normally locally cached, authentication of a particular key only has to take place once, rather than every time the session directory retransmits the announcement.
显然，用于身份验证的密钥不应被信任为属于会话发起人，除非它已通过其他方式进行了单独身份验证，例如由受信任的第三方进行了认证。此类证书通常不包括在SAP报头中，因为它们占用的空间比SAP数据包中通常提供的空间大，因此此类验证必须通过其他机制进行。但是，由于经过认证的公钥通常在本地缓存，因此特定密钥的身份验证只需进行一次，而不是每次会话目录重新传输公告时进行。
SAP is not tied to any single authentication mechanism. Authentication data in the header is self-describing, but the precise format depends on the authentication mechanism in use. The generic format of the authentication data is given in figure 2. The structure of the format specific authentication subheader, using both the PGP and the CMS formats, is discussed in sections 8.1 and 8.2 respectively. Additional formats may be added in future.
SAP不受任何单一身份验证机制的约束。标头中的身份验证数据是自描述的，但精确的格式取决于使用的身份验证机制。认证数据的通用格式如图2所示。第8.1节和第8.2节分别讨论了使用PGP和CMS格式的格式特定认证子标题的结构。将来可能会添加其他格式。
Version Number, V: The version number of the authentication format specified by this memo is 1.
版本号，V：此备忘录指定的身份验证格式的版本号为1。
Padding Bit, P: If necessary the authentication data is padded to be a multiple of 32 bits and the padding bit is set. In this case the last byte of the authentication data contains the number of padding bytes (including the last byte) that must be discarded.
Padding Bit，P：如有必要，将验证数据填充为32位的倍数，并设置填充位。在这种情况下，身份验证数据的最后一个字节包含必须丢弃的填充字节数（包括最后一个字节）。
Authentication Type, Auth: The authentication type is a 4 bit encoded field that denotes the authentication infrastructure the sender expects the recipients to use to check the authenticity and integrity of the information. This defines the format of the authentication subheader and can take the values: 0 = PGP format, 1 = CMS format. All other values are undefined and SHOULD be ignored.
身份验证类型，Auth：身份验证类型是一个4位编码字段，表示发送方希望接收方用于检查信息真实性和完整性的身份验证基础结构。这定义了身份验证子标题的格式，可以采用以下值：0=PGP格式，1=CMS格式。所有其他值均未定义，应忽略。
If a SAP packet is to be compressed or encrypted, this MUST be done before the authentication is added.
如果要压缩或加密SAP数据包，则必须在添加身份验证之前进行压缩或加密。
The digital signature in the authentication data MUST be calculated over the entire packet, including the header. The authentication length MUST be set to zero and the authentication data excluded when calculating the digital signature.
认证数据中的数字签名必须计算整个数据包，包括报头。在计算数字签名时，必须将身份验证长度设置为零，并排除身份验证数据。
It is to be expected that sessions may be announced by a number of different mechanisms, not only SAP. For example, a session description may placed on a web page, sent by email or conveyed in a
可以预期，会议可能会由许多不同的机制宣布，而不仅仅是SAP。例如，会话描述可以放在网页上、通过电子邮件发送或以电子邮件形式传达
session initiation protocol. To ease interoperability with these other mechanisms, application level security is employed, rather than using IPsec authentication headers.
会话启动协议。为了简化与这些其他机制的互操作性，采用了应用程序级安全性，而不是使用IPsec身份验证头。
A full description of the PGP protocol can be found in [2]. When using PGP for SAP authentication the basic format specific authentication subheader comprises a digital signature packet as described in [2]. The signature type MUST be 0x01 which means the signature is that of a canonical text document.
PGP协议的完整描述见[2]。使用PGP进行SAP身份验证时，基本格式特定身份验证子标题包含数字签名数据包，如[2]所述。签名类型必须为0x01，这意味着签名是规范文本文档的签名。
A full description of the Cryptographic Message Syntax can be found in [6]. The format specific authentication subheader will, in the CMS case, have an ASN.1 ContentInfo type with the ContentType being signedData.
加密消息语法的完整描述见[6]。在CMS情况下，特定于格式的身份验证子标题将具有ASN.1 ContentInfo类型，ContentType为signedData。
Use is made of the option available in PKCS#7 to leave the content itself blank as the content which is signed is already present in the packet. Inclusion of it within the SignedData type would duplicate this data and increase the packet length unnecessarily. In addition this allows recipients with either no interest in the authentication, or with no mechanism for checking it, to more easily skip the authentication information.
使用PKCS#7中的选项将内容本身留空，因为已签名的内容已存在于数据包中。将其包含在SignedData类型中会复制此数据并不必要地增加数据包长度。此外，这允许对身份验证不感兴趣或没有检查机制的收件人更容易跳过身份验证信息。
There SHOULD be only one signerInfo and related fields corresponding to the originator of the SAP announcement. The signingTime SHOULD be present as a signedAttribute. However, due to the strict size limitations on the size of SAP packets, certificates and CRLs SHOULD NOT be included in the signedData structure. It is expected that users of the protocol will have other methods for certificate and CRL distribution.
只有一个signerInfo和相关字段对应于SAP公告的发起人。签名时间应作为签名属性出现。但是，由于SAP数据包的大小受到严格的大小限制，signedData结构中不应包括证书和CRL。预计该协议的用户将拥有证书和CRL分发的其他方法。
9 Scalability and caching
9可扩展性和缓存
SAP is intended to announce the existence of long-lived wide-area multicast sessions. It is not an especially timely protocol: sessions are announced by periodic multicast with a repeat rate on the order of tens of minutes, and no enhanced reliability over UDP. This leads to a long startup delay before a complete set of announcements is heard by a listener. This delay is clearly undesirable for interactive browsing of announced sessions.
SAP打算宣布存在长寿命广域多播会话。它不是一个特别及时的协议：会话是通过周期性多播宣布的，重复率大约为几十分钟，并且没有通过UDP增强可靠性。这会导致启动延迟很长时间，然后侦听器才能听到完整的公告集。这种延迟显然不适合交互式浏览已宣布的会话。
In order to reduce the delays inherent in SAP, it is recommended that proxy caches are deployed. A SAP proxy cache is expected to listen to all SAP groups in its scope, and to maintain an up-to-date list of
为了减少SAP固有的延迟，建议部署代理缓存。SAP代理缓存应侦听其范围内的所有SAP组，并维护最新的组列表
all announced sessions along with the time each announcement was last received. When a new SAP listeners starts, it should contact its local proxy to download this information, which is then sufficient for it to process future announcements directly, as if it has been continually listening.
所有已发布的会话以及上次收到每个公告的时间。当一个新的SAP侦听器启动时，它应该联系其本地代理下载此信息，这就足以让它直接处理未来的公告，就像它一直在侦听一样。
The protocol by which a SAP listener contacts its local proxy cache is not specified here.
此处未指定SAP侦听器联系其本地代理缓存的协议。
10 Security Considerations
10安全考虑
SAP contains mechanisms for ensuring integrity of session announcements, for authenticating the origin of an announcement and for encrypting such announcements (sections 7 and 8).
SAP包含确保会话公告完整性、验证公告来源和加密此类公告的机制（第7节和第8节）。
As stated in section 5, if a session modification announcement is received that contains a valid authentication header, but which is not signed by the original creator of the session, then the session must be treated as a new session in addition to the original session with the same SDP origin information unless the originator of one of the session descriptions can be authenticated using a certificate signed by a trusted third party. If this were not done, there would be a possible denial of service attack whereby a party listens for new announcements, strips off the original authentication header, modifies the session description, adds a new authentication header and re-announces the session. If a rule was imposed that such spoof announcements were ignored, then if packet loss or late starting of a session directory instance caused the original announcement to fail to arrive at a site, but the spoof announcement did so, this would then prevent the original announcement from being accepted at that site.
如第5节所述，如果收到的会话修改通知包含有效的身份验证标头，但未经会话的原始创建者签名，然后，该会话必须被视为具有相同SDP源信息的原始会话之外的新会话，除非会话描述之一的发起人可以使用可信第三方签署的证书进行身份验证。如果未执行此操作，则可能会发生拒绝服务攻击，其中一方侦听新通知、剥离原始身份验证标头、修改会话描述、添加新身份验证标头并重新宣布会话。如果规定忽略此类欺骗公告，则如果数据包丢失或会话目录实例启动延迟导致原始公告无法到达某个站点，但欺骗公告确实到达了该站点，则会阻止该站点接受原始公告。
A similar denial-of-service attack is possible if a session announcement receiver relies completely on the originating source and hash fields to indicate change, and fails to parse the remainder of announcements for which it has seen the origin/hash combination before.
如果会话公告接收器完全依赖于原始源和散列字段来指示更改，并且未能解析之前已看到源/散列组合的其余公告，则可能发生类似的拒绝服务攻击。
A denial of service attack is possible from a malicious site close to a legitimate site which is making a session announcement. This can happen if the malicious site floods the legitimate site with huge numbers of (illegal) low TTL announcements describing high TTL sessions. This may reduce the session announcement rate of the legitimate announcement to below a tenth of the rate expected at remote sites and therefore cause the session to time out. Such an attack is likely to be easily detectable, and we do not provide any mechanism here to prevent it.
拒绝服务攻击可能来自正在发布会话公告的合法站点附近的恶意站点。如果恶意站点向合法站点发送大量（非法）描述高TTL会话的低TTL公告，则可能发生这种情况。这可能会将合法公告的会话公告速率降低到远程站点预期速率的十分之一以下，从而导致会话超时。这种攻击很可能很容易被检测到，我们这里没有提供任何机制来防止它。
A. Summary of differences between SAPv0 and SAPv1
A.SAPv0和SAPv1之间的差异摘要
For this purpose SAPv0 is defined as the protocol in use by version 2.2 of the session directory tool, sdr. SAPv1 is the protocol described in the 19 November 1996 version of this memo. The packet headers of SAP messages are the same in V0 and V1 in that a V1 tool can parse a V0 announcement header but not vice-versa. In SAPv0, the fields have the following values:
为此，SAPv0被定义为会话目录工具sdr版本2.2使用的协议。SAPv1是本备忘录1996年11月19日版本中描述的协议。SAP消息的数据包头在V0和V1中是相同的，因为V1工具可以解析V0公告头，但反之亦然。在SAPv0中，字段具有以下值：
o Version Number: 0
o 版本号：0
o Message Type: 0 (Announcement)
o 消息类型：0（公告）
o Authentication Type: 0 (No Authentication)
o 身份验证类型：0（无身份验证）
o Encryption Bit: 0 (No Encryption)
o 加密位：0（无加密）
o Compression Bit: 0 (No compression)
o 压缩位：0（无压缩）
o Message Id Hash: 0 (No Hash Specified)
o 消息Id哈希：0（未指定哈希）
o Originating Source: 0 (No source specified, announcement has not been relayed)
o 发起源：0（未指定源，公告尚未中继）
B. Summary of differences between SAPv1 and SAPv2
B.SAPv1和SAPv2之间的差异摘要
The packet headers of SAP messages are the same in V1 and V2 in that a V2 tool can parse a V1 announcement header but not necessarily vice-versa.
SAP消息的数据包头在V1和V2中是相同的，因为V2工具可以解析V1公告头，但不一定相反。
o The A bit has been added to the SAP header, replacing one of the bits of the SAPv1 message type field. If set to zero the announcement is of an IPv4 session, and the packet is backwards compatible with SAPv1. If set to one the announcement is of an IPv6 session, and SAPv1 listeners (which do not support IPv6) will see this as an illegal message type (MT) field.
o 已将A位添加到SAP标头，替换SAPv1消息类型字段的一个位。如果设置为零，则公告为IPv4会话，并且数据包向后兼容SAPv1。如果设置为1，则公告为IPv6会话，SAPv1侦听器（不支持IPv6）会将其视为非法消息类型（MT）字段。
o The second bit of the message type field in SAPv1 has been replaced by a reserved, must-be-zero, bit. This bit was unused in SAPv1, so this change just codifies existing usage.
o SAPv1中消息类型字段的第二位已替换为保留位，必须为零。此位在SAPv1中未使用，因此此更改仅对现有用法进行编码。
o SAPv1 specified encryption of the payload. SAPv2 includes the E bit in the SAP header to indicate that the payload is encrypted, but does not specify any details of the encryption.
o SAPv1指定了有效负载的加密。SAPv2在SAP报头中包含E位，以指示有效负载已加密，但未指定加密的任何详细信息。
o SAPv1 allowed the message identifier hash and originating source fields to be set to zero, for backwards compatibility. This is no longer legal.
o 为了向后兼容，SAPv1允许将消息标识符散列和原始源字段设置为零。这已不再合法。
o SAPv1 specified gzip compression. SAPv2 uses zlib (the only known implementation of SAP compression used zlib, and gzip compression was a mistake).
o SAPv1指定了gzip压缩。SAPv2使用zlib（唯一已知的SAP压缩实现使用zlib，而gzip压缩是一个错误）。
o SAPv2 provides a more complete specification for authentication.
o SAPv2提供了更完整的身份验证规范。
o SAPv2 allows for non-SDP payloads to be transported. SAPv1 required that the payload was SDP.
o SAPv2允许运输非SDP有效载荷。SAPv1要求有效载荷为SDP。
o SAPv1 included a timeout field for encrypted announcement, SAPv2 does not (and relies of explicit deletion messages or implicit timeouts).
o SAPv1包含一个用于加密公告的超时字段，SAPv2没有（并且依赖于显式删除消息或隐式超时）。
C. Acknowledgements
C.致谢
SAP and SDP were originally based on the protocol used by the sd session directory from Van Jacobson at LBNL. Version 1 of SAP was designed by Mark Handley as part of the European Commission MICE (Esprit 7602) and MERCI (Telematics 1007) projects. Version 2 includes authentication features developed by Edmund Whelan, Goli Montasser-Kohsari and Peter Kirstein as part of the European Commission ICE-TEL project (Telematics 1005), and support for IPv6 developed by Maryann P. Maher and Colin Perkins.
SAP和SDP最初基于LBNL的Van Jacobson提供的sd会话目录所使用的协议。SAP第1版由Mark Handley设计，作为欧洲委员会MICE（Esprit 7602）和MECI（远程信息处理1007）项目的一部分。版本2包括Edmund Whelan、Goli Montasser Kohsari和Peter Kirstein开发的身份验证功能，作为欧盟委员会ICE-TEL项目（远程通信1005）的一部分，以及Maryann P.Maher和Colin Perkins开发的IPv6支持。
D. Authors' Addresses
D.作者地址
Mark Handley AT&T Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA
美国加利福尼亚州伯克利中心大街1947号中心街600室国际计算机科学研究所ICSI互联网研究中心马克·汉德利，邮编94704
EMail: mjh@aciri.org
EMail: mjh@aciri.org
Colin Perkins USC Information Sciences Institute 4350 N. Fairfax Drive, Suite 620 Arlington, VA 22203, USA
科林·帕金斯南加州信息科学研究所美国弗吉尼亚州阿灵顿费尔法克斯大道北4350号620室22203
EMail: csp@isi.edu
EMail: csp@isi.edu
Edmund Whelan Department of Computer Science, University College London, Gower Street, London, WC1E 6BT, UK
Edmund Whelan，伦敦大学学院计算机科学系，伦敦高尔街，WC1E 6BT，英国
EMail: e.whelan@cs.ucl.ac.uk
EMail: e.whelan@cs.ucl.ac.uk
References
工具书类
[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer. "OpenPGP message format", RFC 2440, November 1998.
[2] 卡拉斯，J.，唐纳哈克，L.，芬尼，H.和R.塞耶。“OpenPGP消息格式”，RFC2440，1998年11月。
[3] Deutsch, P. and J.-L. Gailly, "Zlib compressed data format specification version 3.3", RFC 1950, May 1996.
[3] Deutsch，P.和J.-L.Gailly，“Zlib压缩数据格式规范3.3版”，RFC 1950，1996年5月。
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[4] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[5] Handley, M., Thaler, D. and R. Kermode, "Multicast-scope zone announcement protocol (MZAP)", RFC 2776, February 2000.
[5] Handley，M.，Thaler，D.和R.Kermode，“多播作用域公告协议（MZAP）”，RFC 27762000年2月。
[6] Housley, R., "Cryptographic message syntax", RFC 2630, June 1999.
[6] Housley，R.，“加密消息语法”，RFC 2630，1999年6月。
[7] Mayer, D., "Administratively scoped IP multicast", RFC 2365, July 1998.
[7] Mayer，D.，“管理范围的IP多播”，RFC 2365，1998年7月。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。