Subject: Re: [mile] Working group last call for XMPP-grid

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 14 Apr 2017 20:12:50 +0000

Hello Nancy and team,

I hadn't gone through the doc before because of my lack of knowledge of XMPP-Grid. I just went through it as a non-XMPP-Grid expert. Below I have some comments and nits. I think the comments below would generated some significant changes to the doc, so it might not be ready for WGLC yet.
*       Nit: Add space in "[RFC6120]that"
*       Nit: "and among network platforms, endpoints, and most any network connected device." Needs rephrasing.
*       Section 1.4 should address RID vs ROLIE vs XMPP-Grid. We have now defined 3 transports for IODEF documents, so I think it would be beneficial to qualify where each one fits.
*       Change all references of [RFC5070] to IODEF-bis [RFC7970].
*       In Section 3, I think it would be worth to expand on the IODEF-bis attributes that could serve as filters. Also how Topics and Subtopics would be defined in the context of IODEF. Would there be any rules in searching for attributes that deep in IODEF classes like nodeRole attributes?
*       Nit: There is an empty parent bullet over "Real-time event notifications through publish and subscribe."
*       I think section 2.6 should be in an appendix since it is mostly showcasing example xml form.
*       In section 5.1.4, "Protect the confidentiality of the CA's private key" is inaccurate. The CA signs the public key but does not know the private key that corresponds to that public key.
*       In section 5.1.4, it is not clear what "Issue certificates that go beyond name constraints or other constraints imposed by a relying party or a cross-certificate" means.
*       In section 5.2.2, could sharing info with other nodes be one more threat for the compromised XMPP-Node?
*       Section 5.3.1 mentions that both mutual cert auth or HTTP Basic are acceptable, but section 2.4.1 only requires mutual cert auth. Are certs the only ones mandated?
*       In section 5.3.1 s/certificate-based authentication SHOULD each verify the revocation status of the other party/certificate-based authentication SHOULD each verify the revocation status of the other party's certificate
*       5.3.1 does not define ARC and SSRC
*       5.3.2 and 5.3.3 does not define TNC.

A clarification question for my benefit: Is this draft intended to standardize XMPP-Grid and demonstrate its applicability in IODEF and other info sharing standards. Even though IODEF is one of the shared standards, the draft mostly focuses on setting the XMPP-Grid protocol and architecture up. I was curious if SACM had considered the draft back in the day as it is dealing with more broad set of info sharing standards instead of MILE whose charter was focusing on IODEF mostly. No worries, since it already is a MILE WG item anyway.

Rgs,
Panos

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Takeshi Takahashi
Sent: Thursday, March 30, 2017 11:50 PM
To: [email-masked]
Subject: [mile] Working group last call for XMPP-grid

Hello all,

This is a WGLC for draft-ietf-mile-xmpp-grid.
The version to be reviewed is
https://tools.ietf.org/id/draft-ietf-mile-xmpp-grid-02.txt

We will have 1 month for this call.
Please provide comments before May 1st and provide your support and/ or raise any issue you feel are yet to be addressed.

Thank you.
Take

_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

---

From: Adam Montville <[email-masked]>
Date: Thu, 20 Apr 2017 14:42:54 +0000

Take and MILE WG,

The following is a partial review of XMPP-grid (I'm still working through
it). As with the ROLIE review there are two categories of items: Nits and
Non-nits. Many are suggestive/inquisitive.

Non-nits:

The IODEF treatment in this draft is surprisingly light, though I
understand. XMPP-grid as an agnostic transport cares not what goes through
it. Then, why make this particular draft tied to IODEF at all? In other
words, I don't think the draft would lose any value if section 3 were
removed. On the other hand, it doesn't hurt to keep it in there (I just
don't think it's necessary, in spite of being put through the MILE WG).

No IANA considerations at this time? I think the group should probably
settle on whether or not there are any before publication :-) If I were to
offer any suggestion, it would be to consider (and this might be an
entirely separate draft) establishing the start of a controlled capability
vocabulary that could be stored in an IANA registry.

I, at first, didn't like the openness of the topic/capability definition,
but now I think I do. It's just going to be of limited overall value until
disparate vendors start collaborating on their vocabulary.

In the XMPP-Grid Topics Protocol Flow section on page 22, item 'a' implies
that schemas need to be available for a given capability. Earlier in the
draft, XMPP-Grid is stated as being suitable for structured and
unstructured data. Is there a contention between these perspectives?

The protocol details (section 2.6) were enough for me to get the gist of
what's happening in the protocol, but having not tried to implement the
specification, I can't really speak for whether the XML examples are
complete enough to code against. How many implementations are there? Has
anyone yet commented on the ability to implement from this specification?

Nits

Page 5: "Topics" definition at the top of the page. Proposed change:
"...real-time to a set of subscribed devices."

Page 5: XMPP-Grid Connection Agent definition. Proposed change: "...library
that an XMPP-Grid node..." In fact, this is found throughout the draft, so
a find/replace could help --> find "a XMPP-Grid" and replace with "an
XMPP-Grid".

Page 16: Consider rewording third sentence of section 2.4.1. Maybe there is
a "the" missing... "...XMPP uses the Simple Authentication..."

Page 16: Last sentence of last paragraph. Proposed change: "...trust to be
uniquely established..."

Page 19: Third sentence of first paragraph. Proposed change: "...Node
identity extracted from the request, a group to which the Node is assigned
during account approval, and Topic/capability to which the permission is
sought..."

Page 20: Last sentence of first paragraph. Proposed change: "...allows or
disallows the flow..."

Page 20: Last sentence on the page. Proposed change: "Based on this
result..." or "Based on the result".

Page 22: First sentence of item 'b' in section 2.5. Proposed change: "...if
the subscriber wants...values in a capability provider's..."

Page 23: Fifth sentence in first paragraph of section 2.5.1. Proposed
change: "...nodes with older capabilities..."

Kind regards,

Adam

On Thu, Mar 30, 2017 at 10:50 PM Takeshi Takahashi <
[email-masked]> wrote:

> Please provide comments before May 1st and provide your support and/ or
> raise any issue you feel are yet to be addressed.
>
> Thank you.
> Take
>
>
> [email-masked]

---

From: Dave Cridland <[email-masked]>
Date: Thu, 20 Apr 2017 17:12:09 +0100

Folks,

TL/DR: This shouldn't be published, possibly ever, certainly not in
its current state.

I remain bewildered as to what this specification offers above and
beyond XEP-0060, and I cannot implement from this specification.

This is, in part, because the document is written in essentially two
parts - one describes how good it'll be once you've got it, and the
other has some very lightweight sketches of what the protocol might
look like if it were specified, and most of those appear to be
reinventions of existing XMPP protocol extensions.

An example is registration. The authors have elected to write their
own registration protocol, rather than use XEP-0077. Perhaps this is
needed, but it's not clear because the behaviour of a Controller when
given a registration request isn't specified. I have no idea what a
Controller is meant to do with the registration. Maybe register. But
if I don't, does it work anyway? Who knows. It's in an XML namespace
which appears to be, at best non-traditional, at worst illegal. The
register element, despite being empty, is spelt out "in full" with
both opening and closing tags, which seems odd - perhaps the
serializer used does this and it's a cut and paste.

Then there's a "login" and "logout". A "login" looks reasonable modulo
the horrible use of incorrect XML namespacing, though again I have
absolutely no idea what it might do, and what the requirement is here.
The login result, on the other hand, is special - it's placed in the
default namespace (ie, xmlns=""), which really should not be used. It
contains a <value/> element, with a default-namespaced attribute. I
didn't even know that was legal, so I'm impressed. The meaning of
<value/>, and whether xsi:nil can also be set to "false", is not
explained. Perhaps that's obvious.

Typically, in XMPP, we have used presence to indicate client
availability - but without knowing whether this is what's intended
with the login/logout construct, I have no idea if that meets the
requirements - it's only mentioned in passing in §2.4.

The "getCapabilityListRequest", which is also in the default
namespace, is another example of reinventing a perfectly serviceable
wheel. XEP-0030 includes a full suite of discovery, and for that
matter the XMPP community has been using "versioned" namespaces to
offer parallel revisions of services for many years, with much
success.

In this entirely new capability discovery, however, the response
includes a set of triples of "id", "name", and "version". None of
these are explained. The example contains a lengthy list of
capabilities, none of which seem to be documented anywhere.

Next up - sorry, there's nothing so simple as section numbers here -
there's DiscoveryQuery, which looks suspiciously like it might be a
rendition of Java introspection over XMPP. It says it responds with a
hostname; it doesn't, instead it responds with a Jid. Again, this kind
of discovery is supported within XEP-0030 - it's a disco#items
request, so not search-based, but the functionality is there
nonetheless, and certainly doesn't need rewriting from scratch.

Publisher registration is, I think, new - XEP-0060 does not have
anything similar that I can immediately think of.

Subscription, on the other hand, is very much within XEP-0060. I have
literally no idea why this isn't used.

Publishing actually does, here, use XEP-0060 - though no mention of
the fact is made, and there's no documentation of the payload format.

The security considerations section seems mostly OK, but please note
that §5.3.1 suddenly decides to replace the transport layer with HTTP,
which is mildly confusing to say the least. How we're supposed to
authenticate over XMPP using an HTTP authentication mechanism is
unknown.

So what we have here is a vast amount of NIH, plus - if my
understanding is correct - one added feature, that'd make a two-page
XEP.

This is *not* to say that XMPP has no place in CTI sharing; in fact I
think it's very useful. But by departing from existing, well-defined
XMPP protocol extensions, this specification promptly loses many
advantages. As an example, while XEP-0060 provides a reasonably
complete pubsub service on its own, it can be enhanced by XEP-0314
into permitting originator-controlled data labelling, which in turn
can be used for access control, highly useful in federated
environments. Instead of poorly describing a new protocol extension
which duplicates existing work, it'd be much better if the document
described how to use existing protocol effectively - and indeed, where
the document is doing so, it works well.

Dave.
(Personal opinion, not as XMPP Council or XMPP Standards Foundation).

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 21 Apr 2017 14:19:34 -0600

> TL/DR: This shouldn't be published, possibly ever, certainly not in

Sadly, I must concur with Dave's assessment. I'd be happy to review a
future version that is more fully and correctly specified.

Peter

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 27 Apr 2017 17:25:21 +0000

Hi Panos,

Many thanks for the review!!  Comments and answers below:

From: Panos Kampanakis <[email-masked]>
Date: Friday, April 14, 2017 at 1:12 PM
To: Takeshi Takahashi <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [mile] Working group last call for XMPP-grid

Hello Nancy and team,

I hadn’t gone through the doc before because of my lack of knowledge of XMPP-Grid. I just went through it as a non-XMPP-Grid expert. Below I have some comments and nits. I think the comments below would generated some significant changes to the doc, so it might not be ready for WGLC yet.
·         Nit: Add space in "[RFC6120]that"
·         [NCW] Will fix in next revision
·
·         Nit: "and among network platforms, endpoints, and most any network connected device." Needs rephrasing.
·         [NCW] Will rephrase to: “among any network connected device”
·
·         Section 1.4 should address RID vs ROLIE vs XMPP-Grid. We have now defined 3 transports for IODEF documents, so I think it would be beneficial to qualify where each one fits.
·         [NCW] I am not sure the comparison makes sense to have inside the XMPP-Grid spec, though your point is well taken.  We can add applicability for when XMPP-Grid makes sense to use within the XMPP-Grid draft; and if the group warrants it, we can have a separate writeup that explains the differences between the three transports (at some point Kathleen had a wiki but not sure its up anymore?) and where/how each applies.
·
·         Change all references of [RFC5070] to IODEF-bis [RFC7970].
·         NCW] Will fix in next revision
·
·         In Section 3, I think it would be worth to expand on the IODEF-bis attributes that could serve as filters. Also how Topics and Subtopics would be defined in the context of IODEF. Would there be any rules in searching for attributes that deep in IODEF classes like nodeRole attributes?
·         [NCW] The XMPP Pub/Sub or Query mechanisms allow for filtering on any attributes, do you have some to suggest from IODEF?  We will rework the draft to show the applicability and definition of sharing IODEF as a Topic, as to the subtopics, I would think that it could depend on the publisher of the information as they code potentially define subtopics based on the Assessment impact vs. nodeRole or some other class type as well?
·
·         Nit: There is an empty parent bullet over “Real-time event notifications through publish and subscribe.”
·         [NCW] I will sort out the formatting issues in the XML file, thanks for catching this one.
·
·         I think section 2.6 should be in an appendix since it is mostly showcasing example xml form.
·         [NCW] Will consider moving it as we restructure the draft.
·
·         In section 5.1.4, “Protect the confidentiality of the CA's private key” is inaccurate. The CA signs the public key but does not know the private key that corresponds to that public key.
·         That is correct; but the bullet refers to the CA protecting itself and thus protecting its own (CA) private key as it uses it to validate the issued certs.
·
·         In section 5.1.4, it is not clear what “Issue certificates that go beyond name constraints or other constraints imposed by a relying party or a cross-certificate” means.
·         [NCW] We meant that the CA is only authorized to issue certs to secure the XMPP (XMPP-Grid) connections and thus should not be trusted to issue other types of certs.  So we can just change it to one sentence (vs. the single bullet) to state:  “The CA is not expected (trusted) to issue certificates beyond the constraints imposed by a relying party.”
·
·         In section 5.2.2, could sharing info with other nodes be one more threat for the compromised XMPP-Node?
·         [NCW] Yes, the intent for the bullets was to cite some such examples.  Do you have suggestions for improvement if it isn’t clear?
·
·         Section 5.3.1 mentions that both mutual cert auth or HTTP Basic are acceptable, but section 2.4.1 only requires mutual cert auth. Are certs the only ones mandated?
·         [NCW] Yes, our implementation only uses x.509 certificates, but as XMPP uses SASL for authentication, other mechanisms can be used.  So, I think its appropriate to add the guidance of SHOULD use certs for best security practices (vs. passwords or shared secrets).
·
·         In section 5.3.1 s/certificate-based authentication SHOULD each verify the revocation status of the other party/certificate-based authentication SHOULD each verify the revocation status of the other party’s certificate
·         [NCW] Thanks, will do.
·
·         5.3.1 does not define ARC and SSRC
·         [NCW] Thanks, will do.
·
·         5.3.2 and 5.3.3 does not define TNC.
·         [NCW] Thanks, will do.

A clarification question for my benefit: Is this draft intended to standardize XMPP-Grid and demonstrate its applicability in IODEF and other info sharing standards. Even though IODEF is one of the shared standards, the draft mostly focuses on setting the XMPP-Grid protocol and architecture up. I was curious if SACM had considered the draft back in the day as it is dealing with more broad set of info sharing standards instead of MILE whose charter was focusing on IODEF mostly. No worries, since it already is a MILE WG item anyway.
NCW] Yes, the Intent is to standardize XMPP-Grid and show its applicability into IODEF (though we also state that other info sharing models can be used). The intent, which we’ll strengthen is to show how IODEF is transported thru XMPP-Grid

Rgs,
Panos

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Takeshi Takahashi
Sent: Thursday, March 30, 2017 11:50 PM
To: [email-masked]
Subject: [mile] Working group last call for XMPP-grid

Hello all,

Thank you.
Take

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 27 Apr 2017 17:42:43 +0000

Many thanks for the full review Adam!  I will take care of the nits in the next revision.  Meanwhile, please see further comments on the non-nits below:

From: mile <[email-masked]> on behalf of Adam Montville <[email-masked]>
Date: Thursday, April 20, 2017 at 7:42 AM
To: Takeshi Takahashi <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [mile] Working group last call for XMPP-grid

Take and MILE WG,

The following is a partial review of XMPP-grid (I'm still working through it). As with the ROLIE review there are two categories of items: Nits and Non-nits. Many are suggestive/inquisitive.

Non-nits:

The IODEF treatment in this draft is surprisingly light, though I understand. XMPP-grid as an agnostic transport cares not what goes through it. Then, why make this particular draft tied to IODEF at all? In other words, I don't think the draft would lose any value if section 3 were removed. On the other hand, it doesn't hurt to keep it in there (I just don't think it's necessary, in spite of being put through the MILE WG).
[NCW] Section 3 is to demonstrate how (any) data can be transported….using IODEF as one such example (for Topic definition and pub/sub mechanics).  Given David and Peter’s feedback, my intent is to revamp the draft to better highlight how this is achieved @protocol level.  Please do let me know after the next revision if you think it is still not necessary.

No IANA considerations at this time? I think the group should probably settle on whether or not there are any before publication :-) If I were to offer any suggestion, it would be to consider (and this might be an entirely separate draft) establishing the start of a controlled capability vocabulary that could be stored in an IANA registry.
[NCW]  Thanks for that suggestion Adam!  We will consider this.

I, at first, didn't like the openness of the topic/capability definition, but now I think I do. It's just going to be of limited overall value until disparate vendors start collaborating on their vocabulary.
[NCW] Thanks. Given the current feedback, we will revamp the draft to show both the controller and the data plane mechanics  for the sharing of information.  We did add extensions and strayed from XEP-0030 (discovery) to allow for other pub/sub mechanisms in the future, but to your point, our intent is to help foster improved collaborations of info sharing in a framework that would allow for convergence at some point while enabling a migration given all the disparate vendor formats and mechanisms.

In the XMPP-Grid Topics Protocol Flow section on page 22, item 'a' implies that schemas need to be available for a given capability. Earlier in the draft, XMPP-Grid is stated as being suitable for structured and unstructured data. Is there a contention between these perspectives?
[NCW] Kind of ☺  Of course, once instantiating data to a Schema, imho, there has to be a structure by which information can be exposed and understood.  However, that is the explicit nature to facilitate the sharing.  The “unstructured” falls to the actual implementation.  That is, publishers (and subscribers) can choose to store and manage the data before publication or after receipt in an (un)structured form more suited for their purpose.

The protocol details (section 2.6) were enough for me to get the gist of what's happening in the protocol, but having not tried to implement the specification, I can't really speak for whether the XML examples are complete enough to code against. How many implementations are there? Has anyone yet commented on the ability to implement from this specification?
[NCW] Yes, we had tried to only expose the data plane side, but we are revamping the draft to more explicitly show and justify why some extensions to XMPP in the control plane is defined.  The main rationale was to allow for other pub/sub or non-pub/sub mechanisms to co-exist in a secure information sharing fabric.

Nits

Page 5: "Topics" definition at the top of the page. Proposed change: "...real-time to a set of subscribed devices."

Page 5: XMPP-Grid Connection Agent definition. Proposed change: "...library that an XMPP-Grid node..." In fact, this is found throughout the draft, so a find/replace could help --> find "a XMPP-Grid" and replace with "an XMPP-Grid".

Page 16: Consider rewording third sentence of section 2.4.1. Maybe there is a "the" missing... "...XMPP uses the Simple Authentication..."

Page 16: Last sentence of last paragraph. Proposed change: "...trust to be uniquely established..."

Page 19: Third sentence of first paragraph. Proposed change: "...Node identity extracted from the request, a group to which the Node is assigned during account approval, and Topic/capability to which the permission is sought..."

Page 20: Last sentence of first paragraph. Proposed change: "...allows or disallows the flow..."

Page 20: Last sentence on the page. Proposed change: "Based on this result..." or "Based on the result".

Page 22: First sentence of item 'b' in section 2.5. Proposed change: "...if the subscriber wants...values in a capability provider's..."

Page 23: Fifth sentence in first paragraph of section 2.5.1. Proposed change: "...nodes with older capabilities..."

Kind regards,

Adam

On Thu, Mar 30, 2017 at 10:50 PM Takeshi Takahashi <[email-masked]<mailto:[email-masked]>> wrote:
Hello all,

Thank you.
Take

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 27 Apr 2017 18:01:25 +0000

Hi David and Peter,

While I thought we had explained the differences, we apparently did not do it well enough.

So your points are well taken and I will rework the draft to better layout where XMPP-Grid is explicitly XMPP

And where the extensions were made.  Additionally,  I’ll work (through the use of IODEF) in providing the

Full example for how this is achieved.

I have a couple more questions/comments below:

On 4/20/17, 9:12 AM, "mile on behalf of Dave Cridland" <[email-masked] on behalf of [email-masked]> wrote:

    Folks,

    its current state.

[NCW] This will be part of the rework as XMPP-Grid does actually use XEP-0060

[NCW] There is actually no registration, the step was meant to show the use of

XMPP’s SASL/TLS connection.  Will improve it by keeping it to the XMPP nomenclature

If that will help as we are not using XEP-0070 but rather RFC 6120.

[NCW] The notion of the “login” is meant to be part of RFC 6120, so will clean that up.

Can you help highlight why you believe it is incorrect XML namespacing?

The “logout” was added to allow the server side to explicit cleanup if the client sends that message.

[NCW] Yes, for the XMPP use in the data plane, we could use the presence, but there may

be instances in which XMPP is not used to share information which is why we added the explicit

‘logout’.

    success.

[NCW] XMPP-Grid does indeed not use XEP-0030 as there may be instances in which

XMPP may not be used to share the information but rather other interfaces…..and will

Update the draft to ensure we cover the needed information.

    unknown.

    XEP.

    Dave.

    mile mailing list

    [email-masked]

---

From: Dave Cridland <[email-masked]>
Date: Thu, 27 Apr 2017 19:58:57 +0100

On 27 April 2017 at 19:01, Nancy Cam-Winget (ncamwing)
<[email-masked]> wrote:
> On 4/20/17, 9:12 AM, "mile on behalf of Dave Cridland"
> <[email-masked] on behalf of [email-masked]> wrote:
>
>
>
>     Folks,
>
>
>

Only partially. Publishing and the events are used, but not subscriptions, etc.

> If that will help as we are not using XEP-0070 but rather RFC 6120.

You explicitly document a protocol exchange using an AccountQuery
element shown in §2.6 as the first example:

            <iq id="ay0tK-4" to="grid_Controller.jabber"
                from="[email-masked]/mac" type="get">
            <grid xmlns='gi' type='request'>
            <AccountQuery xmlns='com.domain.gi.gcl.Controller'>
            <register/></register></AccountQuery>
            </grid>
            </iq>

This is absolutely not part of RFC 6120, and if "there is actually no
registration", then this specification is incorrect.

Note also:
1) "gi" is not strictly a valid URI, and therefore not a valid XML
namespace URI.
2) The same goes for "com.domain.gi.gcl.Controller", which appears to
be a Java classname.
3) The first register tag is self-closed; the second is a spurious
close tag which should not be present.
4) It's sent to the grid controller (which has a jid I'm mildly
concerned is illegal since it contains an underscore in the domain
portion).

> client sends that message.

Ah, I used the wrong terminology there.

       <iq id="ay0tK-5" to="grid_Controller.jabber"
           from="[email-masked]/mac" type="get">
         <grid xmlns='gi' type='request'>
           <AccountQuery xmlns='com.domain.gi.gcl.Controller'>
             <login/></login>
           </AccountQuery>
         </grid>
       </iq>

This has the same complaints as the above register.

       <iq xmlns="jabber:client" to=" [email-masked]/mac"
           from="grid_Controller.jabber" type="result" id="ay0tK-5">
         <grid xmlns="gi" type="response">
           <AccountQuery xmlns="com.domain.gi.gcl.Controller">
             <login xmlns="">
               <value xmlns:ns2="gi" xmlns:xsi=" xsi:nil="true" />
             </login>
           </AccountQuery>
         </grid>
       </iq>

The response, however, is more interestingly broken.

The login element here has been explicitly placed in the empty
namespace - the namespace everything resides in if XML namespaces are
never declared.

The value element also resides in this namespace, but has two
namespace prefix declarations - one for the prefix ns2, which is never
used. The "xsi" namespace prefix is also set to the empty namespace,
but only used for an attribute.

It's not clear if what you have:

<value xmlns:n='' n:nil="true"/>

is equivalent to the following:

<value nil="true"/>

For comparison, these two are certainly not equivalent:

<n:value xmlns;n="x" n:nil="true"/>   <value xmlns="x" nil="true"/>

However, it's not clear that binding a prefix to the empty string is
actually allowed at all - the TR simply says this MAY be done for the
default namespace declaration (ie, no prefix). I've no idea how actual
XML processors will treat this.

> be instances in which XMPP is not used to share information which is why we

Yes... But if you're gatewaying through from another protocol, the
gateway can do the presence. It has to, after all, do the login/logout
instead. Using presence has various advantages - for one thing, the
server will automatically send unavailable presence if the device is
disconnected.

> Update the draft to ensure we cover the needed information.

I'm reading this as, "The existing design might not be suitable in all
cases, so everyone must use our new design in all cases". This
confuses me.

XEP-0030 can transport both simple string-based feature capabilities,
and dataforms containing arbitrary structured data.

It is also the incumbent standard, so if you'd like to supplant it you
will need to provide a solid argument.