Re: [mile] Ben Campbell's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)

[Dave Cridland <[e-mail]>]

On Sun, 24 Mar 2019 at 22:06, Peter Saint-Andre <[e-mail]> wrote:

> Hi Ben, thanks for continuing to engage on these topics. Replies inline.
>
> On 3/24/19 3:55 PM, Ben Campbell wrote:
> >
> >
> >> On Mar 24, 2019, at 10:14 PM, Peter Saint-Andre <[e-mail]>
> wrote:
> >>
> >> On 3/24/19 1:32 PM, Ben Campbell wrote:
> >>> Hi, apologies for not getting back to this sooner. I’m trying to close
> >>> or clarify my DISCUSS points prior to stepping down from the IESG this
> >>> week. Please see inline:
> >>>
> >>> Thanks!
> >>>
> >>> Ben.
> >>>
> >>>> On Mar 4, 2019, at 6:49 PM, Nancy Cam-Winget (ncamwing)
> >>>> <[e-mail] <mailto:[e-mail]>> wrote:
> >>>>
> >>>> Hi Ben,
> >>>>     Thanks for the careful review and comments, please see answers
> below:
> >>>>
> >>>>     On 1/22/19, 19:14, "Ben Campbell" <[e-mail]
> >>>> <mailto:[e-mail]>> wrote:
> >>>>
> >>>>
> >>>>
>  ----------------------------------------------------------------------
> >>>>         DISCUSS:
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>
> >>>>         Hi, thanks for the readable approach to this. I like the plain
> >>>> English approach
> >>>>         to the security considerations, in particular. But I do have
> >>>> some comments,
> >>>>         including a couple that I think needs to be resolved before
> >>>> progressing the
> >>>>         draft:
> >>>>
> >>>>         1) I was surprised not to see a discussion of the "never-meet"
> >>>> problem. That
> >>>>         is, what happens if a provider and a consumer never connect
> >>>> with the controller
> >>>>         at the same time. Is the controller expected to
> >>>> store-and-forward items
> >>>>         submitted to a topic prior to when the consumer connects? IIRC
> >>>> (and I apologize
> >>>>         that I did not have time to refresh my memory on the
> >>>> referenced XEPs), that
> >>>>         sort of behavior is optional under XEP-0060. Is it required
> >>>> for this use case?
> >>>>         Is support for delayed delivery (xep-0203) or something
> >>>> similar required? Or
> >>>>         perhaps platforms are expected to keep long-lived connections?
> >>>>     [NCW] I think this is an implementation detail, but we've added a
> >>>> sentence in section 4
> >>>>     To describe that it is an option per XEP-0060.
> >>>
> >>> I’m not sure that’s enough to solve the isssue. I think this is more
> >>> than an implementation detail. I think there’s some implicit
> assumptions
> >>> about how and when providers and consumers connnect to the server that
> >>> are required for interoperation. These should be explicit. For example,
> >>> do you expect that consumers will maintain long-lived connections to
> the
> >>> server, or just connect occasionally to download any waiting data? If
> >>> there are several new pieces of data published while a consumer is not
> >>> connected, do they expect to download all the changes or just the
> >>> latest? (i,e does this require the server to be configured for
> >>> persistent items?)
> >>
> >> The "never-meet" problem isn't really a problem in XMPP - all servers
> >> implement support for so-called "offline messages" and the message
> >> delivery semantics defined in Section 8 of RFC 6121 take full account of
> >> eventual delivery by servers to clients that are not online at the time
> >> the message was created. A reference to RFC 6121 should be sufficient to
> >> correctly specify this behavior.
> >
> >
> > I agree referencing RFC 6121 would help.  I had missed the fact the
> examples use ‘message' stanzas (although if there is normative text that
> says to do that, I have still missed it.)
>
> XEP-0060 uses message stanzas for content delivery.
>
> > Am I mistaken to remember that offline-storage is still optional even
> for message stanzas?
> >
> > In any case, a mention of the use of offline-storage as described in
> 6121 would be sufficient to for me to clear on this point. It would be nice
> for it to suggest (normatively or otherwise) the use of offline-storage, or
> at least point out the consequences of not using it.
>
> Specifying that servers MUST support offline storage for these use cases
> seems appropriate. I can't remember why we said it was only SHOULD-level
> in the updated XMPP RFCs (6120 & 6121) - that was silly of us.
>
>
We called it SHOULD because there are multiple methods for the
decortication of felines, some possibly preferable to the "traditional"
offline messages, and it might be a sensible choice to use these and no
longer support offline messages in the sense of XEP-0160.

In particular, there's XEP-0313 (Message Archive Management) which, either
as a "personal" archive on the consumer's server, or as a service available
on the Pubsub Node, would allow a consumer to "catch up" perfectly well -
and probably more effectively than the XEP-0160 style.

Plus there's XEP-0198 (Stream Management), which rather blurs what
"offline" actually means, XEP-0357 (Push Notifications) which might send
the traffic out of band, and so on.

Also "SHOULD" doesn't mean "OPTIONAL", as Ben OUGHT to know. ;-)


> Peter
>
> _______________________________________________
> mile mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mile
>