Re: [Standards] BOSH patches

Hi, I am new to this mailing list. I have been trying to implement BOSH in Java (client side) on basis of draft 1.10. I think the document is quite understandable. However, I ran into the following issues: - I did not understand the HTTP pipelining stuff, which is now removed :) - The 'rid'

Re: [Standards] BOSH patches

Hi, yes, to should be from in 7.2. Concerning the xs:positiveInteger: http://www.w3schools.com/schema/schema_dtypes_numeric.asp I am not really sure if a positiveInteger is unbound and an unsignedInt is limited to 32bit. I don't really understand the difference anyway. Still, unsignedLong feels

Re: [Standards] BOSH patches

In the end, there's not only two connections, which flip-flop (one always being an active connection). But there are unlimited connections. Every time a new request must be sent, a new connection is created, which sends the request and then waits for a response. If a new request must be sent,

[Standards] (no subject)

Hi XMPP community, I have read and implemented some XEPwhich are in Draft status and now I have some suggestions to improve them. In particular I suggest the following: XEP-0107: User Mood: The sample and the XML Schema tell me differen things. The sample suggests: happy ecstatic

[Standards] Some suggestions regarding XEP-0107, XEP-0115, XEP-0172, XEP-0184, XEP-0308

(resending my previous message, because I forgot subject and it was unreadable in the archive because it did include HTML... sorry) Hi XMPP community, I have read and implemented some XEP which are in Draft status and now I have some suggestions to improve them. In particular I suggest the

[Standards] XEP-0013: Flexible Offline Message Retrieval missing purge and fetch in XML Schema

Hi, I am just implementing XEP-0013: Flexible Offline Message Retrieval and found that the purge and fetch elements are missing in the XML Schema. Just saying, if anyone cares and wants to correct the XEP. -- Christian

Re: [Standards] XEP-0013: Flexible Offline Message Retrieval missing purge and fetch in XML Schema

/ element in the http://jabber.org/protocol/offline; namespace, but it is nowhere explained/mentioned in the XEP. -- Christian Am 25.01.2014 um 22:56 schrieb Peter Saint-Andre: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/25/2014 02:27 PM, Christian Schudt wrote: Hi, I am just

Re: [Standards] BOSH patches, hopefully the last before final

Hi, is there any diff document similar to http://xmpp.org/extensions/diff/api/xep/0124/diff/1.10/vs/1.11rc2 ?? It would be easier to read. Christian Am 27.01.2014 um 16:21 schrieb Winfried Tilanus: Hi, These patches close the last open issues in XEP-0124 and XEP-0206. As far as I can

Re: [Standards] BOSH patches, hopefully the last before final

Hi, I've mentioned it already once here in this mailing list: I've had trouble connecting (and authenticating) through Openfire's BOSH implementation, when I don't know Openfire's domain, but only its IP address or hostname (which might be different to the domain name). It turned out, that

Re: [Standards] BOSH patches, hopefully the last before final

...@tilanus.com An: standards@xmpp.org Betreff: Re: [Standards] BOSH patches, hopefully the last before final -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 29-01-14 08:14, Christian Schudt wrote: Hi Christian, On a general notice: interop issues are a good reason to take a close look

Re: [Standards] XEP-0048: Bookmarks XML Schema error

'/ /xs:choice /xs:complexType /xs:element would be correct. I assume it is allowed to have storage url/ conference/ url/ /storage -- Christian Am 29.01.2014 um 20:50 schrieb Kim Alvefur: On 2014-01-29 20:31, Christian Schudt wrote: I just found an error in the XML Schema for XEP

Re: [Standards] BOSH patches, hopefully the last before final

Winfried Tilanus: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/29/2014 01:04 PM, Christian Schudt wrote: Hi, The problem we then had, when users wanted to connect with BOSH, is that our BOSH implementation (which is the one from Openfire) did not return a from attribute, which also

Re: [Standards] BOSH patches, hopefully the last before final

