UPnP 设备规范（ UDA 1.0）
前言
本文档合并了几个单独的文档，这些文档构成了 UPnP 设备体系结构 1.0 版的整体，包括以前针对 AutoIP，SSDP，HTTPU/MU，FXPP 和 GENA 的单独规范， 以及《 UPnP Vendor Implementation Guide》中的说明。 它不引入任何新的技术要求，而仅构成编辑上的说明。
简介
What is UPnP™1 Technology?
UPnP™技术定义了一种架构，该架构用于构建各种形式的智能设备，无线设备和 PC 设备普遍对v等网络连接。 它旨在为家庭，小型企业，公共场所或连接到 Internet 的临时或非托管网络带来易于使用，灵活，基于标准的连接。 UPnP技术提供了一种分布式，开放的网络体系结构，该体系结构利用 TCP/IP 和 Web 技术来实现无缝的邻近网络， 以及在联网设备之间进行控制和数据传输。
UPnP Device Architecture（UDA）不仅仅是即插即用外围设备模型的简单扩展。 它的设计旨在使能众多厂商支持零配置，“无感” 联网以及服务的自动发现。 这意味着设备可以动态加入网络，获取IP地址，申明其功能以及了发现了解其他设备的存在和功能。 最终，设备也可以自动顺畅地离开网络，而不会留下任何不必要的状态。
UPnP 体系结构利用了普遍的 Internet 协议技术，例如 IP，TCP，UDP，HTTP 和 XML。 像 Internet 合约基于声明性的有线协议一样，UPNP 以 XML 表示并通过 HTTP 协议进行通信。 使用互联网协议是 UDA 的一个不错的选择，因为它具有跨不同物理媒体的可靠能力， 可以实现现实世界中的多供应商互操作，并且可以与 Internet 以及许多家庭和办公室内部网实现协同作用。 UPnP体系结构已明确设计为适应这些环境。 此外，作为一个桥接万物的协议， UDA 还解决了设备因为成本，技术或传统限制设备无法获取 IP 时的场景
为什么 UPnP 技术是 “普遍性” 的？ 没有设备驱动程序， 使用通用协议。 UPnP 网络是独立的（媒体）。 UPnP 设备可以使用任何编程语言在任何操作系统上实现。 UDA 在程序/接口设计上没有设置任何限制。 操作系统供应商可以为其客户的需求实现合适的 API。
UPnP™ 论坛组
UPnP 论坛则是一项行业计划，旨在使来自许多不同的供应商的独立设备和 PC 之间实现轻松而强大的连接。 UPnP 论坛寻求开发一套用于描述设备协议的标准。基于 XML 的设备的标准架构用于在可扩展网络环境中，实现设备到设备互相操作。
The UPnP Implementers Corporation（UIC）由UPnP 论坛中的各个行业成员公司组成， 采用统一的设备互连技术标准以对这些设备进行测试和认证。 UIC 开发和管理测试和认证过程，管理 UPnP 徽标的分发，并向 UIC 成员和其他有关 UPnP 设备认证的相关方提供相关信息。 UPnP 设备认证对拥有 UPNP 设备和已支付 UIC 会费的 UPnP 论坛和 UIC 的成员开放。 有关更多信息，请参见 http://www.upnp-ic.org。
UPnP论坛已经建立了专门领域知识领域的工作委员会。 这些工作委员会负责创建建议的设备标准，构建示例实现以及构建适当的测试套件。 本文档指出了UPnP论坛工作委员会职权范围内的特定技术决策。
UPnP 供应商可以建立具有互操作性以及共享知识产权和徽标计划的好处的合规设备。 除了徽标程序之外，供应商还可以构建遵循本文定义的 UPnP 设备架构的设备，而无需使用正式的标准程序。 如果供应商制造非标准设备，则他们将决定由UPnP论坛工作委员会决定的技术决定（没看懂，原文贴后面了）。If vendors build non-standard devices, they determine technical decisions that would otherwise be determined by a UPnP Forum working committee.
关于本文档
本文包含的 UDA（以前称为DCP框架）定义了控制器或控制点与设备之间进行通信的协议。 为了进行发现，描述，控制，事件和演示，UPnP设备体系结构使用以下协议栈（）：
在最上层，消息在逻辑上仅包含有关其设备的 UPnP 供应商特定信息。 在第二层， UPnP 论坛工作委员会定义补充供应商的内容的信息。 来自以上各层的消息以特定于 UPnP 的协议托管， 例如本文档中定义的简单服务发现协议（SSDP）和通用事件通知体系结构（GENA），以及所引用的其他协议。 以上消息是通过 HTTP（通过 UDP 的多播或单播来传输）或通过在 TCP 上的 HTTP 传递的。 最终，以上所有消息均通过 IP 网络传递。 本文档的其余部分详细描述了每个协议层的内容和格式。 作为参考，以上[方括号]中的颜色表示在本文档中哪个协议定义了特定的消息组件。
UDA 定义了两种设备的一般分类：受控设备（或简称为“设备”）和控制点。 受控设备充当服务器的角色，响应来自控制点的请求。 控制点和受控设备都可以在包括个人计算机和嵌入式系统在内的各种平台上实现。 被控设备，控制点两者可以在同一网络终端上同时运行。
UPnP 网络的基础是 IP 寻址（IP addressing）。 每个设备必须具有动态主机配置协议（DHCP）客户端，并在设备首次连接到网络时搜索 DHCP 服务器。 如果 DHCP 服务器可用，则该设备必须使用分配给它的IP地址。 如果没有可用的DHCP服务器，即网络不受管理，则设备必须使用自动 IP ( AutoIP )来获取地址。 简而言之，“自动IP” 定义了设备如何从一组保留的地址中智能地选择 IP 地址， 以及如何在托管网络和非托管网络之间轻松移动。 如果在进行 DHCP 事务处理期间，设备（例如，通过DNS服务器或DNS转发）获得了域名， 则设备应在后续的网络操作中使用该名称； 否则，设备应使用其IP地址。
给定一个IP地址，UPnP 网络中的步骤 1 是发现（ discovery ）。 将设备添加到网络后，UPnP 发现协议允许该设备将其服务通告给网络上的控制点。 同样，当将控制点添加到网络时，UPnP 发现协议允许该控制点搜索网络上感兴趣的设备。 两种情况下的基本交换是发现消息，该发现消息包含关于设备或其服务之一的一些基本细节， 例如，设备的类型，标识符以及指向更详细信息的指针（URL）。 下面有关发现的部分说明了设备如何播发，控制点搜索方式以及发现消息格式的详细信息。
UPnP 组网中的第 2 步为描述( description )。 控制点发现设备后，控制点对设备的了解仍然很少。 为了使控制点了解有关设备及其功能的更多信息，或与设备进行交互， 控制点必须从设备在发现消息中提供的 URL 检索设备的描述。 设备可能包含其他逻辑设备以及功能单元或服务, 并且包括特定于供应商的制造商信息。例如型号名称和编号，序列号，制造商名称，特定于供应商的网站的 URL 等 （设备的 UPnP 描述以 XML 表示）。 该描述还包括任何嵌入式列表。设备或服务，以及用于控制，事件和演示的 URL。 对于每个服务，描述都包括服务响应的命令或动作的列表，以及每个动作的参数或自变量。 服务描述还包括（状态）变量列表；这些变量在运行时对服务状态进行建模，并根据其数据类型，范围和事件特征进行描述。 下文“描述”部分说明了如何描述设备以及控制点如何检索这些描述。
UPnP网络中的第三步 3 是控制。 在控制点检索到设备的描述之后，控制点可以将操作发送到设备的服务。 为此，控制点将适当的控制消息发送到服务的控制 URL（在设备描述中提供）。 控制消息还使用简单对象访问协议（SOAP）用 XML 表示。 像函数调用一样，响应于控制消息，服务将返回任何特定于操作的值。 动作的效果（如果有的话）是通过描述服务运行时状态的变量的变化来建模的。 下面有控制的部分的操作说明，状态变量和控制消息格式的描述。
UPnP 网络中的步骤 4 正在事件（eventing）。 服务的 UPnP 描述包括服务响应的操作列表和在运行时对服务状态建模的变量列表。 这些变量更改时，服务将发布更新，并且控制点可以订阅以接收此信息。 该服务通过发送事件消息( eventing msg )来发布更新。 事件消息包含多个状态变量的名称以及这些变量的当前值。这些消息也以XML表示。 当控制点首次订阅时，会发送一个特殊的初始事件消息。 该事件消息包含所有事件变量的名称和值，并允许订户初始化其服务状态模型。 为了支持具有多个控制点的方案，事件设计为使所有控制点均等地了解任何操作的效果。 因此，并且无论状态变量为何更改，被控点因向所有订户发送所有事件消息。 订阅者会受到所有已经变更的消息。下面有事件的部分说明了订阅和事件消息的格式。
UPnP 网络中的第 5 步是展示（presentation）。 如果设备具有用于展示的 URL，则控制点可以从该 URL 检索页面， 将该页面加载到浏览器中，并根据页面的功能，允许用户控制设备和/或查看设备状态。 完成这些操作的程度取决于演示页面和设备的特定功能。 下面有 “演示” 的部分说明了检索演示页面的协议。
Audience
本文档的读者包括 UPnP 设备供应商（vendor），UPnP 论坛工作委员会的成员以及需要了解 UPnP 协议技术细节的其他任何人。
本文档假设读者熟悉 HTTP，TCP，UDP，IP 协议家族； 本文档未尝试解释它们。 本文档还假定大多数读者将不熟悉 XML，尽管它不是 XML 教程，但鉴于 XML 在 UPnP 设备体系结构中的中心地位，将详细解决与 XML 有关的问题。 本文档不假定读者对各种编程或脚本语言的理解。
Required vs. recommended
在本文档中，特性被描述成 Required（要求）, Recommended（推荐）, or Optional（可选） 三个等级。
Required (or Must or Shall)
必须实现这些基本功能，以符合 UPnP 设备架构（UDA）。 短语“不应该（shall not）”和“不得( must not )”表示禁止的行为，如果执行，则表示该实现不符合要求。
Recommended (or Should).
这些功能增加了 UPnP 设备体系结构支持的功能，应予以实现。 推荐的功能通常利用 UPnP 设备架构的功能，而不会造成较大的成本增加。 请注意，对于合规性测试，如果实施了推荐功能，则它必须满足指定要求才能符合这些准则。 某些推荐功能可能会在将来成为要求。 短语“不应”表示允许但不建议的行为
Optional (or May).
UPnP 设备体系结构既不需要也不推荐这些功能，但是如果实现了该功能，则必须满足指定的要求才能符合这些准则。 这些功能将来不太可能成为必需。
Acronyms
ARP Address Resolution Protocol
CP Control Point
DCP Device Control Protocol
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
GENA General Event Notification Architecture
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
HTTPU HTTP (Unicast over UDP)
HTTPMU HTTP (Multicast over UDP)
SOAP Simple Object Access Protocol
SSDP Simple Service Discovery Protocol
UDA UPnP™ Device Architecture
UPC Universal Product Code
URI Uniform Resource Identifier
URL Uniform Resource Locator<
URN Uniform Resource N me
UUID Universally Unique Identifier
XML Extensible Markup Language
References and resources
RFC 2616 HTTP: Hypertext Transfer Protocol 1.1. http://www.ietf.org/rfc/rfc2616.txt
RFC 2279 UTF-8, a transformation format of ISO 10646 (character encoding). http://www.ietf.org/rfc/rfc2279.txt
XML Extensible Markup Language. W3C recommendation. http://www.w3.org/TR/2000/REC-xml-20001006.
本文档的每个部分都包含有关特定主题资源的其他信息。
0. Addressing
寻址是 UPnP™ 网络的第 0 步。 通过寻址，设备可以获得网络地址。 寻址成功才能使控制点在步骤 1 （discovery）在找到有感兴趣的设备， 步骤 2（description）在控制点了解设备功能， 步骤 3（control）在控制点向设备发送命令， 步骤4（eventing）控制点监听设备状态变化， 步骤5（presentation）控制点显示设备用户界面。
UPnP 网络的基础是 IP 寻址。 每个本身不实现 DHCP 服务器的 UPnP 设备都必须具有动态主机配置协议（DHCP）客户端， 并在设备首次连接到网络时搜索 DHCP 服务器（如果设备本身实现DHCP服务器，则它可以分配本身就是它所控制的池中的地址）。 如果 DHCP 服务器可用，即管理网络，则该设备必须使用分配给它的 IP 地址。 如果没有DHCP服务器可用，即网络不受管理； 设备必须使用自动 IP 寻址（Auto-IP）来获取地址。
此处定义的自动 IP 是定义设备（a）确定 DHCP 是否不可用，以及（b）从一组本地链路 IP 地址中智能地选择 IP 地址。 这种地址分配方法使设备可以轻松地在托管和非托管网络之间移动。
本节定义了自动 IP 的操作。 本节中描述的操作在下面列出的参考文档中进行了详细说明。 如果本文档和参考文档之间存在冲突，则始终以参考文档为准。
0.1 Addressing: Determining whether to use Auto-IP
支持自动 IP 并的设备被配置为首先通通过 DHCP 发送 DHCPDISCOVER 消息请求 IP 地址开始。 此 DHCP 客户端应侦听 DHCPOFFER 的时间量取决于厂商自己的实现。 如果在此期间收到 DHCPOFFER，则设备必须进行继续动态地址分配过程。 如果没有收到有效的 DHCPOFFER，则设备开始自动配置 IP 地址流程。
0.2 Addressing: Choosing an address
为了使用自动 IP 自动配置 IP 地址，设备需要实现有关的算法来选择 169.254.0.0/16 范围内的地址。 此范围中的前 256 个地址和后 256 个地址被保留，不能使用。
经过算法选择的地址必须测试所选的地址在局域网中的唯一性，以确定该地址是否已被使用。 如果该地址正被另一个设备使用，则必须选择并测试另一个地址，直到达到厂商自己定义的最大重试次数。 当多个设备试图分配地址时，应将地址选择随机化以避免冲突。 建议设备使用伪随机算法（分布在从 169.254.1.0 到 169.254.254.255 的整个地址范围内）选择地址， 以最大程度地减少同时加入网络的设备选择相同地址的可能性，并在检测到冲突时按相同顺序选择备用地址。 可以使用设备的以太网硬件 MAC 地址来作为伪随即算法的种子。
0.3 Addressing: Testing the address
要测试所选的地址，设备必须使用地址解析协议（ARP）探针。 ARP 探针是一个 ARP 请求，其中设备 IP 地址用作发件人的 IP 地址，而发件人的 MAC 地址设置为 0s。 ( hwsrc == 自己 MAC 地址， psrc == 0.0.0.0, pdst == 探测的 IP 地址，也就是自己随机选择出来的 IP 地址 ) 然后，设备将侦听 ARP 探针或针对同一 IP 地址的其他 ARP 探针的响应。 如果看有一个使用设备当前选择的 IP 的 ARP 数据包，则设备必须考虑使用其他地址。 可以重复进行 ARP 探测，以确保该地址尚未使用。 建议每两秒钟发送四次探测。
成功配置链接本地地址后，设备应发送两个自己的 ARP 报文，间隔 2 秒，这次将配置的 IP 填充为了发送方 IP 地址。 这些 ARP 的目的是确保网络上的其他主机没有因为以前可能使用相同地址而遗留的陈旧 ARP 缓存。
拥有非易失性存储的设备可以记录其选择的 IP 地址， 并在下一次引导时将其用作探测时的第一个候选地址，以提高地址的稳定性并减少解决地址冲突的需要。
当设备正在发送 ARP 探针并侦听答复时，地址冲突检测不应局限于地址测试阶段。 地址冲突检测是一个持续不断的过程，只要设备使用链接本地地址，该过程就一直有效。 在任何时候，如果设备接收到一个 ARP 数据包，该 ARP 数据包具有自己的 IP 地址作为发送方 IP 地址， 但发送方硬件地址与自己的硬件地址不匹配，则该设备应将此视为地址冲突并应做出响应 如以下（a）或（b）中所述：
a: 立即配置新的本地链接IP地址，或者
b: 如果设备当前具有活动的 TCP 连接或其他原因希望保留相同的IP地址， 并且最近（例如，在过去的十秒钟内）没有看到任何其他冲突的 ARP 数据包， 则它可以选择尝试保护其地址一次 ，方法是记录收到冲突的 ARP 数据包的时间， 然后广播一个 gratuitous ARP，并为将自己的 IP 和硬件地址作为 ARP 的源地址。 但是，如果在此后的短时间内（例如十秒钟之内）收到另一个冲突的ARP数据包， 则设备应立即如上所述配置新的自动IP地址。
设备应按照上述（a）或（b）中的说明响应冲突的 ARP 数据包； 它不应忽略冲突的 ARP 数据包。 要从一个 IP 地址切换到新的 IP 地址， 设备应尽可能取消在前一个地址上发布的所有未完成的广告， 并且必须在新地址上发布新的广播。 发现部分介绍了广播及其取消。
成功配置自动 IP 地址后， 应使用链接级广播而不是链接级单播发送包含自动 IP 源地址的所有后续 ARP 数据包（答复和请求）， 以便及时发现重复地址。 作为替代方案，无法发送广播 ARP 答复的设备应发送单播 ARP 答复， 但随后忽略遵循 RFC 826 中有关记录来自已接收ARP请求的发件人信息的指令。 这意味着，在未能记录发送方信息的情况下，该设备很可能稍后会发送自己的广播ARP请求， 从而使使用相同IP地址的另一设备能够检测到冲突并对其进行响应。
源或目标地址在 169.254.0.0/16 范围内的 IP 数据包不得发送到任何路由器进行转发。 具有多播目标地址和自动IP源地址的IP数据报不应从本地链路转发出去。 设备和控制点可以假定所有 169.254.0.0/16 目标地址都在链接上并且可以直接访问。 169.254.0.0/16 地址范围一定不能划分子网。
0.4 Addressing: Periodic checking for dynamic address availability
自动配置 IP 地址的设备必须定期检查 DHCP 服务器的存在。 这是通过发送 DHCPDISCOVER 消息来完成的。 进行此检查的频率取决于实现方式，但是每 5 分钟检查一次将在所需的网络带宽和连接性维护之间保持平衡。 如果收到DHCPOFFER，则设备必须继续进行动态地址分配。 DHCP分配的地址到位后，设备可以释放自动配置的地址， 但也可以选择在一段时间内（或无限期地）维护该地址以保持连接性。
要从一个 IP 地址切换到新的 IP 地址，设备应尽可能取消在前一个地址上发布的所有未完成的广告， 并且必须在该新地址上发布新的广告。 发现部分介绍了广告及其取消。
0.5 Addressing: Device naming and DNS interaction
设备具有网络的有效 IP 地址后，就可以通过该地址在该网络上对其进行定位和引用。 最终用户可能需要定位和识别设备。 在这些情况下，设备的友好名称比 IP 地址更容易被人使用。 如果 UPnP 设备选择向 DHCP 服务器提供主机名并向 DNS 服务器注册，则该设备应确保所请求的主机名是唯一的， 或者应为用户提供一种更改所请求的主机名的方法。 UPnP设备通常不提供主机名，而是使用文字（数字）IP地址提供URL。
而且，名称比 IP 地址更加静态。 当设备的 IP 地址更改时，按名称引用设备的客户端不需要任何修改。 设备的 DNS 名称到其 IP 地址的映射可以手动输入，也可以根据 RFC 2136 动态输入到 DNS 数据库中。 尽管支持动态 DNS 更新的设备可以直接在 DNS 中注册其 DNS 记录， 但也可以配置 DHCP 服务器进行注册 DNS 记录代表这些DHCP客户端。
0.6 Addressing: Name to IP address resolution
如果一台设备需要通过 DNS 联系另外一台设备，那么我们先要从 DNS 的名字中取得设备的 IP 地址。 设备根据 RFC1034 和 1035 向预配置的 DNS 服务器提交 DNS 查询， 并从 DNS 服务器接收包含目标设备 IP 地址的响应。 可以使用 DNS 服务器列表对设备进行静态预配置。 或者，可以通过DHCP，或在通过DHCPINFORM消息分配地址之后，为设备配置 DNS 服务器列表。
0.7 Addressing references
RFC1034
Domain Names - Concepts and Facilities. http://www.ietf.org/rfc/rfc1034.txt
RFC1035
Domain Names - Implementation and Specification. http://www.ietf.org/rfc/rfc1035.txt
RFC 2131
Dynamic Host Configuration Protocol. http://www.ietf.org/rfc/rfc2131.txt
RFC 2136
Dynamic Updates in the Domain Name System. http://www.ietf.org/rfc/rfc2136.txt
1. Discovery
发现是 UPnP™ 网络中的第一步。 发现是在寻址（第 0 步）之后获得的，其中设备获得了网络地址。 通过发现，控制点可以找到有趣的设备。 发现可以进行描述（第 2 步），其中控制点了解设备功能，进行控制（第 3 步），控制点向设备发送命令， 进行事件（第 4 步），控制点侦听设备的状态变化， 和演示（第 5 步），其中控制点显示设备的用户界面。
发现是 UPnP 网络的第一步。将设备添加到网络后，UPnP 发现协议允许该设备将其服务通告给网络上的控制点。 同样，当将控制点添加到网络时，UPnP 发现协议允许该控制点搜索网络上感兴趣的设备。 两种情况下的基本交换是发现消息，该消息包含有关设备或其服务之一的一些基本细节， 例如，设备的类型，设备的唯一的标识符，及指向更详细信息的指针。
将新设备添加到网络后，它会用多播的方式广播一些消息，这些消息会宣传其自身，其嵌入式设备及其服务。 任何感兴趣的控制点都可以侦听标准多播地址，以获取有关新功能可用的通知。
同样，将新的控制点添加到网络后，它会用多播的方式广播一条搜索消息，搜索有趣的设备，服务或两者。 所有设备必须侦听这些消息的标准多播地址，并且如果它们的任何嵌入式设备或服务符合发现消息中的搜索条件， 则必须做出响应。
重申一下，控制点可以获悉感兴趣的设备，因为该设备发送了广告宣传自己的消息， 或者因为该设备响应了搜索消息。 在任何一种情况下，如果控制点对设备感兴趣并希望了解更多信息， 则控制点将使用发现消息中的信息来发送描述查询消息。 “描述”部分详细说明了描述消息。
当设备从网络中删除时，如果可能的话，它应该多播多条发现消息，以撤销其先前的公告， 从而有效地声明其嵌入式设备和服务将不再可用。 更改设备的IP地址后，它应也应该撤消所有之前的公告，并使用新的IP地址发布广告。
对于具有多个网络接口的设备和控制点， 应该在所有启用 UPnP 网络的网络接口上发送 UPnP 通告和搜索。 每个广播消息或搜索消息都必须在 LOCATION 标头中指定一个可在该接口上访问的地址
为了避免网络拥塞，每个多播消息的每个 IP 数据包的生存时间（TTL）应该默认为4，并且应该是可配置的。 当 TTL 大于 1 时，多播消息可能会遍历多个路由器。 因此，使用非 AutoIP 地址的控制点和设备必须发送 IGMP Join 消息， 以便路由器将多播消息转发给它们 （使用 Auto-IP 地址时，这是不必要的，因为具有 Auto-IP 地址的数据包将不会被路由器转发）。
发现在不同版本的 UPnP 网络的设备和控制点的互操作性中起着重要作用。 UPnP 设备体系结构（在此定义）同时具有主要版本和次要版本，通常写为 major.minor， 其中，主要和次要均为整数（例如，版本2.10 比版本2.2更新）。 次要版本的提升必须是同一主版本的较早次要版本的兼容超集。 主要版本中的进步不一定是早期版本的超集，也不保证其向后兼容。 版本信息在发现和描述消息中传达。 在前一种情况下，每个发现消息都包括设备支持的 UPnP 网络版本（在 SERVER 标头中）； 相关的发现消息中还包含支持的设备和服务类型的版本。 作为备份，后者也包含相同的信息。 本节将说明发现消息中版本信息的格式以及对发现消息的特定要求，以保持与次要版本的改进的兼容性。
本节的其余部分详细解释 UPnP 发现协议（SSDP）， 列举设备如何通告和撤消其通告以及控制点搜索和设备如何响应。
1.1 Discovery: Advertisement
将设备添加到网络后，该设备会将其服务通告给控制点。 它通过将发现消息多播到标准地址和端口（239.255.255.250:1900）来实现此目的。 控制点侦听此端口以检测网络上何时有新功能可用。 为了公布其功能的全部范围，设备会多播设备自身的服务相对应的发现消息。 每个消息都包含特定于设备（或服务）的信息和有关其封闭设备的信息。 消息应应该包含该消息的过期信息； 如果设备仍然可用，则应重新发送广告。 如果设备不可用，则设备应明确取消其广告，但是如果设备无法执行此操作，则广告将自行失效。
1.1.1 Discovery: Advertisement protocols and standards
为了发送（和接收）广播，设备（和控制点）需要遵从以下提到的 UPNP 的子集。 （UPnP 的完整协议栈在文章开头有提及）
在最上层，发现消息包含供应商的信息，例如，用于设备描述和设备标识符的URL。 从协议栈向下看，供应商内容将由 UPnP 论坛工作委员会提供的信息（例如设备类型）进行补充。 来自以上各层的消息以本文档中定义的 UPnP 的协议承载。 同样的，上述消息是通过使用 HTTPMU（ HTTP 多播变体） 的头部或者方法进行封装传递。 HTTP 消息是通过 UDP over IP 传递的。 作为参考，上方[方括号]中的颜色表示哪种协议定义了下面列出的发现消息中的特定标头和值。
1.1.2 Discovery: Advertisement: Device available -- NOTIFY with ssdp:alive
将设备添加到网络后，它会多播发现消息，以通告其根设备，任何嵌入式设备和所有服务。 每个发现消息包含四个主要组件：
在 NT（通知类型）标头中发送的潜在搜索目标（例如设备类型），
在 USN（唯一服务名称）标头中发送该设备综合服务的组合标识符，
在 LOCATION 标头中发送的有关该设备（或在服务中为封闭设备）的更多信息的 URL，
在 CACHE-CONTROL 标头中发送的广播消息的有效期限。
为了公布其功能，设备会广播多次自身服务的多条发现消息。 具体来说，根设备必须多播：
更设备（服务）的发现消息。
两条为两个嵌入设备发送的搜索消息。
设备各自的服务。
** 请注意，USN 标头的前缀（在双冒号之前）必须与设备描述中的 UDN 元素的值匹配。 (“描述”部分说明了UDN元素。)
** 请注意，此NT标头的值必须与设备描述中的UDN元素的值匹配。
如果根设备具有 d 个嵌入式设备和 s 个嵌入式服务，但只有 k 种不同的服务类型， 那么该设备将可达到 3 + 2d + k 个请求。 如果特定设备或嵌入式设备包含特定服务类型的多个实例， 则仅需要通告一次该服务类型（而不是每个实例一次）。 这会将设备功能的全部范围通告给感兴趣的控制点。 这些消息必须按照到期时间粗略的排好先后顺序，然后按照序列顺序发送出去； 严格的顺序无关紧要，但是单独的刷新或取消消息是禁止的。 （不知道翻译对不对，原文在这里： order is unimportant, but refreshing or canceling individual messages is prohibited）
更新的 UPnP 设备和服务类型需要与该类型的先前版本完全向后兼容。 设备必须公布每种受支持类型的最高受支持版本。 例如，如果设备支持“音频”服务的版本2，即使它也支持版本 1，它也只会发布版本 2。 由此，固定版本的设备或服务的控制点也可以与更高版本进行交互。 但由于仅具有向后兼容性要求，因此只能使用较低版本中定义的功能。 例如，如果控制点仅支持“音频”服务的版本“ 1”，并且设备宣传其支持“音频”服务的版本“ 2”， 则控制点应识别并能够使用该设备 。
为广播选择合适的有效时间是在最小化网络流量和最大化设备状态新鲜度之间的平衡。 相对较短的有效时间（最短为1800秒）将确保控制点具有当前设备状态， 但会增加网络流量； 较长的持续时间（例如一天左右）会损害设备状态的新鲜度，但可以大大减少网络流量。 通常，设备供应商应该选择一个与预期设备使用率相对应的值： 对于短期内预计将成为网络一部分的设备，有效期的时间应该设置比较短； 对于预期长期成为网络成员的设备，有效期时间应该设置较长。 频繁连接和离开网络的设备（例如移动无线设备）应使用较短的有效期时间，以便控制点可以更准确地了解其可用性。 初始的广告集应具有比较合适的有效时间，并且整个组应尽快发送。 广播的后续刷新可能会随时间分布，而不是作为一个组发送。
设备应在发送初始广告集之前随机的等待小于 100 毫秒的间隔，以减少网络风暴的可能性； 该随机间隔也应在设备获得新 IP 地址或安装新网络接口的情况下应用。
由于 UDP 的不可靠特性，设备应多次发送上述每个发现消息，尽管为避免网络拥塞， 发现消息的发送次数不应超过 3 次。另外，设备必须在 CACHE-CONTROL 标头中指定的超市时间到期之前， 定期重新发送其广告。 建议以小于广播到期时间一半的随机分布间隔进行这种广告刷新， 以便为在广告到期之前从为丢失的广播提供恢复的机会，并随着时间的流逝在网络上随机分布多个设备的广告刷新， 以避免网络流量激增。 但请注意，UDP 数据包的长度也是有界的（在某些实现中可能只有512字节）。 每个发现消息必须完全适合单个UDP数据包。而且，不保证上述 3 + 2d + k 个消息将以特定顺序到达。
将设备添加到网络后，它必须使用以下格式广播自己的请求，其中 NTS 头字段的值应该为 ssdp：alive， Method 字段应该为 NOTIFY。其中斜体代表待填充字段。
NOTIFY 方法的请求没有负载（body）部分，但是在头部后了空行一定不能少。（结尾是两个 \r\n）
IP 包的 TTL 默认为 4，但也可以更具具体的情况进行调整。
下面会详细介绍一下上面请求体中各个字段的作用。如非特殊说明，所有的头字段的 Key( field ) 都为大些( UpperCase )。
request line
NOTIFY 发送 notifications 和 events 的方法
* 必须具备 | 请求通用而非特定资源
HTTP/1.1 HTTP 的版本
headers
HOST 必须具备 | Internet 号码分配机构（IANA）为 SSDP 保留的多播信道和端口（239.255.255.250:1900）。 如果在该字段中省略了 1900 这个端口号， 那么接受端应该默认使用 1900 这个端口。
CACHE-CONTROL 必须具备 | 指定广播的有效秒数的 max-age 指令。 超过此时间之后，控制点应假定设备（或服务）不再可用。 | 该字段应大于或等于 1800 秒（30分钟）。 但可由 UPnP 供应商配置指定。 | 数据类型为整数。
LOCATION 需要包含 | 包含指向根设备的 UPnP 描述的 URL。 通常，在非托管网络中，主机部分包含的是 IP 地址字符串，而不是域名。 由 UPnP 供应商指定。单一网址。
NT 需要支持 | 指定 Notification 的类型，具体请参考一下 NT 那张表
NTS 需要支持 | Notification 的子类型，目前必须是该字段 ssdp:alive
SERVER 需要支持。 | 包含操作系统名称，操作系统版本，UPnP / 1.0，产品名称和产品版本的串联。 这些信息由 UPnP 供应商自行指定。 | 数据类型：字符串。 | 该头字段必须准确反映设备支持的 UPnP 设备体系结构的版本号。 控制点必须准备好接受比控制点本身实现的更高的次要版本号。 | 例如，实现 UDA 版本 1.0 的控制点将能够与实现 UDA 版本 1.1 的设备进行互操作。
USN 需要支持。 | 唯一服务名称。标识设备或服务的唯一实例。 必须是以下之一。 | 该字符串的前缀（在双冒号之前）必须与设备描述中的 UDN 元素的值匹配。 （“描述”部分将介绍了 UDN 元素。） | 仅存在单个 URI。
NT 支持的可选项
upnp:rootdevice 根设备，此类消息在一个设备中只会出现一条。
uuid:device-UUID 每一个设备只会发送一次，根设备或者嵌入设备 | UUID 由 UPNP 供应商（vendor）自己决定。
urn:schemas-upnp-org:device:deviceType:v 每一个设备只会发送一次， 根设备或者嵌入式设备。 | 设备类型和版本号由 UPnP 供应商自己确定。 | 指定的版本号为最高支持的版本
urn:schemas-upnp-org:service:serviceType:v 每个服务发送一次。 | 服务类型和版本号有 UPnP Forum 制定， | 指定的版本号为最高支持的版本
urn:domain-name:device:deviceType:v 每一个设备只会发送一次， 根设备或者嵌入式设备。 | 域名的定义由 UPnP 供应商决定， | 指定的版本号为最高支持的版本 | 域名中的句点字符必须根据 RFC 2141 替换为连字符。
urn:domain-name:service:serviceType:v 每一个服务都会发送一次。 | 域名，服务类型和版本号都由 UPnP 供应商自己定义， | 这里指定的版本号为最高支持的版本 | 域名中的句点字符必须根据 RFC 2141 替换为连字符。
USN 支持的可选项
uuid:device-UUID::upnp:rootdevice 根设备发送一次 | 设备 UUID 由供应商决定
uuid:device-UUID 每一个设备都会发送一次, 根设备或者嵌入设备 | 设备 UUID 由供应商决定
uuid:device-UUID::urn:schemas-upnp-org:device:deviceType:v 每一个设备都会发送一次, 根设备或者嵌入设备 | 设备 UUID 由供应商决定 | 设备的类型和版本号有 UPnP 委员会确定 | 这里指定的版本号为最高支持的版本
uuid:device-UUID::urn:schemas-upnp-org:service:serviceType:v 每一个服务都会发送一次 | 设备 UUID 由供应商决定 | 设备的类型和版本号有 UPnP 委员会确定 | 这里指定的版本号为最高支持的版本
uuid:device-UUID::urn:domain-name:device:deviceType:v 每一个设备都会发送一次, 根设备或者嵌入设备 | 设备 UUID， 域名，设备类型，版本由供应商决定 | 这里指定的版本号为最高支持的版本 | 域名中的句点字符必须根据 RFC 2141 替换为连字符。
uuid:device-UUID::urn:domain-name:service:serviceType:v 每一个服务都会发送一次 | 设备 UUID， 域名，服务类型，版本由供应商决定 | 这里指定的版本号为最高支持的版本 | 域名中的句点字符必须根据 RFC 2141 替换为连字符。
NOTIFY 的请求不需要响应。
1.1.3 Discovery: Advertisement: Device unavailable -- NOTIFY with ssdp:byebye
当要将某个设备及其服务从网络中删除时，该设备应多播一个 ssdp：byebye 消息， 该消息对应于其多播的尚未到期的每个 ssdp：alive 消息。 如果设备突然从网络中删除，则可能无法组播消息。 作为后备，发现消息必须在 CACHE-CONTROL 标头中包含一个到期值（如上所述）。 如果不重新发布，发现消息最终将会自行失效，并且必须从任何控制点缓存中删除。
（注意：当一个控制点从网络中推出时，不需要 discovery 相关的请求发出。）
当设备将要从网络中删除时，应通过为发送的每个 ssdp：alive 消息发送一个多播请求，显式撤消其发现消息。 每个多播请求在 NTS 标头中必须具有以下格式的 NOTIFY 和 ssdp：byebye 方法。 斜体值是实际值的占位符
(该请求无 Body 字段，但是后面的空行不能省略，即 IP 负载字段应该以 \r\n\r\n 结尾)
IP 包的 TTL 应该设置成 4, 但是该字段 UPnP 可以根据实际情况修改。
下面将会根据上叙协议中各个字段的详细解释。 除非特殊说明，上叙头中的字段都是大小写敏感的。
Request line
NOTIFY 发送 notifications 和 events 的方法
* 请求通用而非特定资源 | 必须具备
HTTP/1.1 HTTP 的版本
headers
HOST 必须具备 | Internet 号码分配机构（IANA）为 SSDP 保留的多播信道和端口（239.255.255.250:1900）。 如果在该字段中省略了 1900 这个端口号， 那么接受端应该默认使用 1900 这个端口。
NT 需要支持 | （请参考 ssdp:alive 中的说明） | 这里只包含单个 URI
NTS 需要支持 | Notificatioin 的子类型 | 该字段必须为 ssdp:byebye | 这里只包含单个 URI
USN 需要支持 | 唯一的服务名字 | （请参考 ssdp:alive 中的说明） | 这里只包含单个 URI
（该 NOTIFY 信息不要服务端响应）
由于 UDP 的不可靠特性， 设备应多次发送上述每个消息。 作为后备，如果控制点无法接收到有关设备或服务不可用的通知， 原始发现消息最终将失效，从而产生相同的效果。
1.2 Discovery: Search
将控制点添加到网络后，UPnP 发现协议允许该控制点搜索网络上感兴趣的设备。 它通过在保留的地址和端口（239.255.255.250:1900）上多播搜索消息， 该搜索消息的特征码或目标等于设备或服务的类型或标识符。 来自设备的响应与新设备进入网络时广播的消息基本相同，区别是，前者是单播的，后者是组播的。
1.2.1 Discovery: Search protocols and standards
当要搜索设备（并由控制点发现）， 控制点（和设备）使用如下的 UPnP 协议栈的子集。 （本文档开头列出了整个 UPnP 协议栈。）
在协议顶层，搜索消息包含特定于供应商的信息，例如控制点，设备和服务标识符。 协议栈向下一层，供应商内容将由 UPnP 论坛工作委员会提供的信息进行补充，例如设备或服务类型。 来自以上各层的消息都将托管在本文档中定义的 UPnP 协议中。 相应的，搜索请求是通过 HTTP 的多播变体传递的，该变体已使用其他方法和标头进行了扩展。 而搜索响应是通过 HTTP 的单播变体（已扩展）传递的。 两种 HTTP 消息都是通过 UDP over IP 传递的。 作为参考，上方[方括号]中的颜色表示哪种协议定义了下面列出的发现消息中的特定标头和值。
1.2.2 Discovery: Search: Request with M-SEARCH
当一个控制点加入网络之后，它应该发送一个 M-SEARCH 类型的多播请求。 该请求服从下面的格式。Values in italics are placeholders for actual values.
( M-SEARCH 请求没有负载（body 字段），但是结尾的空行必须存在，即数据包应该以 \r\n\r\n 结束。 )
IP 包的 TTL 应该设置成 4, 但是该字段 UPnP 可以根据实际情况修改。
下面将会根据上叙协议中各个字段的详细解释。除非特殊说明，上叙头中的字段都是大小写敏感的。
Request line
NOTIFY 发送 notifications 和 events 的方法
* 请求通用而非特定资源 | 必须具备
HTTP/1.1 HTTP 的版本
headers
HOST 必须具备 | Internet 号码分配机构（IANA）为 SSDP 保留的多播信道和端口（239.255.255.250:1900）。 如果在该字段中省略了 1900 这个端口号， 那么接受端应该默认使用 1900 这个端口。
MAN 该字段服从 HTTP 扩展框架要求。 | 与 NTS 和 ST 标头不同， MAN 标头的值用双引号引起来； | 它定义扩展的范围（名称空间）。 字段值必须为 “ssdp：discover”。
MX 需要支持，该字段指定最大的等待时长，单位为 s, 推荐值在 1 - 120 s 之间。 | 设备的响应该在经过 0 - MAX 之间随机的一段时间后发出， | 而且不应该为迁就网络状况而去增大该值，（下面会说明原因） | 这个字段由 UPnP 供应商指定， | 数据类型为整数
ST 需要支持，指定搜索的目标。 | 必须从以下几个中选择一个（见接下来的 ST 表） | 仅仅包含一个指向资源的 URI
ST 中包含的可选项
ssdp:all 搜索所有的服务
upnp:rootdevice 仅搜索根设备
uuid:device-UUID 搜索 UUID 指定的设备，UUID 由供应商决定
urn:schemas-upnp-org:device:deviceType:v 搜索任何 deviceType 类型的设备， DeviceType 由 UPnP 委员会定义
urn:schemas-upnp-org:service:serviceType:v 搜索任何 serviceType 类型的设备， serviceType 由 UPnP 委员会定义
urn:domain-name:device:deviceType:v 搜索任何服从该域名，设备类型的设备， | 这里的域名和设备类型有 UPNP 供应商定义 | 域名中的句点字符必须根据 RFC 2141 替换为连字符。
urn:domain-name:service:serviceType:v 搜索任何服从该域名，服务类型的服务， | 这里的域名和服务类型有 UPNP 供应商定义 | 域名中的句点字符必须根据 RFC 2141 替换为连字符。
由于 UDP 的不可靠特性，控制点应多次发送各个 M-SEARCH 消息。 作为备用，为防止设备收不到控制点发送的 M-SEARCH 消息的可能性， 设备应定期重新发送其广告（请参见上面 NOTIFY 中带有 ssdp：alive 的 CACHE-CONTROL 标头）。
控制点应该在 MX s 内一直等待设备发出响应。 MX 间隔上响应的随机分布意味着响应者可能在收到 M-SEARCH 请求后的 MX 秒发送响应。 因此供应商应该基于观察到的响应者的数量，然后根据经验调一个合适的 MX 值。 也因为上叙原因，因此无法通过增加 MX 值来解决影响流量传播的网络特征。 请求者可以根据观察到的网络行为，通过启发式方法适应网络特征（确切的启发式方法不在本文范围内）。 算法最终应该会导致请求者等待 M-SEArCH 的时间会略微超过 MX 的时间，从而适应网络的传输特性。 以最小化丢失设备的响应。
需要设备和服务类型的更新版本与以前的版本完全向后兼容。 设备必须响应任何受支持版本的 M-SEARCH 请求。 例如，如果设备实现“ urn：schemas-upnporg：service：Audio：2”， 则该设备也应该响应类型为 “ urn：schemas-upnp-org：service：Audio：1” 的搜索请求。 响应中应指定与搜索请求中包含的版本相同的版本。 如果控制点搜索特定版本的设备或服务并且未收到任何响应（大概是因为网络上没有设备支持指定的版本），但愿意使用较低的版本进行操作，则它可能会重复搜索指定较低的版本。
1.2.3 Discovery: Search: Response
为了找到这些设备，设备必须为每一个从该多播地址收到的请求返回一个响应。 如果发起 MSEARCH 设备的 ST 头为 “ssdp:all” 或者 "upnp:rootdevices" 或者 "uuid:device-UUID"（device-UUID 和本设备一致）, 设备则必须响应这些消息，
设备在收到 DMC 发出的请求之后应该随机的响应 0 - MX 指定的时间然后才响应设备的请求。 这么做是为了防止环境中的设备集中的响应 DMC 的请求，造成短暂的网络拥塞， 如果一个搜索请求有多个响应，那么这些响应也应该随机的分布在 0 - MX 时间段内。 如果搜索请求不包含 MX 标头，则设备必须静默丢弃并忽略搜索请求。 如果 MX 标头指定的值大于120，则设备应假定其包含的值等于或小于 120。 设备在发送响应之前等待随机延迟的同时，不应停止响应其他请求。
在 M-SEARCH 的响应消息中，LOCATION 字段指定的 URL 必须是可以访问的。
设备对 M-SEARCH 的响应是有意相似于 ssdp:alive 的广播消息的，比如说响应的头几乎与 ‘ssdp:alive’ 消息的头一致（除了 NT 头换成了 ST 头）。 响应必须以以下格式发送。 斜体值是实际值的占位符
( M-SEARCH 请求没有负载（body 字段），但是结尾的空行必须存在，即数据包应该以 \r\n\r\n 结束。 )
IP 包的 TTL 应该设置成 4, 但是该字段 UPnP 可以根据实际情况修改。
下面将会根据上叙协议中各个字段的详细解释。除非特殊说明，上叙头中的字段都是大小写敏感的。
request line
HTTP/1.1 HTTP 的版本
200 HTTP 状态码，200 代表成功响应
OK 响应成功的描述字段
headers
CACHE-CONTROL 必须具备 | 指定广播的有效秒数的 max-age 指令。 超过此时间之后，控制点应假定设备（或服务）不再可用。 | 该字段应大于或等于 1800 秒（30分钟）。 但可由 UPnP 供应商配置指定。 | 数据类型为整数。
DATE 建议携带此字段 | 响应的时候生成， | 格式 follow “rfc1123-date”， 在 RFC 2616 中有定义。
EXT 该字段由 （ HTTP Extension Framework） 引入 | 主要用于确定理解请求中 “MAN” 头 | 该头不需要携带任何值
LOCATION 需要包含 | 包含指向根设备的 UPnP 描述的 URL。 | 通常，在非托管网络中，主机部分包含的是 IP 地址字符串，而不是域名。 | 由 UPnP 供应商指定。单一网址。
SERVER 需要支持。 | 包含操作系统名称，操作系统版本，UPnP / 1.0，产品名称和产品版本的串联。 这些信息由 UPnP 供应商自行指定。 | 数据类型：字符串。 | 该头字段必须准确反映设备支持的 UPnP 设备体系结构的版本号。 控制点必须准备好接受比控制点本身实现的更高的次要版本号。 | 例如，实现 UDA 版本 1.0 的控制点将能够与实现 UDA 版本 1.1 的设备进行互操作。
ST 如果请求中指定搜索此头，那么在这里就要包含此头。 | 具体请参考 请求部分的说明
USN 需要支持。这里指定唯一服务名称。 | 具体请参考 "ssdp:alive" NOTIFY 部分 的说明
如果搜索请求出现错误（例如 MAN 标头中的值无效，MX 标头丢失或其他格式错误的内容）， 则设备应静默丢弃并忽略搜索请求。 不建议发送错误响应，因为如果许多设备向同一请求发送错误响应，则可能会出现数据包风暴。
1.3 Discovery references
RFC 2141
URN Syntax. http://www.ietf.org/rfc/rfc2141.txt
RFC 2616
HTTP: Hypertext Transfer Protocol 1.1. http://www.ietf.org/rfc/rfc2616.txt.
RFC 2774
HTTP Extension Framework. http://www.ietf.org/rfc/rfc2774.txt.
2. Description
Description 是 UPnP™ 网络中的步骤 2，在寻址（步骤0）和设备发现（步骤1）之后。
在控制点发现设备之后，控制点仍然对设备知之甚少 - 仅仅能获取发现消息中涉及到的信息，即设备（或服务）的 UPnP 类型， 设备的通用标识符以及设备 UPnP 描述的 URL。 为了控制点了解有关设备及其功能的更多信息，或与设备交互， 控制点必须从发现消息中由设备提供的 URL 检索设备及其功能的详细描述。
设备的 UPnP 描述分为两个逻辑部分： 一个设备描述（名词）描述（动词）物理和逻辑容器，以及描述设备公开的功能的服务描述。 UPnP 设备描述包括特定于供应商的制造商信息， 例如型号名称和编号，序列号，制造商名称，特定的供应商的网站的 URL 等（以下详细信息）。 对于设备中包含的每个服务，设备描述都列出了服务类型，名称，服务描述的 URL， 控制的 URL 和事件的 URL。 设备描述还包括所有嵌入式设备的描述以及用于展示设备状态信息或者控制接口的 URL。 本节说明 UPnP 设备说明，而“控制”，“事件”和“演示”部分分别说明如何使用用于控制，事件和演示的 URL。
注意，单个物理设备可以包括多个逻辑设备。 多个逻辑设备也可以组合成一个嵌入式设备上的根设备（或服务）。 当然也可以组合成多个根设备。 在前一种情况下，根设备只有一个 UPnP 设备描述，并且该设备描述包含所有嵌入式设备的描述。 在后一种情况下，有多个 UPnP 设备描述，每个根设备一个。
UPnP 设备的描述由 UPnP 供应商编写。 该描述采用 XML 格式来表示，通常基于标准的 UPnP 设备模板。 UPnP 论坛工作委员会制作了 UPnP 设备模板； 他们从 UPnP 模板语言（该模板语言是从 XML 的标准构造派生而来）派生模板。 本节说明 UPnP 设备描述，UPnP 设备模板的格式以及 UPnP 模板语言涵盖设备的部分
UPnP 服务描述包括服务响应的命令或动作的列表以及，每个动作的参数或自变量。 服务描述同样也包括变量列表，这些变量决定了设备的运行时状态，同样服务表述还包括各项数据的数据类型，范围和事件特征。 本节说明操作，自变量，状态变量以及这些变量的属性的描述。而事件的特征将会在事件部分说明。
像 UPnP 设备描述一样，UPnP 服务描述由 UPnP 供应商编写。 该描述采用 XML 语法，通常基于标准的 UPnP 服务模板。 UPnP 论坛工作委员会制作了 UPnP 服务模板； 他们从 UPnP 模板语言中获得了模板，并在必要时使用人类语言对其进行了扩充。 UPnP 模板语言源自 XML 的标准构造。 本节将说明 UPnP 服务描述的格式，UPnP 服务模板，典型的人类语言扩展以及 UPnP 模板语言涵盖服务的部分。
UPnP 供应商可以通过扩展服务（包括其他 UPnP 服务）或嵌入其他设备来区分其设备。 当控制点检索特定设备的描述时，这些添加的功能将显示的提供给控制点，以进行设备的控制和事件处理。 从设备和服务描述也严格地记录了设备的实现的功能。
检索 UPnP 设备描述很简单： 控制点使用 HTTP GET 请求去访问设备描述的 URL(在 Discovery 阶段获取)，然后设备即会返回设备对应的描述。 检索 UPnP 服务描述的过程与在设备描述中使用 URL 的过程一样。 响应和请求的协议栈，方法，标头和主体在下面详细说明。
只要来自设备的发现广播还没有过期， 控制点就可以假定该设备及其服务可用。 由于设备和服务描述是静态的，因此只要设备及其服务可用，就可以在任何时候检索设备和服务描述。 如果设备取消其广播或广播到期，则控制点应假定该设备及其服务不再可用。 如果设备需要更改这些描述之一，则必须取消其未完成的广播并重新进行广播。 因此，如果设备重新出现在网络上，则控制点不应假定设备和服务描述不变。
像发现一样，描述在使用不同版本的 UPnP 网络的设备和控制点的互操作性中也起着重要作用。 如发现部分所述，UPnP 设备体系结构既有主要版本也有次要版本。 主版本和次版本是单独的整数； 即使它们可能出现在打印中，也不应将其解释为一个带小数点的数值。 次要版本的提升必须是同一主版本的较早次要版本的兼容超集。 主要版本中的进步不一定是早期版本的超集，也不保证其向后兼容。 版本信息在描述消息中传递，作为后备，此信息也存在在设备的发现消息中。 本节将会说明描述消息中版本信息的格式。
设备和服务的标准由 UPnP 论坛工作委员会标准化或由供应商创建。 设备或服务的每个更高版本都必须是先前版本的完全向后兼容的超集， 即，与该设备的早期版本相比，当前版本必须包括前一版本的所有嵌入式设备和服务。 在设备的所有版本中，UPnP 设备或服务类型均相同，而对于更高版本，设备或服务版本必须更大。 在工作委员会的开发过程中，设备和服务模板的版本可能具有非整数版本（例如“ 0.9”）， 但是标准化后必须成为整数。 设备和服务的版本号可能大于其设计所针对的体系结构的主要版本号 （例如，“ Power：2”可能被设计为在 UDA 版本1.0上工作）； 设备或服务模板的版本与设计用来工作的体系结构的版本之间没有直接关联。 如果定义了设备或服务的非向后兼容版本，则该设备或服务必须具有不同的设备或服务名称， 以指示其不向后兼容（新类型的版本号应从1重新开始）。
UPnP 设备和服务类型可以以各种组合形式组装成 “building blocks”。 标准设备类型和供应商定义的设备类型都可以嵌入标准设备类型中。 标准和供应商定义的设备类型都可以嵌入在供应商定义的设备类型中。 同样，标准和供应商定义的服务类型都可以嵌入在标准和供应商定义的设备类型中。 能够与特定设备或服务类型一起工作的控制点，即使将其嵌入在无法识别的另一种设备类型（标准或供应商定义）中， 也应识别该设备或服务类型。 例如，如果定义了标准服务类型“ Print：1”，并且定义了包含“ Print：1”服务的标准设备类型“ Printer：1”， 控制点希望找到并使用“ Print：1” 服务应，无论服务是嵌入在 “urn：schemas-upnp-org：device：Printer：1” 设备中, 还是嵌入在供应商定义的 “urn：acme-com：device：Printer：1” 中, 或者 “urn：acme-com：device：AcmeMultifunctionPrinter：1”。
本节的其余部分首先说明如何描述设备，并详细说明特定于供应商的信息， 嵌入式设备以及用于控制，事件和显示的URL。 其次，它说明了 UPnP 设备模板。 第三，它解释了如何描述服务，解释了动作，参数，状态变量以及这些变量的属性的详细信息。 然后说明 UPnP 服务模板和 UPnP 模板语言。 最后，本节详细说明控制点如何从设备检索设备和服务描述。
2.1 Description: Device description
设备的 UPnP 描述包含几条特定于供应商的信息，所有嵌入式设备的定义，用于设备显示的 URL，所有服务的列表以及用于控制和事件的URL。 除了定义非标准设备（供应商定义的设备和标准嵌入式设备和服务）之外， UPnP供应商还可以提供这些信息，以下是实际元素和值的占位符列表（斜体）。 其中一些占位符将由 UPnP 论坛工作委员会（红色）或 UPnP 供应商（紫色）指定。 对于非标准设备，所有这些占位符将由 UPnP 供应商指定。 （由UPnP设备体系结构定义的元素显示为绿色，以备后用。）紧随清单之后的是元素，属性和值的详细说明。
下面列出的是上面列表中出现的每个元素，属性和值的详细信息。 所有元素和属性都区分大小写； HTTP 指定 URL 也区分大小写； 除非另有说明，否则其他值不区分大小写。 元素的顺序无关紧要。 除非另有说明：必需元素必须只出现一次（没有重复）， 推荐或可选元素最多也只能出现一次。 请注意，某些实现可能会严格执行以下各个元素的长度限制，因此建议工作委员会注意所有指定的限制。
xml Required | 此字段区分大小写。
root Required | 此元素必须设置 xmlns 属性，而且值必须是 urn:schemas-upnp-org:device-1-0， 这引用了 UPnP 模板语言（如下所述）。 该元素下的子元素一起描述了根设备，区分大小写。其子设备类型如下：
specVersion Required | 包含下列元素
major Required | UDA 的主版本号，必须为 1
minor Required | UDA 的子版本号. 对于实现 UDA 1.0 版本的设备此元素的值 必须为 0
这两个子元素必须准确的反应所实现的 UDA 的版本。而对于控制端，则必须准备接受设备端的版本高于自身的情况。
URLBase Optional | 定义 Base URL。 用于构造标准 URL。根据 RFC 2396 中的规则，描述中其他位置出现的 URL 将是 Base URL 的相对路径, 在使用其他 URL 的时候需要先与 Base URL 拼接成一个完整的 URL。 如果 URLBase 为空或未给出，则可以直接访问其他位置出现的 URL（这是现在的首选实现，不再建议使用 URLBase）。 由UPnP供应商指定。| Single URI。
device Required. 包含下面的元素:
deviceType REQUIRED | UPnP 设备类型. Single URI.
对于由 UPnP 论坛工作委员会定义的标准设备，必须以 "urn:schemasupnp-org：device""开头， 然后是标准化设备类型后缀，冒号和整数设备版本，即 urn: schemas-upnp-org:divice deviceType:ver。 必须指定设备类型的最高支持版本。
对于UPnP供应商指定的非标准设备，必须以 "urn:" + 供应商域名 + ”：device：” + ”deviceType“ + 冒号 + 整数版本， 即“ urn：域名：device：deviceType：ver”。 供应商域名中的句点字符必须根据 RFC 2141 替换为连字符。 必须指定设备类型的最高支持版本。
设备类型的后缀由 UPNP 委员会定义，或者由设备供应商定义，长度必须小于 64 字节（版本号和冒号不在计数范围）。
friendlyName Required | 一个对终端用户友好的简短描述，应支持本地化语言(参见. ACCEPT-LANGUAGE 和 CONTENTLANGUAGE 头). 由设备供应商指定。该元素值必须小雨 64 字节 | String 类型。
manufacturer Required | 制造商名字. 应该支持本地化 (参见. ACCEPT-LANGUAGE 和 CONTENTLANGUAGE 头). 由设备供应商指定。该元素值必须小雨 64 字节 | String 类型。
manufacturerURL Optional | 制造商的主页，应该支持本地化 (参见. ACCEPT-LANGUAGE 和 CONTENTLANGUAGE 头). 由设备供应商指定。该元素值必须小雨 64 字节 | String 类型。
modelDescription Recommended | 关于设备模块的详细描述， 应该支持本地化 (参见. ACCEPT-LANGUAGE 和 CONTENTLANGUAGE 头). 由设备供应商指定。该元素值必须小雨 128 字节 | String 类型。
modelName Required | 设备模块名字， 应该支持本地化 (参见. ACCEPT-LANGUAGE 和 CONTENTLANGUAGE 头). 由设备供应商指定。该元素值必须小雨 32 字节 | String 类型。
modelNumber Recommended | 设备模块数量， 应该支持本地化 (参见. ACCEPT-LANGUAGE 和 CONTENTLANGUAGE 头). 由设备供应商指定。该元素值必须小雨 32 字节 | String 类型。
modelURL Optional | 模块的介绍网址， 应该支持本地化 (参见. ACCEPT-LANGUAGE 和 CONTENTLANGUAGE 头). 由设备供应商指定。该字段有可能是资源相对与 BaseURL 的相对位置 | String 类型。
serialNumber Recommended | 设备序列号， 应该支持本地化 (参见. ACCEPT-LANGUAGE 和 CONTENTLANGUAGE 头). 由设备供应商指定。该元素值必须小雨 64 字节 | String 类型。
UDN Required | 唯一的设备名称，设备的通用唯一标识符（与根标识符还有嵌入式标识符也保持唯一性）。 在设备的生命周期内，该元素的值应该保持不变（即重启后任然有效，恢复出厂设置之后可以变更）， 必须与设备发现消息中 NT 标头的值匹配。 在所有发现消息中，必须与 USN 标头的前缀匹配。 （关于发现的部分说明了 NT 和 USN 标头）。 必须为以下格式（ ”uuid：“ + PnP 供应商指定的UUID后缀） | 单个URI。
UPC Optional | 通用产品代码（Universal Product Code），由 12 个数字组成， 标识消费者包装的代码。 由统一代码委员会管理（the Uniform Code Council）。 由 UPnP 供应商指定 | Single UPC。
iconList 如果产品有自己的 ICON, 那么此字段就需要存在。 有供应商自己指定，包含以下子元素：
icon Recommended | 用于在控制点 UI 中描绘设备的图标。 应该支持本地化 (参见. ACCEPT-LANGUAGE 和 CONTENTLANGUAGE 头). ICON 的大小是取决于供应商设计。包含以下子元素：
mimetype Required | Icon 的 MIME type， (参考 RFC 2045, 2046, and 2387) | Single MIME image type | 至少应该包含 image/png (Portable Network Graphics, see IETF RFC 2083) 类型
width Required | icon 的水品大小（宽） | 单位为像素 | Integer
height Required | icon 的垂直大小（高） | 单位为像素 | Integer
depth Required | icon 每个像素的（色彩深度） | Integer
url Required | img 的 URL( XML 不支持直接嵌入图片在描述文档中. 参看下面的注释) | 该字段有可能是资源相对与 BaseURL 的相对位置 | 由 UPNP 供应商指定 | Single URL.
serviceList Optional | 包含以下子元素：
service Optional | 对于 UPNP 委员会定义的每个服务都要有描述， 对于供应商额外自定义的用来区分设备的服务也需要在这里有描述。 该服务元素有一下属性。
serviceType Required | 服务类型 | 必须包含一个 23 位 UTF-8 编码的散列值 | Single URI.
对于由 UPnP 委员会定义的标准服务类型， 必须遵守以下格式( “urn：schemas-upnp-org：service" + 标准服务类型后缀 + ： + 整数服务版本)， 即 urn: schemas-upnp-org:device： ：serviceType：ver 。 必须指定服务的最高支持版本。
对于非标服务，则必须遵守以下格式 ( "urn:" + 供应商的域名 + ”:service:“ + 服务类型后缀 + 服务版本号-整数 )，供应商域名中的句点字符必须根据RFC 2141替换为连字符。必须指定服务类型的最高支持版本。
这些服务的类型有 UPnP 委员会或者供应商定义，长度必须小于 64 字节 ( 类型后缀和冒号分隔符不包括在内 )。
serviceId REQUIRED | 服务的唯一标识 | 在整个设备描述中必须是唯一的 | Single URI.
对于 UPNP 委员会定义的标准服务，这里必须是服从以下格式 ( urn:upnp-org:serviceId: + 服务的 ID 后缀 )（如 urn:upnporg:serviceId:serviceID ）。 如果这个实例在上面指定的服务类型（如：
对于非标设备，必须服从以下格式（”urn：“ + 供应商域名 + ":serverId:" + 服务 ID 后缀）， 例如： “urn:domain-name:serviceId:serviceID”。 如果这个实例在上面指定的服务类型（如：
这里的设备 ID 后缀由 UPNP 委员会或者供应商定义，必须小于 64 字节。
SCPDURL Required | 详细描述此服务的 URL， (nee 服务控制协议定义 URL). (参考以下服务描述章节的说明 ） 又 UPNP 供应商指定 | Single URL.
controlURL Required | 用于控制的 URL (参考以下控制章节的说明). 此字段有可能是 BaseURL 的相对路径 | 有供应商指定 | Single URL.
eventSubURL Required | 事件的 URL（请参阅事件部分）。 可能是 BaseURL 的相对路径。 设备内必须唯一； 没有两个服务可以具有用于事件的相同 URL。 如果服务没有事件变量，则不应包含事件（请参见事件部分）； 如果服务没有事件，则此元素必须存在但应为空，即
deviceList 当此根设备拥有嵌入设备的时候，此元素存在。该元素拥有以下子元素：
device Required | 有供应商决定 | 没有嵌入设备都必须拥有一个描述， 如果供应商这里的子元素的定义和上面根设备包含的子元素一致。
presentationURL Recommended | 展示设备状态和控制界面的 URL (参考展示章节). 此字段有可能是 BaseURL 的相对路径 | 有供应商指定 | Single URL.
控制点在识别和与设备交互时使用的 serviceID 应该要与设备定义的值不同。 如果存在一个服务有多个实例，则控制点应默认（除非用户操作另有指示）应使用与设备类型定义的 serviceId 值关联的服务实例。 如果服务的所有实例都不具有由设备类型定义的 serviceId 值，则控制点可以使用任何服务实例。 当仅存在一个服务实例时，即使 serviceId 值与设备类型定义的值不匹配，控制点也应使用该实例。
为看可扩展性，当像上面的清单那样处理 XML 时，设备和控制点必须忽略： （a）任何未知元素及其子元素或内容 以及 （b）任何未知属性及其值。
控制点和设备应忽略它们不理解的 UPnP 设备和服务描述中嵌入的任何 XML 注释或 XML 处理指令。
UPnP设备描述应使用UTF-8编码。
当任何文本元素或属性的值包含一个或多个保留标记的字符时（例如 ampersand（＆）或 less than（“ <”））， 必须按照XML规范第2.4节的规定对文本进行转义，并将每个此类字符替换为等效的数字表示形式或字符串（例如“&”或“<”）。 出现在 URL 中的此类字符也可以根据 RFC 2396 第 2.4 节中指定的 URL 转义规则进行转义。
XML 不支持直接将二进制数据（例如，图标）嵌入 UPnP 设备描述中。 如果一定要嵌入，可以使用 bin.base64（二进制数据的 MIME-style 的 base 64 编码）或 bin.hex（十六进制数字代表八位字节）的 XML 数据类型将二进制数据转换为文本。 或者，可以通过在 XML 中嵌入 URL 并响应单独的 HTTP 请求来传输数据来间接传递数据。 UPnP 设备描述中的图标以后一种方式传输。
如果有包括任何图标，则至少应该采用 RFC 2083 中���义的可移植网络图形（PNG）格式， 由 MIME 类型“ image/png” 指示，而且不应该采用 progressive encoding 编码方式。 由于各种控制点偏爱的种类繁多，因此不建议使用特定的图标大小。 鼓励控制点供应商发布实施指南。
请注意，在 UPnP 设备体系结构的 1.0 版中， serviceList 元素是必需的，并且它至少包含一个服务元素。 但随后的版本取消了这些要求，以适应网关和基本设备类型。 如果设备没有服务，则 serviceList 元素可以完全省略，也可以存在但不包含服务元素。
2.2 Description: UPnP Device Template
上面的清单说明了 UPnP 设备描述和 UPnP 设备模板之间的关系。 如上所述，UPnP 设备描述是由 UPnP 供应商按照 UPnP 设备模板以 XML 编写的。 UPnP 委员会制作了 UPnP 设备模板，作为标准化设备的一种方法。
通过选择适当的占位符，上面列出的内容可以是 UPnP 设备模板或 UPnP 设备描述。 其中，某些占位符由 UPnP 论坛工作委员会（红色）定义（如：UPnP 设备类型标识符 / UPnP 服务 / UPnP 嵌入式设备（如果有的话））。 如果这些被编写到代码中，则生成的 XML 文档即是 UPNP 设备模板。 UPnP 设备模板是 UPnP 论坛工作委员会的主要成果之一。
更进一步，由 UPnP 供应商（紫色）指定上面列表中的其余占位符， 即特定于供应商的信息。 如果在代码中指定了这些占位符（以及其他占位符）， 则列表将是 UPnP 设备描述，适合传递给控制点以用来后续的控制 / 事件 / 演示。
换句话说，UPnP 设备模板定义了设备的整体类型， 每个 UPnP 设备描述都使用供应商特定的信息实例化该模板。 前者 UPnP 论坛工作委员会定义， 而后者由 UPnP 供应商定义。
2.3 Description: Service description
PnP 描述定义了服务的可执行动作, 参数，状态变量及其数据类型，范围和事件特征。
每个服务可能有零个或多个动作。 每个动作可以具有零个或多个参数。 这些参数可以是输入参数或也可以是输出参数。 如果一个动作具有一个或多个输出自变量， 则这些自变量中的一个可被标记为返回值。 每个参数应对应一个状态变量。 这给直接操纵的编程模型增强了简单性。
每一个服务必须有一个或者多个状态变量。
为了定义非标服务，UPnP 供应商可能会增加自己定义的 action 或者 service 给标准设备， 而且也可能嵌入非标准设备到标准设备。
为了说明这些观点，下面列出了包含实际元素的占位符（以斜体显示）和值。 对于标准的 UPnP 服务，其中一些占位符将由 UPnP 论坛工作委员会定义（红色）或由UPnP供应商指定（紫色）。 对于非标准服务，所有这些占位符将由 UPnP 供应商指定。 （由UPnP设备体系结构定义的元素显示为绿色，以备后用。）紧随清单之后的是元素，属性和值的详细说明。
下面列出的是上面列表中出现的每个元素，属性和值的详细信息。 所有元素和属性（包括动作，参数和状态变量名称）均区分大小写, 顺序也无关紧要，必需元素必须仅出现一次（没有重复），推荐或可选元素最多只能出现一次， 除非另有说明。
xml所有的 XML 文档都大小写敏感
scpd Required | Must | 属性 xmlns 的值必须是 urn:schemas-upnp-org:service-1-0; 这引用了UPnP模板语言（如下所述）。下面详细介绍该元素的子元素：
specVersion Required | 包含以下子元素：
major Required | UDA 的主版本号，必须为 1
minor Required | UDA 的子版本号. 对于实现 UDA 1.0 版本的设备此元素的值 必须为 0
这两个子元素必须准确的反应所实现的 UDA 的版本。而对于控制端，则必须准备接受设备端的版本高于自身的情况。
actionList Required （ 如果服务拥有 action ） (每一个服务必须包含 >= 0 个 action), action 的子元素有如下几种：
action Required | 对 UPnP 委员会定义的每个操作都要实现一次。 如果 UPnP 供应商需要通过添加其他 action 来区分服务， 则也要为添加的 action 实现在此处。一个 action 包含以下子元素：
name Required | action 的名字， 不得包含连字符（-，UTF-8 中为 0x2D ）或 哈希字符（＃，UTF-8 中为 0x23）。 | 区分大小写 | 第一个字符必须是 USASCII 字母（A-Z，a-z）/ USASCII 数字（0-9） / 下划线（“ _”）/ 大于 U+007F 的非实验性 Unicode 字母或数字。
支持的字符必须在以下范围 USASCII 字母（A-Z，a-z） / USASCII 数字（0-9） / 下划线（“ _”） / 句点（“.”） / Unicode组合字符 / 扩展程序或非实验性 Unicode 大于 U+007F 的字母或数字。
在任何情况下，前三个字母不得为“ XML”。
对于标准的 action 必须以 X_ 或者 A_ 开头。
对于非标 action， 但是是添加到标准设备中的 action， 则必须以 X_ 开头。
String | 必须小于 32 个字符。
argumentList
Required （当且仅当 action 定义了要操作的参数时）( 每一个 action 可能会有 >= 0 个参数)，参数有以下的子元素
argument
Required | 每一个参数都拥有这样的一个元素，该元素又如下子元素：
name
Required | 参数的名字 |
不得包含连字符（UTF-8中为 '-'，0x2D）。
第一个字符必须是 USASCII 字母（A-Z，a-z），
USASCII 数字（0-9），
下划线（“ _”）或大于 U+007F 的非实验性 Unicode 字母或数字。
中间包含的字符必须在以下范围内：
USASCII 字母（A-Z，az） / USASCII数字（0-9） / 下划线（“ _”），句点（“.”），Unicode 组合字符，扩展程序或非实验 Unicode 大于 U+007F的字母或数字。
任何组合中，前三个字母不得为“ XML”。
应小于32个字符。
direction
Required |
参数是输入参数还是输出参数。
值必须是 in or out。
retval
Optional | 最多将一个 out 参数指定为返回值。
如果在一个 action 中指定了一个返回值，
则该参数在文档顺序中一定要是在 out 类型的参数列表中排第一。
relatedStateVariable
Required | 该参数关联的状态变量名称，
serviceStateTable
Required | 每一个服务包含大于 0 个状态变量，该状态变量的元素对象包含如下元素：
stateVariable
Required | 对 UPnP 委员会定义的每个状态变量都要在此实现。
如果 UPnP 供应商有通过添加其他状态变量来区分服务，
则每个其他变量也需要在此实现。
sendEvents 属性定义当此状态变量的值更改时是否生成事件消息；
非事件状态变量具有 sendEvents = “no”;
默认值为 sendEvents = yes。
该状态变量的元素对象包含如下元素：
name
Required | 状态变量的名字，
不得包含连字符（-，UTF-8 中为 0x2D ）或
哈希字符（＃，UTF-8 中为 0x23）。
| 区分大小写 | 第一个字符必须是 USASCII 字母（A-Z，a-z）/ USASCII 数字（0-9） / 下划线（“ _”）/ 大于 U+007F 的非实验性 Unicode 字母或数字。
支持的字符必须在以下范围 USASCII 字母（A-Z，a-z） / USASCII 数字（0-9） / 下划线（“ _”） / 句点（“.”） / Unicode组合字符 / 扩展程序或非实验性 Unicode 大于 U+007F 的字母或数字。
在任何情况下，前三个字母不得为“ XML”。
dataType
Required | 与 XML Schema 第 2 部分《数据类型定义》的数据类型相同。
由 UPnP 委员会为标准状态变量定义， 或者由UPnP供应商指定用于扩展。 必须为以下值之一：
ui1
1 Byte 无符号整形。
数值范围 [0, 255] 。
ui2
2 Byte 无符号整形。
数值范围 [0, 65535]。
ui4
4 Byte 无符号整形。
数值范围 [0, 4294967295] 。
i1
1 Byte 有符号整形。
数值范围 [-128 , 127 ]。
i2
2 Byte 有符号整形。
数值范围 [-32768 ,32767 ]。
i4
4 Byte 有符号整形。
数值范围 [-2147483648, 2147483647] 。
int
Fixed point, integer number. May have leading sign. May have leading zeros.
(No currency symbol.) (No grouping of digits to the left of the decimal, e.g., no
commas.)
r4
4 字节浮点型，格式和 float 一样，
数值范围在 [ 3.40282347E+38 , 1.17549435E-38 ] 之间。
r8
8 字节浮点型，格式和 float 一样，
复数数值范围在 [ -1.79769313486232E308， -4.94065645841247E-324 ] 之间。正数在 [4.94065645841247E-324 ， 1.79769313486232E308 ] 之间。
number
Same as r8.
fixed.14.4
Same as r8， 但是不会超过 14 个数字在小数点左边，不会超过 4 个数字在小数点右边。
float
Floating point number. Mantissa (left of the decimal) and/or exponent may
have a leading sign. Mantissa and/or exponent may have leading zeros. Decimal
character in mantissa is a period, i.e., whole digits in mantissa separated from
fractional digits by period. Mantissa separated from exponent by E. (No
currency symbol.) (No grouping of digits in the mantissa, e.g., no commas.)
char
Unicode string. 一个字节。
string
Unicode string.不限长度。
date
格式遵从 ISO 8601 标准，但不包括 time data 类型.
dateTime
格式遵从 ISO 8601 标准，但不包括 timezone.
dateTime.tz
格式遵从 ISO 8601 标准，time 和 timezone 都是可选的。
boolean
值包含两个值 0 / 1, 0 代表 假，1 代表真，”true“ / ”false“, ”yes“ / ”no“ 也可以使用，但是不推荐。
bin.base64
MIME 样式的 Base64 编码的二进制 BLOB。
每 3 个字节分成 4 个 par，每一 Par 占 6 个 bit。
然后将 6 个 bit 映射到 8 个 bit 中。大小不受限制。
bin.hex
将一个字节拆分成两个十六进制字符表示，每 4 个 bit 对应一个 字符。
大小不受限制。
bin.uri
uri
bin.uuid
UUID( niversally Unique ID )。
代表八位位组的十六进制数字。 可选的嵌入式连字符将被忽略。
defaultValue
Recommended | 初始值，
由 UPnP 委员会定义或者 UPnP 供应商定义.
必须符合以上的数值类型，必须在以下提到的 allowedValueList
或者 allowedValueRange 内。
allowedValueList
Recommended |
枚举合法的字符串值。 禁止使用非字符串数据类型。 该字段与allowedValueRange 互斥。
子元素是有序的（参见NEXT_STRING_BOUNDED）。 包含以下子元素：
allowedValue
Required | 一个合法的字符串值，对于标准的状态变量，这里的值由 UPnP 委员会定义，对于 UPnP 扩展的则又供应商自己决定。
该字段的值必须小于 32 个字符。
allowedValueRange
Recommended.
定义一个合法的数值范围，该字段与 allowedValueList 互斥。
包含以下子元素：
minimum
Required | 可选范围的下边界，
由 UPnP 委员会定义，对于 UPnP 扩展的则又供应商自己决定。
此处为单个数值。
maxiumum
Required | 可选范围的上边界，
由 UPnP 委员会定义，对于 UPnP 扩展的则又供应商自己决定。
此处为单个数值。
step
Recommended | 每一次 increment 或者 decrement 是的步进。例如在操作 v = v + s 中 s 的值。
由UPnP论坛工作委员会定义或委托给UPnP供应商。 单个数值。
元素 relatedStateVariable 的值必须是定义在同一服务里状态变量的名称。
relatedStateVariable 定义了参数的类型；
argument 和 relatedStateVariable 之间不一定存在任何语义关系。
relatedStateVariable 必须在 serviceStateTable 中指定 stateVariable 的名称，该名称具有的 dataType，
allowedValueList 和 allowedValueRange。
如果不存在带有适当定义的 stateVariable，
则工作委员会（或供应商）必须为此目的定义其他状态变量；
用于描述参数类型而定义的状态变量的名称的前缀应该是 “ A_ARG_TYPE_”。
allowedValueList 和 allowedValueRange 元素可用于指示设备可选的功能。
UPnP 委员会可能要求列表或范围中的所有值都应由所有供应商支持（无选项），或带有最小可选值的最小子集，或允许供应商完全决定。
如果委员会允许，供应商可以将供应商定义的 allowedValues 添加到标准 allowedValueList 中（名称前缀必须为 'X_'）。
但是，应注意，定制的可选功能应该尽可能的减少了控制点可能依赖的值的数量，从而防止影响到交互操作时的兼容性。
如果设备功能会在设备运行期间发生变化，则委员会应定义单独的 action 来检测设备功能，
而不是将区分功能的信息嵌入到服务描述中。
而每次服务描述文档更改时，设备都应该取消之前的广播并重新发布新的功能的广播。
如果服务描述用于传达功能信息，则设备必须从服务描述中省略未实现的可选元素（动作，allowedValues等）。
为了将来的可扩展性，当像上面的清单那样处理 XML 时，设备和控制点必须忽略：
（a）任何未知元素及其子元素或内容，以及（b）任何未知属性及其值。
控制点和设备应忽略嵌入在 XML 描述文档中的注释，和控制点本身不支持或者不懂的那些描述。
UPnP 服务描述应使用 UTF-8 编码。
任何属性或者元素的值都包含一个或者多个保留字（即 '&' 符号或者是 '<'）,
如一定要使用此类字符则必须按照 XML 规范的 2.4 节的规定对文本进行转义，
并用等效的数字表示形式或字符串替换每个此类字符（例如 '& amp;” 或 “& lt;”）。
出现在 URL 中的此类字符也可以根据 RFC 2396 第 2.4 节中指定的 URL 转义规则进行转义。
注意，服务在逻辑上可能没有任何动作，但具有状态变量和事件；
尽管这种服务不太可能，但是它将成为自治信息源。
但是注意，禁止使用没有状态变量的服务。
与设备描述不同，服务描述和关联的值不应使用 locale-specific（本地化） 的值。
应用程序应将信息从标准格式转换（格式化）为语言环境的正确语言（或格式）。
例如，日期以与语言环境无关的格式（ISO 8601）表示，而整数则以没有语言环境特定的格式表示（例如，没有货币符号，没有数字分组）。
字符串值应以标准的 “语言环境” 或与语言环境无关的方式表示。
具有 allowedValueList 的变量应使用 UPnP 标准语言的标记值。
但是，在某些情况下，动作的行为取决于语言环境。
在这种情况下，应该定义一个参数来指示语言环境，
比如可以使用 ACCEPT-LANGUAGE 和 CONTENT-LANGUAGE 标头（RFC 1766）。
如果存在多个依赖于语言环境的 action，则该服务可以包括一个操作，
该操作用于设置状态变量以指示语言环境，以消除了将语言环境标识符分别传递给每个操作的需要。
UPnP 委员会标准化的服务具有整数版本。
服务的每个更高版本都必须是先前版本的超集，
即，它必须完全包含服务的早期版本所定义的所有操作和状态变量。
UPnP 服务类型在服务的所有版本中都相同，而对于更高版本，该服务版本必须更大。
在工作委员会的开发过程中，设备和服务模板的版本可能具有非整数版本（例如“ 0.9”），但是标准化后必须成为整数。
设备和服务的版本号可能大于其设计所针对体系结构的主要版本号，但是设备服务也要应该响应低版本控制端的指令
（例如，“ Power：2” 可能被设计为在 UDA 版本 1.0 上工作）。
2.4 Description: UPnP Service Template
上面的清单还说明了 UPnP 服务描述和 UPnP 服务模板之间的关系。
如上所述，服务的 UPnP 描述是由 UPnP 供应商按照 UPnP 服务模板以 XML 编写的。
UPnP 委员会制作了 UPnP 服务模板，作为标准化设备的一种方法。
通过适当的占位符规范，
上面的清单可以是 UPnP 服务模板也可以是 UPnP 服务描述。
回想一下，某些占位符将由 UPnP 论坛工作委员会（红色）定义，即 action 及其 arguments，status 及其 dataType，
range 和 event characteristics 。
如果将上面指定的这些实例化为代码，那么这就是一份 UPnP 服务模板，
UPnP 服务模板是 UPnP 论坛工作委员会的主要交付成果之一。
更进一步，如果 UPnP 供应商（紫色）指定了上面列表中的其余占位符，
即由供应商指定的其他 action 和 status variables。
如果指定了这些占位符（以及其他占位符），
则列表将是 UPnP 服务描述，适用于对设备内服务的有效控制。
换句话说，UPnP 服务模板定义了服务的整体类型，
而 UPnP 服务描述则在模板的基础上包含了供应商的添加特定的特性。
第一个由 UPnP 委员会创建； 后者由 UPnP 供应商提供。
2.5 Description: Non-standard vendor extensions
如上所述，UPnP 供应商可以通过添加其他服务和嵌入式设备来区分其设备并扩展标准设备。
同样，UPnP 供应商可以通过添加其他操作或状态变量来扩展标准服务。
下表中列出了每种方法的命名约定，并在上面进行了详细说明。
如上表的最后两行所示，
UPnP 供应商还可以将非标准 XML 添加到设备或服务描述中。
每个添加项都必须由供应商的 XML namespace 限制。
供应商添加的 XML 元素必须包含在以 X_ 开头的元素中，
并且该元素必须是标准元素的子元素。
可以将非标准属性添加到标准元素中，
前提是这些属性的元素名称是 X_ 开头的。
为了说明这一点，
下面列举了实际元素和值的占位符（斜体）。
以及一些 UPnP 供应商指定（紫色）字段替换后的样例。
和一些则由 UPnP 设备体系结构定义的样例（绿色）。
RootStandardElement
Required | 一个标准的根元素. xmlns 属性定义了 namespaces。
在这个案例中,描述了一个标准 UPnP namespace 和一个以 'n' 为前缀的非标 namespace。
注意对于设备的描述，这个描述必须存在 root 元素中。
注意对于设备的描述，这个描述必须存在 scpd 元素中。
AnyStandardElement
Required | 任何标准元素，无论是根元素还是其他元素，文本的内容或者元素的内容。
必须作为标准设备或标准服务服务的一部分。
X_VendorAttribute 必须以 X_ 开头，后可以接任意字符串。
（前缀 A_ 是保留的。）
EltOnlyStandardElement
Required | Element with content of element only. Must already be included as part of the standard device or service
description.
仅包含元素内容的元素。 这些元素必须包含在标准设备或标准服务描述中。
对于设备的描述，必须是其中之一：
root, specVersion, device, iconList, icon, serviceList, service, and/or deviceList.
对于服务的描述，必须是其中之一：
scpd, actionList, action, argumentList, argument, serviceStateTable, stateVariable, allowedValueList, and/or allowedValueRange.
X_VendorElement
Required | 必须是以 'X_' 开头( 前缀 ‘A_’ 为保留字)。必须有 xmlns 属性. 可能还包括其他任意的 XML 内容。
如果控制点不理解自定义的一些标签，那么控制点应该忽略之。
2.6 Description: UPnP Template Language for devices
上面的段落解释了 UPnP 设备描述，并说明了如何从 UPnP 设备模板中实例化该描述。
如前所述，UPnP 设备模板是由 UPnP 论坛工作委员会制作的，这些模板是从 UPnP 模板语言衍生而来的。
该模板语言定义了设备和服务的有效模板。以下是与设备有关的该语言的清单和说明。
UPnP 模板语言是用 XML 语法编写的，并且派生自 XML Schema（第1部分：结构，第2部分：数据类型）。
XML 模式提供了一组 XML 的结构，这些结构表达（展示/阐述）了描述语言概念，
例如必需元素与可选元素，元素嵌套和值的数据类型（以及此处不感兴趣的其他属性）。
UPnP 模板语言使用这些 XML 架构构造来定义元素，例如以上详细列出的 specVersion，URLBase，deviceType 等。
因为 UPnP 模板语言是使用另一种精确的语言构造的，所以它是明确的。
并且由于 UPnP 模板语言，UPnP 设备模板和 UPnP 设备描述都是机器可读的，
因此自动化工具可以自动检查以确保后两个具有所有必需的元素，正确地嵌套并且具有正确的数据类型的值。
下面是由 UDA 定义的设备的 UPnP 模板。
这些元素在 UPnP 设备模板中有介绍（这里和上面的解释都用绿色表示）;
Below is where these elements are defined; above is where they are used.
紧随其后的是对使用的 XML Schema 元素，属性和值的简要说明。
本节末尾的 XML Schema 参考有更多详细信息。
UPnP Template Language for devices
ElementType
用新的派生语言定义元素。 name 属性定义元素名称。
dt:type 属性使用新的派生语言为 element 的值定义数据类型。
element
使用嵌套的方式来引用元素。 minOccurs 属性定义元素必须出现的最小次数。 默认值为 minOccurs = 1;
可选元素的 minOccurs =0。maxOccurs属性定义元素必须出现的最大次数。 默认值为maxOccurs = 1;
可以出现一次或多次的元素具有 maxOccurs = *。
Content =“textOnly” 表示元素不包含子元素；
content =“eltOnly”表示元素包含子元素。
2.7 Description: UPnP Template Language for services
本章节介绍服务描述是如何从 UPnP 服务模板中实例化到的。像设备模板一样，UPnP 的服务模板也是有 UPnP 委员会定义的每个操作都要实现一次。
服务模板和设备模板也都是由 UPnP 模板语言衍生而来，像上面介绍的一样，UPnP 模板文档服从 XML 的语法格式（由 XML Schema 衍生而来），
（这里主要产靠 Part1: struct 和 Part 2: DataTypes）。
下面是一个 service 描述模板的例子，这里绿色代表涉及的内容对应上面提到的内容。
下面定义的元素也揭示了他们的用法。
紧随其后的是对使用的 XML Schema 元素，属性和值的简要说明。本节末尾的 XML Schema 参考有更多详细信息。
UPnP Template Language for services
attribute
引用属性以声明该可能出现在哪些元素中。
像任何 XML 元素一样，AttributeType 元素可以具有自己的属性。
在此元素内使用 required 属性指示该属性是否必须存在；
可选属性 required=no。
AttributeType
定义一个新的 AttributeType，像任何XML元素一样，AttributeType元素可以具有自己的属性。
在此元素中使用 name 属性定义属性名称，因为它将在派生语言中使用。
element
使用嵌套的方式来引用元素。 minOccurs 属性定义元素必须出现的最小次数。 默认值为 minOccurs = 1;
可选元素的 minOccurs =0。maxOccurs属性定义元素必须出现的最大次数。 默认值为maxOccurs = 1;
可以出现一次或多次的元素具有 maxOccurs = *。
Content =“textOnly” 表示元素不包含子元素；
content =“eltOnly”表示元素包含子元素。
ElementType
定义一个新的 element。 name 属性定义元素名称。dt：type 属性使用新的 element 的值定义数据类型。
model 定义此处是否有一个新的 elements, 属性指示新的派生语言中的元素是否可以包含此处未明确指定的元素；
如果仅可以使用以前的特定元素，则 model=closed。
content 属性指示可能包含的内容；
仅包含其他元素的元素具有 content = eltOnly;
仅包含字符串的元素的content = textOnly。
group
将内容组织为一组以指定序列。 minOccurs 属性定义组必须出现的最小次数。
maxOccurs 属性定义组必须出现的最大次数。
顺序属性限制元素的顺序； 当最多允许一个元素时，order = one。
2.8 Description: Retrieving a description
如上所述，控制点发现设备后，仍然对设备知之甚少。
要了解有关设备及其功能的更多信息，控制点必须使用设备在发现消息中提供的 URL 检索设备的 UPnP description(描述)。
然后，控制点必须使用设备描述中提供的 URL 检索一个或多个服务描述。
这是一个简单的基于 HTTP 的过程，并使用了整个 UPnP 协议堆栈的以下子集。 （本文档开头列出了整个UPnP协议栈。）
在协议的最上层，描述消息包含特定于厂商的信息，例如，设备类型，服务类型和所需的服务。
从协议栈向下移动，供应商内容将由 UPnP 论坛工作委员会提供的信息进行补充，例如型号名称，型号编号和特定的 URL。
来自以上各层的消息以本文档中定义的特定于 UPnP 的协议托管。
反过来，上述消息通过基于 IP/TCP 上的 HTTP 传递。
作为参考，上面[方括号]中的颜色表示在下面列出的描述消息中哪个协议定义了特定的标头和主体元素。
使用此协议栈，检索UPnP设备描述非常简单：
控制点向发现消息中的 URL 发出 HTTP GET 请求，并且设备在 HTTP 响应的正文中返回其描述。
类似地，为了检索 UPnP 服务描述，控制点向设备描述中的 URL 发出 HTTP GET 请求，然后设备在 HTTP 响应的正文中返回该描述。
响应和请求的标头和正文将在下面详细说明。
首先，控制点必须使用以下格式的GET方法发送请求。 斜体部分需要填上实际的值
获取 description 的请求没有负载字段， 但在请求头之后一定要有空行（即以 \r\n\r\n 结束）。
下面列出的是请求行的详细信息以及出现在上面列表中的标题。 除非另有说明，否则所有标头值均区分大小写。
Request line
GET
HTTP GET Method
path to description
获取 device 或者 service 的 description 的资源路径。device description 的 URL 在 discovery 响应的 LOCATION 字段中。
service description 的 URL 在 device description 的 SCPDURL 字段中。
HTTP/1.1
HTTP 版本
headers
HOST
Required | 服务的域名或者 IP 地址（端口号可省略），
device description 的 URL 在 discovery 响应的 LOCATION 字段中。
service description 的 URL 在 device description 的 SCPDURL 字段中。
如果端口号没有给出，则默认为 80 端口。
ACCEPT-LANGUAGE
在获取设备描述的时候推荐添加此字段，该字段表示有限选择的语言，
如果这个字段没有指定可用的语言，则返回的描述采用用默认语言。
请参考（ RFC 1766 ）。
在 Control Point 发出获取描述的请求之后，设备需要马上响应 ControlPoint 请求，将 description 文档发给 ControlPoint。
设备必须在合适的时间（一定要小于 30s）响应该请求。
如果在这个时间内响应失败了，那么 ControlPoint 必须马上重新发送一个请求。
设备必须以以下的格式返回响应信息。（斜线部分应该替换成具体的值）
这个响应的负载部即是设备或者服务的描述部分。在上面的几个小节中阐述了。
下面将会介绍请求头字段部分，所有的值都是大小写敏感的。
headers
CONTENT-LANGUAGE
如果请求的头字段中有 ACCEPT-LANGUAGE 字段则必须存在该字段。否则应该遵从 RFC 1766 中对语言格式的要求。
CONTENT-LENGTH
Required | Body 的大小，单位字节 | Integer
CONTENT-TYPE
Required | 该处的值必须为 text/xml
DATE
Recommended | 该处记录响应生成是的时间，格式遵从 RFC 2616 中定义的 “rfc1123-date” 格式
SERVER
关于请求 description 的响应，不需要此头字段。（我不知道为什么要存在此说明，莫名其妙）
请注意，由于 HTTP 1.1 允许使用分块编码，因此，如果 GET 请求指定 HTTP 1.1， 则某些设备可能会使用分块编码发送描述。
因此，建议所有在 GET 请求中包含 HTTP 1.1的实现都支持接收分块编码。
2.9 Description references>
ISO 8601
ISO (International Organization for Standardization). Representations of dates and times, 1988-06-15.
传送门
RFC 822
Standard for the format of ARPA Internet text messages.
传送门
RFC 1123
Includes format for dates, for, e.g., HTTP DATE header
传送门
RFC 1766
Format for language tag for, e.g., HTTP ACCEPT-LANGUAGE header.
传送门
See also for language codes
传送门.
RFC 2045
Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.
传送门
RFC 2046
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.
传送门
RFC 2083
PNG (Portable Network Graphics) Specification Version 1.0
传送门 和
传送门
RFC 2387
Format for representing content type, e.g., mimetype element for an icon.
传送门
RFC 2396
Uniform Resource Identifiers: Generic Syntax.
传送门
RFC 2616
HTTP: Hypertext Transfer Protocol 1.1.
传送门
UPC
Universal Product Code. 12-digit, all-numeric code that identifies the consumer package. Managed by the Uniform Code
Council.
传送门
XML
Extensible Markup Language.
传送门
XML Schema (Part 1: Structures, Part 2: Datatypes)
Grammar defining UPnP Template Language. 传送门1,
传送门2
3. Control
UPnP™ networking 的第三步就是 Control。该步骤在 addressing, discovery, description 之后，但是该步骤与第四步（eventing）是独立的。
通过控制，控制点通过调用设备描述中的 action 并附带参数来控制。
Control 和 Eventing 是 presentation 的延伸。
给定一个设备和该设备服务的信息，控制点可以向该设备发起请求调用服务的 action，并接受服务执行动作的响应。
调用的方式是通过 RPC 的方式实现的，控制点向服务点发送请求控制数据，服务点接收控制命令，并且返回成功或者失败的结果给控制点
如何控制设备？在设备的 description 中有个 controlURL 元素，该元素的值即为服务器地址，
控制点向这个地址发送合适的请求，即可实现对设备的控制。
控制点的动作会最终影响设备的运行时状态。
当这些状态改变，设备应该将这些状态发送给感兴趣（之前订阅过）的控制点。
这个章节将会介绍发起控制的消息格式，响应格式。
Eventing 章节将会介绍 event 相关的信息。
委员会和供应商会定义一些 actions 的状态, 以允许控制点确定设备的当前值的动作。
与 action 的调用类似，控制点需要发送一个定义好的请求。服务收到该请求之后，
服务需要将请求的状态变量，以及变量的值返回给控制点。
每个服务需要负责保持其状态表的一致性，以便控制点在轮询时查到的值是有意义的。
事件部分介绍了变量值的自动通知。
只要设备 discovery 时广播的消息没有过期，那么控制点即可认为广播的服务是可用的。
如果设备取消了广播，控制点必须认定之前广播的设备和服务不可用了。
UPnP 的控制消息和响应的负载应该是 UTF-8 编码的。
尽管 UDA 确实定义了一套方法来调用动作并轮询值，
但 UDA 并未指定或约束针对在控制点上运行的应用程序的 API 设计；
操作系统供应商可以创建适合其客户需求的API。
如果有很大的一部分数据需要随 action 一起传输（特别是事先不知道数据的大小），
则不建议将数据作为 SOAP 参数的一部分或者作为 MIME 附件发送，
相反的应该采用 out-of-band 的方式传输。
例如，你可以在 argument 中包含一个 URL。
控制点可以通过该 URL 去GET / PUT /POST 获取目标数据。
如果事先不知道数据量，则可以使用 HTTP chunked encoding。
在接下来的章节将对 Control Msg 的格式进行详细解释。
3.1 Control: Protocols
为了执行动作或者获取状态，控制点需要用到下面的这个 UPNP 协议栈。
（ UPnP 的完整协议栈在本文档开头有说明）
在协议栈最上层，控制信息包含了供应商（vendor）的一些信息（比如：参数值）。
接下来供应商的 Content 由 UPnP 委员会补充（如：action 的名字，argument 的名字，variable 的名字）。
以上各层的消息都由 UPnP-specific protocols 承载，协议定义在本文档中。
因此，上述消息使用简单对象访问协议（SOAP）标头和主体元素进行格式化，
并且这些消息是通过基于 IP/TCP 上的 HTTP 传递。
作为参考，上面[方括号]中的颜色表示在下面列出的订阅消息中哪个协议定义了特定的标头元素。
3.2 Control: Action
控制点调用服务 action, 服务返回操作结果或者错误，都采用 SOAP 封包的形式进行通信（传输协议是 HTTP ）。
3.2.1 Control: Action: Invoke
简单对象访问协议（SOAP）定义了利用 XML 和 HTTP 实现远程过程调用的一组规范。
UDA 使用 SOAP 将控制消息传递到设备，并将结果或错误返回给控制点。
SOAP 定义了其他 HTTP 标头，并且为了确保它们不会与其他 HTTP 扩展名混淆，
SOAP 遵循 HTTP 扩展框架（RFC 2774），并在 MAN 标头中指定 SOAP 唯一 URI，并以 M- 作为 HTTP 方法的前缀。
在这里，方法为 M-POST。 使用 M-POST 要求 HTTP 服务器查找和理解 SOAP 唯一 URI 和特定于 SOAP 的标头。
为了向防火墙和代理提供更大的管理灵活性，SOAP 指定必须首先尝试不使用 MAN 头或 M- 前缀的请求。
如果请求的响应为 “405不允许的方法” 而被拒绝，则必须使用 MAN 头和 M 前缀发送第二个请求。
如果该请求以 “未实现501” 或 “未扩展510” 的响应被拒绝，
则该请求将失败。 （其他HTTP响应应根据HTTP规范进行处理。）
下面是使用 POST 方法发送的控制消息的列表（不带 MAN 头），后面是头和主体的说明。
紧随其后的是使用 M-POST 方法和 MAN 标头发送的控制消息列表。
要调用设备服务上的操作，控制点必须使用以下格式的POST方法发送请求。 斜体值是实际值的占位符。
下面列出的是上面列表中出现的请求行，标题和正文元素的详细说明。
所有标头值和元素名称均区分大小写，值不区分大小写，除非另有说明。
元素的顺序无关紧要，除非另有说明。
必需元素必须仅出现一次（没有重复），推荐或可选元素最多只能出现一次，除非另有说明。
Request line
POST
HTTP method.
path control url
组件 URL 路径，用于控制此服务（设备描述的 service 元素的 controlURL 子元素）。| single URL
HTTP/1.1
HTTP/1.1 版本。
headers
HOST
Required |
URL 的域名或 IP 地址以及用于控制此服务的 URL 的可选端口组件（设备描述的 service 元素的 controlURL 子元素）。
如果端口为空或未指定，则假定端口为 80。
ACCEPT-LANGUAGE
(该控制消息无 ACCEPT-LANGUAGE 头)
CONTENT-LENGTH
Required | Body 的大小，单位字节 | Integer
CONTENT-TYPE
Required | 必须为 text/xml， 指明 Body 采用的字符编码，这里必须为 “uft-8”。
MAN
(POST 请求无此字段， M-POST 请求则需要附带此字段)
SOAPACTION
Required | SOAP 定义的此标头 | 必须是服务类型 | Hash mark | 所有的名称都应该用双引号引起来。
如果是使用 M-POST 方法，
HTTP 头中必须有 MAN 头。
| Single URI
| 必须指定控制服务的版本，这里方便服务识别当前控制点可支持的版本。
其值可以是定义了指定操作的服务类型的任何版本。
body
Envelope
Required | 由 SOAP 定义的元素
| xmlns 属性的值必须为 http://schemas.xmlsoap.org/soap/envelope/.
| encodingStyle 属性的值必须为 http://schemas.xmlsoap.org/soap/encoding/
| 该元素包含以下子元素：
Body
Required | 由 SOAP 定义
| 应该符合 SOAP 的命名空间，该元素包含以下子元素：
actionName
Required | 元素的名字为被调用 action 的名字，
xmlns 的属性值必须为服务类型，用双引号包含起来，
这里指定的版本号必须与 SOAPACTION 中的版本号一致。
该元素的值大小写铭感。
该元素标签必须为 Body 的第一个标签，该元素标签包含如下子元素。
argumentName
如果 action 拥有参数，那么此元素必须存在，
每一个参数（argument） 需要实现一次（元素的名称不受命名空间的限制，元素名称符合上下文即可），
| 区分大小写 | 该元素的值必须是符合 UPnP 服务描述中定义的数据类型和数据范围
| 顺序也必须按照 SCPD 中指定的顺序（该处的顺序服从 description spec 中 in 的排列顺序），
如果 CONTENT-TYPE 是不支持的值（不是'text/xml'）, 那么设备必须返回一下 HTTP 错误状态码（“415 Unsupported Media Type”）。
为了将来的可扩展性，当像上面的清单那样处理 XML 时，设备控制点必须忽略它不认识的元素，子元素，内容，属性，值。
设备和控制点应该忽略任何有可能受到的但是不认识的 XML 注释或者 XML 的处理说明。
XML 命名空间前缀不必是上面给出的特定示例（例如，“ s”或“ u”）；
它们可以是任何遵循常规 XML 命名空间机制规则的值；
设备必须接受使用其他合法 XML 命名空间前缀的请求。
如果一个 action 没有 'in' 参数，那么你可以用 combine the opening and closing XML tags 表示。
(比如： 可以用“
当一个参数的值中包含保留符号时（如 ‘&’ / ’<‘），必须按照 XML 规范第 2.4 节的规定对文本进行转义，
并用等效的数字表示形式或字符串（例如 ‘&’ 或 ‘<'）替换每个此类字符。
出现在 URL 中的此类字符也可以根据 RFC 2396 的 2.4 节中指定的 URL 转义规则进行转义。
请注意，由于 HTTP 1.1 允许使用分块编码，因此，如果 POST 方法标头指定 HTTP 1.1，
则某些控制点可能会使用分块编码发送操作请求。
不支持使用分块编码接收操作请求的设备实现应返回 505 HTTP Version Not Supported 错误。
如果带有 POST 请求的响应为 405 Method Not Allowed 被拒绝，
则控制点必须以以下格式发送带有方法 M-POST 和 MAN 的第二个请求。
斜体值是实际值的占位符。
(Message body for request with method M-POST is the same as body for request with method POST. See above.)
Request Line
M-POST
HTTP 可扩展框架定义的方法 (RFC 2774)
path control url
组件 URL 路径，用于控制此服务（设备描述的 service 元素的 controlURL 子元素）。| single URL
HTTP/1.1
HTTP/1.1 版本。
Headers
HOST
Required |
URL 的域名或 IP 地址以及用于控制此服务的 URL 的可选端口组件（设备描述的 service 元素的 controlURL 子元素）。
如果端口为空或未指定，则假定端口为 80。
ACCEPT-LANGUAGE
(该控制消息无 ACCEPT-LANGUAGE 头)
CONTENT-LENGTH
Required | Body 的大小，单位字节 | Integer
CONTENT-TYPE
Required | 必须为 text/xml， 指明 Body 采用的字符编码，这里必须为 “uft-8”。
MAN
Required | 此处的值必须是 "http://schemas.xmlsoap.org/soap/envelope/"。
ns 则定义了为其他字段（如：SOAPACTION）定义了命名空间（ namespace)（如 01）
SOAPACTION
Required | SOAP 定义的此标头 | 必须是服务类型 | Hash mark | 所有的名称都应该用双引号引起来。
如果是使用 M-POST 方法，
HTTP 头中必须有 MAN 头。
| Single URI
| 必须指定控制服务的版本，这里方便服务识别当前控制点可支持的版本。
其值可以是定义了指定操作的服务类型的任何版本。
3.2.2 Control: Action: Response
服务必须在 30s 内完成请求的操作，并做出响应，这里的 30s 包括预期的传输时间（从传输操作消息的时间到接收到相关响应的时间测得的时间）。
应该定义的完成操作时间的时间比 30s 要短，以便尽早返回响应。
如果服务在此时间内无法响应，则控制点应执行的操作取决于应用程序交互设计。
服务必须以以下格式发送响应。 斜体值是实际值的占位符。
下面将对 response line / headers / body elements 作详细解释。
所有头（ header ）的值和元素（ element ）的名称均区分大小写；
除非特殊申明，所有值都不区分大小写；
除非特殊申明，所有的元素的顺序都是无关紧要的。
除非另有说明，否则必需元素必须仅出现一次（没有重复），推荐或可选元素当且仅当出现一次。
Response line
HTTP/1.1
HTTP version
200 OK
HTTP success code
Headers
CONTENT-LANGUAGE
(控制消息中无此头)
CONTENT-LENGTH
Required | Body 的大小，单位字节 | Integer
CONTENT-TYPE
Required | 必须为 text/xml， 指明 Body 采用的字符编码，这里必须为 “uft-8”。
DATE
Recommended | 该处的时间为响应生成时的时间，时间格式为 “rfc1123-date”， 此格式定义于 RFC 2616.
EXT
Required. 确认 MAN 中指定的请求类型是可被识别的 | 此处只有头，无值
SERVER
Required | 此处并列如下参数，操作系统名称和操作系统版本，此两个值用 / 充当分割符，
UPnP的版本，以及产品的名称和产品的版本。其中操作系统信息，UPnP 信息，和产品信息之间用空格充当分割符。| String
| 必须准确反映设备支持的 UPnP 设备体系结构的版本号。
| 控制点必须准备好接受比控制点本身实现的更高的次要版本号（但主版本号相同）。
例如，实现 UDA 版本 1.0 的控制点应当能够能够与实现 UDA 版本 1.1 的设备进行互操作。
Body
Envelope
Required | 由 SOAP 定义的元素
| xmlns 属性的值必须为 http://schemas.xmlsoap.org/soap/envelope/.
| encodingStyle 属性的值必须为 http://schemas.xmlsoap.org/soap/encoding/
| 该元素包含以下子元素：
Body
Required | 由 SOAP 定义
| 应该符合 SOAP 的命名空间，该元素包含以下子元素：
指明
Required | 该元素的名称对应请求操作的 action 的名称，
xmlns 属性的值必须使用双引号引起 | 而这里的 Version 也必须与请求头中 SOAPACTION 指定的 version 相同
| 大小写敏感 | 而且必须是 Body 元素中的第一个子元素 | 此元素包含一下子元素：
argumentName
Required | 当且仅当 action 拥有 out 参数的时候才拥有此字段， 这里的值即填写 action 执行之后的。
| 每一个 out 参数只允许出现一次
| 如果 action 有一个标记为 retval 的参数，则此参数必须是第一个元素。
（元素名称不受名称空间限制，符合上下文语义即可）
| 区分大小写。 UPnP服务描述所定义的单一数据类型
| 参数出现的顺序必须与设备可用的服务描述（SCPD）中指定的顺序相同
为了将来的可扩展性，当像上面的清单那样处理，设备和控制点必须忽略自己不认识的元素或者子元素，和任何认识的属性和该属性的值。
所有的控制点和设备应该忽略 XML 的注释或者他们看不懂的 XML 的流程说明。
XML 命名空间的前缀不必是上面给出的特定示例（例如，“ s”或“ u”）， 它们可以是任何遵循常规 XML 命名空间规则的值， 控制点必须接受使用其他合法 XML 命名空间前缀的响应。
如果一个 action 没有一个 out 参数，那么该参数使用单闭合标签是有效的。
(如： 可以用 “
当任何参数的值包含一个或多个保留为标记的字符（例如，“＆”或小于（“<”））时，
必须根据 XML 规范 2.4 节的规定对文本进行转义。
并用等效的数字表示形式或字符串替换每个此类字符（例如 “&”或“<”）。
出现在 URL 中的此类字符也可以根据 RFC 2396 第 2.4 节中指定的URL转义规则进行转义。
如果控制点使用 HTTP/1.0 承载 SOAP 协议，但是没有携带 KeepAlive 头，
设备必须在响应结束之后关闭通信 socket。
如果控制点使用 HTTP/1.1 承载 SOAP 协议，而且设置 Connection: CLOSE,
那么设备必须在������之后关闭通信 socket。
请注意，由于 HTTP 1.1 允许使用分块编码，
因此，如果 POST 请求指定 HTTP 1.1，
则某些设备可能会使用分块编码来发送操作响应。
因此，建议在 POST 请求中包括 HTTP 1.1 的所有实现都支持接收分块编码。
如果服务在调用控制点发送的操作时遇到错误，
则该服务必须在 30 秒内发送响应(包括预期的传输时间)。
注意 out 参数不能用于传达错误信息， out 参数只能用于返回数据。
错误响应必须以以下格式发送。 斜体值是实际值的占位符。
下面列出的是上面列表中出现的 response line / Headers 和 Body 的详细信息。
所有头（ header ）的值和元素（ element ）的名称均区分大小写；
除非特殊申明，所有值都不区分大小写；
除非特殊申明，所有的元素的顺序都是无关紧要的。
除非另有说明，否则必需元素必须仅出现一次（没有重复），推荐或可选元素当且仅当出现一次。
Response line
HTTP/1.1
HTTP version
500 Internal Server Error
HTTP error code
Headers
CONTENT-LANGUAGE
(无此头字段)（PS: 不清楚卫生么要这样提示，我理解应该是如果请求中包含 ACCEPT-LANGRAGE，
而且当前控制参数的确包含本地化的一些值，则这里会出现该字段）
CONTENT-LENGTH
Required | Body 的大小，单位字节 | Integer
CONTENT-TYPE
Required | 必须为 text/xml， 指明 Body 采用的字符编码，这里必须为 “uft-8”。
DATE
Recommended | 该处的时间为响应生成时的时间，时间格式为 “rfc1123-date”， 此格式定义于 RFC 2616.
EXT
Required. 确认 MAN 中指定的请求类型是可被识别的 | 此处只有头，无值
SERVER
Required | 此处并列如下参数，操作系统名称和操作系统版本，此两个值用 / 充当分割符，
UPnP的版本，以及产品的名称和产品的版本。其中操作系统信息，UPnP 信息，和产品信息之间用空格充当分割符。| String
| 必须准确反映设备支持的 UPnP 设备体系结构的版本号。
| 控制点必须准备好接受比控制点本身实现的更高的次要版本号（但主版本号相同）。
例如，实现 UDA 版本 1.0 的控制点应当能够能够与实现 UDA 版本 1.1 的设备进行互操作。
Body
Envelope
Required | 由 SOAP 定义的元素
| xmlns 属性的值必须为 http://schemas.xmlsoap.org/soap/envelope/.
| encodingStyle 属性的值必须为 http://schemas.xmlsoap.org/soap/encoding/
| 该元素包含以下子元素：
Body
Required | 由 SOAP 定义
| 应该符合 SOAP 的命名空间，该元素包含以下子元素：
Fault
Required | 由 SOAP 定义
| 当调用 action 失败的时候存在此字段
| 错误的值应该符合 SOAP 定义的命名规则
| 包含以下子元素：
faultCode
Required | 由 SOAP 定义
| 值必须为 ‘Client’
(该处的值应该服从 SOAP 的命名规范)
faultstring
Required | 由 SOAP 定义
| 值必须为 'UPnPError'
detail
Required | 由 SOAP 定义
| 包含以下子元素：
UPnPError
Required | 由 UDA 定义
| 包含以下子元素：
errorCode
Required | 由 UDA 定义
| 这里定义遇到的是哪一种错误
| 请参考下面的表格中的值，以及对应的错误类型
| 整形
errorDescription
UDA 定义的推荐字段，用于简短描述错误类型
| 具体 Code 对应的推荐值参考下表
| 供应商也可以自定义值，但最好设计成是人类可读的
| 此处描述字段值的长度应该 < 256 个字符
下表总结了已定义的错误类型以及 errorCode 和 errorDescription 元素的相应值。
为了将来的可扩展性，当像上面的清单那样处理，设备和控制点必须忽略自己不认识的元素或者子元素，和任何认识的属性和该属性的值。
XML 命名空间前缀不必是上面给出的特定示例（例如，“ s”或“ u”）；
它们可以是任何遵循常规 XML 名称空间机制规则的值；
控制点必须接受使用其他合法 XML 名称空间前缀的响应。
3.3 Control: Query for variable
UPnP 论坛已将 QueryStateVariable action 作废，
除非在有限的测试场景测试出现非期望结果，否则控制点不应该再使用此方法，
委员会和供应商应明确定义查询状态变量所需的功能。
如果需要，这样的显式查询动作可以包括多个状态变量。
UPnP 设备体系结构中保留了 QueryStateVariable 的以下定义，以供参考并与早期实现向后兼容。
除了调用设备服务上的操作外，控制点还可以通过发送查询消息来轮询服务以获取状态变量的值。
查询消息一次只能查询一个状态变量；如果要查询多个，则必须发送多条查询消息。
此查询消息与服务的事件（如果有）是相互独立的。
如果想要对 variable 的值进行检查，查询的次数会远远多余事件发送的次数，
关于事件的部分描述了事件管理。
3.3.1 Control: Query: Invoke
要查询状态变量的值，控制点必须以以下格式发送请求。 斜体值是实际值的占位符。
下面列出的是上面列表中出现的 request line / Headers 和 Body 的详细信息。
所有头（ header ）的值和元素（ element ）的名称均区分大小写；
除非特殊申明，所有值都不区分大小写；
除非特殊申明，所有的元素的顺序都是无关紧要的。
除非另有说明，否则必需元素必须仅出现一次（没有重复），推荐或可选元素当且仅当出现一次。
Request line
POST
HTTP 的请求方法
path of control URL
服务器用于接受控制的服务资源路径
(该路径在设备描述文档的 service 元素的 controlURL 元素下)。 | Single relative URL.
HTTP/1.1
HTTP 版本.
Headers
HOST
Required | 用于发送控制指令的服务器的服务地址（可能是域名也可能是 IP 地址）
（该地址存在与设备描述文档的 service 元素下），
该地址可能会携带端口号，如果没有携带，则默认为是 80 端口。
ACCEPT-LANGUAGE
(Control 消息不需要此头)
CONTENT-LENGTH
Required | Body 的大小，单位字节 | Integer
CONTENT-TYPE
Required | 必须为 text/xml， 指明 Body 采用的字符编码，这里必须为 “uft-8”。
MAN
(POST 请求无此字段， M-POST 请求则需要附带此字段)
SOAPACTION
Required | SOAP 定义的此标头
| 之必须是 urn:schemas-upnp-org:control-1-0#QueryStateVariable
| 如果 HTTP method 使用的是 M-POST, 则头名必须使用 MAN 头中使用的 namespace 来限定
| Single URI
Body
Envelope
Required | 由 SOAP 定义的元素
| xmlns 属性的值必须为 http://schemas.xmlsoap.org/soap/envelope/.
| encodingStyle 属性的值必须为 http://schemas.xmlsoap.org/soap/encoding/
| 该元素包含以下子元素：
Body
Required | 由 SOAP 定义
| 应该符合 SOAP 的命名空间，该元素包含以下子元素：
QueryStateVariable
Required | 由 UPnP 定义，这里填写的即使 Action 的名字，
其中 xmlns 属性的值必须为 urn:schemas-upnp-org:control-1-0,
而且此元素必须是 Body 元素的第一个子元素，
| 包含一下子元素。
varName
Required | 由 UPnP 定义，是 state 变量的名字，该状态必须从属于 QueryStateVariable 的命名空间
| String
为了将来的可扩展性，当按照 Flexible XML Processing Profile（FXPP）的规定处理上述清单中的 XML 时，
设备和控制点必须忽略：（a）任何未知元素及其子元素或内容，以及（b）任何未知元素 属性及其值。
如果带有 POST 的请求被拒绝并返回响应 405 Method Not Allowed，
则控制点必须使用上述方法 M-POST 和 MAN 发送第二个请求。
3.3.2 Control: Query: Response
要回答有关状态变量值的查询，服务必须在 30 秒内响应（此 30 秒包含传输时间），
如果服务在此时间内无法响应，则控制点应执行的操作取决于应用程序。
服务必须以以下格式发送响应。 斜体值是实际值的占位符。
下面列出的是上面列表中出现的 response line / Headers 和 Body 的详细信息。
所有头（ header ）的值和元素（ element ）的名称均区分大小写；
除非特殊申明，所有值都不区分大小写；
除非特殊申明，所有的元素的顺序都是无关紧要的。
除非另有说明，否则必需元素必须仅出现一次（没有重复），推荐或可选元素当且仅当出现一次。
Response line
HTTP/1.1
HTTP version.
200 OK
HTTP success code.
Headers
CONTENT-LANGUAGE
(无此头字段)（PS: 不清楚卫生么要这样提示，我理解应该是如果请求中包含 ACCEPT-LANGRAGE，
而且当前控制参数的确包含本地化的一些值，则这里会出现该字段）
CONTENT-LENGTH
Required | Body 的大小，单位字节 | Integer
CONTENT-TYPE
Required | 必须为 text/xml， 指明 Body 采用的字符编码，这里必须为 “uft-8”。
DATE
Recommended | 该处的时间为响应生成时的时间，时间格式为 “rfc1123-date”， 此格式定义于 RFC 2616.
EXT
Required. 确认 MAN 中指定的请求类型是可被识别的 | 此处只有头，无值
SERVER
Required | 此处并列如下参数，操作系统名称和操作系统版本，此两个值用 / 充当分割符，
UPnP的版本，以及产品的名称和产品的版本。其中操作系统信息，UPnP 信息，和产品信息之间用空格充当分割符。| String
| 必须准确反映设备支持的 UPnP 设备体系结构的版本号。
| 控制点必须准备好接受比控制点本身实现的更高的次要版本号（但主版本号相同）。
例如，实现 UDA 版本 1.0 的控制点应当能够能够与实现 UDA 版本 1.1 的设备进行互操作。
Body
Envelope
Required | 由 SOAP 定义的元素
| xmlns 属性的值必须为 http://schemas.xmlsoap.org/soap/envelope/.
| encodingStyle 属性的值必须为 http://schemas.xmlsoap.org/soap/encoding/
| 该元素包含以下子元素：
Body
Required | 由 SOAP 定义
| 应该符合 SOAP 的命名空间，该元素包含以下子元素：
QueryStateVariableResponse
Required | 由 SOAP 定义
| xmlns 属性的值必须为 urn:schemasupnp-org:control-1-0
| 必须是 Body 元素的第一个元素
| 包含如下子元素：
return
Required | 由 UPnP 定义
| 元素名字 element defined by UPnP.
（元素名称不受名称空间限制；语言符合下文即可。）
此处的值是在请求中的 varName 元素中指定的状态变量的当前值。
为了将来的可扩展性，当按照 Flexible XML Processing Profile（FXPP）的规定处理上述清单中的 XML 时，
设备和控制点必须忽略：（a）任何未知元素及其子元素或内容，以及（b）任何未知元素 属性及其值。
当任何参数的值包含一个或多个保留为标记的字符（例如，“＆”或小于（“<”））时，
必须根据 XML 规范 2.4 节的规定对文本进行转义。
并用等效的数字表示形式或字符串替换每个此类字符（例如 “&”或“<”）。
出现在 URL 中的此类字符也可以根据 RFC 2396 第 2.4 节中指定的URL转义规则进行转义。
如果服务无法为变量提供值，则服务必须在 30 秒内发送响应（该 30s 包含预期的传输时间）。
响应必须以以下格式发送。 斜体值是实际值的占位符。
下面列出的是上面列表中出现的 response line / Headers 和 Body 的详细信息。
所有头（ header ）的值和元素（ element ）的名称均区分大小写；
除非特殊申明，所有值都不区分大小写；
除非特殊申明，所有的元素的顺序都是无关紧要的。
除非另有说明，否则必需元素必须仅出现一次（没有重复），推荐或可选元素当且仅当出现一次。
Response line
HTTP/1.1
HTTP version.
500 Internal Server Error
HTTP error code.
Headers
CONTENT-LANGUAGE
(无此头字段)（PS: 不清楚卫生么要这样提示，我理解应该是如果请求中包含 ACCEPT-LANGRAGE，
而且当前控制参数的确包含本地化的一些值，则这里会出现该字段）
CONTENT-LENGTH
Required | Body 的大小，单位字节 | Integer
CONTENT-TYPE
Required | 必须为 text/xml， 指明 Body 采用的字符编码，这里必须为 “uft-8”。
DATE
Recommended | 该处的时间为响应生成时的时间，时间格式为 “rfc1123-date”， 此格式定义于 RFC 2616.
EXT
Required. 确认 MAN 中指定的请求类型是可被识别的 | 此处只有头，无值
SERVER
Required | 此处并列如下参数，操作系统名称和操作系统版本，此两个值用 / 充当分割符，
UPnP的版本，以及产品的名称和产品的版本。其中操作系统信息，UPnP 信息，和产品信息之间用空格充当分割符。| String
| 必须准确反映设备支持的 UPnP 设备体系结构的版本号。
| 控制点必须准备好接受比控制点本身实现的更高的次要版本号（但主版本号相同）。
例如，实现 UDA 版本 1.0 的控制点应当能够能够与实现 UDA 版本 1.1 的设备进行互操作。
Body
Envelope
Required | 由 SOAP 定义的元素
| xmlns 属性的值必须为 http://schemas.xmlsoap.org/soap/envelope/.
| encodingStyle 属性的值必须为 http://schemas.xmlsoap.org/soap/encoding/
| 该元素包含以下子元素：
Body
Required | 由 SOAP 定义
| 应该符合 SOAP 的命名空间，该元素包含以下字段:
Fault
Required | 由 SOAP 定义. 此标签包含为什么服务没有返回请求变量值的原因。
格式需要服从 SOAP 的命名规范 | 包含以下子元素：
faultcode
Required | 由 SOAP 定义
| 值必须为 ‘Client’
(该处的值应该服从 SOAP 的命名规范)
faultstring
Required | 由 SOAP 定义
| 通用描述 UPnP ErrorCode 的字符串
| 请查看以下表格中的说明
detail
Required | 由 SOAP 定义
| 包含以下子元素：
UPnPError
Required | 由 UPnP 定义
| 包含以下子元素：
errorCode
Required | 由 UPnP 定义
| 定义遭遇何种 Error 的 Code
| 具体的值请查看下表定义
| Integer
errorDescription
Required | 由 UPnP 定义
| 一个解释该错误类型的简短说明
| 请查看以下表格中的说明
| 建议小于 256 个字符
| String
下表总结了 UPnP 定义的常用的 errorCode 和 errorDescription。
如果设备没有实现 QueryStateVariable 指定的 Action, 设备服务应该返回 401 Invalid Action。
为了将来的可扩展性，当像上面的清单那样处理，设备和控制点必须忽略自己不认识的元素或者子元素，和任何认识的属性和该属性的值。
3.4 Control references
RFC 1123
Includes format for dates, for, e.g., HTTP DATE header.
传送门
RFC 2396
Uniform Resource Identifiers: Generic Syntax
传送门
RFC 2616
HTTP: Hypertext Transfer Protocol 1.1
传送门
RFC 2774
HTTP Extension Framework.
传送门
SOAP
Simple Object Access Protocol.
传送门
XML
Extensible Markup Language.
传送门
4. Eventing
Eventing 是 UPnP™ networking 的第四步，通过 Eventing 控制点监听设备的变化。
Control 和 Eventing 作为设备的控制和展示借口，相当于 presntation (第五步)的外延。
在控制点 discovery 和获取设备 description 之后，控制点知道了设备包含的设备和服务信息。
正如 Description 那节描述的那样，UPnP 服务描述包括服务的 action 列表和运行时服务状态变量列表。
如果这些状态变量中的一个或多个发生了事件，则服务在这些变量更改时发布更新，
并且控制点可以订阅以接收此信息。 在本节中， Publisher 指事件的源（通常是设备的服务），
而订户指事件的目的地（通常是控制点）。
为了订阅事件，订阅者发送订阅消息。
如果订阅被接受，则设备需要返回一个有效期给订阅者。
为了使订阅保持活动状态，订阅者必须在订阅到期之前对其订阅进行续订。
当订阅者不再需要来自 Publisher 的事件时，订阅者应取消其订阅。
本节在下面详细说明了订阅，续订和取消消息。
Publisher 通过发送事件消息来通知状态变量的更改。
事件消息包含一个或多个状态变量的名称以及这些变量的当前值，以 XML 表示。
当订户第一次订阅时，会发送一个特殊的初始事件消息。
该事件消息包含所有事件变量的名称和值，并允许订户初始化其服务状态模型。
为了支持具有多个控制点的方案，可以使用事件来使感兴趣的控制点及时的知晓设备（服务）的状态变更（即便这个变更是由其他控制点影响的）。
当设备（服务）的状态变更，应该向所有订阅者发送所有事件消息，所有的订阅者也应该接收所有的 event,
并且无论状态变量为何更改（不管是因为响应 action 的请求导致的或因为服务因自身原因导致的）都发送事件消息更改。
本节将在下面详细说明事件消息的格式。
一些状态变量可能变化的速度很快，以至于事件并不能及时的将这些变化发出，
一个可选的做法是，如果来不及报告，那么就过滤或者平滑的处理掉中间变化的状态变量，
只报告最后的状态即可。
有些状态可能包含的数值太大或者 size 太大，而以至于订阅者无法识别（使用），针对这种情况，
由于这个原因或其他原因，服务可以将一个或多个状态变量指定为 non-event， 并且不将该事件消息发送给订户即可。
为了确定此类设置为 non-event 变量的当前值，控制点必须显式轮询，当然前提是假定设备（服务）提供了接口来获取状态变量的值。
本节说明如何在服务描述中描述变量事件。
为了发送或者接受事件的消息，控制点和服务必须 following 完整 UPnP 协议栈的子集。
（完整的 UPnP 协议栈在本文最开始已经说明了）。
在协议最上层，订阅和事件消息包含供应商特有的消息，例如订阅的 URL / 订阅的持续时间 / 特定的变量值。
在协议栈中向下移动，供应商内容将由 UPnP 委员会提供的信息进行补充，例如服务标识符或变量名。
来自以上各层的消息用本文档中定义的 UPnP 的协议承载。
而 UPnP 消息由通过 HTTP 或者扩展了 HTTP 头的 HTTP 协议承载。
作为参考，图片中[方括号]中的颜色表示在下面列出的订阅消息中哪个协议定义了特定的标头元素。
在本章剩下的内容中，首先会解释说明订阅相关的内容，
包括详细的订阅消息，刷新消息，取消订阅等操作。
其次，还会介绍 eventing 消息的格式，和如何发送给控制点。
最后，将会介绍 eventing 的 the UPnP Template Language。
4.1 Eventing: Subscription
当且仅当它拥有一个或一个以上的状态变量在服务描述文档中被标记为可被 event 时，一个服务拥才有 event 事件，
如果一个服务拥有 event 时间， 它将会发送该时间给感兴趣的订阅者。
Publisher 拥有一个 Subscriber 列表，而且保存这每一个 Subscriber 的如下信息：
unique subscription identifier
Required | 在订阅的整个生命周期内此 ID 必须是唯一的，但是对长度并没有做要求。
由 Publisher 生成并在响应订阅请求时发送给 Subscriber 。
推荐使用 universally-unique identifiers （ 参考 RFC4122 ） 来保证唯一性 | Single URI
delivery URL for event messages
Required | 由 Subscriber 在请求订阅的消息中提供 | Single URL
event key
Required | 订阅初始的时候值为 0。 Key 必须是序列增长的，即每发送一个 event, Key 应该自增 1。
Subscriber 接收到排序好的 key 之后即可知道自己丢失了哪些 event 消息。
当 Key 增长到 4294967295 之后在增加的 event， key 应该变成 1 (32-bit 无符号整形最大值).
有些实现可能包括了 0, 遇到 0 的 key 应该将之忽略。
subscription duration
Required | 订阅到期之前的时间或持续时间。 单个整数或关键字“ infinite”。
Publisher 应接受尽可能多的管理 / 维护 / 交付订阅。
Publisher 可能希望在电源故障时保留订阅。
虽然控制点可以从完全的网络故障中恢复，但是如果问题很简单并且已定位到设备，
则重新使用存储的订阅可能会加快恢复速度。
订户列表的更新是和订阅动作（subscription, renewal, and cancellation）相关的，
为了订阅服务的事件，订阅者发送订阅消息，该消息包含 Publisher 的 URL，
Publisher 的服务标识符以及 Subscriber 接收事件消息的 URL。
订阅消息还可以包括所请求的订阅持续时间。
Publisher 的 URL 和服务标识符来自描述消息。
如 “描述” 部分中所述，描述消息包含设备描述。
设备描述包含（除其他事项外）每个服务的事件 URL（在 eventSubURL 元素中）和服务标识符（在 serviceId 元素中）；
它们分别对应于 Publisher 的 URL 和服务标识符。
Publisher 的网址对于该设备中的特定服务必须是唯一的。
订阅请求发出，即代表订阅该 URL 下的所有事件，没有提供任何机制来可变地订阅事件消息。
向订户发送该服务的所有事件消息。 这是设计服务时要考虑的一个因素。
如果订阅请求被接受，则 Publisher 应该立即做出响应，响应的内容包括该订阅的 UUID 和该订阅的有效期。
有效期的选择应该考虑到控制点从该网络中移除的频率，如果控制点每隔几分钟就会从网络中离开，
那么过期时间就应该设置得比较短，以保证 Publiser 能更快的处理过期的 Subscriber;
如果控制点几乎是永久性的存在网络中，则订阅时间应该设置得非常长，
以减小因为经常的刷新订阅信息而造成网络拥塞。
订阅被接受后，Publisher 首先应该发送第一个 event, 该 event 包含当前服务的基础状态，好让 Subscriber 对当前设备有一个基本的了解。
该消息包括当前可被 event 状态变量的名字，以及搜索状态变量的值(状态变量的值和范围之前已经在 description 文档中有说明)。
即使控制点在传递之前取消订阅，该消息也始终会发送出去。
设备必须在发送初始事件消息之前确保控制点已收到对订阅请求的响应，以确保控制点已接收到 SID（订阅ID），从而可以将事件消息与订阅相关联。
为了保持订阅的在线状态，Subscriber 必须在订阅过期前 发送 renewal 消息执行 renew 操作，
renewal 消息需要发送到和订阅消息相同的 URL,
但是 renewal 消息并不需要包括 Subscriber 接受 event 的 URL；
相反的 renewal 消息应该包含之前订阅的时响应的 UUID。
Publisher 返回给 renewal 消息的响应和订阅时的响应一样。
如果订阅过期了，这个订阅的 UUID 以及对应的信息都将变得无效，
Publisher 应该停止向该 Subscriber 发送 event，并且可以将该 Subscriber 的信息从定户列表中清除。
如果定于试图发送除订阅消息的其他消息给服务，那么 Publisher 应该拒绝该 Subscriber 的所有请求。
当 Subscriber 不再需要来自特定服务的事件时，订户应取消其订阅。
取消订阅通常会减少服务，控制点和网络负载。
如果将订户突然从网络中删除，则可能无法发送取消消息。 作为后备，除非最终续订，否则订阅最终将自行失效。
Subscriber 应监视来自 Publisher 的发现消息。 如果 Publisher 取消其设备和服务的广播，
则订阅者应假定其订阅已被有效取消。
以下是对订阅，续订和取消消息的请求，响应和错误的特定格式的说明。
4.1.1 Eventing: Subscribing: SUBSCRIBE with NT and CALLBACK
对于设备中的每个服务，描述消息均包含事件 URL（设备描述中 service 元素的 eventSubURL 子元素）和 UPnP 服务标识符（设备描述中 service 元素中的 serviceId 子元素）。
为了订阅特定服务的事件，将订阅消息发送到该服务的事件 URL。
（请注意，事件 URL 可能是相对于 Base URL 的）。
消息包含该服务的标识符以及事件消息的传递 URL。 订阅消息还可以包括请求的订阅过期时间（时间段）。
要订阅服务事件，订阅者必须使用以下格式发送带有方法 SUBSCRIBE 以及 NT 和 CALLBACK 标头的请求。
斜体值是实际值的占位符。
SUBSCRIBER 方法的请求没有负载（body）部分，但是在头部后了空行一定不能少。（结尾是两个 \r\n）
下面的列表详细描述了上图中出现的请求的 request line / headers 字段. 除非特殊申明，所有的头的值都是大小写敏感的。
Request line
SUBSCRIBE
订阅和刷新订阅的 HTTP Method.
publisher path
订阅事件 URL 中的资源路径，（该 URL 在设备描述文档中 eventSubURL 子元素中提供 ） | Single, relative URL.
HTTP/1.1
HTTP version
Headers
HOST
Required | 订阅事件的域名或者 IP 地址，端口信息是可选标注的
( 该 URL 在 device 描述文档中的 eventSubURL 元素有提及)。
如果端口号未指定则默认为是 80 端口。
CALLBACK
Required | 接受订阅事件的服务器 location ( URL ),
如果 CALLBACK 中包含了多个 URL，那么在发送事件的时候，Publisher 会按照顺序一个一个尝试，直到有一个成功。
每个 URL 用 '<' 和 ‘>’ 包围。
每一个 URL 应该指定的是 HTTP/TCP 的服务器（URL 前缀为 'http://'）。
设备不得以任何方式截断此 URL；
如果没有足够的内存来存储整个 CALLBACK URL，则设备必须拒绝订阅。
NT
Required | Notification 类型, 值必须是 upnp:event。
SID
（此订阅请求，无 SID 标头）
TIMEOUT
Recommended | 此订阅消息失效的时间间隔，值微微 infinite 或者数妙。
UPnP 委员会的建议。
由 UPnP 供应商定义。
格式由关键字 “Second-” 组成，后跟（无中间空格）是整数或关键字 “infinite”。
如果有足够的资源支持新的定户，Publisher 就应该接受新定户的请求。
为了接受新的请求， Publisher 应该为该请求生成一个唯一码，分配一个订阅的有效时间。
并发送初始事件消息（本节稍后将详细说明）。
要接受订阅请求，发布者必须在 30 秒内（包括传输时间）以以下格式发送响应。
斜体值是实际值的占位符。
SUBSCRIBER 方法的请求没有负载（body）部分，但是在头部后了空行一定不能少。（结尾是两个 \r\n）
如果设备发送的响应基于 HTTP/1.0 但是有 KeepAlive 头， 或者是基于 HTTP/1.1 但是没有 Connection: CLose 头，
那么设备必须保证在发送初始化事件之前先发送 TCP FIN Flag。
在其他的情况下（除非响应使用了 HTTP Chunk 功能），必须在发送初始事件之前指定 Content-Length（并将其设置为0）。
下面的列表详细描述了上图中出现的请求的 request line / headers 字段. 除非特殊申明，所有的头的值都是大小写敏感的。
Headers
DATE
Recommended | 该时间为响应生成时的时间，服从 RFC 2616 定义的 “rfc1123-date” 格式。
SERVER
Required | 此处并列如下参数，操作系统名称和操作系统版本，此两个值用 / 充当分割符，
UPnP的版本，以及产品的名称和产品的版本。其中操作系统信息，UPnP 信息，和产品信息之间用空格充当分割符。| String
| 必须准确反映设备支持的 UPnP 设备体系结构的版本号。
| 控制点必须准备好接受比控制点本身实现的更高的次要版本号（但主版本号相同）。
例如，实现 UDA 版本 1.0 的控制点应当能够能够与实现 UDA 版本 1.1 的设备进行互操作。
SID
Required | 为该订阅生成的 UUID. 必须是全局唯一的， 而且必须以 uuid: 作为前缀。
由 UPnP 供应商定义。Single URI.
TIMEOUT
Recommended | 此订阅消息失效的时间间隔，值微微 infinite 或者数妙。
UPnP 委员会的建议。
由 UPnP 供应商定义，该值应该大于或者等于 1800 秒。
格式由关键字 “Second-” 组成，后跟（无中间空格）是整数或关键字 “infinite”。
如果 Publisher 不能接受订阅，或者在订阅请求消息中检查到了错误，Publisher 必须发送一个响应同志定户，错误信息如下。
响应消息必须在 30s 内发送出去（该时间包含消息传输时间）。
Errors
Incompatible headers
400 Bad Request | 如果存在 SID 标头以及 NT 或 CALLBACK 标头之一，
则发布者必须发送 400 Bad Request 错误消息。
Missing or invalid CALLBACK
412 Precondition Failed
| 如果 CALLBACK 标头丢失或不包含有效的 HTTP URL，则发布者必须以 HTTP 错误 412 Precondition Failed 进行响应。
Invalid NT
412 Precondition Failed
| 如果 NT 标头不等于 upnp:event , 则发布者必须响应 412 Precondition Failed 错误消息。
Unable to accept subscription
5xx
| 如果发布者无法接受订阅（例如由于资源不足），则它必须以 HTTP 500 系列错误代码响应。
UPnP 协议底层协议栈中的层可能会返回其他错误。 有关详细信息，请查阅这些协议的文档。
4.1.2 Eventing: Renewing a subscription: SUBSCRIBE with SID
为了刷新订阅的状态，Subscriber 应当发送 renew 消息到订阅事件的 URL。
与初始订阅消息不同，续订消息既不包含服务的标识符也不包含事件消息的传递 URL。
而是，该消息包含由发布者分配的订阅标识符，从而提供对要更新的订阅的明确引用。
像订阅消息一样，续订消息也可以包括请求的订阅持续时间。
续订消息的请求方法和订阅消息的请求方法一致，只是两个消息包含的头集合不一样。
续订消息使用 SID，而订阅消息使用 NT 和 CALLBACK。
一个既包含 SID,又包含 NT 和 CALLBACK 的消息是错误的。
为了续订服务的事件， Subscriber 应该发送以下格式请求到订阅服务的 URL,
斜体值是实际值的占位符。
SUBSCRIBER 方法的请求没有负载（body）部分，但是在头部后了空行一定不能少。（结尾是两个 \r\n）
下面的列表详细描述了上图中出现的请求的 request line / headers 字段. 除非特殊申明，所有的头的值都是大小写敏感的。
Request line
SUBSCRIBE
订阅和刷新订阅的 HTTP Method.
publisher path
订阅事件 URL 中的资源路径，（该 URL 在设备描述文档中 eventSubURL 子元素中提供 ） | Single, relative URL.
HTTP/1.1
HTTP version
Headers
HOST
Required | 订阅事件的域名或者 IP 地址，端口信息是可选标注的
( 该 URL 在 device 描述文档中的 eventSubURL 元素有提及)。
如果端口号未指定则默认为是 80 端口。
CALLBACK
(续订消息中无此头)
NT
(续订消息中无此头)
SID
Required | 由 Publisher 之前分配个定户的 SID，
必须是全局唯一的，而且值必须以 uuid: 开头，由 UPnP 供应商定义 | Single URI
TIMEOUT
Recommended | 此订阅消息失效的时间间隔，值微微 infinite 或者数妙。
UPnP 委员会的建议。
由 UPnP 供应商定义。
格式由关键字 “Second-” 组成，后跟（无中间空格）是整数或关键字 “infinite”。
要接受续订，发布者会重新分配订阅期限，并且必须以与新订阅请求相同的格式和条件发送响应，但不需要再次发送初始事件消息。
如果发布者不能接受续订，或者续订请求有错误，则发布者必须发送带有以下错误之一的响应。 响应必须在 30s 内发送(包括预期的传输时间)。
Errors
Incompatible headers
400 Bad Request | 如果存在 SID 标头以及 NT 或 CALLBACK 标头之一，
则发布者必须发送 400 Bad Request 错误消息。
Invalid SID
412 Precondition Failed
| 如果 SID 其值未可知，或者该订阅已过期，则 Publisher 必须响应 412 Precondition Failed 错误信息。
Missing SID
412 Precondition Failed
| 如果 SID 缺失，或者为空，则 Publisher 必须响应 412 Precondition Failed 错误信息。
Unable to accept renewal
5xx
| 如果发布者无法接受续订（例如由于资源不足），则它必须以 HTTP 500 系列错误代码响应。
UPnP 协议底层协议栈中的层可能会返回其他错误。 有关详细信息，请查阅这些协议的文档。
4.1.3 Eventing: Canceling a subscription: UNSUBSCRIBE
当不再需要订阅服务的事件时，应将取消订阅的消息发送到该服务的事件 URL（请注意，事件 URL 可能是基于 Base URL 的），
该消息中包含由 Publisher 分配的 SID，
取消订阅通常会减少服务，控制点和网络负载。
如果将控制点突然从网络中删除，则可能无法发送取消订阅消息。
作为后备，除非最终续订，否则订阅最终将自行失效。
若要取消对服务事件的订阅，订阅者应使用以下格式的 UNSUBSCRIBE 方法发送请求。
斜体值是实际值的占位符。
UNSUBSCRIBE 方法的请求没有负载（body）部分，但是在头部后了空行一定不能少。（结尾是两个 \r\n）
下面的列表详细描述了上图中出现的请求的 request line / headers 字段. 除非特殊申明，所有的头的值都是大小写敏感的。
Request line
UNSUBSCRIBE
取消订阅的 HTTP Method.
publisher path
订阅事件 URL 中的资源路径，（该 URL 在设备描述文档中 eventSubURL 子元素中提供 ） | Single, relative URL.
HTTP/1.1
HTTP version
Headers
HOST
Required | 订阅事件的域名或者 IP 地址，端口信息是可选标注的
( 该 URL 在 device 描述文档中的 eventSubURL 元素有提及)。
如果端口号未指定则默认为是 80 端口。
CALLBACK
( UNSUBSCRIBE 方法没有 CALLBACK 头 )
NT
( UNSUBSCRIBE 方法没有 NT 头 )
SID
Required | 由 Publisher 之前分配个定户的 SID，
必须是全局唯一的，而且值必须以 uuid: 开头，由 UPnP 供应商定义 | Single URI
TIMEOUT
( UNSUBSCRIBE 方法没有 TIMEOUT 头 )
为了取消订阅，Publisher 必须在 30s 内发送如下的响应消息（改 30s 包括传输时间），
HTTP/1.1 200 OK
如果在取消订阅的时候发生了错误，Publisher 必须发送如下的错误信息给定户。 该消息必须在 30s 内发送如下的响应消息（改 30s 包括传输时间），
Errors
Incompatible headers 400 Bad Request | 如果存在 SID 标头以及 NT 或 CALLBACK 标头之一， 则发布者必须发送 400 Bad Request 错误消息。
Invalid SID 412 Precondition Failed | 如果 SID 其值未可知，或者该订阅已过期，则 Publisher 必须响应 412 Precondition Failed 错误信息。
Missing SID 412 Precondition Failed | 如果 SID 缺失，或者为空，则 Publisher 必须响应 412 Precondition Failed 错误信息。
UPnP 协议底层协议栈中的层可能会返回其他错误。 有关详细信息，请查阅这些协议的文档。
4.2 Eventing: Event messages
服务通过发送事件消息来发布对其状态变量的更改。 这些消息包含一个或多个状态变量的名称以及这些变量的当前值。 事件消息应尽快发送给订户，以使定户能及时的获取有关该服务的精准信息，并使订户能及时的响应到用户界面。 如果同时更改多个变量的值，则发布者应将这些更改捆绑到单个事件消息中，以减少处理和网络流量。
如上所述，初始事件消息是在订户首次订阅时发送的； 该事件消息包含所有事件变量的名称和值，并允许订户初始化其服务状态模型。 发布者接受订阅后，应尽快发送此消息。 即使控制点在传递消息之前取消订阅，也应始终发送此消息。
事件消息用 event key 标记。 发布者必须为每个订阅维护一个单独的事件密钥，以便于错误检测（如下所述）。 当发布者发送初始事件消息时，订阅的 event key 被初始化为 0。 对于每个后续事件消息，发布者都会递增订阅的 event key，并将更新后的密钥包括在事件消息中。 事件密钥的任何实现都应处理溢出，并将事件密钥从 4294967295 包装回 1（而不是0）。 当下一个事件键不是上一个键的增量时，订阅服务器还必须处理这种特殊情况。 应实现为4字节（32位）无符号整数。
如果定户没有对任何事件消息做出响应，则发布者应继续尝试向订阅者发送后续事件消息，直到订阅到期。
为了修复事件订阅，例如，如果订户错过了一个或多个事件消息， 则订户必须退订并重新订阅。 这样，订户将获得新的订阅标识符，新的初始事件消息和新的事件密钥。
所有 UPnP 的事件消息应该使用 UTF-8 编码。
4.2.1 Eventing: Event messages: NOTIFY
为了发送事件消息，Publisher 必须发送一个如下格式的请求，该请求的请求方法为 NOTIFY。 斜体值是实际值的占位符。
下面列出的是上图中出现的 response line / Headers 和 Body 的详细信息。 所有头（ header ）的值和元素（ element ）的名称均区分大小写； 除非特殊申明，所有值都不区分大小写； 除非特殊申明，所有的元素的顺序都是无关紧要的。 除非另有说明，否则必需元素必须仅出现一次（没有重复），推荐或可选元素当且仅当出现一次。 特别是，单个 propertyset 元素不得包含多个指定同一 variableName 元素的 property 元素； 每一个同名的 variableName 状态必须使用单独的事件通知消息。
Request line
NOTIFY 用于 Notify event 的 HTTP 请求方法。
delivery path Notify 消息服务的 URL 的资源路径（该值存在与定户发送订阅消息的 CALLBACK 头中）。 必须是 CALLBACK 标头中包含的 URL 之一，不能截断或修改。| Single, relative URL
HTTP/1.1 HTTP version.
Headers
HOST Required | 接受订阅事件的域名或者 IP 地址，端口信息是可选标注的 ( 该 URL 在 Subscriber 发送的订阅请求的 CALLBACK 头有提及)。 如果端口号未指定则默认为是 80 端口。
ACCEPT-LANGUAGE （事件消息无此头）
CONTENT-LENGTH Required | Body 的大小，单位字节 | Integer
CONTENT-TYPE Required | 必须为 text/xml， 指明 Body 采用的字符编码，这里必须为 “uft-8”。
NT Required | Notification 类型, 值必须是 upnp:event。
NTS Required | 事件推送的子类型 | 值必须为 upnp:propchange。
SID Required | 由 Publisher 之前分配个定户的 SID， 必须是全局唯一的，而且值必须以 uuid: 开头，由 UPnP 供应商定义 | Single URI URI.
SEQ Required | Event key | initial event 的值必须为 0, 没向定户发送一次事件消息，该定户的该值就相应的增加 1， 为防止溢出，当值为 4294967295 再发送的下一个事件的改值将变为 1。 该值为 32 位无符号的十进制，不带前导零（某些实现可能包含前导零，接收者应将其忽略）。
Body
properyset Required | xmlns 属性必须为 urn:schemas-upnp-org:event-1-0 包含如下子元素：
property Required | 每一个状态变量名在每一个时间中只重复一次，而且必须属于 propertyset 命名空间前缀的响应。 包含如下元素：
variableName Required | 有变动的状态变量的名称（服务描述中 stateVariable 元素的 name 子元素）。 不得使用任何命名空间限定。 值是此状态变量的新值。 区分大小写。 UPnP 服务描述所指定的单一数据类型。
为了将来的可扩展性，当像上面的清单那样处理 XML 时，设备和控制点必须忽略： （a）任何未知元素及其子元素或内容，以及（b）任何未知属性及其值。 请注意，当使用比控制点支持的版本更高的服务订阅事件时，该服务可能会将原本定户不能识别的状态变量发送给控制点。 此时，控制点应丢弃并忽略事件通知消息中的此类无法识别的状态变量。
所有的控制点和设备应该忽略 XML 的注释或者他们看不懂的 XML 的流程说明。
请注意，由于 HTTP 1.1 允许使用分块编码， 因此，如果 SUBSCRIBE 请求指定 HTTP 1.1， 则某些设备可能会使用分块编码来发送操作响应。 因此，建议在 SUBSCRIBE 请求中包括 HTTP 1.1 的所有实现都支持接收分块编码。
为了确认收到此事件消息，订户必须在 30s 内做出响应，包括预期的传输时间。 如果订阅者在 30s 内没有响应，或者发布者无法连接到订阅 URL， 则发布者应放弃向订阅者发送此消息，但应保持订阅处于活动状态，并向订阅者发送将来的事件消息， 直到订阅过期或被取消。 订户必须以以下格式发送响应。
HTTP/1.1 200 OK
NOTIFY 方法的请求没有负载（body）部分，但是在头部后了空行一定不能少。（结尾是两个 \r\n）
如果控制点使用 HTTP/1.0 承载 SOAP 协议，但是没有携带 KeepAlive 头， 设备必须在响应结束之后关闭通信 socket。 如果控制点使用 HTTP/1.1 承载 SOAP 协议，而且设置 Connection: CLOSE, 那么设备必须在响应之后关闭通信 socket。
如果事件消息有错误，则订户必须以以下错误之一进行响应。 响应必须在 30 秒内发送，包括预期的传输时间。
Errors
MISS SID 412 Precondition Failed | 如果 SID 缺失，或者为空，则 Publisher 必须响应 412 Precondition Failed 错误信息。
Invalid SID 412 Precondition Failed | 如果 SID 其值未可知，或者该订阅已过期，则 Publisher 必须响应 412 Precondition Failed 错误信息。 (收到此错误响应时必须终止此 SID。)
Missing NT or NTS header 400 Bad Request | 如果 NT 或者 NTS 头缺失，则发布者必须响应 400 Bad Request 错误消息。
Invalid NT header 412 Precondition Failed | 如果 NT 标头不等于 upnp:event , 则发布者必须响应 412 Precondition Failed 错误消息。
Invalid NTS header 412 Precondition Failed | 如果 NTS 头不等于 upnp:propchange ，则发布者必须响应 412 Precondition Failed 错误消息。
UPnP 协议底层协议栈中的层可能会返回其他错误。 有关详细信息，请查阅这些协议的文档。
4.3 Eventing: UPnP Template Language for eventing
UPnP 模板语言为设备和服务定义了格式正确的模板。 在较小程度上，它还提供了事件消息主体的模板。 “描述” 部分说明了与设备和服务有关的 UPnP 模板语言。 如该部分所述，UPnP 模板语言是用 XML 语法编写的，并且是从XML架构派生的（第1部分：结构，第2部分：数据类型）。 以下是与事件有关的该语言列表。它定义的元素用于事件消息中。 它们在这里是绿色，在上面的清单中是绿色。 以下是定义这些元素的位置（尽管这是最低限度的定义）； 以及使用它们的地方。
紧随其后的是对使用的 XML Schema 元素，属性和值的简要说明。 本节末尾的 XML Schema 参考文献有更多详细信息。
UPnP Template Language for eventing
element 引用元素以声明嵌套。 maxOccurs 属性定义元素必须出现的最大次数。 默认值为 maxOccurs = 1 ; 可以出现一次或多次的元素具有 maxOccurs = * 。
ElementType 用新的派生语言定义元素。 name 属性定义元素名称。 model 属性定义元素是否包含子元素。 如果有元素中的子元素包含的内容不确定的时候 model 等于 open, 如果只有元素中的子元素才拥有内容的时候 model 等于 eltOnly, name 属性定义元素名称。 model 性指示新的派生语言中的元素是否可以包含此处未明确指定的元素， 仅在未指定的子元素可能会包括在内的时候，model = open。 content 属性指示可能包含的内容， 仅包含其他元素的元素具有 content = eltOnly。
如 “描述” 部分中所述，服务的 UPnP 模板语言还为状态变量指定 sendEvents 属性。 此属性的默认值为 yes。 为了表示状态变量可 event，在服务描述中此属性的值为 yes（或省略该属性）。 如果为 non-event, 则其值为 no。 请注意，如果所有服务的状态变量均为 non-event，则该服务没有任何要发布的内容，并且控制点无法订阅，也不会从该服务接收事件消息。
4.4 Eventing: Augmenting the UPnP Template Language
在 UPnP 模板语言中，对设备和服务做 annotations 是很有用的。 在较小程度上，这些批注中的值可以平滑和温和的捕获事件。
如上所述，某些状态变量可能更改值的速度太快，以至于无法使用。 以下是 UPnP 论坛工作委员会或 UPnP 供应商推荐的词汇表，用于记录由于变量值更改而导致发送的事件消息数量的度。
maximumRate = n Optional | 在发送事件之后，状态变量的值产生了变化，但是你设置了该值， 那么即便在 ns 秒内产生了事件。下次发送事件也会在 ns 以后。 但是如果 v 在 ns 内停止了连续的更新，那么此时应该及时的吧该变量的最新状态发送出去。 | 建议给频繁，持续变化的状态变量设置该值（比如说播放进度） | 整数。
minimumDelta = n Optional | 在发送事件之后，状态变量的值产生了变化，但是你设置了该值， 那么即便值的变化在 +-n 范围内，此时并不会产生事件， 但是如果 v 此时值超出了 allowedValueRange 的范围，那么此时应该及时的吧该变量的最新状态发送出去。 | 建议需要进行滤波，或者计数类型的状态变量设置该值 | 整数。
事件发生后，发布者可以发送任何已更改的调节变量。 发布者也应尽最大努力满足上述审核规则， 但发布者在发出事件时可以过滤掉最近的更改。
请注意，查询状态变量，仅仅会影响事件，而不会导致状态变量的更新。 具体来说，返回状态变量值的控制动作可能会返回比通过事件发布的状态值更接近于真是值。 换句话说，调节导致的状态表更改并非意味都会导致事件的发生。
关于那个状态变量是否可被 event 或者调节，这由 UPnP 委员会或者 UPnP 供应商决定（非标服务）。
4.5 Eventing references
RFC 2396 Uniform Resource Identifiers: Generic Syntax 传送门
RFC 2616 HTTP: Hypertext Transfer Protocol 1.1. 传送门
XML Extensible Markup Language. 传送门
XML Schema (Part 1: Structures, Part 2: Datatypes) Grammar defining UPnP Template Language. 传送门 / 传送门
A Universally Unique IDentifier (UUID) URN Namespace 传送门
5. Presentation
演示是 UPnP™ 网络中的第 5 步，是对 3 3步和第 4 步的补充。
在控制点（1）发现设备并（2）检索到该设备的描述之后，控制点就可以打开演示功能。 如果设备具有用于演示的 URL，则控制点可以从该 URL 检索页面，将页面加载到浏览器中，并根据页面的功能，允许用户控制设备和/或查看设备状态。 这些功能可以实现的程度取决于演示页面和设备的特定功能。
用于演示的 URL 包含在设备描述中的 presentationURL 元素内。 设备描述是通过描述消息传递的。 “描述” 部分详细说明了设备描述和描述消息。
为了发送或者接受事件的消息，控制点和服务必须 following 完整 UPnP 协议栈的子集。 （完整的 UPnP 协议栈在本文最开始已经说明了）。
协议最上层，演示页面由 UPnP 供应商指定。 在协议第二层，UDA 指定该页面用 HTML 编写。 该页面通过基于 TCP/IP 上的 HTTP 传递。 作为参考，为了与本文档中的其他部分保持一致，在[方括号]中添加��颜色��
为了检索演示页面，控制点向演示 URL 发出 HTTP GET 请求，然后设备返回一个演示页面。
与 UPnP 设备和服务模板以及标准设备和服务类型不同，演示页面的功能完全由 UPnP 供应商指定。 演示页面不在 UPnP 委员会的主持下。 该页面必须是 HTML 页面； 它应该是 HTML 3.0 或更高版本。 但是，其他设计方面留给供应商指定。 这包括但不限于控制点浏览器的所有功能，使用的脚本语言或浏览器插件以及与设备进行交互的方式。 为了实现演示页面，UPnP 供应商可能希望利用 UPnP 机制进行控制和/或事件化，以利用设备的现有功能，但并不限于此。
演示页面应使用 HTML 提供的本地化机制（例如，具有 charset 属性的 META 标签）。 控制点应使用 HTTP 的 ACCEPT-LANGUAGE 和 CONTENT-LANGUAGE 功能来尝试检索本地化的演示文稿页面。 具体地说，控制点可以在对演示页面的请求中包括 HTTP ACCEPT-LANGUAGE 标头。 如果请求中存在 ACCEPT-LANGUAGE 标头，则响应必须包含 CONTENT-LANGUAGE 标头以标识页面的语言。
5.1 Presentation references
HTML HyperText Markup Language 传送门