idnits 2.17.1 draft-pfeiffer-temporal-fragments-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 731. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 738. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 744. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 19, 2005) is 6978 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-03) exists of draft-pfeiffer-cmml-02 -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2616 (ref. '4') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2326 (ref. '5') (Obsoleted by RFC 7826) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Pfeiffer 2 Internet-Draft C. Parker 3 Expires: September 20, 2005 A. Pang 4 CSIRO 5 March 19, 2005 7 Specifying time intervals in URI queries and fragments of time-based 8 Web resources 9 draft-pfeiffer-temporal-fragments-03 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 20, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document specifies a syntax for addressing time intervals within 45 time-based Web resources through URI queries and fragments. This 46 scheme is particularly used for Annodex [1] and CMML [2] Web 47 resources, though it could be picked up by any other time-based Web 48 resource format. Temporal addressing enables, e.g., direct access to 49 a clip inside a video stored on a Web Server, or direct jumps to a 50 specific event within a piece of music. The syntax is not restricted 51 to audio or video Web resources though, but covers all kinds of Web 52 resources that contain time-continuous information. 54 When a server (e.g. a Web Server) supports the URI query syntax, it 55 is able to extract the given time subsections from the base resource 56 and serve them as another resource of the same type. Specifying a 57 time point or interval through a URI fragment in contrast does not 58 deliver a subpart of the resource - instead it is up to the user 59 agent and the resource type as to what action is invoked. Examples 60 are a fast forward to a time point, or a zoom into a time interval. 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [3]. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Incorporating temporal addressing into the Generic URI 70 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Temporal addressing through URI queries . . . . . . . . . . . 6 72 4. Temporal addressing through URI fragments . . . . . . . . . . 8 73 5. Time schemes . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 6. Implementation with HTTP . . . . . . . . . . . . . . . . . . . 12 75 6.1 Identifying enabled HTTP servers . . . . . . . . . . . . . 12 76 6.2 Caching URIs with temporal queries in HTTP proxy 77 servers . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 6.3 Overview of added HTTP message headers . . . . . . . . . . 15 79 6.3.1 X-Accept-Range-Redirect . . . . . . . . . . . . . . . 15 80 6.3.2 X-Range-Redirect . . . . . . . . . . . . . . . . . . . 15 81 6.3.3 X-Accept-TimeURI . . . . . . . . . . . . . . . . . . . 15 82 7. Implementation with RTP/RTSP . . . . . . . . . . . . . . . . . 16 83 8. Security considerations . . . . . . . . . . . . . . . . . . . 17 84 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 87 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 88 Intellectual Property and Copyright Statements . . . . . . . . 22 90 1. Introduction 92 Many resources on the World Wide Web represent information that 93 relate to a timeline of events. Time-sampled recordings of sound, 94 temporally interleaved audio-visual streams, or data files containing 95 time series data are examples. This document describes a syntax for 96 addressing temporal offsets and time intervals in such resources. 97 The aim is to make it simple to incorporate infrastructure into the 98 Internet which supports the addressing and retrieval of temporal 99 subparts of time-based Web resources, as well as the automated 100 processing of such subparts for reuse. 102 The temporal URI interval specifications are to be used on resources 103 that represent a specific timeline. An example of such resources are 104 most resources of MIME types "audio/*" and "video/*". Files 105 containing commands for creating time-continuous experiences (such as 106 SMIL files for authoring interactive multimedia, or VRML files for 107 authoring 3D worlds) cannot be addressed in this manner. However, if 108 one particular user interaction (i.e. one experience) is recorded, 109 the recording contains data that relates to a single timeline and can 110 be addressed with the manner described in this specification. 112 The temporal URI queries and fragments specified in this document 113 have been implemented and demonstrated to work with Annodex [1] and 114 CMML [2] format Web resources over HTTP [4]. A possible 115 implementation over RTP/RTSP [5] for Internet streaming is being 116 specified. Usage with other protocols is possible, but has not been 117 explored yet. 119 2. Incorporating temporal addressing into the Generic URI Scheme 121 The Generic URI Scheme [6] defines two manners in which subparts of 122 Web resources can be addressed: queries and fragments. Queries are 123 given through extending the Web resource's address by a string that 124 is separated through the special character "?". Fragments are given 125 through extending the Web resource's address by a string that is 126 separated through the special character "#". 128 RFC 3986 [6] specifies that URI queries identify a resource and thus 129 a Web server MUST process the query returning a fully defined 130 resource. There is no generically defined structure to URI queries. 131 However, the format of a CGI query string where name-value pairs are 132 separated by the special character "&" is a commonly used format. 133 The Common Gateway Interface, or CGI, is a convention for external 134 gateway programs to interface with information servers such as HTTP 135 servers (see http://hoohoo.ncsa.uiuc.edu/cgi/). When defining a 136 common manner in which temporal subparts of a Web resource can be 137 addressed, it is important to be compatible with this common CGI 138 format. 140 RFC 3986 [6] also specifies that URI fragments identify a secondary 141 resource by reference to a primary resource and that fragments are 142 interpreted client side, i.e. the Web infrastructure consisting of 143 Web servers and Web proxies will generally ignore the "#" extension 144 of URIs. This basically implies that a fragment provides a 145 particular view on a resource and the view is defined through the 146 type of resource and through the client side application. 148 Both, URI query and URI fragment identifiers have traditionally been 149 defined for specific media types or even specific services. This is 150 especially true for URI queries where the query string may consist of 151 name-value pairs that contain the particular fields and field entries 152 of a particular form that resides on a particular server and is 153 processed by a particular server extension. For the temporal 154 addressing that is proposed in this document, it is important that 155 every Web server that interpretes the query parameter reacts 156 uniformly to it. The particular resources which are covered in this 157 manner are the Annodex [1] and CMML [2] media types. This scheme can 158 be adopted for other media types, by including it in the media type 159 registration for that format. 161 3. Temporal addressing through URI queries 163 URI query strings are specified after the special character "?". A 164 temporal query parameter defines one or more intervals of time. Time 165 is given with respect to specific time schemes. The default time 166 scheme is "npt" (normal play time), in which a time point is 167 specified in seconds through a floating point number with an 168 arbitrary temporal resolution. The available time schemes and their 169 specifications are described further down in this document. 171 The BNF for a temporal URI query parameter is: 173 time-parameter = "t" "=" [ timescheme ":" ] time-intervalspec 175 time-intervalspec = time-interval ["," time-intervalspec] 177 time-interval = timespec ["/" timespec] 179 timescheme = *( unreserved / pct-encoded / sub-delims / 180 "/" / "?" / "#" / "[" / "]" / "@" ) 182 timespec = *( unreserved / pct-encoded / "?" / "#" / 183 "[" / "]" / "@" / "!" / "$" / "&" / "'" / 184 "(" / ")" / "*" / "+" / ";" / "=" ) 186 All time intervals actually specify start and end times. If no end 187 timespec is given, it defaults to "infinity", which for a file means 188 the end of the file or for a stream the end of the stream. 189 Overlapping time intervals MUST be interpreted by merging the 190 intervals into one. 192 It is not valid to give several temporal URI query parameters in one 193 URI query. They all need to be wrapped into a single specification. 195 A URI with a query for several intervals may be split by the user 196 agent into several queries for a single interval each and then sent 197 to the server in consecutive requests, which in the case of HTTP/1.1 198 would e.g. be pipelined. This is of particular interest to user 199 clients that can not handle resources that consist of temporally 200 non-consecutive data, e.g. chained Annodex bitstreams. 202 Examples for URIs containing temporal queries are: 203 o http://example.com/video.anx?t=npt:15.2 --- video.anx is 204 transferred from 15.2 seconds into video.anx to the end of the 205 file/stream. 206 o http://example.com/video.anx?t=15.2/18.7 --- video .anx is 207 transferred from 15.2 seconds into video.anx to 18.7 seconds; the 208 default time scheme "npt" is used. 210 o http://example.com/video.anx?t=npt:15.2/18.7,23 --- video.anx is 211 transferred from 15.2s to 18.7s and from 23s to the end of the 212 file/stream. 213 o http://example.com/video.anx?t=npt:15.2/18.7,17.4/30.1 -- 214 video.anx is transferred from 15.2 seconds into video.anx to 30.1 215 seconds. 216 o http://example.com/video.anx?t=npt:15.2/18.7&t=23 --- invalid 217 query parameters - MUST create an error message. 219 4. Temporal addressing through URI fragments 221 URI fragment specifiers are given after the special character 222 crosshatch ("#"). A temporal URI fragment defines a specific 223 temporal view onto a Web resource consisting of one or more intervals 224 of time. Again, time is given with respect to specific time schemes 225 as defined below, "npt" being the default. 227 The BNF for a temporal URI fragment identifier is (reusing the 228 time-intervalspec of the URI query section above): 230 temporal-fragment = time-parameter 232 As with temporal URI query parameters, all temporal intervals are 233 specified through start and end times, the default end time being 234 infinity, which may map to the end of a file or stream. Also, 235 several temporal URI fragment identifiers are not allowed. 237 What a user agent does with a temporal URI fragment is up to itself. 238 As a result of the request being sent to the server, the user agent 239 receives the complete resource. If the user agent is a Web browser 240 and the resource is a video, the user agent MAY play back only the 241 specified time section(s). If the user agent is a sound editor and 242 the resource a sound file, the user agent MAY select the disjoint 243 time intervals in the sound file as a first step to applying some 244 filter to them. 246 Examples for URIs with temporal fragment specifications are: 247 o http://example.com/video.anx#t=npt:15.2 --- specifies a view on 248 the section between 15.2 seconds into video.anx and the end of the 249 file/stream. 250 o http://example.com/video.anx#t=15.2/18.7 --- specifies a view on 251 the section between 15.2s and 18.7s of video.anx, with a default 252 time scheme of "npt". 253 o http://example.com/video.anx#t=npt:15.2/18.7,23 --- specifies a 254 view on the section between 15.2s and 18.7s, as well as 23s to the 255 end of the file/stream. 256 o http://example.com/video.anx#t=npt:15.2/18.7,17.4/30.1 -- 257 specifies a view on the section between 15.2s and 30.1s of 258 video.anx. 260 5. Time schemes 262 A time scheme is a short identifier for a type of time specification. 263 The following general time schemes are specified in this document. 264 Further time schemes are expected to emerge and should probably be 265 registered through IANA. 266 o "npt" Normal Play Time; base of seconds as used in the RTSP 267 standard [5] 268 o "smpte" Society of Motion Picture and Television Engineers time 269 codes as specified in the SMPTE time and control code standard [7] 270 o "utc" Universal Time Code giving wall-clock time as specified in 271 the ISO 8601 standard [8]. 273 Specification as BNF: 275 timescheme = npt-timescheme | smpte-timescheme | utc-timescheme | *unreserved 276 timespec = npt-timespec | smpte-timespec | utc-timespec | *uric 278 These time schemes are specified as follows: 279 NPT time has a second or subsecond resolution. It is specified as 280 H:M:S.h (npt-hhmmss) or S.h (npt-sec), where H=hours, M=minutes, 281 S=second and h=fractions of a second. Negative values are not 282 allowed. 283 Specification as BNF: 285 npt-timescheme = "npt" 286 npt-timespec = npt-sec | npt-hhmmss 287 npt-sec = 1*DIGIT [ "." *DIGIT ] 288 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] 289 npt-hh = 1*DIGIT ; any positive number 290 npt-mm = 1*2DIGIT ; 0-59 291 npt-ss = 1*2DIGIT ; 0-59 293 SMPTE time codes [7] are optimized for frame level accuracy. 294 SMPTE is specified as HH:MM:SS:FF, where HH=hours, MM=minutes, 295 SS=second, FF=frames. The drop-frame algorithms for calculating 296 the exact times can be found in the references SMPTE standard. 297 Negative values are not allowed. 298 "smpte-24=" SMPTE time with a 24 fps basis 299 "smpte-24-drop=" SMPTE time with a 24/1.001 fps basis 300 "smpte-25=" SMPTE time with a 25 fps basis 301 "smpte-30=" SMPTE time with a 30 fps basis 302 "smpte-30-drop=" SMPTE time with a 30/1.001 fps basis 303 "smpte-50=" SMPTE time with a 50 fps basis 304 "smpte-60=" SMPTE time with a 60 fps basis 305 "smpte-60-drop=" SMPTE time with a 60/1.001 fps basis 306 Specification as BNF: 308 smpte-timescheme = "smpte-24" | "smpte-24-drop" | "smpte-25" | 309 "smpte-30" | "smpte-30-drop" | "smpte-50" | 310 "smpte-60" | "smpte-60-drop" 311 smpte-timespec = smpte-hh ":" smpte-mm ":" smpte-ss [ ":" smpte-ff ] 312 smpte-hh = 1*2DIGIT 313 smpte-mm = 1*2DIGIT 314 smpte-ss = 1*2DIGIT 315 smpte-ff = 1*2DIGIT 317 UTC time has a second or subsecond resolution. It is given as 318 YYYYMMDDTHHmmss.hhZ, where Y=year, M=month, D=day, H=hour, 319 m=minute, s=second, h=subseconds (one-hundredth of a second). 320 Specification as BNF: 322 utc-timescheme = "clock" 323 utc-timespec = utc-date "T" utc-hhmmss "Z" 324 utc-date = 8DIGIT ; < YYYYMMDD > 325 utc-hhmmss = 6DIGIT [ "." 1*DIGIT ] ; < HHMMSS.fraction > 327 Examples for time-interval URI specifications with different time 328 schemes are: 330 http://example.com/audio.anx?t=smpte-25:10:07:33:06/10:07:55:00 331 (for a temporal interval between 36453.25s - 36475s) 332 http://example.com/audio.anx#t=npt:10:07:33.25 333 (for a temporal interval between 36453.25s and the end of the file/stream) 334 http://example.com/audio.anx?t=clock:20021107T173045.25Z 335 (for Thu Jul 11 05:30:45 UTC 2002 and a quarter seconds) 337 The semantic interpretation of time specifications given with any of 338 the schemes depends on the resource. With every resource there are 339 two associated basetimes: a UTC basetime which may e.g. specify the 340 creation time of the resource, and a playback basetime used for 341 display in a user agent while presenting the resource. 343 The playback basetime of a resource defaults to 0 seconds unless the 344 resource has a different basetime associated with it. A contrasting 345 example: in professional video production, the first frame of video 346 of a program normally refers to a SMPTE basetime of 01:00:00:00, not 347 00:00:00:00. This practice arose from the requirements of program 348 production and analog videotape recording technology, and it has 349 subsequently become a uniform, almost ironclad practice worldwide. 350 Associating such a practice to a digital video resource requires a 351 way to store that basetime with the resource and interpreting it 352 correctly when addressing via temporal URIs. Annodex provides such a 353 mapping through a field in its headers that stores the playback 354 basetime. CMML has a tag in its stream element for it. 356 Examples: If a resource has an associated basetime of 3600 seconds, 357 and the given temporal fragment offset is 4000 sec, only a seek of 358 400 sec into the resource is required. If the basetime is given as 359 clock time 20001010T142211.23Z and the temporal offset specified is 360 20001010T145511.23Z, an offset of 33 minutes into the resource is 361 requested. 363 The UTC basetime of a resource defaults to being non-specified. 364 Associating such a UTC basetime with a resource requires a way to 365 store that basetime with the resource. For example, for a resource 366 that is a file on a server, it may be chosen to be the time of 367 storage of that resource. Annodex also provides a field in its 368 headers to store the UTC basetime, and CMML has a tag for it. 370 The semantic interpretation of temporal intervals is as IN and OUT 371 times like the conventions in use for editing media content: 372 [time_from;time_to[ . This means that the interval stops just at the 373 end time. The reasoning is that it just works when concatenating two 374 intervals that follow directly upon each other. 376 6. Implementation with HTTP 378 6.1 Identifying enabled HTTP servers 380 Time-continuous resources often come with high bandwidth 381 requirements, so a HTTP [4] server SHOULD serve out only the queried 382 time interval of a base resource to avoid unnecessary network load. 383 For example, a 1 hour Digital Video (DV format) requires about 25 GB 384 (MPEG-2 reduces that to about 3 GB). This also significantly reduces 385 the delay for the user agent for receiving relevant data. 387 A user agent that sends a URI that includes a temporal query to a 388 HTTP server expects the server to return just the subparts of the 389 base resource that it is querying for. It expects to be notified by 390 the server if the server cannot resolve the query such that it may 391 take appropriate action. 393 The HTTP protocol specifies that a server MUST return a "404 Not 394 Found" error message on URI requests which cannot be resolved. A URI 395 with a query component is a different URI than the same URI without a 396 query component, so if it cannot be resolved, a "404 Not Found" is 397 expected . However, most current implementations of HTTP servers 398 regard the query component as a relative to the same URI without the 399 query component and therefore support a somewhat non-conformant 400 resolution of such a URI request: if they cannot resolve the query 401 component, they will try to resolve the same URI without the query 402 component. This makes it difficult for a user agent to find out 403 whether a temporal query component was actually resolved or not. 405 To address this issue, a HTTP server that is capable of resolving 406 temporal URI requests on a specified resource MUST return an 407 additional accept header field that indicates that it can handle the 408 temporal URI addressing and for which time schemes it can handle it. 409 The header field is called "X-Accept-TimeURI" and the value is a list 410 of time schemes, e.g. "X-Accept-TimeURI: npt, smpte-24, smpte-25, 411 smpte-30, smpte-50, smpte-60". This request header is included for 412 all URI requests to resources on which the HTTP server can resolve a 413 temporal URI request. A user agent SHOULD check the 414 "X-Accept-TimeURI" field to decide whether its temporal URI request 415 has been honoured and thus the results can be displayed accurately. 417 6.2 Caching URIs with temporal queries in HTTP proxy servers 419 Caching HTTP/1.1 [4] proxy servers allow storage of requested Web 420 resources closer to the requesting user agent and reuse by other 421 close-by user agents, reducing bandwidth usage and access time. The 422 HTTP/1.1 caching mechanisms also works for time-based Web resources. 423 However, complete time-based Web resources, such as Annodex 424 resources, are often memory-intensive. User agents may more 425 frequently request URIs with temporal queries than the full resource. 426 Therefore, a larger impact on bandwidth usage is expected from 427 caching the temporal URI queries as they are independent resources. 429 The defined caching mechanism in HTTP/1.1 for subranges of a resource 430 is based on storage of byte subranges. For time-based Web resources 431 for which it is possible to map a temporal URI query to a set of byte 432 subranges on the base resource, URIs with time-queries can also be 433 stored in a proxy's cache. To this end, the HTTP server MUST ensure 434 that the core data that relates to the temporal subpart is bitwise 435 identical to the original data - otherwise a byte range cannot be 436 defined. This is achieved for Annodex subresources by changing only 437 the control section but not the data section on remuxing, as 438 described in the Annodex specifiation [1]. 440 Mapping of temporal URI queries to byte ranges can only happen on the 441 origin server, being the only component that holds the base resource 442 and can thus understand the relationship between time and bytes. The 443 caching mechanism in HTTP/1.1 for byte ranges is based on the user 444 agent requesting a URI with a "Range" request header that specifies 445 the byte ranges. Thus, an additional agent-driven negotiation for 446 delivery of the byte range mapping prior to the "Range" request is 447 introduced to enable support of temporal URI queries. 449 A request header of "X-Accept-Range-Redirect" is required to indicate 450 to the server that a mapping of the temporal URI query parameters to 451 a byte range is requested rather than delivery of the query-part of 452 the resource straight away. As this field initiates the server to 453 provide a different response than if this field was not available, 454 the server MUST include into its response a message header of "Vary: 455 X-Accept-Range-Redirect". It MAY also indicate with "Accept-Ranges: 456 bytes" that it is able to accept byte range requests. And it MAY 457 indicate with "X-Accept-TimeURI" that it has processed the temporal 458 URI query request. 460 The server will return a list of the byte ranges that the user agent 461 should ask for in another additional response header field: 462 "X-Range-Redirect". It will also need to redirect the user agent to 463 another resource, namely the base resource, which it provides in the 464 "Location" header field. Data that is specific to the URI request 465 with the given time-query MUST then be returned to the user agent in 466 the message body, such as for example an adapted control section of 467 an Annodex file. The response is a "200 OK" as the request was 468 satisfied with this response. 470 After this, the user agent has all the information it requires to 471 post another GET request, this time for the base resource only and 472 including a "Range" request header field. 474 In its response, the server includes the requested one or several 475 byte ranges. If several byte ranges are required, the response will 476 be a multipart message as defined in the HTTP/1.1 specification [4]. 477 The response message headers include the "Accept-Ranges: bytes" 478 header, and the "Vary: Range" header, and provides the byte range(s) 479 in the "Content-Range" header. 481 This is an example HTTP message exchange: 482 1. User Agent HTTP request: 484 GET http://example.com/video.anx?t=npt:15.2 HTTP/1.1 485 Accept: application/x-annodex 486 X-Accept-Range-Redirect: bytes 488 2. Server HTTP response: 490 HTTP/1.1 200 OK 491 Date: Fri Feb 11 14:47:12 EST 2005 492 Server: Apache/2.0(Unix) 493 Content-Type: application/x-annodex 494 X-Range-Redirect: bytes=777- 495 Vary: X-Accept-Range-Redirect 496 Accept-Ranges: bytes 497 Location: http://example.com/video.anx 498 X-Accept-TimeURI: npt, smpte-25 500 Message body: control section of video.anx?t=npt:15.2 502 3. User Agent HTTP request: 504 GET http://example.com/video.anx HTTP/1.1 505 Accept: application/x-annodex 506 Range: bytes=777- 508 4. Server HTTP response: 510 HTTP/1.1 200 OK 511 Date: Fri Feb 11 14:49:08 EST 2005 512 Server: Apache/2.0(Unix) 513 Content-Type: application/x-annodex 514 Content-Range: bytes 777- 515 Vary: Range 516 Accept-Ranges: bytes 517 X-Accept-TimeURI: npt, smpte-25 519 Message body: video.anx from byte position 777 onwards 521 6.3 Overview of added HTTP message headers 523 6.3.1 X-Accept-Range-Redirect 525 The X-Accept-Range-Redirect request header field prompts the server 526 to reply with a byte range specification that maps the queried time 527 ranges of a URI. 529 X-Accept-Range-Redirect = "X-Accept-Range-Redirect" ":" "bytes" 531 6.3.2 X-Range-Redirect 533 The X-Range-Redirect response header field provides a list of byte 534 ranges to which the server redirects a user agent for finding the 535 rest of the data that was requested. 537 X-Range-Redirect = "X-Range-Redirect" ":" ranges-specifier 539 An example of this field is: 541 X-Range-Redirect: bytes=500-600,1000- 543 6.3.3 X-Accept-TimeURI 545 The X-Accept-TimeURI response header field returns for a timed URI 546 query what time schemes it can resolve and thus implicitly also 547 whether it has resolved it. 549 X-Accept-TimeURI = "X-Accept-TimeURI" ":" 1#timescheme 550 ) 552 An example of this field is: 554 X-Accept-TimeURI: npt, smpte-24, smpte-25, smpte-30-drop, smpte-30 556 7. Implementation with RTP/RTSP 558 Initial discussions within the AV Transport Working Goup have started 559 about how to use temporal URI addressing over RTP/RTSP. It doesn't 560 seem to make sense to distinguish between fragments and queries as in 561 the streaming scenario everything is focused on being performed on 562 the server. Therefore the idea is not to bother with query 563 specifications and only focus on fragment specifications. 565 When interpreting temporal fragment offsets in RTP/RTSP, the user 566 agent transforms it into a Range specification in the PLAY request 567 header field. Multiple time ranges are easily queued by several PLAY 568 requests. 570 For example, a requested URI of rtsp://foo.bar/nemo#t=npt:10 will 571 e.g. result in the following PLAY request: 573 PLAY rtsp://foo.bar/nemo RTSP 1.0 574 CSeq: 2 575 Session: 12345678 576 Range: npt=10- 578 An implementation of this specification has not been put forward yet. 580 Also note that RealNetworks is using a different syntax for querying 581 temporal intervals of RealMedia over RTP/RTSP. 583 8. Security considerations 585 This specification does not create any new security issues beyond the 586 ones already specified for URIs in RFC 3986 [6]. 588 9. ChangeLog 590 draft-pfeiffer-temporal-fragments-01: 591 o Extension of the number of available SMPTE time-schemes. Many 592 thanks to Bill Miller and Oliver Morgan of the SMPTE for their 593 input on these changes. 594 o Deleted "start" and "now" as time specification values. 595 o Extension of the temporal fragment addressing to also address 596 temporal intervals, not only time points. 597 o Added section that includes some key points of discussion where 598 the existing URI standard contradicts the use of fragments for 599 time-continuous data. 601 draft-pfeiffer-temporal-fragments-02: 602 o Full compatibility with existing URI standard specification is 603 achieved by using both, query and fragment specifications for 604 addressing. 605 o Restriction of specification to http scheme (Web) only, as usage 606 on other protocols (such as rtp/rtsp) still needs to be explored. 607 o All addressing is interval based because an offset really implies 608 a view onto the document from that point onwards. 610 draft-pfeiffer-temporal-fragments-03: 611 o Restricted the specification for Annodex and CMML currently with 612 only a suggestion to adopt it for other formats. 613 o Changed the specification of periods of time to be compatible with 614 ISO 8601, i.e. replaced "-" with "/". This is also very useful 615 for time specs that contain a "-" like most of the ISO 8601 specs. 616 Thanks to Dean Blackketter for pointing it out. 617 o Replaced the word "timebase" with the word "basetime" as that 618 seems to be the more commonly used one to specify a timestamp for 619 the start of a stream of time-sampled data. 620 o Added a section on how to use timed URIs with HTTP. This includes 621 caching Web proxies and added HTTP message headers. 622 o Started a section on how to use timed URIs with RTP/RTSP. Some 623 initial feedback from the AVT Working Group at IETF seems to 624 indicate not to bother with rtsp queries and just to focus on 625 fragments. This may not be quite conformant to the URI RFC 626 because these RTP/RTSP fragments would be handled on the server - 627 yet this has not been resolved for any use of fragments over 628 RTP/RTSP. 630 draft-pfeiffer-temporal-fragments-04: 631 o Fixed some of the examples for the specification of samples with 632 times, which should now include "t=". 634 10. References 636 [1] Pfeiffer, S., Parker, C. and A. Pang, "The Annodex exchange 637 format for time-continuous data files, Version 3.0 (work in 638 progress)", I-D draft-pfeiffer-annodex-02.txt, March 2005, 639 . 641 [2] Pfeiffer, S., Parker, C. and A. Pang, "The Continuous Media 642 Markup Language (CMML), Version 2.0 (work in progress)", 643 I-D draft-pfeiffer-cmml-02.txt, March 2005, 644 . 646 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirements 647 Levels", RFC 2119, BCP 14, March 1997. 649 [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 650 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 651 HTTP/1.1", RFC 2616, June 1999, 652 . 654 [5] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 655 Protocol (RTSP)", RFC 2326, April 1998. 657 [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 658 Identifiers (URI): Generic Syntax", RFC 3986, January 2005, 659 . 661 [7] The Society of Motion Picture and Television Engineers, "SMPTE 662 STANDARD for Television, Audio and Film - Time and Control 663 Code", ANSI 12M-1999, September 1999. 665 [8] ISO, TC154., "Data elements and interchange formats -- 666 Information interchange -- Representation of dates and times", 667 ISO 8601, 2000. 669 Authors' Addresses 671 Silvia Pfeiffer 672 Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia 673 PO Box 76 674 Epping, NSW 1710 675 Australia 677 Phone: +61 2 9372 4180 678 Email: Silvia.Pfeiffer@csiro.au 679 URI: http://www.ict.csiro.au/Silvia.Pfeiffer/ 680 Conrad D. Parker 681 Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia 682 PO Box 76 683 Epping, NSW 1710 684 Australia 686 Phone: +61 2 9372 4222 687 Email: Conrad.Parker@csiro.au 688 URI: http://www.ict.csiro.au/Conrad.Parker/ 690 Andre T. Pang 691 Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia 692 PO Box 76 693 Epping, NSW 1710 694 Australia 696 Phone: +61 2 9372 4222 697 Email: Andre.Pang@csiro.au 698 URI: http://www.ict.csiro.au/ 700 Appendix A. Acknowledgements 702 The authors greatly acknowledge the contributions of Rob Collins, Zen 703 Kavanagh, and Andrew Nesbit in developing this specification. We 704 also thank Bill Miller and Oliver Morgan of the SMPTE, Dave Singer 705 from Apple Computer Inc., and Dean Blackketter for their 706 contributions. 708 The many comments on this document from the URI discussion group at 709 the W3C (uri@w3.org), especially the comments from Larry Masinter, Al 710 Gilman and Martin Duerst and others have strongly shaped the current 711 format. 713 Many thanks also to the Audio/Video Transport working group at the 714 IETF (avt@ietf.org), foremost to Magnus Westerlund, for giving 715 valuable feedback on how to improve the specification and picking up 716 the discussion around how to use the scheme on RTP/RTSP. 718 Last but not least thanks go to the ISO/MPEG working group with whom 719 harmonisation in addressing formats is still pursued - thanks to Ian 720 Burnett, Myriam Amielh, Ernest Wan, and Gerrard Drury. 722 Intellectual Property Statement 724 The IETF takes no position regarding the validity or scope of any 725 Intellectual Property Rights or other rights that might be claimed to 726 pertain to the implementation or use of the technology described in 727 this document or the extent to which any license under such rights 728 might or might not be available; nor does it represent that it has 729 made any independent effort to identify any such rights. Information 730 on the procedures with respect to rights in RFC documents can be 731 found in BCP 78 and BCP 79. 733 Copies of IPR disclosures made to the IETF Secretariat and any 734 assurances of licenses to be made available, or the result of an 735 attempt made to obtain a general license or permission for the use of 736 such proprietary rights by implementers or users of this 737 specification can be obtained from the IETF on-line IPR repository at 738 http://www.ietf.org/ipr. 740 The IETF invites any interested party to bring to its attention any 741 copyrights, patents or patent applications, or other proprietary 742 rights that may cover technology that may be required to implement 743 this standard. Please address the information to the IETF at 744 ietf-ipr@ietf.org. 746 Disclaimer of Validity 748 This document and the information contained herein are provided on an 749 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 750 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 751 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 752 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 753 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 754 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 756 Copyright Statement 758 Copyright (C) The Internet Society (2005). This document is subject 759 to the rights, licenses and restrictions contained in BCP 78, and 760 except as set forth therein, the authors retain all their rights. 762 Acknowledgment 764 Funding for the RFC Editor function is currently provided by the 765 Internet Society.