Re: [Webpush] Spencer Dawkins' No Objection on draft-ietf-webpush-protocol-11: (with COMMENT)

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Brian,

Thanks for the helpful explanation, and thanks for considering my comments.

Spencer

On Oct 12, 2016 23:02, "Brian Raymor" <[e-mail]> wrote:
>
>
> Hi Spencer,
>
> > I noticed that
> >
> >  push message subscription:  This resource provides read and delete
> >     access for a message subscription.  A user agent receives push
> >      messages (Section 6) using a push message subscription.  Every
> >     push message subscription has exactly one push resource associated
> >     with it.
>
> > and
>
> >   push message:  The push service creates a push message resource to
> >      identify push messages that have been accepted for delivery
> >      (Section 5).  The push message resource is also deleted by the
> >      user agent to acknowledge receipt (Section 6.2) of a push message.
>
> > don't say "A link relation of type ..." about the resource being
defined,
> > but
>
> >   push message subscription set:  This resource provides read and
> >      delete access for a collection of push message subscriptions.  A
> >     user agent receives push messages (Section 6.1) for all the push
> >      message subscriptions in the set.  A link relation of type
> >      "urn:ietf:params:push:set" identifies a push message subscription
> >      set.
>
> >   push:  An application server requests the delivery (Section 5) of a
> >      push message using a push resource.  A link relation of type
> >      "urn:ietf:params:push" identifies a push resource.
>
> > and
>
> >   receipt subscription:  An application server receives delivery
> >      confirmations (Section 5.1) for push messages using a receipt
> >     subscription.  A link relation of type
> >      "urn:ietf:params:push:receipt" identifies a receipt subscription.
>
> > do. Is that intentional? Or would link relation indentification not be
> > useful for these resources (if you told me that, I'd believe you).
>
> It is intentional. Both the push message subscription and the push message
> resources are returned in the Location: header in the 201 (Created)
response
> and don't require a redundant link relation.
>
> For example:
>
> https://tools.ietf.org/html/draft-ietf-webpush-protocol-11#section-4
>
>    A 201 (Created) response indicates that the push subscription was
>    created.  A URI for the push message subscription resource that was
>    created in response to the request MUST be returned in the Location
>    header field.
>
> > I see that Topic: has no semantics, but I wonder if the example use of
> > Topic in Section 5.4 might be clearer if a different Topic was used -
> > "Topic: upd" looks like "upd" would have semantic meaning, on first
> > reading.
>
> I'm open to suggestions, but I don't know that a change would enhance
> clarity.
>
> > I wondered why the use of subscription sets in
>
> >   There are minor differences between receiving push messages for a
> >   subscription and a subscription set.  If a subscription set is
> >   available, the user agent SHOULD use the subscription set to monitor
> >   for push messages rather than individual push message subscriptions.
>
> > was a SHOULD, and not a MUST. Is this just an efficiency thing, or is it
> > something else? It would be helpful to explain this.
>
> Subscription sets evolved over time as we explored appropriate models
> such as "push service decides" or "user agent decides". In the end, we
needed to
> ensure that the subscription set design was flexible enough to address a
> broad range of scenarios, including a late-breaking one from Canon:
>
> https://www.ietf.org/mail-archive/web/webpush/current/msg00357.html
>
> which resulted in "user agent decides" + "push service encourages".
>
> Subscription sets are included for efficiency as described:
>
>     https://tools.ietf.org/html/draft-ietf-webpush-protocol-11#section-4.1
>
>    Collecting multiple push message subscriptions into a subscription
>    set can represent a significant efficiency improvement for push
>    services and user agents.  The push service MAY provide a URI for a
>    subscription set resource in a link relation of type
>    "urn:ietf:params:push:set".
>
>    When a subscription set is returned in a push message subscription
>    response, the user agent SHOULD include this subscription set in a
>    link relation of type "urn:ietf:params:push:set" in subsequent
>    requests to create new push message subscriptions.
>
> This was added for Herve's scenario:
>
>    A user agent MAY omit the subscription set if it is unable to receive
>    push messages in an aggregated way for the lifetime of the
>    subscription.  This might be necessary if the user agent is
>    monitoring subscriptions on behalf of other push message receivers.
>
> > Is there any guidance you could give about the retry mechanism described
> > in this text? How many times, how often, etc.
>
> >   If the push service does not receive the acknowledgement within a
> >   reasonable amount of time, then the message is considered to be not
> >   yet delivered.  The push service SHOULD continue to retry delivery of
> >   the message until its advertised expiration.
>
> There's no general guidance. The policy would be specific to a push
service.
>
> > I'm guessing that
>
> >   A push service that does not support reliable delivery over
> >   intermittent network connections or failing applications on devices,
> >   forces the device to acknowledge receipt directly to the application
> >   server, incurring additional power drain in order to establish
> >   (usually secure) connections to the individual application servers.
>
> > isn't just about "establish", but "establish and maintain"?
>
> That would be more precise. Updating.
>
>