From f96a9d5816ea57598985b12ef0d98251db33c062 Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Tue, 26 Oct 2021 23:20:19 -0700 Subject: [PATCH 01/21] Add table of certificate algorithms --- index.bs | 54 ++++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 44 insertions(+), 10 deletions(-) diff --git a/index.bs b/index.bs index edf457e..9fd9b01 100644 --- a/index.bs +++ b/index.bs @@ -55,6 +55,8 @@ url: https://tools.ietf.org/html/rfc8122#section-5; type: dfn; spec: RFC8122; te url: https://tools.ietf.org/html/rfc8122#section-5; type: dfn; spec: RFC8122; text: md5 url: https://tools.ietf.org/html/rfc6381#section-3; type: dfn; spec: RFC6381; text: codecs parameter url: https://tools.ietf.org/html/rfc8610#section-3; type: dfn; spec: RFC8610; text: concise data definition language +url: https://tools.ietf.org/html/rfc5280#section-4.2.1.3; type: dfn; spec: RFC5280; text: digitalSignature +url: https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3; type: dfn; spec: RFC8446; text: signature scheme Introduction {#introduction} @@ -367,16 +369,43 @@ QUIC connection. The [=agent certificate=] must have the following characteristics: -* 256-bit, 384-bit, or 521-bit ECDSA public key -* Self-signed -* Supporting the at least one of the following signature algorithms: - * secp256r1_sha256 - * secp384r1_sha384 - * secp521r1_sha512 -* Valid for signing +* 256-bit, 384-bit, or 521-bit ECDSA public key. +* Self-signed. +* Supporting the at least one of the [=certificate algorithms=] listed below. + * The `AlgorithmIdentifiers` are defined in [[!RFC5480]]. +* Valid for signing. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Agent Certificate Algorithms
TLS 1.3 [=Signature Scheme=]Public Key `AlgorithmIdentifier`Signature `AlgorithmIdentifier`
`secp256r1_sha256``301306072a8648ce3d020106082a8648ce3d030107``300a06082a8648ce3d040302`
`secp384r1_sha384``301006072a8648ce3d020106052b81040022``300a06082a8648ce3d040303`
`secp521r1_sha512`TBDTBD
The following X.509 v3 fields are to be set as follows: +
@@ -392,8 +421,12 @@ The following X.509 v3 fields are to be set as follows: - - + + + + + + @@ -416,10 +449,11 @@ The following X.509 v3 fields are to be set as follows: - +
Field``
Signature Algorithm IDOne of the values listed above.Public Key `AlgorithmIdentifier`One of the supported [=certificate algorithms=].
Signature `AlgorithmIdentifier`One of the supported [=certificate algorithms=].
Issuer Name
Certificate Key usageSigning[=digitalSignature=]
+
Mandatory fields not mentioned above should be set according to [[!RFC5280]]. From d78c511832115551646a02d6b69cf45a00f845b5 Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Thu, 8 Sep 2022 11:58:23 -0700 Subject: [PATCH 02/21] Remove P521 from the public key algorithm table --- index.bs | 5 ----- 1 file changed, 5 deletions(-) diff --git a/index.bs b/index.bs index 383f1c5..1ab9717 100644 --- a/index.bs +++ b/index.bs @@ -395,11 +395,6 @@ The [=agent certificate=] must have the following characteristics: `301006072a8648ce3d020106052b81040022` `300a06082a8648ce3d040303` - - `secp521r1_sha512` - TBD - TBD - From 71dc49182fe95a850fad3dafb7e3695d13944a78 Mon Sep 17 00:00:00 2001 From: "Mark Foltz (Google)" Date: Fri, 9 Sep 2022 11:34:17 -0700 Subject: [PATCH 03/21] Update index.bs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: François Daoust --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 1ab9717..06b2e07 100644 --- a/index.bs +++ b/index.bs @@ -371,7 +371,7 @@ The [=agent certificate=] must have the following characteristics: * 256-bit, 384-bit, or 521-bit ECDSA public key. * Self-signed. -* Supporting the at least one of the [=certificate algorithms=] listed below. +* Supporting at least one of the [=certificate algorithms=] listed below. * The `AlgorithmIdentifiers` are defined in [[!RFC5480]]. * Valid for signing. From 1d5c721158fee61d5cccf0ea55cb345602a2145f Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Fri, 9 Sep 2022 13:04:46 -0700 Subject: [PATCH 04/21] Add OIDs --- index.bs | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/index.bs b/index.bs index 06b2e07..c58c60b 100644 --- a/index.bs +++ b/index.bs @@ -372,7 +372,8 @@ The [=agent certificate=] must have the following characteristics: * 256-bit, 384-bit, or 521-bit ECDSA public key. * Self-signed. * Supporting at least one of the [=certificate algorithms=] listed below. - * The `AlgorithmIdentifiers` are defined in [[!RFC5480]]. + * The `AlgorithmIdentifiers` are defined in [[!RFC5480]] (for public keys) and + [[!RFC5758]] (for signature schemes). * Valid for signing. @@ -387,8 +388,25 @@ The [=agent certificate=] must have the following characteristics: - - + + From 1bf41199718bb74596ef96267af626f3481636bd Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Fri, 9 Sep 2022 13:07:18 -0700 Subject: [PATCH 05/21] Fix indent --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index c58c60b..d9d2629 100644 --- a/index.bs +++ b/index.bs @@ -373,7 +373,7 @@ The [=agent certificate=] must have the following characteristics: * Self-signed. * Supporting at least one of the [=certificate algorithms=] listed below. * The `AlgorithmIdentifiers` are defined in [[!RFC5480]] (for public keys) and - [[!RFC5758]] (for signature schemes). + [[!RFC5758]] (for signature schemes). * Valid for signing.
`secp256r1_sha256``301306072a8648ce3d020106082a8648ce3d030107``300a06082a8648ce3d040302``secp256r1` +

