Subject: [mile] XMPP Grid

From: Dave Cridland <[email-masked]>
Date: Thu, 21 Jul 2016 14:51:19 +0100

Folks,

I've been aware of the XMPP Grid work for a while, but I've only recently
read through the draft.

It's not clear to me if this provides anything above and beyond the
pre-existing capabilities provided by the XSF specifications such as
XEP-0060, XEP-0030, and so on.

XEP-0060 in particular provides a complete protocol for publish-subscribe
within XMPP which has widespread adoption. Specialist services can and have
been created on top of the primitives it offers, although it can also be
used "as-is".

Pushing IODEF, or any other XML payload, through XEP-0060 is trivial, and
it offers discoverability and so on as part of the basic feature set.

I'm curious as to why this isn't being used, and if it were, what would be
the feature gaps.

Dave.

---

From: Jerome Athias <[email-masked]>
Date: Fri, 22 Jul 2016 09:45:02 +0300

Hi,

Not sure what you mean by "why this isn't being used".
>From a 'pure standard point of view', it seems that XEP-0060 would
play more into the Implementation area.
With that said, I can see how/why it could be pointed out, or
'recommend' in a Standard or Guidelines around a Standard.

My 2c
/JA

On Thu, Jul 21, 2016 at 4:51 PM, Dave Cridland <[email-masked]> wrote:
> Pushing IODEF, or any other XML payload, through XEP-0060 is trivial, and it
> offers discoverability and so on as part of the basic feature set.
>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>

---

From: Dave Cridland <[email-masked]>
Date: Fri, 22 Jul 2016 08:46:54 +0100

Jerome,

> 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).

> 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: Jerome Athias <[email-masked]>
Date: Fri, 22 Jul 2016 11:28:58 +0300

clear now
I don't know...

Meantime, one (not-related) question: is it content-agnostic, meaning
would it work, i.e., with JSON in place of XML?

---

From: Dave Cridland <[email-masked]>
Date: Fri, 22 Jul 2016 09:42:48 +0100

> 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.

---

From: Jerome Athias <[email-masked]>
Date: Fri, 22 Jul 2016 11:46:36 +0300

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:
> 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.

---

From: Jerome Athias <[email-masked]>
Date: Fri, 22 Jul 2016 11:53:10 +0300

PS: question would apply similarly in the context of
https://datatracker.ietf.org/doc/draft-takahashi-mile-jsoniodef/