ContentDuration - Revision history

Rillian: RFC 3803 defines an integer version of this header

2009-12-30T08:15:50Z

RFC 3803 defines an integer version of this header

← Older revision		Revision as of 08:15, 30 December 2009
Line 6:		Line 6:

	This is intended to be the playback duration of the resource, regardless of any time offset in internal timestamps.		This is intended to be the playback duration of the resource, regardless of any time offset in internal timestamps.

			This header is already documented for MIME, ''with integer instead of fractional decimal seconds'', in [http://tools.ietf.org/html/rfc3803 RFC 3803].

	Older applications used X-Content-Duration instead. This SHOULD be supported by user agents for backwards compatibility with older server		Older applications used X-Content-Duration instead. This SHOULD be supported by user agents for backwards compatibility with older server

Rillian: Q: support HH:MM:SS?

2009-12-30T05:21:31Z

Q: support HH:MM:SS?

← Older revision		Revision as of 05:21, 30 December 2009
Line 1:		Line 1:
	We've been using the Content-Duration header with http servers to provide the length (in time) of a particular Ogg physical bitstream. This speeds up ui display and, if Content-Length is also set, allows faster seeking dispatch over remote protocols by priming the binary search with an initial average bitrate.		We've been using the Content-Duration message header with http servers to provide the length (in time) of a particular Ogg physical bitstream. This speeds up ui display and, if Content-Length is also set, allows faster seeking dispatch over remote protocols by priming the binary search with an initial average bitrate.

	Older applications used X-Content-Duration instead. This SHOULD be supported by user agents for backwards compatibility with older server implementations, but new servers should use Content-Duration. This page is a draft spec for registering that message header.		The header specifies the duration of a temporal-tracked media resource in decimal seconds, e.g.

			Content-Duration: 2189.242

			This is intended to be the playback duration of the resource, regardless of any time offset in internal timestamps.

			Older applications used X-Content-Duration instead. This SHOULD be supported by user agents for backwards compatibility with older server
			implementations, but new servers should use Content-Duration. This page is a draft spec for registering that message header.

			Question: should we allow the [[[DDD]:HH]:MM]:SS.sss format as well? It's more work to parse, but seems more natural for a message header.

	== PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE ==		== PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE ==

Rillian: /* PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE */ fill in some defaults

2009-12-30T05:05:45Z

PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE: fill in some defaults

← Older revision		Revision as of 05:05, 30 December 2009
Line 5:		Line 5:
	== PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE ==		== PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE ==

	Header field name:		Header field name: Content-Duration
	The name proposed for the new header field. This SHOULD conform		The name proposed for the new header field. This SHOULD conform
	to the field name specification details noted in Section 4.1.		to the field name specification details noted in Section 4.1.

	Applicable protocol:		Applicable protocol: http (applicable to mime in general?)
	Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616),		Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616),
	"netnews" (RFC 1036), or cite any other standards-track RFC		"netnews" (RFC 1036), or cite any other standards-track RFC
Line 15:		Line 15:
	used.		used.

	Status:		Status: provisional
	Specify: "provisional". This will be updated if and when the		Specify: "provisional". This will be updated if and when the
	header registration is subsequently moved to the permanent		header registration is subsequently moved to the permanent
	registry.		registry.

	Author/Change controller:		Author/Change controller: Ralph Giles <giles@xiph.org> Xiph.org Foundation
	The name, email address, and organization name of the submission		The name, email address, and organization name of the submission
	author, who may authorize changes to or retraction of the		author, who may authorize changes to or retraction of the
Line 29:		Line 29:
	address for discussion of or comments on the specification.		address for discussion of or comments on the specification.

	Specification document(s):		Specification document(s): http://wiki.xiph.org/ContentDuration
	Reference to document that specifies the header for use with the		Reference to document that specifies the header for use with the
	indicated protocol. The document MUST be an RFC, a current		indicated protocol. The document MUST be an RFC, a current
Line 36:		Line 36:
	of the relevant sections MAY also be included, but is not		of the relevant sections MAY also be included, but is not
	required.		required.

	~~NOTE: if the specification is available in printed form only,~~
	~~then an Internet draft containing full reference to the paper~~
	~~document should be published and cited in the registration~~
	~~template. The paper specification MAY be cited under related~~
	~~information.~~

	Related information:		Related information:
	Optionally, citations to additional documents containing further		Optionally, citations to additional documents containing further
	relevant information.		relevant information.

Rillian: paste in the provisional registration template from RFC 3864

2009-12-30T05:00:28Z

paste in the provisional registration template from RFC 3864

← Older revision		Revision as of 05:00, 30 December 2009
Line 2:		Line 2:

	Older applications used X-Content-Duration instead. This SHOULD be supported by user agents for backwards compatibility with older server implementations, but new servers should use Content-Duration. This page is a draft spec for registering that message header.		Older applications used X-Content-Duration instead. This SHOULD be supported by user agents for backwards compatibility with older server implementations, but new servers should use Content-Duration. This page is a draft spec for registering that message header.

			== PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE ==

			Header field name:
			The name proposed for the new header field. This SHOULD conform
			to the field name specification details noted in Section 4.1.

			Applicable protocol:
			Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616),
			"netnews" (RFC 1036), or cite any other standards-track RFC
			defining the protocol with which the header is intended to be
			used.

			Status:
			Specify: "provisional". This will be updated if and when the
			header registration is subsequently moved to the permanent
			registry.

			Author/Change controller:
			The name, email address, and organization name of the submission
			author, who may authorize changes to or retraction of the
			repository entry. A postal address, home page URI, telephone and
			fax numbers may also be included.
			If the proposal comes from a standards body working group, give
			the name and home page URI of the working group, and an email
			address for discussion of or comments on the specification.

			Specification document(s):
			Reference to document that specifies the header for use with the
			indicated protocol. The document MUST be an RFC, a current
			Internet-draft or the URL of a publicly accessible document (so
			IANA can verify availability of the specification). An indication
			of the relevant sections MAY also be included, but is not
			required.

			NOTE: if the specification is available in printed form only,
			then an Internet draft containing full reference to the paper
			document should be published and cited in the registration
			template. The paper specification MAY be cited under related
			information.

			Related information:
			Optionally, citations to additional documents containing further
			relevant information.

Rillian: Start a draft for the Content-Duration message header

2009-12-30T04:57:23Z

Start a draft for the Content-Duration message header

New page

We've been using the Content-Duration header with http servers to provide the length (in time) of a particular Ogg physical bitstream. This speeds up ui display and, if Content-Length is also set, allows faster seeking dispatch over remote protocols by priming the binary search with an initial average bitrate.

Older applications used X-Content-Duration instead. This SHOULD be supported by user agents for backwards compatibility with older server implementations, but new servers should use Content-Duration. This page is a draft spec for registering that message header.