On 2/18/10 8:44 PM, "Peter Saint-Andre" <[email protected]> wrote:
>>> * To have "acks" without implement XEP-0184 Message Receipts or similar >> >> What do you do if you don't receive the ack? Resend? > > IQs MUST be acked or errored according RFC 3920. Bad client, bad! > > Now the ack or error might be lost. Again, there are no guarantees here. > But it's more likely that the subscriber supports 3920 semantics for IQs > than that it supports XEP-0184. There are a myriad of ways the original IQ or the ack could get lost. My point is that the response does not serve any value to the sender, since I don't believe there is anything useful to be done when the sender does not receive the ack. Resending is almost always going to be wrong. >> Headlines to unknown resources aren't well-defined. To be logically >> consistent, they should be dropped. > > Yes, that needs to be clarified in 3921bis. Currently it says the > following for the case of message to full JID, no such resource: > > o For a message stanza of type "chat", "headline", or "normal", the > server SHOULD treat the stanza as if it were addressed to > <u...@domain> as described in the next section (but without > modifying the value of the 'to' attribute). Heh. It turns out that type='groupchat' is exactly what you want. From section 8.3.1.1 of 3921bis: For a message stanza of type "groupchat", the server MUST NOT deliver the stanza to any of the available resources but instead MUST return a stanza error to the sender, which SHOULD be <service-unavailable/>. -- Joe Hildebrand
