Network Working Group N. Williams
Request for Comments: 5178 Sun
Category: Standards Track A. Melnikov
Isode Ltd.
May 2008
Network Working Group N. Williams
Request for Comments: 5178 Sun
Category: Standards Track A. Melnikov
Isode Ltd.
May 2008
Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type
通用安全服务应用程序接口（GSS-API）国际化和基于域的服务名称和名称类型
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes domain-name-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Internationalization of the GSS-API is also covered.
本文档描述了基于域名的服务主体名称以及通用安全服务应用程序编程接口（GSS-API）的相应名称类型。还包括GSS-API的国际化。
Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the "domain" which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names.
基于域的服务名称类似于基于主机的服务名称，但除了主机名之外还使用域名（不一定是Internet域名）。基于域的名称的主要目的是为使用不安全服务发现协议的应用程序提供保护措施。这是通过提供一种在集群服务所服务的“域”之后命名集群服务的方法来实现的，从而允许它们的客户机基于服务名称的身份验证来授权服务的服务器。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Name Type OID . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Name Type OID and Symbolic Name . . . . . . . . . . . . . . 4
4. Query and Display Syntaxes . . . . . . . . . . . . . . . . . . 4
4.1. Examples of Domain-Based Names . . . . . . . . . . . . . . 5
5. Internationalization (I18N) Considerations . . . . . . . . . . 5
5.1. Importing Internationalized Names . . . . . . . . . . . . . 5
5.2. Displaying Internationalized Names . . . . . . . . . . . . 5
6. Application Protocol Examples . . . . . . . . . . . . . . . . . 6
6.1. NFSv4 Domain-Wide Namespace Root Server Discovery . . . . . 6
6.2. LDAP Server Discovery . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Name Type OID . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Name Type OID and Symbolic Name . . . . . . . . . . . . . . 4
4. Query and Display Syntaxes . . . . . . . . . . . . . . . . . . 4
4.1. Examples of Domain-Based Names . . . . . . . . . . . . . . 5
5. Internationalization (I18N) Considerations . . . . . . . . . . 5
5.1. Importing Internationalized Names . . . . . . . . . . . . . 5
5.2. Displaying Internationalized Names . . . . . . . . . . . . 5
6. Application Protocol Examples . . . . . . . . . . . . . . . . . 6
6.1. NFSv4 Domain-Wide Namespace Root Server Discovery . . . . . 6
6.2. LDAP Server Discovery . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Some applications need to discover the names of servers for a specific resource. Some common methods for server discovery are insecure, e.g., queries for DNS [RFC1035] SRV resource records [RFC2782] without using DNSSEC [RFC4033], and are subject to attacks whereby a client can be re-directed to incorrect and possibly malicious servers. A client may even be re-directed to a server that has credentials for itself and thus may authenticate itself to the client, and yet it could be incorrect or malicious (because it has been compromised, say).
某些应用程序需要发现特定资源的服务器名称。一些常见的服务器发现方法是不安全的，例如，在不使用DNSSEC[RFC4033]的情况下查询DNS[RFC1035]SRV资源记录[RFC2782]，并且会受到攻击，从而使客户端可以重新定向到不正确且可能恶意的服务器。客户机甚至可能被重新定向到具有其自身凭据的服务器，从而可能向客户机验证其自身，但它可能是不正确的或恶意的（例如，因为它已被破坏）。
Domain-based names allow for GSS-API [RFC2743] initiator applications (clients) to authorize acceptor principals (servers) to serve the resource for which the client used insecure server discovery without either securing the server discovery method or requiring an additional protocol for server authorization. That is, either a discovered server has credentials for authenticating the domain-based service names that it is intended to respond to, or it does not. Availability of valid credentials for authenticating domain-based names embodies the authorization of a given server to a domain-wide service.
基于域的名称允许GSS-API[RFC2743]启动器应用程序（客户端）授权接受主体（服务器）为客户端使用不安全服务器发现的资源提供服务，而无需保护服务器发现方法或要求额外的服务器授权协议。也就是说，发现的服务器具有用于验证其打算响应的基于域的服务名称的凭据，或者没有。用于验证基于域的名称的有效凭据的可用性体现了给定服务器对域范围服务的授权。
A domain-based name consists of three required elements:
基于域名的名称由三个必需元素组成：
o a service name
o 服务名称
o a domain name
o 域名
o a hostname
o 主机名
The domain name and the hostname should be Domain Name System (DNS) names, though domain-based names could be used in non-DNS environments. Because of the use of DNS names we must also provide for internationalization of the GSS-API.
域名和主机名应该是域名系统（DNS）名称，但基于域名的名称可以在非DNS环境中使用。由于使用DNS名称，我们还必须提供GSS-API的国际化。
Note that domain-based naming isn't new. According to a report to the KITTEN WG mailing list, there exists at least one implementation of LDAP which uses domain-based service naming, and the DIGEST-MD5 HTTP / Simple Authentication and Security Layer (SASL) mechanism [RFC2831] describes a similar notion. (See section 2.1.2 of [RFC2831] for a description of the "serv-name" field of the digest-response.)
请注意，基于域的命名并不是新的。根据KITTEN WG邮件列表的一份报告，至少存在一种使用基于域的服务命名的LDAP实现，DIGEST-MD5 HTTP/Simple Authentication and Security Layer（SASL）机制[RFC2831]描述了类似的概念。（有关摘要响应的“服务名称”字段的说明，请参见[RFC2831]的第2.1.2节。）
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The IANA has recorded the following new name-type OID in IANA's "SMI Security for Name System Designators Codes (nametypes)" registry:
IANA已在IANA的“名称系统标识符代码（名称类型）SMI安全性”注册表中记录了以下新名称类型OID：
5 gss-domain-based-services [RFC5178]
5 gss基于域的服务[RFC5178]
This document creates a new GSS-API name-type, with a symbolic name of "GSS_C_NT_DOMAINBASED_SERVICE" and this OID:
本文档创建了一个新的GSS-API名称类型，其符号名称为“GSS_C_NT_DOMAINBASED_SERVICE”，此OID：
{iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss-
domain-based(5)}
{iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss-
domain-based(5)}
There is a single name syntax for domain-based names. It is expressed using the ABNF [RFC5234].
基于域的名称有一个单一的名称语法。它使用ABNF[RFC5234]表示。
The syntax is:
语法是：
domain-based-name = service "@" domain "@" hostname
domain-based-name = service "@" domain "@" hostname
hostname = domain
hostname = domain
domain = sub-domain 1*("." sub-domain)
域=子域1*（“”子域）
sub-domain = Let-dig [Ldh-str]
子域=Let dig[Ldh str]
Let-dig = ALPHA / DIGIT
Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
Where <service> is defined in Section 4.1 of [RFC2743]. Other rules not defined above are defined in Appendix B.1 of [RFC5234].
其中，<服务>在[RFC2743]第4.1节中定义。[RFC5234]附录B.1中定义了上述未定义的其他规则。
These examples are not normative:
这些例子并不规范：
o ldap@somecompany.example@ds1.somecompany.example
o ldap@somecompany.example@ds1.somecompany.example
o nfs@somecompany.example@nfsroot1.somecompany.example
o nfs@somecompany.example@nfsroot1.somecompany.example
The .example top-level domain is used here in accordance with [RFC2606].
此处根据[RFC2606]使用示例顶级域。
We introduce new versions of GSS_Import_name() and GSS_Display_name() to better support Unicode. Additionally, we provide for the use of ASCII Compatible Encoding (ACE)-encoded DNS in the non-internationalized interfaces [RFC3490].
我们引入了GSS_Import_name（）和GSS_Display_name（）的新版本，以更好地支持Unicode。此外，我们还规定在非国际化接口[RFC3490]中使用ASCII兼容编码（ACE）编码的DNS。
When the input_name_type parameter is the GSS_C_NT_DOMAINBASED_SERVICE OID, then GSS_Import_name() implementations and GSS-API mechanisms MUST accept ACE-encoded internationalized domain names in the hostname and domain name slots of the given domain-based name string.
当输入_name_type参数是GSS_C_NT_DOMAINBASED_服务OID时，GSS_Import_name（）实现和GSS-API机制必须在给定基于域名字符串的主机名和域名槽中接受ACE编码的国际化域名。
Support for non-ASCII internationalized domain names SHOULD also be provided through a new function, GSS_Import_name_utf8(), that operates exactly like GSS_Import_name() (with the same input and output parameters and behavior), except that it MUST accept internationalized domain names both as UTF-8 strings and as ACE-encoded strings via its input_name_string argument.
还应通过一个新函数GSS_Import_name_utf8（）提供对非ASCII国际化域名的支持，该函数的操作与GSS_Import_name（）完全相同（具有相同的输入和输出参数和行为），但它必须接受国际化域名作为UTF-8字符串，并通过其输入\名称\字符串参数作为ACE编码字符串。
Implementations of GSS_Display_name() MUST only output US-ASCII or ACE-encoded internationalized domain names in the hostname and domain name slots of domain-based names (or mechanism names (MN) that conform to the mechanism's form for domain-based names).
GSS_Display_name（）的实现只能在基于域名（或符合基于域名的机制形式的机制名（MN））的主机名和域名槽中输出US-ASCII或ACE编码的国际化域名。
Support for non-ASCII internationalized domain names SHOULD also be provided through a new function, GSS_Display_name_utf8(), that operates exactly like GSS_Display_name() (with the same input and output parameters and behavior), except that it outputs UTF-8 strings via its name_string output argument. GSS_Display_name_utf8() MUST NOT output ACE-encoded internationalized domain names.
还应通过一个新函数GSS_Display_name_utf8（）提供对非ASCII国际化域名的支持，该函数的操作与GSS_Display_name（）完全相同（具有相同的输入和输出参数和行为），只是它通过其name_字符串输出参数输出UTF-8字符串。GSS_Display_name_utf8（）不能输出ACE编码的国际化域名。
The following examples are not normative. They describe how the authors envision two applications' use of domain-based names.
以下示例不具有规范性。他们描述了作者对两个应用程序使用基于域名的设想。
Work is ongoing to provide a method for constructing domain-wide NFSv4 [RFC3530] filesystem namespaces where there is a single "root" with one or more servers (replicas) and multiple filesystems glued into the namespace through use of "referrals". Clients could then construct a "global" namespace through use of the DNS domain hierarchy.
目前正在进行的工作是提供一种方法，用于构造域范围的NFSv4[RFC3530]文件系统名称空间，其中有一个“根”，一个或多个服务器（副本）和多个文件系统通过使用“引用”粘在名称空间中。然后，客户端可以通过使用DNS域层次结构来构造“全局”命名空间。
Here, clients would always know, from context, when they need to find the root servers for a given DNS domain. Root server discovery would be performed using DNS SRV RR lookups, without using DNSSEC where DNSSEC has not been deployed.
在这里，客户端总是可以从上下文中知道何时需要查找给定DNS域的根服务器。根服务器发现将使用DNS SRV RR查找执行，而不使用尚未部署DNSSEC的DNSSEC。
When using RPCSEC_GSS [RFC2203] for security, NFSv4 clients would use domain-based names to ensure that the servers named in the SRV RRs are in fact authorized to be the NFSv4 root servers for the target domain.
当使用RPCSEC_GSS[RFC2203]进行安全保护时，NFSv4客户端将使用基于域的名称，以确保SRV RRs中命名的服务器实际上已被授权为目标域的NFSv4根服务器。
LDAP clients using the GSS-API through SASL would also benefit from use of domain-based names to protect server discovery through insecure DNS SRV RR lookups, much as described above.
通过SASL使用GSS-API的LDAP客户端也将受益于使用基于域的名称通过不安全的DNS SRV RR查找来保护服务器发现，如上所述。
Unlike NFSv4 clients, not all LDAP clients always know from context when they should use domain-based names. That's because existing clients may use host-based naming to authenticate servers discovered through SRV RR lookups. Changing such clients to use domain-based naming when domain-based acceptor credentials have not been deployed to LDAP servers, or when LDAP servers have not been modified to allow use of domain-based naming, would break interoperability. That is, there is a legacy server interoperability issue here. Therefore, LDAP clients may require additional configuration at deployment time to enable (or disable) use of domain-based naming.
与NFSv4客户机不同，并非所有LDAP客户机都能从上下文中知道何时应该使用基于域的名称。这是因为现有客户端可能使用基于主机的命名来验证通过SRV RR查找发现的服务器。当基于域的接受者凭据尚未部署到LDAP服务器时，或者当LDAP服务器未被修改以允许使用基于域的命名时，将此类客户端更改为使用基于域的命名将破坏互操作性。也就是说，这里存在一个遗留服务器互操作性问题。因此，LDAP客户端可能需要在部署时进行额外配置，以启用（或禁用）基于域的命名。
Note: whether SASL [RFC4422] or its GSS-API bridges [RFC4752] [GS2] require updates in order allow use of domain-based names is not relevant to the theory of how domain-based naming would protect LDAP clients' server discovery.
注意：SASL[RFC4422]或其GSS-API桥接器[RFC4752][GS2]是否需要更新以允许使用基于域的名称与基于域的命名如何保护LDAP客户端的服务器发现的理论无关。
Use of GSS-API domain-based names may not be negotiable by some GSS-API mechanisms, and some acceptors may not support GSS-API domain-based names. In such cases, the initiators are left to fall back on the use of host-based names, so the initiators MUST also verify that the acceptor's host-based name is authorized to provide the given service for the domain that the initiator had wanted.
某些GSS-API机制可能无法协商使用基于GSS-API的域名，并且某些接受者可能不支持基于GSS-API的域名。在这种情况下，发起者只能使用基于主机的名称，因此发起者还必须验证接受者基于主机的名称是否有权为发起者想要的域提供给定服务。
The above security consideration also applies to all GSS-API initiators who lack support for domain-based service names.
上述安全考虑也适用于所有缺乏对基于域的服务名称支持的GSS-API启动器。
Note that, as with all service names, the mere existence of a domain-based service name conveys meaningful information that may be used by initiators for making authorization decisions; therefore, administrators of distributed authentication services should be aware of the significance of the service names for which they create acceptor credentials.
请注意，与所有服务名称一样，仅仅存在一个基于域的服务名称就传递了有意义的信息，发起者可以使用这些信息来做出授权决策；因此，分布式身份验证服务的管理员应该知道为其创建接受方凭据的服务名称的重要性。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[RFC2831]Leach，P.和C.Newman，“使用摘要认证作为SASL机制”，RFC 28312000年5月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[GS2] Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", Work in Progress, October 2007.
[GS2]Josefsson，S.，“在SASL中使用GSS-API机制：GS2机制家族”，正在进行的工作，2007年10月。
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[RFC2203]Eisler，M.，Chiu，A.，和L.Ling，“RPCSEC_GSS协议规范”，RFC 2203，1997年9月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]Eastlake，D.和A.Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530]Shepler，S.，Callaghan，B.，Robinson，D.，Thurlow，R.，Beame，C.，Eisler，M.，和D.Noveck，“网络文件系统（NFS）版本4协议”，RFC 3530，2003年4月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, November 2006.
[RFC4752]Melnikov，A.，“Kerberos V5（“GSSAPI”）简单身份验证和安全层（SASL）机制”，RFC 4752，2006年11月。
Authors' Addresses
作者地址
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct. Austin, TX 78727 US
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct。德克萨斯州奥斯汀78727美国
EMail: Nicolas.Williams@sun.com
EMail: Nicolas.Williams@sun.com
Alexey Melnikov Isode Ltd. 5 Castle Business Village, 36 Station Road Hampton, Middlesex TW12 2BX United Kingdom
Alexey Melnikov Isode Ltd.英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号TW12 2BX
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.