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

[Peter Saint-Andre <[e-mail]>]

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.

Peter