/45667 -- Christian Am 02.02.2014 um 13:01 schrieb Winfried Tilanus: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/01/2014 06:17 PM, Christian Schudt wrote: Hi, The whole issue with the 'from' attribute is no big problem of course. It was just something that caught my attention

Re: [Standards] BOSH patches, hopefully the last before final

: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/02/2014 01:29 PM, Christian Schudt wrote: Hi Christian, I am of course not in the position to decide about such things (may vs should vs must…) and I can hardly weigh up the real impact of such a change, but I thought status Draft is liberal

Re: [Standards] BOSH patches, hopefully the last before final

Looks good. Two things though:   1. Session Creation Response: My suggestions concerning the 'from' attribute obv hasn't made it :-(.. Well, so be it. But I found this sentence: 'to' -- This attribute communicates the identity of the backend server to which the client is attempting to connect.  

Re: [Standards] BOSH patches, hopefully the last before final

, Christian Schudt wrote: Hi Christian, Thanks for reviewing the patches and sorry for the delay in my response. 1. Session Creation Response: My suggestions concerning the 'from' attribute obv hasn't made it :-(.. Well, so be it. But I found this sentence: 'to' -- This attribute communicates

Re: [Standards] BOSH patches, hopefully the last before final

to advanced to Final and it should be more clear then, imo. Christian   Gesendet: Montag, 17. Februar 2014 um 16:29 Uhr Von: Winfried Tilanus winfr...@tilanus.com An: standards@xmpp.org Betreff: Re: [Standards] BOSH patches, hopefully the last before final On 17-02-14 15:33, Christian Schudt wrote: Hoi

[Standards] JSON-RPC over XMPP? / XEP-0335: JSON Containers

Hi, we are using a custom JSON transport protocol in order to JSON-RPC (http://en.wikipedia.org/wiki/JSON-RPC). It is very similar to XEP-0009 (Jabber-RPC), but uses JSON instead of XML. (It's much easier to transport complex return values or parameters with JSON-RPC than with XML-RPC.) Just

Re: [Standards] DRAFT: XEP-0152 (Reachability Addresses)

Hi,   nice to see a new specification moving to Draft status!   I have two minor improvements to the document: 1. The XML Schema is missing the xml:lang attribute for the 'desc' element. 2. The XML Schema has minOccurs='0' for the 'addr' element, although the text says MUST contain at least one

Re: [Standards] DRAFT: XEP-0152 (Reachability Addresses)

] DRAFT: XEP-0152 (Reachability Addresses) On 2/26/14, 4:37 AM, Christian Schudt wrote: Hi, nice to see a new specification moving to Draft status! I have two minor improvements to the document: 1. The XML Schema is missing the xml:lang attribute for the 'desc' element. Good idea. 2

Re: [Standards] XEP-0134: XMPP Design Guidelines

