[Standards] STANAG 5066 availablity - RE: Proposed XMPP Extension: Server to Server communication over STANAG 50666 ARQ

Dave, Thanks for raising this important point. I did put a note in the draft, that I have requested permission from NATO to put the spec on the Web. STANAG 5066 is NATO UNCLASSIFIED, so I can share with anyone who wants to review in context of this specification - it is not a light

Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method

Wed, 26 Aug 2015 16:48:41 +0200 Kim Alvefur z...@zash.se wrote: Didn't Jingle File Transfer support transfer of multiple files? OK, probably it does. But it's still unclear how this will interact with thumbnails. As I understand several files will be rejected at the first step (only thumbnails

[Standards] LAST CALL: XEP-0320 (Use of DTLS-SRTP in Jingle Sessions)

This message constitutes notice of a Last Call for comments on XEP-0320 (Use of DTLS-SRTP in Jingle Sessions). Abstract: This specification defines how to use DTLS-SRTP (RFC 5763) in the Jingle application type for the Real-time Transport Protocol (RTP) as a way to negotiate media path key

[Standards] LAST CALL: XEP-0352 (Client State Indication)

This message constitutes notice of a Last Call for comments on XEP-0352 (Client State Indication). Abstract: This document defines a way for the client to indicate its active/inactive state. URL: http://xmpp.org/extensions/xep-0352.html This Last Call begins today and shall end at the close

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

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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? While I think there is a gap in the XMPP specifications in ways for allowing a user to transparently switch clients in mid-conversation, it’s seems this spec inadequately addresses

Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method

On 2015-08-26 16:36, Evgeny Khramtsov wrote: Wed, 19 Aug 2015 15:44:30 + (UTC) XMPP Extensions Editor edi...@xmpp.org wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Jingle HTTP Transport Method Abstract: This specification defines two Jingle transport

Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method

Wed, 19 Aug 2015 15:44:30 + (UTC) XMPP Extensions Editor edi...@xmpp.org wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Jingle HTTP Transport Method Abstract: This specification defines two Jingle transport methods for establishing HTTP connections for

[Standards] Add Message Hint (XEP-0334) to implicitly ask server to store messages

Hi, quick suggestion with the upcoming OMEMO Encryption and the general desire to save messages in MAM that do not have a body wouldn't it make sense to add a new message processing hint that asks the server politely to store the message in the archive. (For example named pretty-please-store

Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method

I don't see this XEP resolves any of these. That is correct. However, this XEP was never intended to solve those issues, in the exact same way that no other Jingle transport (IBB, SOCKS5, ICE, raw UDP, etc) is intended to directly solve those problems. These are things that apply to *all*