Good day.
I was wondering of formatting the XML documents for XEPs to Atom
Syndication Format.
This would allow people to subscribe to selected XEPs and to receive
automatic updates.
The XHTML pages would remain the same, as they are today, once the XSLT
stylesheet be adapted to the new Atom format.
This is a recent realization which I have had, during drafting a new
publishing system in which each page, be made of Atom Syndication
Format, including fixed pages such as "about", "contact", and "help",
with an exception for an OPML page.
gemini://woodpeckersnest.space/~schapps/journal/2025-07-03-rivista-to-be-atom-based-publishing-system.gmi
https://portal.mozz.us/gemini/woodpeckersnest.space/~schapps/journal/2025-0…
Please advise.
Kind regards,
Schimon
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Data Policy
Abstract:
This document specifies metadata on how an entity handles its data
(encryption, data retention, etc).
URL: https://xmpp.org/extensions/inbox/data_policy.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Hi all,
I'm currently implementing SASL2 (et al) into Openfire, which is amusing
since I had the first implementation there years ago.
In doing so, I've a few comments, most of which are directed at past-me of
course. Past-me is an idiot, and I have ample evidence of this.
1) One of the changes from the original SASL profile is that there's no
need for (and mention of) the "equals hack" to indicate no data. Should
this be explicitly called out?
2) The user-agent - this is a SHOULD (well, RECOMMENDED, which means the
same thing). The consequences of not including it are that other
specifications might rely on it - the same as the id, which is also SHOULD.
I dislike the amount of SHOULD here, it feels like the "outer" SHOULD is
sufficient, and a user-agent with no id attribute is a bit useless.
3) The id string given MUST be a UUIDv4. What should the server do if it
receives a non-UUID, or a UUID of a different type to v4? A purist might
reject it, but this seems wrong - what guidance can we put here? If we
accept any old string, and it's not a UUIDv4, what happens?
4) Second para of Initiation talks about an authorization string, but
there's no such string defined. Was this intended to mean the requested
authorization identity in the SASL mechanism? That's an interesting
challenge, especially from just the initial-response which might not be
present. I think I follow the intent here, but the detail seems off.
Dave.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Data Forms File Input Element
Abstract:
This specification defines an element which can be used with data
forms to let users upload one or more files.
URL: https://xmpp.org/extensions/inbox/data-form-file-element.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
A few weeks ago I made an important pull request to complete, fix and
update the XEP-0317: Hats.
https://github.com/xsf/xeps/pull/1437
This PR included the following changes:
* Specify a urn:xmpp:hats:commands:dcreate command to add a hat to the
available list
* Specify a urn:xmpp:hats:commands:ddestroy command to destroy a hat
from the list
* Clarify how the service should broadcast the hat changes when it is
edited, assigned, removed or destroyed
* Specify a way for an entity to get the complete list of hats using a
hash in disco#info
* Add a hue optional parameter allowing entities to assign a color to
the hat that can be displayed properly in any conditions on the
client (as explained in XEP-0392: Consistent Color Generation)
* Standardize all the form fields using XEP-0068
* Fix some typos
I tried to reach the authors without success so I'm trying again using
the mailing list.
I'd really like to move it forward then we can start implementing them
in our clients and servers.
Regards,
edhelas
