Re: [Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT)

[Brian Raymor <[e-mail]>]

Hi Stephen,

>> And our experience is that developers are consuming all the related
>> drafts. We had some new members during WGLC who demonstrated
>> this point with their contributions.

>> So doesn't that argue to make the relevant drafts normative
>> references? That's not meant to be a blocking comment btw,
>> I'm ok with the RFC having those as informative (modulo my
>> last question below) but think it'd be better if they were
>> normative.

Not at all - and frankly that would subvert consensus in the working group.
We created vapid and message encryption as separate drafts because they’re optional.
The normative references occur in the W3C Push API. For WebPush,
the other drafts demonstrate one approach that might not be appropriate
for other scenarios but are included for awareness.

As I wrote in an earlier response:

  WebPush includes informative references to vapid and message encryption as 
  examples. In response to comments from Ben Campbell during the review, Martin
  created a pull request which clarifies this:

  https://github.com/webpush-wg/webpush-protocol/pull/138/files

  The consensus in the working group was that other implementations/scenarios outside
  the browser (such as IoT) would pursue their own approaches to address the requirements.

> I've just one last thing to ask before we're done:

> Do we envisage anyone ever using this push service mechanism
> without the content of the message being as defined in the
> webpush encryption draft and without following the W3C API?

Absolutely. As I wrote in an earlier response:

  WebPush is similar to WebSockets in the sense that there's a related API under
  development at the W3C. I'd note that RFC6455 uses an informative reference
  to the W3C WSAPI. The expectation is that there will be multiple API surfaces for
  WebPush similar to the situation for WebSockets.

For example, one co-author (Elio) has scenarios in the IoT space. No browser involved.

> If we do, and if that content ends up in a browser or other
> application that needs the SOP or similar, then I'm still not
> sure it's ok to say nothing in this draft.

I'm not suggesting that there will be multiple API(s) in the browser-case.
The expectation is the web developers will use the W3C Push API or
a framework based on the Push API. SOP is very browser-specific and
there’s already a solution in this case. 

Cheers,
...Brian