Subject: Re: [mile] XMPP Grid

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 11 Oct 2016 02:50:36 +0000

Hi,

I will let Syam further elaborate.

But, XMPP-grid does use XEP-0060….however, XMPP-grid does also expose another interface to allow for a broader protection/registration so that an entity can “join” the XMPP-grid and be authorized to leverage more than one topic…

Nancy

From: mile <[email-masked]<mailto:[email-masked]>> on behalf of Dave Cridland <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 22, 2016 at 12:46 AM
To: Jerome Athias <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] XMPP Grid

Jerome,

On 22 July 2016 at 07:45, Jerome Athias <[email-masked]<mailto:[email-masked]>> wrote:
Not sure what you mean by "why this isn't being used".

I meant that XEP-0060 is not being used as the pub-sub mechanism within XMPP-Grid, and instead a new generic publish-subscribe mechanism has been defined.

For example, the flows in §2.4.3 all exist within XEP-0060:

Figures 5 and 7 are equivalent to a pubsub node with an access-model of authorize, where the Controller is an owner. See for example:

http://www.xmpp.org/extensions/xep-0060.html#subscriber-subscribe-approval
http://www.xmpp.org/extensions/xep-0060.html#owner-subreq

Figure 6 is equivalent to http://www.xmpp.org/extensions/xep-0060.html#publisher-publish

Figure 8 might be new (although it looks like a session establishment to my eyes, so XMPP has protocol for those too).

>From a 'pure standard point of view', it seems that XEP-0060 would
play more into the Implementation area.

I'm not sure what you mean here. XEP-0060 is very much a standards-track specification, and not any particular implementation. There are, however, a number of existing implementations of XEP-0060. It's a Draft specification within the XSF, which is (roughly) equivalent to Proposed Standard within the IETF.

Dave.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 11 Oct 2016 02:52:30 +0000

Hi,

Yes, XMPP-Grid can support other formats like STIX and JSON (as is also
the case for XMPP using XEP-0295 https://xmpp.org/extensions/xep-0295.html)

	Nancy.

On 7/22/16, 1:53 AM, "mile on behalf of Jerome Athias"
<[email-masked] on behalf of [email-masked]> wrote:

>PS: question would apply similarly in the context of
>https://datatracker.ietf.org/doc/draft-takahashi-mile-jsoniodef/
>
>On Fri, Jul 22, 2016 at 11:46 AM, Jerome Athias <[email-masked]>
>wrote:
>> Yep, I admit, I was thinking in context of STIX -in general- (mainly
>> v1 vs v2 in TAXII context)
>>
>> Thanks for the answer. Crystal clear
>>
>> On Fri, Jul 22, 2016 at 11:42 AM, Dave Cridland <[email-masked]>
>>wrote:
>>>
>>>
>>> On 22 July 2016 at 09:28, Jerome Athias <[email-masked]> wrote:
>>>>
>>>> Meantime, one (not-related) question: is it content-agnostic, meaning
>>>> would it work, i.e., with JSON in place of XML?
>>>
>>>
>>> You're presumably thinking in terms of STIX 2.0? Yes and no.
>>>
>>> There's no absolute requirement that the payload format be anything in
>>> particular - it has to be an XML element (ie, DOM subtree) for syntax's
>>> sake, but that XML could easily be a container element with a textual
>>>value
>>> in JSON format, like:
>>>
>>> <stix xmlns='some:stix:namespace'><![CDATA[{"type":"malware", ...
>>> }]]></stix>
>>>
>>> An alternative would be throwing the JSON into an attribute value, but
>>>that
>>> would probably need more escaping than a CDATA block.
>>>
>>> As a general note, XMPP treats XML as a pragmatic syntax, rather than
>>>buying
>>> into the complete XML ecosystem of document and schema, so the result
>>>tends
>>> to be much more palatable than, say, typical JAXB output, and the
>>>community
>>> is less prone to purism about mixing JSON and XML than might be
>>>expected.
>>>
>>> Dave.
>
>_______________________________________________
>mile mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mile

---

From: Dave Cridland <[email-masked]>
Date: Tue, 11 Oct 2016 09:05:32 +0100

On 11 October 2016 at 03:50, Nancy Cam-Winget (ncamwing)
<[email-masked]> wrote:
> But, XMPP-grid does use XEP-0060….

It doesn't cite is as a reference, and it says at the end of §2.1 that:

   The XMPP extensions used in XMPP-Grid are now part (e.g. publish/
   subscribe) of the main XMPP specification [RFC6120] and the presence
   in [RFC6121].  A full list of XMPP Extension Protocols (XEPs)
   [RFC6120] can be found in http://xmpp.org/extensions/xep-0001.html .

This strongly suggests it's only using the baseline specification.
There's no mention of the XEP-0060 namespace (or indeed any XEP
namespaces) throughout. There are new protocol exchanges defined for
subscription, approvals, and so on.

