[Standards] RFC 6121 ambiguous stanza processing rules

Hi, I have difficulties understanding the correct server side processing of inbound „unsubscribe“ and „unsubscribed" presence, because RFC 6121 is ambiguous here: - § 3.3.3. Server Processing of Inbound Unsubscribe MUST first check if the user's bare JID is in the contact's roster with

Re: [Standards] Call for Experience: XEP-0066: Out of Band Data

Hi, see my answers below. > Am 25.02.2020 um 16:52 schrieb Jonas Schäfer (XSF Editor) > : > > The XEP Editor would like to Call for Experience with XEP-0066 before > presenting it to the Council for advancing it to Final status. > > > During the Call for Experience, please answer the

Re: [Standards] XMPP Council Minutes 2018-04-11

Hi, here some implementation for XEP 131 and 141 because you said „doesn’t have enough implementation“. => XEP-0001 requirement (at least two implementations) is fulfilled. — Christian > 4) Advance to Final XEP-0131: Stanza Headers and Internet Metadata - >

Re: [Standards] Call for Experience: XEP-0131: Stanza Headers and Internet Metadata

> 1. What software has XEP-0131 implemented? 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.

Re: [Standards] Call for Experience: XEP-0141: Data Forms Layout

> 1. What software has XEP-0141 implemented? 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. I’ve implemented it in Babbler,

Re: [Standards] Call for Experience: XEP-0066: Out of Band Data

  >> TL;DR: The purpose is/was to transfer files in case the receiver is offline. > Given the primary mechanism in -66 is iq-based, I don’t think this is true, > or I misunderstood your point. Maybe you are right. It was just a guess, because someone asked for the purpose of 0066. Because

Re: [Standards] user is set online on input without unlocking the device

Hi, I agree with you about the expected behavior. But the behavior when changing the status is specific to the client implementation and I think this "lock screen" behavior is nowhere specified by XMPP (at best is should be specified in some "best practices" informational XEP or in an

Re: [Standards] Private Data storage discrepancy

Hi,   although I can't give you a good answer here, this is probably related to the issue I mentioned during the Call for Experience.   It's unclear if a single pubsub item should contain only one bookmark or multiple. The one bookmark per item appraoch seems to be favoured by XEP-223: "the

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

Hi, my original question quickly drifted away to a discussion about the use case of serverless messaging. But I feel my concern was not addressed: 1. Why can’t the receiving entity include its Entity Caps as stream feature as described in XEP-0115? 2. Why should we instead use disco#info? I

Re: [Standards] Call for Experience: XEP-0066: Out of Band Data

> However I'm not really sure what the intended purpose of this XEP is > and if we still have a use case for that purpose. I understood the purpose as follows: a) You upload some file to a server (nowadays you could also use XEP-363). b) You send a message to a contact with XEP-0066. c) Contact

Re: [Standards] Call for Experience: XEP-0048: Bookmarks

> 1. What software has XEP-0048 implemented? 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. Enough. > 2. Have developers experienced any problems with

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

> Are people still using this technology? In my experience, it was a fun > experiment in ~2006 but didn't work well in practice: too chatty over > the network, presence never worked correctly, you'd send a message to > someone and it turns out they weren't available, etc. I was considering

[Standards] 0174 Serverless Messaging: Discovering Capabilities

Hi, I find the whole passage „Discovering Capabilities“ of Serverless Messaging [1] a bit confusing. 1. Why can’t the receiving entity include its Entity Caps as stream feature as described in [2]. 2. I can see the slight optimization of including disco#info data as stream feature (similar

Re: [Standards] XEP-0153: Encoding of photo hash?

ng > clients would support any such deviations. > > > > From: Standards <standards-boun...@xmpp.org> on behalf of Christian Schudt > <christian.sch...@gmx.de> > Sent: 24 February 2018 19:22 > To: XMPP Standards > Subject: [Standards] XEP-0153: Encoding of photo hash? > > Hi list, > > I’ve got a question about XEP-0153. Its XML schema defines that the photo > hash is encoded as Base64: > >

[Standards] XEP-0153: Encoding of photo hash?

Hi list, I’ve got a question about XEP-0153. Its XML schema defines that the photo hash is encoded as Base64:

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

[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] 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,

Re: [Standards] XEP-0392: Consisten Colors - Error in Test Vectors?

Hi Paul,   I don't think there's an error in specification, because I've successfully implemented it (and the test vectors).   Have a look at my Java implementation:  

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

Hi,   an alternative would be to assume that all stanzas have been received, if the h value is higher than the number of sent stanzas.   E.g. if client sends 10 stanzas and server responds with h='20', the client would assume that the server has received all 10 stanzas. That means "clearing"

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

Hi,   please consider this issue: https://github.com/xsf/xeps/issues/581   I kindly ask the authors of XEP-0060 to describe the "max-nodes-exceeded" error in the specification or to remove it from the XML schema, if it should not be used.   Although one can guess, when this error should be

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

[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] 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

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] 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,

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

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

[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

[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

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] 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

[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] 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] 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

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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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

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

[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

[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] 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

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?

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] 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“:

[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

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] 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] 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] 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

[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

[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)

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

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

[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

[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

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] 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] 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

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] 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] 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/

[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] 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-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-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

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] 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

  1   2   >