Re: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)

[Phil Sorber <[e-mail]>]

For sure the first discuss item has already been addressed in the git repo
[1], and there is also a statement that the JSON is UTF-8 encoded now as
well. I'm not sure that really resolves the second point though. I'll let
the authors address that directly.

Martin, Peter, perhaps this is a good opportunity to push a new draft
before the telechat?

[1]
https://github.com/webpush-wg/webpush-vapid/compare/draft-ietf-webpush-vapid-03...master

On Tue, Aug 1, 2017 at 1:55 PM Alexey Melnikov <[e-mail]>
wrote:

> Alexey Melnikov has entered the following ballot position for
> draft-ietf-webpush-vapid-03: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> The following is a nit, but I think it is important that it gets fixed:
>
> In Section 4.1:
>
>    The example in Figure 3 shows a restriction to the key used in
>    Figure 1.  Extra whitespace is added to meet formatting constraints.
>
>    POST /subscribe/ HTTP/1.1
>    Host: push.example.net
>    Content-Type: application/webpush-optjons+json;charset=utf-8
>
> Firstly, "optjons" above should be "options". Secondly, the MIME type
> registration of application/webpush-options+json says that the MIME type
> has no
> parameters, yet you use charset above. So which is it?
>
>    Content-Length: 104
>
>    { "vapid": "BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH
>                F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> In Section 3, 3rd para:
>
>    This authentication scheme does not require a challenge.  Clients are
>    able to generate the Authorization header field without any
>    additional information from a server.  Therefore, a challenge for
>    this authentication scheme MUST NOT be sent in a WWW-Authenticate
>    header field.
>
> Does this mean that there is no way to discover whether a particular server
> supports "vapid" HTTP authentication scheme?
>
>
>