IETF 92 / Dallas Texas / 2015-Mar-23
Presenter: Elio Demaggio
See slides for summary of topic
No discussion ensued
Presenter: Martin Thomson
See slides for summary of topic
The question is: should we keep the aggregation behavior described in draft-thomson, or is the simplicity of eliminating the registration step worth the trade-offs?
Costin: Slight preference for aggregation, because it's cheaper to scale
Harald Alvestrand: In the disaggregated model, the token identifying the subscription and where to push is the same, right?
Martin: That's a separable issue.
Harald: If they're the same, and there's no other authorization for reading, then anyone who can push messages to me can also read my messages.
Martin: Good point. If we go with disaggregation, then we need to make a decision on that front. That's the next topic.
Robby Simpson: It seems that the push in the aggregated model would be a push of a lot of things I'm interested in.
Martin: When a push client indicates a resource change, the aggregated model only sends the changed information, not some monolithic document representing all of the subscriptions.
Joe Hildebrand: Is this a decision we must make now, or can we defer it?
Martin: I think we need to know now.
Elio: If you consider reliability, then the push server will need to keep track of a registration to subscription mapping. With the aggregation model, the UA is responsible to dispatch notifications to the right party. With a disaggregated model, you can have multiple independent processes listening to incoming notifications.
Darshak: Don't have enough information to make the decision now. In answer to the question of what we need to know, we should run the use cases through both models and explore their properties. That should help highlight which works better.
Joe: If you'll help with that, I think it sounds like a good idea.
There was an exchange here between Costin and Elio that I couldn't follow
Martin: Do you agree that if we do A, then you don't need to do D?
Elio: Yes, the aggregation behavior subsumes the disaggregation model.
Martin: I propose that we assume the aggregation model until we have an analysis
Action Item: Darshak volunteers to help with the analysis
Mike Jones: GCM encryption doesn't support streaming. So what you get is a whole payload, or nothing. So in terms of the assertion that other things don't support streaming, the algorithm you've selected does not either.
Richard Barnes: So, you get a chunk at a time, and each one has authentication information, right?
Martin: Yes, truncation is possible. Basically, we take what TLS does and steal it.
Mike: Okay, I'll read and comment.
Joe: Let's have that conversation on the list.
There was a quick exchange around key conveyance, with the result being an explanation that it takes a different path than the payload
Quick exchange among Martin, Joe and others around TTL, with the result being that people seem to favor a new header, communicating a relative time to save data
Martin: Do we need to be able to discover this?
Matt Miller: Applications do need to be able to figure this out.
Elio: This is useful from the client
Patrick McManus: This is sounding a lot like the behavior we have for cache control.
Martin: But when you pull the original information, you get a max-age. And then you start using it, and 4 weeks later, it's gone.
Dan Druta: This is useful for message suppression across multiple devices. Both that and message confirmation need delivery receipts.
Dave: Don't confuse "eyes on" with message delivery.
Martin: Right, suppressing messages would require additional, over-the-top application logic.
Elio: The web broswer has the ability to acknowledge when it wants -- if it wants to wait for something to be clicked or displayed, it can: basically, it means "I've done what I wanted to do with this informaiton"
Miguel: We need to decide how reliable we want these receipts to be.
Martin: You have a 1-way message to the browser, and then a 1-way message back to acknoweldge it. It's turtles all the way down, unless something becomes best-effort. So we make the receipts best-effort. If the server misses an ack, it sends the messages twice, so that requires dedupe, but that's not a big deal.
Harald: The delivery of receipts looks exactly like push. It seems to me that this can be done exactly at the application layer without any special protocol mechanism.
Elio: I don't understand how this can be done without having a server in between, and once the server is there, we're specifying how the information will be delivered. If it's 100% at the app layer, then you need to start setting up subscriptions just for acknowledgement.
Martin: It is easily possible to do this without additional mechanism, but the costs are significant. We do need to decide whether this is core to the protocol, or if it is just an extension.
Elio: We need to understand what the scenarios are here.
Adam: If we don't do this as part of core, we're going to end up with apps having to do fallback behavior to deal with non-extended implementations.
Matt: Plus one.
Doug Turner: I sort of disagree. As an app developer, you can have a back-channel (e.g. XHR) to deal with communicating this information. And then, as a push server implementor, I don't need to deal with these things. I would urge us to use the app and its back-channel to the web server to provide delivery notifications.
Dan: There are delivery notifications that require notification immediately, even if the app is not running.
Elio: For many apps, the main point of the notifications are to get the user to open the app again.
Joe: If the two authors could get together and merge documents, it would make this question much easier.
Martin: That's what we want to do, but we'd like guidance from the WG on aggregation.
Action Item: Authors tentatively agree to get a merged draft in ~1 month, will come back to WG with concrete timelines later this week.