Hi, I always like up to date documents and specifications. So I vote yes :-) In my opinion, there are (too) many last-updated-2004 documents. (or at least mid-2000s) Or generally documents, which are really long in Draft state. (XEP-0001 says it can become Final after 6 months in Draft and 2

Re: [Standards] XEP-0045 to Final?

'/ /query /iq Maybe return a stanza error, if the requester is no member of the room. Christian Gesendet: Mittwoch, 05. März 2014 um 10:54 Uhr Von: Winfried Tilanus winfr...@tilanus.com An: standards@xmpp.org Betreff: Re: [Standards] XEP-0045 to Final? On 01-03-14 18:04, Christian Schudt wrote: Hi

Re: [Standards] XEP-0045 to Final?

behavior on email discussion lists? On 3/5/14, 10:16 AM, Christian Schudt wrote: Hi, could you elaborate on this proposal a little bit, please? Could you elaborate a bit on the use case and the need for it? I'm not saying it's bad or irrelevant, but XEP-0045 was not designed to solve every possible

Re: [Standards] XEP-0045 to Final?

, 05. März 2014 um 12:31 Uhr Von: Peter Saint-Andre stpe...@stpeter.im An: XMPP Standards standards@xmpp.org Betreff: Re: [Standards] XEP-0045 to Final? On 3/5/14, 11:25 AM, Christian Schudt wrote: Hi, Could you elaborate a bit on the use case and the need for it? I'm not saying it's bad

[Standards] XEP-0060: PubSub questions

Hi, I am implementing XEP-0060 and therefore working through the specification. A few things caught my attention and I'd like to hear your comments about it. 1. 6.5 Retrieve Items from a Node vs 5.5 Discover Items for a Node is a little bit unclear. Where's the difference really? I mean, if I

Re: [Standards] XEP-0060: PubSub questions

Hi, check here: http://xmpp.org/extensions/xep-0248.html So basically a PubSub implementation can neglect the associate and disassociate element. this is the application protocol specific error. it should be used in conclusion with not-authorized error from the RFC. Check here:

[Standards] XEP-0045: Multi-User Chat: Question/problem with modifying member list (e.g. in offline case)

Dear XMPP community, I recently had the following requirement for a Multi-User Chat implementation: User A (owner) and User B are in a members-only room. User A modifies the member list according to 9.3 and 9.5 Modifying the Member List and adds another User C to the member list and also

[Standards] XEP-0045: Multi-User Chat: Question/problem with modifying member list (e.g. in offline case)

Dear XMPP community,   I recently had the following requirement for a Multi-User Chat implementation:   User A (owner) and User B are in a members-only room. User A modifies the member list according to “9.3 and 9.5 Modifying the Member List” and adds another User C to the member list and also

Re: [Standards] Fwd: Minutes 2014-04-02

Regarding the advancement (to Final) of some XEPs, heres my opinion (as a developer/user of your XEPs): 184 Delivery Receipts could be clear about the message type, which must be used for receipts, although no type implies normal. 224 Attention: No concerns for Final. I also find it useful,

[Standards] XEP-0149: Time Periods vs. XEP-0060

Hi, I was reading through XEP-0149: Time Periods and saw, that it allows for multiple payloads in a PubSub item, i.e. an activity and a headers element. How is this compatible with 7.1.3.5 Bad Payload (If the item/ element contains more than one payload element, ...) of XEP-0060 PubSub?

Re: [Standards] XEP-0149: Time Periods vs. XEP-0060

I believe that the idea is to not treat the headers as payload. But it probably can cause incompatibility for servers that don't know about shim, so probably it would be really nicer to put it inside payload. The problem I am having is that I implemented the item element with a *single*

Re: [Standards] XEP-0149: Time Periods vs. XEP-0060

by the way, is not it a secret where do you implement these XEPs? http://sco0ter.bitbucket.org/babbler/

Re: [Standards] XEP-0045: Multi-User Chat: Question/problem with modifying member list (e.g. in offline case)

So you essentially want occupants to be informed about affiliation changes of users not in the room. Correct. Specifically I want occupants to be informed if a normal entity (i.e. non-member) becomes a member. But this is probably also considered an affiliation change from none to member.

Re: [Standards] XEP-0149: Time Periods vs. XEP-0060

I'd prefer, you do it because I have no account there. Am 13.04.2014 um 14:25 schrieb Sergey Dobrov: Could you maybe describe the issues you found here: http://wiki.xmpp.org/web/PubSubIssues#XEP-0060:_PubSub ? Or maybe you want me to do it instead of you? On 04/04/2014 23:02, Christian

Re: [Standards] Carbons - inbound messages to bare jid

Hi, Ive recently implemented XEP-280 for Openfire and have to say I like the bare JID behavior as it is. I dont see a reason to wrap the message in a forwarded extension for the bare JID case. Its easier for clients to use carbons, because they dont need to modify their message logic

[Standards] Some questions on MUC / XEP-0045

Hi, I have some questions on MUC: 1. Shouldn't the (initial) room subject message have Delayed Delivery, because the subject was set some time ago? It probably should, but the spec doesn't mention anything about it (7.2.16 Room Subject). 2. Is the actor/ actually needed in the muc#admin

Re: [Standards] Some questions on MUC / XEP-0045

2. Is the actor/ actually needed in the muc#admin namespace? There are no examples, but it's in the XML schema. Yes, see http://xmpp.org/extensions/xep-0045.html#example-90 Example 90 is in the #user namespace. 3. Can a client request multiple affiliations and get all affiliated

[Standards] XEP-231 Bits of Binary

Hi all, I am currently reading and implementing XEP-231 Bits of Binary and stumbled upon a possible bug: I noticed, that the SHA-1 hash 8f35fef110ffc5df08d579a50083ff9308fb6242, which is used in the examples, is the hash of the used Base64 string (iVBORw0KGgoAAA…..). The description of the

Re: [Standards] XEP-231 Bits of Binary

31.05.2014 um 21:20 schrieb Dave Cridland: On 31 May 2014 19:28, Christian Schudt christian.sch...@gmx.de wrote: I am currently reading and implementing XEP-231 Bits of Binary and stumbled upon a possible bug: I noticed, that the SHA-1 hash 8f35fef110ffc5df08d579a50083ff9308fb6242, which is used

[Standards] XEP-0319 vs. XEP-0256

Hi, I've read about XEP-0319: Last User Interaction in Presence and wonder where's the difference to XEP-0256: Last Activity in Presence? For me both cover the same use cases. When should a client use one over the other? Ok… for now XEP-0319 is still experimental, so a client would prefer

Re: [Standards] LAST CALL: XEP-0186 (Invisible Command)

I might be too late to the party, but I just began implementing it on client side and I think 3.1.2 Client Handling lacks some point: After becoming invisible the client should (automatically?) send directed presence (which equals the last undirected presence) to all entities in the

Re: [Standards] Cleaning the Wiki

Hi, I appreciate the idea to introduce an issue tracker for XEPs (like Jira). Reason: I (like many others) have raised several issues on this mailing list, most of them only minor ones like errors in XML Schemas, errors in examples, other inconsistencies or mere typos. But afaik none of them

[Standards] Whiteboarding with XMPP

Hi,   I am looking to implement whiteboard functionality in an XMPP client.   All I've found about it (protocol-wise) is this:   http://xmpp.org/extensions/inbox/whiteboard.html http://xmpp.org/extensions/inbox/whiteboard2.html http://xmpp.org/extensions/xep-0010.html (Whiteboarding SIG)

[Standards] Field Standardization for http://jabber.org/protocol/pubsub#publish-options

Hi, XEP-0060 specifies Field Standardization for publish-options with only one field (pubsub#access_model“): http://xmpp.org/extensions/xep-0060.html#registrar-formtypes-publish (16.4.5). However, XEP-0222 and XEP-0223 uses more fields for the

Re: [Standards] XEP-0332 Last Call comment summary

I follow 3a). Generally the whole document is hard to understand for me. Reasons for that are: 1. The introduction and motivation is written very abstract and it's hard to grasp the intent.    It could use some friendly How it works section, similar to other XEPs. 2. Some terminology (like XML

Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)

