index.html 115 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
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-us"><head><title>Media Fragments URI 1.0</title><style type="text/css">
        /**/
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

ol.enumar      { list-style-type: decimal; }
ol.enumla      { list-style-type: lower-alpha; }
ol.enumlr      { list-style-type: lower-roman; }
ol.enumua      { list-style-type: upper-alpha; }
ol.enumur      { list-style-type: upper-roman; }

dt.label       { display: run-in; }

li, p           { margin-top: 0.3em;
                 margin-bottom: 0.3em; }

.diff-chg       { background-color: yellow; }
.diff-del       { background-color: red; text-decoration: line-through;}
.diff-add       { background-color: lime; }

table          { empty-cells: show; }

table caption {
        font-weight: normal;
        font-style: italic;
        text-align: left;
        margin-bottom: .5em;
}

div.issue {
  color: red;
}
.rfc2119 {
  font-variant: small-caps;
}

div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}

div.boxedtext {
   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.practice
{
   margin: 1.5em 0.5em 1em 1em;
 }

@media screen {
 p.practice {
   position: relative;
   top: -2em;
   padding: 0;
   margin: 1.5em 0.5em -1em 1em;
}
}
/**/ </style><link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" /><link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-ED" /></head><body><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home" /></a></p>
<h1><a id="title" name="title" />Media Fragments URI 1.0</h1>
<h2><a id="w3c-doctype" name="w3c-doctype" />W3C Working Draft 30 November 2011</h2><dl><dt>This version:</dt><dd>
      <a href="http://www.w3.org/TR/2011/WD-media-frags-20111130/">http://www.w3.org/TR/2011/WD-media-frags-20111130/</a>
    </dd><dt>Latest version:</dt><dd>
      <a href="http://www.w3.org/TR/media-frags/">http://www.w3.org/TR/media-frags/</a>
    </dd><dt>Previous version:</dt><dd>
      <a href="http://www.w3.org/TR/2011/WD-media-frags-20110317/">http://www.w3.org/TR/2011/WD-media-frags-20110317/</a>
    </dd><dt>Editors:</dt><dd><a href="http://www.eurecom.fr/~troncy/">
          Raphaël Troncy
        </a>, EURECOM</dd><dd><a href="http://multimedialab.elis.ugent.be/emannens">
          Erik Mannens
        </a>, IBBT Multimedia Lab, University of Ghent</dd><dd><a href="http://blog.gingertech.net/">
          Silvia Pfeiffer
        </a>, W3C Invited Expert</dd><dd><a href="http://multimedialab.elis.ugent.be/dvdeurse">
          Davy Van Deursen
        </a>, IBBT Multimedia Lab, University of Ghent</dd><dt>Contributors:</dt><dd><a href="http://www.deri.ie/about/team/member/Michael_Hausenblas/">
          Michael Hausenblas
        </a>, DERI, National University of Ireland, Galway</dd><dd><a href="mailto:philipj@opera.com">
          Philip Jägenstedt
        </a>, Opera Software</dd><dd><a href="http://www.cwi.nl/~jack/">
          Jack Jansen
        </a>, CWI, Centrum Wiskunde &amp; Informatica, Amsterdam</dd><dd><a href="mailto:ylafon@w3.org">
          Yves Lafon
        </a>, W3C</dd><dd><a href="http://www.kfish.org/">
          Conrad Parker
        </a>, W3C Invited Expert</dd><dd><a href="http://blog.tomayac.com/">
          Thomas Steiner
        </a>, Google, Inc.</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.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <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></div><hr /><div>
<h2><a id="abstract" name="abstract" />Abstract</h2><p>
        This document describes the Media Fragments 1.0 specification. It specifies the syntax for constructing media fragment URIs and explains how
        to handle them when used over the HTTP protocol. The syntax is based on the specification of particular name-value pairs that can be used
        in URI fragment and URI query requests to restrict a media resource to a certain fragment.
        The Media Fragment WG has no authority to update registries of all targeted media types. We recommend media type owners to harmonize 
        their existing schemes with the ones proposed in this document and update or add the fragment semantics specification to their 
        media type registration.
      </p></div><div>
<h2><a id="status" name="status" />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 W3C publications and the latest revision
  of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at
  http://www.w3.org/TR/.</em></p><p>
    This is the Candidate Recommendation of the Media Fragments URI 1.0 specification. It has been
    produced by the <a href="http://www.w3.org/2008/WebVideo/Fragments/">Media Fragments Working Group</a>, which is part of the
    <a href="http://www.w3.org/2008/WebVideo/">W3C Video on the Web Activity</a>.
    The Working Group expects to advance this specification to 
    <a href="http://www.w3.org/2004/02/Process-20040205/tr.html#RecsW3C">Recommendation</a> Status.
  </p><p>
    The W3C Membership and other interested parties are invited to review this Candidate Recommendation document 
    and send comments through 20 November 2011.
    Please send comments about this document to <a href="mailto:public-media-fragment@w3.org">public-media-fragment@w3.org</a> mailing list (<a href="http://lists.w3.org/Archives/Public/public-media-fragment/">public
    archive</a>).
    Use "[CR Media Fragment]" in the subject line of your email.
    We expect that sufficient feedback to determine its future will have been received by 20 November 2011.
    This specification will remain a Candidate Recommendation until at least 20 November 2011.
  </p><p>
    The <a href="http://www.w3.org/2008/WebVideo/Fragments/">Media Fragments Working Group</a> will advance this specification to 
    Proposed Recommendation when the following exit criteria have been met:
  </p><ol class="enumar"><li>Sufficient reports of implementation experience have been gathered to demonstrate that the Media Fragments URI syntax and processing 
    features are implementable and are interpreted in a consistent manner. To do so, the Working Group will insure that all features 
    have been implemented at least twice in an interoperable way.</li><li>The implementations have been developed independently.</li><li>The Working Group has adopted a public test suite for the 
    <a href="http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases">User Agents</a> and has produced 
    an implementation report for this specification.</li></ol><p>
    The Implementation results are publicly released and are intended solely to be used as proof of 
    Media Fragments URI implementability. It is only a snap shot of the actual implementation behaviors at one moment of time, as these 
    implementations may not be immediately available to the public. The interoperability data is not intended to be used for assessing 
    or grading the performance of any individual implementation. Any feedback on implementation and use of this specification would be 
    very welcome. To the extent possible, please provide a separate email message for each distinct comment.
  </p><p>
    This Candidate Recommendation version of the Media Fragments URI 1.0 specification incorporates requests for changes from comments sent during the first 
    and second Last Call Review, as agreed with the commenters (see <a href="comments-disposal.html">Disposition of Last Call comments</a>) and changes 
    following implementation experiences from the Working Group. The Working Group would like to point out that the processing of media fragment URI when 
    used over the HTTP protocol is now described in a separate document <a href="recipes.html">Protocol for Media Fragments 1.0 Resolution in HTTP</a>.
  </p><p>
    For convenience, the differences between this CR version and the Second Last Call Working Draft are highlighted in the 
    <a href="lc2-cr-diff.htm">CR Diff document</a>. The differences between the Second Last Call Working Draft and the 
    First Last Call Working Draft are also highlighted in the <a href="lc1-lc2-diff.htm">CR Diff document</a>.
  </p><p>
    Publication as a Working Draft 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>
    This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">
    5 February 2004 W3C Patent Policy</a>. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/42785/status">public 
    list of any patent disclosures</a> made in connection with the 
    deliverables of the group; that page also includes instructions 
    for disclosing a patent. An individual who has actual knowledge 
    of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential 
    Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 
    6 of the W3C Patent Policy</a>.
  </p></div><div class="toc">
<h2><a id="contents" name="contents" />Table of Contents</h2><p class="toc">1 <a href="#introduction">Introduction</a><br />
2 <a href="#standardisation">Standardisation Issues</a><br />
    2.1 <a href="#standardisation-terminology">Terminology</a><br />
    2.2 <a href="#standardisation-approach">Media Fragments Standardisation</a><br />
        2.2.1 <a href="#standardisation-URI-fragments">URI Fragments</a><br />
        2.2.2 <a href="#standardisation-URI-queries">URI Queries</a><br />
3 <a href="#fragment-query">URI fragment and URI query</a><br />
    3.1 <a href="#URIquery-vs-fragments">When to choose URI fragments? When to choose URI queries?</a><br />
    3.2 <a href="#URIfragment-user-agent">Resolving URI fragments within the user agent</a><br />
    3.3 <a href="#URIfragment-server">Resolving URI fragments with server help</a><br />
    3.4 <a href="#URIfragment-proxies">Resolving URI fragments in a proxy cacheable manner</a><br />
    3.5 <a href="#URIquery-media-fragments">Resolving URI queries</a><br />
    3.6 <a href="#URIquery-URIfragment">Combining URI fragments and URI queries</a><br />
4 <a href="#media-fragment-syntax">Media Fragments Syntax</a><br />
    4.1 <a href="#general-structure">General Structure</a><br />
    4.2 <a href="#fragment-dimensions">Fragment Dimensions</a><br />
        4.2.1 <a href="#naming-time">Temporal Dimension</a><br />
            4.2.1.1 <a href="#npt-time">Normal Play Time (NPT)</a><br />
            4.2.1.2 <a href="#smpte-time">SMPTE time codes</a><br />
            4.2.1.3 <a href="#clock-time">Wall-clock time code</a><br />
        4.2.2 <a href="#naming-space">Spatial Dimension</a><br />
        4.2.3 <a href="#naming-track">Track Dimension</a><br />
        4.2.4 <a href="#naming-id">ID Dimension</a><br />
        4.2.5 <a href="#common-syntax">Common Syntax</a><br />
5 <a href="#media-fragment-processing">Media Fragments Processing</a><br />
    5.1 <a href="#processing-media-fragment-uri">Processing Media Fragment URI</a><br />
        5.1.1 <a href="#processing-name-value-components">Processing name-value components</a><br />
        5.1.2 <a href="#processing-name-value-lists">Processing name-value lists</a><br />
    5.2 <a href="#processing-protocol-frag">Protocol for URI fragment Resolution in HTTP</a><br />
    5.3 <a href="#processing-protocol-query">Protocol for URI query Resolution in HTTP</a><br />
6 <a href="#media-fragment-semantics">Media Fragments Semantics</a><br />
    6.1 <a href="#valid-uri">Valid Media Fragment URIs</a><br />
        6.1.1 <a href="#valid-uri-temporal">Valid temporal dimension</a><br />
        6.1.2 <a href="#valid-uri-spatial">Valid spatial dimension</a><br />
        6.1.3 <a href="#valid-uri-track">Valid track dimension</a><br />
        6.1.4 <a href="#valid-uri-id">Valid id dimension</a><br />
    6.2 <a href="#error-uri">Errors detectable based on the URI</a><br />
        6.2.1 <a href="#error-uri-general">Errors on the general URI level</a><br />
        6.2.2 <a href="#error-uri-temporal">Errors on the temporal dimension</a><br />
        6.2.3 <a href="#error-uri-spatial">Errors on the spatial dimension</a><br />
        6.2.4 <a href="#error-uri-track">Errors on the track dimension</a><br />
        6.2.5 <a href="#error-uri-id">Errors on the id dimension</a><br />
    6.3 <a href="#error-media">Errors detectable based on information of the source media</a><br />
        6.3.1 <a href="#error-media-general">Errors on the general level</a><br />
        6.3.2 <a href="#error-media-temporal">Errors on the temporal dimension</a><br />
        6.3.3 <a href="#error-media-spatial">Errors on the spatial dimension</a><br />
        6.3.4 <a href="#error-media-track">Errors on the track dimension</a><br />
        6.3.5 <a href="#error-media-id">Errors on the id dimension</a><br />
7 <a href="#implementor-notes">Notes to Implementors (non-normative)</a><br />
    7.1 <a href="#media-fragment-browser">Browsers Rendering Media Fragments</a><br />
    7.2 <a href="#media-fragment-display">Clients Displaying Media Fragments</a><br />
    7.3 <a href="#media-fragment-clients">All Media Fragment Clients</a><br />
    7.4 <a href="#media-fragment-servers">Media Fragment Servers</a><br />
    7.5 <a href="#media-fragment-webapps">Media Fragment Web Applications</a><br />
8 <a href="#conclusions">Conclusions</a><br />
    8.1 <a href="#qualification-resources">Qualification of Media Resources</a><br />
</p>
<h3><a id="appendices" name="appendices" />Appendices</h3><p class="toc">A <a href="#references-normative">References</a><br />
B <a href="#collected-syntax-uri">Collected ABNF Syntax for URI</a> (Non-Normative)<br />
C <a href="#collected-syntax-http">Collected ABNF Syntax for HTTP Headers</a> (Non-Normative)<br />
D <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br />
</p></div><hr /><div class="body"><div class="div1">
<h2><a id="introduction" name="introduction" />1 Introduction</h2><p>
        Audio and video resources on the World Wide Web are currently treated as "foreign" objects, which can only be embedded using a plugin that is capable of decoding and interacting with the media resource. Specific media servers are generally required to provide for server-side features such as direct access to time offsets into a video without the need to retrieve the entire resource. Support for such media fragment access varies between different media formats and inhibits standard means of dealing with such content on the Web.
      </p><p>
        This specification provides for a media-format independent, standard means of addressing media fragments on the Web using Uniform Resource Identifiers (URI). 
		In the context of this document, media fragments are regarded along four different dimensions: temporal, spatial, and tracks. 
		Further, a temporal fragment can be marked with a name and then addressed through a URI using that name, using the id dimension. 
		The specified addressing schemes apply mainly to audio and video resources - the spatial fragment addressing may also be used on images.
      </p><p>
        The aim of this specification is to enhance the Web infrastructure for supporting the addressing and retrieval of subparts of time-based Web resources, as well as the automated processing of such subparts for reuse. Example uses are the sharing of such fragment URIs with friends via email, the automated creation of such fragment URIs in a search engine interface, or the annotation of media fragments with RDF. Such use case examples as well as other side conditions on this specification and a survey of existing media fragment addressing approaches are provided in the requirements <cite><a href="#mf-req">Use cases and requirements for Media Fragments</a></cite> document that accompanies this specification document.
      </p><p>
        The following features are marked as risk. They can be removed from the specification if no sufficient implementations proved their
        interoperability. Those features are: the <a href="#naming-track"><b>4.2.3 Track Dimension</b></a>,
        the <a href="#naming-id"><b>4.2.4 ID Dimension</b></a> and the <a href="#smpte-time"><b>4.2.1.2 SMPTE time codes</b></a> and 
        <a href="#clock-time"><b>4.2.1.3 Wall-clock time code</b></a> for specifying time.
      </p></div><div class="div1">
<h2><a id="standardisation" name="standardisation" />2 Standardisation Issues</h2><div class="div2">
<h3><a id="standardisation-terminology" name="standardisation-terminology" />2.1 Terminology</h3><p>
          The keywords <strong>MUST</strong>, <strong>MUST NOT</strong>, <strong>SHOULD</strong> and <strong>SHOULD NOT</strong> are to be interpreted as defined in <cite><a href="#rfc2119">RFC 2119</a></cite>.
        </p><p>
          According to <cite><a href="#rfc3986">RFC 3986</a></cite>, the term "URI" does not include relative
          references. In this document, we consider both URIs and relative
          references. Consequently, we use the term "URI reference" as defined in <cite><a href="#rfc3986">RFC 3986</a></cite> (section 4.1).
          For simplicity reasons, this document, however, only uses the term "media fragment URI" in place of "media fragment URI
          reference".
        </p><p>
          The following terms are used frequently in this document and need to be clearly understood:
        </p><ul><li>
            URI fragment: The fragment component is indicated by the presence of a
            number sign ("#") character and terminated by the end of the URI.</li><li>
            URI query: The query component is indicated by the first question
            mark ("?") character and terminated by a number sign ("#") character
            or by the end of the URI.</li><li>
            Media fragment URI: a URI addressing subparts of a media resource - that could be through URI queries or URI fragments</li></ul></div><div class="div2">
<h3><a id="standardisation-approach" name="standardisation-approach" />2.2 Media Fragments Standardisation</h3><p>
          The basis for the standardisation of media fragment URIs is the URI specification, <cite><a href="#rfc3986">RFC 3986</a></cite>. Providing media fragment identification information in URIs refers here to the specification of the structure of a URI fragment or a URI query. This document will explain how URI fragments and URI queries are structured to identify media fragments. It normalises the name-value parameters used in URI fragments and URI queries to address media fragments. These build on existing CGI parameter conventions.
        </p><p>
           In this section, we look at implications of standardising the structure of media fragment URIs.
        </p><div class="div3">
<h4><a id="standardisation-URI-fragments" name="standardisation-URI-fragments" />2.2.1 URI Fragments</h4><p>
            The URI specification <cite><a href="#rfc3986">RFC 3986</a></cite> says about the format of a URI fragment in Section 3.5:
          </p><p>
            <i>"The fragment's format and resolution is [..] dependent on the media type [RFC2046] of a potentially retrieved representation. [..] Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications."</i>
          </p><p>
            This essentially means that only media type definitions (as registered through the process defined in <cite><a href="#rfc4288">RFC 4288</a></cite>) are able to introduce a standard structure on URI fragments for that mime type. One part of the registration process of a media type can include information about how fragment identifiers in URIs are constructed for use in conjunction with this media type.
          </p><p>
             Note that the registration of URI fragment construction rules as expressed in Section 4.11 of <cite><a href="#rfc4288">RFC 4288</a></cite> is only a SHOULD-requirement. An analysis of all media type registrations showed that only a few media type registration in the audio/*, image/*, video/* branches are currently defining fragments or fragment semantics (see for example the fragment definition for SVG in <cite><a href="#svg1.1">SVG 1.1</a></cite>, chapter 17).
          </p><p>
            The Media Fragment WG has no authority to update registries of all targeted media types. To the best of our knowledge there are only <a href="http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaTypeReview">few media types  that actually have a specified fragment format</a> even if it is not registered with the media type: these include Ogg, MPEG-4, and MPEG-21. Further, only a small number of software packages actually supports these fragment formats. For all others, the semantics of the fragment are  considered to be unknown.
          </p><p>
            As such, the intention of this document is to propose a specification to all media type owners in the audio/*, image/*, and video/* branches for a structured approach to URI fragments and for specification of commonly agreed dimensions to address media fragments (i.e. subparts of a media resource) through URI fragments. We recommend media type owners to harmonize their existing schemes with the ones proposed in this document and update or add the fragment semantics specification to their media type registration.
          </p></div><div class="div3">
<h4><a id="standardisation-URI-queries" name="standardisation-URI-queries" />2.2.2 URI Queries</h4><p>The URI specification <cite><a href="#rfc3986">RFC 3986</a></cite> says about the format of a URI query in Section 3.4:
          </p><p>
            <i>"The query component [..] serves to identify a resource within the scope of the URI's scheme and naming authority (if any). [..] Query components are often used to carry identifying information in the form of "key=value" pairs [..]."</i>
          </p><p>
            URI query specifications are more closely linked to the URI scheme, some of which do not even use a query component. We are mostly concerned with the HTTP <cite><a href="#rfc2616">RFC 2616</a></cite> and the RTP/RTSP <cite><a href="#">rfc2326</a></cite> protocols here, which both support query components. HTTP says nothing about how a URI query has to be interpreted. RTSP explicitly says that fragment and query identifiers do not have a well-defined meaning at this time, with the interpretation left to the RTSP server.
          </p><p>
            The URI specification <cite><a href="#rfc3986">RFC 3986</a></cite> says generally that the data within the URI is often parsed by both the user agent and one or more servers. It refers in particular to HTTP in Section 7.3:
          </p><p>
            <i>"In HTTP, for example, a typical user agent will parse a URI into its five major components, access the authority's server, and send it the data within the authority, path, and query components.  A typical server will take that information, parse the path into segments and the query into key/value pairs, and then invoke implementation-specific handlers to respond to the request."</i>
          </p><p>
            Since the interpretation of query components resides with the functionality of servers, the intention of this document wrt query components is to recommend standard name-value pair formats for use in addressing media fragments through URI queries. We recommend server and server-type software providers to harmonize their existing schemes in use with media resources to support the nomenclature proposed in this specification.
          </p></div></div></div><div class="div1">
<h2><a id="fragment-query" name="fragment-query" />3 URI fragment and URI query</h2><table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">This section is non-normative</td></tr></table><p>
        To address a media fragment, one needs to find ways to convey the fragment information. This specification builds on URIs <cite><a href="#rfc3986">RFC 3986</a></cite>. Every URI is defined as consisting of four parts, as follows:
      </p><div class="exampleOuter"><p>
        &lt;scheme name&gt; : &lt;hierarchical part&gt; [ ? &lt;query&gt; ] [ # &lt;fragment&gt; ]
      </p></div><p>
        There are therefore two possibilities for representing the media fragment addressing in URIs: the <em>URI query part</em> or the <em>URI fragment part</em>.
      </p><div class="div2">
<h3><a id="URIquery-vs-fragments" name="URIquery-vs-fragments" />3.1 When to choose URI fragments? When to choose URI queries?</h3><p>
        For media fragment addressing, both approaches - URI query and URI fragment - are useful.
      </p><p>
        The main difference between a URI query and a URI fragment is that a URI query produces a new resource, while a URI fragment provides a secondary resource that has a relationship to the primary resource. URI fragments are resolved from the primary resource without another retrieval action. This means that a user agent should be capable to resolve a URI fragment on a resource it has already received without having to fetch more data from the server.
      </p><p>
        A further requirement put on a URI fragment is that the media type of the retrieved fragment should be the same as the media type of the primary resource. Among other things, this means that a URI fragment that points to a single video frame out of a longer video results in a one-frame video, not in a still image. To extract a still image, one would need to create a URI query scheme - something not envisaged here, but easy to devise.
      </p><p>
        There are different types of media fragment addressing in this specification. As noted in the <cite><a href="#mf-req">Use cases and requirements for Media Fragments</a></cite> document (section "Fitness Conditions on Media Containers/Resources"): not all container formats and codecs are "fit" for supporting the different types of fragment URIs. "Fitness" relates to the fact that a media fragment can be extracted from the primary resource without syntax element modifications or transcoding of the bitstream.
      </p><p>
        Resources that are "fit" can therefore be addressed with a URI fragment. Resources that are "conditionally fit" can be addressed with a URI fragment with an additional retrieval action that retrieves the modified syntax elements but leaves the codec data untouched. Resources that are "unfit" require transcoding. Such transcoded media fragments cannot be addressed with URI fragments, but only with URI queries.
      </p><p>
        Therefore, when addressing a media fragment with the URI mechanism, the author has to know whether this media fragment can be produced from the (primary) resource itself without any transcoding activities or whether it requires transcoding. In the latter case, the only choice is to use a URI query and to use a server that supports transcoding and delivery of a (primary) derivative resource to satisfy the query.
      </p></div><div class="div2">
<h3><a id="URIfragment-user-agent" name="URIfragment-user-agent" />3.2 Resolving URI fragments within the user agent</h3><p>
        A user agent may itself resolve and control the presentation of media fragment URIs. The simplest case arises where the user agent has
        already downloaded the entire resource and can perform the extraction from its locally cached copy. For some media types, it may also be
        possible to perform the extraction over the network without any special protocol assistance. For temporal fragments this requires a user
        agent to be able to seek on the media resource using existing protocol mechanisms.
      </p><p>
        An example of a URI fragment used to address a media fragment is <code>http://www.example.org/video.ogv#t=60,100</code>. In this case,
        the user agent knows that the primary resource is <code>http://www.example.org/video.ogv</code> and that it is only expected to display
        the portion of the primary resource that relates to the fragment <code>#t=60,100</code>, i.e. seconds 60-100. Thus, the relationship
        between the primary resource and the media fragment is maintained.
      </p><p>
        In traditional URI fragment retrieval, a user agent requests the complete primary resource from the server and then applies the
        fragmentation locally. In the media fragment case, this would result in a retrieval action on the complete media resource, on which the
        user agent would then locally perform its fragment extraction - something generally unviable for such large resources.
      </p><p>
        Therefore, media resources are not always retrieved over HTTP using a single request. They may be retrieved as a sequence of byte range requests
        on the original resource URI, or may be retrieved as a sequence of requests to different URIs each representing a small part of the
        media. The reasons for such mechanisms include bandwidth conservation, where a client chooses to space requests out over time during
        playback in order to maximize bandwidth available for other activities, and bandwidth adaptation, where a client selects among various
        representations with varying bitrate depending on the current bandwidth availability.
      </p><p>
        A user agent that knows how to map media fragments to byte ranges will be able to satisfy a URI fragment request such as the above example
        by itself. This is typically the case for user agents that know how to seek to media fragments over the network.
        For example, a user agent that deals with a media file that includes an index of its seekable structures can resolve the media fragment
        addresses to byte ranges from the index. This is the case e.g. with seekable QuickTime files. Another example is a user agent that
        knows how to seek on a media file through a sequence of byte range requests and eventually receives the correct media fragment. This is
        the case e.g. with Ogg files in Firefox versions above 3.5.
      </p><p>
        Similarly, a user agent that knows how to map media fragments to a sequence of URIs can satisfy a URI fragment request by itself. This
        is typically the case for user agents that perform adaptive streaming. For example, a user agent that deals with a media resource that
        contains a sequence of URIs, each a media file of a few seconds duration, can resolve the media fragment addresses to a subsequence of
        those URIs. This is the case with QuickTime adaptive bitrate streaming or IIS Smooth Streaming.
      </p><p>
        If such a user agent natively supports the media fragment syntax as specified in this document, it is deemed conformant to this
        specification for fragments and for the particular dimension.
      </p></div><div class="div2">
<h3><a id="URIfragment-server" name="URIfragment-server" />3.3 Resolving URI fragments with server help</h3><p>
        For user agents that natively support the media fragment syntax, but have to use their own seeking approach, this specification provides
        an optimisation that can make the byte offset seeking more efficient. It requires a conformant server with which the user agent will follow
        a protocol defined later in this document.
      </p><p>
        In this approach, the user agent asks the server to do the byte range mapping for the media fragment address itself and send back the
        appropriate byte ranges. This can not be done through the URI, but has to be done through adding protocol headers. User agents that
        interact with a conformant server to follow this protocol will receive the appropriate byte ranges directly and will not need to do costly
        seeking over the network.
      </p><p>
        Note that it is important that the server also informs the user agent what actual media fragment range it was able to retrieve. This is
        important since in the compressed domain it is not possible to extract data at an arbitrary resolution, but only at the resolution
        that the data was packaged in. For example, even if a user asked for <code>http://www.example.org/video.ogv#t=60,100</code> and the
        user agent sent a range request of <code>t=60,100</code> to the server, the server may only be able to return the range
        <code>t=58,103</code> as the closest decodable range that encapsulates all the required data.
      </p><p>
        Note that if done right, the native user agent support for media fragments and the improved server support can be integrated without
        problems: the user agent just needs to include the byte range and the media fragment range request in one request. A server that does not
        understand the media fragment range request will only react to the byte ranges, while a server that understands them will ignore the
        byte range request and only reply with the correct byte ranges. The user agent will understand from the response whether it received a
        reply to the byte ranges or the media fragment ranges request and can react accordingly.
      </p></div><div class="div2">
<h3><a id="URIfragment-proxies" name="URIfragment-proxies" />3.4 Resolving URI fragments in a proxy cacheable manner</h3><p>
        The current setup of the World Wide Web relies heavily on the use of caching Web proxies to speed up the delivery of content. In the
        case of URI fragments that are resolved by the server as indicated in the previous section, existing Web proxies have no means of
        caching these requests since they only understand byte ranges.
      </p><p>
        To make use of the existing Web proxy infrastructure of the Web, we need to make sure that the user agent only asks for byte ranges,
        so they can be served from the cache. This is possible if the server - instead of replying with the actual data - replies with the mapped
        byte ranges for the requested media fragment range. Then, the user agent is able to resend his range request this time with bytes only,
        which can possibly already be satisfied from the cache. Details of this will be specified later.
      </p><table border="1" summary="Editorial note: Raphael"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Raphael</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">Should we not foresee future "smart" media caches that would be able to actually cache range request in other units than bytes?
        </td></tr></table></div><div class="div2">
<h3><a id="URIquery-media-fragments" name="URIquery-media-fragments" />3.5 Resolving URI queries</h3><p>
        The described URI fragment addressing methods only work for byte-identical segments of a media resource, since we assume a simple mapping
        between the media fragment and bytes that each infrastructure element can deal with. Where it is impossible to maintain byte-identity
        and some sort of transcoding of the resource is necessary, the user agent is not able to resolve the fragmentation by itself and a
        server interaction is required. In this case, URI queries have to be used since they result in a server interaction and can deliver a
        transcoded resource.
      </p><p>
        Another use for URI queries is when a user agent actually wants to receive a completely new resource instead of just a byte range from
        an existing (primary) resource. This is, for example, the case for playlists of media fragment resources. Even if a media fragment
        could be resolved through a URI fragment, the URI query may be more desirable since it does not carry with itself the burden
        of the original primary resource - its file headers may be smaller, its duration may be smaller, and it does not automatically allow
        access to the remainder of the original primary resource.
      </p><p>
        When URI queries are used, the retrieval action has to additionally make sure to create a fully valid new resource. For example, for the
        Ogg format, this implies a reconstruction of Ogg headers to accurately describe the new resource (e.g. a non-zero start-time or different
        encoding parameters). Such a resource will be cached in Web proxies as a different resource to the original primary resource.
      </p><p>
        An example URI query that includes a media fragment specification is <code>http://www.example.org/video.ogv?t=60,100</code>. This results
        in a video of duration 40s (assuming the original video was more than 100s long).
      </p><p>
        Note that this resource has no per-se relationship to the original primary resource. As a user agent uses such a URI with e.g. a HTML5
        video element, the browser has no knowledge about the original resource and can only display this video as a 40s long video starting at 0s.
        The context of the original resource is lost.
      </p><p>
        A user agent may want to display the original start time of the resource as the start time of the video in order to be consistent with the
        information in the URI. It is possible to achieve this in one of two ways: either the video file itself has some knowledge that it is an
        extract from a different file and starts at an offset - or the user agent is told through the retrieval action which original primary
        resource the retrieved resource relates to and can find out information about it through another retrieval action. This latter option
        will be regarded later in this document.
      </p><p>
        An example for a media resource that has knowledge about itself of the required kind are Ogg files. Ogg files that have a skeleton
        track and were created correctly from the primary resource will know that their start time is not 0s but 60s in the above example.
        The browser can simply parse this information out of the received bitstream and may display a timeline that starts at 60s and ends at 100s
        in the video controls if it so desires.
      </p><p>
        Another option is that the browser parses the URI and knows about how media resources have a fragment specification that follows a standard.
        Then the browser can interpret the query parameters and extract the correct start and end times and also the original primary resource.
        It can then also display a timeline that starts at 60s and ends at 100s in the video controls. Further it can allow a right-click menu to
        click through to the original resource if required.
      </p><p>
         A use case where the video controls may neither start at 0s nor at 60s is a mashed-up video created through a list of media fragment URIs.
         In such a playlist, the user agent may prefer to display a single continuous timeline across all the media fragments rather than a
         collection of individual timelines for each fragment. Thus, the 60s to 100s fragment may e.g. be mapped to an interval at 3min20 to 4min.
      </p><p>
        No new protocol headers are required to execute a URI query for media fragment retrieval. Some optional protocol headers that improve the
        information exchange will be recommended later in this document.
      </p></div><div class="div2">
<h3><a id="URIquery-URIfragment" name="URIquery-URIfragment" />3.6 Combining URI fragments and URI queries</h3><p>
        A combination of a URI query for a media fragment with a URI fragment yields a URI fragment resolution on top of the newly created resource.
        Since a URI with a query part creates a new resource, we have to do the fragment offset on the new resource. This is simply a conformant
        behaviour to the URI standard <cite><a href="#rfc3986">RFC 3986</a></cite>.
      </p><p>
        For example, <code>http://www.example.org/video.ogv?t=60,100#t=20</code> will lead to the 20s fragment offset being applied to the new
        resource starting at 60 going to 100. Thus, the reply to this is a 40s long resource whose playback will start at an offset of 20s.
      </p><table border="1" summary="Editorial note: Silvia"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Silvia</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
          We should at the end of the document set up a table with all the different addressing types and http headers and say what we deem
          is conformant and how to find out whether a server or user agent is conformant or not.
        </td></tr></table></div></div><div class="div1">
<h2><a id="media-fragment-syntax" name="media-fragment-syntax" />4 Media Fragments Syntax</h2><p>
        This section describes the external representation of a media fragment specifier, and how this should be interpreted.
      </p><p>
        Guiding principles for the definition of the media fragments syntax were as follows:
      </p><ul><li>a. The MF syntax for queries and fragments should be identical</li><li>b. The MF syntax should be unambiguous</li><li>c. The MF syntax should allow any UTF-8 character in track or id names</li><li>d. The MF syntax should adhere to applicable formal standards</li><li>e. The MF syntax should adhere to de-facto usage of queries and fragments</li><li>f. The MF syntax should be as concise as possible, with no unneeded grammatical fluff</li></ul><div class="div2">
<h3><a id="general-structure" name="general-structure" />4.1 General Structure</h3><p>
          A list of name-value pairs is encoded in the query or
          fragment component of a URI. The name and value components
          are separated by an equal sign (<code>=</code>), while
          multiple name-value pairs are separated by an ampersand
          (<code>&amp;</code>).
        </p><div class="exampleInner"><a id="namevalues" name="namevalues" /><pre>
name = fragment - "&amp;" - "="
value = fragment - "&amp;"
namevalue = name [ "=" value ]
namevalues = namevalue *( "&amp;" namevalue )</pre></div><p>
          The names and values can be arbitrary Unicode strings,
          encoded in <cite><a href="#utf-8">UTF-8</a></cite> and percent-encoded as per
          <cite><a href="#rfc3986">RFC 3986</a></cite>. Here are some examples of URIs
          with name-value pairs in the fragment component, to
          demonstrate the general structure:
        </p><div class="exampleInner"><pre>
http://www.example.com/example.ogv#a=b&amp;c=d
http://www.example.com/example.ogv#t=10,20
http://www.example.com/example.ogv#track=audio&amp;t=10,20
http://www.example.com/example.ogv#id=Cap%C3%ADtulo%202</pre></div><p>
          While arbitrary name-value pairs can be encoded in this
          manner, this specification defines a fixed set of
          dimensions. The dimension keyword name is encoded in the
          name component, while dimension-specific syntax is encoded
          in the value component.
        </p><p>
	  Section <a href="#processing-name-value-components"><b>5.1.1 Processing name-value components</b></a>
	  defines in more detail how to process the name-value pair
	  syntax, arriving at a list of name-value Unicode string
	  pairs. The syntax definitions in
	  <a href="#fragment-dimensions"><b>4.2 Fragment Dimensions</b></a> apply to these Unicode
	  strings.
        </p></div><div class="div2">
<h3><a id="fragment-dimensions" name="fragment-dimensions" />4.2 Fragment Dimensions</h3><p>Media fragments support addressing the media along four dimensions:</p><dl><dt class="label">temporal</dt><dd><p>
                This dimension denotes a specific time range in the
                original media, such as "starting at second 10, continuing
                until second 20";
              </p></dd><dt class="label">spatial</dt><dd><p>
                this dimension denotes a specific range of pixels in
                the original media, such as "a rectangle with size (100,100)
                with its top-left at coordinate (10,10)";
              </p></dd><dt class="label">track</dt><dd><p>
                this dimension denotes one or more tracks in the
                original media, such as "the english audio and the video track";
              </p></dd><dt class="label">id</dt><dd><p>
                this dimension denotes a named temporal fragment within the original media, such as "chapter 2", and can be seen as a convenient way of specifying a temporal fragment.
              </p></dd></dl><p>
          All dimensions are logically independent and can be combined; the outcome is independent of the order of the dimensions. Note however that the id dimension a shortcut is for the temporal dimension; combining both dimensions need to be treated as described in section <a href="#error-uri-general"><b>6.2.1 Errors on the general URI level</b></a>.
        </p><p>
          The track dimension refers to one of a set of parallel media streams (e.g. "the english audio track for a video"), not to a (possibly self-contained) section of the source media (e.g. "Audio track 2 of a CD").
        </p><div class="div3">
<h4><a id="naming-time" name="naming-time" />4.2.1 Temporal Dimension</h4><p>
          Temporal clipping is denoted by the name <code>t</code>, and specified as an interval with a begin time and an end time (or an in-point and an out-point, in video editing terms). Either or both may be omitted, with the begin time defaulting to 0 seconds and the end time defaulting to the duration of the source media. The interval is half-open: the begin time is considered part of the interval whereas the end time is considered to be the first time point that is not part of the interval. If a single number only is given, this corresponds to the begin time except if it is preceded by a comma that would in this case indicate the end time.
          </p><p>Examples:</p><div class="exampleInner"><pre>
t=10,20   # =&gt; results in the time interval [10,20)
t=,20     # =&gt; results in the time interval [0,20)
t=10      # =&gt; results in the time interval [10,end)</pre></div><p>
          Temporal clipping can be specified either as Normal Play Time (npt) <cite><a href="#rtsp">RFC 2326</a></cite>, as SMPTE timecodes, <cite><a href="#smpte">SMPTE</a></cite>, or as real-world clock time (clock) <cite><a href="#rtsp">RFC 2326</a></cite>. Begin and end times are always specified in the same format. The format is specified by name, followed by a colon (<code>:</code>), with <code>npt:</code> being the default.
          </p><div class="exampleInner"><a id="timesegment" name="timesegment" /><pre>
timeprefix    = %x74                                      ; "t"
timeparam     = <a href="#npttimedef">npttimedef</a> / <a href="#smptetimedef">smptetimedef</a> / <a href="#clocktimedef">clocktimedef</a></pre></div><p>
          In this version of the media fragments specification there is no extensibility mechanism to add time format specifiers.
          </p><div class="div4">
<h5><a id="npt-time" name="npt-time" />4.2.1.1 Normal Play Time (NPT)</h5><p>
          Normal Play Time can either be specified as seconds, with an optional fractional part to indicate miliseconds, or as colon-separated hours, minutes and seconds (again with an optional fraction). Minutes and seconds must be specified as exactly two digits, hours and fractional seconds can be any number of digits. The hours, minutes and seconds specification for NPT is a convenience only, it does not signal frame accuracy. The specification of the "npt:" identifier is optional since NPT is the default time scheme. This specification builds on the RTSP specification of NPT <cite><a href="#rtsp">RFC 2326</a></cite>.
          </p><div class="exampleInner"><a id="npttimedef" name="npttimedef" /><pre>
npt-sec       =  1*DIGIT [ "." *DIGIT ]                     ; definitions taken
npt-hhmmss    =  npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; from <cite><a href="#rtsp">RFC 2326</a></cite>,
npt-mmss      =  npt-mm ":" npt-ss [ "." *DIGIT] 
npt-hh        =   1*DIGIT     ; any positive number
npt-mm        =   2DIGIT      ; 0-59
npt-ss        =   2DIGIT      ; 0-59

npttimedef    = [ deftimeformat ":"] ( npttime  [ "," npttime ] ) / ( "," npttime )

deftimeformat = %x6E.70.74                                ; "npt"
npttime       = npt-sec / npt-mmss / npt-hhmmss
</pre></div><p>Examples:</p><div class="exampleInner"><pre>
t=npt:10,20         # =&gt; results in the time interval [10,20)
t=npt:,121.5        # =&gt; results in the time interval [0,121.5)
t=0:02:00,121.5     # =&gt; results in the time interval [120,121.5)
t=npt:120,0:02:01.5 # =&gt; also results in the time interval [120,121.5)</pre></div></div><div class="div4">
<h5><a id="smpte-time" name="smpte-time" />4.2.1.2 SMPTE time codes</h5><p>
          SMPTE time codes are a way to address a specific frame (or field) without running the risk of rounding errors causing a different frame to be selected. The format is always colon-separated hours, minutes, seconds and frames. Frames are optional, defaulting to 00. If the source format has a further subdivison of frames (such as odd/even fields in interlaced video) these can be specified further with a number after a dot (<code>.</code>). The SMPTE format name must always be specified, because the interpretation of the fields depends on the format. The SMPTE formats supported in this version of the specification are:
          </p><ul><li><code>smpte</code>,</li><li><code>smpte-25</code>,</li><li><code>smpte-30</code> and </li><li><code>smpte-30-drop</code>.</li></ul><p>
            <code>smpte</code> is a synonym for <code>smpte-30</code>.
          </p><div class="exampleInner"><a id="smptetimedef" name="smptetimedef" /><pre>
smptetimedef  = smpteformat ":"( frametime [ "," frametime ] ) / ( "," frametime )
smpteformat   = %x73.6D.70.74.65                          ; "smpte"
               / %x73.6D.70.74.65.2D.32.35                ; "smpte-25"
               / %x73.6D.70.74.65.2D.33.30                ; "smpte-30"
               / %x73.6D.70.74.65.2D.33.30.2D.64.72.6F.70 ; "smpte-30-drop"
frametime     = 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT [ "." 2DIGIT ] ]
</pre></div><p>Examples:</p><div class="exampleInner"><pre>
t=smpte-30:0:02:00,0:02:01:15       # =&gt; results in the time interval [120,121.5)
t=smpte-25:0:02:00:00,0:02:01:12.40 # =&gt; results in the time interval [120,121.5)
                                    #    (80 or 100 subframes per frame seem typical)
</pre></div><p>
          Using SMPTE timecodes may result in frame-accurate begin and end times, but only if the timecode format used in the media fragment specifier is the same as that used in the original media item.
          </p></div><div class="div4">
<h5><a id="clock-time" name="clock-time" />4.2.1.3 Wall-clock time code</h5><p>
          Wall-clock time codes are a way to address real-world clock time that is associated typically with a live video stream. These are the same time codes that are being used by RTSP <cite><a href="#rtsp">RFC 2326</a></cite>, by SMIL <cite><a href="#smil30">SMIL</a></cite>, and by HTML5 <cite><a href="#html5">HTML 5</a></cite>. The scheme uses ISO 8601 UTC timestamps (http://www.iso.org/iso/date_and_time_format). The format separates the date from the time with a "T" character and the string ends with "Z", which includes time zone capabilities. To that effect, the ABNF grammar is referring to <cite><a href="#rfc3339">RFC 3339</a></cite>, which include the relevant part of ISO 8601 in ABNF form. The time scheme identifier is "clock".
          </p><div class="exampleInner"><a id="clocktimedef" name="clocktimedef" /><pre>
datetime      = &lt;date-time, defined in <cite><a href="#rfc3339">RFC 3339</a></cite>&gt;
clocktimedef  = clockformat ":"( clocktime [ "," clocktime ] ) / ( "," clocktime )
clockformat   = %x63.6C.6F.63.6B                          ; "clock"
clocktime     = (datetime / walltime / date)
walltime      = &lt;full-time, defined in <cite><a href="#rfc3339">RFC 3339</a></cite>&gt;
date          = &lt;full-date, defined in <cite><a href="#rfc3339">RFC 3339</a></cite>&gt;

; WARNING: if your date-time contains '+' (or any other reserved character, per <cite><a href="#rfc3986">RFC 3986</a></cite>),
; it should be percent-encoded when used in a URI.
</pre></div><p>For convenience, the definition is copied here</p><div class="exampleInner"><a id="datetime" name="datetime" /><pre>
; defined in <cite><a href="#rfc3339">RFC 3339</a></cite>
;
date-fullyear   = 4DIGIT
date-month      = 2DIGIT  ; 01-12
date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                          ; month/year
time-hour       = 2DIGIT  ; 00-23
time-minute     = 2DIGIT  ; 00-59
time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                          ; rules
time-secfrac    = "." 1*DIGIT
time-numoffset  = ("+" / "-") time-hour ":" time-minute
time-offset     = "Z" / time-numoffset

partial-time    = time-hour ":" time-minute ":" time-second
                  [time-secfrac]
full-date       = date-fullyear "-" date-month "-" date-mday
full-time       = partial-time time-offset

date-time       = full-date "T" full-time
</pre></div><p>Examples:</p><div class="exampleInner"><pre>
t=clock:2009-07-26T11:19:01Z,2009-07-26T11:20:01Z   # =&gt; results in a 1 min interval
                                                    # on 26th Jul 2009 from 11hrs, 19min, 1sec
t=clock:2009-07-26T11:19:01Z                        # =&gt; starts on 26th Jul 2009 from 11hrs, 19min, 1sec
t=clock:,2009-07-26T11:20:01Z                       # =&gt; ends on 26th Jul 2009 from 11hrs, 20min, 1sec</pre></div></div></div><div class="div3">
<h4><a id="naming-space" name="naming-space" />4.2.2 Spatial Dimension</h4><p>
              Spatial clipping selects an area of pixels from visual media streams. For this release of the media fragment specification, 
              only rectangular selections are supported. The rectangle can be specified as pixel coordinates or percentages.
            </p><p>
              Pixels coordinates are interpreted after taking into account the resource's dimensions, aspect ratio, clean aperture, resolution,
              and so forth, as defined for the format used by the resource. If an anamorphic format does not define how to apply the aspect 
              ratio to the video data's dimensions to obtain the "correct" dimensions, then the user agent must apply the ratio by increasing 
              one dimension and leaving the other unchanged.
            </p><p>
              Rectangle selection is denoted by the name <code>xywh</code>. The value is an optional format <code>pixel:</code> or <code>percent:</code> 
              (defaulting to pixel) and 4 comma-separated integers. The integers denote x, y, width and height, respectively, with x=0, y=0 being the 
              top left corner of the image. If percent is used, x and width are interpreted as a percentage of the width of the original media, and 
              y and height are interpreted as a percentage of the original height.
            </p><div class="exampleInner"><a id="spacesegment" name="spacesegment" /><pre>
xywhprefix    = %x78.79.77.68                             ; "xywh"
xywhparam     = [ xywhunit ":" ] 1*DIGIT "," 1*DIGIT "," 1*DIGIT "," 1*DIGIT
xywhunit      = %x70.69.78.65.6C                          ; "pixel"
              / %x70.65.72.63.65.6E.74                    ; "percent"
</pre></div><p>Examples:</p><div class="exampleInner"><pre>
xywh=160,120,320,240        # =&gt; results in a 320x240 box at x=160 and y=120
xywh=pixel:160,120,320,240  # =&gt; results in a 320x240 box at x=160 and y=120
xywh=percent:25,25,50,50    # =&gt; results in a 50%x50% box at x=25% and y=25%</pre></div><p>
              If the clipping region is pixel-based and the image is
              multi-resolution (like an ICO file), the fragment MUST be ignored, so
              that the url represents the entire image.
              More generally, pixel-clip an image that does not have a single well defined pixel resolution (width and height) is not recommended.
            </p></div><div class="div3">
<h4><a id="naming-track" name="naming-track" />4.2.3 Track Dimension</h4><p>
        Track selection allows the extraction of tracks (audio, video, subtitles, etc) from a media container that supports multiple tracks. Track selection is denoted by the name <code>track</code>. The value is a string. Percent-escaping can be used in the string to specify unsafe characters (including separators such as semi-colon), see the grammar below for details. Multiple track specification is allowed, but requires the specification of multiple track parameters. Interpretation of the string depends on the container format of the original media: some formats allow numbers only, some allow full names.
        </p><div class="exampleInner"><a id="tracksegment" name="tracksegment" /><pre>
trackprefix   = %x74.72.61.63.6B                          ; "track"
trackparam    = unistring
</pre></div><p>Examples:</p><div class="exampleInner"><pre>track=1                         # =&gt; results in only extracting track 1
track=video&amp;track=subtitle      # =&gt; results in extracting track 'video' and track 'subtitle'
track=Wide%20Angle%20Video      # =&gt; results in only extracting track 'Wide Angle Video'</pre></div><p>As the allowed track names are determined by the original source media, this information has to be known before construction of the media fragment. 
		There is no support for generic media type names (audio, video) across container formats: most container formats allow multiple tracks of each media type, 
		which would lead to ambiguities.</p><p>Note that there are existing discovery mechanisms for retrieving the track names of a media resource, such as the Rich Open multitrack media 
		Exposition format (ROE) <cite><a href="#roe">ROE</a></cite> or the Media Annotations API <cite><a href="#mediaAnnotations">Media Annotations</a></cite>. Further, HTML5 media <cite><a href="#HTML5Media">HTML5 Media</a></cite> has a discovery mechanism 
		for retrieving the track names of a media resource through the audioTracks, videoTracks, and textTracks IDL attributes of the HTMLMediaElement. For example, to discover all the names 
		of the available tracks of a video resource, you may want to use the following JavaScript excerpt.</p><div class="exampleInner"><pre>&lt;video id="v1" src="video" controls&gt; &lt;/video&gt;

&lt;script type="text/javascript"&gt;
  var video = document.getElementsByTagName("video")[0];
  var track_names = [];
  var idx = 0;

  for (i=0; i&lt; video.audioTracks.length; i++, idx++) {
    track_names[idx] = video.audioTracks.getLabel(i);
  }
  for (i=0; i&lt; video.videoTracks.length; i++, idx++) {
    track_names[idx] = video.audioTracks.getLabel(i);
  }
  for (i=0; i&lt; video.textTracks.length; i++, idx++) {
    track_names[idx] = video.textTracks[i].label;
  }
&lt;/script&gt;</pre></div></div><div class="div3">
<h4><a id="naming-id" name="naming-id" />4.2.4 ID Dimension</h4><p>
      ID-based selection is denoted by the name <code>id</code>, with the value being a string enclosed. Percent-escaping can be used in the string to include unsafe characters, see the grammer below for details. Interpretation of the string depends on the underlying container format: some container formats support named temporal fragments or numbered temporal fragments. As with track selection, determining which names are valid requires knowledge of the original media item.
      </p><p>An id fragment can be seen as a shortcut for a temporal fragment (i.e., a named temporal fragment). Hence, an id fragment can always be resolved to a temporal fragment.</p><div class="exampleInner"><a id="idsegment" name="idsegment" /><pre>
idprefix    = %x69.64	     ; "id"
idparam     = unistring
</pre></div><p>Examples:</p><div class="exampleInner"><pre>
id=1               # =&gt; results in only extracting the section called '1'
id=chapter-1       # =&gt; results in only extracting the section called 'chapter-1'
id=Airline%20Edit  # =&gt; results in only extracting the section called 'Airline Edit'</pre></div></div><div class="div3">
<h4><a id="common-syntax" name="common-syntax" />4.2.5 Common Syntax</h4><div class="exampleInner"><pre>
DIGIT         = &lt;DIGIT, defined in <cite><a href="#rfc5234">RFC 5234</a></cite>&gt;
pchar         = &lt;pchar, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>&gt;
unreserved    = &lt;unreserved, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>&gt;
pct-encoded   = &lt;pct-encoded, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>&gt;
fragment      = &lt;pct-encoded, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>&gt;

unichar       = &lt;any Unicode code point&gt;
unistring     = *unichar
</pre></div><p>For convenience, the following definitions are copied here. Only the definitions in the original documents are considered normative</p><div class="exampleInner"><a id="importeddefs" name="importeddefs" /><pre>
; defined in <cite><a href="#rfc5234">RFC 5234</a></cite>
ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
DIGIT         =  %x30-39 ; 0-9
HEXDIG        =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

; defined in <cite><a href="#rfc3986">RFC 3986</a></cite>
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded   = "%" HEXDIG HEXDIG
sub-delims    = "!" / "$" / "&amp;" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
fragment      = *( pchar / "/" / "?" )
</pre></div></div></div></div><div class="div1">
<h2><a id="media-fragment-processing" name="media-fragment-processing" />5 Media Fragments Processing</h2><p>
      This section defines the different exchange scenarios for the situations explained in section <a href="#fragment-query"><b>3 URI fragment and URI query</b></a>
      over the HTTP protocol.
    </p><p>
      The formal grammar defined in the section <a href="#media-fragment-syntax"><b>4 Media Fragments Syntax</b></a> describes what producers of media fragment should output.
      It is not taking into account possible percent-encoding that are valid according to <cite><a href="#rfc3986">RFC 3986</a></cite> and the grammar is not a
      specification of how a media fragment should be parsed. Therefore, section <a href="#processing-media-fragment-uri"><b>5.1 Processing Media Fragment URI</b></a> defines
      how to parse media fragment URIs.
    </p><div class="div2">
<h3><a id="processing-media-fragment-uri" name="processing-media-fragment-uri" />5.1 Processing Media Fragment URI</h3><p>
        This sections defines how to parse media fragment URIs defined in section <a href="#media-fragment-syntax"><b>4 Media Fragments Syntax</b></a>, along with notes on some of
        the caveats to be aware of.  Implementors are free to use any equivalent technique(s).
      </p><table border="1" summary="Editorial note: Raphael"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Raphael</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
          To generate a simple figure that shows this processing:
          URI parsing (percent decoding) =&gt;  name=value pairs =&gt; (rfc2047encoding) HTTP
        </td></tr></table><div class="div3">
<h4><a id="processing-name-value-components" name="processing-name-value-components" />5.1.1 Processing name-value components</h4><p>
          This section defines how to convert an octet string (from the
          query or fragment component of a URI) into a list of name-value
          Unicode string pairs.
        </p><ol class="enumar"><li><p>
            Parse the octet string according to the
            <a href="#namevalues">namevalues</a> syntax, yielding a list
            of name-value pairs, where name and value are both octet
            string. In accordance with <cite><a href="#rfc3986">RFC 3986</a></cite>, the
            name and value components must be parsed and separated
            before percent-encoded octets are decoded.
            </p></li><li><p>
              For each name-value pair:
            </p><ol class="enumla"><li><p>
                Decode percent-encoded octets in name and value as
                defined by <cite><a href="#rfc3986">RFC 3986</a></cite>. If either name or
                value are not valid percent-encoded strings, then remove
                the name-value pair from the list.
                </p></li><li><p>
                Convert name and value to Unicode strings by
                interpreting them as <cite><a href="#utf-8">UTF-8</a></cite>. If either
                name or value are not valid UTF-8 strings, then remove
                the name-value pair from the list.
                </p></li></ol></li></ol><p>
          Note that the output is well defined for any input.
        </p><p>
          Examples:
        </p><table border="1"><tr><th>Input</th><th>Output</th><th>Notes</th></tr><tr><td>"t=1"</td><td>[("t", "1")]</td><td>simple case</td></tr><tr><td>"t=1&amp;t=2"</td><td>[("t", "1"), ("t", "2")]</td><td>repeated name</td></tr><tr><td>"a=b=c"</td><td>[("a", "b=c")]</td><td>"=" in value</td></tr><tr><td>"a&amp;b=c"</td><td>[("a", ""), ("b", "c")]</td><td>missing value</td></tr><tr><td>"%74=%6ept%3A%310"</td><td>[("t", "npt:10")]</td><td>unnecssary percent-encoding</td></tr><tr><td>"id=%xy&amp;t=1"</td><td>[("t", "1")]</td><td>invalid percent-encoding</td></tr><tr><td>"id=%E4r&amp;t=1"</td><td>[("t", "1")]</td><td>invalid UTF-8</td></tr></table><p>
          While the processing defined in this section is designed to be
          largely compatible with the parsing of the URI query component
          in many HTTP server environments, there are incompatible
          differences that implementors should be aware of:
        </p><ul><li><p>
            "&amp;" is the only primary separator for name-value
            pairs, but some server-side languages also treat ";" as
            a separator.
            </p></li><li><p>
              name-value pairs with invalid percent-encoding should be
              ignored, but some server-side languages silently mask
              such errors.
            </p></li><li><p>
              The "+" character should not be treated specially, but
              some server-side languages replace it with a space (" ")
              character.
            </p></li><li><p>
              Multiple occurrences of the same name must be preserved,
              but some server-side languages only preserve the last
              occurrence.
            </p></li></ul></div><div class="div3">
<h4><a id="processing-name-value-lists" name="processing-name-value-lists" />5.1.2 Processing name-value lists</h4><p>
          This section defines how to convert a list of name-value
          Unicode string pairs into the media fragment dimensions.
        </p><p>
          Given the dimensions defined in section <a href="#fragment-dimensions"><b>4.2 Fragment Dimensions</b></a>, each has a pair of
          production rules that corresponds to the name and value component respectively:
        </p><table border="1"><tr><th>Keyword</th><th>Dimension</th></tr><tr><td>t</td><td><a href="#naming-time"><b>4.2.1 Temporal Dimension</b></a></td></tr><tr><td>xywh</td><td><a href="#naming-space"><b>4.2.2 Spatial Dimension</b></a></td></tr><tr><td>track</td><td><a href="#naming-track"><b>4.2.3 Track Dimension</b></a></td></tr><tr><td>id</td><td><a href="#naming-id"><b>4.2.4 ID Dimension</b></a></td></tr></table><ol class="enumar"><li><p>
              Initially, all dimension are undefined.
            </p></li><li><p>
              For each name-value pair:
            </p><ol class="enumla"><li><p>
                If name matches a keyword in the above table, interpret
                value as per the corresponding section.
                </p></li><li><p>
                Otherwise, the name-value pair does not represent a
                media fragment dimension. Validators should emit a
                warning. User agents must ignore the name-value pair.
                </p></li></ol></li></ol><p>
          Note: Because the name-value pairs are processed in order,
          the last valid occurence of any dimension is the one that is
          used.
        </p></div></div><div class="div2">
<h3><a id="processing-protocol-frag" name="processing-protocol-frag" />5.2 Protocol for URI fragment Resolution in HTTP</h3><p>This section defines the protocol steps in HTTP <cite><a href="#rfc2616">RFC 2616</a></cite> to resolve and deliver a media fragment specified as a URI fragment.</p><p>Various recipes are proposed and described in the <cite><a href="#mf-recipe">Protocol for Media Fragments 1.0 Resolution in HTTP</a></cite> document.</p></div><div class="div2">
<h3><a id="processing-protocol-query" name="processing-protocol-query" />5.3 Protocol for URI query Resolution in HTTP</h3><p>This section describes the protocol steps used in HTTP <cite><a href="#rfc2616">RFC 2616</a></cite> to resolve and deliver a media fragment specified as a URI query.</p><p>The recipe proposed is described in the <cite><a href="#mf-recipe">Protocol for Media Fragments 1.0 Resolution in HTTP</a></cite> document.</p></div></div><div class="div1">
<h2><a id="media-fragment-semantics" name="media-fragment-semantics" />6 Media Fragments Semantics</h2><p>In this section, we discuss how Media Fragment URIs should be interpreted by UAs. Valid and error cases are presented. In case of errors, we distinguish between errors that can be detected solely based on the Media Fragment URI and errors that can only be detected when the UA has information of the media resource (such as duration or track information).</p><div class="div2">
<h3><a id="valid-uri" name="valid-uri" />6.1 Valid Media Fragment URIs</h3><p>For each dimension, a number of valid media fragments and their semantics are presented.</p><div class="div3">
<h4><a id="valid-uri-temporal" name="valid-uri-temporal" />6.1.1 Valid temporal dimension</h4><p>To describe the different cases for temporal media fragments, we make the following definitions:</p><ul><li>s: the start point of the media, which is always zero (in NPT);</li><li>e: the end point of the media (i.e. duration) and e &gt; 0;</li><li>a: a positive integer, a &gt;= 0;</li><li>b: a positive integer, b &gt;= 0.</li></ul><p>Further, as stated in section <a href="#naming-time"><b>4.2.1 Temporal Dimension</b></a>, temporal intervals are half-open (i.e., the begin time is considered part of the interval whereas the end time is considered to be the first time point that is not part of the interval). 
			Thus, if we state below that "the media is played from x to y", this means that the frame corresponding to y will not be played.</p><p>For t=a,b with a &lt;= b</p><ul><li>t=a with a &lt; e: media is played from a to e.</li><li>t=,b with b &lt;= e: media is played from s to b.</li><li>t=,b with e &lt; b: media is played from s to e.</li><li>t=a,b with a = 0, b = e: whole media resource is played.</li><li>t=a,b with a &lt; b, a &lt; e and b &lt;= e: media is played from a to b (the normal case).</li><li>t=a,b with a &lt; b, a &lt; e and e &lt; b: media is played from a to e.</li><li>%74=10,20  resolve percent encoding to t=10,20.</li><li>t=%31%30   resolve percent encoding to t=10.</li><li>t=10%2C20  resolve percent encoding to t=10,20.</li><li>t=%6ept:10 resolve percent encoding to t=npt:10.</li><li>t=npt%3a10 resolve percent encoding to t=npt:10.</li></ul></div><div class="div3">
<h4><a id="valid-uri-spatial" name="valid-uri-spatial" />6.1.2 Valid spatial dimension</h4><p>To describe the different cases for spatial media fragments, we make the following definitions:</p><ul><li>a: the x coordinate of the spatial region (a &gt;= 0).</li><li>b: the y coordinate of the spatial region (b &gt;= 0).</li><li>c: the width the spatial region (c &gt; 0).</li><li>d: the height of the spatial region (d &gt; 0).</li><li>w: the width of the media resource (w &gt; 0).</li><li>h: the height of the media resource (h &gt; 0).</li></ul><p>The following spatial fragments are all valid:</p><ul><li>xywh=a,b,c,d with a+c &lt;= w and b+d &lt;= h: the UA displays a spatial fragment with coordinates (in pixel xywh format) a,b,c,d (the normal pixel case).</li><li>xywh=a,b,c,d with a+c &gt; w, a &lt; w, and b+d &lt; h: the UA displays a spatial fragment with coordinates (in pixel xywh format) a,b,w-a,d.</li><li>xywh=a,b,c,d with a+c &lt; w, b+d &gt; h, and b &lt; h: the UA displays a spatial fragment with coordinates (in pixel xywh format) a,b,c,h-d.</li><li>xywh=a,b,c,d with a+c &gt; w, a &lt; w, b+d &gt; h, and b &lt; h: the UA displays a spatial fragment with coordinates (in pixel xywh format) a,b,w-a,h-d.</li><li>xywh=pixel:a,b,c,d with a+c &lt;= w and b+d &lt;= h: the UA displays a spatial fragment with coordinates (in pixel xywh format) a,b,c,d (the normal pixel case).</li><li>xywh=percent:a,b,c,d with a+c &lt;= 100, b+d &lt;= 100: the UA displays a spatial fragment with coordinates (in pixel xywh format) floor(a/w*100), floor(b/h*100), ceil(c/w*100), ceil(d/h*100) (the normal percent case).</li></ul><p>The result of doing spatial clipping on a media resource that has multiple video tracks is that the spatial clipping is applied to all tracks.</p></div><div class="div3">
<h4><a id="valid-uri-track" name="valid-uri-track" />6.1.3 Valid track dimension</h4><p>The following track fragments are valid:</p><ul><li>track=4 with '4' the name of a track within the source media: the UA only plays the track with name '4'.</li><li>track=n%40m3%20%26%3D with 'n@m3 &amp;=' the name of a track within the source media: the UA only plays the track with name 'n@m3 &amp;='.</li><li>track=4&amp;track=5 with '4' and '5' both the name of tracks within the source media: the UA only plays the tracks with name '4' and '5'.</li></ul></div><div class="div3">
<h4><a id="valid-uri-id" name="valid-uri-id" />6.1.4 Valid id dimension</h4><p>The following id fragments are valid:</p><ul><li>id=song1 with 'song1' an id fragment in the source media corresponding to the temporal fragment t=a,b: the UA only plays from a to b.</li><li>id=n%40m3 with 'n@m3' an id fragment in the source media corresponding to the temporal fragment t=a,b: the UA only plays from a to b.</li></ul></div></div><div class="div2">
<h3><a id="error-uri" name="error-uri" />6.2 Errors detectable based on the URI</h3><p>Both syntactical and semantical errors are treated similar. More specifically, the UA SHOULD ignore name-value pairs causing errors detectable based on the URI.</p><p>Below, we provide more details for each of the dimensions. We look at errors in the different dimensions and their values in the subsequent sub-sections. We start with errors on the more general levels.</p><div class="div3">
<h4><a id="error-uri-general" name="error-uri-general" />6.2.1 Errors on the general URI level</h4><p>The following list provides the different kind of errors that can occur on the general URI level and how they should be treated:</p><ul><li><em>Unknown dimension:</em> only dimensions described in this specification (i.e., t, xywh, track, and id) are considered as known dimensions; all other dimensions are considered as unknown. Unknown dimensions SHOULD be ignored by the UA.</li><li><em>Multiple occurrences of the same dimension:</em> only the last valid occurrence of a dimension (e.g., t=10 in #t=2&amp;t=10) is interpreted, all previous occurrences (valid or invalid) SHOULD be ignored by the UA. The track dimension is an exception to this rule: multiple track dimensions are allowed (e.g., #track=1&amp;track=2 selects both tracks 1 and 2).</li><li><em>Combining dimensions:</em> the id dimension combined with a temporal dimension results in multiple occurrences of the temporal dimension (see previous item).</li></ul></div><div class="div3">
<h4><a id="error-uri-temporal" name="error-uri-temporal" />6.2.2 Errors on the temporal dimension</h4><p>The value cannot be parsed for the temporal dimension or the parsed value is invalid according to the specification. Invalid temporal fragments SHOULD be ignored by the UA.</p><p>Examples:</p><ul><li>t=a,b with a &gt;= b (the case of an empty temporal fragment (a=b) is also considered as an error)</li><li>t=a,</li><li>t=asdf</li><li>t=5,ekj</li><li>t=agk,9</li><li>t='0'</li><li>t=10-20</li><li>t=10:20</li><li>t=10,20,40</li><li>t%3D10 where %3D is equivalent to =; percent encoding does not resolve</li></ul></div><div class="div3">
<h4><a id="error-uri-spatial" name="error-uri-spatial" />6.2.3 Errors on the spatial dimension</h4><p>The value cannot be parsed for the spatial dimension or the parsed value is invalid according to the specification. Invalid spatial fragments SHOULD be ignored by the UA.</p><p>Examples:</p><ul><li>xywh=4,5,abc,8</li><li>xywh=4,5</li><li>xywh=foo:4,5,7,8</li><li>xywh=percent:400,5,6,8</li><li>xywh=4,5,0,3</li></ul></div><div class="div3">
<h4><a id="error-uri-track" name="error-uri-track" />6.2.4 Errors on the track dimension</h4><p>The value cannot be parsed for the track dimension. Invalid track fragments SHOULD be ignored by the UA.</p><p>Examples:</p><ul><li>track=na=me (invalid character in the name of the track)</li></ul></div><div class="div3">
<h4><a id="error-uri-id" name="error-uri-id" />6.2.5 Errors on the id dimension</h4><p>The value cannot be parsed for the id dimension. Invalid id fragments SHOULD be ignored by the UA.</p><p>Examples:</p><ul><li>id=na=me (invalid character in the name of the fragment)</li></ul></div></div><div class="div2">
<h3><a id="error-media" name="error-media" />6.3 Errors detectable based on information of the source media</h3><p>Errors that can only be detected when the UA has information of the source media are treated differently. Examples of such information are the duration of a video, the resolution of an image, track information, or the mime type of the media resource (i.e., all information that is not detectable solely based on the URI). Note that a lot of this information is located within the setup information</p><p>Below, we provide more details for each of the dimensions.</p><div class="div3">
<h4><a id="error-media-general" name="error-media-general" />6.3.1 Errors on the general level</h4><p>The following errors can occur on the general level:</p><ul><li><em>Non-existent dimension:</em> a dimension that does not exist in the source media (e.g., temporal clipping on a still image or spatial clipping on an audio file) is considered as a non-existent dimension. If the UA knows the mime type, it is able to detect non-existent dimensions and SHOULD ignore them.</li></ul></div><div class="div3">
<h4><a id="error-media-temporal" name="error-media-temporal" />6.3.2 Errors on the temporal dimension</h4><p>To describe the different cases for temporal media fragments, we use the definitions from <a href="#valid-uri-temporal"><b>6.1.1 Valid temporal dimension</b></a>. The invalidity of the following temporal fragments can only be detected by the UA if it knows the duration (for non-existent temporal fragments) and the frame rate (for smpte temporal fragments) of the source media.</p><ul><li>t=a,b with a &gt; 0, a &lt; b, a &gt;= e and b &gt; e: a non-existent temporal fragment, the UA seeks to the end of the media (i.e., e).</li><li>t=a with a &gt;= e: a non-existent temporal fragment, the UA seeks to the end of the media (i.e., e).</li><li>t=smpte-25:0:00:04 with the source media having smpte-30 labels: a mismatch between the SMPTE time code used in the URI and the SMPTE labels encoded in the requested media resource results in an invalid temporal fragment. In this case, the temporal fragment SHOULD be ignored by the UA.</li><li>t=smpte-25:0:00:04 with the source media having no smpte labels (i.e., the source media is non smpte-encoded): implementation of this case needs to be defined.</li><li>t=smpte-25:0:00:04 with the source media having non contiguous smpte timecodes: implementation of this case needs to be defined.</li></ul></div><div class="div3">
<h4><a id="error-media-spatial" name="error-media-spatial" />6.3.3 Errors on the spatial dimension</h4><p>To describe the different cases for spatial media fragments, we use the definitions from <a href="#valid-uri-spatial"><b>6.1.2 Valid spatial dimension</b></a>. The invalidity of the following spatial fragments can only be detected by the UA if it knows the resolution of the source media.</p><ul><li>xywh=a,b,c,d with a &gt;= w and/or b &gt;= h: the top-left coordinate (a,b) of the rectangular lies outside the source media and is therefore invalid. The UA SHOULD ignore this spatial fragment.</li></ul></div><div class="div3">
<h4><a id="error-media-track" name="error-media-track" />6.3.4 Errors on the track dimension</h4><p>The invalidity of track fragments can be detected if the UA knows which tracks are available in the source media. 
			If the UA detects a non-existing track in the Media Fragment URI, it SHOULD ignore the track fragment. For example, the source media consists of two tracks: 'videohigh' and 'audiomed'. 
			The track fragment track=foo points to a non-existing track fragment and should be ignored if the UA knows which tracks are available.</p></div><div class="div3">
<h4><a id="error-media-id" name="error-media-id" />6.3.5 Errors on the id dimension</h4><p>The invalidity of id fragments can be detected if the UA knows which id fragments are available in the source media. If the UA detects a non-existing id fragment in the Media Fragment URI, it SHOULD ignore the id fragment. For example, if the source media does not contain the id fragment: 'chapter1', then id=chapter1 points to a non-existing id fragment and should be ignored if the UA knows which id fragments are available.</p></div></div></div><div class="div1">
<h2><a id="implementor-notes" name="implementor-notes" />7 Notes to Implementors (non-normative)</h2><p>
      This section contains notes to implementors. Some of the information here is already
      stated formally elsewhere in the document, and the reference here is mainly a heads-up.
      Other items are really outside the scope of this specification, but the notes here
      reflect what the authors think would be good practice.
    </p><p>
      The sub-sections are not mutually exclusive. Hence, an implementer of a web browser as a media fragment client should read
      the sections <a href="#media-fragment-browser"><b>7.1 Browsers Rendering Media Fragments</b></a>, <a href="#media-fragment-display"><b>7.2 Clients Displaying Media Fragments</b></a> and <a href="#media-fragment-clients"><b>7.3 All Media Fragment Clients</b></a>.
    </p><div class="div2">
<h3><a id="media-fragment-browser" name="media-fragment-browser" />7.1 Browsers Rendering Media Fragments</h3><p>
        The pixel coordinates defined in the section <a href="#naming-space"><b>4.2.2 Spatial Dimension</b></a> are intended to be identical to
        the <a href="http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width">intrinsic width and height defined in HTML5</a>.
      </p><p>
        For spatial URI fragments, the next section describes two distinct use cases, highlighting and cropping.
        HTML rendering clients, however, are expected to implement cropping as the default rendering mechanism.
      </p></div><div class="div2">
<h3><a id="media-fragment-display" name="media-fragment-display" />7.2 Clients Displaying Media Fragments</h3><p>
        When dealing with media fragments, there is a question whether to display the media fragment in
        context or without context. In general, it is recommended to display a URI fragment in context since
        it is part of a larger resource. On the other hand, a URI query results in a new resource, so it is
        recommended to display it as a complete resource without context. The next paragraphs discuss for each
        axis the context of a media fragment and provides suggestions regarding the visualization of the
        URI fragment within its context.
      </p><p>
        For a temporal URI fragment, it is recommended to start playback at a time offset that equals
        to the start of the fragment and pause at the end of the fragment. When the "play" button is
        hit again, the resource will continue loading and play back beyond the end of the fragment.
        When seeking to specific offsets, the resource will load and play back from those seek points.
        It is also recommended to introduce a "reload" button to replay just the URI fragment. In this
        way, a URI fragment basically stands for "focusing attention". Additionally, temporal URI
        fragments could be highlighted on the transport bar.
      </p><p>
        For a spatial URI fragment, we foresee two distinct use cases: highlighting the spatial
        region in-context and cropping to the region. In the first case, the spatial region could
        be indicated by means of a bounding box or the background (i.e., all the pixels that are
        not contained within the region) could be blurred or darkened. In the second case, the region
        alone would be presented as a cropped area. How a document author specifies which use case
        is intended is outside the scope of this specification, we suggest implementors of the
        specification provide a means for this, for example through attributes or stylesheet elements.
      </p><p>
        Finally, for track URI fragments, it is recommended to play only the tracks identified by the
        track URI fragment. If no tracks are specified, the default tracks should be played.
        Different tracks could be selected using drop-down boxes or buttons; the selected tracks are
        then highlighted during playback. The way the UA retrieves information regarding the available
        tracks of a particular resource is out of scope for this specification.
      </p></div><div class="div2">
<h3><a id="media-fragment-clients" name="media-fragment-clients" />7.3 All Media Fragment Clients</h3><p>
        <em>Resolution Order:</em> Where multiple dimensions are combined in one URI fragment request, implementations are expected to first do temporal, id, and track selection on the container level, and then do spatial clipping on the codec level. 
      </p><p>
        <em>Media Fragment Grammar:</em> Note that the grammar for Media Fragment URI only specifies
        the grammar for features standardised by this specification. If a string does not parse
        correctly it does not necessarily mean the URI is wrong, it only means it is not a Media
        Fragment according to this specification. It may be correct for some extended form,
        or for a completely different fragment specification method. For this reason, error
        recovery on syntax errors in media fragment specifiers is unwise.
      </p><p>
        <em>External Clipping:</em> There is no obligatory resolution method for a situation where a media fragment URI is being used in the context of another clipping method. Formally, it is up to the context embedding the media fragment URI to decide whether the outside clipping method overrides the media fragment URI or cascades, i.e. is defined on the resulting resource. In the absence of strong reasons to do otherwise we suggest cascading. An example is a SMIL element as follows: <code>&lt;smil:video clipBegin="5" clipEnd="15" src="http://www.example.com/example.mp4#t=100,200"/&gt;</code>. This should start playback of the original media resource at second 105, and stop at 115.
      </p><p>
        <em>Content-Range-Mapping:</em> The Content-Range-Mapping header returned sometimes
        refers to a completely different range than the one that was specified as the
        <em>Range:</em> in the request. This can happen if a byte-based range is requested from
        a cache server that is not Media Fragment aware, and that server had previously cached
        the data as a result of a time range request. Technically, the information in the
        Content-Range-Mapping header is still correct, but it is completely unrelated to the
        request issued.
      </p></div><div class="div2">
<h3><a id="media-fragment-servers" name="media-fragment-servers" />7.4 Media Fragment Servers</h3><p>
        <em>Media type:</em> The media type of a resource retrieved through a URI fragment request is the same as that of the primary resource. Thus, retrieval of e.g. a single frame from a video will result in a one-frame-long video. Or, retrieval of all the audio tracks from a video resource will result in a video and not a audio resource. When using a URI query approach, media type changes are possible. E.g. a spatial fragment from a video at a certain time offset could be retrieved as a jpeg using a specific HTTP "Accept" header in the request.
      </p><p>
        <em>Synchronisation:</em> Synchronisation between different tracks of a media resource needs to be maintained when retrieving media fragments of that resource. This is true for both, URI fragment and URI query retrieval. With URI queries, when transcoding is required, a non-perceivable change in the synchronisation is acceptable.
      </p><p>
        <em>Embedded Timecodes:</em> When a media resource contains embedded time codes, these need
        to be maintained for media fragment retrieval, in particular when the URI fragment method
        is used. When URI queries are used and transcoding takes place, the embedded time codes
        should remain when they are useful and required.
      </p><p>
        <em>SMPTE Timecodes:</em> Standardisation of SMPTE timecodes in this document is
        primarily intended to allow frame-accurate references to sections of video files, they
        can be seen as a form of content-based addressing.
      </p><p>
        <em>Reasonable Clipping:</em> Temporal clipping
        needs to be as close as reasonably possible to what the media fragment
        specified, and not omit any requested data.
        "Reasonably close" means the nearest compression entity to
        the requested fragment that completely contains the requested fragment.
        This means, e.g. for temporal fragments if a request is made for
        <code>http://www.example.org/video.ogv#t=60,100</code>, but the closest
        decodable range is <code>t=58,102</code> because this is where a packet
        boundary lies for audio and video, then it will be this range that is
        returned. The UA is then capable of
        displaying only the requested subpart, and should also just do that.
        For some container formats this is a non-issue, because the container
        format allows specification of logical begin and end.
      </p><p>
        <em>Reasonable byte ranges:</em> If a single temporal range request would result
        in a disproportionally large number of byte ranges it may be better if the server
        returns a redirect to the query form of the media fragment. This situation could happen
        for example, if the underlying media file is organized in a strange way.
      </p></div><div class="div2">
<h3><a id="media-fragment-webapps" name="media-fragment-webapps" />7.5 Media Fragment Web Applications</h3><p>
        Media Fragment URIs are only defined on media resources. However, many Web developers that
        create Web pages with video or audio want to provide their users the ability
        to jump directly to media fragments - in particular to time offsets in a video - through
        providing a URI scheme for the Web page.
      </p><p>
        The way in which to realize this without requiring an extra server interaction is by
        using a URI fragment scheme on the Web page which is parsed by JavaScript and communicates
        the media fragment to the audio or video resource loader. In HTML5 it would need to change
        the @src attribute of the appropriate &lt;audio&gt; or &lt;video&gt; element with the appropriate
        URI fragment and then call the load() function to make the element (re)load the resource
        with that URI.
      </p><p>
        A URI scheme for such a Web page may involve ampersand-separated name-value
        pairs as defined in this specification, e.g. http://example.com/videopage.html#t=60,100 .
      </p><p>
        However, the Web developer has to create a scheme that works with the remainder
        of the Web page fragment addressing functionality. If, for example, the Web page makes use of
        the ID attributes of the elements on the page for scrolling down on the page, adding media
        fragment URI addressing to the Web page addressing will fail. For example, if
        http://example.com/videopage.html#first works and scrolls to an offset on that Web page,
        http://example.com/videopage.html#first&amp;t=60,100 will not do the same scrolling. The Web
        developer will then need to parse the fragment parameter and implement the scrolling
        functionality in JavaScript manually using the scrollTo() or scrollTop() functions.
      </p></div></div><div class="div1">
<h2><a id="conclusions" name="conclusions" />8 Conclusions</h2><div class="div2">
<h3><a id="qualification-resources" name="qualification-resources" />8.1 Qualification of Media Resources</h3><p>
        HTTP byte ranges can only be used to request media fragments if these media fragments can be expressed in terms of byte ranges. 
		In other words, the media fragments can be extracted in the compressed domain.
	  </p><p>
        If a media fragments of a media resource are expressable in terms of byte ranges, caching media fragments of such media resources is possible using HTTP byte ranges.
		In case media fragments of a media resource cannot be extracted in the compressed domain, transcoding operations are necessary to extract media fragments. 
		Since these media fragments are not expressible in terms of byte ranges, it is not possible to cache these media fragments using HTTP byte ranges. 
	  </p></div></div></div><div class="back"><div class="div1">
<h2><a id="references-normative" name="references-normative" />A References</h2><dl><dt class="label"><a name="rfc2119" />[RFC 2119] </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>. IETF RFC 2119, March 1997. Available at  <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>.
        </dd><dt class="label"><a name="rtsp" />[RFC 2326] </dt><dd>
          <cite>Real Time Streaming Protocol (RTSP)</cite>. IETF RFC 2326, April 1998. Available at <a href="http://www.ietf.org/rfc/rfc2326.txt">http://www.ietf.org/rfc/rfc2326.txt</a>.
        </dd><dt class="label"><a name="sdp" />[RFC 2327] </dt><dd>
          <cite>Session Description Protocol (SDP)</cite>. IETF RFC 2327, April 1998. Available at <a href="http://www.ietf.org/rfc/rfc2327.txt">http://www.ietf.org/rfc/rfc2327.txt</a>.
        </dd><dt class="label"><a name="rfc2616" />[RFC 2616] </dt><dd>
          <cite>Hypertext Transfer Protocol -- HTTP/1.1</cite>. IETF RFC 2616, June 1999. Available at <a href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a>.
        </dd><dt class="label"><a name="rfc3339" />[RFC 3339] </dt><dd>G. Klyne and C. Newman.
          <cite>Date and Time on the Internet: Timestamps</cite>. IETF RFC 3339, July 2002. Available at <a href="http://www.ietf.org/rfc/rfc3339.txt">http://www.ietf.org/rfc/rfc3339.txt</a>.
        </dd><dt class="label"><a name="ogg" />[RFC 3533] </dt><dd>
          <cite>The Ogg Encapsulation Format Version 0</cite>. IETF RFC 3533, May 2003. Available at <a href="http://www.ietf.org/rfc/rfc3533.txt">http://www.ietf.org/rfc/rfc3533.txt</a>.
        </dd><dt class="label"><a name="rfc3986" />[RFC 3986] </dt><dd>T. Berners-Lee and R. Fielding and L. Masinter. 
          <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite> Uniform Resource Identifier (URI): Generic Syntax</cite></a>. 
          IETF RFC 3986, January 2005. Available at  <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>.
        </dd><dt class="label"><a name="rfc5234" />[RFC 5234] </dt><dd>D. Crocker.
          <a href="http://tools.ietf.org/html/rfc5234"><cite>Augmented BNF for Syntax Specifications: ABNF</cite></a>. 
          IETF RFC 5234, January 2008. Available at <a href="http://tools.ietf.org/html/rfc5234">http://tools.ietf.org/html/rfc5234</a>.
        </dd><dt class="label"><a name="rfc4288" />[RFC 4288] </dt><dd>N. Freed and J. Klensin.
          <a href="http://www.ietf.org/rfc/rfc4288.txt"><cite>Media Type Specifications and Registration Procedures</cite></a>. 
          IETF RFC 4288, December 2005. Available at <a href="http://www.ietf.org/rfc/rfc4288.txt">http://www.ietf.org/rfc/rfc4288.txt</a>.
        </dd><dt class="label"><a name="rfc5147" />[RFC 5147] </dt><dd>
          E. Wilde and M. Duerst.
          <a href="http://tools.ietf.org/html/rfc5147"><cite>URI Fragment Identifiers for the text/plain Media Type</cite></a>. 
          IETF RFC 5147, April 2008. Available at  <a href="http://tools.ietf.org/html/rfc5147">http://tools.ietf.org/html/rfc5147</a>.
        </dd><dt class="label"><a name="html40" />[HTML 4.0] </dt><dd>D. Ragett and A. Le Hors and I. Jacobs.
          <a href="http://www.w3.org/TR/REC-html40/intro/intro.html#fragment-uri"><cite>HTML Fragment identifiers</cite></a>. 
          W3C Recommendation, December 1999. Available at <a href="http://www.w3.org/TR/REC-html40/intro/intro.html#fragment-uri">http://www.w3.org/TR/REC-html40/intro/intro.html#fragment-uri</a>.
        </dd><dt class="label"><a name="html5" />[HTML 5] </dt><dd>Ian Hickson.
          <a href="http://www.w3.org/TR/2009/WD-html5-20090825/"><cite>HTML5</cite></a>. 
          W3C Working Draft, 25th May 2011. Available at <a href="http://www.w3.org/TR/2011/WD-html5-20110525/">http://www.w3.org/TR/2011/WD-html5-20110525/</a>.
        </dd><dt class="label"><a name="svg1.1" />[SVG 1.1] </dt><dd>J. Ferraiolo.<a href="http://www.w3.org/TR/2011/REC-SVG11-20110816/linking.html#LinksIntoSVG"><cite>Linking 
          into SVG content: IRI fragments and SVG views</cite></a>. W3C Recommendation, August 2011. Available at 
          <a href="http://www.w3.org/TR/2011/REC-SVG11-20110816/linking.html#LinksIntoSVG">http://www.w3.org/TR/2011/REC-SVG11-20110816/linking.html#LinksIntoSVG</a>.
        </dd><dt class="label"><a name="smil30" />[SMIL] </dt><dd>Sjoerd Mullender.
          <a href="http://www.w3.org/TR/2008/REC-SMIL3-20081201/"><cite>Synchronized Multimedia Integration Language (SMIL 3.0)</cite></a>. 
          W3C Recommendation 01 December 2008. Available at <a href="http://www.w3.org/TR/2008/REC-SMIL3-20081201/">http://www.w3.org/TR/2008/REC-SMIL3-20081201/</a>.
        </dd><dt class="label"><a name="xpointer" />[xpointer] </dt><dd>P. Grosso and E. Maler and J. Marsh and N. Walsh.
          <a href="http://www.w3.org/TR/xptr-framework/"><cite>XPointer Framework</cite></a>. W3C Rec, March 2003. 
          Available at <a href="http://www.w3.org/TR/xptr-framework/">http://www.w3.org/TR/xptr-framework/</a>.
        </dd><dt class="label"><a name="mpeg-7" />[MPEG-7] </dt><dd>
          <cite>Information Technology - Multimedia Content Description Interface (MPEG-7)</cite>. 
          Standard No. ISO/IEC 15938:2001, International Organization for Standardization(ISO), 2001.
        </dd><dt class="label"><a name="temporalURI" />[temporal URI] </dt><dd>
          S. Pfeiffer and C. Parker and A. Pang.
          <a href="http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html"><cite>Specifying time intervals in URI queries and fragments of time-based Web resources</cite></a>. Internet Draft, March 2005. Available at  <a href="http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html">http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html</a>.
        </dd><dt class="label"><a name="cmml" />[CMML] </dt><dd>
          <cite>Continuous Media Markup Language (CMML), Version 2.1</cite>. 
          IETF Internet-Draft 4th March 2006 <a href="http://www.annodex.net/TR/draft-pfeiffer-cmml-03.txt">http://www.annodex.net/TR/draft-pfeiffer-cmml-03.txt</a>.
        </dd><dt class="label"><a name="roe" />[ROE] </dt><dd>
          <cite>Rich Open multitrack media Exposition (ROE)</cite>. 
          Xiph Wiki. Retrieved 13 April 2009 at <a href="http://wiki.xiph.org/index.php/ROE">http://wiki.xiph.org/index.php/ROE</a>.
        </dd><dt class="label"><a name="skeleton" />[Skeleton] </dt><dd>
          <cite>Ogg Skeleton</cite>. Xiph Wiki. 
          Retrieved 13 April 2009 at <a href="http://wiki.xiph.org/OggSkeleton">http://wiki.xiph.org/OggSkeleton</a>.
        </dd><dt class="label"><a name="mpeg21" />[MPEG-21] </dt><dd>
          <cite>Information Technology - Multimedia Framework (MPEG-21)</cite>. 
          Standard No. ISO/IEC 21000:2002, International Organization for Standardization(ISO), 2002. Available at  <a href="http://www.chiariglione.org/mpeg/working_documents/mpeg-21/fid/fid-is.zip">http://www.chiariglione.org/mpeg/working_documents/mpeg-21/fid/fid-is.zip</a>.
        </dd><dt class="label"><a name="smpte" />[SMPTE] </dt><dd>
          <cite>SMPTE RP 136 Time and Control Codes for 24, 25 or 30 Frame-Per-Second Motion-Picture Systems</cite>
        </dd><dt class="label"><a name="isoBaseMediaFF" />[ISO Base Media File Format] </dt><dd>
          <cite>Information technology - Coding of audio-visual objects - Part 12: ISO base media file format</cite>. 
          Retrieved 13 April 2009 at <a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c051533_ISO_IEC_14496-12_2008.zip">http://standards.iso.org/ittf/PubliclyAvailableStandards/c051533_ISO_IEC_14496-12_2008.zip</a>
        </dd><dt class="label"><a name="mf-req" />[Use cases and requirements for Media Fragments] </dt><dd>
          <cite>Use cases and requirements for Media Fragments</cite>. 
          W3C Working Draft 30 April 2009: <a href="http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/">http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/</a>
        </dd><dt class="label"><a name="mf-recipe" />[Protocol for Media Fragments 1.0 Resolution in HTTP] </dt><dd>
          <cite>Protocol for Media Fragments 1.0 Resolution in HTTP</cite>. 
          W3C Working Draft 29 November 2011: <a href="http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-recipes/">http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-recipes/</a>
        </dd><dt class="label"><a name="utf-8" />[UTF-8] </dt><dd>
          <cite>UTF-8, a transformation format of ISO 10646</cite>. <a href="http://tools.ietf.org/html/rfc3629">http://tools.ietf.org/html/rfc3629</a>
        </dd><dt class="label"><a name="ecma-262" />[ECMA-262 5th edition] </dt><dd>
          <cite>ECMA-262 5th edition</cite>: <a href="http://www.ecma-international.org/publications/standards/Ecma-262.htm">http://www.ecma-international.org/publications/standards/Ecma-262.htm</a>
        </dd><dt class="label"><a name="mediaAnnotations" />[Media Annotations] </dt><dd>
          <cite>API for Media Resource 1.0</cite>: <a href="http://www.w3.org/TR/mediaont-api-1.0/">http://www.w3.org/TR/mediaont-api-1.0/</a>
        </dd><dt class="label"><a name="webLinking" />[Web Linking] </dt><dd>
          <cite>Web Linking</cite>: <a href="http://tools.ietf.org/html/draft-nottingham-http-link-header-10">http://tools.ietf.org/html/draft-nottingham-http-link-header-10</a>
        </dd><dt class="label"><a name="HTML5Media" />[HTML5 Media] </dt><dd>
          <cite>HTML5 Media</cite>: <a href="http://www.w3.org/TR/html5/video.html">http://www.w3.org/TR/html5/video.html</a>
        </dd></dl></div><div class="div1">
<h2><a id="collected-syntax-uri" name="collected-syntax-uri" />B Collected ABNF Syntax for URI (Non-Normative)</h2><div class="exampleInner"><pre>
unichar       = &lt;any Unicode code point&gt;
unistring     = *unichar

; defined in <cite><a href="#rfc5234">RFC 5234</a></cite>
ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
DIGIT         =  %x30-39 ; 0-9
HEXDIG        =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

; defined in <cite><a href="#rfc3986">RFC 3986</a></cite>
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded   = "%" HEXDIG HEXDIG
sub-delims    = "!" / "$" / "&amp;" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
fragment      = *( pchar / "/" / "?" )

; defined in <cite><a href="#rtsp">RFC 2326</a></cite>
npt-sec       = 1*DIGIT [ "." *DIGIT ]                     ; definitions taken
npt-hhmmss    = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; from <cite><a href="#rtsp">RFC 2326</a></cite>
npt-mmss      = npt-mm ":" npt-ss [ "." *DIGIT] 
npt-hh        =   1*DIGIT     ; any positive number
npt-mm        =   2DIGIT      ; 0-59
npt-ss        =   2DIGIT      ; 0-59

; defined in <cite><a href="#rfc3339">RFC 3339</a></cite>
date-fullyear   = 4DIGIT
date-month      = 2DIGIT  ; 01-12
date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                          ; month/year
time-hour       = 2DIGIT  ; 00-23
time-minute     = 2DIGIT  ; 00-59
time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                          ; rules
time-secfrac    = "." 1*DIGIT
time-numoffset  = ("+" / "-") time-hour ":" time-minute
time-offset     = "Z" / time-numoffset

partial-time    = time-hour ":" time-minute ":" time-second
                  [time-secfrac]
full-date       = date-fullyear "-" date-month "-" date-mday
full-time       = partial-time time-offset

date-time       = full-date "T" full-time

; Mediafragment definitions
segment       = mediasegment / *( pchar / "/" / "?" )     ; augmented fragment
                                                          ; definition taken from
                                                          ; <cite><a href="#rfc3986">RFC 3986</a></cite>

;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Common Prefixes ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;

deftimeformat    = %x6E.70.74                                      ; "npt"
pfxdeftimeformat = %x74.3A.6E.70.74                                ; "t:npt"
smpteformat      = %x73.6D.70.74.65                                ; "smpte"
                  / %x73.6D.70.74.65.2D.32.35                      ; "smpte-25"
                  / %x73.6D.70.74.65.2D.33.30                      ; "smpte-30"
                  / %x73.6D.70.74.65.2D.33.30.2D.64.72.6F.70       ; "smpte-30-drop"
pfxsmpteformat   = %x74.3A.73.6D.70.74.65                          ; "t:smpte"
                  / %x74.3A.73.6D.70.74.65.2D.32.35                ; "t:smpte-25"
                  / %x74.3A.73.6D.70.74.65.2D.33.30                ; "t:smpte-30"
                  / %x74.3A.73.6D.70.74.65.2D.33.30.2D.64.72.6F.70 ; "t:smpte-30-drop"
clockformat      = %x63.6C.6F.63.6B                                ; "clock"
pfxclockformat   = %x74.3A.63.6C.6F.63.6B                          ; "clock"

;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Media Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
mediasegment      = ( <a href="#timesegment">timesegment</a> / <a href="#spacesegment">spacesegment</a> / <a href="#tracksegment">tracksegment</a> / <a href="#idsegment">idsegment</a> )
               *( "&amp;" ( <a href="#timesegment">timesegment</a> / <a href="#spacesegment">spacesegment</a> / <a href="#tracksegment">tracksegment</a>  / <a href="#idsegment">idsegment</a> )

timesegment      = timeprefix "=" timeparam
timeprefix       = %x74                                      ; "t"
timeparam        = <a href="#npttimedef">npttimedef</a> / <a href="#smptetimedef">smptetimedef</a> / <a href="#clocktimedef">clocktimedef</a>
npttimedef       = [ deftimeformat ":"] ( npttime  [ "," npttime ] ) / ( "," npttime )

npttime       = npt-sec / npt-mmss / npt-hhmmss

smptetimedef  = smpteformat ":"( frametime [ "," frametime ] ) / ( "," frametime )
frametime     = 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT [ "." 2DIGIT ] ]

clocktimedef  = clockformat ":"( clocktime [ "," clocktime ] ) / ( "," clocktime )
clocktime     = (datetime / walltime / date)
datetime      = date-time                                 ; inclusion of <cite><a href="#rfc3339">RFC 3339</a></cite>

spacesegment  = xywhprefix   "=" xywhparam
xywhprefix    = %x78.79.77.68                             ; "xywh"
xywhparam     = [ xywhunit ":" ] 1*DIGIT "," 1*DIGIT "," 1*DIGIT "," 1*DIGIT
xywhunit      = %x70.69.78.65.6C                          ; "pixel"
              / %x70.65.72.63.65.6E.74                    ; "percent"

tracksegment  = trackprefix "=" trackparam
trackprefix   = %x74.72.61.63.6B                          ; "track"
trackparam    = unistring

idsegment   = idprefix "=" idparam
idprefix    = %x69.64					                  ; "id"
idparam     = unistring
      </pre></div></div><div class="div1">
<h2><a id="collected-syntax-http" name="collected-syntax-http" />C Collected ABNF Syntax for HTTP Headers (Non-Normative)</h2><div class="exampleInner"><pre>
; defined in <cite><a href="#rfc2616">RFC 2616</a></cite>
CHAR                   = [any US-ASCII character (octets 0 - 127)]
token                  = 1*[any CHAR except CTLs or separators]`
first-byte-pos         = 1*DIGIT
last-byte-pos          = 1*DIGIT
bytes-unit             = "bytes"
range-unit             = bytes-unit | other-range-unit
byte-range-resp-spec   = (first-byte-pos "-" last-byte-pos)
Range                  = "Range" ":" ranges-specifier
Accept-Ranges          = "Accept-Ranges" ":" acceptable-ranges

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; HTTP Request Headers ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
ranges-specifier       = byte-ranges-specifier | fragment-specifier
;
; note that ranges-specifier is extended from <cite><a href="#rfc2616">RFC 2616</a></cite>
; to cover alternate fragment range specifiers
;
fragment-specifier     = "include-setup" | fragment-range *( "," fragment-range )
                                                           [ ";" "include-setup" ]
fragment-range         = time-ranges-specifier | id-ranges-specifier
;
; note that this doesn't capture the restriction to one fragment dimension occurring
; maximally once only in the fragment-specifier definition.
;
time-ranges-specifier  = timeprefix ":" time-ranges-options
time-ranges-options    = npttimeoption / smptetimeoption / clocktimeoption
npttimeoption          = deftimeformat "=" npt-sec   "-" [ npt-sec ]
smptetimeoption        = smpteformat   "=" frametime "-" [ frametime ]
clocktimeoption        = clockformat   "=" datetime  "-" [ datetime ]

id-ranges-specifier = idprefix "=" idparam

;;
Accept-Range-Redirect  = "Accept-Range-Redirect" ":" bytes-unit
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; HTTP Response Headers ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
Content-Range-Mapping      = "Content-Range-Mapping" ":" '{'
                             ( content-range-mapping-spec [ ";" def-include-setup ] ) / def-include-setup
                             '}' '=' '{'
                             byte-content-range-mapping-spec '}'

def-include-setup          = %x69.6E.63.6C.75.64.65.2D.73.65.74.75.70  ; "include-setup"

byte-range-mapping-spec    = bytes-unit SP
                             byte-range-resp-spec *( "," byte-range-resp-spec ) "/"
                             ( instance-length / "*" )

content-range-mapping-spec = time-mapping-spec | id-mapping-spec
time-mapping-spec          = timeprefix ":" time-mapping-options
time-mapping-options       = npt-mapping-option / smpte-mapping-option / clock-mapping-option
npt-mapping-option         = deftimeformat SP npt-sec   "-" npt-sec   "/"
                                          [ npt-sec ]   "-" [ npt-sec ]
smpte-mapping-option       = smpteformat   SP frametime "-" frametime "/"
                                          [ frametime ] "-" [ frametime ]
clock-mapping-option       = clockformat   SP datetime  "-" datetime  "/"
                                          [ datetime ]  "-" [ datetime ]

id-mapping-spec          = idprefix SP idparam

;;
acceptable-ranges          = 1#range-unit *( "," 1#range-unit )| "none"
;
; note this does not represent the restriction that range-units can only appear once at most;
; this has also been adapted from <cite><a href="#rfc2616">RFC 2616</a></cite>
; to allow multiple range units.
;
other-range-unit           = token | timeprefix | idprefix

;;
Range-Redirect             = "Range-Redirect" ":" byte-range-resp-spec *( "," byte-range-resp-spec )
      </pre></div></div><div class="div1">
<h2><a id="acknowledgments" name="acknowledgments" />D Acknowledgements (Non-Normative)</h2><p>
    This document is the work of the <a href="http://www.w3.org/2008/WebVideo/Fragments/">W3C Media Fragments Working Group</a>. Members of the Working Group are
    (at the time of writing, and in alphabetical order):
    Eric Carlson (Apple, Inc.), 
Chris Double (Mozilla Foundation),
Michael Hausenblas (DERI Galway at the National University of Ireland, Galway, Ireland),
Philip Jägenstedt (Opera Software),
Jack Jansen (CWI),
Yves Lafon (W3C),
Erik Mannens (IBBT),
Thierry Michel (W3C/ERCIM),
Guillaume (Jean-Louis) Olivrin (Meraka Institute),
Soohong Daniel Park (Samsung Electronics Co., Ltd.),
Conrad Parker (W3C Invited Experts),
Silvia Pfeiffer (W3C Invited Experts),
Nobuhisa Shiraishi (NEC Corporation),
David Singer (Apple, Inc.),
Thomas Steiner (Google, Inc.),
Raphaël Troncy (EURECOM),
Davy Van Deursen (IBBT),

  </p><p>
    The people who have contributed to <a href="http://lists.w3.org/Archives/Public/public-media-fragment/">
      discussions on public-media-fragment@w3.org
    </a> are also gratefully acknowledged. In particular:
    Olivier Aubert, Werner Bailer, Pierre-Antoine Champin, Cyril Concolato, Franck Denoual, Martin J. Dürst,
    Jean Pierre Evain, Ken Harrenstien, Kilroy Hughes, Ryo Kawaguchi, Wim Van Lancker,
    Véronique Malaisé, Henrik Nordstrom, Yannick Prié, Yves Raimond, Julian Reschke, Geoffrey Sneddon, 
    Felix Sasaki, Jakub Sendor, Philip Taylor, Christian Timmerer, Jorrit Vermeiren, Jeroen Wijering and Munjo Yu.
  </p></div></div></body></html>