> however, XMPP-grid does also expose
> another interface to allow for a broader protection/registration so that an
> entity can “join” the XMPP-grid and be authorized to leverage more than one
> topic…
>

I'm afraid I'm not sure what you mean here - it appears to imply a
restriction on the number of pubsub topic subscriptions an entity may
have that I'm entirely unaware of.

I'm sure that there are some additional capabilities required to
support your use cases here, but it would really help to isolate and
identify these.

> Nancy
>
> From: mile <[email-masked]> on behalf of Dave Cridland
> <[email-masked]>
> To: Jerome Athias <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> On 22 July 2016 at 07:45, Jerome Athias <[email-masked]> wrote:
>>
> I meant that XEP-0060 is not being used as the pub-sub mechanism within
> XMPP-Grid, and instead a new generic publish-subscribe mechanism has been
> defined.
>
> Figures 5 and 7 are equivalent to a pubsub node with an access-model of
> authorize, where the Controller is an owner. See for example:
>
> Figure 6 is equivalent to
> http://www.xmpp.org/extensions/xep-0060.html#publisher-publish
>
> Figure 8 might be new (although it looks like a session establishment to my
> eyes, so XMPP has protocol for those too).
>
>>
> I'm not sure what you mean here. XEP-0060 is very much a standards-track
> specification, and not any particular implementation. There are, however, a
> number of existing implementations of XEP-0060. It's a Draft specification
> within the XSF, which is (roughly) equivalent to Proposed Standard within
> the IETF.
>
> Dave.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 11 Oct 2016 09:06:50 +0100

> the case for XMPP using XEP-0295 https://xmpp.org/extensions/xep-0295.html)

Of course, that XEP would qualify for the RFC Editor comment of "Check
Publication Date".

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 11 Oct 2016 17:59:43 +0000

Hi David,

RFC 6120/6121 does speak to using XEP-0060 and that is how XMPP-Grid uses
it.
Though your point for clarity is well taken and will work with Syam to
make clarifications.

Thanks, Nancy

---

From: Dave Cridland <[email-masked]>
Date: Tue, 11 Oct 2016 19:08:11 +0100

> RFC 6120/6121 does speak to using XEP-0060 and that is how XMPP-Grid uses

RFC 6120 mentions it twice, as an example. XEP-0060 is an Informative
reference in RFC 6120, and not mentioned at all in RFC 6121. Unless
XMPP-Grid actually makes use of the protocol (and by inference its
namespace), then it doesn't use it at all. Given that XMPP-Grid
doesn't even use XEP-0030 for discovery, which is a prerequisite to
XEP-0060, it's hard to see how one could possibly describe it as used.

As I say, while I'm confident that existing protocol extensions
(including XEP-0060) would cover a large amount of the capability
XMPP-Grid seems to be defining, I'm much more interested in the
feature-gaps that might explain why it's not being used here.

---

From: "Syam Appala (syam1)" <[email-masked]>
Date: Thu, 13 Oct 2016 01:34:00 +0000

Yes, XMPP-Grid can support other formats like STIX and JSON. The payload gets wrapped into an XMPP XML messaging envelope to get that routed on XMPP fabric.

Like Nancy mentioned, XEP-0295 is a good illustration. 

Thanks
Syam