要点记录
一、概要
1、Description在逻辑上分为两部分：
a）device description：用来描述物理/逻辑上的容器；
b）service description：device所能提供的服务；
2、一个物理设备可以包含多个逻辑设备，多个逻辑设备能够被看作带有多个embeded services的root device，也可以被看作是单个的root device（可以没有对应的embeded service），最新的case是按照后一种情况对待：存在多个UPnP device description，每一个对应一个单独的root device；
3、如前所述，UPnP的版本号分为major和minor两部分，major version相同的情况下，必须保证向后兼容，不同的情况下则不保证向后兼容；
4、Device和service的版本号在概念上不同于UPnP版本号，它可以由UPnP工作组标准化，也可以由vendor定义，在开发阶段，可以是非整数的格式，产品化之后必须定义为整数格式。device和service type的版本号上升时，必须确保device包含低版本所有的embeded devices和services（向后兼容），如果版本号上升时，不能确保向后兼容，则device和service的name需要更新，同时对应的版本号需要重置为1。
5、Device type和service type是一个“building block”的概念。Standard或是vendor-defined的device type可以被封装在standard或vendor-defined的device type内，service type也是一样。CP需要具备在任何可能的device type（无论该CP是否能够识别）内识别出自己需要的service type；
6、注意multi-homed和UPnP-enabled interfaces的概念，这是DA1.1和DA1.0有区别的地方。（DMS多网卡（场景是什么）？old IP address尚未过期，new IP address已经启用？）
二、Device description
1、紧跟"device:"的device type后缀应当小于64个字符；
2、friendlyName和manufacturer应当小于64个字符；
3、modelDescription应当小于128个字符；
4、modelName和modelNumber应当小于32个字符；
5、URLBase域不再被推荐使用；
6、serialNubmer应当小于64个字符；
7、对于不能识别的element、attribute以及对应的sub elements和values，devices和CPs应当忽略；
8、Device description的编码方式应为UTF-8；
三、UPnP Device Template
四、Service description
需要关注一下扩展data types的定义和处理。
五、UPnP Service Template
六、Non-standard vendor extensions and limitations
七、UPnP Device Schema
八、UPnP Service Schema
九、UPnP Datatype Schema
十、Retrieving a description using HTTP
1、Description的基于HTTP+TCP的方式，注意和Discovery的区别；
2、CP请求description之后，device需要在30s内回应，否则CP应当重传前次的请求；