xsf / xeps Goto Github PK

As discussed during XMPP Summit 19, XEP-0308: Last Message Correction should be compatible with XEP-0313: Message Archive Management.

Glossaries using the dl/di/dt/dd elements do not render properly in PDFs. Instead you just end up with a normal paragraph containing all the definitions and text (eg. See 0366's glossary section in the PDF version vs. the HTML version).

Considering "4.5 Sending a message": there is a KEY/IV pair and a KEY/IV elements, which could be easily confused. Moreover the KEY element consists of encrypted data, but IV not. What do you think about changing the naming of the KEY element to something more explicit like "ENCRYPTED_KEY"?

According to the current status, experimental, it should be deferred by now...

The XEP refs that are linked from several places on various IETF sites (eg. see the "citation libraries" section here: https://xml2rfc.tools.ietf.org/) are missing:

• https://www.xmpp.org/extensions/refs/jsf-xeps.tgz
• https://www.xmpp.org/extensions/refs/jsf-xeps.zip
• https://www.xmpp.org/extensions/refs/

and this does not appear to be updating:

• https://www.xmpp.org/extensions/rss.xml
• https://www.xmpp.org/extensions/atom.xml

XEP-0347 references an image hosted outside of xmpp.org.

It is undesirable for XEPs to include references outside of the XEP change control process. Some allowances might be necessary, but such exceptional references also must be clearly marked as non-normative and outside the change control process.

@mwild1 said (at XMPP Summit 18) that it would be good for the client to specify how it wants the server to proceed with respect to presence probes. (E.g., it might not want its server to ever send probes, or it might want the server to send probes so that it can learn about the presence of other entities.)

The XEP rendering script, gen.py, cannot run with the new repo layout.

The errors are because the intermediate XML file is empty. This appears to happen because gen.py (and its deps) assume the parent directory is the repository, rather than the current directory.

Please add the clarification of why MAC/authentication tag is being encrypted but IV is left unencrypted and not both left unencrypted or vice versa or both encrypted.

Please add ePUB support.

Due to 08cfcb9 all XEPs may need to be regenerated.

Pending the following PRs:

• #50
• #51

There are several (S)HTML files scattered about the repo that can most likely be removed. The ones that provide redirects can be handled in the xsf/xmpp.org repo instead, or in the nginx config; either way they probably shouldn't be in the xeps repo.

Travis should check that a new revision was added to XEPs and fail the build if not. This would encourage authors to add a revision, and at least alert the editor that something needed to be done before merging to master if the author didn't want to deal with it.

As reported by goffi on the standards Mailing List:

There is a little issue with XEP-0050: in section 3.4 bullet 3, it's is
said that when the element is present:

• The action "execute" is always allowed, and is equivalent to the
  action "next".
• The "next" action is typically the "next" button or option in a
  wizard. If is not contained by the , it is disabled.

So if "next" action is disabled, execute is allowed but equivalent to a
disabled action.

I have had an issue which seems related to this confusion with SleekXMPP
and Gajim: if the next action is disabled in sleekXMPP, Gajim still show
the "execute" button, but a click on it result in an error, while the
"finish" button act as expected.

My guess is that "execute" should be equivalent to "complete" when

This revision [Editors note: XEP-0144] seems to have been stalled since the 2012-06-19, according to the date element of the latest revision, and has never been published on xmpp.org.

This has been found thanks to xsf-tools’ xeputils chocking while parsing the date.

While studying MUC-0045, I noticed that the maxhistoryfetch configuration field doesn't have the roomconfig_ prefix which the other fields have.

See for example here: http://xmpp.org/extensions/xep-0045.html#example-157

Is this due to legacy or actually a bug?

#192 updated the registry policy to have a Proposed state. This means that the editors should probably:

• figure out where the new registry pages will live and how they're generated and how to add things in a proposed state
• audit all experimental XEPs for proposed registry entries (or update the tooling to support proposed entries and run it against the experimental XEPs)
• audit templates or other mentions of the registry to make sure they include the new policy where appropriate

SCRAM-SHA-1 allows mutual authentication: not just the server establishes that the client knows the password, but also the other way around. This works because the server includes a specifically crafted hash on the <success/> element.

XEP-0305 seems to suggest that the client should ignore this:

When the client suspects that it is sending its final SASL response, with pipelining it appends an initial stream header and resource binding request.

In my opinion, XEP-0305 should either:

• Note explicitly that the client still MUST process the final SASL message from the server, and if the response indicates an authentication failure, immediately close the connection. The client MUST NOT pipeline anything beyond the bind <iq> (assuming that the resource is not considered sensitive).
• Forbid pipelining until the client has sent and received all SASL messages. This adds one more roundtrip, but it ensures nothing is leaked.

I've merged updates to XEP-0364 and bumped the version. Whatever things need to be run on the server need to be run.

The OTR Disco XEP was apparently accepted (http://mail.jabber.org/pipermail/council/2015-September/004044.html) but never published.

I've merged version 0.2.2 of XEP-0363 (#165) to fix a typo. The file needs to be regenerated on the server.

The 16 bytes key and the GCM authentication tag (The tag SHOULD have at least 128 bit) are concatenated and for each intended recipient device...

Once received due to the predefined length of the first field (key), the length of the tag can be calculated. Considering OMEMO file-transfer: the tag is appended at the end of the encrypted file and the total length is reported to the receiver. It seems to me not possible to derive the used authentication tag length in this case.

In the first paragraph of section 4, this link points to a non-existing page: https://xmpp.org/xmpp-protocols/xmpp-extensions/submitting-a-xep/

The following XEPs are affected by 548a9ee and may need to be regenerated:

• README
• 0053
• 0028
• 0143
• 0001

If external (non data-uri) images are embedded in an XEP, Travis should fail the build.

Currently there is a reference to an old draft of the XMPP over WebSocket subprotocol in xep.ent; this should potentially be updated to reference RFC7395 instead.

Investigate current usages and if it makes sense to update. If so, add a new entity (done as part of the compliance suite that's in PR right now) and update the old references.

Update XEP-0313 to next revision.

Pending the following PRs are updated:

• #22
• #40 (waiting on 0.5)

IPR Response from Authors:

• Florian
• Vincent
• Dominik

The 2016 compliance suite submission is in the inbox, but does not appear on the website and needs to have HTML generated.

In the affiliations section it talks about affiliation state changes and for a change from publisher to member is shows n/a. What does that mean exactly? Does that mean a publisher cannot be changed to a member? Do they have to be changed to none first then to a member?

Still shows "-2015"

Now XEP says the following:

Note: Computing the hash of the file before sending it can slow down the process of file transfer, because the sending application needs to process the file twice. The File Sender might prefer to send the hash after the file transfer has begun, using a transport-info message as described under Checksum.

Should be:

Note: Computing the hash of the file before sending it can slow down the process of file transfer, because the sending application needs to process the file twice. The File Sender might prefer to send the hash after the file transfer has begun, using a session-info message as described under Checksum.

This PR: https://github.com/xsf/xeps/pull/189/files adds registrar considerations, but I don't think we have an actual registry right now, or a repo for the registry, or anyone who knows how to handle the registry. Leaving this issue as a reminder to add the contents of that PR to the registry in the future when we get it back.

Please correct me if I'm wrong about any of this; I might just not know where the registry stuff lives or how to deal with it. /cc @stpeter @ashward

The README should really contain directions for generating HTML from one of the XEP XML files. It's unclear to me what the current process for that is.

http://xmpp.org/extensions/inbox/mix.html

• IPR From Kevin
• IPR From Peter
• Added to Council Agenda
• Accepted

While building the XEPs I notice that some of them depend on external resources that no longer exist.

from https://travis-ci.org/xsf/xmpp.org/builds/91354956#L1610:

********** Error report for XEP-0253 **********
********** Build Errors **********
Error while generating tex.xml for XEP-0253: warning: failed to load external entity "http://xsltsl.sourceforge.net/modules/date-time.xsl"compilation error: file http://xsltsl.sourceforge.net/modules/stdlib.xsl line 13 element importxsl:import : unable to load http://xsltsl.sourceforge.net/modules/date-time.xslwarning: failed to load external entity "http://xsltsl.sourceforge.net/modules/uri.xsl"
Error while converting xml to tex for XEP-0253: /tmp/XEPbuilder_w3O9Fg/xep-0253.tex.xml:1:0: no element found

Was decided in Council's 2013-07-24 meeting:

• http://logs.xmpp.org/council/2013-07-24/#15:12:14
• http://mail.jabber.org/pipermail/council/2013-August/003748.html
• http://mail.jabber.org/pipermail/council/2013-July/003737.html

should become

WARNING: This document has been automatically Deferred after 12
months of inactivity in its previous Experimental state.
Implementation of the protocol described herein is not recommended
for production systems. However, exploratory implementations are
encouraged to resume the standards process.

Section 7.1.5 of XEP-0060 refers to <publish-options/>. It is not defined in any of the schemas in XEP-0060.

I also brought this issue up on the standards mailing list (link leads to my email in the mailing list archive).

make PDF is failing

simon@crater  /tmp/xeps   master  make pdf
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 19415    0 19415    0     0  20016      0 --:--:-- --:--:-- --:--:-- 20015
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 88726  100 88726    0     0  78655      0  0:00:01  0:00:01 --:--:-- 78727
This is XeTeX, Version 3.1415926-2.5-0.9999.3 (TeX Live 2013/Debian)
 restricted \write18 enabled.
entering extended mode
! I can't find file `build/xepbuild/xep-0001.xml.texml.tex'.
<*> build/xepbuild/xep-0001.xml.texml.tex

(Press Enter to retry, or Control-D to exit)
Please type another input file name:

I've checked the "missing" file and build/xepbuild/xep-0001.xml.texml.tex is in the directory.

IPR Response from Authors:

• Florian
• Vincent
• Dominik

https://xmpp.org/extensions/xep-0143.html#maintain still says that the editor prefers to receive patches via email. Should we now add that it's possible to submit a GitHub pull request?

The last two registry entries in section 16.4.2 are invalid (the field element does not have a label, which I think is supposed to be required).

See also xsf/registrar#22

First requested at 2015-08-05 Council meeting.

• DWD
• KS
• LS
• MW
• PH

In line with IANA terminology, I would prefer to change "Proposed" and "Standard" for registry entries to "Provisional" and "Permanent". See for instance http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml as governed by https://tools.ietf.org/html/rfc7595. I will submit a PR for this.

When modifying multiple pubsub affiliations the extension states:

the service MUST return an IQ error (which SHOULD be ) with the invalid entries, where the affiliation returned is the original, un-altered affiliation

But the provided example is not following this rule. It does not list which affiliation modifications are not acceptable.

Requested at 2015-08-05 Council meeting.

• DWD
• KS
• LS
• MW
• PH

Hi team,
Attached please find a ProtoXEP that is intended to replace XEP-0176 (in fact, it is forked from XEP-0176).
I assert that I own any rights to the content in the submitted proposal (aside from what is already in XEP-0176).
I promise to assign those rights to the XMPP Standards Foundation upon acceptance of the proposal.
Thanks!
Peter

I see three options here:

• Setup a deploy stage in Travis after all checks are green
• Setup a cron job on perseus to pull once an hour or so and publish any changes
• Setup a webhook in GitHub that hits an endpoint on perseus when there are new changes on master (and then have perseus run whatever scripts are necessary)