diff --git a/abstract.md b/abstract.md index 8aba253..d801903 100644 --- a/abstract.md +++ b/abstract.md @@ -1,3 +1,3 @@ -This document specifies a protocol to notify WebDAV clients over push notifications when contents of a collection are changed on the WebDAV server. +This document specifies a protocol to notify WebDAV clients when the content or properties of a resource or its members are changed on the WebDAV server. -The protocol is primarily specified to be used with Web Push (RFC 8030), but can be used with other transports as well. +Currently, the only specified transport for these push notifications is Web Push (RFC 8030). However, the protocol could be used with other transports as well. diff --git a/content.mkd b/content.mkd index cf6b8f0..f6ab073 100644 --- a/content.mkd +++ b/content.mkd @@ -3,7 +3,7 @@ **(This document is in work and subject of ongoing modification.)** -WebDAV-Push is intended as a tool for WebDAV {{RFC4918}} clients to get notified about updates in collections in near time so that they can refresh their views, perform synchronization etc. +WebDAV-Push is intended as a tool for WebDAV {{RFC4918}} clients to get notified about updates in resources (usually collections) in near time so that they can refresh their views, perform synchronization etc. A client MUST NOT rely solely on WebDAV-Push, so it should also perform regular polling like when WebDAV-Push is not available. However if WebDAV-Push is available, the polling frequency can be significantly reduced. @@ -13,7 +13,7 @@ Typical use cases: - A desktop file manager shows contents of a WebDAV collection and wants to be notified on updates in order to refresh the view. - A calendar Web app shows a CalDAV collection and wants to be notified on updates in order to refresh the view. -[^todo]: TODO +[^todo]: TO BE DONE ## Notational Conventions @@ -43,31 +43,31 @@ Typical use cases: A WebDAV-Push server needs to - advertise WebDAV-Push and relevant information (service detection), -- manage subscriptions to collections, and -- send push messages when a subscribed collection changes. +- manage subscriptions to resources (usually collections), and +- send push messages when a subscribed resource changes. In order to manage subscriptions, a WebDAV server needs to -- provide a way for clients to subscribe to a collection (with transport-specific information), -- provide a way for clients to unsubscribe from collections, and +- provide a way for clients to subscribe to a resource (with transport-specific information), +- provide a way for clients to unsubscribe from a resource, and - handle expired or otherwise invalid subscriptions. -Notifications about updates in collections have to be sent to all subscribed clients over the respective push transports. +Notifications about updated resources have to be sent to all subscribed clients over the respective push transports. A WebDAV-Push client typically - detects whether the server supports WebDAV-Push and which push transports, - connects to a push service (which is usually not operated by the same party as the WebDAV server), -- subscribes to one or more collections on the server (providing push service-specific details), +- subscribes to one or more resources on the server (with the data received from the push service), - receives push notifications that cause some client-side action (like to refresh the view or run synchronization), -- re-subscribes to collections before the subscriptions expire, -- unsubscribes from collections when notifications are not needed anymore. +- re-subscribes to resources before the registrations expire, +- unsubscribes from resources when notifications are not needed anymore. WebDAV-Push is not restricted to a specific push transport. This allows even upcoming, yet unknown push transports to be used with WebDAV-Push. Push transport definitions can define extra properties and additional processing rules. WebDAV-Push implementations SHOULD implement at least the Web Push transport (defined in {{transport-web-push}}). If possible, other push transports SHOULD be connected over a Web Push gateway instead of defining a new WebDAV-Push transport. -To use proprietary push services, client vendors may need to provide a rewrite proxy that offers a Web Push endpoint which signs and forwards the requests to the respective proprietary service. If possible, VAPID should be used instead of such proxies. +To use a proprietary push service, a client vendor may need to provide a rewrite proxy that offers a Web Push endpoint which signs and forwards the requests to the respective proprietary service. If possible, VAPID should be used instead of such a proxy. ## Terminology @@ -78,7 +78,7 @@ Push notification : push message or delivery of a push message Push message -: Actual network message that is sent from the server over a push transport to the client. Notifies the client that a specific collection (identified by its push topic) has changed. +: Actual network message that is sent from the server over a push transport to the client. Notifies the client that a specific resource (identified by its push topic) has changed. In Web Push context, a WebDAV-Push server can send a push message (more exact, "request delivery of a push message") over the push service by `POST`ing the message to the client's subscription URL. @@ -93,7 +93,7 @@ Push service If the transport is Web Push, the term "(push) subscription (URL)" as used in this document is equivalent to the Web Push term "push resource". (Push) topic -: Character sequence that identifies a WebDAV collection for push purposes (unique per WebDAV server). A specific collection could be reachable at different URLs, but it can only have one push topic. +: Character sequence that identifies a WebDAV resource for push purposes (unique per WebDAV server). A specific resource could be reachable at different URLs, but it can only have one push topic. (Push) transport : Protocol that defines an actual push mechanism. In this document, Web Push is the only defined push transport (see {{transport-web-push}}). However, WebDAV-Push may also be used with other push transports like proprietary or yet unknown protocols. In that case, it has to be specified how to use that protocol with WebDAV-Push. A push transport typically involves a push service. @@ -109,7 +109,7 @@ Web Push There are also additional standards that can be considered to belong to Web Push, especially VAPID ({{RFC8292}}) and Message Encryption ({{RFC8291}}). WebDAV-Push -: WebDAV-based protocol to notify clients about updates in collections using a push transport (vs. polling). Specified in this document. +: WebDAV-based protocol to notify clients about updates in resource using a push transport (in contrast to polling). Specified in this document. (WebDAV-Push) client : WebDAV client that supports WebDAV-Push, for instance a CalDAV/CardDAV app on a mobile device @@ -139,20 +139,20 @@ Content-Length: 0 Here, the OPTIONS response contains "webdav-push" in the DAV header to indicate that the resource supports the properties and operations defined in this document. -## Collection Properties {#collection-properties} +## Push Properties {#push-properties} -To provide information about WebDAV-Push support, new properties are defined. A WebDAV-Push server MUST provide the `transports`, `topic` and `supported-triggers` properties for collections that support WebDAV-Push. +To provide information about WebDAV-Push support, new properties are defined. A server MUST provide the `transports`, `topic` and `supported-triggers` properties for resources that support WebDAV-Push. A server MUST NOT provide the `topic` and `supported-triggers` properties for resources that don't support WebDAV-Push (for instance for non-collection resources, if they're not supported). -The `transports` element lists available push transports. Although the property is defined on every collection, its value is usually the same for every collection on the server. Within the scope of this document, the only supported transport is `web-push` (see {{transport-web-push}}). +The `transports` element lists available push transports. Within the scope of this document, the only supported transport is `web-push` (see {{transport-web-push}}). Although the property is defined on every Push-capable resource, its value is usually the same for every resource on the server. -The `topic` is a globally unique identifier for the collection. A specific collection could be reachable at different URLs, but it can only have one push topic. A server could for instance use a server-internal ID that is not going to change or a random UUID per collection. +The `topic` is a globally unique identifier for the resource. A specific resource could be reachable with different URLs, but it can have only one push topic. A server could for instance use a random UUID or a canonical URL that won't change over the lifetime of the resource. The value should be globally unique because a client can subscribe to resources from multiple servers and needs to be able to determine the correct one when it receives a push message. -The `supported-triggers` element contains at least one of the following elements: +The `supported-triggers` element MUST contain at least one of the following elements: -- `content-update` if the collection supports push notifications on content updates ({{content-updates}}). It contains a `{DAV:}sync-level` property that indicates the maximum supported depth. -- `property-update` if the collection supports push notifications on property updates ({{property-updates}}). It contains a `{DAV:}depth` property that indicates the maximum supported depth. +- `content-update` if the resource supports push notifications on content updates (see {{content-updates}}). It contains a `{DAV:}depth` property that indicates the maximum supported depth. +- `property-update` if the resource supports push notifications on property updates (see {{property-updates}}). It contains a `{DAV:}depth` property that indicates the maximum supported depth. -Clients can use WebDAV `PROPFIND` to retrieve these properties. +Clients can use WebDAV `PROPFIND` to retrieve these properties. WebDAV-Push SHOULD only be advertised to clients which are actually allowed to use it. Example: @@ -172,7 +172,7 @@ HTTP/1.1 207 Multi-Status {::include xml/sample-propfind-multistatus.xml} ~~~ -In this case, the requested collection supports WebDAV-Push in general (because it has a push topic). It supports the Web Push transport. Push notifications can be requested on content updates of internal members and on property updates of the collection itself. +In this case, the queried collection supports WebDAV-Push in general and thus has a push topic. It supports the Web Push transport and provides a VAPID public key. Push notifications are supported for content updates of internal members and on property updates of the collection itself. The comment shows how support for some other (not yet defined) transport could be advertised together with additional specific information that is required to use it. @@ -180,55 +180,65 @@ The comment shows how support for some other (not yet defined) transport could b # Subscription Management -WebDAV-Push SHOULD only be advertised to clients which are actually allowed to use it. - - ## Subscription Registration -To subscribe to a collection, the client sends a `POST` request with `Content-Type: application/xml` to the collection it wants to subscribe. The root XML element of the XML body is `push-register` and can be used to distinguish between WebDAV-Push and other requests. +To subscribe to a resource, the client sends a `POST` request with `Content-Type: application/xml` to the resource it wants to subscribe. The root XML element of the XML body is `push-register` and can be used to distinguish between WebDAV-Push and other requests. The `push-register` element contains: * exactly one `subscription` element, which contains all information the server needs to send a push message, -* exactly one `trigger` element to specify the types of events the client wants to be notified about, and +* exactly one `trigger` element to specify the type of updates the client wants to be notified about, and * an optional `expires` element that contains the requested expiration time in the `IMF-fixdate` format (as defined in {{Section 5.6.7 of RFC9110}}). The `subscription` element specifies a subscription that shall be notified on updates and contains exactly one element with details about a specific subscription type. Within the scope of this document, only the `web-push-subscription` child element is defined (see {{transport-web-push}}). To specify which updates the client wants to be notified about, it uses the `trigger` element, which itself can contain: -* A `content-update` element to indicate the client's interest in notifications when the members of the collection change (_content update_). -* A `property-update` element to indicate the client's interest in notifications when the WebDAV properties of the collection change (_property update_). +* A `content-update` element to indicate the client's interest in notifications when the contents of the subscribed resource or its members change ("content update"). +* A `property-update` element to indicate the client's interest in notifications when the WebDAV properties of the subscribed resource or its members change ("property update"). -WebDAV-Push is intended more as a helpful tool to speed up things (like synchronization) than a strict query processor. So subscriptions are processed in a relaxed way: the server does its best to fulfill the request, but if a certain trigger is not available, it's downgraded or ignored instead of rejected with an error response. If a client needs to know which triggers are supported, it can use `PROPFIND` with `supported-triggers`. +WebDAV-Push is intended more as a helpful tool to speed up things (like synchronization) than a strict query processor. So subscriptions are processed in a relaxed way: the server does its best to fulfill the request, but if a certain trigger is not available, it's downgraded or ignored instead of rejected with an error response. If a client needs to know which triggers are supported, it can use `PROPFIND` with `supported-triggers`. A client MUST expect the server to downgrade or ignore certain triggers when they're not (fully) supported, and MUST be prepared to receive an error when it registers a subscription with only unsupported triggers. ### Content Updates {#content-updates} -A _content update_ occurs when a member is changed or removed, as defined in {{Section 3.5 of RFC6578}} (typically when a member is added or removed or its contents are modified). If the server supports {{RFC6578}}, a content update implies that the `{DAV:}sync-token` changes. +A "content update" occurs when the subscribed resource or a member is changed or removed, as defined in {{Section 3.5 of RFC6578}}. Typically, this is the case when the resource itself is modified or removed, or when a member is added or removed or its contents are modified. If the server supports {{RFC6578}}, a content update of a collection usually implies that the `{DAV:}sync-token` changes. + +The `content` element contains a `{DAV:}depth` element that specifies whether the client is interested + +- only in content updates of the subscribed resource (depth: `0`), +- only in content updates of the subscribed resource and its internal members (depth: `1`), or +- in content updates of the subscribed resource and its members (depth: `infinite`). -The `content` element contains a `{DAV:}sync-level` element that specifies whether the client is interested only in changes of internal members (value: `1`) or of all members (value: `infinite`). +A content update of a collection itself (not of a member) only occurs when the collection has an entity body that is returned by `GET` and that body changes. A server MAY ignore such changes and not send notifications in that case. -A server SHOULD support content update notifications with a `{DAV:}sync-level` of at least `1` for every Push-capable collection. If a collection doesn't support the content update trigger with the requested `{DAV:}sync-level`, it MUST fall back to the lowest supported value instead. If the collection doesn't support the content update trigger at all, it MUST be ignored. +A server SHOULD support content update notifications with a depth of at least `1` for every Push-capable collection. -In case the `{DAV:sync-level}` is `infinite`, the limitations described in {{Section 3.3 of RFC6578}} apply: notifications about changes in members which are not supported by the `DAV:sync-collection` report may not be sent. +If the subscribed resource doesn't support the content update trigger with the requested depth, the server MUST fall back to the lowest supported value instead. If the content update trigger isn't supported for the subscribed resource at all, it MUST be ignored. + +In case the depth is `infinite`, the limitations described in {{Section 3.3 of RFC6578}} apply: notifications about changes in members which are not supported by the `DAV:sync-collection` report may not be sent. ### Property Updates {#property-updates} -A _property update_ occurs when the WebDAV properties of the collection or its members are modified. Notifications about properties update are controlled by two elements within `properties`: +A "property update" occurs when the WebDAV properties of the subscribed resource or its members are modified. Properties update notifications are controlled by two elements within the `property-update` element: + +1. The `{DAV:}depth` element specifies whether the client is interested + + - only in property updates of the subscribed resource (depth: `0`), + - only in property updates of the subscribed resource and its internal members (depth: `1`), or + - in property updates of the subscribed resource and its members (depth: `infinite`). -1. The `{DAV:}depth` element (as defined in {{Section 10.2 of RFC4918}}) specifies the depth: +If the subscribed resource doesn't support the content update trigger with the requested depth, the server MUST fall back to the lowest supported value instead. If the content update trigger isn't supported for the subscribed resource at all, it MUST be ignored. - * A depth of `0` means that the client is only interested in property updates of the subscribed collection itself. - * A depth of `1` means that the client is interested in property updates of the subscribed collection and its internal members. - * A depth of `infinite` means that the client is interested in property updates of the subscribed collection and all its members. + In case the depth is `infinite`, the limitations described in {{Section 3.3 of RFC6578}} apply: notifications about changes in members which are not supported by the `DAV:sync-collection` report may not be sent. - If the collection doesn't support the property update trigger with the requested `{DAV:}depth`, it MUST fall back to the lowest supported value instead. If the collection doesn't support the property update trigger at all, it MUST be ignored. +2. The optional `{DAV:}prop` element (as used in a `PROPFIND` request) specifies a list of properties that the client is interested in. - In case the `{DAV:}depth` is `infinite`, the limitations described in {{Section 3.3 of RFC6578}} apply: notifications about changes in members which are not supported by the `DAV:sync-collection` report may not be sent. + If the `{DAV:}prop` element is empty or not present, the server chooses a list of properties that it considers to be useful for the client. If the `{DAV:}prop` element is present and contains properties for which property update notifications are not supported, the server MUST ignore those unsupported properties. Also, a server MAY ignore the contents of a `{DAV:prop}` element at all and treat it like if it was empty or not present. -2. The optional `{DAV:}prop` element (as used in a `PROPFIND` request) specifies a list of properties that the client is interested in. This list of properties MUST NOT contain properties that represent a content update, especially `{DAV:}getetag`, `{DAV:}getlastmodified` and `{DAV:}sync-token`. If the `{DAV:}prop` element is present and contains properties for which property update notifications are not supported, the server MUST ignore those unsupported properties. + Neither a server nor a client SHOULD use property update notifications for properties that automatically change on a content update, like `{DAV:}getetag`, `{DAV:}getlastmodified` and `{DAV:}sync-token`, because this would implicitly cause a property update for every content update. Notifications about content updates should instead be requested/sent explicitly as content update notifications. + +The removal of a resource, including the subscribed resource, is not considered as a property update but as a content update. - If the `{DAV:}prop` element is empty or not present, the server chooses a list of properties that it considers to be useful for the client. Also, a server MAY ignore the contents of a `{DAV:prop}` element at all and treat it like if it was empty or not present. ### Response @@ -237,7 +247,7 @@ Allowed response codes: * 201 if the subscription was registered and the server wants to return additional information, like encryption details that are only valid for this subscription. The format of these details is specified by the respective transport definition. * 204 if the subscription was registered without additional information * 403 with precondition `invalid-subscription` when the request doesn't contain a valid `subscription` -* 403 with precondition `push-not-available` if WebDAV-Push is not available for this collection or if the user is not allowed to register a push subscription for it +* 403 with precondition `push-not-available` if WebDAV-Push is not available for this resource or if the user is not allowed to register a push subscription for it * 403 with precondition `no-supported-trigger` when the request doesn't contain a trigger or when all requested triggers are ignored (because they're not supported) * other response code with usual HTTP/WebDAV semantics @@ -259,23 +269,23 @@ Location: https://example.com/webdav/subscriptions/io6Efei4ooph Expires: Wed, 02 Oct 2024 07:28:00 GMT ~~~ -Example 2: If a client registers a content update trigger with a `{DAV:}sync-level` of `infinite` and a property update trigger with a `{DAV:}depth` of `1`, but the collection supports only content update triggers with a `{DAV:}sync-level` of `1` and doesn't support the property update trigger at all, it registers the subscription and responds with 201. Notifications will then only be sent on content updates with a `{DAV:}sync-level` of `1` (trigger downgraded by server). On property updates, notifications will not be sent (trigger ignored by server). +Example 2: A client registers a content update trigger with a depth of `infinite` and a property update trigger with a depth of `1`, but the collection supports only content update triggers with a depth of `1` and doesn't support the property update trigger at all, it registers the subscription and responds with 201. Notifications will then only be sent on content updates with a depth of `1` (trigger downgraded by server). On property updates, notifications will not be sent (trigger ignored by server). -Example 3: If a client registers a property update trigger with a `{DAV:}depth` of `0` and the collection doesn't support property update triggers at all, the server ignores the trigger. So all triggers of the request are ignored and the server responds with 403 with `no-supported-trigger`. +Example 3: A client registers a property update trigger with a depth of `0` and the collection doesn't support property update triggers at all, the server ignores the trigger. So all triggers of the request are ignored and the server responds with 403 with `no-supported-trigger`. ## Subscription Updates Every subscription has an identifier that uniquely identifies the (push transport, push service, client) triple. For Web Push, the identifier is the push resource URI. -A server MUST NOT register a subscription with the same identifier multiple times. Instead, when a client wants to register a subscription with an identifier that is already registered for the requested collection, the server MUST update the subscription with the given details and the expiration date. +A server MUST NOT register a subscription with the same identifier multiple times. Instead, when a client wants to register a subscription with an identifier that is already registered for the requested resource, the server MUST update the subscription with the given details and the expiration date. The response is the same as for subscription registration. ## Subscription Removal -A client can explicitly unsubscribe from a collection by sending a `DELETE` request to the previously acquired registration URL. +A client can explicitly unsubscribe from a resource by sending a `DELETE` request to the previously acquired registration URL. Allowed response codes: @@ -283,8 +293,6 @@ Allowed response codes: * 404 if the registration URL is unknown (or expired). * other response code with usual HTTP/WebDAV semantics -When a subscription registration is removed, no further push messages must be sent to the subscription. - Sample request: ~~~ @@ -308,15 +316,15 @@ Expired subscriptions MUST NOT be used anymore as chances are high that doing so # Push Notification -A WebDAV-Push server MUST notify registered subscriptions of a subscribed collection: +A WebDAV-Push server MUST notify registered subscriptions of a subscribed resource: -- on a _content update_ of the collection, if this was requested during subscription registration, -- on a _property update_ of the collection, if this was requested during subscription registration. +- on a _content update_, if this was requested during subscription registration, +- on a _property update_, if this was requested during subscription registration. ## Push Message -The push message body consists of a `push-message` element, which contains information about the affected collection: +The push message body consists of a `push-message` element, which contains information about the affected resource: - a `topic` element with the push topic, - a `content-update` element in case of a content update, and/or @@ -330,15 +338,15 @@ Example: {::include xml/sample-push-message.xml} ~~~ -Here, both the contents and the properties of the collection with topic `O7M1nQ7cKkKTKsoS_j6Z3w` have changed. The new sync-token (after the change) is `http://example.com/sync/10`. +Here, both the contents and the properties of the resource (or its members, depending on the registered trigger) with topic `O7M1nQ7cKkKTKsoS_j6Z3w` have changed. The new sync-token (after the change) is `http://example.com/sync/10`. When necessary or useful, a server MAY * impose a rate limit for push messages, -* delay push messages for a short time, -* omit/merge push messages. +* delay push messages (usually for a short time, for instance to avoid multiple push messages for ongoing changes in the user interface), +* merge/omit push messages. -The server MUST ensure that such measures don't change the overall meaning of the push notifications so that the client can still perform its desired action. For instance, of a series of push messages that contain only content updates and occur shortly after each other, all but the last message can be omitted. If one of the push messages signals a property update, it can't be just omitted because the client then wouldn't know that a property update happened. +Such measures SHOULD not change the overall meaning of the push notifications so that the client can still perform its desired action. For instance, of a series of push messages that contain only content updates and occur shortly after each other, all but the last message can be omitted. If one of the push messages signals a property update, it can't be just omitted because the client then wouldn't know that a property update happened. ## Removal of Invalid Subscriptions @@ -347,31 +355,24 @@ A WebDAV-Push server MUST ensure that invalid subscriptions (encountered when tr An invalid subscription is a subscription that push notifications can't be delivered to. Usually the push service returns an HTTP error code like 404 when it receives a notification for an invalid subscription. There may also be other conditions that render a subscription invalid, like a non-resolvable hostname or an encryption handshake error. -A server MAY use some logic like remembering the last successful delivery plus some tolerance interval to defer removal of an invalid subscription for some time. Doing so will make WebDAV-Push more reliable in case of temporary problems and avoid temporal "holes" between subscription removal and re-registration. - - - -# Interoperability - -## Client Guidelines +A server MAY use some logic like remembering the last successful delivery plus some tolerance interval to defer removal of an invalid subscription. Doing so will make WebDAV-Push more reliable in case of temporary problems and avoid temporal "holes" between subscription removal and re-registration. -Before registering a subscription, a client SHOULD check whether the transport is supported and which triggers are supported (usually with the same `PROPFIND` request that requests details like the VAPID public key). The client MUST expect the server to downgrade or ignore certain triggers when they're not (fully) supported. The client MUST be prepared to receive an error when it registers a subscription with only unsupported triggers. -## CalDAV/CardDAV +# CalDAV/CardDAV WebDAV-Push can be used with CalDAV ({{RFC4791}}) and CardDAV ({{RFC6352}}) to provide short-time update notifications when collections (calendars, address books) or entries (contacts, events, …) change. Depending on the features of a CalDAV/CardDAV client, it could for instance subscribe to: - content updates of a home-set to become notified about new collections, -- content updates of a collection (usually with a sync-level of 1) to become notified about modified entries, -- property updates of a collection (usually with a depth of zero) to become notified about changes of properties like display name, calendar color and access permissions, +- content updates of a collection (usually with a depth of `1`) to become notified about modified entries, +- property updates of a collection (usually with a depth of `0`) to become notified about changes of properties like display name, calendar color and access permissions, - property updates (for instance display name) of a principal to update real names of collection owners. CalDAV/CardDAV servers that support WebDAV-Push SHOULD support: -- content updates with a `{DAV:}sync-level` of at least 1 on +- content updates with a `{DAV:}depth` of at least 1 on - `calendar-home-set` and `addressbook-home-set` collections, - calendars and address books (collections which have a `{DAV:}resourcetype` of `{CALDAV:}calendar` or `{CARDDAV:}addressbook`), - scheduling inbox and outbox collections (collections which have a `{DAV:}resourcetype` of `{CALDAV:}schedule-inbox` or `{CALDAV:}schedule-outbox` as defined in {{Section 2 of RFC6638}}); @@ -387,7 +388,7 @@ The general requirements from {{Section 8 of RFC8030}} apply regardless of which - HTTP over TLS MUST be used for all communications. - Mechanisms that provide end-to-end confidentiality, integrity and data origin authentication MUST be used. -Push services could relate clients over metadata and heuristics. For instance, clients which are at the same time notified by a specific WebDAV-Push server have probably subscribed the same collection. +Push services could relate clients over metadata and heuristics. For instance, clients which are at the same time notified by a specific WebDAV-Push server have probably subscribed the same resource. See RFC 3552 and RFC 6973 [^todo] @@ -456,7 +457,7 @@ It contains exactly one `push-resource` element, which contains an absolute URI VAPID binds push subscriptions to the specific WebDAV-Push server. -A WebDAV-Push server which supports VAPID stores a key pair. The server exposes an additional transport property `vapid-public-key` (within the `web-push` element), which contains the VAPID public key in uncompressed form and base64url encoded. Its attribute `type="p256ecdsa"` MUST be added to allow different key types in the future. See {{collection-properties}} for an example. +A WebDAV-Push server which supports VAPID stores a key pair. The server exposes an additional transport property `vapid-public-key` (within the `web-push` element), which contains the VAPID public key in uncompressed form and base64url encoded. Its attribute `type="p256ecdsa"` MUST be added to allow different key types in the future. See {{push-properties}} for an example. If available, the client SHOULD use this key to create a restricted subscription at the push service. diff --git a/xml/sample-propfind-multistatus.xml b/xml/sample-propfind-multistatus.xml index 17e4659..b535fcc 100644 --- a/xml/sample-propfind-multistatus.xml +++ b/xml/sample-propfind-multistatus.xml @@ -15,7 +15,7 @@ O7M1nQ7cKkKTKsoS_j6Z3w - 1 + 1 0 diff --git a/xml/sample-push-register.xml b/xml/sample-push-register.xml index 6f0d395..9743467 100644 --- a/xml/sample-push-register.xml +++ b/xml/sample-push-register.xml @@ -9,7 +9,7 @@ - infinite + infinite 0 diff --git a/xml/webdav-push.rng b/xml/webdav-push.rng index 0f69f71..31e5e93 100644 --- a/xml/webdav-push.rng +++ b/xml/webdav-push.rng @@ -21,7 +21,7 @@ - + @@ -49,7 +49,7 @@ - + @@ -216,15 +216,6 @@ - - - - 1 - infinite - - - -