+ Object Identifiers: +

    +
  1. `1.2.840.10045.2.1` (ECC)
    2. +
  2. `1.2.840.10045.3.1.7` (ECDSA P256)
    3. +
+ DER representation: `301306072a8648ce3d020106082a8648ce3d030107` +

+ 		`ecdsaWithSha256` +

+ Object identifier: +

    +
  1. `1.2.840.10045.4.3.2`
    2. +
+ DER representation: `300a06082a8648ce3d040302` +

+
`secp384r1_sha384`
From 7817aa602616b68a8ba4f430a733491eabfb2f11 Mon Sep 17 00:00:00 2001 From: "Mark Foltz (Google)" Date: Mon, 7 Nov 2022 14:55:06 -0800 Subject: [PATCH 06/21] Adds a reference to the DER specification. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: François Daoust --- index.bs | 1 + 1 file changed, 1 insertion(+) diff --git a/index.bs b/index.bs index d9d2629..761a254 100644 --- a/index.bs +++ b/index.bs @@ -374,6 +374,7 @@ The [=agent certificate=] must have the following characteristics: * Supporting at least one of the [=certificate algorithms=] listed below. * The `AlgorithmIdentifiers` are defined in [[!RFC5480]] (for public keys) and [[!RFC5758]] (for signature schemes). + * [[!X690]] specifies the Distinguished Encoding Rules (DER) representation used to encode the identifiers. * Valid for signing.
From f7bf346a615c37290299c4bbade196759322d778 Mon Sep 17 00:00:00 2001 From: "Mark Foltz (Google)" Date: Mon, 7 Nov 2022 14:56:35 -0800 Subject: [PATCH 07/21] Update AlgorithmIdentifier to match RFC 5758. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: François Daoust --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 761a254..b1d9725 100644 --- a/index.bs +++ b/index.bs @@ -399,7 +399,7 @@ The [=agent certificate=] must have the following characteristics: DER representation: `301306072a8648ce3d020106082a8648ce3d030107`

-
`ecdsaWithSha256` + `ecdsa-with-SHA256`