Hi, here’s my feedback for it. 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? No. In my opinion, XEP-0256: Last Activity in Presence already covers everything, which is needed for this use case. XEP-0012 also says something about

Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)

I like Florian’s idea! It won’t mess up with existing XEP-0256 implementations and if someone really feels he can only deal with absolute timestamps he could use that optional attribute. It’s way easier to implement as opposed to implement a whole new XEP (+ abstraction layer, which deals with

Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)

Hi, Receiving query xmlns='jabber:iq:last' seconds='903’/ can mean either the user went idle $TIME_STANZA_SENT - 903 seconds or user went offline at that point. You can’t know it solely based on this stanza. You’d require further presence information to resolve the semantic overload. In

Re: [Standards] Blocking command and Privacy Lists

+1 Seems reasonably for me. Also this line seems weird for me: If the foregoing suggestions are followed, the user will appear offline to the contact. I think it should be „the contact will appear offline to the user“, but it could be removed anyway, if Sam’s suggestion takes place.

Re: [Standards] Reusing thread in chat sessions after receiving gone/ chat state?

I hope I didn’t ask dumb questions... An answer would be appreciated! Thanks. Christian Am 11.01.2015 um 20:08 schrieb Christian Schudt christian.sch...@gmx.de: Thanks for your answer! I’ve had a lengthy discussion with another developer about „one-to-one chat sessions“ in general and we

