Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00

[Martin Thomson <[e-mail]>]

If we take this path, it might be necessary to reverse the slots we use for
these two URIs, simply because we would now have a need to identify the
subscription in a request to a different resource (though we could avoid
that by making the subscription URI the target of a "create subscription"
request, it offers no option for the server to reject the proposed
grouping).

Note that the use of relative URIs was for economy only; the Location
header field requires absolute URIs though. Perhaps we should be more
explicit and use absolute everywhere to avoid risking confusion.
On Jul 23, 2015 12:22 AM, "Benjamin Bangert" <[e-mail]> wrote:

> Yea, that's what I figured on re-reading it. The reason I interpreted it
> differently is because the urn:ietf:params:push link is *relative*, while
> the Location is an absolute URI. In our current Push situation, the domain
> the UA connects to is a different subdomain than the domain used for
> app-servers to connect to, so a relative URL just seems wrong.
>
> I had assumed based on this, that the absolute URL then, would be the only
> reasonable thing to hand out to an appserver. Either way, it should work
> fine as I said if the private one is just the same for all subscriptions,
> or we tack on a new Link for receiving them that is the aggregation link
> that must be used if present.
>
> On Wed, Jul 22, 2015 at 2:44 PM, Darshak Thakore <[e-mail]>
> wrote:
>
>>   I think you have it backwards (maybe we need to be more explicit in
>> the spec). The Location link is the “private” link that the UA holds.
>> That’s the link to which the UA/client is going to make the request to for
>> getting the notifications  (Section 6 shows that the h2 GET is being done
>> by the UA/client to the "/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx"). The
>> “urn:ietf:params:push” link is the one that is distributed to the
>> application servers (along wit the /receipts/xxxx). The current spec
>> requires the UA/client to make separate GET’s to the URI provided in the
>> Location field (albeit it can be done on the same h2 connection). By
>> linking the subscriptions to the primary subscription, the UA/client can
>> make a single h2 GET request to primary subscription URI (the one returned
>> in the Location header of the primary subscription) and get notifications
>> for all subsequent subscriptions.
>>
>>
>>   On 7/22/15, 10:30 AM, "Benjamin Bangert" <[e-mail]> wrote:
>>
>>    On Wed, Jul 22, 2015 at 8:27 AM, Costin Manolache <[e-mail]>
>> wrote:
>>
>>>
>>>
>>> On Wed, Jul 22, 2015 at 1:25 AM, Darshak Thakore <
>>> [e-mail]> wrote:
>>>
>>>>  Comments below
>>>>
>>>>   On 7/21/15, 6:48 PM, "Costin Manolache" <[e-mail]> wrote:
>>>>
>>>>   I think one question is who makes the decision if subscrptions are
>>>> 'aggregated' or not. And the only answer
>>>> I know is the push provider - since the push provider is the one
>>>> bearing the costs and defining the
>>>> requirements for UAs that connect to it.
>>>>
>>>>
>>>>  DT>> As I mentioned in the other email (Benjamin’s email), I’m not
>>>> sure how a PS can force a UA to aggregate (unless the PS somehow identifies
>>>> the client based on authentication/cookie/something-else).
>>>>
>>>
>>>  In aggregate model, there is a registration (or subscription) for the
>>> UA, and each origin/serviceworker have a subscription associated with the
>>> UA.
>>>
>>>  The PS can simply reject subscriptions that don't have an associated
>>> parent, and not deliver the the registration/root. Than the UA
>>> may chose a different PS, or aggregate.
>>>
>>>  Or: terms of service and abuse detection on PS.
>>>
>>>  There was a thread about PS returning a URL that may require
>>> additional user interaction when the UA registers with the PS,
>>> and may have separate relation ( like Setup Wizard in android ). For
>>> example GCM attempts to determine device type, if it is rooted, etc.
>>>
>>>  I don't think the expectation is that a PS MUST accept arbitrary UAs,
>>> free and without any checks or rules.
>>>
>>
>>  I'm associating one h2 connection as being one UA, and treating the
>> first Subscribe operation, or the first Receive Push Messages operation as
>> the registration. Also, I am perhaps misreading the spec in which URL is
>> given out to whom, now that I think about it. In Sec 3, the Subscribe
>> response is such:
>>
>> HTTP/1.1 201 Created
>> Date: Thu, 11 Dec 2014 23:56:52 GMT
>> Link: </p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
>>         rel="urn:ietf:params:push"
>> Link: </receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ>;
>>         rel="urn:ietf:params:push:receipt"
>> Location: https://push.example.net/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx
>> Cache-Control <https://push.example.net/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibxCache-Control>: max-age:864000, private
>>
>> My thought was that the Location link is the one given to the AppServers,
>> and the urn:ietf:params:push link is the 'private URL' that the UA uses to
>> receive push messages. This way, after the initial Subscribe, the PS has
>> associated that h2 connection with the private URL, and new Subscribe
>> requests will return new Location links to give to the AppServer. It also
>> means the UA would need to store the Location for each Subscribe, since the
>> private URL would be unchanging for all later Subscribe requests.
>>
>>
>>  On reconnect, receiving push messages by hitting the private URL would
>> then associate the h2 connection again, acting as the registration.
>>
>>  If a UA wants to operate independent batches of subscriptions, as the
>> IoT use-case previously cited, it must use entirely separate h2 connections
>> for each batch.
>>
>>  The spec includes a Location without identifying its actual use, as my
>> reading of it seems unclear on if the Link is the one given to the
>> AppServer, or if its the Location.
>>
>>  This presumes that there is no h2 proxying such that individual
>> requests over the same connection might be on behalf of different UA's. (I
>> really really don't like the thought of an h2 proxy of this nature, because
>> it means it could lie about whether a client is still actually 'alive' to
>> ping frames, and that's given us enough grief with mobile TCP proxies).
>>
>>  In this manner, the PS could choose whether to give the same private
>> URL back for all Subscribe requests over the same connection, or not. The
>> additional requirements on the UA:
>> - It must store the Location, since that's the guaranteed unique part
>> - If it gets the same private URL back, it should only use the Receive
>> operation once, and realize all new push messages will come over the
>> existing GET
>>  - On reconnect, it MUST send the Receive operation before any new
>> Subscribe operations (since that's treated as 'registration' on reconnect)
>>
>>  This way a PS gets to choose, and the associating link is the push link
>> itself. If the thought was that the push Link is the one sent to
>> AppServers, then some of this will need a bit of changing of course.
>>
>>
>>
>>>
>>>
>>>>  I think the PS should/must support it but it would be the client/UA’s
>>>> decision to aggregate. We can put language to “strongly recommend” the
>>>> client/UA to aggregate but it would still be the client’s decision to
>>>> include the initial subscription when making subsequent subscription
>>>> requests.
>>>>
>>>
>>>>
>>>>  If we agree that a push provider may require 'aggregation' - all
>>>> subscriptions from a device, when connecting
>>>> to such a provider, will need to have something in common, to allow the
>>>> aggregation. The original
>>>>  "registration + subscription" does it by having a first step where a
>>>> device gets the common element.
>>>> It can be simplified by defining the 'registration' as a regular
>>>> subscription, and allowing each app to
>>>>  have a 'child' subscription. This works nicely if a UA supports
>>>> profiles/multi-user for example - and may
>>>> be extended later for more complicated cases, where a UA acts as a
>>>> proxy for other UAs ( for example
>>>> a wearable device paired over BT ).
>>>>
>>>>
>>>>  DT>> I think within the context of the fact that a client does want
>>>> to “aggregate”, all of the above is doable. However as I mentioned above,
>>>> if a client does not send the “parent subscription” info in the subsequent
>>>> subscription requests, there’s no easy way for a PS to force aggregation.
>>>>
>>>
>>>  I wouldn't be very worried about a small percentage of devices not
>>> aggregating - and anything large is usually detectable.
>>>
>>>
>>>  Costin
>>>
>>>
>>>>
>>>>  The subscription API should allow a way to create 'links' between
>>>> subscriptions. We do need to
>>>> finish the separate discussion on sender authentication and
>>>> registration - but assuming a push service
>>>> requires sender authentication, this is another 'link' between the app
>>>> subscription and the server id (
>>>> which can be another capability URL or subscription ).
>>>>
>>>>
>>>>  DT>> Yes, I believe that should be doable with the idea here.
>>>>
>>>>
>>>>  I don't think it's a problem if the 'non-aggregated' model - where
>>>> nothing is shared - is defined even as default,
>>>> and some push providers may chose to support both, or only one model,
>>>> depending on their scale and costs
>>>>
>>>>
>>>>  Costin
>>>>
>>>> On Tue, Jul 21, 2015 at 9:26 AM, Benjamin Bangert <[e-mail]
>>>> > wrote:
>>>>
>>>>>  My preference would be for the server to be able to require this,
>>>>> rather than leaving it up to the client. If a server doesn't want to expend
>>>>> the heavy resource cost of treating every single subscription as its own
>>>>> URL, there should be a way for the server to indicate that in its
>>>>> subscription response.
>>>>>
>>>>>  For an IoT use-case, where a client might want different sets of
>>>>> subscriptions entirely, and to only check one group of them, it could open
>>>>> a separate h2 connection to retrieve that set.
>>>>>
>>>>> On Mon, Jul 20, 2015 at 2:41 PM, Darshak Thakore <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>>
>>>>>> It seems like we do want some mechanism that allows a client to
>>>>>> retrieve
>>>>>> notifications for all subscriptions with a single fetch. For IoT
>>>>>> based use
>>>>>> cases also this is desirable. I guess this keeps going back to the
>>>>>> aggregation-vs-disaggregation discussion. However I¹m wondering if its
>>>>>> possible to define/create a sort of ³aggregation-on-demand² mode with
>>>>>> the
>>>>>> default being the current ³disaggregation² mode.
>>>>>>
>>>>>> For example, once a client/UA has subscribed for the first time and
>>>>>> holds
>>>>>> 1 subscription, when it wants to create subsequent subscriptions, it
>>>>>> can
>>>>>> include the first subscription in the request:
>>>>>>
>>>>>> POST /subscribe/ HTTP/1.1
>>>>>> HOST: push.example.net
>>>>>> Link: </s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx>;
>>>>>> rel=³urn:ietf:params:push:subcribe² (I¹m not sure if its ok to use
>>>>>> Link
>>>>>> header in a request, if not we need to find something more suitable)
>>>>>>
>>>>>> When a PS processes this request, it can associate the new
>>>>>> subscription
>>>>>> with the one provided. (I think the additional data stored by the PS
>>>>>> to
>>>>>> achieve this should be minimal). The response would contain the new
>>>>>> subscription info as currently defined (and maybe something
>>>>>> additional to
>>>>>> indicate that the new subscription is tied to the one in the request)
>>>>>>
>>>>>> When receiving PUSH messages, a client/UA can make a single GET
>>>>>> request to
>>>>>> the primary subscription resource and the server will send push
>>>>>> notifications for all subscriptions associated with the primary
>>>>>> subscription.
>>>>>>
>>>>>> For example, the request would be
>>>>>>
>>>>>> HEADERS         [stream 7] +EHD_STREAM +END_HEADERS
>>>>>>   :method       = GET
>>>>>>   :path         = /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx
>>>>>>   :authority    = push.example.net
>>>>>>
>>>>>> And the corresponding response would be
>>>>>>
>>>>>> PUSH_PROMISE    [stream 7; promised stream 4] +END_HEADERS
>>>>>>   :method       = GET
>>>>>>   :path         = /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk
>>>>>>   :authority    = push.example.net
>>>>>>
>>>>>> HEADERS         [stream 4] +END_HEADERS
>>>>>>   :status       = 200
>>>>>>   ‹‹OTHER HEADERS ‹‹
>>>>>>   :content-loc  = /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx
>>>>>>
>>>>>> DATA            [stream 4] +END_STREAM
>>>>>>      iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
>>>>>>
>>>>>>
>>>>>> PUSH_PROMISE    [stream 7; promised stream 6] +END_HEADERS
>>>>>>   :method               = GET
>>>>>>   :path                 = /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui
>>>>>>   :authority            = push.example.net
>>>>>>
>>>>>> HEADERS         [stream 6] +END_HEADERS
>>>>>>   :status       = 200
>>>>>>   ‹‹OTHER HEADERS ‹‹
>>>>>>   :content-loc  = /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW
>>>>>>
>>>>>> DATA            [stream 6] +END_STREAM
>>>>>> {encoded/encrypted-notification-message}
>>>>>>
>>>>>>
>>>>>> ‹‹ additional PUSH messages for other subscriptions ‹‹
>>>>>>
>>>>>>
>>>>>>
>>>>>> In the above example, the responses can include a Content-Location (or
>>>>>> some other appropriate) header to indicate the associated
>>>>>> subscription for
>>>>>> the notification message. This would allow the client/UA to send just
>>>>>> one
>>>>>> GET request to retrieve (and keep receiving) notifications on all its
>>>>>> active subscriptions. A client/UA may even choose to keep certain
>>>>>> subscriptions separate and group only a subset of them (this would be
>>>>>> useful in IoT like cases)
>>>>>>
>>>>>>
>>>>>> Darshak
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson"
>>>>>>  <[e-mail] on behalf of [e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>> >On 20 July 2015 at 09:21, Benjamin Bangert <[e-mail]>
>>>>>> wrote:
>>>>>> >> What's the use-case of a client polling over a long-lived
>>>>>> connection
>>>>>> >
>>>>>> >The use case is for a device that is only periodically online (a
>>>>>> >constrained device) that wants to check in, then immediately go
>>>>>> >offline again.
>>>>>> >
>>>>>>  >_______________________________________________
>>>>>> >Webpush mailing list
>>>>>> >[e-mail]
>>>>>> >https://www.ietf.org/mailman/listinfo/webpush
>>>>>>
>>>>>> _______________________________________________
>>>>>> Webpush mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/webpush
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Webpush mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/webpush
>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Webpush mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webpush
>
>