discontinued / server · Files

index.html 203 KB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>
<html dir="ltr" xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
    <title>Requirements for Home Networking Scenarios</title>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
        
    
  <style type="text/css">
/*****************************************************************
 * ReSpec CSS
 * Robin Berjon (robin at berjon dot com)
 * v0.05 - 2009-07-31
 *****************************************************************/


/* --- INLINES --- */
em.rfc2119 { 
    text-transform:     lowercase;
    font-variant:       small-caps;
    font-style:         normal;
    color:              #900;
}

h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
    border: none;
}

dfn {
    font-weight:    bold;
}

a.internalDFN {
    color:  inherit;
    border-bottom:  1px solid #99c;
    text-decoration:    none;
}

a.externalDFN {
    color:  inherit;
    border-bottom:  1px dotted #ccc;
    text-decoration:    none;
}

a.bibref {
    text-decoration:    none;
}

code {
    color:  #ff4500;
}


/* --- WEB IDL --- */
pre.idl {
    border-top: 1px solid #90b8de;
    border-bottom: 1px solid #90b8de;
    padding:    1em;
    line-height:    120%;
}

pre.idl::before {
    content:    "WebIDL";
    display:    block;
    width:      150px;
    background: #90b8de;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

.idlType {
    color:  #ff4500;
    font-weight:    bold;
    text-decoration:    none;
}

/*.idlModule*/
/*.idlModuleID*/
/*.idlInterface*/
.idlInterfaceID, .idlDictionaryID {
    font-weight:    bold;
    color:  #005a9c;
}

.idlSuperclass {
    font-style: italic;
    color:  #005a9c;
}

/*.idlAttribute*/
.idlAttrType, .idlFieldType, .idlMemberType {
    color:  #005a9c;
}
.idlAttrName, .idlFieldName, .idlMemberName {
    color:  #ff4500;
}
.idlAttrName a, .idlFieldName a, .idlMemberName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlMethod*/
.idlMethType {
    color:  #005a9c;
}
.idlMethName {
    color:  #ff4500;
}
.idlMethName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlParam*/
.idlParamType {
    color:  #005a9c;
}
.idlParamName {
    font-style: italic;
}

.extAttr {
    color:  #666;
}

/*.idlConst*/
.idlConstType {
    color:  #005a9c;
}
.idlConstName {
    color:  #ff4500;
}
.idlConstName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlException*/
.idlExceptionID {
    font-weight:    bold;
    color:  #c00;
}

.idlTypedefID, .idlTypedefType {
    color:  #005a9c;
}

.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
    color:  #c00;
    font-weight:    normal;
}

.excName a {
    font-family:    monospace;
}

.idlRaises a.idlType, .excName a.idlType {
    border-bottom:  1px dotted #c00;
}

.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
    width:  45px;
    text-align: center;
}
.excGetSetTrue, .prmNullTrue, .prmOptTrue { color:  #0c0; }
.excGetSetFalse, .prmNullFalse, .prmOptFalse { color:  #c00; }

.idlImplements a {
    font-weight:    bold;
}

dl.attributes, dl.methods, dl.constants, dl.fields, dl.dictionary-members {
    margin-left:    2em;
}

.attributes dt, .methods dt, .constants dt, .fields dt, .dictionary-members dt {
    font-weight:    normal;
}

.attributes dt code, .methods dt code, .constants dt code, .fields dt code, .dictionary-members dt code {
    font-weight:    bold;
    color:  #000;
    font-family:    monospace;
}

.attributes dt code, .fields dt code, .dictionary-members dt code {
    background:  #ffffd2;
}

.attributes dt .idlAttrType code, .fields dt .idlFieldType code, .dictionary-members dt .idlMemberType code {
    color:  #005a9c;
    background:  transparent;
    font-family:    inherit;
    font-weight:    normal;
    font-style: italic;
}

.methods dt code {
    background:  #d9e6f8;
}

.constants dt code {
    background:  #ddffd2;
}

.attributes dd, .methods dd, .constants dd, .fields dd, .dictionary-members dd {
    margin-bottom:  1em;
}

table.parameters, table.exceptions {
    border-spacing: 0;
    border-collapse:    collapse;
    margin: 0.5em 0;
    width:  100%;
}
table.parameters { border-bottom:  1px solid #90b8de; }
table.exceptions { border-bottom:  1px solid #deb890; }

.parameters th, .exceptions th {
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
    font-family:    initial;
    font-weight:    normal;
    text-shadow:    #666 1px 1px 0;
}
.parameters th { background: #90b8de; }
.exceptions th { background: #deb890; }

.parameters td, .exceptions td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
    vertical-align: top;
}

.parameters tr:first-child td, .exceptions tr:first-child td {
    border-top: none;
}

.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
    width:  100px;
}

.parameters td.prmType {
    width:  120px;
}

table.exceptions table {
    border-spacing: 0;
    border-collapse:    collapse;
    width:  100%;
}

/* --- TOC --- */
.toc a {
    text-decoration:    none;
}

a .secno {
    color:  #000;
}

/* --- TABLE --- */
table.simple {
    border-spacing: 0;
    border-collapse:    collapse;
    border-bottom:  3px solid #005a9c;
}

.simple th {
    background: #005a9c;
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
}

.simple th[scope="row"] {
    background: inherit;
    color:  inherit;
    border-top: 1px solid #ddd;
}

.simple td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
}

.simple tr:nth-child(even) {
    background: #f0f6ff;
}

/* --- DL --- */
.section dd > p:first-child {
    margin-top: 0;
}

.section dd > p:last-child {
    margin-bottom: 0;
}

.section dd {
    margin-bottom:  1em;
}

.section dl.attrs dd, .section dl.eldef dd {
    margin-bottom:  0;
}

/* --- EXAMPLES --- */
pre.example {
    border-top: 1px solid #ff4500;
    border-bottom: 1px solid #ff4500;
    padding:    1em;
    margin-top: 1em;
}

pre.example::before {
    content:    "Example";
    display:    block;
    width:      150px;
    background: #ff4500;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

/* --- EDITORIAL NOTES --- */
.issue {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #f00;
    background: #ffc;
}

.issue::before {
    content:    "Issue";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #f00;
    background: #fff;
    padding:    3px 1em;
}

.note {
    margin: 1em 0em 0em;
    padding:    1em;
    border: 2px solid #cff6d9;
    background: #e2fff0;
}

.note::before {
    content:    "Note";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #cff6d9;
    background: #fff;
    padding:    3px 1em;
}

/* --- Best Practices --- */
div.practice {
    border: solid #bebebe 1px;
    margin: 2em 1em 1em 2em;
}

span.practicelab {
    margin: 1.5em 0.5em 1em 1em;
    font-weight: bold;
    font-style: italic;
}

span.practicelab   { background: #dfffff; }

span.practicelab {
    position: relative;
    padding: 0 0.5em;
    top: -1.5em;
}

p.practicedesc {
    margin: 1.5em 0.5em 1em 1em;
}

@media screen {
    p.practicedesc {
        position: relative;
        top: -2em;
        padding: 0;
        margin: 1.5em 0.5em -1em 1em;
    }
}

/* --- SYNTAX HIGHLIGHTING --- */
pre.sh_sourceCode {
  background-color: white;
  color: black;
  font-style: normal;
  font-weight: normal;
}

pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; }           /* language keywords */
pre.sh_sourceCode .sh_type { color: #666; }                            /* basic types */
pre.sh_sourceCode .sh_usertype { color: teal; }                             /* user defined types */
pre.sh_sourceCode .sh_string { color: red; font-family: monospace; }        /* strings and chars */
pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; }     /* regular expressions */
pre.sh_sourceCode .sh_specialchar { color: 	#ffc0cb; font-family: monospace; }  /* e.g., \n, \t, \\ */
pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; }         /* comments */
pre.sh_sourceCode .sh_number { color: purple; }                             /* literal numbers */
pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; }       /* e.g., #include, import */
pre.sh_sourceCode .sh_symbol { color: blue; }                            /* e.g., *, + */
pre.sh_sourceCode .sh_function { color: black; font-weight: bold; }         /* function calls and declarations */
pre.sh_sourceCode .sh_cbracket { color: red; }                              /* block brackets (e.g., {, }) */
pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; }   /* TODO and FIXME */

/* Predefined variables and functions (for instance glsl) */
pre.sh_sourceCode .sh_predef_var { color: #00008B; }
pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }

/* for OOP */
pre.sh_sourceCode .sh_classname { color: teal; }

/* line numbers (not yet implemented) */
pre.sh_sourceCode .sh_linenum { display: none; }

/* Internet related */
pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }

/* for ChangeLog and Log files */
pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }

/* for Prolog, Perl... */
pre.sh_sourceCode .sh_variable { color: #006400; }

/* for LaTeX */
pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
pre.sh_sourceCode .sh_argument { color: #006400; }
pre.sh_sourceCode .sh_optionalargument { color: purple; }
pre.sh_sourceCode .sh_math { color: orange; }
pre.sh_sourceCode .sh_bibtex { color: blue; }

/* for diffs */
pre.sh_sourceCode .sh_oldfile { color: orange; }
pre.sh_sourceCode .sh_newfile { color: #006400; }
pre.sh_sourceCode .sh_difflines { color: blue; }

/* for css */
pre.sh_sourceCode .sh_selector { color: purple; }
pre.sh_sourceCode .sh_property { color: blue; }
pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }

/* other */
pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
pre.sh_sourceCode .sh_paren { color: red; }
pre.sh_sourceCode .sh_attribute { color: #006400; }

</style><link href="http://www.w3.org/StyleSheets/TR/W3C-IG-NOTE" rel="stylesheet" type="text/css" charset="utf-8" /></head>
  <body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C" /></a></p><h1 class="title" id="title">Requirements for Home Networking Scenarios</h1><h2 id="w3c-interest-group-note-01-december-2011"><acronym title="World Wide Web Consortium">W3C</acronym> Interest Group Note 01 December 2011</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2011/NOTE-hnreq-20111201/">http://www.w3.org/TR/2011/NOTE-hnreq-20111201/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/hnreq/">http://www.w3.org/TR/hnreq/</a></dd><dt>Previous version:</dt><dd>none</dd><dt>Editor:</dt><dd><span>Giuseppe Pascale</span>, <a href="http://www.opera.com/">Opera Software</a></dd>
<dt>Authors:</dt><dd><span>Clarke Stevens</span>, <a href="http://www.cablelabs.com/">CableLabs</a></dd>
<dd><span>Jan Lindquist</span>, <a href="http://www.ericsson.com/">Ericsson</a></dd>
<dd><span>Jean-Claude Dufourd</span>, <a href="http://www.telecom-paristech.fr/">Telecom ParisTech</a></dd>
<dd><span>Matt Hammond</span>, <a href="http://www.bbc.co.uk/">BBC</a></dd>
<dd><span>Russell Berkoff</span>, <a href="http://www.samsung.com/">Samsung</a></dd>
<dd><span>Tatsuya Igarashi</span>, <a href="http://www.sony.com/">Sony</a></dd>
</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2011 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr /></div>
    <div id="abstract" class="introductory section"><h2>Abstract</h2>
      <p>This document lists the design goals and requirements that potential <acronym title="World Wide Web Consortium">W3C</acronym> recommendations should support in order to enable access to services and content provided by home network devices on other devices, including the discovery and playback of content available to those devices, both from services such as traditional broadcast media and internet based services but also from the home network.</p>
    </div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p>
      <p>Recommendations in this document are the result of discussion in the Home Network Task Force of the <a href="http://www.w3.org/2011/webtv/">Web and TV Interest Group</a>. The Home Network Task Force believes that most of these recommendations listed in this document will be refined and addressed within the <a href="http://www.w3.org/2009/dap/">Device APIs Working Group</a>, as part of its work on a devices and services discovery API standard. In particular, while the Home Network Task Force may continue to discuss areas of home networking scenarios that have not already been raised in this document, it does not anticipate further work on the scenarios and requirements highlighted in this document within the Web and TV Interest Group.</p>
    <p>This document was published by the <a href="http://www.w3.org/2011/webtv/">Web and TV Interest Group</a> as an Interest Group Note. If you wish to make comments regarding this document, please send them to <a href="mailto:public-web-and-tv@w3.org">public-web-and-tv@w3.org</a> (<a href="mailto:public-web-and-tv-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-web-and-tv/">archives</a>). All feedback is welcome.</p><p>Publication as an Interest Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p>
<p>The disclosure obligations of the Participants of this group are described in the <a href="http://www.w3.org/2010/09/webTVIGcharter.html#patentpolicy">charter</a>.</p>
</div>
<div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a href="#conformance" class="tocxref"><span class="secno">2. </span>Conformance</a></li><li class="tocline"><a href="#terminology" class="tocxref"><span class="secno">3. </span>Terminology</a></li><li class="tocline"><a href="#requirements" class="tocxref"><span class="secno">4. </span>Requirements</a><ul class="toc"><li class="tocline"><a href="#general" class="tocxref"><span class="secno">4.1 </span>General</a><ul class="toc"><li class="tocline"><a href="#compatibility-with-widely-deployed-standards" class="tocxref"><span class="secno">4.1.1 </span>Compatibility with widely deployed standards</a></li></ul></li><li class="tocline"><a href="#discovery-and-advertising" class="tocxref"><span class="secno">4.2 </span>Discovery and Advertising</a><ul class="toc"><li class="tocline"><a href="#service-discovery" class="tocxref"><span class="secno">4.2.1 </span>Service Discovery</a></li><li class="tocline"><a href="#application-discovery" class="tocxref"><span class="secno">4.2.2 </span>Application Discovery</a></li><li class="tocline"><a href="#content-discovery" class="tocxref"><span class="secno">4.2.3 </span>Content Discovery</a></li><li class="tocline"><a href="#content-advertisement" class="tocxref"><span class="secno">4.2.4 </span>Content Advertisement</a></li><li class="tocline"><a href="#services-advertisement" class="tocxref"><span class="secno">4.2.5 </span>Services Advertisement</a></li><li class="tocline"><a href="#media-identification" class="tocxref"><span class="secno">4.2.6 </span>Media Identification</a></li></ul></li><li class="tocline"><a href="#control-and-communication" class="tocxref"><span class="secno">4.3 </span>Control and Communication</a><ul class="toc"><li class="tocline"><a href="#control-of-content-players" class="tocxref"><span class="secno">4.3.1 </span>Control of Content Players</a></li><li class="tocline"><a href="#control-of-content-recorders" class="tocxref"><span class="secno">4.3.2 </span>Control of Content Recorders</a></li><li class="tocline"><a href="#playback-of-content" class="tocxref"><span class="secno">4.3.3 </span>Playback of Content</a></li><li class="tocline"><a href="#playback-of-live-content" class="tocxref"><span class="secno">4.3.4 </span>Playback of Live Content</a></li><li class="tocline"><a href="#x3-box-model" class="tocxref"><span class="secno">4.3.5 </span>3 Box Model</a></li><li class="tocline"><a href="#time-synchronization" class="tocxref"><span class="secno">4.3.6 </span>Time-synchronization</a></li><li class="tocline"><a href="#accurate-time-synchronization" class="tocxref"><span class="secno">4.3.7 </span>Accurate Time-synchronization</a></li><li class="tocline"><a href="#service-communication" class="tocxref"><span class="secno">4.3.8 </span>Service Communication</a></li><li class="tocline"><a href="#application-communication" class="tocxref"><span class="secno">4.3.9 </span>Application Communication</a></li><li class="tocline"><a href="#content-protection" class="tocxref"><span class="secno">4.3.10 </span>Content Protection</a></li></ul></li><li class="tocline"><a href="#migration" class="tocxref"><span class="secno">4.4 </span>Migration</a><ul class="toc"><li class="tocline"><a href="#push-migration" class="tocxref"><span class="secno">4.4.1 </span>Push Migration</a></li><li class="tocline"><a href="#pull-migration" class="tocxref"><span class="secno">4.4.2 </span>Pull Migration</a></li></ul></li><li class="tocline"><a href="#security-and-privacy" class="tocxref"><span class="secno">4.5 </span>Security and Privacy</a><ul class="toc"><li class="tocline"><a href="#application-trust-level" class="tocxref"><span class="secno">4.5.1 </span>Application Trust Level</a></li><li class="tocline"><a href="#access-to-home-network-services" class="tocxref"><span class="secno">4.5.2 </span>Access to Home Network Services</a></li><li class="tocline"><a href="#prevent-leaking-of-information" class="tocxref"><span class="secno">4.5.3 </span>Prevent Leaking of Information</a></li></ul></li></ul></li><li class="tocline"><a href="#use-cases" class="tocxref"><span class="secno">5. </span>Use Cases</a><ul class="toc"><li class="tocline"><a href="#u1.-service-user-interface" class="tocxref"><span class="secno">5.1 </span>U1. Service User Interface</a></li><li class="tocline"><a href="#u2.-discovered-content-host" class="tocxref"><span class="secno">5.2 </span>U2. Discovered Content Host</a></li><li class="tocline"><a href="#u3.-service-migration" class="tocxref"><span class="secno">5.3 </span>U3. Service Migration</a></li><li class="tocline"><a href="#u4.-service-distribution" class="tocxref"><span class="secno">5.4 </span>U4. Service Distribution</a></li><li class="tocline"><a href="#u5.-3-box-model" class="tocxref"><span class="secno">5.5 </span>U5. 3-Box Model</a></li><li class="tocline"><a href="#u6.-application-exposing-a-service" class="tocxref"><span class="secno">5.6 </span>U6. Application Exposing a Service</a></li><li class="tocline"><a href="#u7.-application-discovering-a-service" class="tocxref"><span class="secno">5.7 </span>U7. Application Discovering a Service</a></li><li class="tocline"><a href="#u8.-application-push-migration" class="tocxref"><span class="secno">5.8 </span>U8. Application Push-Migration</a></li><li class="tocline"><a href="#u9.-application-pull-migration" class="tocxref"><span class="secno">5.9 </span>U9. Application Pull-Migration</a></li><li class="tocline"><a href="#u10.-media-identification" class="tocxref"><span class="secno">5.10 </span>U10. Media Identification</a></li><li class="tocline"><a href="#u11.-tv-control" class="tocxref"><span class="secno">5.11 </span>U11. TV Control</a></li><li class="tocline"><a href="#u12.-time-synchronization" class="tocxref"><span class="secno">5.12 </span>U12. Time Synchronization</a></li><li class="tocline"><a href="#u13.-lip-sync-time-synchronization" class="tocxref"><span class="secno">5.13 </span>U13. Lip Sync Time Synchronization</a></li><li class="tocline"><a href="#u14.-local-link-of-web-applications" class="tocxref"><span class="secno">5.14 </span>U14. Local Link of Web Applications</a></li><li class="tocline"><a href="#u15.-home-network-enabled-user-agent---network-media-player" class="tocxref"><span class="secno">5.15 </span>U15. Home Network Enabled User-Agent - Network Media Player</a></li><li class="tocline"><a href="#u16.-home-network-enabled-user-agent---network-media-server" class="tocxref"><span class="secno">5.16 </span>U16. Home Network Enabled User-Agent - Network Media Server</a></li><li class="tocline"><a href="#u17.-home-network-enabled-user-agent" class="tocxref"><span class="secno">5.17 </span>U17. Home Network Enabled User-Agent</a></li><li class="tocline"><a href="#u18.-home-network-enabled-user-agent---network-record-controller" class="tocxref"><span class="secno">5.18 </span>U18. Home Network Enabled User-Agent - Network Record Controller</a></li><li class="tocline"><a href="#u19.-upnp---dlna-ecosystem-support" class="tocxref"><span class="secno">5.19 </span>U19. UPnP / DLNA ecosystem support</a></li></ul></li><li class="tocline"><a href="#security" class="tocxref"><span class="secno">6. </span>Security</a><ul class="toc"><li class="tocline"><a href="#threats" class="tocxref"><span class="secno">6.1 </span>Threats</a><ul class="toc"><li class="tocline"><a href="#security-1" class="tocxref"><span class="secno">6.1.1 </span>Security</a></li><li class="tocline"><a href="#privacy" class="tocxref"><span class="secno">6.1.2 </span>Privacy</a></li></ul></li><li class="tocline"><a href="#potential-solutions" class="tocxref"><span class="secno">6.2 </span>Potential Solutions</a><ul class="toc"><li class="tocline"><a href="#home-network-access-allowed-only-to-trusted-applications" class="tocxref"><span class="secno">6.2.1 </span>Home Network Access Allowed Only to Trusted Applications</a><ul class="toc"><li class="tocline"><a href="#how-to-determine-the-trust-level-of-an-application--several-may-apply" class="tocxref"><span class="secno">6.2.1.1 </span>How to Determine the Trust Level of an Application (Several May Apply)</a></li><li class="tocline"><a href="#trust-levels-options--mutually-exclusive" class="tocxref"><span class="secno">6.2.1.2 </span>Trust Levels Options (Mutually Exclusive)</a></li></ul></li><li class="tocline"><a href="#device-pairing" class="tocxref"><span class="secno">6.2.2 </span>Device Pairing</a></li><li class="tocline"><a href="#device-information-only-visible-to-the-user" class="tocxref"><span class="secno">6.2.3 </span>Device Information only Visible to the User</a></li><li class="tocline"><a href="#modular-access-to-home-network-services-and-content" class="tocxref"><span class="secno">6.2.4 </span>Modular Access to Home Network Services and Content</a></li></ul></li></ul></li><li class="tocline"><a href="#categorization-of-requirements-and-next-steps" class="tocxref"><span class="secno">7. </span>Categorization of Requirements and Next Steps</a><ul class="toc"><li class="tocline"><a href="#requirements-categorization" class="tocxref"><span class="secno">7.1 </span>Requirements Categorization</a></li><li class="tocline"><a href="#identified-gaps" class="tocxref"><span class="secno">7.2 </span>Identified Gaps</a></li><li class="tocline"><a href="#next-steps" class="tocxref"><span class="secno">7.3 </span>Next Steps</a></li><li class="tocline"><a href="#open-issues" class="tocxref"><span class="secno">7.4 </span>Open Issues</a></li></ul></li><li class="tocline"><a href="#related-works--informative" class="tocxref"><span class="secno">8. </span>Related Works (Informative)</a><ul class="toc"><li class="tocline"><a href="#cablelabs" class="tocxref"><span class="secno">8.1 </span>CableLabs</a></li><li class="tocline"><a href="#opera" class="tocxref"><span class="secno">8.2 </span>Opera</a><ul class="toc"><li class="tocline"><a href="#problem" class="tocxref"><span class="secno">8.2.1 </span>Problem</a></li><li class="tocline"><a href="#current-practice" class="tocxref"><span class="secno">8.2.2 </span>Current Practice</a></li><li class="tocline"><a href="#proposed-solution" class="tocxref"><span class="secno">8.2.3 </span>Proposed Solution</a></li><li class="tocline"><a href="#bbc" class="tocxref"><span class="secno">8.2.4 </span>BBC</a></li></ul></li><li class="tocline"><a href="#telecom-paristech" class="tocxref"><span class="secno">8.3 </span>Telecom ParisTech</a></li><li class="tocline"><a href="#cea-2014-web-based-protocol-and-framework-for-remote-user-interface---overview" class="tocxref"><span class="secno">8.4 </span>CEA-2014 Web-based Protocol and Framework for Remote User Interface - Overview</a><ul class="toc"><li class="tocline"><a href="#remote-ui-application-listing" class="tocxref"><span class="secno">8.4.1 </span>Remote UI Application Listing</a></li><li class="tocline"><a href="#client-capabilities-matching" class="tocxref"><span class="secno">8.4.2 </span>Client Capabilities Matching</a></li><li class="tocline"><a href="#standardized-audio-video-player" class="tocxref"><span class="secno">8.4.3 </span>Standardized Audio-Video Player</a></li><li class="tocline"><a href="#digital-rights-management-framework" class="tocxref"><span class="secno">8.4.4 </span>Digital Rights Management Framework</a></li><li class="tocline"><a href="#content-download-management-framework" class="tocxref"><span class="secno">8.4.5 </span>Content Download Management Framework</a></li><li class="tocline"><a href="#upnp---dlna-home-network-framework" class="tocxref"><span class="secno">8.4.6 </span>UPnP / DLNA Home Network Framework</a></li><li class="tocline"><a href="#svg--scalable-vector-graphics--integration-with-xhtml" class="tocxref"><span class="secno">8.4.7 </span>SVG (Scalable Vector Graphics) integration with XHTML</a></li><li class="tocline"><a href="#server-to-client-notification-framework" class="tocxref"><span class="secno">8.4.8 </span>Server to Client Notification Framework</a></li><li class="tocline"><a href="#remote-ui-save-and-restore-framework" class="tocxref"><span class="secno">8.4.9 </span>Remote UI Save and Restore Framework</a></li></ul></li><li class="tocline"><a href="#universal-plug-n-play--upnp--reference" class="tocxref"><span class="secno">8.5 </span>Universal Plug'n Play (UPnP) Reference</a><ul class="toc"><li class="tocline"><a href="#introduction-1" class="tocxref"><span class="secno">8.5.1 </span>Introduction</a></li><li class="tocline"><a href="#upnp-av-architecture" class="tocxref"><span class="secno">8.5.2 </span>UPnP AV Architecture</a></li><li class="tocline"><a href="#upnp-device-architecture" class="tocxref"><span class="secno">8.5.3 </span>UPnP Device Architecture</a></li><li class="tocline"><a href="#upnp-media-renderer-device" class="tocxref"><span class="secno">8.5.4 </span>UPnP Media Renderer Device</a></li><li class="tocline"><a href="#upnp-media-server-device" class="tocxref"><span class="secno">8.5.5 </span>UPnP Media Server Device</a></li></ul></li><li class="tocline"><a href="#ericsson-labs" class="tocxref"><span class="secno">8.6 </span>Ericsson Labs</a></li></ul></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">A. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">A.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">A.2 </span>Informative references</a></li></ul></li></ul></div>

    

    <div id="introduction" class="section">
      
<!-- OddPage -->
<h2><span class="secno">1. </span>Introduction</h2>
      
      <p>There is an increasing amount of personal and streaming (broadcast) content that users would like to be able to access from any device in the home (personal computers, tablets, mobile phones, TVs and others).</p>
      
      <p>Growing numbers of consumer electronic devices such as TVs and mobile phones can access internet based services as well as content originating from both home network devices and broadcast services. For example, many commercial video providers currently provide the ability for a user to access content stored on a home network device (e.g. a <abbr title="digital video recorder">DVR</abbr>) or accessed via a network connected <abbr title="set-top box">STB</abbr>. A home network content discovery and control protocol is used by the <abbr title="digital video recorder">DVR</abbr> and <abbr title="set-top box">STB</abbr> to provide this access, through a native user interface, to other devices in the home (e.g. PCs, TVs).</p>

      <p>The dominant scenario today is for a home network device to both discover and playback home network content. Examples of these devices may include personal computers or connected televisions. This is commonly referred to as a 2-Box model. An emerging scenario is for the content discovery and control to take place on a separate handheld device, such as a smartphones or tablets. The handheld device then instructs a content player (e.g. a TV) to playback content from a content server (e.g. a <abbr title="digital video recorder">DVR</abbr>). This is referred to as the 3-Box model.</p>

      <p>In all use cases, security mechanisms are made available to protect user privacy and content owners’ rights.</p>

      <p>There is no standardized way to build a web application that can use content discovery and control protocols to access the content on other devices in the home network. This document lists the design goals and requirements that future <acronym title="World Wide Web Consortium">W3C</acronym> recommendations need to address in order to address this problem. This would enable content providers to deliver web applications to any conforming device in order to enhance and harmonize the user experience.</p>
    </div>

    <div id="conformance" class="section">
      
<!-- OddPage -->
<h2><span class="secno">2. </span>Conformance</h2>

      <p>As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.</p>

      <p>The key words <em class="rfc2119" title="must">must</em>, <em class="rfc2119" title="must not">must not</em>, <em class="rfc2119" title="shall">shall</em>, <em class="rfc2119" title="should">should</em> and <em class="rfc2119" title="should not">should not</em> in this specification are to be interpreted as described in RFC 2119 [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2119">RFC2119</a></cite>].</p>

      <p>This specification only applies to one class of product: <dfn id="dfn-w3c-technical-reports"><acronym title="World Wide Web Consortium">W3C</acronym> Technical Reports</dfn>. A number of specifications may be created to address the requirements enumerated in this document. In some cases the union of multiple parts of different specifications may be needed to address a single requirement. Nevertheless, this document speaks only of <dfn id="dfn-conforming-specifications">conforming specifications</dfn>.</p>

      <p>Conforming specifications are ones that address one or more requirements listed in this document. Conforming specifications should attempt to address <em class="rfc2119" title="should">should</em> level requirements requirements unless there is a technically valid reason not to do so.</p>
    </div>

    <div id="terminology" class="section">
      
<!-- OddPage -->
<h2><span class="secno">3. </span>Terminology</h2>

      <dl>
        <dt><dfn id="dfn-programme">programme</dfn> (program)</dt>
        <dd>A programme (program) comprises a single period of audio visual content. It is usually expected to be labeled in content directories or television programme guides as a single entity. This might include an episode of a television programme, a radio programme, or a movie.</dd>

        <dt><dfn id="dfn-device">device</dfn></dt>
        <dd>For the purposes of this document, a device is any piece of equipment connected to the <a href="#dfn-home-network" class="internalDFN">home network</a>. Note that this is a generic term that also includes <a href="#dfn-television" class="internalDFN">television</a> (defined below).</dd>

        <dt><dfn id="dfn-television">television</dfn></dt>
        <dd>A <a href="#dfn-device" class="internalDFN">device</a> that presents <a href="#dfn-programme" class="internalDFN">programme</a> content from a variety of sources - such as received via broadcast (cable, satellite, terrestrial), on-demand streaming services, or streamed from other devices in the home (e.g. PVR). Within the scope of this document, it is presumed that a television is connected to the <a href="#dfn-home-network" class="internalDFN">home network</a>.</dd>

        <dt><dfn id="dfn-service">service</dfn></dt>
        <dd>For the purposes of this document, a service is any functionality available on a <a href="#dfn-device" class="internalDFN">device</a>, such as the ability to play back audio/video content, record content and print documents</dd>

        <dt><dfn id="dfn-document">document</dfn></dt>
        <dd>An individual resource that adheres to a certain content type, ranging from short static documents to long essays or reports with rich multimedia. For simplicity, terms such as shown, displayed, and visible might sometimes be used when referring to the way a document is rendered to the user. These terms are not meant to imply a visual medium; they must be considered to apply to other media in equivalent ways.</dd>

        <dt><dfn id="dfn-application">application</dfn></dt>
        <dd>For the purposes of this document, the term “application” refers to a collection of documents (not necessarily delivered over HTTP) which use server-side or client-side processing to provide a &quot;native application&quot;-like experience within a Web browser or other kinds of Web run-time. Applications may include locally executable elements of interactivity and persistent state. Note that locally stored applications like <acronym title="World Wide Web Consortium">W3C</acronym> Widgets [<cite><a class="bibref" rel="biblioentry" href="#bib-WIDGETS">WIDGETS</a></cite>] are intended to be covered by this definition.</dd>

        <dt><dfn id="dfn-home-network">home network</dfn></dt>
        <dd>For the purposes of this document, the term “home network” refers to the networking infrastructure that facilitates Internet Protocol communications between devices within the home. This may range from a single legacy IPv4 subnet to multiple IPv4 subnets and dual stack or IPv6 environments and will typically (but not always) be connected to the Internet.</dd>

        <dt><dfn id="dfn-content-item">content item</dfn></dt>
        <dd>For the purposes of this document, the term “content item” refers to metadata describing or more binary versions of media. The media described by an item may either be stored or streamed. A single content item may refer to multiple media binaries that represent different formats for the content being described.</dd>

        <dt><dfn id="dfn-channel-item">channel item</dfn></dt>
        <dd>For the purposes of this document, the term “channel item” refers to an “item” describing a streaming source. A channel item may contain metadata describing the channel source such as channel number, distribution network, etc. A channel may not be available on the home network, i.e. the “channel item” may refer to a channel that can only be locally tuned. In these cases “channel item” metadata will not provide network addressing information (URLs) to connect to the channel source.</dd>

        <dt><dfn id="dfn-epg-item">epg item</dfn> (electronic programming guide)</dt>
        <dd>For the purposes of this document, the term “epg item” refers to an item that may be available with some defined time range. An “epg item” may contain metadata describing the channel source for the content and the time range the channel media will be available.</dd>

        <dt><dfn id="dfn-record-schedule">record schedule</dfn> (item)</dt>
        <dd>For the purposes of this document, the term “record schedule” refers to an item which contains metadata describing a request to a network recording service to record content. “Record schedule items” may include: simple time/duration requests, recording of a specific <a href="#dfn-epg-item" class="internalDFN">epg item</a>, and recording dynamically selected <a title="epg item" href="#dfn-epg-item" class="internalDFN">epg items</a> based metadata properties of desired content. “Record schedule items” additionally include metadata describing the status of the recording request.</dd>

        <dt><dfn id="dfn-record-task">record task</dfn> (item)</dt>
        <dd>For the purposes of this document, the term “record task item” refers to an item which contains metadata describing a pending or completed network recording operation. “Record task items” are created by a network recording service and allow network record service clients to control pending recording operations. Additionally, “record task items” include metadata describing the status of the recording request and the identity of <a title="content item" href="#dfn-content-item" class="internalDFN">content items</a> that represent the results of network recording operations.</dd>
      </dl>
    </div>

    <div id="requirements" class="section">
      
<!-- OddPage -->
<h2><span class="secno">4. </span>Requirements</h2>

      <p>This section enumerates the requirements that conforming specification(s) would need to address to enable discovery and control of devices and services in the home network by a user agent. These requirements are directly motivated by the use cases described in this document (see <a href="#use-cases" class="sectionRef">section 5. Use Cases</a>) and are based on an interactive process of feedback from the discussions in the Home-Network Task Force of the Web and TV Interest Group.</p>

      <div id="general" class="section">
        <h3><span class="secno">4.1 </span>General</h3>

        <div id="compatibility-with-widely-deployed-standards" class="section">
          <h4><span class="secno">4.1.1 </span>Compatibility with widely deployed standards</h4>
          <p>Several home network protocols (e.g. UPnP and M-DNS/DNS-SD) are in popular use today for advertising and sharing content and services in a home network environment. <a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="shall">shall</em> set out requirements for an API that would enable interaction with those protocols.</p>
        </div>
      </div>

      <div id="discovery-and-advertising" class="section">
        <h3><span class="secno">4.2 </span>Discovery and Advertising</h3>

        <div id="service-discovery" class="section">
          <h4><span class="secno">4.2.1 </span>Service Discovery</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a means for applications to discover services advertised by devices and applications in the home network. Details of the advertising protocols are out of scope for this document and the type and number of supported discovery protocols is user agent dependent. Nevertheless <a href="#dfn-conforming-specifications" class="internalDFN">conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a means for application search for specific services and to be able to determine the means by which it should communicate with that service.</p>
        </div>

        <div id="application-discovery" class="section">
          <h4><span class="secno">4.2.2 </span>Application Discovery</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a means for applications running in different user-agents to discover each other directly via the home network. Details of the advertising protocol are out of scope for this document.</p>
        </div>

        <div id="content-discovery" class="section">
          <h4><span class="secno">4.2.3 </span>Content Discovery</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a means for applications to discover devices in the home network capable of serving content (content servers). In addition, <a href="#dfn-conforming-specifications" class="internalDFN">conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a mechanism to retrieve a list of the available content, provide additional information (metadata) about the content and to support negotiation of a supported content format between content servers and content players.</p>
        </div>

        <div id="content-advertisement" class="section">
          <h4><span class="secno">4.2.4 </span>Content Advertisement</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a means for applications to expose content descriptions to a service on the home network. Other devices or applications on the home network should be able to play back the content served by the application and retrieve additional metadata about the served content.</p>
        </div>
        
        <div id="services-advertisement" class="section">
          <h4><span class="secno">4.2.5 </span>Services Advertisement</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a means for applications to expose and advertise services on the home network.</p>
        </div>

        <div id="media-identification" class="section">
          <h4><span class="secno">4.2.6 </span>Media Identification</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide applications with a means to identify and thereby recognize a program that may be available from devices or services on the home network, when such an identifier is available. Such identifiers <em class="rfc2119" title="should">should</em> be unique to a program, but common across multiple instance of the same program; and <em class="rfc2119" title="should">should</em> be consistent across different services and devices in different home networks.</p>
        </div>
      </div>

      <div id="control-and-communication" class="section">
        <h3><span class="secno">4.3 </span>Control and Communication</h3>

        <div id="control-of-content-players" class="section">
          <h4><span class="secno">4.3.1 </span>Control of Content Players</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> enable applications to know what content can be presented by a device or service on the home network and control the playback of that content presented, in such a way that the application does not have to handle:</p>
          <ul>
            <li>issues of codec, container format, or transport protocol compatibility</li>
            <li>differences in the mechanisms by which content is delivered to the rendering device (e.g. received from broadcast vs. streamed from a media server)</li>
          </ul>
        </div>

        <div id="control-of-content-recorders" class="section">
          <h4><span class="secno">4.3.2 </span>Control of Content Recorders</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> enable applications to control recording of content presented by devices or services within the home network, in such a way that the application does not have to handle:</p>
          <ul>
            <li>issues of codec, container format, or transport protocol compatibility</li>
            <li>differences in the mechanisms by which content is delivered to the rendering device (e.g. received from broadcast vs. streamed from a media server)</li>
          </ul>
        </div>

        <div id="playback-of-content" class="section">
          <h4><span class="secno">4.3.3 </span>Playback of Content</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a means to play back content advertised by a home network content server.</p>
        </div>

        <div id="playback-of-live-content" class="section">
          <h4><span class="secno">4.3.4 </span>Playback of Live Content</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a means to play back live content advertised by a home network content server.</p>
        </div>

        <div id="x3-box-model" class="section">
          <h4><span class="secno">4.3.5 </span>3 Box Model</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a means for controlling the playback of content from home network content servers to home network content players. <a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> support means to negotiate a supported content type format that is available on the content server and is suitable for being played on the content player.</p>
        </div>

        <div id="time-synchronization" class="section">
          <h4><span class="secno">4.3.6 </span>Time-synchronization</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a means for applications to co-time the presentation of their own content (audio, video or other) with the timeline of a programme being played back on another device, including programmes being received via broadcast. <a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide applications with a means to be aware of the progress (time within the programme) of the playback of media content on a remote device/service, including programmes being received via broadcast.</p>
        </div>

        <div id="accurate-time-synchronization" class="section">
          <h4><span class="secno">4.3.7 </span>Accurate Time-synchronization</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> support any protocols or optional protocol features that enable applications to be aware of the progress (time within the programme) of the playback of a programme on a remote device to within frame accuracy (1/25th or 1/30th second) or better. <a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> support the ability to determine an estimate of the level of accuracy with which timing information about media playback on a remove device/service is conveyed to applications.</p>
        </div>

        <div id="service-communication" class="section">
          <h4><span class="secno">4.3.8 </span>Service Communication</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a means for an application to exchange messages directly via the home network with services discovered in the home network.</p>
        </div>

        <div id="application-communication" class="section">
          <h4><span class="secno">4.3.9 </span>Application Communication</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a means for applications to exchange messages directly via the home network with other applications running on a different user agent in the home network.</p>
        </div>

        <div id="content-protection" class="section">
          <h4><span class="secno">4.3.10 </span>Content Protection</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> support the content protection mechanism for a content item used by a content server in order to play back that content item. <a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="must">must</em> provide a graceful failure model when a content protection mechanism is not supported.</p>
        </div>
      </div>

      <div id="migration" class="section">
        <h3><span class="secno">4.4 </span>Migration</h3>
        
        <div id="push-migration" class="section">
          <h4><span class="secno">4.4.1 </span>Push Migration</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a means to transfer an application to a different user agent in the home network without requiring support of an application server.</p>
        </div>

        <div id="pull-migration" class="section">
          <h4><span class="secno">4.4.2 </span>Pull Migration</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> support transfering an application to a different user agent in the home network without requiring support of an application server. The request is initiated by the target user agent.</p>
        </div>
      </div>

      <div id="security-and-privacy" class="section">
        <h3><span class="secno">4.5 </span>Security and Privacy</h3>
        
        <div id="application-trust-level" class="section">
          <h4><span class="secno">4.5.1 </span>Application Trust Level</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> provide a means to define the trust level of an application. Determining the trust level may involve interaction with the user and the use of security mechanisms such as password, PIN etc.</p>
        </div>

        <div id="access-to-home-network-services" class="section">
          <h4><span class="secno">4.5.2 </span>Access to Home Network Services</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> allow access to home network devices and services only to trusted applications.</p>
        </div>

        <div id="prevent-leaking-of-information" class="section">
          <h4><span class="secno">4.5.3 </span>Prevent Leaking of Information</h4>
          <p><a href="#dfn-conforming-specifications" class="internalDFN">Conforming specifications</a> <em class="rfc2119" title="should">should</em> prevent unauthorized transfer of information outside the home network.</p>
        </div>
      </div>
    </div>

    <div id="use-cases" class="section">
      
<!-- OddPage -->
<h2><span class="secno">5. </span>Use Cases</h2>

      <p>This section is a non-exhaustive list of use cases that would be enabled by one (or more) specifications implementing the requirements listed above. Each use case is written according to the following template:</p>

      <dl>
        <dt>Ux. &lt;TITLE&gt;</dt>
        <dd>Use case title</dd>
        
        <dt>Description</dt>
        <dd><ul>
          <li>High level description/overview of the goals of the use case</li>
          <li>Schematic illustration (devices involved, work flows, etc.) (Optional)</li>
        </ul></dd>

        <dt>Motivation</dt>
        <dd><ul>
          <li>Explanation of the benefit to the ecosystem</li>
          <li>Why existing standards cannot be used to accomplish this use case</li>
        </ul></dd>

        <dt>Dependencies</dt>
        <dd>Other use cases, proposals or other ongoing standardization activities which this use case is dependent on or related to.</dd>

        <dt>Requirements</dt>
        <dd>List of requirements implied by this Use Case.</dd>
      </dl>

      <div id="u1.-service-user-interface" class="section">
        <h3><span class="secno">5.1 </span>U1. Service User Interface</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>An application as an interface to a service: the application provides a remote user interface for a device (light switch, HiFi volume control, radio station chooser, etc.) or a service on a device (remote control on the media player software on a computer).</p>

            <p>Possible implementation:</p>
            <ul>
              <li>the application discovers services with a discovery protocol, selects one service of a certain expected type, e.g. a media renderer service.</li>
              <li>the application binds to it and provides a UI for it.</li>
              <li>on user interaction, the application sends the messages to set the content url to play then play, pause, ... to the media renderer service, with appropriate parameters.</li>
            </ul>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <p>There is no standard interface to discovery protocols in existing standards implemented in connected devices. There is no standard interface to service communication protocols in existing standards implemented in connected devices. What should be standardized is:</p>
            <ul>
              <li>an interface to get a list of discovered services;</li>
              <li>an interface to get the list of messages exposed by a discovered service;</li>
              <li>an interface to send a message to a discovered service;</li>
              <li>an interface to set a listener for messages from a discovered service.</li>
            </ul>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <p>In order to interface with a service, the application first needs to discover the service (or the device, then the service on the device).</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>Determine list of discovered services</td>
              <td><a href="#service-discovery" class="sectionRef">section 4.2.1 Service Discovery</a></td>
            </tr>
            <tr>
              <td>Determine list of discovered services</td>
              <td><a href="#service-discovery" class="sectionRef">section 4.2.1 Service Discovery</a></td>
            </tr>
            <tr>
              <td>Send a message to a discovered service</td>
              <td><a href="#service-communication" class="sectionRef">section 4.3.8 Service Communication</a></td>
            </tr>
            <tr>
              <td>Listen to messages (possibly unsolicited) from a discovered service</td>
              <td><a href="#service-communication" class="sectionRef">section 4.3.8 Service Communication</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>
      
      <div id="u2.-discovered-content-host" class="section">
        <h3><span class="secno">5.2 </span>U2. Discovered Content Host</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>A document as host for discovered content: e.g. the document describe content provided by a local, discovered device or service.</p>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <p>Rendering a media on another device than the one hosting is the basic step to enable more complex use cases.</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>Support a document which displays discovered content</td>
              <td><a href="#playback-of-content" class="sectionRef">section 4.3.3 Playback of Content</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u3.-service-migration" class="section">
        <h3><span class="secno">5.3 </span>U3. Service Migration</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>An application moving across HNTF user agents in a decentralized situation (local application, without a server).</p>
            <p>A radio service is split into a radio application which resides typically on a HiFi, TV, personal music player or computer, and a radio controller application which resides on a device with intuitive interaction capability such as a phone, computer or tablet. The radio application is implemented as a document exposing a service interface on the network, and has a state that needs preserving if the document is migrated. The radio controller application is a pure interface, and does not have its own state.</p>
            <p>The radio application does not have a visual interface. The radio application exposes a service of type JCDsRadioApp with seven possible messages:</p>
            <ul>
              <li>setURI(radioStationURI, radioName),</li>
              <li>play(),</li>
              <li>stop(),</li>
              <li>setVolume(n),</li>
              <li>getURI(),</li>
              <li>getRadioName(),</li>
              <li>getPlayState(),</li>
              <li>getVolume().</li>
            </ul>
            <p>The radio application is running on a TV set.</p>
            <p>The radio controller application has a visual interface, comprising:</p>
            <ul>
              <li>a button to choose the radio station.</li>
              <li>a play button.</li>
              <li>a stop button.</li>
              <li>a label for the current radio station name.</li>
              <li>a volume bar to display the current volume.</li>
              <li>two buttons to increase and decrease the volume.</li>
            </ul>
            <p>The radio controller application is running on a smartphone. The radio controller application looks for a service called JCDsRadioApp by using the HNTF discovery mechanism, then establishes a connection with the above application. The radio controller application gets the radio name, volume, play state of the radio application and displays that information.</p>
            <p>The stage is now set.</p>
            <p>The user wants to move from the TV in the main room to the computer in her office:</p>
            <ul>
              <li>In the HNTF user agent on the TV, the user requests to migrate the radio application.</li>
              <li>The TV HNTF UA looks for other HNTF UAs on the network, by discovering service &quot;HNTFUserAgentv1.0&quot;.</li>
              <li>The result of the discovery is a list of HNTF UAs: the one on the phone, the one on the computer, possibly other ones.</li>
              <li>The user selects the HNTF UA running on the computer.</li>
              <li>The TV HNTF UA sends the message migrate(appURI, contextURI) to the computer HNTF UA.</li>
              <li>The computer HNTF UA requests the appURI to get the radio application, then requests the contextURI, which contains all the information needed to place the radio application in the same state it was in on the TV.</li>
              <li>The computer HNTF UA loads the radio application, then the context. Loading the context first sets the volume to half and the station to &quot;Jazz&quot;.</li>
              <li>Then the computer HNTF UA exposes a service of type JCDsRadioApp.</li>
              <li>Then the smartphone HNTF UA understands that its connection to the radio application in the TV is down, so it starts again a discovery of service type JCDsRadioApp. It finds one on the computer HNTF UA, and sends a connection request.</li>
              <li>The computer HNTF UA receives a connection request from the device mentioned in the migration context as formerly connected. It accepts the connection without requiring a user validation.</li>
            </ul>
            <p>End of migration.</p>
            <p>When moving the radio document, the following needs to be preserved:</p>
            <ul>
              <li>the service needs to be restarted and exposed on the new device</li>
              <li>the connection to the (same) radio controller needs to be reestablished</li>
              <li>the radio needs to be playing the same station, with the same volume, etc.</li>
            </ul>
            <p>Another possible example is a multi-user game, e.g. with lots of players sending location and activity information about their character/cars. Upon migration, the game state needs to be transferred to the new device, and the connections to other players need to be reestablished.</p>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <ul>
              <li>no way to discover a service from an application</li>
              <li>no way to expose a service from an application</li>
              <li>no way to move an application to another device and restart it while keeping an execution context</li>
            </ul>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <p>This use case depends on discovery. This is a refinement of ISSUE-15, where the migrated document uses a service rather than exposes a service.</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>User-Agents support a service to transfer a running Application to different User-Agent.</td>
              <td><a href="#push-migration" class="sectionRef">section 4.4.1 Push Migration</a></td>
            </tr>
            <tr>
              <td>Applications support the ability to save their current state and provide this information via a contextURI.</td>
              <td><a href="#push-migration" class="sectionRef">section 4.4.1 Push Migration</a></td>
            </tr>
            <tr>
              <td>Applications support the ability to restore their state on a different User-Agent using state information provided by a contextURI.</td>
              <td><a href="#push-migration" class="sectionRef">section 4.4.1 Push Migration</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u4.-service-distribution" class="section">
        <h3><span class="secno">5.4 </span>U4. Service Distribution</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>An application spawning other applications on other devices and communicating with them: e.g. the TV set receives and renders an application implementing some voting; the application discovers multiple phones in the home, proposes to activate voting interfaces on each of the viewers' phones, communicates with the voting interfaces, collates votes and sends them back to the channel's voting service.</p>
            <p>Possible implementation:</p>
            <ul>
              <li>The TV receives a connected TV application for voting, which starts automatically.</li>
              <li>The application exposes a service on the HN to collect votes and forward them to the TV channel.</li>
              <li>The application discovers personal interactive devices (phones and tablets for our case) running the HNTF document UA which exposes a recognizable service.</li>
              <li>The application sends a <i>suggest</i> message with a URL to a voting interface.
              </li><li> Willing users accept the suggested migration and their UA loads the voting interface.
              </li><li> The voting interface document loads and discovers and binds to the vote collecting service.
              </li><li> The user votes
              </li><li> The voting interface document sends a <i>vote</i> message to the vote collecting service.
              </li><li> The vote collecting service exposed by the TV application receives the <i>vote</i> message and forwards them for a certain voting period.
              </li><li> At the end of the show (or of the voting period), the application is killed by the TV system, so the voting collection service disappears.
              </li><li> Seeing the voting collection service disappear, the voting interfaces may shut down.
            </li></ul>
            <p>This use case does not require new technology, but reuses technology required by other use cases. Technologies required by other use cases are:</p>
            <ul>
              <li>the ability to discover</li>
              <li>the ability to expose a service</li>
            </ul>
            <p>This use case requires:</p>
            <ul>
              <li>the HNTF UAs to implement a service which could be called &quot;HNTF service&quot;, so that documents can discover other &quot;HNTF UAs&quot;</li>
              <li>the HNTF service to include a &quot;suggest&quot; message telling the UA to please render a document given by URL</li>
              <li>maybe the HNTF service to include a message allowing a document to determine its capabilities, to be able to segregate between devices appropriate for voting or not.</li>
            </ul>
            <p>A few sketches for clarification:</p>
            <p><a href="ServiceDistributionUC1.jpg"><img alt="Step 1: TV receives voting document from a server" src="ServiceDistributionUC1.jpg" width="600" height="450" /></a></p>
            <p><a href="ServiceDistributionUC2.jpg"><img alt="Step 2: document discovers devices" src="ServiceDistributionUC2.jpg" width="600" height="450" /></a></p>
            <p><a href="ServiceDistributionUC3.jpg"><img alt="Step 3: document spawns sub-documents (by reference)" src="ServiceDistributionUC3.jpg" width="600" height="450" /></a></p>
            <p><a href="ServiceDistributionUC4.jpg"><img alt="Step 4: devices which approved spawn fetch sub-documents" src="ServiceDistributionUC4.jpg" width="600" height="450" /></a></p>
            <p><a href="ServiceDistributionUC5.jpg"><img alt="Step 5: local communication between documents" src="ServiceDistributionUC5.jpg" width="600" height="450" /></a></p>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <p>This is the generic version of a crucial &quot;second screen&quot; usage scenario.</p>
            <p>As there are more devices in the home, some generic and some task-specific, and with varying capabilities (including different UI methods), there is a growing need to spread an application across different devices to achieve service distribution. But the service usually &quot;enters&quot; the home network through one particular device. The service running entirely on the initial device, as part of other use cases, can discover its environment and determine that other devices could meaningfully contribute to the quality of experience. From then on, the service needs to send part of &quot;itself&quot; to other devices.</p>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <ul>
              <li><a href="#u1.-service-user-interface" class="sectionRef">section 5.1 U1. Service User Interface</a></li>
              <li><a href="#u6.-application-exposing-a-service" class="sectionRef">section 5.6 U6. Application Exposing a Service</a></li>
              <li><a href="#u7.-application-discovering-a-service" class="sectionRef">section 5.7 U7. Application Discovering a Service</a></li>
            </ul>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>A document exposes an interface to a service</td>
              <td><a href="#service-discovery" class="sectionRef">section 4.2.1 Service Discovery</a>
              <br /><a href="#service-communication" class="sectionRef">section 4.3.8 Service Communication</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u5.-3-box-model" class="section">
        <h3><span class="secno">5.5 </span>U5. 3-Box Model</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>A document as an interface coordinating action between other services. In the most obvious example, a document discovers media content sources and media players. The document allows the user to select a source and a player, then control playback (Play, pause, rewind, etc.) of the content to the player.</p>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <p>Assets offered by one service (on one device) can be consumed by another service (on another device) and controlled by a separate controlling document (on a third device). Vendors can offer control services to manage services across the whole home.</p>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <p>This is similar to Service User Interface (see <a href="#u1.-service-user-interface" class="sectionRef">section 5.1 U1. Service User Interface</a>) but it explicitly manages services between independent devices, multiple simultaneous </p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>An application may invoke services to control devices on other User-Agents separate from the User-Agent issuing the service requests</td>
              <td><a href="#x3-box-model" class="sectionRef">section 4.3.5 3 Box Model</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u6.-application-exposing-a-service" class="section">
        <h3><span class="secno">5.6 </span>U6. Application Exposing a Service</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>An application exposes a service on the home network. In order to allow this with some technologies, it may be necessary for the HNTF user agent to advertise itself on the HN as a device. For example, an application rendered on a connected TV has access to the connected TV API for EPG information. Other devices on the HN do not have access to this information. The application implements a service exposing the EPG information and makes it discoverable by other devices.</p>
            <p>Possible implementation:</p>
            <ul>
              <li>the application A is a TV-broadcast-related application, which is allowed to call the function returning the description of the next program.</li>
              <li>the application A exposes a service with one message getNextProgramDescription.</li>
              <li>application B on another device discovers the service (not knowing that it is an application, it is just another service to application B).</li>
            </ul>
            <p>Neither application A or B know the actual nature of the other. They may have an IP address, and they share a service type.</p>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <p>Allowing sharing resources other than content, such as a capability (a large screen, a sensor) or an &quot;authorization&quot; (permission to use a restricted API).</p>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <p>This is a prerequisite to applications discovering each other without a &quot;middle man&quot;: one of the two applications exposes a service that the other application may discover.</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>An application can cause a User-Agent to act as a device which exposes services</td>
              <td><a href="#services-advertisement" class="sectionRef">section 4.2.5 Services Advertisement</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u7.-application-discovering-a-service" class="section">
        <h3><span class="secno">5.7 </span>U7. Application Discovering a Service</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>An application discovers a service. Discovery means that after discovery, the application has:</p>
            <ul>
              <li>an identification of a device (maybe) and a service;</li>
              <li>a means to know the messages that can be exchanged, possibly with their parameters;</li>
              <li>a means to send messages to the service, if the service may receive messages;</li>
              <li>a means to receive messages from the service, if the service may send messages.</li>
            </ul>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <p>Very basic use case, on which all other use cases depend. There is no existing way for an application to discover services and communicate with them, if the author did not have the address of the service.</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>An application can determine allowable messages and parameters provided by a service</td>
              <td><a href="#service-discovery" class="sectionRef">section 4.2.1 Service Discovery</a></td>
            </tr>
            <tr>
              <td>An application can send messages to a service</td>
              <td><a href="#service-communication" class="sectionRef">section 4.3.8 Service Communication</a></td>
            </tr>
            <tr>
              <td>An application can receive messages from a service</td>
              <td><a href="#service-communication" class="sectionRef">section 4.3.8 Service Communication</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u8.-application-push-migration" class="section">
        <h3><span class="secno">5.8 </span>U8. Application Push-Migration</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>An application moving across devices in a decentralized situation (local application, without a server).</p>
            <p>I start using my phone for the user interface to a device and then my tablet becomes available, so I move the interface application to the tablet. The application in question is an HNTF application, which means it has discovered services and has connections to some services and a history of execution. Just restarting the application on another device would lose the execution state, the existing connections, etc...</p>
            <ul><li> I start using my phone as a UI of a service on my TV, e.g. EPG, but the screen is small.
            </li><li> My tablet finally becomes available.
            </li><li> I request the migration of the current application: this is a user agent function.
            </li><li> The user agent discovers its peers on the network, i.e. other user agents capable of running the current document.
            </li><li> The user agent proposes to me a list of suitable user agents, including the one running on the tablet.
            </li><li> I choose the user agent running on the tablet.
            </li><li> The UA on the phone binds to the UA on the tablet, and sends a migration message with the URL of the document, and the URL of the execution state.
            </li><li> The UA on the tablet receives the migration message, fetches the application and the execution state and loads both.
            </li><li> The UA on the tablet signals to the UA on the phone that migration is complete, by replying &quot;success&quot; to the migration message.
            </li><li> The UA on the phone stops rendering the migrated application.
            </li><li> I pick up the tablet and go on with the service at the point I left it on the phone.
            </li></ul>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <p>There is no way with current standards and in the absence of a central server to achieve the saving and transfer of the execution state of a widget, so there is no way to start an application on a device, switch devices and restart the application on the new device, keeping the exact same execution state.</p>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <p>This use case depends on discovery.</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>User-Agents support a service to transfer a runningapplication from another User-Agent to itself</td>
              <td><a href="#push-migration" class="sectionRef">section 4.4.1 Push Migration</a></td>
            </tr>
            <tr>
              <td>Applications support the ability to save their current state and provide this information via a contextURI</td>
              <td><a href="#push-migration" class="sectionRef">section 4.4.1 Push Migration</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u9.-application-pull-migration" class="section">
        <h3><span class="secno">5.9 </span>U9. Application Pull-Migration</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>An application moving across devices in a decentralized situation (local application, without a server), <strong>the migration being initiated on the target device</strong>.</p>
            <p>I start using my phone for the user interface to a device and then my tablet becomes available, so I move the interface application to the tablet by interacting with the tablet. The application in question is an HNTF application, which means it has discovered services and has connections to some services and a history of execution. Just restarting the application on another device would lose the execution state, the existing connections, etc...</p>
            <ul>
              <li>I start using my phone as a UI of a service on my TV, e.g. EPG, but the screen is small.</li>
              <li>My tablet finally becomes available.</li>
              <li>I drop my phone.</li>
              <li>I take the tablet, start the HNTFUA and request a list of discoverable HNTFUAs on the tablet: this is a user agent function.</li>
              <li>I start the HNTFUA of the phone and request from it a list of pullable applications and I choose one in the list.</li>
              <li>The UA on the tablet sends a pull-migration message with the identifier of the wanted application chosen from the above list.</li>
              <li>The UA on the tablet receives the response to the pull-migration message, i.e. the url of the application and the url of the execution state, fetches the application and the execution state and loads both.</li>
              <li>The UA on the tablet signals to the UA on the phone that migration is complete.</li>
              <li>The UA on the phone stops rendering the migrated application.</li>
            </ul>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <p>Same as ISSUE-15, with the additional twist of triggering the migration from the target device rather than the source device.</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>User-Agents support a service to notify a running application of a request to transfer itself to another User-Agent</td>
              <td><a href="#pull-migration" class="sectionRef">section 4.4.2 Pull Migration</a></td>
            </tr>
            <tr>
              <td>Applications support the ability to save their current state and provide this information via a contextURI</td>
              <td><a href="#pull-migration" class="sectionRef">section 4.4.2 Pull Migration</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u10.-media-identification" class="section">
        <h3><span class="secno">5.10 </span>U10. Media Identification</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>Where available, applications should be able to determine and refer to programmes using a unique and consistent identifier. If the same programme is available from multiple devices or services, the programme should have the same identifier associated with it across all devices or services.</p>
            <p>Scenario: An application, wants to present more information associated with a particular programme that the user is currently viewing on their television, without the television acting as an intermediary that serves that additional information.</p>
            <ol>
              <li>The application discovers an appropriate service</li>
              <li>The application sends a request to the service to return an identifier for the programme currently playing on the television</li>
              <li>The application discovers a service that can return metadata for an identified programme</li>
              <li>The application sends a request to the service to retrieve a unique identifier for the programme that was assigned by the original broadcaster, content publisher or content creator</li>
              <li>The application contacts an internet service that can resolve identifiers to additional programme metadata</li>
              <li>The internet service returns additional metadata for the programme</li>
            </ol>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <ul>
              <li>Allows anyone (not just the original content creator or distributor) to create an application that can associate programmes with metadata and web based content; without that metadata or content having to be delivered, or referenced by data served from services on the television or set top box.</li>
              <li>Recommendations to be fed to any groups defining home network protocols to add global content identifier support where not present</li>
              <li>Areas for standardization: (Application specific API/protocols)
              <ul>
                <li>Requirement for any high level media playback API abstractions (see issue-20) should include the ability to:
                <ul>
                  <li>expose such identifiers as part of programme metadata</li>
                  <li>search for programmes using such identifiers</li>
                  <li>request playback of a programme using such an identifier</li>
                </ul></li>
                <li>This use case does not suggest mandating a particular identifier format.</li>
              </ul>
              </li>
            </ul>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <p><a href="#u11.-tv-control" class="sectionRef">section 5.11 U11. TV Control</a> (for outlined user scenario)</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>Provide consistent program identifiers which are meaningful across multiple devices</td>
              <td><a href="#media-identification" class="sectionRef">section 4.2.6 Media Identification</a></td>
            </tr>
            <tr>
              <td>Provide a means to obtain metadata corresponding to program identifiers</td>
              <td><a href="#media-identification" class="sectionRef">section 4.2.6 Media Identification</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u11.-tv-control" class="section">
        <h3><span class="secno">5.11 </span>U11. TV Control</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>An API, or service, for simplified control of key functionality of television devices, including those with integrated broadcast receivers and limited or no media streaming capabilities. The application defines its own user interface, independent of the user interface of the television device.</p>
            <p>Application developers would benefit from a simplified API or services that provide:</p>
            <ul>
              <li>A single unified directory of programmes that a given rendering device (e.g. television display) is able to obtain and play. The application does not have to check, for itself, across multiple sources of content and for any issues of codec, container format, and transport protocol compatibility.</li>
              <li>A single simple method for requesting a programme or channel to be presented by a rendering device, irrespective of the above factors.</li>
            </ul>
            <p>It is also desirable to be able to control other common aspects of television functionality through the same API.</p>
            <p>The target of the API would be a processing engine on the home network. For a Javascript API this processing engine could be incorporated into the user agent. Alternatively, it could be implemented by any other device on the home network, including the television device itself. For the latter case, the user agent must be able to discover and communicate with the processing engine in order to execute the functions of the API.</p>
            <p>The processing engine may, when appropriate, utilize existing home networking protocols to perform its function. For example: it may use UPnP AV services to discover and stream content.</p>
            <p>Scenario 1: Basic programme guide application: The application uses the API to perform the following tasks:</p>
            <ul>
              <li>The application sends a request to discover television devices on the home network</li>
              <li>The application sends a request to ask for the identity of the programme currently being presented on the television, and the source (e.g. television channel)</li>
              <li>The application sends a request to retrieve basic programme metadata (title, description, start and end times) and displays this for the user</li>
              <li>The application sends a request to retrieve a list of sources (e.g. channels) of programmes that can be displayed on the television</li>
              <li>The application sends a request to retrieve a list of programmes, and their basic metadata for those sources for presentation to the user</li>
              <li>The application sends a request to cause a given channel or programme be played on the television.</li>
            </ul>
            <p>Extension to scenario 1: Control of other television functions:</p>
            <ul>
              <li>The application can send a request to change the volume of the television</li>
              <li>The application can enable or disable accessibility features such as subtitles or audio-description</li>
              <li>The application can request to seek (jump to a different time point) within the programme being played</li>
            </ul>
            <p>Scenario 2: A web site with material supporting a particular programme wants to be able to offer to play the programme on a television if it is available. A possible interaction (via the API):</p>
            <ul>
              <li>The application sends a request to discover television devices on the home network</li>
              <li>The application makes a request to query if a specific programme is available to the television. If it is available, the application offers the choice to the user to display it.</li>
              <li>If the user accepts, the application requests that programme be played on the television.</li>
            </ul>
            <p>Each of the interactions described should be ideally achievable a single call to an API or service method.</p>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <ul>
              <li>Simplify creation of applications that will work with a range of devices and variety of means by which a given programme might played on the television.</li>
              <li>Standardization could facilitate a new ecosystem of interfaces.</li>
              <li>Existing standards for home network communication are not commonly available from the browser context and expose functionality at a lower level.</li>
              <li>What could be standardized:
              <ul>
                <li>Type of use case: Application specific services / protocols / APIs</li>
                <li>A Javascript API</li>
                <li>Service(s) for television type devices on the home network</li>
              </ul>
              </li>
            </ul>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <ul>
              <li><a href="#u7.-application-discovering-a-service" class="sectionRef">section 5.7 U7. Application Discovering a Service</a></li>
              <li>Scenario 2 requires <a href="#u10.-media-identification" class="sectionRef">section 5.10 U10. Media Identification</a></li>
            </ul>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>Provide a directory of programs a rendering device can play</td>
              <td><a href="#control-of-content-players" class="sectionRef">section 4.3.1 Control of Content Players</a></td>
            </tr>
            <tr>
              <td>Provide a service to select a program on a rendering device to play</td>
              <td><a href="#control-of-content-players" class="sectionRef">section 4.3.1 Control of Content Players</a></td>
            </tr>
            <tr>
              <td>Provide services to control other aspects of a rendering device such as Seek, Volume, etc.</td>
              <td><a href="#control-of-content-players" class="sectionRef">section 4.3.1 Control of Content Players</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u12.-time-synchronization" class="section">
        <h3><span class="secno">5.12 </span>U12. Time Synchronization</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>Applications should be able to time synchronize their activity with the time-line of a programme being played on a television or other home media rendering device.</p>
            <p>Application developers will benefit from having a single simple API that provides a unified interface to this functionality, irrespective of the means by which the programme is being delivered to, or played by, the television device.</p>
            <p>The application is running on a different device from where the programme is being played. This could be a laptop, mobile phone, tablet, etc. Both devices are on the same home network. The device playing the programme may be a television or other media rendering device. The programme being played may be being obtained by a variety of different means:</p>
            <ul>
              <li>from a live broadcast via an integrated tuner</li>
              <li>playback from local storage (e.g. a Personal Video Recorder device)</li>
              <li>streaming from another device on the home network</li>
              <li>streaming from an on-demand internet service</li>
            </ul>
            <p>The target of the API would be a processing engine on the home network. For a Javascript API this processing engine could be incorporated into the user agent. Alternatively, it could be implemented by any other device on the home network, including the television device itself. For the latter case, the user agent must be able to discover and communicate with the processing engine in order to execute the functions of the API.</p>
            <p>The processing engine may, when appropriate, utilize existing home networking protocols to perform its function. For example: it may use UPnP AV services to query and set the playback time index.</p>
            <p>An API meeting these requirements may enable an application to:</p>
            <ul>
              <li>request the current playback time index of the programme being played on a given device</li>
              <li>command the device to jump to a different playback time index</li>
              <li>request notification when programme playback reaches a particular moment or time interval in the programme timeline.</li>
            </ul>
            <p>Scenario: An application wants to present a slideshow of content relating to the programme the user is watching on their television. As the programme progresses, the slideshow automatically moves onto the correct slide for any given point in the programme. If it is possible to seek within the programme timeline (because the programme is not being watched from a live broadcast), the user can use the application to jump to a different point in the presentation and the television will also seek to the corresponding segment of the programme.</p>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <ul>
              <li>Simplify creation of applications that will work with a range of devices and variety of means by which a given programme might played on the television.</li>
              <li>Enable the creation of added-value viewing experience for the user where additional information is available in a timely fashion without interrupting the TV viewing experience or increasing on screen 'clutter'.</li>
              <li>What could be standardized:
              <ul>
                <li>Type of use case: Application specific services / protocols / APIs</li>
                <li>A Javascript API</li>
                <li>Services or protocols implemented by devices on the home network</li>
              </ul></li>
            </ul>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <ul>
              <li><a href="#u7.-application-discovering-a-service" class="sectionRef">section 5.7 U7. Application Discovering a Service</a></li>
              <li><a href="#u10.-media-identification" class="sectionRef">section 5.10 U10. Media Identification</a> required for an application to know which content to provide for the programme being watched in the described scenario.</li>
              <li>This use case could be considered an extension of <a href="#u11.-tv-control" class="sectionRef">section 5.11 U11. TV Control</a></li>
            </ul>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>Provide ability to generate notification to application when a particular playback time is reached</td>
              <td><a href="#time-synchronization" class="sectionRef">section 4.3.6 Time-synchronization</a></td>
            </tr>
            <tr>
              <td>Provide the ability to position playback to a specified time-index</td>
              <td><a href="#time-synchronization" class="sectionRef">section 4.3.6 Time-synchronization</a></td>
            </tr>
            <tr>
              <td>Obtain the current playback time-index</td>
              <td><a href="#time-synchronization" class="sectionRef">section 4.3.6 Time-synchronization</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u13.-lip-sync-time-synchronization" class="section">
        <h3><span class="secno">5.13 </span>U13. Lip Sync Time Synchronization</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>This use case is a specialization of the use case Time Synchronisation (see <a href="#u12.-time-synchronization" class="sectionRef">section 5.12 U12. Time Synchronization</a>)</p>
            <p>An application should be able to synchronize the presentation of its own content with a high degree of accuracy to the timeline of a programme being played on a television or other home media rendering device. The level of accuracy should be sufficient to achieve 'lip-sync' between audio and video (typically within 1 to 2 video frames or tens of milliseconds).</p>
            <p>In addition to the functions described in the Time Synchronisation use case; the API used by the application should be able to:</p>
            <ul>
              <li>report an estimate of the timing synchronism accuracy that is achievable</li>
              <li>provide synchronization to within lip-sync accuracy if all devices involved support it</li>
            </ul>
            <p>The processing engine that implements the API may utilize existing home networking protocols to achieve the required accuracy. A likely necessary component will be the synchronization of clocks between the television or media rendering device and the device on which the application is running. Possible protocols that might be used to achieve this include: Precision Time Protocol (IEEE 1588-2002) [<cite><a class="bibref" rel="biblioentry" href="#bib-IEEE1588">IEEE1588</a></cite>], IEEE 802.1AS [<cite><a class="bibref" rel="biblioentry" href="#bib-IEEE802-1AS">IEEE802-1AS</a></cite>], UPnP Precision Time Synchronization [<cite><a class="bibref" rel="biblioentry" href="#bib-UPNP-AVT3">UPNP-AVT3</a></cite>].</p>
            <p>Applications will benefit if the API presents a simple unified set of functions such that the application does not need know which protocols are being used.</p>
            <p>Scenario: An application plays alternative audio that is time synchronized to a programme that the user is watching. The synchronization is sufficiently accurate to maintain 'lip-sync' between the alternative audio and the programme video. The alternative audio may be delivered to the application independently of the television device - such as via a direct stream from a broadcaster's internet based server.</p>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <ul>
              <li>Simplify creation of applications requiring lip-sync accurate time synchronization that will work with a range of devices and variety of means by which a given programme might be played on the television.</li>
              <li>What could be standardized:
              <ul>
                <li>Type of use case: Application specific services / protocols / APIs</li>
                <li>A Javascript API</li>
                <li>Services or protocols implemented by devices on the home network</li>
              </ul>
              </li>
            </ul>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <p>This use case is a specialization of the Time Synchronization use case (see <a href="#u12.-time-synchronization" class="sectionRef">section 5.12 U12. Time Synchronization</a>)</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>Determine the time synchronization capabilities of home-network devices</td>
              <td><a href="#accurate-time-synchronization" class="sectionRef">section 4.3.7 Accurate Time-synchronization</a></td>
            </tr>
            <tr>
              <td>Provide the capability for applications to synchronize with playback content to approximately frame resolution</td>
              <td><a href="#accurate-time-synchronization" class="sectionRef">section 4.3.7 Accurate Time-synchronization</a></td>
            </tr>
            <tr>
              <td>Provide the capability to precisely synchronize multiple content streams</td>
              <td><a href="#accurate-time-synchronization" class="sectionRef">section 4.3.7 Accurate Time-synchronization</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u14.-local-link-of-web-applications" class="section">
        <h3><span class="secno">5.14 </span>U14. Local Link of Web Applications</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>This use case is about the bi-directional communication between web applications via the local IP network e.g. Home IP network.</p>
            <p>Assumptions:</p>
            <ul>
              <li>User devices are connected to the same local IP network</li>
              <li>The applications on user devices know each other and can exchange messages for communications</li>
              <li>Note that the applications may not necessarily be provided by the same distributor or service provider</li>
              <li>A user uses the IR remote controller to operate the HTML5 browser on the TV device (10 feet UI)</li>
              <li>A user uses the touch screen to operate the HTML5 browser on the tablet device or smart phone (Touch UI)</li>
              <li>Note that the application may not necessarily to be a web application as long as it communicates by the same network protocols as the user-agent does.</li>
            </ul>
            <p>User Scenario A - Single User:</p>
            <ul>
              <li>Bob operates the TV device to watch movies on an online video service</li>
              <li>Bob also operates the tablet device to access a social network service about movies</li>
              <li>Bob views web pages of the social network service and find a favorite movie</li>
              <li>Bob clicks the “your device” button on the web page of the social network service</li>
              <li>The application on the TV device show the web page of the video service about the movie, then Bob starts to watch the movie</li>
            </ul>
            <p>User Scenario B - Multiple Users:</p>
            <ul>
              <li>Bob operates his smart phone to use an application for a picture service</li>
              <li>Alice operates her smart phone to access another picture application</li>
              <li>Bob selects his favorite picture and clicks the “Sharing photo with other device” on the application</li>
              <li>The application on Bob’s device shows the device name list and he selects the Alice’s device</li>
              <li>The picture file is transferred from the Bob’s device to the Alice’s device while each application shows the progress bar of file transfer</li>
              <li>After the transfer is completed, the application on the Alice’s device shows the Bob’s favorite picture</li>
            </ul>
            <p>User Scenario - Interactive Quiz:</p>
            <ul>
              <li>Alice and Bob operates the TV device to watch a quiz programme, from live broadcast</li>
              <li>Alice and Bob also operate their smart phones to access a quiz application</li>
              <li>Note: The smart phone quiz application knows that the quiz programme is being watched on the TV and establishes communication with an interactive application on the TV that is active during the quiz programme)</li>
              <li>The TV application overlays on-screen information informing Alice and Bob that they are now taking part in the quiz.</li>
              <li>As a question is asked in the quiz programme, the interactive TV application instructs Alice and Bob's smart phone quiz applications to ask Alice and Bob the same questions. Alice and Bob enter answers to the questions using their smart phones, which are relayed back to the interactive TV application.</li>
              <li>Between quiz rounds, Alice and Bob's scores are displayed on their smart phones and overlayed on screen by the TV interactive application. Scores are compared to those of the contestants featuring in the programme.</li>
              <li>Note: Regarding need/justification: Using local-link communication to an interactive application provided as part of a broadcast stream provides a way around scalability concerns if participation is substantial for a particularly popular programme.</li>
            </ul>
            <p>Use case (System Interactions):</p>
            <ul>
              <li>A User-Agent discovers other Users agent on the same IP-sub network</li>
              <li>Via API, the User-Agent provides the discovered application list which contains the applications which are running on other user-agent, e.g. application id, the URL for message exchange, physical device name(for user selection)</li>
              <li>The application establishes the bi-directional communication for message exchanges with the application on the other user-agent via API</li>
            </ul>
            <p>Implementation examples:</p>
            <ul>
              <li>For the local discovery, the HTML5 browser implements UPnP Discovery to provide the generic discovery API to find applications on the same IP sub-network</li>
              <li>For the message exchange, the HTML5 browser implements the extended WebSocket protocol and APIs for bi-directional communications</li>
              <li>The HTML5 browser should implement some mechanism to confirm the user consensus to permit the device discovery and message exchanges for the applications</li>
            </ul>
            <p>Additional comments:</p>
            <ul>
              <li>The above user scenarios are examples. As long as the message exchange API is service/application agnostic, many rich user experience can be realized as the open web platform does</li>
            </ul>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <p>The “Local Link” enables applications to exchange message, e.g. String, Blob, via the local network directly. Without the “local Link”, the applications which are running on different devices can in-directly communicate via a service on the Internet. But, the “Local Link” has the following benefits:</p>
            <ul>
              <li>Adhoc: Without any syndication of services, the applications provided by different services can communicate each other's in ad-hoc. Also, all devices are not required to be bound to the same service. This is a kind of service mash-up using multiple devices</li>
              <li>Efficient: A large size of files can be transferred between devices via high bandwidth local network connection.</li>
              <li>Off-line: Even if the Internet access is not available, the applications can still communicate</li>
              <li>User-centric: Users can easily recognize which devices communicate. Only devices on the same network are listed and the communications of different user device are based on the user consent</li>
            </ul>
            <p>There are some standards of local discovery, e.g. UPnP, Bonjour, WS-Discovery, but there is no standard of the JavaScript API which enables communications between Web applications in the manner of application/service agnostic.</p>
            <p>What needs to be standardized:</p>
            <ul>
              <li>Type of use case: Generic APIs</li>
              <li>General service discovery and messaging APIs should be standardized</li>
              <li>Network protocols for the APIs should be specified</li>
            </ul>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <p>Any other use cases related to the local IP network discovery since the discovery is also application/service agnostic</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>Support applications communicating with each-other via ad-hoc messages</td>
              <td><a href="#application-communication" class="sectionRef">section 4.3.9 Application Communication</a>
              <br /><a href="#application-discovery" class="sectionRef">section 4.2.2 Application Discovery</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u15.-home-network-enabled-user-agent---network-media-player" class="section">
        <h3><span class="secno">5.15 </span>U15. Home Network Enabled User-Agent - Network Media Player</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>Enable a User-Agent to act as a Home Network Media Player</p>

            <p>The User-Agent acts as a Home Network Media Player device. For example (steps further detailed below):</p>
            <ol>
              <li>List available Home Network Media Server devices.</li>
              <li>List available content on a Home Network Media Server.</li>
              <li>List available content on a Home Network Media Server matching specified metadata criterion.</li>
              <li>Determine capabilities of User-Agent playback facilities provided to Home Network Media Player. Ex: supported content formats, number of streams, supported resolution(s).</li>
              <li>Play content from a Home Network Media Server.</li>
              <li>View EPG data from a Home Network Media Server.</li>
              <li>Tune and play live programs from a Home Network Media Server capable of streaming live content.</li>
              <li>Select and play recorded content from a Home Network Recording device.</li>
              <li>Select and play time-shifted content.</li>
            </ol>

            <p>Detailed steps for &quot;List available Home Network Media Server devices&quot;:</p>
            <ol>
              <li>Web page issues a method to discover home network devices</li>
              <li>User-Agent gets an event indicating the list is ready.</li>
              <li>User-Agent retrieves a list of handles representing the discovered devices</li>
              <li>Web page issues a method to get information about each discovered device</li>
              <li>Web page retains handles for devices of the appropriate type.</li>
              <li>Web page displays available devices to end-user.</li>
              <li>End-User selects one of the displayed devices.</li>
              <li>Web page issues method to access the device.</li>
              <li>User-Agent responds that a password is required.</li>
              <li>Web page obtains the password from the end-user (or secure password store) and issues method to provide the password to the User-Agent</li>
              <li>Web page can now access the device.</li>
            </ol>

            <p>Detailed steps for &quot;List available content on a Home Network Media Server&quot;:</p>
            <ol>
              <li>Web page formats an action request to browse the Home Network device metadata containers for EPG Items matching desired channel/time ranges.</li>
              <li>Web page issues method to send action request to selected Home Network device</li>
              <li>User-Agent sends request to Home Network Media Server device.</li>
              <li>User-Agent generates event when Home Network device responds (or times-out)</li>
              <li>Web page gets response (XML document) from Home Network Media Server device.</li>
              <li>Web page displays containers and items as indicated in XML document
              <br /><em>This depends on the data representation of Home Network Media Server content metadata.</em></li>
              <li>Web page displays the information in the Home Media Server response.</li>
            </ol>

            <p>Detailed steps for &quot;List available content on a Home Network Media Server matching specified metadata criterion&quot;:</p>
            <ol>
              <li>Web page formats an action request to determine searchable metadata on the selected Home Network device metadata store.</li>
              <li>Web page issues method to send action request to selected Home Network device.</li>
              <li>Web page formats an action request to search the Home Network device metadata store.</li>
              <li>Web page issues method to send action request to selected Home Network device</li>
              <li>User-Agent sends request to Home Network Media Server device.</li>
              <li>User-Agent generates event when Home Network device responds (or times-out)</li>
              <li>Web page gets response (XML document) from Home Network Media Server device.</li>
              <li>Web page displays containers and items as indicated in XML document</li>
            </ol>

            <p>Detailed steps for &quot;Play content from a Home Network Media Server&quot;:</p>
            <ol>
              <li>End-user select displayed Home Network Media Server item for playback.</li>
              <li>Web page formats an action request to browse metadata for selected item.</li>
              <li>User-Agent sends request to Home Network Media Server device.</li>
              <li>User-Agent generates event when Home Network device responds (or times-out)</li>
              <li>Web page gets response (XML document) from Home Network Media Server device.</li>
              <li>Web page selects media binary format that is compatible with User-Agent.</li>
              <li>Web page displays Media Player using HTML5 <code>&lt;video&gt;</code> element.</li>
              <li>Web page transfers item URL to <code>&lt;video&gt;</code> element <code>@src</code> (or creates <code>&lt;source&gt;</code> element as child element)</li>
            </ol>

            <p>Detailed steps for &quot;View EPG data from a Home Network Media Server&quot;:</p>
            <ol>
              <li>Web page formats an action request to determine root container(s) for EPG data on the selected Home Network device metadata store.</li>
              <li>Web page issues method to send action request to selected Home Network device.</li>
              <li>Web page formats an action request to search the Home Network device metadata store.</li>
              <li>Web page issues method to send action request to selected Home Network device</li>
              <li>User-Agent sends request to Home Network Media Server device.</li>
              <li>User-Agent generates event when Home Network device responds (or times-out)</li>
              <li>Web page gets response (XML document) from Home Network Media Server device.</li>
              <li>Web page displays EPG containers and EPG items as indicated in XML document</li>
            </ol>

            <p>Detailed steps for &quot;Tune and play live programs from a Home Network Media Server capable of streaming live content&quot;:</p>
            <ol>
              <li>Web page formats an action request to determine root container(s) for Channel Lineup metadata on the selected Home Network device.<br />
              Notes:
              <ul>
                <li>Multiple Channel Lineup containers may represent either an aggregate of multiple channel sources (Broadcast, Cable, Satellite) or selected channel sources (“Favorite Channels” for instance).</li>
                <li>Channel Lineup containers contain Channel Items which are metadata bundles of channel related properties. Some example of channel properties are: Channel Name, Channel Number, Channel Icon, Channel Preview Stream.</li>
                <li>A Channel Item contains metadata describing one or more URLs which stream the channel's binary content. Access to one of these URL implies any tuning operations necessary to make the requested channel source available.</li>
              </ul>
              </li>
              <li>Web page formats a channel listing based on Channel Items found. In addition the Web page may construct a subset of available Channel Items based previously stored end-user selections.</li>
              <li>Web page may support a Channel Up/Down notion based on an ordering of channels selected by the end-user of by using metadata properties of the Channel Items (Channel Number, Channel Name, etc.)</li>
              <li>Web page will typically offer the end-user the ability to select a channel for playback. The Web page will generate a <code>&lt;video&gt;</code> element referencing the channel's streaming URL provided by the Channel Item metadata.</li>
            </ol>

            <p>Detailed steps for &quot;Select and play recorded content from a Home Network Recording device&quot;:</p>
            <ol>
              <li>Web page formats an action request to determine root container(s) for Recorded Content metadata on the selected Home Network device.
              <br />Notes:
              <ul>
                <li>Recorded Content Items are similar to stored Content Items. However, Recorded Content Items may contain metadata containing the ID of the Recording Service request that resulted in the creation of this item.</li>
              </ul></li>
              <li>Web page display information about recorded content item.</li>
              <li>Web page offers end-user the ability to play recorded item.</li>
              <li>Web page offers end-user the ability to manipulate the Recording request which created the item.</li>
            </ol>

            <p>Notes for &quot;Select and play Time-Shift recorded content from a Home Network Recording device&quot;:</p>
            <ul>
              <li>Time-shift recording is an important variant of Network Recording. For Time-Shift recording no explicit request is required to record content; instead, the recording device automatically records the currently tuned channel (or favorite channel) in a circular buffer. Recorded content may be organized as one of more blocks of continuous content or as a list of separate captured programs.</li>
              <li>Time-shift recording generates temporary Content Items (bundles of content metadata). These content items are typically pointed to by the Channel Item that the content was captured from. For Time-shift Content Items some additional metadata properties are defined to indicate that the recording of an item may not be complete, and/or that a Content Item may represent a partial recording the original content.</li>
            </ul>

            <p>Detailed steps for &quot;Select and play Time-Shift recorded content from a Home Network Recording device&quot;:</p>
            <ol>
              <li>Web page access Channel Items (as described in prior use-case)</li>
              <li>Web page detects Channel Item lists to one or more Content Items as preserved content.</li>
              <li>Web page displays preserved Content Items which is available for the channel.</li>
              <li>Web page offers user ability to play preserved content by accessing URL in preserved Content Item.</li>
              <li>Web page offers user ability to convert preserved content to permanently recorded content by offering preserved Content Item(s) to the Network Recording service.</li>
            </ol>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <ul>
              <li>Existing Home Network interfaces do not (by scope/tradition) standardize user interface control. However, the combination of HTML markup and Javascript allow both access to Home Network devices functions and access to very capable user interface resources.</li>
              <li>Why were you not able to use only existing standards to accomplish this?
              <ul>
                <li>HTML User-Agents do not provided the abstractions necessary for Javascript to issue discover and issue commands to home network devices.</li>
                <li>Basic access methods to home network devices need to be standardized so that developers can implement pages to control Home Network devices using Javascript/HTML.</li>
              </ul>
              </li>
              <li>What might you suggest could be standardized?
              <ul>
                <li>Provide generic access methods to enable a User-Agent to discover and command home network devices.</li>
                <li>Provide a means for applications to control some of the parameters that may need to be exposed to support well-established home network protocols. A more detailed analysis is needed to identify such parameters and a way to specify them in a transport agnostic way</li>
                <li>Provide access and privacy controls for untrusted pages accessing home network devices.</li>
                <li>Allow pages to discover functional differences (optional functionality) that may be implemented in some but not all Home Network ecosystem devices.</li>
              </ul>
              </li>
            </ul>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <p>This use-case provides the basic framework for generic access to home network devices. It is &quot;agnostic&quot; towards the underlying functionality of the devices being controlled.</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>Application can obtain and display descriptive metadata for playback content</td>
              <td><a href="#service-discovery" class="sectionRef">section 4.2.1 Service Discovery</a>
              <br /><a href="#content-discovery" class="sectionRef">section 4.2.3 Content Discovery</a></td>
            </tr>
            <tr>
              <td>Application can obtain and display other descriptive metadata such as Electronic Programming Guides</td>
              <td><a href="#service-discovery" class="sectionRef">section 4.2.1 Service Discovery</a>
              <br /><a href="#content-discovery" class="sectionRef">section 4.2.3 Content Discovery</a></td>
            </tr>
            <tr>
              <td>Application can select content binary formats which match the User-Agent’s supported playback formats</td>
              <td><a href="#playback-of-content" class="sectionRef">section 4.3.3 Playback of Content</a></td>
            </tr>
            <tr>
              <td>Application can play content from Home Network stored content sources</td>
              <td><a href="#playback-of-content" class="sectionRef">section 4.3.3 Playback of Content</a></td>
            </tr>
            <tr>
              <td>Applications can play live content from Home Network streaming sources</td>
              <td><a href="#playback-of-live-content" class="sectionRef">section 4.3.4 Playback of Live Content</a></td>
            </tr>
            <tr>
              <td>Applications can play content from Home Network recording sources</td>
              <td><a href="#playback-of-content" class="sectionRef">section 4.3.3 Playback of Content</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u16.-home-network-enabled-user-agent---network-media-server" class="section">
        <h3><span class="secno">5.16 </span>U16. Home Network Enabled User-Agent - Network Media Server</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>Enable a User-Agent to act as a Home Network Media Server.</p>
            <p>Scenario: The User-Agent acts as a Home Network Media Server device. For example:</p>
            <ul>
              <li>Create a discoverable Home Network Media Server device.</li>
              <li>List available content that the User-Agent chooses to make available on the Home Network.</li>
              <li>Provide descriptive metadata (title, description) for this content.</li>
              <li>Provide multiple binary formats for this content.</li>
              <li>Provide functionality to allow other User-Agents to search for content matching specified metadata criteria.</li>
              <li>Provide capability for Home Network Media Server to notify clients when list of available content changes.</li>
            </ul>

            <p>Detailed steps for &quot;Create a discoverable Home Network Media Server device&quot;:</p>
            <ol>
              <li>Web page provides User-Agent descriptive metadata for the device to be created.</li>
              <li>Web page provides User-Agent access to programs to service requests made to Home Network Media Server.</li>
              <li>Web page requests User-Agent to make device visible on Home Network</li>
            </ol>
            <p>Detailed steps for &quot;List available content that the User-Agent chooses to make available on the Home Network&quot;:</p>
            <ol>
              <li>Created Media Server device receives request to list Media Server content.</li>
              <li>User-Agent invokes previously registered program (php?) to service request.</li>
              <li>User-Agent forwards results of registered program to requesting end-point providing identifiers for (Content Items) describing available content.</li>
            </ol>
            <p>Detailed steps for &quot;Provide descriptive metadata (title, description) for this content&quot;:</p>
            <ol>
              <li>Created Media Server device receives a request to provide metadata for a Content Item.</li>
              <li>User-Agent invokes a previously registered program (php?) to provide metadata corresponding to a Content Item.</li>
              <li>User-Agent forwards results of registered program to requesting end-point.</li>
            </ol>
            <p>Detailed steps for &quot;Provide multiple binary formats for this content&quot;:</p>
            <ol>
              <li>Content Items contain metadata providing one or more alternative formats for content represented by a content item. This metadata consists of a URL which serves the content item and additional descriptive metadata for the content binary served by the corresponding URL.</li>
            </ol>
            <p>Detailed steps for &quot;Provide functionality to allow other User-Agents to search for content matching specified metadata criteria&quot;:</p>
            <ol>
              <li>Created Media Server device receives a request to provide Content Item identifiers whose metadata matches criteria provided by the end-point.</li>
              <li>User-Agent invokes a previously registered program (php?) to provide identifiers of Content Items which match the search criteria provided.</li>
              <li>User-Agent forwards results of registered program to requesting end-point.</li>
            </ol>
            <p>Detailed steps for &quot;Notify User-Agents of changes to available content&quot;:</p>
            <ol>
              <li>User-Agent receives request from end-point(s) to report changes to available content.</li>
              <li>User-Agent receives notification that available content has changed.</li>
              <li>User-Agent forwards notification to end-point(s) which have registered for this notification.</li>
            </ol>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <p>Existing Home Network interfaces do not (by scope/tradition) standardize user interface control. However, the combination of HTML markup and Javascript allow both access to Home Network devices functions and access to very capable user interface resources.</p>
            <p>Why were you not able to use only existing standards to accomplish this?</p>
            <ul>
              <li>HTML User-Agents do not provided the abstractions necessary for Javascript to issue discover and issue commands to home network devices.</li>
              <li>Basic access methods to home network devices need to be standardized so that developers can implement pages to control Home Network devices using Javascript/HTML.</li>
            </ul>
            <p>What might you suggest could be standardized?</p>
            <ul>
              <li>Provide generic access methods to enable a User-Agent to discover and command home network devices.</li>
              <li>Provide a mean for applications to control some of the parameters that may need to be exposed to support well-established home network protocols. A more detailed analysis is needed to identify such parameters and a way to specify them in a transport agnostic way</li>
              <li>Provide access and privacy controls for untrusted pages accessing home network devices.</li>
              <li>Allow pages to discover functional differences (optional functionality) that may be implemented in some but not all Home Network ecosystem devices.</li>
            </ul>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <p>This use-case provides the basic framework for generic access to home network devices. It is &quot;agnostic&quot; towards the underlying functionality of the devices being controlled.</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>Applications can cause a User-Agent to act as a Home Network media server</td>
              <td><a href="#content-advertisement" class="sectionRef">section 4.2.4 Content Advertisement</a></td>
            </tr>
            <tr>
              <td>Applications support services which provide metadata describing available content</td>
              <td><a href="#content-advertisement" class="sectionRef">section 4.2.4 Content Advertisement</a></td>
            </tr>
            <tr>
              <td>Application supports services which allow searching for content metadata matching specified criteria</td>
              <td><a href="#content-advertisement" class="sectionRef">section 4.2.4 Content Advertisement</a></td>
            </tr>
            <tr>
              <td>Application supports services which notify clients of changes in available content or content metadata</td>
              <td><a href="#content-advertisement" class="sectionRef">section 4.2.4 Content Advertisement</a></td>
            </tr>
            <tr>
              <td>Content descriptions support offering content in multiple binary formats</td>
              <td><a href="#content-advertisement" class="sectionRef">section 4.2.4 Content Advertisement</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u17.-home-network-enabled-user-agent" class="section">
        <h3><span class="secno">5.17 </span>U17. Home Network Enabled User-Agent</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>Enable a User-Agent to control other media oriented Home Network Devices (3-box model).</p>
            <p><a href="hn-ua.jpg"><img src="hn-ua.jpg" alt="" width="600" height="374" /></a></p>
            <p>Scenario: The User-Agent commands other media oriented home network devices. For example:</p>
            <ul>
              <li>Determine the playback capabilities of a Home Network Media Rendering device. For example: supported content formats, number of streams, supported resolution(s).</li>
              <li>Direct a Home Network Media Rendering device to play compatible content stored on a Home Network Media Server.</li>
              <li>Direct a Home Network Media Rendering device to play live content from a Home Network Media Server capable of streaming content.</li>
              <li>Control Home Network Media Renderer attributes: Brightness, Contrast, Volume, etc.</li>
              <li>Control Home Network Media Renderer multiplex stream selection: Closed Captioning, Language, Subtitling and Camera Angles.</li>
            </ul>

            <p>Detailed steps for &quot;Direct a Home Network Media Rendering device to play content stored from a Home Network Media Server&quot;:</p>
            <ol>
              <li>Web page requests User-Agent discover Media Rendering devices on Home Network</li>
              <li>Web page allows end-user to select a Media Rendering device</li>
              <li>Web page issues request to Media Rendering device to determine content formats it supports</li>
              <li>Web page requests User-Agent discover Media Server devices on Home Network</li>
              <li>Web page allows end-user to select a Media Server device</li>
              <li>Web page obtains list of Content Items available on Media Server</li>
              <li>Web page removes items from list which do not have formats compatible with selected Media Renderer device</li>
              <li>Web page allows end-user to select from remaining Content Items</li>
              <li>Web page selects Content Item URL that provides &quot;best&quot; playback experience on Media Renderer</li>
              <li>Web page sends selected Content Item URL to Media Renderer device</li>
              <li>Web page sends command to Media Renderer device to begin playback</li>
            </ol>

            <p>Detailed steps for &quot;Direct a Home Network Media Rendering device to play live content from a Home Network Media Server capable of streaming content&quot;:</p>
            <ul>
              <li>Steps are similar to above use-case. However, Media Rendering device needs to modify buffer sizes to account for content being served at playback rate.</li>
            </ul>

            <p>Detailed steps for &quot;Control Home Network Media Renderer attributes: Brightness, Contrast, Volume, etc.&quot;:</p>
            <ol>
              <li>Web page issues request to Media Renderer device to get default settings</li>
              <li>Web page issues request to Media Renderer device to modify default settings</li>
              <li>Web page issues request to Media Renderer device to modify settings for current Content Item (if any)</li>
            </ol>

            <p>Detailed steps for &quot;Control Home Network Media Renderer multiplex stream selection: Closed Captioning, Language, Subtitling and Camera Angles&quot;:</p>
            <ol>
              <li>Steps are followed to the point where Media Render is provided the Content Item URL.</li>
              <li>Web page issues request to Media Renderer to determine what playback attributes can be modified for the selected Content Item.</li>
              <li>Web page may request to Media Renderer device to select desired playback settings for the selected Content Item if user wishes to override default settings.</li>
            </ol>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <p>Existing Home Network interfaces do not (by scope/tradition) standardize user interface control. However, the combination of HTML markup and Javascript allow both access to Home Network devices functions and access to very capable user interface resources.</p>
            <p>Why were you not able to use only existing standards to accomplish this?</p>
            <ul>
              <li>HTML User-Agents do not provided the abstractions necessary for Javascript to issue discover and issue commands to home network devices.</li>
              <li>Basic access methods to home network devices need to be standardized so that developers can implement pages to control Home Network devices using Javascript/HTML.</li>
            </ul>
            <p>What might you suggest could be standardized?</p>
            <ul>
              <li>Provide generic access methods to enable a User-Agent to discover and command home network devices.</li>
              <li>Provide a mean for applications to control some of the parameters that may need to be exposed to support well-established home network protocols. A more detailed analysis is needed to identify such parameters and a way to specify them in a transport agnostic way.</li>
              <li>Provide access and privacy controls for untrusted pages accessing home network devices.</li>
              <li>Allow pages to discover functional differences (optional functionality) that may be implemented in some but not all Home Network ecosystem devices.</li>
            </ul>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <p>This use-case provides the basic framework for generic access to home network devices. It is &quot;agnostic&quot; towards the underlying functionality of the devices being controlled.</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>Application allows a User-Agent to discover and control media playback on other Home-Network Devices</td>
              <td><a href="#x3-box-model" class="sectionRef">section 4.3.5 3 Box Model</a>
              <br /><a href="#control-of-content-players" class="sectionRef">section 4.3.1 Control of Content Players</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u18.-home-network-enabled-user-agent---network-record-controller" class="section">
        <h3><span class="secno">5.18 </span>U18. Home Network Enabled User-Agent - Network Record Controller</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>Enable a User-Agent to control a Home Network Recording Device.</p>
            <p>Scenario: The User-Agent controls a Home Network Recording device. For example:</p>
            <ul>
              <li>Request the recording device capture content based on simple time/date criteria.</li>
              <li>Request the recording device capture content based recurring time/date criteria.</li>
              <li>Request the recording device capture content based on an EPG description.</li>
              <li>Request the recording device capture content based on a metadata description.</li>
              <li>Provide controls to suspend/restart/cancel planned recording activities.</li>
              <li>Provide status information for current/future recording activities.</li>
              <li>Provide access to recorded program descriptions and content.</li>
            </ul>

            <p>Detailed steps for &quot;Request the recording device capture content based on simple time/date criteria&quot;:</p>
            <ol>
              <li>Web page issues a request to determine the capabilities of the Network Recording device.</li>
              <li>Web page creates a XML document describing a simple record schedule.</li>
              <li>Web page sends XML document to Network Recording device.</li>
              <li>Network recording device creates one or more Recording Tasks.</li>
              <li>Web page may issue request to Network Recording device to determine status of Recording Tasks.</li>
            </ol>

            <p>Detailed steps for &quot;Request the recording device capture content based recurring time/date criteria&quot;:</p>
            <ol>
              <li>Web page creates a XML document describing a recurring record schedule.</li>
              <li><strong>Note:</strong> See above steps.</li>
            </ol>

            <p>Detailed steps for &quot;Request the recording device capture content based on an EPG description&quot;:</p>
            <ol>
              <li>Web page obtains a EPG Content Items from Media Server (See prior use-case)</li>
              <li>Web page creates a XML document containing identifier of the EPG Item.</li>
              <li><strong>Note:</strong> Network Recording service presumes that EPG service resides on same device.</li>
              <li>Web page sends XML document to Network Recording device.</li>
              <li>Network recording device creates one or more Recording Tasks.</li>
            </ol>
            
            <p>Detailed steps for &quot;Request the recording device capture content based on a metadata description&quot;:</p>
            <ol>
              <li>Web page creates a XML document describing a recurring record schedule which selects content based on metadata properties.</li>
              <li>Web page sends XML document to Network Recording device.</li>
              <li>Network recording device creates one or more Recording Tasks.</li>
            </ol>

            <p>Detailed steps for &quot;Provide controls to suspend/restart/cancel planned recording activities&quot;:</p>
            <ol>
              <li>Web page may issue request to Recording Device to get current Recording Tasks.
              <br /><strong>Note:</strong> Record Tasks are generated from XML Record Schedule documents submitted to Network Recording Device.</li>
              <li>Web page may issue request to suspend, restart or cancel Record Tasks or Record Schedules.</li>
            </ol>

            <p>Detailed steps for &quot;Provide status information for current/future recording activities&quot;:</p>
            <ol>
              <li>Web page may issue request to Recording Device to get current Recording Task documents. Record Tasks contain various status information indicating whether recording is pending (not started), active (started but not completed), or done (completed).</li>
            </ol>

            <p>Detailed steps for &quot;Provide access to recorded program descriptions and content&quot;:</p>
            <ol>
              <li>The Network Recording device (Record Tasks) creates Content Items.</li>
              <li>The Record Task contains identifiers to the created Content Item(s) for the Record Task.</li>
              <li>The Content Items contain metadata describing what was recorded.</li>
            </ol>
          </dd>

          <dt>Motivation</dt>
          <dd>
            <p>Existing Home Network interfaces do not (by scope/tradition) standardize user interface control. However, the combination of HTML markup and Javascript allow both access to Home Network devices functions and access to very capable user interface resources.</p>
            <p>Why were you not able to use only existing standards to accomplish this?</p>
            <ul>
              <li>HTML User-Agents do not provided the abstractions necessary for Javascript to issue discover and issue commands to home network devices.</li>
              <li>Basic access methods to home network devices need to be standardized so that developers can implement pages to control Home Network devices using Javascript/HTML.</li>
            </ul>
            <p>What might you suggest could be standardized?</p>
            <ul>
              <li>Provide generic access methods to enable a User-Agent to discover and command home network devices.</li>
              <li>Provide a means for applications to control some of the parameters that may be needed to be exposed to support well-established home network protocols. A more detailed analysis is needed to identify such parameters and a way to specify them in a transport agnostic way.</li>
              <li>Provide access and privacy controls for untrusted pages accessing home network devices.</li>
              <li>Allow pages to discover functional differences (optional functionality) that may be implemented in some but not all Home Network ecosystem devices.</li>
            </ul>
          </dd>

          <dt>Dependencies</dt>
          <dd>
            <p>This use-case provides the basic framework for generic access to home network devices. It is &quot;agnostic&quot; towards the underlying functionality of the devices being controlled.</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>Application supports various recording schedules: Time of Day, Electronic Programming Guide, Metadata matching</td>
              <td><a href="#control-of-content-recorders" class="sectionRef">section 4.3.2 Control of Content Recorders</a></td>
            </tr>
            <tr>
              <td>Application provides status information for current and pending recording activities</td>
              <td><a href="#control-of-content-recorders" class="sectionRef">section 4.3.2 Control of Content Recorders</a></td>
            </tr>
            <tr>
              <td>Application provides ability to cancel, suspend, and restart pending recording activities</td>
              <td><a href="#control-of-content-recorders" class="sectionRef">section 4.3.2 Control of Content Recorders</a></td>
            </tr>
            <tr>
              <td>Application provides access to recorded content</td>
              <td><a href="#control-of-content-recorders" class="sectionRef">section 4.3.2 Control of Content Recorders</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>

      <div id="u19.-upnp---dlna-ecosystem-support" class="section">
        <h3><span class="secno">5.19 </span>U19. UPnP / DLNA ecosystem support</h3>

        <dl>
          <dt>Description</dt>
          <dd>
            <p>Use cases U15, U16, U17, U18 and U1 describe functionality implemented by existing UPnP/DLNA home network devices in general terms. However, there is an existing install base of UPnP/DLNA compliant devices and the associated SDOs (UPnP Forum, DLNA) continue actively develop additional device related specifications. It would be beneficial to the end-user community if <acronym title="World Wide Web Consortium">W3C</acronym> User-Agents provided access to UPnP/DLNA devices without requiring any modification to the existing install base of UPnP/DLNA compliant devices.</p>
            <p>Scenarios:</p>
            <ul>
              <li>user agents support applications which can discover UPnP/DLNA compliant devices.</li>
              <li>user agents support applications retrieving UPnP Device and Service Description XML documents.</li>
              <li>user agents support application issuing of SOAP actions to control UPnP/DLNA devices.</li>
              <li>user agents support applications subscribing to UPnP Service Events.</li>
              <li>user agents support applications inspection of UPnP Service State Variables.</li>
              <li>user agents support applications including DLNA specified HTTP transport headers to obtain DLNA content metadata and to control playback features (such as trick-play, time-based positioning).</li>
            </ul>
            <p>A summary of UPnP specifications relevant to this use case is provided in <a href="#universal-plug-n-play--upnp--reference" class="sectionRef">section 8.5 Universal Plug'n Play (UPnP) Reference</a>.</p>
          </dd>

          <dt>Requirements</dt>
          <dd><table>
            <tbody><tr>
              <th>Low Level</th>
              <th>High Level</th>
            </tr>
            <tr>
              <td>Application supports access to UPnP/DLNA devices without modification of existing deployed devices</td>
              <td><a href="#compatibility-with-widely-deployed-standards" class="sectionRef">section 4.1.1 Compatibility with widely deployed standards</a></td>
            </tr>
            <tr>
              <td>Application support UPnP devices not related to content playback</td>
              <td><a href="#compatibility-with-widely-deployed-standards" class="sectionRef">section 4.1.1 Compatibility with widely deployed standards</a></td>
            </tr>
          </tbody></table>
          </dd>
        </dl>
      </div>
    </div>

    <div id="security" class="section">
      
<!-- OddPage -->
<h2><span class="secno">6. </span>Security</h2>
      <p>Enabling application access to Home Network devices and content available on such devices raise several security and privacy concerns. Addressing user security and privacy is of primary importance for <a href="#dfn-conforming-specifications" class="internalDFN">conforming specifications</a>. This implies that some features may have to be &quot;restricted&quot; in order not to compromise user security. This may have an impact on the flexibility of these specifications, so a delicate balance between user experience and security needs to be found.</p>

      <p>This section lists possible threats that <a href="#dfn-conforming-specifications" class="internalDFN">conforming specifications</a> may have to deal with and possible solutions to reduce risks for the user. This section is not intended as an exhaustive list of problems and solutions but is intended to provide some directions for further investigation.</p>

      <div id="threats" class="section">
        <h3><span class="secno">6.1 </span>Threats</h3>

        <div id="security-1" class="section">
          <h4><span class="secno">6.1.1 </span>Security</h4>
          <ol>
            <li>
              Malicious attacks
              <ul>
                <li>An external server can control an Home Network device (e.g. send spam to your printer)</li>
                <li>A vulnerability in one of the Home Network devices can be used as a back door to get access to the Home Network</li>
                <li>Denial of service - repeated requests for resources could render a Home Network device/application/service unusable</li>
              </ul>
            </li>
            <li>Leaking of information from the home network to the Internet (e.g. content, content metadata)</li>
            <li>Some users inside the home network may (inadvertently) allow external application(s) unwanted access to home network devices (e.g. a family may wish to prevent any website that the children view on their PCs or phones from being able to query and/or control other devices)</li>
          </ol>
        </div>

        <div id="privacy" class="section">
          <h4><span class="secno">6.1.2 </span>Privacy</h4>
          <ol>
            <li>3rd party visibility into content (e.g. movies) available in the HN.</li>
            <li>3rd party visibility of types of devices available in the home network</li>
            <li>3rd party visibility of applications in use/installed (e.g. don't expose the fact that my home security system is part of my HN)</li>
          </ol>
        </div>
      </div>
      
      <div id="potential-solutions" class="section">
        <h3><span class="secno">6.2 </span>Potential Solutions</h3>

        <p>The list of techniques listed in this section are not mutually exclusive but can be combined to provide more flexibility in handling user security.</p>
        
        <div id="home-network-access-allowed-only-to-trusted-applications" class="section">
          <h4><span class="secno">6.2.1 </span>Home Network Access Allowed Only to Trusted Applications</h4>
          <ul>
            <li>In order for the application(s) to be able to access Home Network functionalities exposed by the UA, it needs to be trusted (by default is untrusted)</li>
            <li>There could be different way to identify if an application is trusted and also different trust levels (and associated permissions).</li>
          </ul>
        
          <div id="how-to-determine-the-trust-level-of-an-application--several-may-apply" class="section">
            <h5><span class="secno">6.2.1.1 </span>How to Determine the Trust Level of an Application (Several May Apply)</h5>
            <ol>
              <li>Asking the user to authorize the application (via a dialog, a white list or other means)</li>
              <li>Using a white list that is provided by the platform (e.g. surrendering control to service providers)</li>
            </ol>
          </div>

          <div id="trust-levels-options--mutually-exclusive" class="section">
            <h5><span class="secno">6.2.1.2 </span>Trust Levels Options (Mutually Exclusive)</h5>
            <ol>
              <li>just 2 levels (trusted/untrusted)
              <ul>
                <li>Trusted have full access to the Home Network capabilities</li>
                <li>Untrusted have NO access to the Home Network capabilities</li>
              </ul>
              </li>
              <li>multiple trust levels and associated permissions (like user in OSes)
              <ul>
                <li>identify different subgroups of capabilities that the UA is able to expose</li>
                <li>associate these capabilities to a permission and each group to a subset of permissions</li>
              </ul>
              </li>
              <li>don't define generic trust levels but let the user decide on a &quot;per action&quot; base (see <a href="#modular-access-to-home-network-services-and-content" class="sectionRef">section 6.2.4 Modular Access to Home Network Services and Content</a>)</li>
            </ol>
          </div>
        </div>

        <div id="device-pairing" class="section">
          <h4><span class="secno">6.2.2 </span>Device Pairing</h4>
          <ul>
            <li>Pairing operation (using a PIN/password) is needed before devices can communicate
            <ul>
              <li>The user is prompted to authorize the communication. Note that this could lead to a Potential denial-of-service.</li>
              <li>The user need to enter a (numeric) PIN or alphanumeric password
              <ul>
                <li>Numeric PIN may be easier to enter with traditional remote controls</li>
                <li>A &quot;default&quot; PIN could be defined as common in other standards.</li>
              </ul>
              </li>
              <li>The pairing could be one way (the control device make a &quot;log in&quot; into the controlled device) or two ways (devices needs to authorize each other)</li>
            </ul>
            </li>
            <li>Pairing Expiration: having pairing expire after a while could provide more security. In some scenarios thought, having the ability to configure it permanently allow for a better user experience. For example a user may have the Home Network devices configured by a technician. This is also very important for people with disabilities that may be unable to configure devices themselves.</li>
          </ul>
        </div>

        <div id="device-information-only-visible-to-the-user" class="section">
          <h4><span class="secno">6.2.3 </span>Device Information only Visible to the User</h4>
          <p>Exposing information about services, content and devices in the Home Network to an application is a potential privacy leak. This could be minimized allowing the application to only get access to:</p>
          <ul>
            <li>an identifier for the device/content/service</li>
            <li>an API to ask the UA to show more information about the content/service/device in some specific use cases, e.g.:
            <ul>
              <li>ask the user to authorize a specific device to perform a given action</li>
              <li>show the user additional details about a specific device/ piece of content</li>
            </ul>
            </li>
          </ul>
          <p>This mechanism could limit the application flexibility but increases the user privacy.</p>
          <p>An alternative approach could be to limit the application ability to access this information until the application has been explicitly authorized by the User, or has successfully paired with the device.</p>
        </div>

        <div id="modular-access-to-home-network-services-and-content" class="section">
          <h4><span class="secno">6.2.4 </span>Modular Access to Home Network Services and Content</h4>
          <p>One possible approach could be to consider each service as a separate &quot;functionality&quot; that the device has to authorize, in a similar fashion as Apps on mobile phones need to be authorized to access specific functionalities provided by the platform. The main difference in this case is that services available in the Home Network change over time, and also there isn't an installation process for web applications. Furthermore such approach would need a way to uniquely identify services (potentially across different home networking protocols) and expose relevant information for the user to understand what is actually authorizing. Such a technique would be then specification what would decide to enable a level interface for communication between devices/applications, which is not explicitly aware of different services.</p>
        </div>
      </div>
    </div>

    <div id="categorization-of-requirements-and-next-steps" class="section">
      
<!-- OddPage -->
<h2><span class="secno">7. </span>Categorization of Requirements and Next Steps</h2>

      <p>One of the deliverable of the Home Network Task Force, according to its charter, is a set of recommendation to <acronym title="World Wide Web Consortium">W3C</acronym> Director for recommendation track work fulfilling some (or all) of the identified requirements.</p>

      <p>This section summarizes the consensus of the TF about the desirable next steps and also to try to give an indication of relative priorities of the identified requirements.</p>
      
      <div id="requirements-categorization" class="section">
        <h3><span class="secno">7.1 </span>Requirements Categorization</h3>

        <p>The HNTF has made an attempt to categorize requirements based on the priority of addressing them to enable some of the use cases that are already available via other technologies or that are felt particularly important to have an enhanced user experience. Go without saying that all identified requirements are considered important by the Task Force; so the criteria followed is more the degree to which each requirements enables use cases that cannot be covered today rather than a value judgment of the importance of one requirement versus another (which differs by individual). By this &quot;enablement&quot; criterion, a feature that enables more use cases is higher priority than a feature that enables a limited subset of use cases.</p>

        <p>The following requirements underpin most (if not all) of the use cases (see <a href="#use-cases" class="sectionRef">section 5. Use Cases</a>) listed in this document, so they are considered the starting point for a technical work:</p>

        <ul>
          <li><a href="#service-discovery" class="sectionRef">section 4.2.1 Service Discovery</a></li>
          <li><a href="#content-discovery" class="sectionRef">section 4.2.3 Content Discovery</a></li>
        </ul>

        <p>These alone are insufficient to fulfill most of the use cases and user scenarios identified. The use cases that seem most straightforward to address next and which also show the most immediate utility are those that support the ability to control and query media playback:</p>

        <ul>
          <li><a href="#compatibility-with-widely-deployed-standards" class="sectionRef">section 4.1.1 Compatibility with widely deployed standards</a></li>
          <li><a href="#control-of-content-players" class="sectionRef">section 4.3.1 Control of Content Players</a></li>
          <li><a href="#playback-of-content" class="sectionRef">section 4.3.3 Playback of Content</a></li>
          <li><a href="#playback-of-live-content" class="sectionRef">section 4.3.4 Playback of Live Content</a></li>
          <li><a href="#x3-box-model" class="sectionRef">section 4.3.5 3 Box Model</a></li>
          <li><a href="#time-synchronization" class="sectionRef">section 4.3.6 Time-synchronization</a></li>
          <li><a href="#service-communication" class="sectionRef">section 4.3.8 Service Communication</a></li>
        </ul>

        <p>The requirements listed above focus on enabling applications to utilize existing home network services. The remaining requirements all enable use cases and scenarios that are of great interest and could be considered a &quot;next step&quot; of making it possible for applications to advertise and/or offer services. These requirements would allow leveraging web technologies and creating new types of application which mashes up Web and home networked devices.</p>

        <ul>
          <li><a href="#services-advertisement" class="sectionRef">section 4.2.5 Services Advertisement</a></li>
          <li><a href="#content-advertisement" class="sectionRef">section 4.2.4 Content Advertisement</a></li>
          <li><a href="#application-communication" class="sectionRef">section 4.3.9 Application Communication</a></li>
          <li><a href="#application-discovery" class="sectionRef">section 4.2.2 Application Discovery</a></li>
          <li><a href="#push-migration" class="sectionRef">section 4.4.1 Push Migration</a></li>
          <li><a href="#pull-migration" class="sectionRef">section 4.4.2 Pull Migration</a></li>
          <li><a href="#accurate-time-synchronization" class="sectionRef">section 4.3.7 Accurate Time-synchronization</a></li>
        </ul>

        <p>While security requirements are of really high priority in general, some of the requirement listed in this document may or may not be covered by <a href="#dfn-conforming-specifications" class="internalDFN">conforming specifications</a> depending on the particular technical solution that will be designed to cover the requirements listed above. That is why the following requirements to no fall into the High/Low priority scheme:</p>

        <ul>
          <li><a href="#application-trust-level" class="sectionRef">section 4.5.1 Application Trust Level</a></li>
          <li><a href="#access-to-home-network-services" class="sectionRef">section 4.5.2 Access to Home Network Services</a></li>
          <li><a href="#prevent-leaking-of-information" class="sectionRef">section 4.5.3 Prevent Leaking of Information</a></li>
        </ul>

        <p>Media Identification is a prerequisite for applications to be able to properly relate items of media content to a wider web of data/content. On the other end this requirement is orthogonal to the other discussed in this document and could be probably discussed in parallel with the work on the other requirements. That is why the following requirement is also not categorized:</p>
        <ul>
          <li><a href="#media-identification" class="sectionRef">section 4.2.6 Media Identification</a></li>
        </ul>
      </div>

      <div id="identified-gaps" class="section">
        <h3><span class="secno">7.2 </span>Identified Gaps</h3>
        <p>A close analysis and discussion of the use-cases and requirements described in this document, lead the group to conclude that the <strong>major gap</strong> in the Open Web platform is the <strong>lack of means for an application to discover services and applications available on the home network</strong>. Filling such a gap will probably allow the coverage of most (if not all) requirements listed in this document (see <a href="#requirements" class="sectionRef">section 4. Requirements</a>).</p>

        <p>Some concerns were raised if the discovery alone is enough to address advertisements requirements especially for support of existing protocols such as UPnP. In fact, advertisements itself could be implemented as a service so that applications can discover it and then register to be advertised on the network. Such a service may be provided by the UA itself (i.e. the functionality is provided by the UA but exposed as a service) or by an external device. It is not clear though (lacking implementations of this) if this approach will be enough flexible and efficient.</p>

        <p>Furthermore to have an interoperable solution, a common advertising service would have to be standardized or JavaScript binding to already in use advertising services/protocols would have to be provided.</p>

        <p>The discussion will have to be deferred to the point in time when a User Agent supporting discovery is available.</p>
      </div>

      <div id="next-steps" class="section">
        <h3><span class="secno">7.3 </span>Next Steps</h3>
        <p>The HNTF believes that all the identified use cases and requirements are important to achieve a better convergence between the Web and TV. The TF also believes that all of them have an impact on the current web platform architecture so a recommendation track work would be needed to make sure that the identified requirements are covered in an open and interoperable way.</p>
        
        <p>The HNTF believes that many of the requirements identified here may match the deliverables in the <a href="http://www.w3.org/2011/07/DeviceAPICharter">Device APIs Working Group Charter</a>. Therefore it is proposed to provide this requirement document as an input for further work to the <strong>Device APIs (DAP) Working Group</strong>. However, if after a more detailed analysis, requirements detailed in this document are found to be out-of-scope for the DAP WG, then the HNTF recommends that additional <acronym title="World Wide Web Consortium">W3C</acronym> Working Groups be chartered to address the remaining requirements.</p>
      </div>

      <div id="open-issues" class="section">
        <h3><span class="secno">7.4 </span>Open Issues</h3>
        <p>During his work, the HNTF did not have time to explore topics like the access to the home network from outside the home or concepts like group of homes. The TF believes that this is an area of extreme interest and would suggest the DAP WG (or any other working group working on the requirements extracted from this document) further investigate these topics. The Web &amp; TV IG itself may consider discussing these topics and provide feedbacks to one or more <acronym title="World Wide Web Consortium">W3C</acronym> Working Groups.</p>
      </div>
    </div>

    <div id="related-works--informative" class="section">
      
<!-- OddPage -->
<h2><span class="secno">8. </span>Related Works (Informative)</h2>

      <p>This section include references to related works (prototypes, draft APIs, etc.) that have been produced by IG participants and are related to the use cases outlined in this document. Note that this section is informative and that the Web and TV Interest Group do not endorse any of the works listed in this section. Nevertheless the Web and TV Interest Group thinks that these related works contain useful ideas that could be discussed and expanded by a working group writing specifications addressing requirements enumerated in this document.</p>

      <div id="cablelabs" class="section">
        <h3><span class="secno">8.1 </span>CableLabs</h3>
        <p>CableLabs is a not-for-profit research and development consortium that has cable operators as its members. While working on defining use cases and requirements as member of the Home Network TF of the Web and TV IG, some work has been done by CableLabs to experiment with possible ways to support use cases discussed by the Home Network Task Force in an HTML5 user agent. See CableLabs Revised Home Networking API [<cite><a class="bibref" rel="biblioentry" href="#bib-CLABS-HNAPI">CLABS-HNAPI</a></cite>].</p>
      </div>

      <div id="opera" class="section">
        <h3><span class="secno">8.2 </span>Opera</h3>
        <p>Opera proposed a low-level API to address some of the use cases outlined in this document and discussed by the Home Network Task Force of the Web and TV IG. This section contains an outline of the proposal as presented to the DAP WG.</p>
    
        <div id="problem" class="section">
          <h4><span class="secno">8.2.1 </span>Problem</h4>
          <p>A number of devices connected within a local network today advertise service API endpoints to the network, the primary purpose of which is to allow other devices within the same local network to connect, control and interact with those services through the provided interfaces.</p>
          <p>It is possible today to build native applications that can both discover and communicate with such local-networked services. There is currently no standard or, indeed, any particularly easy way to discover or interact with local devices and services from a web application without significant technical hackery on the part of the user (see 'current practice' below).</p>
          <p>We need a way for a user agent, acting as a broker between a user and a web application to discover services via common discovery protocols (i.e. SSDP and DNS-SD) within the local network, allow web applications to request a particular service type (or class of service) that it wishes to interact with and then for a user to authorize that connectivity based on services found in their local network matching the requested service type. The solution should then enable communication to occur between the authorized web application and the local-networked service, bypassing or overriding the same-origin policy rule if necessary to allow for safe and secure cross-domain communication.</p>
        </div>

        <div id="current-practice" class="section">
          <h4><span class="secno">8.2.2 </span>Current Practice</h4>
          <p>Assuming the user is able to obtain a local-networked service's host and port information, which in itself is a hard task for both technical and non-technical users alike, the user must then provide that host and port information to the web application by entering such information in e.g. a web form and submitting said form. Having got this far the web application, despite having all the information required to communicate with a local-networked device/service, is then likely to encounter another issue, namely the same-origin policy rule which prevents a web application from communicating with a networked device that does not share the same host and port origin combination as itself.</p>
          <p>As a solution to this, CORS has been developed to enable cross-origin messaging from web applications. Within the home network, if the target networked device happened to provide the HTTP header <code>Access-Control-Allow-Origin: *</code> then there is little problem with the browser now being able to communicate with the provided host and port.</p>
          <p>However, the majority of local-networked services do not implement CORS and because <code>Access-Control-Allow-Origin: *</code> is generally a bad idea to enable within a local network, it is not really the ideal future-facing solution within local networks to ensure access is granted only to web applications that a user has explicitly authorized access to.</p>
          <p>In the vast majority of use cases communication from a web application to a local-networked service is blocked or inherently insecure today due to one or more of the issues above being present in modern web browsers.</p>
          <p>The current practice therefore does not fulfill the requirements of the initial problem and so we began to consider alternative approaches.</p>
        </div>

        <div id="proposed-solution" class="section">
          <h4><span class="secno">8.2.3 </span>Proposed Solution</h4>
          <p>To counter the issues identified in the current practice above we developed a low-level API, produced incrementally over the course of the last few months, that allows a web application to request a particular service type (or class of service type) and for the user to then be able to authorize and connect a discovered matching service to the requesting web application. This enables a user-authorized web application to control, interact and synchronize content (and otherwise generally communicate) with home-networked services, negating the operational issues present in browsers today.</p>
          <p>The proposed solution is available, see Networked Service Discovery and Messaging [<cite><a class="bibref" rel="biblioentry" href="#bib-DISCO-PROP">DISCO-PROP</a></cite>].</p>
          <p>A note on CORS: this API is intended to work with or without CORS support enabled in local-networked services. That is to say, CORS in combination with e.g. HTTP authentication schemes, assuming such a model is deployed widely in the future, may provide a good user authorization model for this API (perhaps even to the point of negating the need for any specialized Service Discovery user interfaces at all). As it stands, the proposed solution is intended to work with existing services deployed within local networks without shoe-horning all communications in to a future-only CORS model.</p>
          <p><strong>Disclaimer:</strong> This API proposal does not represent the consensus of any standards group and should not be referenced as anything other than an unofficial draft which is a work in progress.</p>
        </div>

        <div id="bbc" class="section">
          <h4><span class="secno">8.2.4 </span>BBC</h4>
          <p>The BBC is non-profit, publicly funded broadcaster based in the UK that also engages in technical research. As part of its participation in the Home Network TF, the BBC has shared its own experimental API work that enables clients, including HTML user agents, to discover and communicate with television style devices within the home network.</p>
          <p>This API defines a RESTful web service to be implemented by a television, set-top-box, or similar device. The data model represents programmes and sources of programmes in a relatively abstract way. The API in turn defines a uniform way to discover, identify, acquire (e.g. record) and control playback of programme content. There is also provision for starting and communicating with web or native applications running on the television. Applications using this API avoid having to deal with issues of codec, container format or transport protocol compatibility.</p>
          <p>Documents providing background, an introductory overview and a draft specification of the API are available:</p>
          <ul>
            <li><a href="http://www.bbc.co.uk/blogs/researchanddevelopment/2011/02/universal-control.shtml">Universal Control</a></li>
            <li>White Paper 193 : The Universal Control API version 0.6.0 - An Overview [<cite><a class="bibref" rel="biblioentry" href="#bib-BBC-WP193">BBC-WP193</a></cite>]</li>
            <li>White Paper 194 : The Universal Control API v.0.6.0 - Specification for the behaviour of a universal control server running on a set-top box, and the clients that connect to it [<cite><a class="bibref" rel="biblioentry" href="#bib-BBC-WP194">BBC-WP194</a></cite>]</li>
          </ul>
          <p>The BBC has prototyped various remote control and second screen experiences that use this API. These include:</p>
          <ul>
            <li>The presentation of time-synchronised slideshows</li>
            <li>Near-lip-synced alternative audio</li>
            <li>A Mobile phone as a remote control with support for blind users</li>
            <li>Enhancement of websites with awareness of current TV viewing</li>
          </ul>
          <p>The following documents briefly describe some of these applications:</p>
          <ul>
            <li><a href="http://www.w3.org/2010/11/web-and-tv/slides/BBC-Universal-Control-API.pdf">Universal Control API</a> (PDF slides)</li>
            <li><a href="http://www.bbc.co.uk/blogs/researchanddevelopment/2011/04/the-autumnwatch-companion---de.shtml">Designing for second screens: The Autumnwatch Companion</a></li>
          </ul>
        </div>
      </div>

      <div id="telecom-paristech" class="section">
        <h3><span class="secno">8.3 </span>Telecom ParisTech</h3>
        <p>Telecom ParisTech is a French academic institution where research relevant to HNTF on combining <acronym title="World Wide Web Consortium">W3C</acronym> widgets, SVG and UPnP went on from 2008 to 2010. The work has been implemented as part of the open source multimedia player GPAC (see <a href="http://gpac.wp.institut-telecom.fr/">GPAC</a>) and is publically available. All use cases contributed by Telecom ParisTech to HNTF have been implemented in that system, but for the &quot;pull migration&quot; use case.</p>
        <p>This work is described in the following papers:</p>
        <ol>
          <li><a href="http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=11187">Communicating and migratable interactive multimedia documents</a> (PDF) [<cite><a class="bibref" rel="biblioentry" href="#bib-PTECH-MIGRATE">PTECH-MIGRATE</a></cite>]</li>
          <li><a href="http://www.svgopen.org/2009/papers/28-SVG_Communicating_Widgets/">SVG Communicating Widgets</a> [<cite><a class="bibref" rel="biblioentry" href="#bib-PTECH-SCW">PTECH-SCW</a></cite>]</li>
          <li><a href="http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=9917">Declarative Interfaces for Dynamic Widgets Communications</a> (PDF) [<cite><a class="bibref" rel="biblioentry" href="#bib-PTECH-DECL">PTECH-DECL</a></cite>]</li>
          <li><a href="http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=9919">Widgets Mobility</a> (PDF) [<cite><a class="bibref" rel="biblioentry" href="#bib-PTECH-WM">PTECH-WM</a></cite>]</li>
        </ol>
      </div>

      <div id="cea-2014-web-based-protocol-and-framework-for-remote-user-interface---overview" class="section">
        <h3><span class="secno">8.4 </span>CEA-2014 Web-based Protocol and Framework for Remote User Interface - Overview</h3>

        <p>CEA-2014 [<cite><a class="bibref" rel="biblioentry" href="#bib-CEA-2014">CEA-2014</a></cite>] describes web based Remote UI applications for CE devices. CEA-2014 is referenced by multiple Standards Development Organizations to provide ecosystem specific Remote UI solutions.</p>
        <p>CEA-2014 leverages existing web technology standards including XHTML for screen layout and user interactions; and ECMAScript for interactive application support. In addition, CEA-2014 provides additional standardized interfaces addressing the following areas:</p>
        <ul>
          <li>Remote UI Application Listing</li>
          <li>Client Capabilities Matching</li>
          <li>Standardized Audio-Video Player</li>
          <li>Digital Rights Management Framework</li>
          <li>Content Download Management Framework</li>
          <li>UPnP / DLNA Home Network Framework</li>
          <li>SVG (Scalable Vector Graphics) integration with XHTML</li>
          <li>Server to Client Notification Framework</li>
          <li>Remote UI Save and Restore Framework</li>
        </ul>

        <div id="remote-ui-application-listing" class="section">
          <h4><span class="secno">8.4.1 </span>Remote UI Application Listing</h4>
          <p>CEA-2014 defines a mechanism for a Remote UI server to list available applications. This mechanism is based on an XML schema (XML UI Listing) which provides application descriptive metadata. In addition, a CEA-2014 server may include metadata for multiple versions of the same Remote UI application with differing client capability requirements. A Remote UI client system may then choose a version of a Remote UI application which best matches its capabilities. See Client Capability Matching in the following section</p>
        </div>

        <div id="client-capabilities-matching" class="section">
          <h4><span class="secno">8.4.2 </span>Client Capabilities Matching</h4>
          <p>CEA-2014 defines XML metadata describing the capabilities of a connecting Remote UI client system. These capabilities include Input Support (Remote Control, Keyboard, etc.), AV Player Capabilities, Client Display Capabilities (resolution, color space) and Digital Rights Management capabilities. When a Remote UI client connects to a server, it will first examine the capability requirements of the Remote UI applications offered and will connect to a version that best matches its capabilities. During connection, the Remote UI Client provides its capabilities to the server. The server may modify the web-page provided to better match the connecting client's capabilities or may reject the connection if it cannot tailor the page to support the client's capabilities.</p>
        </div>

        <div id="standardized-audio-video-player" class="section">
          <h4><span class="secno">8.4.3 </span>Standardized Audio-Video Player</h4>
          <p>CEA-2014 defines a standardized Audio-Video Player object. The AV Player object provides methods for control of AV playback (Play, Stop, Pause, Seek and Loop). In addition the AV player provides a &quot;lock-out&quot; mechanism disables end-users from skipping &quot;required content&quot;. AV player callbacks are defined to notify web-pages of various playback related state-changes. The CEA specification defines a state-machine for the AV player so web-pages can rely on predictable AV player state transition behavior.</p>
        </div>

        <div id="digital-rights-management-framework" class="section">
          <h4><span class="secno">8.4.4 </span>Digital Rights Management Framework</h4>
          <p>CEA-2014 defines a framework to allow a Remote UI application (web-page) to communicate with DRM Agent(s) installed on a Remote UI client. This DRM framework allows generic messaging between the web-page and DRM Agents installed on the Remote UI client.</p>
          <p><strong>Note:</strong> CEA-2014 does not define the specifics of any particular DRM system beyond listing of available Digital Rights systems in Remote UI client capabilities.</p>
        </div>

        <div id="content-download-management-framework" class="section">
          <h4><span class="secno">8.4.5 </span>Content Download Management Framework</h4>
          <p>CEA-2014 defines a framework for Remote UI applications to initiate the download of content. Once the download process is started the Remote UI client can switch to other Remote UI applications. In addition to providing status of download operations, CEA-2014 defines a Content Access Descriptor XML schema to describe content to be downloaded. Since Content Access Descriptors are XML documents they may be associated with URLs and embedded into Remote UI applications.</p>
        </div>

        <div id="upnp---dlna-home-network-framework" class="section">
          <h4><span class="secno">8.4.6 </span>UPnP / DLNA Home Network Framework</h4>
          <p>CEA-2014 defines a UPnP / DLNA binding so that web-pages can discover and control home network devices. The binding allows Remote UI applications discover, manage events and command UPnP and DLNA devices. In conjunction with the UPnP / DLNA Home Network Framework the Standardized AV Player is required to comply with DLNA media transport requirements. The combination makes CEA-2014 Remote UI clients suitable to support both UPnP and DLNA applications.</p>
          <p>The ability for Remote UI applications (originating from outside the home) to access home network devices presents significant security and privacy concerns. CEA-2014 requires implementation of a variety of security mechanisms to protect end-users Remote UI applications performing unauthorized access to Home Network devices.</p>
        </div>

        <div id="svg--scalable-vector-graphics--integration-with-xhtml" class="section">
          <h4><span class="secno">8.4.7 </span>SVG (Scalable Vector Graphics) integration with XHTML</h4>
          <p>CEA-2014 supports the embedding of SVG markup within XHTML pages and vice versa. CEA-2014 addresses some issues with regard to differing DOM models and event handling between SVG and XHTML resulting from the combination of SVG and XHTML content on the same web-page.</p>
        </div>

        <div id="server-to-client-notification-framework" class="section">
          <h4><span class="secno">8.4.8 </span>Server to Client Notification Framework</h4>
          <p>CEA-2014 provides the capability for servers to request Remote UI clients display web-pages. An &quot;event&quot; mechanism is defined so that Remote UI clients and servers can classify these Notification messages. In addition CEA-2014 clients may recover previously sent notifications that may have been missed while the Remote UI client was not present on the network.</p>
        </div>

        <div id="remote-ui-save-and-restore-framework" class="section">
          <h4><span class="secno">8.4.9 </span>Remote UI Save and Restore Framework</h4>
          <p>CEA-2014 provides a framework for a Remote UI application to save its state and POST it to a Remote UI server. The saved information consists of a reference to the original Remote UI application URL and metadata describing the saved state of the application. The save state may be restored by a different device effectively allowing the application to be moved to a different Remote UI client. The save-restore process may be triggered by the Remote UI application itself or by a request initiated external to the Remote UI client.</p>
        </div>
      </div>

      <div id="universal-plug-n-play--upnp--reference" class="section">
        <h3><span class="secno">8.5 </span>Universal Plug'n Play (UPnP) Reference</h3>

        <div id="introduction-1" class="section">
          <h4><span class="secno">8.5.1 </span>Introduction</h4>
          <p>This section discusses devices compliant to UPnP (Universal Plug'n Play) architecture. This architecture has been developed over +10 years by member companies of the UPnP Forum. Although this section focuses on UPnP device models defined for AV (Audio-Visual) devices, UPnP defines a number of other standard device models for Home Network Gateways, Telephony, Remote Access, and Home Automation applications.</p>
          <p>Further information concerning membership in the UPnP Forum may be obtained on <a href="http://www.upnp.org/">UPnP Web site</a>.</p>
        </div>

        <div id="upnp-av-architecture" class="section">
          <h4><span class="secno">8.5.2 </span>UPnP AV Architecture</h4>
          <p>UPnP AV (Audio-Visual) Architecture [<cite><a class="bibref" rel="biblioentry" href="#bib-UPNP-AVARCH2">UPNP-AVARCH2</a></cite>] provides an informative overview of the UPnP model for media serving and media rendering devices. It is a good starting point for readers becoming familiar with UPnP architecture related to audio-video device support.</p>
        </div>

        <div id="upnp-device-architecture" class="section">
          <h4><span class="secno">8.5.3 </span>UPnP Device Architecture</h4>
          <p>UPnP Device Architecture [<cite><a class="bibref" rel="biblioentry" href="#bib-UPNP-DEVICEARCH">UPNP-DEVICEARCH</a></cite>] provides the basic mechanisms for discovering, advertising, and commanding of UPnP devices. All UPnP Devices implement and comply with the requirements in this specification.</p>
        </div>

        <div id="upnp-media-renderer-device" class="section">
          <h4><span class="secno">8.5.4 </span>UPnP Media Renderer Device</h4>
          <p>The UPnP MediaRenderer specification [<cite><a class="bibref" rel="biblioentry" href="#bib-UPNP-MR3">UPNP-MR3</a></cite>] defines the required and optional services of a standard UPnP MediaRenderer device.</p>
          
          <p>The following references define the required and optional services provided by a standard UPnP MediaRenderer device:</p>
          <ul>
            <li><strong>UPnP Rendering Control Service</strong>
            <br />The UPnP RenderingControl specification [<cite><a class="bibref" rel="biblioentry" href="#bib-UPNP-RC3">UPNP-RC3</a></cite>] defines actions and variables which control presentation of content on a standard UPnP MediaRenderer device. Examples may include: controlling display brightness, audio volume, soundtrack selection, display pan/zoom, etc.</li>
            <li><strong>UPnP AVTransport Service</strong>
            <br />The UPnP AVTransport specification [<cite><a class="bibref" rel="biblioentry" href="#bib-UPNP-AVT3">UPNP-AVT3</a></cite>] defines actions and variables which control connection to and playback of AV content on a standard UPnP MediaRenderer device. Examples may include: setting a playback URL, issuing Play, Stop, Seek, and Pause operations and determining the current state of a rendering device (Playing, Stopped, Paused, etc).</li>
            <li><strong>UPnP Connection Manager</strong>
            <br />The UPnP ConnectionManager service [<cite><a class="bibref" rel="biblioentry" href="#bib-UPNP-CM3">UPNP-CM3</a></cite>] defines actions and variables to allocate and control multiple sessions on a standard UPnP MediaRenderer device. Examples may include allocating a Picture-in-Picture window on a rendering device, or allocating an additional audio player instance on a rendering device.</li>
          </ul>
        </div>
         
        <div id="upnp-media-server-device" class="section">
          <h4><span class="secno">8.5.5 </span>UPnP Media Server Device</h4>
          <p>The UPnP MediaServer device specification [<cite><a class="bibref" rel="biblioentry" href="#bib-UPNP-MS4">UPNP-MS4</a></cite>] defines the required and optional services of a standard UPnP MediaServer device.</p>
          
          <p>The following references define services provided by a standard UPnP MediaServer device:</p>
          <ul>
            <li><strong>UPnP Content Directory Service</strong>
            <br />The UPnP ContentDirectory service [<cite><a class="bibref" rel="biblioentry" href="#bib-UPNP-CD4">UPNP-CD4</a></cite>] publishes metadata for stored content, broadcast content, channel lineup(s) and electronic programming guide(s). A UPnP MediaServer device may optionally serve content described by ContentDirectory service metadata or the ContentDirectory service may provide metadata referring to content residing on other home network servers.</li>
            <li><strong>UPnP Connection Manager Service</strong>
            <br />The UPnP ConnectionManager service [<cite><a class="bibref" rel="biblioentry" href="#bib-UPNP-CM3">UPNP-CM3</a></cite>] defines actions and variables controlling multiple sessions allocated on a standard UPnP server device. The ConnectionManager service runs on both standard UPnP MediaRender and UPnP MediaServer devices.</li>
            <li><strong>UPnP Device Protection Service</strong>
            <br />The UPnP DeviceProtection service specification [<cite><a class="bibref" rel="biblioentry" href="#bib-UPNP-DP1">UPNP-DP1</a></cite>] provides secure communication to UPnP devices. For a UPnP MediaServer, the UPnP DeviceProtection service controls access to the UPnP MediaServer device services.</li>
            <li><strong>UPnP Scheduled Recording Service</strong>
            <br />The UPnP ScheduledRecording service [<cite><a class="bibref" rel="biblioentry" href="#bib-UPNP-SR2">UPNP-SR2</a></cite>] defines actions and variables which control creating and tracking of recording requests for a recording device. Examples may include: creating a recording request based time or electronic programming guide metadata, displaying programs already recorded and displaying and controlling pending recording activities. The ScheduledRecording service supports recording from both network (URLs) and non-network sources (such as analog and digital tuners).</li>
          </ul>
        </div>
      </div>
        
      <div id="ericsson-labs" class="section">
        <h3><span class="secno">8.6 </span>Ericsson Labs</h3>
        
        <p>Ericsson Labs is the part of Ericsson Research that focuses on iterative open innovation and experiments with new technologies, services and business models. The purpose of Ericsson Labs is to support Ericsson’s vision of the Networked Society by working with partners including technology providers and third-party developers.</p>
        <p>Ericsson Labs provides access to experimental APIs in their infancy so that developers can create new, innovative services. &quot;Web Technologies&quot; is one of the major categories of experimental APIs and the category contains API named &quot;Web Device Connectivity&quot;.</p>
        <ul>
          <li><a href="https://labs.ericsson.com/">Ericsson Labs</a></li>
          <li><a href="https://labs.ericsson.com/apis?api_category=203">Web Technologies</a></li>
          <li><a href="https://labs.ericsson.com/apis/web-device-connectivity/">Web Device Connectivity</a> [<cite><a class="bibref" rel="biblioentry" href="#bib-ERICSSON-WDC">ERICSSON-WDC</a></cite>]</li>
        </ul>
        <p>The Web Device Connectivity API enables you to connect end users’ devices to the Web. It provides end users with new experiences of devices in their home networks being a part of the Web and web sites can seamlessly make use of those home devices. For example, an web site or a blog can access the viewer's DLNA enabled TV and let the viewer choose his/her DLNA enabled TV to play the contents on the web site.</p>
        <ul>
          <li><a href="https://www.youtube.com/watch?v=fwQA4K9UdTM&amp;feature=player_embedded">Demo video</a></li>
        </ul>
        <p>Web Device Connectivity platform consists of a software running inside each end users' home network and interacting with home devices, in-cloud servers aggregating device information and enforcing security policy, and a Javascript library providing API for web sites. Developers can create web sites, by including the Javascript library, which accesses devices in end users' home networks through the Ericsson Labs Web Device Connectivity platform.</p>
      </div>
    </div>
  

<div id="references" class="appendix section">
<!-- OddPage -->
<h2><span class="secno">A. </span>References</h2><div id="normative-references" class="section"><h3><span class="secno">A.1 </span>Normative references</h3><p>No normative references.</p></div><div id="informative-references" class="section"><h3><span class="secno">A.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-BBC-WP193">[BBC-WP193]</dt><dd>J.P. Barrett; M.E. Hammond; S.J.E Jolly. <a href="http://www.bbc.co.uk/rd/publications/whitepaper193.shtml"><cite>White Paper 193 : The Universal Control API version 0.6.0 - An Overview</cite></a>. June 2011. URL: <a href="http://www.bbc.co.uk/rd/publications/whitepaper193.shtml">http://www.bbc.co.uk/rd/publications/whitepaper193.shtml</a>
</dd><dt id="bib-BBC-WP194">[BBC-WP194]</dt><dd>J.P. Barrett; M.E. Hammond; S.J.E Jolly. <a href="http://www.bbc.co.uk/rd/publications/whitepaper194.shtml"><cite>White Paper 194 : The Universal Control API v.0.6.0 - Specification for the behaviour of a universal control server running on a set-top box, and the clients that connect to it</cite></a>. June 2011. URL: <a href="http://www.bbc.co.uk/rd/publications/whitepaper194.shtml">http://www.bbc.co.uk/rd/publications/whitepaper194.shtml</a>
</dd><dt id="bib-CEA-2014">[CEA-2014]</dt><dd><a href="http://www.ce.org/Standards/browseByCommittee_2757.asp"><cite>Web-based Protocol and Framework for Remote User Interface on UPnP Networks and the Internet (Web4CE)</cite></a>. January 2011. ANSI/CEA Standard. URL: <a href="http://www.ce.org/Standards/browseByCommittee_2757.asp">http://www.ce.org/Standards/browseByCommittee_2757.asp</a>
</dd><dt id="bib-CLABS-HNAPI">[CLABS-HNAPI]</dt><dd><a href="http://www.w3.org/2011/webtv/HNTF/CableLabs_Revised_API_20110727-2.pdf"><cite>CableLabs Revised Home Networking API</cite></a>. 26 July 2011. Draft proposal. URL: <a href="http://www.w3.org/2011/webtv/HNTF/CableLabs_Revised_API_20110727-2.pdf">http://www.w3.org/2011/webtv/HNTF/CableLabs_Revised_API_20110727-2.pdf</a>
</dd><dt id="bib-DISCO-PROP">[DISCO-PROP]</dt><dd>Rich Tibbett, Clarke Stevens. <a href="http://people.opera.com/richt/release/specs/discovery/Overview.html"><cite>Networked Service Discovery and Messaging</cite></a>. 22 September 2011. Draft proposal (no official standing). URL: <a href="http://people.opera.com/richt/release/specs/discovery/Overview.html">http://people.opera.com/richt/release/specs/discovery/Overview.html</a>
</dd><dt id="bib-ERICSSON-WDC">[ERICSSON-WDC]</dt><dd><a href="https://labs.ericsson.com/apis/web-device-connectivity/"><cite>Web Device Connectivity</cite></a>. 18 October 2010. Ericsson Labs. URL: <a href="https://labs.ericsson.com/apis/web-device-connectivity/"></a>
</dd><dt id="bib-IEEE1588">[IEEE1588]</dt><dd><a href="http://grouper.ieee.org/groups/1588/"><cite>IEEE 1588-2008: A Precision Clock Synchronization Protocol for Networked Measurement and Control Systems</cite></a>. 24 July 2008. URL: <a href="http://grouper.ieee.org/groups/1588/">http://grouper.ieee.org/groups/1588/</a>
</dd><dt id="bib-IEEE802-1AS">[IEEE802-1AS]</dt><dd>Geoff Garner. <a href="http://ieee802.org/1/pages/802.1as.html"><cite>IEEE 802.1AS - Timing and Synchronization</cite></a>. 30 March 2011. IEEE Standard. URL: <a href="http://ieee802.org/1/pages/802.1as.html">http://ieee802.org/1/pages/802.1as.html</a>
</dd><dt id="bib-PTECH-DECL">[PTECH-DECL]</dt><dd>C. Concolato; J. Le Feuvre; J. C. Dufourd. <a href="http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=9917"><cite>Declarative Interfaces for Dynamic Widgets Communications</cite></a>. September 2009. Document Engineering, Munich, Germany, September 2009, pp. 241-244. PDF Document. URL: <a href="http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=9917">http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=9917</a>
</dd><dt id="bib-PTECH-MIGRATE">[PTECH-MIGRATE]</dt><dd>C. Concolato; J. C. Dufourd; J. Le Feuvre; K. Parkl J. Song. <a href="http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=11187"><cite>Communicating and migratable interactive multimedia documents</cite></a>. May 2011. Multimedia Tools and Applications. PDF document. URL: <a href="http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=11187">http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=11187</a>
</dd><dt id="bib-PTECH-SCW">[PTECH-SCW]</dt><dd>J. C. Dufourd; C. Concolato; J. Le Feuvre. <a href="http://www.svgopen.org/2009/papers/28-SVG_Communicating_Widgets/"><cite>SVG Communicating Widgets</cite></a>. October 2009. SVG Open, Mountain View, CA, USA. URL: <a href="http://www.svgopen.org/2009/papers/28-SVG_Communicating_Widgets/">http://www.svgopen.org/2009/papers/28-SVG_Communicating_Widgets/</a>
</dd><dt id="bib-PTECH-WM">[PTECH-WM]</dt><dd>J. Le Feuvre; C. Concolato; J. C. Dufourd. <a href="http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=9919"><cite>Widgets Mobility</cite></a>. September 2009. International Conference on Mobile Technology, Applications and Systems, Nice, France. PDF document. URL: <a href="http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=9919">http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=9919</a>
</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels.</cite></a> March 1997. Internet RFC 2119.  URL: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a> 
</dd><dt id="bib-UPNP-AVARCH2">[UPNP-AVARCH2]</dt><dd>John Ritchie, Thomas Kuehnel, Wouter van der Beek, Jeffrey Kang. <a href="http://www.upnp.org/specs/av/UPnP-av-AVArchitecture-v2-20101231.pdf"><cite>UPnP AV Architecture:2</cite></a>. 31 December 2010. UPnP Forum. Standardized DCP. For UPnP Version 1.0. PDF document. URL: <a href="http://www.upnp.org/specs/av/UPnP-av-AVArchitecture-v2-20101231.pdf">http://www.upnp.org/specs/av/UPnP-av-AVArchitecture-v2-20101231.pdf</a>
</dd><dt id="bib-UPNP-AVT3">[UPNP-AVT3]</dt><dd><a href="http://www.upnp.org/specs/av/UPnP-av-AVTransport-v3-Service-20101231.pdf"><cite>AVTransport:3 Service</cite></a>. 31 December 2010. UPnP Forum. Standardized DCP. For UPnP Version 1.0. PDF document. URL: <a href="http://www.upnp.org/specs/av/UPnP-av-AVTransport-v3-Service-20101231.pdf">http://www.upnp.org/specs/av/UPnP-av-AVTransport-v3-Service-20101231.pdf</a>
</dd><dt id="bib-UPNP-CD4">[UPNP-CD4]</dt><dd><a href="http://www.upnp.org/specs/av/UPnP-av-ContentDirectory-v4-Service-20101231.pdf"><cite>ContentDirectory:4 Service</cite></a>. 31 December 2010. UPnP Forum. Standardized DCP. For UPnP Version 1.0. URL: <a href="http://www.upnp.org/specs/av/UPnP-av-ContentDirectory-v4-Service-20101231.pdf">http://www.upnp.org/specs/av/UPnP-av-ContentDirectory-v4-Service-20101231.pdf</a>
</dd><dt id="bib-UPNP-CM3">[UPNP-CM3]</dt><dd><a href="http://www.upnp.org/specs/av/UPnP-av-ConnectionManager-v3-Service-20101231.pdf"><cite>ConnectionManager:3 Service</cite></a>. 31 December 2010. UPnP Forum. Standardized DCP. For UPnP Version 1.0. URL: <a href="http://www.upnp.org/specs/av/UPnP-av-ConnectionManager-v3-Service-20101231.pdf">http://www.upnp.org/specs/av/UPnP-av-ConnectionManager-v3-Service-20101231.pdf</a>
</dd><dt id="bib-UPNP-DEVICEARCH">[UPNP-DEVICEARCH]</dt><dd><a href="http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20081015.pdf"><cite>UPnP Device Architecture 1.0</cite></a>. 15 October 2008. UPnP Forum. For UPnP Version 1.0. PDF document. URL: <a href="http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20081015.pdf">http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20081015.pdf</a>
</dd><dt id="bib-UPNP-DP1">[UPNP-DP1]</dt><dd><a href="http://www.upnp.org/specs/gw/UPnP-gw-DeviceProtection-v1-Service-20110224.pdf"><cite>DeviceProtection:1 Service</cite></a>. 24 February 2011. UPnP Forum. Standardized DCP. For UPnP Version 1.0. URL: <a href="http://www.upnp.org/specs/gw/UPnP-gw-DeviceProtection-v1-Service-20110224.pdf">http://www.upnp.org/specs/gw/UPnP-gw-DeviceProtection-v1-Service-20110224.pdf</a>
</dd><dt id="bib-UPNP-MR3">[UPNP-MR3]</dt><dd><a href="http://www.upnp.org/specs/av/UPnP-av-MediaRenderer-v3-Device-20101231.pdf"><cite>MediaRenderer:3 Device</cite></a>. 31 December 2010. UPnP Forum. Standardized DCP. For UPnP Version 1.0. PDF document. URL: <a href="http://www.upnp.org/specs/av/UPnP-av-MediaRenderer-v3-Device-20101231.pdf">http://www.upnp.org/specs/av/UPnP-av-MediaRenderer-v3-Device-20101231.pdf</a>
</dd><dt id="bib-UPNP-MS4">[UPNP-MS4]</dt><dd><a href="http://upnp.org/specs/av/UPnP-av-MediaServer-v4-Device.pdf"><cite>MediaServer:4 Device</cite></a>. 31 December 2010. UPnP Forum. Standardized DCP. For UPnP Version 1.0. PDF document. URL: <a href="http://upnp.org/specs/av/UPnP-av-MediaServer-v4-Device.pdf">http://upnp.org/specs/av/UPnP-av-MediaServer-v4-Device.pdf</a>
</dd><dt id="bib-UPNP-RC3">[UPNP-RC3]</dt><dd><a href="http://www.upnp.org/specs/av/UPnP-av-RenderingControl-v3-Service-20101231.pdf"><cite>RenderingControl:3 Service</cite></a>. 31 December 2010. UPnP Forum. Standardized DCP. For UPnP Version 1.0. PDF document. URL: <a href="http://www.upnp.org/specs/av/UPnP-av-RenderingControl-v3-Service-20101231.pdf">http://www.upnp.org/specs/av/UPnP-av-RenderingControl-v3-Service-20101231.pdf</a>
</dd><dt id="bib-UPNP-SR2">[UPNP-SR2]</dt><dd><a href="http://www.upnp.org/specs/av/UPnP-av-ScheduledRecording-v2-Service-20101231.pdf"><cite>ScheduledRecording:2 Service</cite></a>. 31 December 2010. UPnP Forum. Standardized DCP. For UPnP Version 1.0. URL: <a href="http://www.upnp.org/specs/av/UPnP-av-ScheduledRecording-v2-Service-20101231.pdf">http://www.upnp.org/specs/av/UPnP-av-ScheduledRecording-v2-Service-20101231.pdf</a>
</dd><dt id="bib-WIDGETS">[WIDGETS]</dt><dd>Marcos Cáceres. <a href="http://www.w3.org/TR/widgets/"><cite>Widget Packaging and XML Configuration</cite></a>. W3C Proposed Recommendation. URL: <a href="http://www.w3.org/TR/widgets/">http://www.w3.org/TR/widgets/</a> 
</dd></dl></div></div></body></html>