Re: [Standards] XMPP Security

Hi Michael, So my question is: What is actually the problem with the latest XMPP end-to-end encryption and signing approaches and why isn’t it safe against malicious server operators and sniffing of direct client-to-client transmissions? And is there anything else I should know? The XMPP

Re: [Standards] Reusing thread in chat sessions after receiving gone/ chat state?

Thanks for your answer! I’ve had a lengthy discussion with another developer about „one-to-one chat sessions“ in general and we are having difficulties to understand what is really meant by this term. We’ve read the following documents/paragraphs which involve „chat sessions“:

Re: [Standards] MUC 2

Dave, maybe could you (or somebody else) elaborate on the shortcomings and the different demands of things like buddycloud you have discussed for those who didn't attend the summit. Also what's so bad about multiple parties chatting via a third party chat service (your 2nd use case)? For me

[Standards] Reusing thread in chat sessions after receiving gone/ chat state?

Hi, I am confused about the proper handling of „one-to-one chat sessions“. Specifically the following documents partially contradict each other: http://xmpp.org/extensions/xep-0201.html#chat http://xmpp.org/extensions/xep-0085.html#bizrules-threads XEP-0201 says, a client SHOULD NOT destroy a

[Standards] Service Discovery + dependent features

Hi all, there are several features/extension protocols, which are dependent on others, e.g. urn:xmpp:carbons:2 == urn:xmpp:forward:0 http://jabber.org/protocol/si/profile/file-transfer == http://jabber.org/protocol/si http://jabber.org/protocol/caps == http://jabber.org/protocol/disco#info

Re: [Standards] Service Discovery + dependent features

Thanks Florian, generally I agree, but please read my answers below. urn:xmpp:carbons:2 == urn:xmpp:forward:0 http://jabber.org/protocol/si/profile/file-transfer == http://jabber.org/protocol/si http://jabber.org/protocol/caps == http://jabber.org/protocol/disco#info

Re: [Standards] Service Discovery + dependent features

Ok, makes sense as well. I conclude from this discussion, that there are no extension protocols which MUST be coupled with another one in service discovery (i.e. if A then B), although for some they SHOULD (e.g. if urn:xmpp:jingle:transports:ibb:1 then urn:xmpp:jingle:1). Thanks. -Christian

[Standards] XEP-0022: Message Events replacements

Hallo, XEP-0022 Message Events has been obsoleted and says: Note: More modern protocol extensions for this functionality have been defined in Chat State Notifications (XEP-0085) [1] for the composing and offline events and in Message Delivery Receipts (XEP-0184) [2] for the delivered and

Re: [Standards] XEP-0184 type attribute on message

I have interpreted and implemented it as „normal, too. I have also suggested it to be more clear a year ago here, but unfortunately nobody cared: http://mail.jabber.org/pipermail/standards/2014-January/028479.html - Christian Am 28.02.2015 um 14:43 schrieb Daniele Ricci

Re: [Standards] XEP-184: Message Delivery Receipts - Message Type of Ack Messages

Hi, I think Variant 1 violates XEP-0045: When receiving a „request“ message from an occupant in a MUC room (type=groupchat), the receiver would send a receipt to the sender directly, not to the MUC room, by simply sending it to the „from“ attribute of the request, which is a full JID. It’s

Re: [Standards] XEP-184: Message Delivery Receipts - Message Type of Ack Messages

Sounds good to me… except XEP-0045 still uses „MUST NOT“ for groupchat-type in private occupant-to-occupant messages. Might be inconsistent wording across the two specs. Furthermore I can understand the issue raised in your linked post [1]: In software an empty String and a null reference

Re: [Standards] Nonzas: What are they and do we need them?

For me personally, the contra-Nonza arguments did not convince me. It appears that nothing in the specification prevents you from using Nonzas after resource binding with BOSH. XEP-206 3. only says SHOULD contain. I also don't see why they would introduce a bunch of conceptual and

