[Standards] Call for Experience: XEP-0198: Stream Management
jonas at wielicki.name
Tue Feb 11 15:36:43 UTC 2020
On Dienstag, 11. Februar 2020 16:21:02 CET Jonas Schäfer wrote:
> The XEP Editor would like to Call for Experience with XEP-0198 before
> presenting it to the Council for advancing it to Final status.
> During the Call for Experience, please answer the following questions:
> 1. What software has XEP-0198 implemented?
aioxmpp (LGPLv3+) has an implementation , which I did from scratch when
building the library (twice). It is, to my knowledge, independent of all the
other implementations out there.
> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0198? If so, please describe the problems and, if
> possible, suggested solutions.
We’ve seen several times that people get the counters wrong. It turns out that
it is harder than you’d think to find the right place to count stanzas and
what even counts as a stanza.
I’m not sure what we can do there specification-wise. It is all there, but it
still seems hard to get right on the first attempt. Maybe some pseudo-code
would do? I don’t know.
> 3. Is the text of XEP-0198 clear and unambiguous?
I think so.
> Are more examples needed?
I don’t think so. As mentioned above, some cases around counter handling may
benefit from pseudo-code, though I’m not sure if such code can be written in a
way which is useful for different software architectures.
> Is the conformance language (MAY/SHOULD/MUST) appropriate?
> Have developers found the text confusing at all?
AFAIK not confusing.
> If you have any comments about advancing XEP-0198 from Draft to Final,
> please provide them by the close of business on 2020-02-25. After the
> Call for Experience, this XEP might undergo revisions to address
> feedback received, after which it will be presented to the XMPP
> Council for voting to a status of Final.
> You can review the specification here:
> Please send all feedback to the standards at xmpp.org discussion list.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards