[Members] [Standards] Proposed XMPP Extension: Server to Server communication over STANAG 50666 ARQ

Dave Cridland dave at cridland.net
Thu Aug 27 14:09:53 UTC 2015

Good news:

I've been in contact with the NATO Standardization Office on this one to
clarify my own confusion about the classification, and it seems the only
reason it was not already on their public listing was due to an error in
their database.

I'm told it will be listed tomorrow on the public website I linked to
above; I'll therefore be indicating no objection for the protoXEP once I
confirm this.

This is about the perfect outcome for this situation.


On 27 August 2015 at 10:07, Goffi <goffi at goffi.org> wrote:

> Hi,
> for what it worth I'm strongly opposed to any dependency to anything
> closed. A libre standard must be available free of charge, easily, without
> patent or royalties.
> I have the same thing with the move to github: I'm OK with that (but not
> happy) because we don't need a github account to contribute, but if
> tomorrow I can't report a spec bug, or update my XEPs without a github
> account, it will definitely be a problem and the XSF would be failing it
> what is, in my opinion, one of its most important mission: keeping XMPP
> independent from patents, royalties, closed documentation or private
> companies.
> I'm promoting a lot XMPP these days, and one of my main argument is "you
> can use it for free, you can study or adapt it, you can even fork it, it's
> a libre standard". How could I say after that "yes, but not this XEP, it
> depends on a closed standard" ?
> For this special case I don't know the radio amateur world, but if there
> is a XEP, it should depend on a libre specs (if any). If somebody want to
> use it with a closed spec, nothing prevent to use the XEP as a basis, and
> adapt it for its proprietary stuff. If there is no libre alternative to
> STANAG 5066 (again I don't know at all this world), there should not be
> official XEP for that.
> Thanks
> Goffi
> On 26/08/2015 17:58, Dave Cridland wrote:
>> Folks,
>> I've avoided voting on this because I want to seek some community input
>> on it. Specifically, we (the XMP{P Standards Foundation) claim to be an
>> Open Standards organization, and it's not clear if this submission
>> qualifies because it has a dependency on STANAG 5066, which is not
>> publicly available.
>> STANAG 5066 is a physical layer protocol providing services roughly akin
>> to IPX/SPX and V.90 combined. It's in use both in the Military world
>> (it's a NATO specification) and also by commercial HF radio modems in
>> use by amateur radio operators ("hams") worldwide.
>> Many STANAG documents are available publicly in the NATO Standards
>> Organisation's online document library, here:
>> http://nso.nato.int/nso/nsdd/listpromulg.html - but STANAG 5066 is
>> missing from this list.
>> I'd like to make it clear that otherwise, I'm thoroughly in favour of
>> this.
>> Some parallel cases, which people may decide form a precedent (or may
>> decide are completely different).
>> 1) RTMP as a Jingle transport.
>> RTMP is (or was) a multimedia realtime transport protocol developed by
>> Adobe, and in use in the Flash Player. The Council rejected a submission
>> to allow its use as a Jingle transport, on the basis that it was a
>> closed standard.
>> The minutes say:
>> "Council consensus that it is inappropriate to publish this proposal
>> given the proprietary nature of the RTMP technology on which this
>> specification depends."
>> STANAG 5066, although a STANdardization AGreement, is not publicly
>> available, and therefore certainly doesn't form an "open standard".
>> 2) SDN.801c in XEP-0258
>> As a counter-example of sorts, implementing XEP-0258 in any useful form
>> in a server requires the use of the document SDN.801c, which (similar to
>> STANAG 5066) is an unclassified document which is not publicly available.
>> However, XEP-0258 was, of course, published as a XEP - and indeed it's
>> relatively simple to implement in a client, and its possible to
>> implement a server which uses some other labelling model; arguably
>> therefore SDN.801c is not a hard dependency in the same way.
>> I could go either way on this; though my ideal outcome would be that
>> STANAG 5066 gets put in the NATO public STANAG library alongside the
>> others.
>> Opinions welcome.
>> Dave.
>> On 24 August 2015 at 23:32, XMPP Extensions Editor <editor at xmpp.org
>> <mailto:editor at xmpp.org>> wrote:
>>     The XMPP Extensions Editor has received a proposal for a new XEP.
>>     Title: Server to Server communication over STANAG 50666 ARQ
>>     Abstract:
>>        This specification defines operation over XMPP over the NATO
>>     STANAG 5066 data link service for point to point links (ARQ).   This
>>     enables optimized XMPP performance over HF Radio (which STANAG 5066
>>     was designed for) and over other data links using STANAG 5066.
>>     URL: http://xmpp.org/extensions/inbox/s2s-over-s5066.html
>>     The XMPP Council will decide in the next two weeks whether to accept
>>     this proposal as an official XEP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/members/attachments/20150827/275ab3ea/attachment.html>

More information about the Members mailing list