Hi all,
Implementing this one has thrown up a few observations.
1) There's a note in 3.2 that says that if resumption fails, the server
MUST include the failure in the response, and then proceed to process the
bind request. But, it's only just finished saying that the bind request has
to be processed before sending the response. I'm being picky, of course.
2) 3.2.1 says that the <tag/> SHOULD be included verbatim, which makes
sense - but then also says it SHOULD (recommended, but same thing) be a
prefix. These have the same force, so why are they distinct? Do clients
expect a substring here or a prefix? Obviously a prefix *is* a substring,
but I'm thrown by this being included twice with RFC 2119 language.
3) 3.2.1 also says the syntax SHOULD be "tag" / "rando bit", but then
follows this with Example 4, which shows a dot instead. This makes me
wonder why there's a SHOULD there. Do clients expect a solidus or a period?
Do they care? If not, why is this a SHOULD? Why have *three* SHOULDs
relating to the same thing? The last one seems to encompass the first two,
and then it's ignored in the examples.
4) When discussing the <bound/> element 3.2.1 has a SHOULD for including
the MAM state - is this indicating that servers supporting Bind2 SHOULD
implement MAM, and in particular the urn:xmpp:mam:2 version? Clients do not
request this implicitly, unlike the other interactions, making Bind2
intrinsically bound (if you'll pardon that pun) to a specific MAM version -
this is evident in the schema, in fact.
- Note that Conversations at least appears to only initiate Bind2 if MAM is
supported - although doesn't appear to have any problem if the MAM summary
element is omitted - making it appear as though MAM support is a MUST,
despite including the metadata being a SHOULD still... Though I think the
only way Conversations could know if via the caps feature hash in features,
suggesting bind2 never works first time.
5) Similarly, 3.2 indicates that the server MUST do one thing that requires
MAM, and another thing that relies on it being supported. 3.2.1 somewhat
suggests that XEP-0280 and XEP-0352 are also mandatory to support, though I
think that's just cumbersome language. Interestingly the document metadata
says it does depend on MAM and Carbons - but not CSI. I don't think it does
depend on Carbons, or should depend on MAM (but probably does).
6) If an inline feature request is unsupported or unrecognised, what does
the server do? Ignore it silently? This is of particular interest because
some inline feature requests don't have a confirmation they succeeded.
7) If authentication is successful, but bind fails, does the server say
that authentication has failed? With what error? Or, is bind2 always
expected to succeed? Not including the <bound/> element appears to trigger
Conversations into thinking the session has not been bound, even if the
authorization-identifier is a full jid. But! XEP-0388 says that a full jid
here means that resource binding has occurred (that was intentional; but
clearly that's not what's been implemented, so I'd better remove that!)
8) Unexpectedly, the <inline/> of the bind2 feature is mandatory even when
empty; was this intentional?
9) 3.2.1 is entitled "resource identifier generation", but continues into
discussing the XEP-0280 integration for example.
Fixes:
I think we may find we're doomed to stick with this version, but concretely:
a) I think I'd have MAM advertised within <inline/>, and optional. This is
a breaking change, though we could circumvent it by saying that bind2 can
do the MAM stuff unilaterally, and clients SHOULD include it if they want
it - but that depends on what servers might do if they're faced with a MAM
request they don't understand.
b) All inline features ought to have explicit confirmation, I think, but
that's a breaking change. We could also include a generic inline feature
failure indication ("<failed var="urn:xmpp:failed-extension:0"/>") to say
that a requested feature has failed (or been unrecognised) and made no
changes. And we could make an explicit confirmation at least a SHOULD for
future servers.
c) I'd love to tidy up some of the specification language generally.
Fun (ish) fact: I'll almost certainly have an extraneous inline <feature
var="urn:xmpp:mam:2"/> for Openfire because MAM is a plugin, and
special-casing it for Bind2 will be rather awkward.
Dave.
Hi all!
MUST a pubsub service advertise <feature var='
http://jabber.org/protocol/pubsub'/> with service discovery 'info'
responses?
XEP-0060 shows this being done in examples 8 and 18, but there is no
normative text that defines this.
The feature is not listed in its "Feature Summary" section, and is not
registered with the Registrar.
There has been a discussion around this in the XSF's Discussion chat room
today (logs here:
https://logs.xmpp.org/xsf/2025-10-03#2025-10-03-f173fd843da7c3ee ).
There are implementations in the wild that require that feature to be
advertised, while other software doesn't advertise it.
Given the conflicting implementations, I believe that it would be good to
have normative text be added to XEP-0060 to clarify things. I'm not sure
yet what that text should be.
What do you think?
Kind regards,
Guus
Hi, I have a question about the handling of payload types in XEP-0167. The spec says that "The session-accept message SHOULD include a subset of the payload types sent by the initiator". When are two payload types considered equal? This is not obvious to me because there are optional attributes as well as parameters. I would think that definitely name, clockrate, and id need to match, but I'm not sure about the other attributes and the parameter
values. I think a precise answer to this is needed to determine whether one list of payload types is a subset of another, and therefore whether a given session-accept meets this part of the specification.
Here is an example from a call between two XMPP clients, Dino and Monal
The session-initiate message sent by Dino includes this list of payload types:
<payload-type id='111' channels='2' clockrate='48000' name='opus'>
<parameter name='useinbandfec' value='1' />
</payload-type>
<payload-type id='112' clockrate='32000' name='speex' />
<payload-type id='113' clockrate='16000' name='speex' />
<payload-type id='114' clockrate='8000' name='speex' />
<payload-type id='9' clockrate='8000' name='G722' />
<payload-type id='0' clockrate='8000' name='PCMU' />
<payload-type id='8' clockrate='8000' name='PCMA' />
And the session-accept message sent by Monal includes this list of payload-types:
<payload-type clockrate='8000' name='PCMU' id='0' />
<payload-type channels='2' id='111' clockrate='48000' name='opus'>
<parameter name='profile_level_id' value='4325392' />
<parameter name='useinbandfec' value='true' />
<parameter name='minptime' value='10' />
</payload-type>
<payload-type clockrate='8000' name='G722' id='9' />
<payload-type clockrate='8000' name='PCMA' id='8' />
This currently causes a problem in Dino because one of the responder's payload types (opus) is judged to not be present in the list of sent payload types, because it is not (strictly speaking) equal to any of the sent payload types, because it has a different number of parameters.
In this example, is the responder violating the spec by including extra parameters for the opus payload type, or is the initiator being too strict when comparing the payload types for equality?
Thanks, Jacques
Good evening.
I am developing a journal publishing system with XMPP support.
I am experimenting with the commenting system of XEP-0277, and,
according to Movim, it seems that I fail to create nodes with
appropriate properties.
I suppose that I fail, because Movim indicates that comments are closed
for posts that I publish.
I would be glad for any help.
Thank you.
Schimon
Hi,
There are multiple filetransfer XEPs like e.g. XEP-0385 / XEP-0447 / XEP-0396
They define a hash element, but its not clear to me if the hash is after encryption or before, if the file should be transferred encrypted.
If it is after encryption, the hash can only be used in edge cases for caching purposes (look up if we have this file already) because encryption keys change with each file transfer hence the hash of the encrypted file would change.
Regards
Philipp
Hello!
Section 5.2 of XEP-0060 'Publish-Subscribe' describes how disco#items is
used to discover nodes. Most of that section describes node discovery in
node hierarchies and collection nodes.
In version 1.12 of XEP-0060 text about collections was moved to XEP-0248
'PubSub Collection Nodes'. This specification contains a smaller paragraph
on node discovery (which is also numbered 5.2).
I would like to see the complexity of XEP-0060 be reduced. I believe that
most, if not all of its section 5.2 should be moved to XEP-0248 and removed
from XEP-0060.
The suggested change should not affect backwards compatibility, as it
doesn't result in a change of behavior: as far as I can see, the text only
applies to hierarchies and collection nodes. The change therefore is
permissible even considering XEP-0060 is Stable.
Is there any objection to this? What would relevant Node Discovery content
for XEP-0060 be (other than a reference to XEP-0248)?
Kind regards,
Guus
Good Morning Council Members,
the next XMPP Council Meeting will take place on, Tuesday, September
30 2025 at 15:30 UTC in xmpp:council@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
· UPDATED: XEP-0317 (Hats)
https://xmpp.org/extensions/xep-0317.html
· Proposed XMPP Extension: Pubsub Node Bookmark
https://xmpp.org/extensions/inbox/pubsub-node-bookmark.html
4) Items for voting
a) Proposed XMPP Extension: Pubsub Node Bookmark
https://xmpp.org/extensions/inbox/pubsub-node-bookmark.html
b) XEP-0045: Fix 'roomsecret' field inconsistency
https://github.com/xsf/xeps/pull/1464
5) Pending votes
Dan on:
XEP-0060 / XEP-0248: Improve separation of 'collections'
XEP-0060 & XEP-0248: Default node-type specific configuration
XEP-0070: extend security section
Issue Last Call on 'XEP-0440: SASL Channel-Binding Type Capability'
Daniel and Marvin on:
XEP-0060 / XEP-0248: Improve separation of 'collections'
XEP-0060 & XEP-0248: Default node-type specific configuration
See the spreadsheet of doom:
https://docs.google.com/spreadsheets/d/1oAHUqBdlkobDcmfQ-YRMfZHGQLMWEdOFuEU…
6) Date of Next
7) AOB
8) Close
Hi all,
The 'roomconfig_roomsecret' data form field definition is not consistent.
In XEP-0045, examples 157 and 165 use 'text-private'. The registry
submission in paragraph 16.5.3 uses 'text-single'.
The registry itself (https://xmpp.org/registrar/formtypes.html) uses
'text-private'.
To me, this seems to boil down to a mistake in paragraph 16.5.3, which
should be corrected to 'text-private'. Given that the XEP is Stable, can we
bluntly do that?
Kind regards,
Guus
