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

[Stephen Farrell <[e-mail]>]

Hiya,

We're nearly there...

On 18/10/16 05:14, Brian Raymor wrote:
> Hi Stephen,
> 
>> Saying that would've definitely helped me understand what's going on.
> 
> Sorry about that. It required a few iterations for us to understand, but we got there.
> 
>> Does something need to be stated in this draft? 
> 
> Martin and I have reviewed and are in agreement that
> further clarifications would not be helpful in the protocol draft.
> 
>> Or is it safe enough to assume that the
>> reader will also look at the API and encryption drafts,
>> and that people won't come up with other ways to handle
>> pushed messages that don't support good ways to
>> enforce the SOP?
> 
> Exactly. This is more relevant to the Push API / W3C which Martin
> is now tracking in https://github.com/w3c/push-api/issues/211. 
> 
> 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.

> 
> This was definitely a subtle discussion. We appreciate that your review
> called this out for consideration. 

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?

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.

If we do not, then it'd seem sensible to add a statement to
the effect that all these things are really a package and
it's not necessarily safe to just use this piece alone.

Cheers,
S.


> 
> ...Brian
>