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

Dave Cridland dave at cridland.net
Fri Aug 28 11:18:28 UTC 2015


I see it's now listed, with a url of
http://nso.nato.int/nso/zPublic/stanags/CURRENT/5066Ed03.pdf

Therefore I have no further objections.
On 27 Aug 2015 15:09, "Dave Cridland" <dave at cridland.net> wrote:

> 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.
>
> Dave.
>
> 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/20150828/232306ae/attachment-0001.html>


More information about the Members mailing list