Object identifier:

    From b37e82d8a04ff05cca0825daa1d6c1dc48985ee0 Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Fri, 9 Sep 2022 15:47:00 -0700 Subject: [PATCH 08/21] Add transfer-functions and hdr-metadata to video-capabilities. --- index.bs | 15 +++++++++++++-- messages_appendix.cddl | 8 +++++--- 2 files changed, 18 insertions(+), 5 deletions(-) diff --git a/index.bs b/index.bs index b1d9725..fab14a7 100644 --- a/index.bs +++ b/index.bs @@ -1742,8 +1742,6 @@ following additional fields: display could return this value as 1.6 to indicate its preferred content scaling. Default is none. -Issue(194): Expose capabilities for decoding HDR transfer functions and metadata formats. - : color-gamuts (optional) :: An optional field indicating what color spaces can be decoded and rendered by the media receiver. The media sender may use these values to determine how @@ -1751,6 +1749,19 @@ Issue(194): Expose capabilities for decoding HDR transfer functions and metadata in the [[!MEDIA-CAPABILITIES|Media Capabilities]] API. The default value is a list with the single entry "srgb". +: transfer-functions (optional) +:: An optional field indicating what HDR transfer functions can be decoded and rendered + by the media receiver. Valid values correspond to + [[MEDIA-CAPABILITIES#transferfunction|TransferFunction]] in the + [[!MEDIA-CAPABILITIES|Media Capabilities]] API. The default value is a list with the + single entry "srgb". + +: hdr-metadata (optional) +:: An optional field indicating what HDR metadata types can be decoded and rendered by + by the media receiver. Valid values correspond to + [[MEDIA-CAPABILITIES#hdrmetadatatype|HdrMetadataType]] in the + [[!MEDIA-CAPABILITIES|Media Capabilities]] API. The default value is an empty list. + : native-resolutions (optional) :: An optional field indicating what video-resolutions the media receiver supports and considers to be "native," meaning that scaling is not required. diff --git a/messages_appendix.cddl b/messages_appendix.cddl index 08c5534..ea9e28d 100644 --- a/messages_appendix.cddl +++ b/messages_appendix.cddl @@ -561,9 +561,11 @@ receive-video-capability = { ? 4: uint ; min-bit-rate ? 5: ratio ; aspect-ratio ? 6: [* string] ; color-gamuts - ? 7: [* video-resolution] ; native-resolutions - ? 8: bool ; supports-scaling - ? 9: bool ; supports-rotation + ? 7: [* string] ; transfer-functions + ? 8: [* string] ; hdr-metadata + ? 9: [* video-resolution] ; native-resolutions + ? 10: bool ; supports-scaling + ? 11: bool ; supports-rotation } receive-data-capability = { From 59ec1da4dd50fd799045496fb86f93a1b33d7845 Mon Sep 17 00:00:00 2001 From: "Mark Foltz (Google)" Date: Fri, 9 Sep 2022 15:34:43 -0700 Subject: [PATCH 09/21] Correct typo in RFC8446. --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index fab14a7..38b228e 100644 --- a/index.bs +++ b/index.bs @@ -2604,7 +2604,7 @@ authentication: The active attacker may also attempt to disrupt data exchanged over the QUIC connection by injecting or modifying traffic. These attacks should be mitigated -by a correct implementation of TLS 1.3. See Appendix E of [[RFC846]] for a +by a correct implementation of TLS 1.3. See Appendix E of [[RFC8446]] for a detailed security analysis of the TLS 1.3 protocol. ### Remote active network attackers ### {#remote-active-mitigations} From 442a830b13e54dbf6466b70bb232eb303a90f67f Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Fri, 9 Sep 2022 14:18:47 -0700 Subject: [PATCH 10/21] Explain what a time scale is. --- index.bs | 38 +++++++++++++++++++++++--------------- 1 file changed, 23 insertions(+), 15 deletions(-) diff --git a/index.bs b/index.bs index 38b228e..35e29d4 100644 --- a/index.bs +++ b/index.bs @@ -1051,6 +1051,16 @@ must send a [=presentation-connection-open-response=] message and [=presentation-change-event=] messages when required. +Representation Of Time {#time-representation} +====================== + +The [[#remote-playback-protocol]] and the [[#streaming-protocol]] represent +points of time and durations in terms of a [=time scale=]. A time +scale is a common denominator for time values that allows values which +work on different time scales to be expressed as rational numbers without loss +of precision. The [=time scale=] is represented in hertz, such as 90000 for +90000 Hz, a common time scale for video. + Remote Playback Protocol {#remote-playback-protocol} ======================== @@ -1565,9 +1575,7 @@ changed. All times, time ranges, and durations (such as position, duration, and seekable-time-ranges) used above use a common [=media-time=] value (see Appendix A) -which includes a time scale. This allows time values which work on different -time scales to be expressed without loss of precision. The scale is represented -in hertz, such as 90000 for 90000 Hz, a common time scale for video. +which includes a [=time scale=].
    @@ -1851,7 +1859,7 @@ Each audio encoding offered defines the following fields: RFC 6381 [=codecs parameter=]. : time-scale -:: The time scale used by all audio frames. This allows senders to +:: The [=time scale=] used by all audio frames. This allows senders to make audio-frame messages smaller by not including the time scale in each one. @@ -1872,7 +1880,7 @@ Each video encoding offered defines the following fields: :: The name of the codec used by the encoding. : time-scale -:: The time scale used by all video frames. This allows senders to +:: The [=time scale=] used by all video frames. This allows senders to make video-frame messages smaller by not including the time scale in each one. @@ -1898,7 +1906,7 @@ Each data encoding offered defines the following fields: :: The name of the data type used by the encoding. : time-scale -:: The time scale used by all data frames. This allows senders to +:: The [=time scale=] used by all data frames. This allows senders to make data-frame messages smaller by not including the time scale in each one. @@ -1978,21 +1986,21 @@ separate QUIC streams. :: Identifies the media encoding to which this audio frame belongs. This can be used to reference fields of the encoding (from the [=audio-encoding-offer=] message) such as the codec, codec properties, - time scale (aka clock rate), and default duration. + [=time scale=], and default duration. Referencing fields of the encoding through the encoding id helps to avoid sending duplicate information in every frame. : start-time :: Identifies the beginning of the time range of the audio frame. The end time can be inferred from the start time and duration. The - time scale is equal to the value in the `time-scale` field of the + [=time scale=] is equal to the value in the `time-scale` field of the [=audio-encoding-offer=] message referenced by the `encoding-id`. : duration :: If present, the duration of the audio frame. If not present, the duration is equal to the `default-duration` field of the [=audio-encoding-offer=] message referenced by the `encoding-id`. - The time scale is equal to the value in the `time-scale` field of + The [=time scale=] is equal to the value in the `time-scale` field of the [=audio-encoding-offer=] message referenced by the `encoding-id`. : sync-time @@ -2025,7 +2033,7 @@ ending at the last dependent frame. : encoding-id :: Identifies the media encoding to which this video frame belongs. This can be used to reference fields of the encoding such as the - codec, codec properties, time scale, and default rotation. + codec, codec properties, [=time scale=], and default rotation. Referencing fields of the encoding through the encoding id helps to avoid sending duplicate information in every frame. @@ -2044,12 +2052,12 @@ ending at the last dependent frame. : start-time :: Identifies the beginning of the time range of the video frame. The end time can be inferred from the start time and duration. The - time scale is equal to the value in the `time-scale` field of the + [=time scale=] is equal to the value in the `time-scale` field of the [=video-encoding-offer=] message referenced by the `encoding-id`. : duration :: If present, the duration of the video frame. If not present, that - means duration is unknown. The time scale is equal to the value + means duration is unknown. The [=time scale=] is equal to the value in the `time-scale` field of the [=video-encoding-offer=] message referenced by the `encoding-id`. @@ -2085,7 +2093,7 @@ that makes sense for a specific type of data. : encoding-id :: Identifies the data encoding to which this data frame belongs. This can be used to reference fields of the encoding such as the type of data and - time scale. Referencing fields of the encoding through the encoding id + [=time scale=]. Referencing fields of the encoding through the encoding id helps to avoid sending duplicate information in every frame. : sequence-number @@ -2096,14 +2104,14 @@ that makes sense for a specific type of data. : start-time :: Identifies the beginning of the time range of the data frame. The end time can be inferred from the start time and duration. The - time scale is equal to the value in the `time-scale` field of the + [=time scale=] is equal to the value in the `time-scale` field of the [=data-encoding-offer=] message referenced by the `encoding-id`. : duration :: If present, the duration of the data frame. If not present, the duration is equal to the `default-duration` field of the [=data-encoding-offer=] message referenced by the `encoding-id`. - The time scale is equal to the value in the `time-scale` field of + The [=time scale=] is equal to the value in the `time-scale` field of the [=data-encoding-offer=] message referenced by the `encoding-id`. : sync-time From d6df8ab949c7b0cc112dbcf24bb23cdab07ef9d3 Mon Sep 17 00:00:00 2001 From: "Mark Foltz (Google)" Date: Mon, 12 Sep 2022 13:41:16 -0700 Subject: [PATCH 11/21] Update per comment by tidoust@. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Don't use a circular reference to "time scale." Co-authored-by: François Daoust --- index.bs | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/index.bs b/index.bs index 35e29d4..3e62571 100644 --- a/index.bs +++ b/index.bs @@ -1056,10 +1056,10 @@ Representation Of Time {#time-representation} The [[#remote-playback-protocol]] and the [[#streaming-protocol]] represent points of time and durations in terms of a [=time scale=]. A time -scale is a common denominator for time values that allows values which -work on different time scales to be expressed as rational numbers without loss -of precision. The [=time scale=] is represented in hertz, such as 90000 for -90000 Hz, a common time scale for video. +scale is a common denominator for time values that allows values to be +expressed as rational numbers without loss of precision. The [=time scale=] is +represented in hertz, such as 90000 for 90000 Hz, a common time scale for +video. Remote Playback Protocol {#remote-playback-protocol} ======================== From 9d610defb227bfc25d9862c32e49feca7366ede9 Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Thu, 8 Sep 2022 12:54:11 -0700 Subject: [PATCH 12/21] Remove P-521 curve from agent certificate requirements --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 3e62571..25eca40 100644 --- a/index.bs +++ b/index.bs @@ -369,7 +369,7 @@ QUIC connection. The [=agent certificate=] must have the following characteristics: -* 256-bit, 384-bit, or 521-bit ECDSA public key. +* 256-bit or 384-bit ECDSA public key. * Self-signed. * Supporting at least one of the [=certificate algorithms=] listed below. * The `AlgorithmIdentifiers` are defined in [[!RFC5480]] (for public keys) and From f70adc2ec97e98ffe3f822065ba42d6087338e0c Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Fri, 9 Sep 2022 15:19:52 -0700 Subject: [PATCH 13/21] Reference WebCodecs registry for codec names. --- index.bs | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/index.bs b/index.bs index 25eca40..753aab7 100644 --- a/index.bs +++ b/index.bs @@ -1703,15 +1703,18 @@ The format type is used as the basis for audio and video capabilities. Formats are composed of the following fields: : name (required) -:: The name of the codec. This must be a single-codec RFC 6381 [=codecs parameter=]. - -Issue(233): Use the same codec names as the media APIs. +:: A fully qualified codec string listed in the [[WEBCODECS-CODEC-REGISTRY]] and further + specified by the codec-specific registrations referenced in that registry. : parameters (required) :: A list of (key, value) parameters that can be used to describe properties of a specific format, and not shared by other formats of that type (audio, video, etc.). +For `name`, Open Screen agents may also accept a single-codec [=codec +parameter=] as described in [[!RFC6381]] for codecs not listed in the +[[WEBCODECS-CODEC-REGISTRY]]. + Issue(266): Specify where codec-specific parameters are defined or drop them. Audio capabilities are composed of the above format type, with the following From 99cbc565e246f6a9910fb472cca66eefcc9e68b9 Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Fri, 30 Sep 2022 15:38:31 -0700 Subject: [PATCH 14/21] Tentative fix --- index.bs | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index 753aab7..6be56d5 100644 --- a/index.bs +++ b/index.bs @@ -23,13 +23,14 @@ urlPrefix: https://html.spec.whatwg.org/multipage/media.html#; type: dfn; spec: text: official playback position text: poster frame text: timeline offset -urlPrefix: https://w3c.github.io/presentation-api/#dfn-; type: dfn; spec: PRESENTATION-API +urlPrefix: https://www.w3.org/TR/presentation-api/#dfn-; type: dfn; spec: PRESENTATION-API text: available presentation display text: controlling user agent text: presentation text: presentation id text: presentation request url text: receiving user agent + text: creating a receiving browsing context urlPrefix: https://w3c.github.io/presentation-api/; type: interface; spec: PRESENTATION-API text: PresentationConnection urlPrefix: https://w3c.github.io/remote-playback/#dfn-; type: dfn; spec: REMOTE-PLAYBACK @@ -831,7 +832,7 @@ values: : headers :: headers that the receiver should use to fetch the presentation URL. For example, - [[PRESENTATION-API#establishing-a-presentation-connection|section 6.6.1]] of + [[PRESENTATION-API#creating-a-receiving-browsing-context|section 6.6.1]] of the Presentation API says that the Accept-Language header should be provided. From 4c198423f77157591aae7f4a9c19f7eea07b1342 Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Fri, 30 Sep 2022 15:41:29 -0700 Subject: [PATCH 15/21] Use TR link --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 6be56d5..0c07298 100644 --- a/index.bs +++ b/index.bs @@ -31,7 +31,7 @@ urlPrefix: https://www.w3.org/TR/presentation-api/#dfn-; type: dfn; spec: PRESEN text: presentation request url text: receiving user agent text: creating a receiving browsing context -urlPrefix: https://w3c.github.io/presentation-api/; type: interface; spec: PRESENTATION-API +urlPrefix: https://www.w3.org/TR/presentation-api/; type: interface; spec: PRESENTATION-API text: PresentationConnection urlPrefix: https://w3c.github.io/remote-playback/#dfn-; type: dfn; spec: REMOTE-PLAYBACK text: availability sources set From d0c8817da2b7784bb78f6b99317b55c934befeec Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Tue, 11 Oct 2022 11:15:47 -0700 Subject: [PATCH 16/21] Undo HTMLMediaElement changes --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 0c07298..02f0eeb 100644 --- a/index.bs +++ b/index.bs @@ -833,7 +833,7 @@ values: : headers :: headers that the receiver should use to fetch the presentation URL. For example, [[PRESENTATION-API#creating-a-receiving-browsing-context|section 6.6.1]] of - the Presentation API says that the Accept-Language header should be + the Presentation API says that the HTTP `Accept-Language` header should be provided. The presentation ID must follow the restrictions defined by From fb600d1e22726dd279ec06c0fcf76193820a6ef5 Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Fri, 14 Oct 2022 15:12:09 -0700 Subject: [PATCH 17/21] Make some other xref fixes --- index.bs | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/index.bs b/index.bs index 02f0eeb..3015ae9 100644 --- a/index.bs +++ b/index.bs @@ -31,8 +31,6 @@ urlPrefix: https://www.w3.org/TR/presentation-api/#dfn-; type: dfn; spec: PRESEN text: presentation request url text: receiving user agent text: creating a receiving browsing context -urlPrefix: https://www.w3.org/TR/presentation-api/; type: interface; spec: PRESENTATION-API - text: PresentationConnection urlPrefix: https://w3c.github.io/remote-playback/#dfn-; type: dfn; spec: REMOTE-PLAYBACK text: availability sources set text: compatible remote playback device @@ -1449,13 +1447,13 @@ changed. : loading :: The state of network activity for loading the [=media resource=]. See {{HTMLMediaElement/networkState|HTMLMediaElement.networkState}}. - The default is empty ({{NETWORK_EMPTY}} + The default is empty ({{NETWORK_EMPTY}}) for the initial state in the [=remote-playback-start-response=] message. : loaded :: The state of the loaded media (whether enough is loaded to play). See {{HTMLMediaElement/readyState|HTMLMediaElement.readyState}}. - The default is nothing ({{HAVE_NOTHING}} + The default is nothing ({{HAVE_NOTHING}}) for the initial state in the [=remote-playback-start-response=] message. : error @@ -1631,10 +1629,10 @@ This is how the [[REMOTE-PLAYBACK|Remote Playback API]] uses the messages defined in [[#remote-playback-protocol]]: When [[REMOTE-PLAYBACK#the-list-of-available-remote-playback-devices|section -6.2.1.2]] says "This list contains [=remote playback devices=] and is populated +5.2.1.2]] says "This list contains [=remote playback devices=] and is populated based on an implementation specific discovery mechanism" and [[REMOTE-PLAYBACK#the-list-of-available-remote-playback-devices|section -6.2.1.4]] says "Retrieve available remote playback devices (using an +5.2.1.4]] says "Retrieve available remote playback devices (using an implementation specific mechanism)", the user agent may use the mDNS, QUIC, [=agent-info-request=], and [=remote-playback-availability-request=] messages defined previously in this spec to discover [=receivers=]. The @@ -1643,7 +1641,7 @@ sources set=]. When [[REMOTE-PLAYBACK#establishing-a-connection-with-a-remote-playback-device|section -6.2.4]] says "Request connection of remote to device. The implementation of this +5.2.4]] says "Request connection of remote to device. The implementation of this step is specific to the user agent." and "Synchronize the current media element state with the remote playback state", the controller may send the [=remote-playback-start-request=] message to the receiver to start remote @@ -1654,7 +1652,7 @@ of [[REMOTE-PLAYBACK|Remote Playback API]] may allow for several. When [[REMOTE-PLAYBACK#establishing-a-connection-with-a-remote-playback-device|section -6.2.4]] says "The mechanism that is used to connect the user agent with the +5.2.4]] says "The mechanism that is used to connect the user agent with the remote playback device and play the remote playback source is an implementation choice of the user agent. The connection will likely have to provide a two-way messaging abstraction capable of carrying media commands to the remote playback @@ -1666,8 +1664,8 @@ based on changes to the local media element and receive change the local media element based on changes to the remote playback state. When -[[REMOTE-PLAYBACK#establishing-a-connection-with-a-remote-playback-device|section -6.2.7]] says "Request disconnection of remote from the device. The +[[REMOTE-PLAYBACK#disconnecting-from-a-remote-playback-device|section +5.2.7]] says "Request disconnection of remote from the device. The implementation of this step is specific to the user agent," the controller may send the [=remote-playback-termination-request=] message to the receiver. From 099f20479203ef7e9c59cef3096ce47732502ccd Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Fri, 14 Oct 2022 15:13:44 -0700 Subject: [PATCH 18/21] Remove unnecessary term --- index.bs | 1 - 1 file changed, 1 deletion(-) diff --git a/index.bs b/index.bs index 3015ae9..75e2770 100644 --- a/index.bs +++ b/index.bs @@ -30,7 +30,6 @@ urlPrefix: https://www.w3.org/TR/presentation-api/#dfn-; type: dfn; spec: PRESEN text: presentation id text: presentation request url text: receiving user agent - text: creating a receiving browsing context urlPrefix: https://w3c.github.io/remote-playback/#dfn-; type: dfn; spec: REMOTE-PLAYBACK text: availability sources set text: compatible remote playback device From c5468d605bff5974e4fda552c5424458f7c5467f Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Mon, 31 Oct 2022 10:23:21 -0700 Subject: [PATCH 19/21] Update PR per spec --- index.bs | 31 +++++++++++++++++++------------ messages_appendix.cddl | 14 +++++++++----- 2 files changed, 28 insertions(+), 17 deletions(-) diff --git a/index.bs b/index.bs index 75e2770..0e7849a 100644 --- a/index.bs +++ b/index.bs @@ -1758,18 +1758,25 @@ following additional fields: in the [[!MEDIA-CAPABILITIES|Media Capabilities]] API. The default value is a list with the single entry "srgb". -: transfer-functions (optional) -:: An optional field indicating what HDR transfer functions can be decoded and rendered - by the media receiver. Valid values correspond to - [[MEDIA-CAPABILITIES#transferfunction|TransferFunction]] in the - [[!MEDIA-CAPABILITIES|Media Capabilities]] API. The default value is a list with the - single entry "srgb". - -: hdr-metadata (optional) -:: An optional field indicating what HDR metadata types can be decoded and rendered by - by the media receiver. Valid values correspond to - [[MEDIA-CAPABILITIES#hdrmetadatatype|HdrMetadataType]] in the - [[!MEDIA-CAPABILITIES|Media Capabilities]] API. The default value is an empty list. +: hdr-formats (optional) +:: An optional field indicating what HDR transfer functions and metadata formats + can be decoded and rendered by the media receiver. Each `video-hdr-format` + consists of two fields, `transfer-function` and `hdr-metadata`. + + The `transfer-function` field must be a valid + [[MEDIA-CAPABILITIES#transferfunction|TransferFunction]] + and the `hdr-metadata` must be a valid + [[MEDIA-CAPABILITIES#hdrmetadatatype|HdrMetadataType]], both defined in the + [[!MEDIA-CAPABILITIES|Media Capabilities]] API. + + If a `video-hdr-format` is provided with a `transfer-function` but no + `hdr-metadata`, then the media receiver can render the `transfer-function` + without any associated metadata. (This is the case, for example, with the + "hlg" `transfer-function`.) + + If no `hdr-formats` are listed, then the media reciever cannot decode any + HDR formats. + : native-resolutions (optional) :: An optional field indicating what video-resolutions the media receiver supports and diff --git a/messages_appendix.cddl b/messages_appendix.cddl index ea9e28d..5cbb49d 100644 --- a/messages_appendix.cddl +++ b/messages_appendix.cddl @@ -553,6 +553,11 @@ video-resolution = { 1: uint ; width } +video-hdr-format = { + 0: transfer-function ; string + 1: ? hdr-metadata ; string +} + receive-video-capability = { 0: format ; codec ? 1: video-resolution ; max-resolution @@ -561,11 +566,10 @@ receive-video-capability = { ? 4: uint ; min-bit-rate ? 5: ratio ; aspect-ratio ? 6: [* string] ; color-gamuts - ? 7: [* string] ; transfer-functions - ? 8: [* string] ; hdr-metadata - ? 9: [* video-resolution] ; native-resolutions - ? 10: bool ; supports-scaling - ? 11: bool ; supports-rotation + ? 7: [* video-hdr-format] ; hdr-formats + ? 8: [* video-resolution] ; native-resolutions + ? 9: bool ; supports-scaling + ? 10: bool ; supports-rotation } receive-data-capability = { From b29aea978e2d67b993083bbcef910b538102a716 Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Mon, 31 Oct 2022 10:38:26 -0700 Subject: [PATCH 20/21] Clarify handling of dupes. Reorder fields. --- index.bs | 3 ++- messages_appendix.cddl | 8 ++++---- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/index.bs b/index.bs index 0e7849a..391561b 100644 --- a/index.bs +++ b/index.bs @@ -1765,7 +1765,7 @@ following additional fields: The `transfer-function` field must be a valid [[MEDIA-CAPABILITIES#transferfunction|TransferFunction]] - and the `hdr-metadata` must be a valid + and the `hdr-metadata` field must be a valid [[MEDIA-CAPABILITIES#hdrmetadatatype|HdrMetadataType]], both defined in the [[!MEDIA-CAPABILITIES|Media Capabilities]] API. @@ -1774,6 +1774,7 @@ following additional fields: without any associated metadata. (This is the case, for example, with the "hlg" `transfer-function`.) + The media receiver should ignore duplicate entries in `hdr-formats.` If no `hdr-formats` are listed, then the media reciever cannot decode any HDR formats. diff --git a/messages_appendix.cddl b/messages_appendix.cddl index 5cbb49d..6a10aca 100644 --- a/messages_appendix.cddl +++ b/messages_appendix.cddl @@ -566,10 +566,10 @@ receive-video-capability = { ? 4: uint ; min-bit-rate ? 5: ratio ; aspect-ratio ? 6: [* string] ; color-gamuts - ? 7: [* video-hdr-format] ; hdr-formats - ? 8: [* video-resolution] ; native-resolutions - ? 9: bool ; supports-scaling - ? 10: bool ; supports-rotation + ? 7: [* video-resolution] ; native-resolutions + ? 8: bool ; supports-scaling + ? 9: bool ; supports-rotation + ? 10: [* video-hdr-format] ; hdr-formats } receive-data-capability = { From d62bf1b834ba1d0011bad924a21bcc88933e35f7 Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Wed, 9 Nov 2022 17:29:34 -0800 Subject: [PATCH 21/21] Add DERs for P384 --- index.bs | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index 391561b..fb328d2 100644 --- a/index.bs +++ b/index.bs @@ -409,8 +409,25 @@ The [=agent certificate=] must have the following characteristics: - - + +
    `secp384r1_sha384``301006072a8648ce3d020106052b81040022``300a06082a8648ce3d040303``secp384r1` +

    + Object Identifiers: +

      +
    1. `1.2.840.10045.2.1` (ECC)
      2. +
    2. `1.3.132.0.34` (ECDSA P384)
      3. +
    + DER representation: `301006072a8648ce3d020106052b81040022` +

    +     		`ecdsa-with-SHA384` +

    + Object identifier: +

      +
    1. `1.2.840.10045.4.3.3`
      2. +
    + DER representation: `300a06082a8648ce3d040303` +

    +