Re: [Standards] DRAFT: XEP-0319 (Last User Interaction in Presence)

: Re: [Standards] DRAFT: XEP-0319 (Last User Interaction in Presence) Hi Christian, hi Kim,   On Fri, Apr 10, 2015 at 2:05 PM, Kim Alvefur z...@zash.se wrote:On 2015-04-09 21:54, Christian Schudt wrote: 2. XEP-0256 should be updated (Appendix A): „superseded by XEP-0319“. Or will it become

Re: [Standards] DRAFT: XEP-0319 (Last User Interaction in Presence)

Hi, while implementing this, I’ve recognized a few issues: 1. It should link to XEP-0012 and clarify it’s correlation to 4. Online User Query“. I guess if a client queries an idle client via XEP-0012 it should yield the same result (in seconds) as the idle time broadcast via XEP-0319, no? So

Re: [Standards] Advancing XEP-0280 Carbons

I appreciate the idea, that it should advance to Draft. I’ve implemented it in Openfire and didn’t saw any major flaws in the spec. However, while I did, I often thought „why is it restricted to chat-type only?“. I think enhancing it to „normal“ messages is a good idea, e.g. to let

Re: [Standards] Request HTTP upload slots over XMPP

Hi, Letting the component act as a Jingle File Transfer receiver was my original idea as well. However if you try to find any jingle ft implementations you'll see that there basically aren't any. (To my knowledge there is Gajim, Conversations and Swift (beta) and Swift is currently

Re: [Standards] Request HTTP upload slots over XMPP

Hi, I agree that XMPP is lacking such a specification („MUC File Transfer“, „Offline File Transfer“). Maybe it’s even better, if the client and server could negotiate the transport method first, so that the client could choose between „HTTP Upload“, SOCKS 5 Upload (XEP-0065)“ or „In-Band

Re: [Standards] Minor clarifications to XEP-0198

Hi, What about a client sending delayed stanzas upon stream resumption? Should it add Delayed Delivery as well? E.g. client sends a message, but no ack is received, so it stays in the unacknowledged queue. Eventually client detects a broken connection, reconnects and resends the

Re: [Standards] Move CSI to Last Call (Proposed)

I think this has already been discussed once, but wouldn't it be more intuitive to use IQ semantics for this instead of sending a message which confirms the (de)activation? CSI feels similar to XEP-0186: Invisible Command and it uses IQ as well. I'd just appreciate consistency among XEPs and

Re: [Standards] File Transfer Roadmap

Hi, there's another related XEP: XEP-0137: Publishing Stream Initiation Requests. I am not sure if Jingle File Transfer should cover the following use cases as well, but what I am reading and hearing more and more (in this list, in my company, in forums) are the following two requirements: 1)

Re: [Standards] Proposed XMPP Extension: Mobile Considerations

Hi,   the question of whether we need a new mobile XEP, or just update the old one (potentially with entirely new text). I'd be very interested in hearing any opinions on this one. I'd prefer to have an updated version of XEP-0286, just to keep it simple. Particularly because some parts of it

Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final

Hello, > 1. What software has implemented XEP-0301? Please note that the protocol > must be implemented in at least two separate codebases (at least one of which > must be free or open-source software) in order to advance from Draft to > Final. [1] I’ve implemented it in Babbler Java client

Re: [Standards] Stream Management and BOSH

While BOSH has it's own acknowledgement mechanism, there are still some subtle differences when it comes to resumption: With resumption you don't need to: - re-request the roster - resend presence - re-establish state information (as mentioned in XEP-0198) I see performance benefits (less HTTP

Re: [Standards] Deprecating Privacy Lists

My explanation: Most developers just don't want to write specifications. They don't consider it to be their job. Similar like they also shy at writing documentation or even comments. Developers are lazy in this aspect. Developers just want to code, fix bugs, create a nice UI, apply logical

Re: [Standards] Proposed XMPP Extension: Message Deletion

Hi, the wording is very inconsistent. It sometimes says delete/deletion, sometimes remove/removal, even when referring to the same use case (removal request“, deletion request“). Even the namespace (delete) is different from the element name (remove). I suggest to clean this up. I am no

Re: [Standards] XEP-0280: vs.

Hi, > I get your point. But it feels wrong to define nearly identical > extension elements in two XEPs. The author of xep334, Matthew Wild, > already expressed his willingness to change xep334 so that it can be > re-used in xep280. Therefore I'm all for changing xep334, then issue a > last call

Re: [Standards] NEW: XEP-0363 (HTTP File Upload)

Am 29.09.2015 um 02:02 schrieb Evgeny Khramtsov : > Thu, 24 Sep 2015 13:10:44 +0300 > PG Stath wrote: > >> In general I think that XMPP might be missing developers not because >> features are missing but because of non compatible extensions lists >> and

Re: [Standards] NEW: XEP-0363 (HTTP File Upload)

> Seems like I'm constantly repeating on the list... > Do those implementation resolve the following problems: > 1) MUC friendly > 2) Offline support > > From what I know Jingle FT specs don't provide a solution for those > problems. Funny, I've brought up exactly these two problems, too:

Re: [Standards] Deprecating Privacy Lists

I agree to Florian, Goffi etc... XEP-0016 is complex, but powerful. I see no reason to deprecate it, just because there's a similar XEP (0191). In our company we've had an requirement to be invisible to certain roster groups. This is not solvable with other XEPs. The other mentioned use case

Re: [Standards] Deprecating Privacy Lists

> http://mail.jabber.org/pipermail/standards/2014-December/029430.html > The problem is that it's unclear (to me) how to map XEP-0016 rules that > block some kinds of stanzas but not others. If that's all, I think XEP-0191 §5 only lacks a more precise mapping of 0016 privacy list to block

Re: [Standards] Deprecating Privacy Lists

> Hmm, not sure if you can translate this to xep191. What happens if a > xep191 client removes a jid entry which was added by the server because > the jid is the 'enemies' group? The server should map in both ways, i.e. reflect changes to XEP-0191 into the privacy lists, and also reflect

Re: [Standards] 2016 Compliance Suites

> Please discuss. I think the outcome of that discussion probably affects what > should go into the suites. I never really understood the purpose of these "suites", nor did I feel the XSF is pushing them (last one is Deferred). Nonetheless, here are my thoughts (assuming it should be some kind

[Standards] RFC 6120 § 3.3 Reconnection

Hi, I had a small discussion recently about RFC 6120 § 3.3 Reconnection [1]. It states "It can happen that an XMPP server goes offline unexpectedly“… and recommends a first reconnection after max. 60 seconds. We considered this section to not fit the reality, because in reality it’s rarely

Re: [Standards] Notification of lost membership of non participants in MUC

I think this is already covered by Example 195, isn't it? (and similarly 176, 190)   -- Christian   Gesendet: Dienstag, 17. Mai 2016 um 09:40 Uhr Von: "Daniel Gultsch" An: "XMPP Standards" Betreff: [Standards] Notification of lost membership of non

[Standards] IBB fallback in SI file transfer

Hi,   I've had a brief discussion [1] about how the fallback to IBB works in SI filetransfer.   It's mentioned twice in XEP-0096 and it reads like a fallback to IBB is intended to work but it lacks a proper description about how it actually works.   My interpretion is this:   1. Initiator

Re: [Standards] SASL's DIGEST-MD5: host or domain?

Hi,   when using Java's SASL API [1], you would use the following to create a SASL client for DIGEST-MD5 authentication:   Sasl.createSaslClient("DIGEST-MD5", authzid, "xmpp", serverName, null, cbh);   The fourth parameter "serverName" will be used in the digest-uri It's documented as [1]:

Re: [Standards] LAST CALL: XEP-0333 (Chat Markers)

Hi, > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? Yes. > 2. Does the specification solve the problem stated in the introduction and > requirements? Yes. > 3. Do you plan to implement this specification in your code? If not,

Re: [Standards] LAST CALL: XEP-0334 (Message Processing Hints)

> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? Partly. XEP-0079: Advanced Message Processing already solves the same problem. dropforward => no-copy dropstored => no-store > 2. Does the specification solve the problem

[Standards] BCC addressing in XEP-0033: Extended Stanza Addressing

Hello,   XEP-0033: Extended Stanza Addressing § 6 (8.) [1] says: "Each 'bcc' recipient MUST receive only the associated with that addressee."   However Example 9. [2] sends the message to a BCC recipient, which contains all addresses except the BCC addressee itself.   I think Example 9 is

[Standards] Delayed Delivery on Inbound Subscription Requests

Hi,   I just wished there was a Delayed Delivery element (XEP-0203) on inbound presence subscription requests, for the case the requested contact is offline, or ignoring the request for some time. You don't know when the reqester originally sent the subscription request.   RFC 6121 § 3.1.3

Re: [Standards] Is an IQ sent by the client to its bare JID equal to sending it without 'to' attribute?

Hi Florian, > Subject says it all: Is an IQ request sent by the client to its bare JID > equal to sending it without 'to' attribute? > > I've looked at RFC 6120 § 8.1.1.1. and 10.3.3., but couldn't get an > answer out. > I think § 10.3.3 is clear on this topic. I’d answer your question with

Re: [Standards] Unread syncing

Can't XEP-0333 used for that?   A sends a message to B with a "read request". B reads the message and sends a "read receipt" back to A.   The read receipt is stored in the server archive normally as any other (chat) message.   Clients can query the archive in a normal way, e.g. all message

Re: [Standards] Unread syncing

Isn't MAM supposed to address the issue of "synchronizing multiple resources/clients", so that every client sees the same history of (chat) messages, even if they were originally delivered to another client?   If that syncing works for chat messages, it should work for "read receipt" messages

Re: [Standards] Unread syncing

> Except that they’re not chat messages, so won’t be stored, and if they were > you’d be potentially up to doubling the size of your archive (I guess adding > a quarter to, on average) as you fill it with read markers - unless you want > to customise the MAM service to understand unread state,

[Standards] urn:xmpp:hashes:2

Hi, what exactly was the reason for a namespace bump for urn:xmpp:hashes:1 => urn:xmpp:hashes:2 ? I couldn’t find any discussion about it in the Last Call [1], nor do I see any real difference to the previous version 0.4 [2]. The only difference I see is, that the document now explicitly

Re: [Standards] XEP-0369: xmlns in disco#info feature elements

> The use of a different namespace on in a disco#info reply worries > me. This doesn’t work with XEP-0115 (I hope, because <{urn:xmpp:mix:0}feature/ >> and <{http://jabber.org/protocol/disco#info}feature/> are fundamentally > different elements) and is, as far as I know, specified nowhere as a

Re: [Standards] XEP-0392 angle generation

> If we would be choosing a modern hash function, something from the SHA3 family > or blake would be more sensible. Please consider using either SHA-1 or SHA-256, not blake. The reason: It at least makes Java implementations easier, because those are available on every implementation of the

Re: [Standards] XEP-0060: max-nodes-exceeded error is not described.

Hi,   Openfire does implement it.   -- Christian   Gesendet: Donnerstag, 08. Februar 2018 um 03:26 Uhr Von: "Peter Saint-Andre" <stpe...@stpeter.im> An: standards@xmpp.org Betreff: Re: [Standards] XEP-0060: max-nodes-exceeded error is not described. On 2/7/18 2:04 AM,

[Standards] Entity Capabilities 2.0

Hi, I’ve implemented Entity Capabilities 2.0 (XEP-0390) and like to share some thoughts about it here and in the following link. I think it could be interesting for library developers as well as the author(s) of XEP-0390:

Re: [Standards] Entity Capabilities 2.0

Hi Jonas, > You are referring to the processing entities side? The entity is free to > choose from the set as it desires. The order of elements inside the hash set > is undefined. It could for example iterate a list of hash functions in > descending order of preference and look for hashes in

  1   2   >