[Standards] Re: UPDATED: XEP-0333 (Displayed Markers (was: Chat Markers))

[Dave Cridland]

I entirely missed this, and have no understanding of the rationale, but:

1) I'm somewhat ambivalent about removing , but it's certainly
well implemented by my anecdotological studies.
2) Removing  seems OK, but I've considered various use-cases
for which an explicit, user-driven, acknowledgement is useful. But I've
never actually implemented it, so...
3) It's really not. Some clients and intermediaries need to know whether
they should expect a marker or not. No need to check this prior to sending
a , true, but useful to track missing markers afterward.

Where was the discussion of this, and (more broadly) how does one know what
the discussion and rationale and consensus is if not on this list?

Dave.

On Sun, 10 Mar 2024 at 13:20, Daniel Gultsch  wrote:

> Version 0.5.0 of XEP-0333 (Displayed Markers (was: Chat Markers)) has
> been released.
>
> Abstract:
> This specification introduces a method to let the sender, or multiple
> participants in a group chat, know that a client has displayed
> messages up to a certain point.
>
> Changelog:
> * Remove  to not replicate  functionality.
> * Remove  because it was not implemented in the last 10
> years and apparently is not needed.
> * Remove Disco feature. Opting in via  is enough (dg)
>
> URL: https://xmpp.org/extensions/xep-0333.html
>
> Note: The information in the XEP list at https://xmpp.org/extensions/
> is updated by a separate automated process and may be stale at the
> time this email is sent. The XEP documents linked herein are up-to-
> date.
> ___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Dave Cridland]

It's been pointed out to me that this comes across combative, which isn't
the intention, and I apologise for that.

The crux of my argument here is in the phrase "there's no common behaviour
between Features and, say, a '198 ack".

Much of the aims of XEP-0360 appear to be based on a desire to split top
level elements into things that are Stanzas, and things that are not. This
much is fine. The problem is that this alone does not warrant a XEP in my
view. The XEP then goes further by trying to document common features of
thing that are not Stanzas, but the only commonality around behaviours and
syntax of things that are not Stanzas is simply that they are not Stanzas.

It's a bit like trying to divide life into Plants, and things that are not
Plants. The division might well be useful, but it does not follow that the
things that are not Plants are all the same, somehow - the only commonality
ends up being that they're not Plants.

Imposing rules, however well-meaning, suggests a commonality that does not
exist.

The XEP is tripping over itself in trying to do demonstrate this
commonality. Section 3 suggests examples from other XEPs which don't use
the term. Section 4 suggests consistent behaviours that don't always apply.
Section 5 describes rules for interoperability which are either broken by
existing XEPs or essentially impossible to break.

Paradoxically, the XEP does highlight one issue, albeit obliquely - there
isn't actually a very good definition of "Stanza" anywhere. The XEP points
at two different sections of RFC 6120, but as others have pointed out,
XEP-0114 has something to say here too, and RFC 6120 points to RFC 6121 as
well for some behaviours. This of course causes a lot of complications in
Section 2. An informational XEP summarizing the definition and nature of
Stanzas would be very useful, I think, to newcomers and old hands alike. I
think we all kind of know what we mean when we say "Stanza", but I think
there's a lot of detail that would be useful to gather into one place.

Dave.

On Fri, 22 Mar 2024 at 10:40, Dave Cridland  wrote:

>
>
> On Fri, 22 Mar 2024 at 08:47, Florian Schmaus  wrote:
>
>> For example, assume a XMPP library written in an object-oriented
>> language. There is a superclass TopLevelStreamElement which has one
>> obvious subclass named Stanza. Now, how should we name the other
>> subclass? TopLevelElementThatIsNotAStanza? Feels ridiculous.
>>
>>
> Well, now, that's a really interesting question that delves into OOP
> design.
>
> So, if you're of the classical Java bent, and therefore like injecting
> class hierarchies into everything, you'd have (and I write this in C++,
> because, well, reasons):
>
> class TopLevelElement;
> class Stanza public TopLevelElement;
> class Message public Stanza;
> class Presence public Stanza;
>
> OK, so this seems fair - Messages and Presences are both Stanzas, which is
> a TLE. Great! So what about a stream:features element?
>
> class Features public TopLevelElement;
>
> Well, it's a TLE, but it's not a Stanza.
>
> The thing is, Messages, Presences, and IQs all have common behaviour which
> is sensibly encapsulated into a Stanza class (if we're doing classical OOP,
> anyway).
>
> But there's no common behaviour between Features and, say, a '198 ack -
> there's nothing that is needed there.
>
> Now, you might want to do polymorphism based on something that's not a
> Stanza - I can't actually think why - and for that you might want to inject
> an artificial class. But this is an implementation detail, not something to
> foist upon the entire community.
>
> Dave.
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Dave Cridland]

On Fri, 22 Mar 2024 at 08:47, Florian Schmaus  wrote:

>
>  > In Section 5, business rule #2 states:
>  >
>  > "Nonzas SHOULD NOT have a 'from' or 'to' attribute."
>  >
>  > I have a few questions:
>  >
>  > - When is it sensible to make an exception to this SHOULD NOT?
>
> I can not think of one. However, this does not mean that there may be
> one, hence the defensive wording.
>
>
>  > - How should the 'from' and especially 'to' attributes be handled in the
>  > light of RFC 6120 §4.7?
>
> Hard to answer without any experience with Nonzas carrying a 'from' or
> 'to' attribute.
>

XEP-0220 still exists, by the way. Both db:verify, db:result, and even
db:error all have to, from, and type.

Dave.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Dave Cridland]

On Fri, 22 Mar 2024 at 08:47, Florian Schmaus  wrote:

> For example, assume a XMPP library written in an object-oriented
> language. There is a superclass TopLevelStreamElement which has one
> obvious subclass named Stanza. Now, how should we name the other
> subclass? TopLevelElementThatIsNotAStanza? Feels ridiculous.
>
>
Well, now, that's a really interesting question that delves into OOP design.

So, if you're of the classical Java bent, and therefore like injecting
class hierarchies into everything, you'd have (and I write this in C++,
because, well, reasons):

class TopLevelElement;
class Stanza public TopLevelElement;
class Message public Stanza;
class Presence public Stanza;

OK, so this seems fair - Messages and Presences are both Stanzas, which is
a TLE. Great! So what about a stream:features element?

class Features public TopLevelElement;

Well, it's a TLE, but it's not a Stanza.

The thing is, Messages, Presences, and IQs all have common behaviour which
is sensibly encapsulated into a Stanza class (if we're doing classical OOP,
anyway).

But there's no common behaviour between Features and, say, a '198 ack -
there's nothing that is needed there.

Now, you might want to do polymorphism based on something that's not a
Stanza - I can't actually think why - and for that you might want to inject
an artificial class. But this is an implementation detail, not something to
foist upon the entire community.

Dave.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0388 (Extensible SASL Profile)

[Dave Cridland]

On Mon, 18 Mar 2024, 17:32 Stephen Paul Weber, 
wrote:

> >> However it does lack any way to support indicating to the server
> >> which
> >> credential will be used, other than perhaps by implication from the SASL
> >> mechanism.
> >>
> >>
> >That's not the purview of a SASL profile. If a SASL mechanism supports
> >multiple credentials, that's entirely encapsulated within that mechanism.
>
> Except that it is not. For example all of the SCRAM-SASL-* profiles can
> easily support authentication with any of the passwords on an account, but
> they need to know in advance which one is being used. So SASL mechanism is
> insufficient for selecting credential by itself.
>
> The same goes for the HT-* token mechanisms.
>

Yes, I mean, the SASL profile itself doesn't do anything there.

If you want to indicate a particular credential, you could use the
authentication identifier to select which, and the authorization identifier
might remain the same. Or a mechanism might support multiple credentials.

But the SASL profile isn't involved here.

___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0388 (Extensible SASL Profile)

[Dave Cridland]

On Mon, 18 Mar 2024 at 14:19, Stephen Paul Weber 
wrote:

> >1. Is this specification needed to fill gaps in the XMPP protocol
> >stack or to clarify an existing protocol?
>
> Yes, we currently have no way to use multiple SASL or otherwise to acheive
> a
> similar result.
>
> >2. Does the specification solve the problem stated in the introduction
> >and requirements?
>
> Yes. However it does lack any way to support indicating to the server
> which
> credential will be used, other than perhaps by implication from the SASL
> mechanism.
>
>
That's not the purview of a SASL profile. If a SASL mechanism supports
multiple credentials, that's entirely encapsulated within that mechanism.


> >3. Do you plan to implement this specification in your code? If not,
> >why not?
>
> Yes, I have implemented this for xmpp.js -- except for "tasks" which I
> have
> not implemented and I think there are no official profiles of, making that
> a
> somewhat more risky area of the spec.
>

There's XEP-0400, actually, which defines two tasks.

>
> >4. Do you have any security concerns related to this specification?
>
> No, only usability concerns outlined above
>
> >5. Is the specification accurate and clearly written?
>
> Yes
> ___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0388 (Extensible SASL Profile)

[Dave Cridland]

On Mon, 18 Mar 2024 at 09:00, Daniel Gultsch  wrote:

> This message constitutes notice of a Last Call for comments on
> XEP-0388.
>
> Title: Extensible SASL Profile
> Abstract:
> This document describes a replacement for the SASL profile documented
> in RFC 6120 which allows for greater extensibility.
>
> URL: https://xmpp.org/extensions/xep-0388.html
>
> This Last Call begins today and shall end at the close of business on
> 2024-04-01.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
>
Well, I think so, yes.


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
>
Again, I believe so.


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
I implemented this some time ago in order to get TOTP working in Openfire -
I never merged the code into the main branch, but it is available.


> 4. Do you have any security concerns related to this specification?
>
>
Not that aren't already specified.


> 5. Is the specification accurate and clearly written?
>
>
I can't really judge this; but after implementing it I did do a sweep over
it in order to tidy it up.

I have noticed that Example 8 no longer has the additional data Base64
encoded, which is wrong, so this needs fixing prior to advancing it. It
also spoils the joke.


> Your feedback is appreciated!
> ___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Remove requirement to send disco#info feature in XEP-0030

[Dave Cridland]

I think advice and a recommended course of action promotes
interoperability, and is backwards compatible. XEP-0001 also says such
modifications must be optional; obviously a SHOULD is not a MAY here, but I
think it's fairly clear that a decision to assume that an entity not
including disco#info within its disco#info response has ramifications which
should properly be understood prior to doing so.

IOW, I think this remains within the spirit, albeit not the letter, of the
Final requirements.

On Tue, 12 Mar 2024 at 10:33, Kevin Smith  wrote:

> I agree that a note would be helpful, but we're only noting that bugged
> implementations exist, I don't think that even adding a SHOULD here
> falls within the spirit of the Final requirements. So I think the right
> thing to do is to add a note saying such bugs exist, but not change
> normative language.
>
> /K
>
>
> -- Original Message --
> From "Dave Cridland" 
> To "XMPP Standards" 
> Date 12/03/2024 09:59:33
> Subject [Standards] Re: Remove requirement to send disco#info feature in
> XEP-0030
>
> >As others have said, it's a wart. Any protocol has lots of them; XMPP
> >has always had its fair share. (You mention XEP-0045 briefly, and we're
> >all familiar that it's essentially a collection of warts at this
> >stage). This one is not, as far as I can see, harmful in any meaningful
> >way.
> >
> >As Tedd Sterr notes, removing the reporting of disco#info support via
> >disco#info might leave no features at all, which might - small chance -
> >mean that implementations hit bugs.
> >
> >I see no benefit to interoperability to remove it at this time.
> >
> >However, I could see the benefit of adding a note to the effect of:
> >
> >"Some entities are known not to advertise the
> >"http://jabber.org/protocol/disco#info; feature within their responses,
> >contrary to this specification. Entities receiving otherwise valid
> >responses which do not include this feature SHOULD infer the support."
> >
> >Dave.
> >
> >On Sun, 10 Mar 2024 at 16:27, Jonas Schäfer 
> >wrote:
> >>Dear community,
> >>
> >>it's been a while I spoke up here.
> >>
> >>I would like to discuss the removal of the following part-sentence
> >>from
> >>XEP-0030 (in Final status!):
> >>
> >> > every entity MUST support at least the
> >> > 'http://jabber.org/protocol/disco#info' feature
> >>
> >>Announcing that feature is redundant: An entity which replies with a
> >>properly
> >>constructed `http://jabber.org/protocol/disco#info"/>`
> >>element
> >>is bound to (and has always been bound to) have implemented XEP-0030
> >>to the
> >>best of its knowledge.
> >>
> >>As this is a Final(!) status XEP, here is my estimate of the impact
> >>this
> >>change has:
> >>
> >>- Implementations which required the presence of this feature on the
> >>   receiving side would now become non-compliant: They might assume
> >>   that the remote entity did not really support XEP-0030 and fail with
> >>   an error.
> >>
> >>   Such implementations would need to be adapted in order to be able to
> >>   interoperate with implementations which follow a revised version of
> >>   XEP-0030.
> >>
> >>I don't see any other impact. I also strongly suspect that the set of
> >>implementations which follow XEP-0030 to the letter is rather slim (I
> >>only
> >>know of a single one, which would be the Rust XMPP library xmpp-rs
> >>[1]).
> >>
> >>The reason why this came up: There have in the past been cases ([2]
> >>and
> >>another, not-yet-filed issue against Prosody IM where the disco#info
> >>feature
> >>is missing from MUCs) where implementations didn't emit this feature.
> >>The
> >>seeming pointlessness and lack of information conveyed by this feature
> >>var
> >>make it easy to overlook and low-priority to fix. The fact that this
> >>has gone
> >>undiscovered for at least one Prosody IM release cycle further
> >>supports the
> >>assumption that the number of implementations which rely on that part
> >>of the
> >>spec is rather small.
> >>
> >>Your input is welcome.
> >>
> >>kind regards,
> >>Jonas Schäfer
> >>(these days without "special" role in the standards process)
> >>
> >>[1]: And there exists at least one fork which removed that check:
> >> https://gitlab.com/nesium/xmpp-rs/-/commit/1ddb050
> >>[2]:
> >>
> https://issues.prosody.im/1664___
> >>Standards mailing list -- standards@xmpp.org
> >>To unsubscribe send an email to standards-le...@xmpp.org
> ___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Remove requirement to send disco#info feature in XEP-0030

[Dave Cridland]

As others have said, it's a wart. Any protocol has lots of them; XMPP has
always had its fair share. (You mention XEP-0045 briefly, and we're all
familiar that it's essentially a collection of warts at this stage). This
one is not, as far as I can see, harmful in any meaningful way.

As Tedd Sterr notes, removing the reporting of disco#info support via
disco#info might leave no features at all, which might - small chance -
mean that implementations hit bugs.

I see no benefit to interoperability to remove it at this time.

However, I could see the benefit of adding a note to the effect of:

"Some entities are known not to advertise the "
http://jabber.org/protocol/disco#info; feature within their responses,
contrary to this specification. Entities receiving otherwise valid
responses which do not include this feature SHOULD infer the support."

Dave.

On Sun, 10 Mar 2024 at 16:27, Jonas Schäfer  wrote:

> Dear community,
>
> it's been a while I spoke up here.
>
> I would like to discuss the removal of the following part-sentence from
> XEP-0030 (in Final status!):
>
> > every entity MUST support at least the
> > 'http://jabber.org/protocol/disco#info' feature
>
> Announcing that feature is redundant: An entity which replies with a
> properly
> constructed `http://jabber.org/protocol/disco#info"/>`
> element
> is bound to (and has always been bound to) have implemented XEP-0030 to
> the
> best of its knowledge.
>
> As this is a Final(!) status XEP, here is my estimate of the impact this
> change has:
>
> - Implementations which required the presence of this feature on the
>   receiving side would now become non-compliant: They might assume
>   that the remote entity did not really support XEP-0030 and fail with
>   an error.
>
>   Such implementations would need to be adapted in order to be able to
>   interoperate with implementations which follow a revised version of
>   XEP-0030.
>
> I don't see any other impact. I also strongly suspect that the set of
> implementations which follow XEP-0030 to the letter is rather slim (I only
> know of a single one, which would be the Rust XMPP library xmpp-rs [1]).
>
> The reason why this came up: There have in the past been cases ([2] and
> another, not-yet-filed issue against Prosody IM where the disco#info
> feature
> is missing from MUCs) where implementations didn't emit this feature. The
> seeming pointlessness and lack of information conveyed by this feature var
> make it easy to overlook and low-priority to fix. The fact that this has
> gone
> undiscovered for at least one Prosody IM release cycle further supports
> the
> assumption that the number of implementations which rely on that part of
> the
> spec is rather small.
>
> Your input is welcome.
>
> kind regards,
> Jonas Schäfer
> (these days without "special" role in the standards process)
>
>[1]: And there exists at least one fork which removed that check:
> https://gitlab.com/nesium/xmpp-rs/-/commit/1ddb050
>[2]: https://issues.prosody.im/1664
> ___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Dave Cridland]

On Sun, 10 Mar 2024 at 15:19, Daniel Gultsch  wrote:

> This message constitutes notice of a Last Call for comments on
> XEP-0360.
>
> Title: Nonzas (are not Stanzas)
> Abstract:
> This specification defines the term "Nonza", describing every top
> level stream element that is not a Stanza.
>
> URL: https://xmpp.org/extensions/xep-0360.html
>
> This Last Call begins today and shall end at the close of business on
> 2024-03-25.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
>
No.

Many of you have heard my views on this before. I argued against this XEP
from the outset and I have seen nothing to change my view. Sorry for
rehashing this argument, for those of you who have heard me on this before,
but I still feel strongly that this is a very poor idea.

Introducing new words - not just new terms, but new collections of letters
that have previously never had a meaning at all - seems like a very poor
way to make specifications (and simply our technology) more approachable.

I have always avoided this new word, and will continue to do so, as the
rare specification that introduces a new top-level element will never be
made more simple by saying "This specification adds a new furbley bloople
ding dong - now go and read XEP-0987 for an entire document on what
this might mean.". As an industry, we are rightly chastised for introducing
pointless jargon. It is a clear barrier to entry for newcomers, and should
always be avoided.

The situation becomes even worse in the circumstances of a chatroom or
conversation, by making it more impenetrable that it likely already is.
Casual conversations do not have convenient footnotes and reference
sections.

Of course jargon inevitably accumulates - stanza is an obvious example, but
if I mention CSI, or PEP most people on this list will know what those mean
- but these are essentially shorthands for a large volume of information.
This specification simply introduces a word for top-level elements that are
not stanzas. That's six words to cover the entire XEP.

The rest of the XEP just adds additional words. These are sometimes
questionable, and other times useless.

Section 4 says that usually, top-level elements that are not stanzas that
are exchanged prior to resource binding are request-response. And after
resource binding, they're usually not request/response. Though in fact,
some of the most common examples are the reverse - XEP-0198 uses  and
 exchanges, whereas  has no response as such.

Section 5 tells me that top-level elements that aren't stanzas MUST NOT be
routed. So, wait - a server that's compliant to this won't route these
elements? OK. And if a server isn't compliant to this, what does this mean?
These are not interoperability requirements, these are just statements of
fact. Stanzas being routable top-level elements, it is axiomatic that a
top-level element that is not a stanza is not routed. We do not need to
wave an RFC 2119 statement around to ensure this is the case.

Is a server that offers XEP-0114 not compliant with XEP-0360, since XEP-360
references only RFC 6120? Or do we use the informal definition that talks
about "element name" - does this mean the local name? Does this mean that a
top-level element of 
is in fact a Stanza by the definition of XEP-0360?

None of this serves - or can serve - to clarify an existing protocol to a
new reader.


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
>
I dispute there was ever a problem, whereas it has added a new problem by
its existence.

As I recall, one of the suggested problems was that people might be
confused about what top-level elements to count in XEP-0198, maybe around
whether to count CSI elements - yet neither specification has ever
introduced the term.


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
I have never used the new word in a specification I have written or
contributed to, and will continue to avoid doing so. "This specification
introduces a new top-level element , qualified by the urn:xmpp:bar:0
namespace - it is not routable and MUST NOT be considered a stanza."

Infinitely simpler, and usually overkill.


> 4. Do you have any security concerns related to this specification?
>

My concerns are not security related.


> 5. Is the specification accurate and clearly written?
>
>
Anything that introduces a new made-up word cannot, almost by definition,
count as clearly written.


> Your feedback is appreciated!
> ___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to 

[Standards] Re: Feedback requested: SVCB for XMPP

[Dave Cridland]

On Wed, 14 Feb 2024 at 15:14, Peter Saint-Andre  wrote:

> On 2/13/24 11:18 PM, Travis Burtrum wrote:
>
> > 5.
> > Ultra-minor nit: is BOSH needed or useful with websockets and upcoming
> > webtransport? legacy clients that don't support either of those won't
> > support this either, and will look up bosh the old way.
>
> Could we perhaps deprecate BOSH at this point?
>

We can, though it's still useful in odd cases.

That doesn't preclude supporting it here, though.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Feedback requested: SVCB for XMPP

[Dave Cridland]

On Wed, 14 Feb 2024 at 06:18, Travis Burtrum  wrote:

> Hi Dave!
>
> I've only briefly reviewed this so far, so please forgive if I've missed
> things, but I have some early comments:
>
> Major blocker I'm not sure can be addressed:
>
> 1.
> This essentially re-introduces the major security flaw that was
> addressed in XEP-0156 by removing the TXT record, just with a warning.
> Context:
> *
>
> https://web.archive.org/web/20220828222121/https://mail.jabber.org/pipermail/standards/2022-February/038759.html
> * https://github.com/xsf/xeps/pull/1158
> *
>
> https://www.moparisthebest.com/slides/xmpp-connectivity-security-13JUL2023.html#(17)
>
> But all those points still remain, most importantly:
> * nearly no HTTPS clients/libraries/browsers actually support "connect
> me to domain X but send SNI Y and validate the cert against domain Y", I
> would argue it's too dangerous to even allow trying this
>
>
I agree it's tricky, but HTTPS RRs (and SVCB for HTTPS) do introduce this
requirement anyway, so the difficult part might be convincing the library
that this is the same situation.


> Things easily addressed:
>
> 1.
>  > "xmpps-server" and "xmpps-client" have a default port registered in
> this document.
> I don't actually see these registered.  Also I'm generally opposed to
> this, because, whether we like it or not (and I know most of us do not,
> including me) it's 2024 and protocols are no longer multiplexed via
> port, but instead all go over 443 (TLS or QUIC) and are multiplexed via
> ALPN.  Soothe yourself to sleep at night with the fact that this,
> combined with ECH, is actually a huge win for both connectivity and
> privacy, as intermediaries can no longer guess or police which
> protocol(s) you can use.
>
>
I agree, but I think functionally it's simpler to use a default port here.
(I've not done the various IANA bits needed in this draft yet, hence it
doesn't exist).


> 2.
> It mentions QUIC, and links to the XEP, but I don't see a way to
> indicate a QUIC connection?
>
>
Good point; it'd need another ALPN identifier.


> 3.
> Needs ECH, with HTTPS this is on the HTTPS record, where can it go here?
> I consider this absolutely required.
>
>
The HTTPS RR is actually just a SVCB RR without the attrleaf (ie, the _xmpp
that we have in this one), and this information implied by the type (66
instead of 65). So anything that can be in an HTTPS can be in a SVCB, and
this includes ECH - but I do need to explicitly say it counts, and I'll do
that.


> 4.
> Semi-minor nit: StartTLS certainly doesn't preclude ALPN being sent, but
> I actually wouldn't define it at all here.  legacy clients that don't
> support DirectTLS won't support this spec, and will look up StartTLS the
> old way, and 0 servers have support for StartTLS but not DirectTLS.
> Unless I'm missing some reason to keep support?
>
>
I'd like to support StartTLS (and BOSH) if it seems relatively trivial to
do so. I'm certainly aware of servers that don't support both (or do, but
have it turned off). This is usually for all the wrong reasons, but still.


> 5.
> Ultra-minor nit: is BOSH needed or useful with websockets and upcoming
> webtransport? legacy clients that don't support either of those won't
> support this either, and will look up bosh the old way.
>

BOSH is definitely trivial to support - just an additional path. It does
work in some (sadly not rare) cases where nothing else will. BOSH is
horrible, and I wish we just used WebSockets everywhere, but still.

My focus is currently on things like Google App Engine, where you have a
docker image that can only do HTTP/1.1, accessed indirectly via a load
balancer that terminates TLS. The load balancer will do HTTP/2 and HTTP/3 -
but because it's forwarding on as HTTP/1.1, you don't get the option of
WebTransport, and instead only get WebSockets or BOSH. In some cases (the
really cheap options), you don't even get WebSockets.


> Thanks,
> Travis
> ___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Feedback requested: SVCB for XMPP

[Dave Cridland]

Hi all,

Attached is an *unsubmitted* Internet Draft covering SVCB usage for XMPP.
Assuming attachments work on this list!

Feedback welcome, I intend to submit this one shortly to the IETF.

Dave.


draft-cridland-dnsop-svcb-xmpp.pdf
Description: Adobe PDF document
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0440 and tls-server-end-point

[Dave Cridland]

On Tue, 30 Jan 2024 at 10:11, Florian Schmaus  wrote:

> If we are not positive about it, then why should be push implementations
> into non-compliance by mandating it, when we simply could (strongly)
> recommend it?


Exactly this - interoperability should be a pragmatically achievable goal.
Security should be as high as possible without disrupting that goal,
because if it's disrupted then people will just use something else that
actually works, and the additional requirements have achieved nothing.

Given this, tls-server-end-point seems like it ought to be baseline - it's
relatively easy to implement anywhere, and while it has weaknesses, it's
still a lot better than nothing.

So that says, to me, text along the lines of "MUST implement".

tls-exporter is clearly superior, so we want to encourage that, but accept
there are lots of cases where that's not practical, so "SHOULD implement".

Finally, we know that in some deployments, there is enough control of
clients and other deployment aspects that there's no practical benefit to
supporting the weaker tls-server-end-point, so we might want to indicate
that while deployment in the general case is "strongly advised" (I'm
side-stepping RFC 2119 here), if a particular deployment can remove it
that's actually better security.

Dave.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0440 and tls-server-end-point

[Dave Cridland]

On Thu, 11 Jan 2024 at 12:39, Holger Weiß  wrote:

> * Simon Josefsson  [2024-01-11 13:10]:
> >I believe tls-server-end-point is generally best left unimplemented to
> >guide efforts towards supporting the stronger tls-exporter.
>
> One use case I see for tls-server-end-point is that it allows for
> supporting channel binding by setups where TLS is terminated by some
> reverse proxy, thereby protecting against _some_ but not all attack
> vectors that tls-exporter protects against.


I'm pretty sure this was a key reason we picked the approach. If TLS is
terminated before the server ever sees it, the server can still be
configured to handle tls-server-end-point.

It's not, of course, really channel binding - it's not binding to the
channel itself at all - but it does give some of the protection real
channel binding would.

Dave.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

[Dave Cridland]

Hi all,

(Updated Lance's email to the last-known-good public one).

I dislike this XEP intensely.

But... I think it's probably the most pragmatic solution that fits the
existing standards space.

Questions:
- Should we require this to always be hosted at the exact domain? Pretty
much everywhere I've worked for has the primary website (AKA "the marketing
site") distinct from any production services, whether internal ("IT") or
external ("Engineering") facing. Is it worth having a dummy website on a
different domain that we can check, and stipulate that if both exist, they
MUST be both identical? (Or we can set a priority, but my intent here is
that both would be checked simultaneously).
- While I sympathize with the view that StartTLS for C2S and indeed S2S
should be moving towards deprecation, that flies in the face of the
pragmatism otherwise on display here - they need to be added in I think as
rel types.
- The TTL thing... I agree it's an error in RFC 6415 et al, but I'm
unconvinced it's one we should worry ourselves over too much within the
XSF. I'd save yourself the effort and assume developers are sensible.
- In general, I'm not sure that the JRD/XRD model allows that "xmpp" block;
those might need to be distinct properties.
- In general, I understand the JRD/XRD concept to be tightly bound to RDF,
so I think you'd need to add in attributes as properties, and those
properties would need to be URIs.

Many of the above will make things uglier, but I think more in-line with
the JRD concepts.

Finally, I think it's worth putting some consideration into handling this
one in the IETF entirely - you may find support for extracting the PKP bits
into a generic approach, and all sorts.

As an alternative to all that, it might be sensible to explore *not* using
host-meta, and instead using a well-known JSON blob (I see Matrix does this
for example).

Dave.

On Sat, 16 Dec 2023 at 04:01, Travis Burtrum  wrote:

> Hi all,
>
> Quick summary of this ProtoXEP: It's intended to be the single new
> de-facto way all servers and clients look up connection info to connect
> to servers.
>
> It was clear from the feedback that this ProtoXEP needed an extensive
> rationale section explaining why other alternatives aren't sufficient
> and why certain decisions were made, I have added this and rendered it
> here:
>
> https://www.moparisthebest.com/xeps/host-meta-2.html#rationale
>
> (source @
> https://github.com/moparisthebest/xeps/tree/task/host-meta-2-rationale )
>
> I'd appreciate any feedback, here or in xsf@ .
>
> Lastly I was asked to contact to XEP-0156 authors to see how they'd feel
> about this updating '156 instead of being it's own XEP, so I've CC'd the
> authors who's emails appear to still be valid here, if you could please
> have a look and let us know I'd really appreciate that too. :)
>
> Thanks much,
> Travis
> ___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0458 (Community Code of Conduct)

[Dave Cridland]

On Wed, 1 Nov 2023 at 16:59, Peter Saint-Andre  wrote:

> Hallo Guus,
>
> Thanks for sharing your thoughts. In my comments below, I haven't yet
> provided suggested text, but I wanted to reply quickly and I will send
> another note when I can make concrete proposals.
>
> On 10/31/23 3:18 PM, Guus der Kinderen wrote:
> > Hello,
> >
> > Thank you for the work that has gone into this.
> >
> > To me, the document is clearly worded.
>
> That's good to hear.
>
> > I would appreciate elaboration on
> > the sentence "Humour is not a mitigating factor here" in section 2.3.
>
> I expect that Dave meant "perhaps you were merely trying to be humorous,
> but that doesn't excuse a poor choice of words".
>
>
I think I had in mind:

HAR HAR I WAS ONLY JOKING CAN'T YOU TAKE A JOKE??!??!!111

But yes, as usual, you put it better.


> > An
> > additional suggestions is to add a reminder that we do not all share a
> > common cultural background or even a native language and that this can
> > easily introduce confusion of tongues.
>
> That is an excellent point. I will formulate some text about that.
>
>
This too. What is acceptable humour (or simply phrasing) in one culture
isn't in another - see, for example, "bum bags" versus "fanny packs".


> > To what extent will this document, once adopted, be not only applicable
> > to all of the XSF's Activities, but also be the singular source of
> > policy? Does that need to be specified?
>
> I expect this document would be the single source of policy on the
> topics it covers. If we learn that we've missed something important,
> we'll need to update the XEP. Defining policy for the same topic in two
> places would be confusing.
>
> > As for the applicability: much (all?) of the violations that I witnessed
> > are simple spamming or abusive behaviours in MUC rooms. The definition
> > of desired vs undesirable behaviour that's in this document can help in
> > those cases, but the process on section 5 is less applicable. I doubt
> > that this document intends to make moderators of a room go through a
> > procedure of Reporting to the Conduct Team, prior to issuing a ban.
> > Should this document more explicitly allow for action to be taken
> > outside of the procedure defined in section 5?
>
> Yes, it should. I'll think about this, as well, and propose text in a
> future message.
>
>
I think that there are occasions where an immediate action is warranted,
and should be taken by those with the capacity to do so; moderators banning
people from chatrooms is one case, though there are other cases. We should
ensure that these actions are easily undone. (bans can be dropped, gaffer
tape removed from - oh, wait, what was I saying?)


> Peter
>
>
> ___
> Standards mailing list -- standards@xmpp.org
> Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
> ___
>
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] Re: Chat Markers and Read Status

[Dave Cridland]

On Mon, 18 Sept 2023 at 05:19, Simon Lipp  wrote:

> The use case is easy ; if I’m in conversation with Alice, and Bob sends
> me some message, my client usually puts some notification. But if I
> close the client without reading the message, I have no reminder in the
> next session that I don’t have read Bob’s messages.
>
>
In Inbox, XEP-0430, I originally tried to address this use-case by
"flagging" conversations rather than un-reading them.

I cannot recall why we removed this, probably we decided it was additional
complexity.

But in general terms, I would lean toward identifying the "product need"
and working toward a solution for it rather than trying to encode the
workaround we try to use on (for example) email.

Dave.
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] Re: NEW: XEP-0481 (Content Types in Messages)

[Dave Cridland]

On Tue, 6 Jun 2023 at 22:34, Travis Burtrum  wrote:

>
> Jun 6, 2023 4:31:54 PM Dave Cridland :
>
> >
> > On Thu, 4 May 2023 at 15:06,  wrote:
> >> Version 0.1.0 of XEP-0481 (Content Types in Messages) has been
> >> released.
> >
> > This is weirdly horrible.
>
> Me too, but it's not council's job to police the protocol, what gets
> widely used is decided by running code and consensus.
>

Oh, I'm not saying it shouldn't have been published, I don't think this has
any potential to damage the interoperability of the network, and it seems
free of IPR concerns.

It *is* the Council's job to police what gets through to Stable, I think,
but that's irrelevant here, and will likely remain so in this case I'd have
thought.


>
>
> > * First and foremost, it falls into a general trap that's open to abuse
> by malicious actors, by having a message whose content will be interpreted
> differently by different clients. This has been used by spammers and as a
> malware vector for decades.
>
> So... Same as xml:lang in the RFC ? I don't like that either. :)
>

I think worse. xml:lang I'm not keen on for use as a way to send
multilingual messages, indeed, but if I send you a message such as:


  Innocuous message!
  Evil annoying spam blockchain AI


Then the anti-spam (AI driven using Blockchain of course) might evaluate
only the innocuous message and your client might only display the evil
annoying spam. The anti-spam can't easily know which your client will
display, so it needs to evaluate both, and with something like
text/markdown in the mix, it forces the anti-spam to understand all the
content-types. (Maybe it does by AI, or blockchain, but still).

The same is possible with xml:lang, by sending 'en-gb' and 'en-us'
messages, for example, as you note, but those are at least the same basic
syntax so a little easier to manage.

Critical problem? Not really. But I'd want this pointed out in the Security
Considerations.

Dave.
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] Re: NEW: XEP-0481 (Content Types in Messages)

[Dave Cridland]

On Thu, 4 May 2023 at 15:06,  wrote:

> Version 0.1.0 of XEP-0481 (Content Types in Messages) has been
> released.
>

This is weirdly horrible.

* First and foremost, it falls into a general trap that's open to abuse by
malicious actors, by having a message whose content will be interpreted
differently by different clients. This has been used by spammers and as a
malware vector for decades.
* Secondly, it has a weird edge case where a zero-length encoding of some
data means by implication that the main body has that encoding; but
otherwise it's assumed to be text/plain.
* Thirdly, there's no content encoding, so it limits itself to being used
for content types which can be inserted into a CDATA section. The XML
example is spectacularly horrible as a result - imagine an XML-native
transport layer that has to encode XML?

Dave.
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and

[Dave Cridland]

On Wed, 22 Feb 2023 at 13:33, Thilo Molitor  wrote:

> > There is a very obvious solution to this which everyone seems to be
> > overlooking: we need a new element with a guaranteed unique, non-spoofed
> > UUID; should a server feel the need to do bad things, it can set the
> > 'spoofed' attribute to true and then clients can act accordingly.
> what entity would set that element? the sending client? the server of that
> client? the server of the receiving client?


Any entity that's doing Bad Things of course. See also XEP-0076, RFC 3514.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] uppercase/lowercase of keywords

[Dave Cridland]

On Thu, 19 Jan 2023 at 09:17, Maxime Buquet  wrote:

> On 2023/01/18, Peter Saint-Andre wrote:
> > On 1/18/23 9:26 AM, Thilo Molitor wrote:
> > > In Appendix F: Requirements Conformance all our XEPs refer to RFC 2119
> defining
> > > "MUST", "SHALL" etc.
> > > But since RFC 2119 does not specify which case should be used for these
> > > keywords, a XEP using "shall" or even "sHaLl" uses normative keywords,
> no?
> >
> > My personal practice in writing RFCs has been to studiously avoid
> lowercase
> > conformance terms. It's quite easy and natural in English to use other
> > words: might instead of MAY, ought instead of SHOULD, etc. But it seems
> that
> > most authors are too lazy to do this, which is why we ended up with RFC
> > 8174.
>
> I'd like to nuance this here.
>
> Not everybody has english as their native language and many contribute
> to standardization nonetheless. Maybe standardization should be made
> more accessible, and I think 8174 is an ok step towards this, rather
> than having to be careful about subtle nuances of the language.


Additional Nuance:

The original keywords come from the RFC 1122 and RFC 1123 effort, which was
intended to tighten a lot of the early standards. These derive from a
series of campaigns of various implementors of early commercial Internet
offerings who claimed full conformance because the specifications had
sufficient wiggle-room to allow it. RFC 1123 stipulates that the "words"
are capitalized.

Many people thought these were great, and would reuse them - but often
without restating the definition. An example is RFC 2821 (published,
eventually, a full four years after RFC 2119) - I think Klensin kept his
own definition intentionally, actually, but I can't spot a difference.

Scott Bradner ("sob") would put in a formal appeal every time someone
attempted to use MUST/SHOULD/MAY without a definition, and then produced
his own. RFC 2119 does not stipulate that the keywords are to be
capitalized, but also always uses them in upper case, and does not say they
can be anything else, and stipulates "keywords", which are not the same
thing as words. He has stated on a number of occasions that he didn't
intent the keywords to be case insensitive, either.

Some people thought that a lowercase "must" used as ordinary English rather
than a keyword had the same meaning and weight as an RFC 2119 keyword
because it hadn't been specified not to. Although this was never the
intent, this is made more complicated because it often does... You need not
use RFC 2119 keywords to define a requirement in a specification (RFC 4469
is an example of a specification that eschews RFC 2119 entirely), and this
is often easily performed by words that - if capitalized - would have a
similar meaning. If my specification says "Servers must always ensure a
valid key is used", then capitalizing the MUST makes no difference. But the
meaning of "should" varies enormously from vague encouragement to the same
as saying you must. If I say that implementors should consider ... - is
that MUST consider? SHOULD consider? OUGHT to consider? Or is it none of
those, really?

It is often possible to jump through linguistic hoops to avoid the use of
words also used as RFC 2119 keywords, but that can change the meaning
subtly. Or not so subtly:

Servers may rely on a conformant client providing only...
Servers might rely on a conformant client providing only...

This is made worse when authors decide they MUST capitalize the words,
turning them into formal requirements, even if they MAY NOT [sic] need to.
Especially since this ends up changing the meaning rather dramatically in
cases where someone blindly uppercases a "should" or "may" in "should/may
not" - the English meaning of "SHOULD NOT" and "MAY NOT" is a mandatory
imperative, not a strong encouragement or an optional suggestion. Well,
depending on context... In any case, I would strongly agree this isn't a
matter of laziness.

I find it's hard enough to remind people that "SHOULD" requirements aren't
in any way optional and ignoring them may break interop.

Anyway, all this came to a head a few years back and RFC 8174 was produced
to quench this whole argument to the satisfaction of both sides. We should
use it.

Sorry.

We MUST use it.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388

[Dave Cridland]

I can do on the list too - merge it, publish it, but add yourselves as
authors too.

On Fri, 13 Jan 2023 at 13:55, Thilo Molitor  wrote:

> > Dave approved the PR last week here:
> > https://github.com/xsf/xeps/pull/1214#pullrequestreview-1236512706
> Great, I've not hallucinated! At least partly (I thought he did so on
> list).
>
> -tmolitor
>
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] standardization process

[Dave Cridland]

On Sat, 7 Jan 2023 at 20:46, Florian Schmaus  wrote:

> But let use assume that we remove the council approval requirement for
> experimental XEPs. And further assume that we clearly state that
> experimental XEPs may change protocol without namespace bumps.


Forgetting everything else for a moment, why do you want to get rid of
namespace bumps? WHat is the problem you think would be solved? Those
weren't introduced to slow people down or avoid experimental deployment,
quite the opposite in fact.

Also, I wonder why we never published
https://xmpp.org/extensions/inbox/nsver.html

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0474 (SASL SCRAM Downgrade Protection)

[Dave Cridland]

Not using PLAIN is insufficient - clients have to only use SCRAM, and in
particular, variants of SCRAM that are considered secure.

So yes, if someone is deploying SCRAM-SHA256, this would detect a downgrade
to SCRAM-SHA1, but only while SCRAM-SHA1 is proof against compromise. And
while SCRAM-SHA1 *is* proof against compromise (modulo leaks of the server
credential store), a downgrade to it isn't really something to worry about
(and why is an attacker doing this?). I would therefore argue this provides
no practical protection against downgrades of SASL mechanisms.

Therefore, this is *at best* protecting against changing the channel
binding type to support only channel binding types that the client does not
support, or are weak enough to be under the attacker's control.

Maybe it'd be better to start with a concrete example of an attack,
demonstrate its utility to the attacker, and then show how this prevents
the attack?

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] standardization process (was: Re: XEP-0353 propose id syntax)

[Dave Cridland]

On Thu, 5 Jan 2023 at 21:38, Florian Schmaus  wrote:

> On 05/01/2023 16.31, Peter Saint-Andre wrote:
> > On 1/5/23 3:18 AM, Florian Schmaus wrote:
> >
> >> I become more and more convinced that we may be better with an IETF
> >> I-D / RFC style standardization process. Where an I-D is a mutable,
> >> living document on the road to become an immutable RFC.
> >
> > You know, we could move all of our activities to an IETF Working Group...
>
> I would not want to replace our document tooling with xml2rfc. I really
> like what we have to produce high quality publishable standards documents.
>
>
> It is really just the process that needs to change. My idea is as follows:
>
>
I think all you've done is "shift left", so that ProtoXEPs take the place
of Experimental, and Stable/Final become formally frozen in terms of
compatibility.

Changing Experimental for ProtoXEP is really just a name change (modulo
you'd like to publish without Council approval, and I am ambivalent to
that). You're removing, though, a lot of the protections for deployability
we have with Experimental.

Then you're tightening Stable/Final, so that namespace bumps there would
never happen (though they're astonishingly rare now).

So I'm left wondering what problem you think you're actually solving here?
It might - if we're to rehash the standards process at all - be good to
list the desirable outcomes, then the problems we have, and only then worry
about finding a solution.

I don't pretend our process is perfect (or slim enough), but I do think
it's mostly OK.


> Introduce an I-D-like incubating phase of ProtoXEPs. Everyone is able to
> create a new incubating ProtoXEP, no Council review required. The
> ProtoXEP is mutable at any time and there are no namespace bumps
> required for breaking protocol changes. But there are fixed revisions of
> incubating ProtoXEPs that can be referenced (akin to I-D revisions).
>
> When the authors feel the ProtoXEP is ready for a council review they
> submit it. The council should check, amongst other things, if the
> specification is idiomatic XMPP (but ideally, such things are already
> taken core of in the incubating phase). Even if the council demands
> breaking changes to the specification it should be trivial to
> incorporate them, as specification was a moving target before anyway. If
> the authors oppose the changes, then they still have a document with a
> stable ID (and URL) to share, even if not blessed by the council and not
> a "real" XEP.
>
> Once the council accepts a ProtoXEP and it becomes a XEP. And only the
> addition of editorial changes, clarifications, and implementation advice
> is allowed [1]. Namespace bumps are not allowed, but instead should be
> done via a new incubating XEP.
>
> XEP states would cease to exists. But council may later elevate a XEP to
> become recommended and/or adds it to the compliance suite.
>
>
> I've been thinking about such a change for a while (years). And I spoke
> with a few of you about it at various occasions. But this is the first
> time I wrote it on standards@ and I would appreciate any feedback.
>
> - Flow
>
> 1: So it is different from an RFC, which is strictly immutable once
> published. The IETF has an errata process to pin information to an RFC
> after it was published.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0353 propose id syntax

[Dave Cridland]

On Thu, 5 Jan 2023 at 10:19, Florian Schmaus  wrote:

>
> On 05/01/2023 10.51, Dave Cridland wrote:
> > * The argument that this doesn't need a namespace bump is wrong because
> > "experimental" has no effect here. The entire point of those 'versioned'
> > namespaces was to ensure that we could freely implement Experimental
> > XEPs without worrying about causing compatibility nightmares. The
> > argument that there's no implementation is counter-productive - if
> > there's nobody implementing, then by definition it doesn't matter if you
> > bump the namespace.
>
> +1
>
> I see a recent trend in the community that it is acceptable to introduce
> backwards incompatible changes in 'experimental' XEPs. I think we are
> moving along a dangerous path if this trend continues.
>
>
For a long time, it tended to be the opposite problem - people would add an
optional attribute or child element, and then bump the namespace. That's
irritating (and harms interoperability in a safe manner), but not as bad as
introducing incompatible changes and *not* bumping the namespace.


> However, I believe that this trend is part a symptom of a larger
> problem. Namely that we e are missing a workflow where people can work
> together on a standards document, while implementing what is described
> in that document and still be able to react agile regarding protocol
> changes. The latter means, amongst other things, being able to introduce
> backwards incompatible changes without a namespace bump.
>
>
I think we have that, modulo that if we introduce an incompatible change,
we bump the namespace. And in many cases, you can handle both namespaces
easily with one or two conditionals, so if you're closely tracking a XEP in
your implementation, it's usually OK.

The advantage of our model is that if people are not working closely
together, it's still safe.


> I become more and more convinced that we may be better with an IETF I-D
> / RFC style standardization process. Where an I-D is a mutable, living
> document on the road to become an immutable RFC.


Well... An Experimental XEP maps to an I-D, except we've made ours safe to
implement in the wild (fairly) safely.

RFCs map to DraftStable/Final XEPs. These still might change, but this
really ought to be pretty rare, especially with Final. The fact they're not
immutable is, I agree, not ideal - but the static nature of RFCs brings its
own set of problems and I'm not really sure which is the better option.

I think the thing I'm missing is that I sometimes want to be able to find
the latest XEP version covering a particular namespace, but that requires
tooling changes etc and I don't care enough to fix it myself, so...

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0353 propose id syntax

[Dave Cridland]

On Thu, 5 Jan 2023 at 12:35, Marvin W  wrote:

> Which brings me to the conclusion: If we want to gauarantee a certain
> amount of randomness in any id field, we should just state exactly
> that, e.g. "the id SHOULD include at least 120 bits of randomness, for
> example by using an UUIDv4" (and then we might see people in the wild
> just encode 15 random bytes using base64, saving 16 bytes on the wire
> with every id).


For the "SHOULD" case, yes. For the MUST case, if we're basically encoding
a 128-bit number with a well-known syntax supported by external tooling
like databases, then UUIDv4 is pretty much perfect.

(I'd phrase the "SHOULD" case as "This identifier MUST be globally unique,
and therefore it is RECOMMENDED to use UUIDv4", rather than specifying bits
of randomness - the RECOMMENDED here is in the sense of "If you don't do
this you'd better know what you're doing").
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0353 propose id syntax

[Dave Cridland]

On a Github PR XEP-0353: Add requirement for UUID v4 for id attributes by
tmolitor-stud-tu · Pull Request #1262 · xsf/xeps · GitHub
, Thilo wrote:

> I think explicit is better than implicit, hence this PR.

> Since v0.4 of this XEP isn't implemented by any client yet (to my
knowledge) and because the XEP is still experimental, I think we can do
this update without bumping the namespace.
What do you thing @fippo  @stpeter
 ?


[Aside: Having been bitten by conversations happening off the list, and
therefore with less visibility than I (at least) would like, I'm dragging
this conversation back to the list]

The suggestion here is that the `id` field should be defined as being a
UUIDv4, mandatorily.

Also, that this doesn't need a namespace bump.

I think both of these are wrong:

* The argument that this doesn't need a namespace bump is wrong because
"experimental" has no effect here. The entire point of those 'versioned'
namespaces was to ensure that we could freely implement Experimental XEPs
without worrying about causing compatibility nightmares. The argument that
there's no implementation is counter-productive - if there's nobody
implementing, then by definition it doesn't matter if you bump the
namespace.

* In general, I think ids expected to be reasonably unique ought to be
UUIDv4. I mean, why not? But I'm hesitant to mandate this absolutely, such
as in this change, because although I'd like *senders* to always use a
UUIDv4, I'm a bit concerned about *receivers* making that assumption, and
trying to parse out a UUIDv4 and storing it in a 128-bit number or
something. In some cases, that'd be a handy thing (I've done this
internally with MAM identifiers, for example), but I think we should be
very careful about when this is the right choice.

So, I'd suggest "SHOULD" here at most, and I might choose to phrase it as
"RECOMMENDED", which has the same RFC 2119 meaning, but somewhat different
implicit meaning in English.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Stream Limits Advertisement

[Dave Cridland]

On Sat, 31 Dec 2022 at 13:15, Florian Schmaus  wrote:

> On 31.12.22 13:19, Dave Cridland wrote:
> >
> >
> > On Fri, 30 Dec 2022 at 19:40, Florian Schmaus  > <mailto:f...@geekplace.eu>> wrote:
> >
> > On 30.12.22 11:05, Dave Cridland wrote:
> >  > On Thu, 22 Dec 2022 at 09:23, Matthew Wild  > <mailto:mwi...@gmail.com>
> >  > <mailto:mwi...@gmail.com <mailto:mwi...@gmail.com>>> wrote:
> >  > On Wed, 21 Dec 2022, 15:05 Florian Schmaus,  > <mailto:f...@geekplace.eu>
> >  > <mailto:f...@geekplace.eu <mailto:f...@geekplace.eu>>> wrote:
> >  > Zash's proposal is, as far as I understand it, just an
> >  > optimization
> >  > allowing a sending entity to determine if a stanza will
> > hit the
> >  > limit or
> >  > not, without trying to actually send it.
> >   >
> >  > It is and it isn't. Right now, if a stanza is over the limit
> then
> >  > most implementations will close the connection with a stream
> > error.
> >  > Not closing the connection is non-trivial for implementations
> if
> >  > they want to avoid DoS and use a standard parser.
> >  >
> >  > I think this is a good summary of why the  is needed
> > - it
> >  > allows a sending implementation to alter its behaviour for the
> > better.
> >  >
> >  > I don't think there's the same justification for ,
> >  > though, is there? What would a sending implementation do?
> >
> > Uh, there is much value in the information found in .
> > Simply put, it allows the receiving side to delay liveness checks for
> > the connection until it has been idle longer than idle-seconds.
> >
> >
> > Really? So as a client, if a server says that connections can be idle
> > for up to 1800s, you'd not bother checking them for a half hour?
>
> I guess this is up to the implementation to decide.
>
>
Yes, though I wonder if this falls into the category of a little knowledge.


> > I can see why the *server* might adapt its liveness checks to match the
> > client's, but this XEP doesn't cover that.
>
> I assume the XEP has also s2s connections in mind? Whereas I am mostly
> concerned about c2s connections, especially mobile ones.


I suppose so, but the only case where this makes sense (to me, mind, and
what would I know about S2S on flakey networks?) is where you have a bidi
S2S session and both sides can adapt the liveness checks to be the minimum
of either party, only that's what they'd be anyway in effect. But explicit
> implicit.

Also, if you have '198 in effect, do we care about idle anymore?

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Stream Limits Advertisement

[Dave Cridland]

On Fri, 30 Dec 2022 at 19:40, Florian Schmaus  wrote:

> On 30.12.22 11:05, Dave Cridland wrote:
> > On Thu, 22 Dec 2022 at 09:23, Matthew Wild  > <mailto:mwi...@gmail.com>> wrote:
> > On Wed, 21 Dec 2022, 15:05 Florian Schmaus,  > <mailto:f...@geekplace.eu>> wrote: > Zash's proposal is, as
> far as I understand it, just an
> > optimization
> > allowing a sending entity to determine if a stanza will hit the
> > limit or
> > not, without trying to actually send it.
>  >
> > It is and it isn't. Right now, if a stanza is over the limit then
> > most implementations will close the connection with a stream error.
> > Not closing the connection is non-trivial for implementations if
> > they want to avoid DoS and use a standard parser.
> >
> > I think this is a good summary of why the  is needed - it
> > allows a sending implementation to alter its behaviour for the better.
> >
> > I don't think there's the same justification for ,
> > though, is there? What would a sending implementation do?
>
> Uh, there is much value in the information found in .
> Simply put, it allows the receiving side to delay liveness checks for
> the connection until it has been idle longer than idle-seconds.
>
>
Really? So as a client, if a server says that connections can be idle for
up to 1800s, you'd not bother checking them for a half hour? If a server
sees the connection drop (TCP RST from NAT or something) then the client
won't know about it, so surely both need to perform liveness checks as they
see fit.

I can see why the *server* might adapt its liveness checks to match the
client's, but this XEP doesn't cover that.


> I actually have some very unfinished ProtoXEP from 2017 with similar
> goals (and a bit more [1]):
>
> https://geekplace.eu/xeps/xep-dpmipy/xep-dpmipy.html
>
>
> I think many initial implementations of (bidirectional) XMPP connections
> start with some sort of periodic ping to check if the connection is
> still alive. Then, at some point later some nifty developer recognizes
> that such checks only need to be performed after the connection has been
> idle for a while. Now the developer changes the implementation to check
> every N minutes if the connection has been idle for M minutes, and only
> performs the liveness check if this is the case. This avoid unnecessary
> pings, which is especially important for mobile devices so that they are
> not unnecessary woken up by pings.
>
> Now the question is how to determine M? If the mobile client tells the
> server that it will perform liveness check every 60 minutes, because
> that is when other scheduled actions will take place on the mobile
> device and hence the device won't be in deep sleep anyway, then the
> server could simply set M to 60 minutes [2].
>
> That, at least, was my motivation for said ProtoXEP. But it appears,
> from the description of , that it also shares the
> motivation (but maybe there is more to it?).
>
>
This all makes (a lot of) sense, but isn't possible with the proposal.


> - Flow
>
>
> 1: The idea of my ProtoXEP is that the client tells to the server that
> the server should not ping the client, as the client will ping the
> server after the connection has been idle an client-announced period of
> time. With the goal to reduce unnecessary wakeups of the mobile device
> because of server-to-client pings.
>
> 2: The situation is actually a tiny bit more complex because scheduled
> actions on mobile devices are typically coalesced. But that only means
> that clients have to add the maximum coalescing period to the scheduled
> interval when calculating M.
>

This feels like some guidance would be warranted, akin to (or part of)
XEP-0286.


> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0474 (SASL SCRAM Downgrade Protection)

[Dave Cridland]

On Tue, 13 Dec 2022 at 18:04, Jonas Schäfer  wrote:

> Version 0.1.0 of XEP-0474 (SASL SCRAM Downgrade Protection) has been
> released.
>

I had a long discussion off-list with Thilo on this, and I broadly think it
has very little utility - at best, you can tell if you've been downgraded
*to* a SCRAM-family mechanism, but one that is still considered secure
(since otherwise the attacker could trivially forge the ssdp SCRAM
attribute). So this surely only detects a downgrade when the downgrade
hasn't been successful. No?

Out of curiosity, if we were to say that the mechanisms and TLS channel
bindings stream features were repeated after the authentication (perhaps as
actual stream features, but more sensibly somewhere else -  and
 possibly?) would this satisfy the requirements better?
Differently? Not at all?

And if this isn't making things better, are we better off talking about
clients latching on preferred mechanisms?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Stream Limits Advertisement

[Dave Cridland]

On Thu, 22 Dec 2022 at 09:23, Matthew Wild  wrote:

> On Wed, 21 Dec 2022, 15:05 Florian Schmaus,  wrote:
>
>>
>>  Zash's proposal is, as far as I understand it, just an optimization
>> allowing a sending entity to determine if a stanza will hit the limit or
>> not, without trying to actually send it.
>
>
> It is and it isn't. Right now, if a stanza is over the limit then most
> implementations will close the connection with a stream error. Not closing
> the connection is non-trivial for implementations if they want to avoid DoS
> and use a standard parser.
>

I think this is a good summary of why the  is needed - it
allows a sending implementation to alter its behaviour for the better.

I don't think there's the same justification for , though,
is there? What would a sending implementation do? Defeat the idle check? To
what end? I *thought* we recommended a proper liveness check, so in
principle the idle timeout is a mere implementation detail, and shouldn't
alter behaviour on the other side.

Also, is it worth including a full stream features inside (or after?) bidi?
(I've lost track of how well bidi is implemented, and therefore whether
it's worth doing a version-bump, but this is the first case I'm aware of
where bidi would include a child element, so maybe a version bump here is
easiest?)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Dave Cridland]

On Sat, 19 Nov 2022 at 18:50, Matthew Wild  wrote:

> On Sat, 19 Nov 2022 at 18:31, Dave Cridland  wrote:
> > On Sat, 19 Nov 2022 at 16:33, Daniel Gultsch  wrote:
> >>
> >> The  stream feature wrapper is just a neat wrapper for all
> >> stream features that can be inlined into SASL to announce themselves.
> >> Yes ISR works without inline but that's not the point.
> >>
> >
> > Well, that wasn't in fact the point I was making there - I meant the
>  element within the TLEs.
> >
> > But you're right, neither adds any actionable information whatsoever, so
> isn't useful and therefore should not be added.
> >
> >>
> >> Imagine we want to make compression inline-able. Simply by looking at
> >> the  stream feature a client doesn’t know if compression
> >> can be inlined into SASL. So if we want to make compression inlinable
> >> the new XEP (or an amendment to the existing XEP) would have to either
> >> announce a new stream feature called  (This is
> >> kind of - but not really - what ISR is doing) or place itself in the
> >>  wrapper like this: 
> >>
> >
> > OK, so compression, let's take that as a worked example.
> >
> > A client absolutely knows that XEP-0138 isn't a XEP-0388 extension,
> because it isn't.
> >
> > You cannot simply advertise it in an  block and expect it to
> work, either. When would compression kick in? There's no specification that
> tells you. It might be obvious to you - it might even be obvious to me -
> but it's not specified, and my obvious may not match yours. So you need to
> define what that means, and it's a change in wire protocol, so implicitly
> that means that something new has to be advertised.
>
> I agree, you cannot just advertise anything in an  block and
> expect it to work. Nobody thinks that. Every protocol that supports
> inlining has specified exactly what that means. E.g. XEP-0198 has been
> updated with an additional section to cover this.
>
> Now I'll add that your suggestion also doesn't work: you can't just
> spec something and then expect it to work. Just because we update
> XEP-0198 with a section that describes how it can be inlined, that
> doesn't mean every server supporting SASL2 automatically understands
> XEP-0198 inlining. And as you pointed out, things may change over
> time. In other words, we *need* advertisement and discovery for this
> feature.
>
>
Yes, of course.

So we agree that a SASL2 variant of an existing extension has to have a
stream feature.


> >> It's just a syntax modification that some people find more pleasent;
> >> not a new addition to the XEP to achieve something that wasn’t
> >> possible before.
> >
> > Oh, but it carries all manner of implications.
> >
> > Supposing that we change the wire protocol of XEP-0198 to support
> directly using it as a SASL2 extension. So that means advertising the same
> stream feature under , by this design. So far, so good.
> >
> > But supposing that the SASL2 extension part needs changing - in that
> case, we need to bump the namespace of that - but we don't want to break
> compatibility with the old-style stream feature. So now we have to
> advertise a different stream feature if you're inlineing it, and then if
> the main one changes but the ... you get the drift, I hope.
>
> I don't really understand this concern. A XEP can specify anything to
> be contained in . If the inlining portion of a XEP (only)
> needs to change, then of course it will need to advertise that
> somehow.  doesn't change that either way.
>
>
It means the features advertised in the  block are not simple
restatements of the same features outside; they are themselves distinct
features with a distinct lifecycle, only now we're advertising stream
features in multiple places.

In effect, you're reinventing the stream feature mechanism inside another
stream feature.

> Incidentally, if SASL2+BIND2+etc take over the world, then you'll be
> repeating all these stream features and/or having all stream features
> nesting eternally inside each other.
>
> I don't see how  adds any need for repetition. If 
> didn't exist, everything still has to indicate in some way whether it
> can be inlined or not. Sure, we can have  and
>  features perhaps, but I find  is a much
> cleaner and more logically obvious solution to this issue.
>

I find advertising some stream features only inside other stream features
an additional complexity that's not warranted.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #1 client-identifier

[Dave Cridland]

On Sat, 19 Nov 2022 at 18:34, Matthew Wild  wrote:

> On Sat, 19 Nov 2022 at 15:14, Dave Cridland  wrote:
> >
> > I commented about this on the PR, but that seems to have been dismissed,
> so again, for the list:
> >
> > * I'm not convinced this is required to be a mandatory feature of SASL2,
> despite its obvious utility, but I'm not going to argue very strongly that
> it shouldn't be.
> > * I *am* convinced that an id attribute has to be mandatory (and SHOULD
> be a UUIDv4).
> > * I am also convinced that the human-readable software information
> shouldn't be mandatory.
>
> I agree that neither of these should be mandatory, and that's why they
> aren't. If there are reasons for clients not to include them, they
> don't have to. Not including them may have consequences - e.g. the
> FAST spec depends on the client id being present so wouldn't be
> usable, and if the software info isn't included then the user will be
> less informed about what is connecting to their account. For such
> reasons, it is recommended that they are included. But mandatory, no.
>
>
Clients SHOULD also include a user-agent/> element, informing the
server about the connecting client. The 'id'
attribute is RECOMMENDED, and if present it contains a unique stable
identifier for the client installation. This allows
the server to provide functionality such as deriving stable resource
identifiers (see ). The child elements software/> and device/>
contain text descriptions of the client software and the device it is
installed on. These allow the server to keep the user informed
about what devices are connected to their account. Servers MUST NOT expose
this information to other entities (such functionality is available in
 if required).

So...

The  isn't mandatory, no, and I stand corrected on my first
point. I'm not convinced this should be a part of SASL2, as such - but to
be clear, I'm not convinced it shouldn't be either.

But if included, then the id isn't mandatory, which was my second point - I
think the id needs to be a MUST for this to have value, whether or not the
software info is supplied.

The child elements aren't explicitly mandatory or optional in this
paragraph, but are included in every example. I'd assumed they were
mandatory based on this and the phrasing "The child elements ... contain" -
no "if present" as with the id attribute. Certainly it's very unclear if
they're recommended, optional, or mandatory. Is there some other text I'm
missing? It's not in the schema, as far as I can find, either.


> Regards,
> Matthew
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Dave Cridland]

On Sat, 19 Nov 2022 at 16:33, Daniel Gultsch  wrote:

> The  stream feature wrapper is just a neat wrapper for all
> stream features that can be inlined into SASL to announce themselves.
> Yes ISR works without inline but that's not the point.
>
>
Well, that wasn't in fact the point I was making there - I meant the
 element within the TLEs.

But you're right, neither adds any actionable information whatsoever, so
isn't useful and therefore should not be added.


> Imagine we want to make compression inline-able. Simply by looking at
> the  stream feature a client doesn’t know if compression
> can be inlined into SASL. So if we want to make compression inlinable
> the new XEP (or an amendment to the existing XEP) would have to either
> announce a new stream feature called  (This is
> kind of - but not really - what ISR is doing) or place itself in the
>  wrapper like this: 
>
>
OK, so compression, let's take that as a worked example.

A client absolutely knows that XEP-0138 isn't a XEP-0388 extension, because
it isn't.

You cannot simply advertise it in an  block and expect it to work,
either. When would compression kick in? There's no specification that tells
you. It might be obvious to you - it might even be obvious to me - but it's
not specified, and my obvious may not match yours. So you need to define
what that means, and it's a change in wire protocol, so implicitly that
means that something new has to be advertised.

So, as you note, either way something new has to be advertised, so the
 there is just additional cruft.

But once negotiated, there's no need to put it in an  element in
the messages anyway - what value does that add? The entire syntax of SASL2
was explicitly designed to handle extension, that was literally a stated
goal.


> It's just a syntax modification that some people find more pleasent;
> not a new addition to the XEP to achieve something that wasn’t
> possible before.


Oh, but it carries all manner of implications.

Supposing that we change the wire protocol of XEP-0198 to support directly
using it as a SASL2 extension. So that means advertising the same stream
feature under , by this design. So far, so good.

But supposing that the SASL2 extension part needs changing - in that case,
we need to bump the namespace of that - but we don't want to break
compatibility with the old-style stream feature. So now we have to
advertise a different stream feature if you're inlineing it, and then if
the main one changes but the ... you get the drift, I hope.

So repeating the same stream feature inside a SASL2 stream feature as
 isn't actually what you want.

You do, genuinely, just want a new stream feature.

Incidentally, if SASL2+BIND2+etc take over the world, then you'll be
repeating all these stream features and/or having all stream features
nesting eternally inside each other.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Dave Cridland]

On Sat, 22 Oct 2022 at 22:29, Thilo Molitor  wrote:

> Again, MattJ already explained this well:
> https://mail.jabber.org/pipermail/
> standards/2022-October/038998.html
> 
>
> SASL2 allows for inlining additional elements into the authentication flow.
> That, like pipelining, reduces round-trip-times.
> To let clients distinguish, which features can be inlined into the SASL2
> authentication flow and which features are supported by the server but can
> not
> be inlined, a new "namespace" for inlinable features is needed.
>
>
When I designed SASL2, I designed it such that arbitrary elements could be
introduced anywhere in the flow by having them within SASL2 top-level
elements. I certainly didn't intend to imply that this meant that clients
could inject top-level-elements from other extensions that happened to be
supported without negotiation. I'm not sure where that came from.


> As MattJ says:
> > It's important to stress that, despite calling out XEP-0198 and Bind 2
> > in the changelog and text, this is intended for example purposes only.
> > There is no intention to increase the scope of XEP-0388 to cover which
> > specific protocols can be negotiated (in fact this is the whole reason
> > for introducing  as an extension point).
>
> The Bind2 update already in our pipeline as well as the XEP-0198 update
> use
> that  element as specified in our SASL2 update.
>
> In fact, Bind2 has it's own  element, too.
>

ISR, for example - XEP-0397 - doesn't need the  element at all to
handle XEP-0198.

You can argue it's too tied into HT-* or whatever, but the framework for
adding extensions into SASL2 exists already and I'm honestly confused as to
why a further  is needed here.


> > The split is between things that are enabled before resource binding,
> > and those that are enabled after resource binding. You can see an
> > example here: https://matthewwild.co.uk/uploads/xeps-tmp/
> xep-0386.html#example-1
>
> -tmolitor
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #1 client-identifier

[Dave Cridland]

I commented about this on the PR, but that seems to have been dismissed, so
again, for the list:

* I'm not convinced this is required to be a mandatory feature of SASL2,
despite its obvious utility, but I'm not going to argue very strongly that
it shouldn't be.
* I *am* convinced that an id attribute has to be mandatory (and SHOULD be
a UUIDv4).
* I am also convinced that the human-readable software information
shouldn't be mandatory.

On Sat, 22 Oct 2022 at 22:29, Thilo Molitor  wrote:

> I'm trying to rephrase and sum up here, what MattJ already said: https://
> mail.jabber.org/pipermail/standards/2022-October/038998.html
>
> Stable client-identifier:
> This allows per-device tokens or even passwords.
> It allows to present users with a list of devices that currently have
> access
> to their account.
>
> Software and Device:
> The software and device information allows users to better identify their
> clients than just using the opaque client-identifier: "Conversations on
> Kiva's
> iPhone" is far more descriptive than "0ba15cd[...]".
>
> @MattJ: Add it, if I'm missing something here
>
> -tmolitor
>
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection

[Dave Cridland]

On Wed, 19 Oct 2022 at 16:02, Thilo Molitor  wrote:

> Am Mittwoch, 19. Oktober 2022, 16:32:55 CEST schrieb Dave Cridland:
> > Small point: GS2 doesn't ever allow clients to know if channel binding is
> > proven, since the channel binding data is passed in the clear to the
> > server. It does prove the server saw the channel binding data as sent by
> > the client, but not whether the server can see the same channel.
>
> Surely the GS2 implementing server would abort authentication if the
> channel-
> binding data did not match it's own channel. right?


That would be a sensible and conformant implementation, yes.

 But what I was meaning is that the client cannot prove that the server has
done so. It's mostly an irrelevance, really - but when we're discussing
what can and cannot be proven at either end, I think it's important to be
accurate.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection

[Dave Cridland]

On Wed, 19 Oct 2022 at 14:59, Thilo Molitor  wrote:

> That's a wekness of SCRAM itself. Channel-binding problems will be
> detected
> after the client-final-message as well.
>

Small point: GS2 doesn't ever allow clients to know if channel binding is
proven, since the channel binding data is passed in the clear to the
server. It does prove the server saw the channel binding data as sent by
the client, but not whether the server can see the same channel.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection

[Dave Cridland]

On Wed, 12 Oct 2022 at 17:17, Jonas Schäfer  wrote:

> Title: SASL SCRAM Downgrade Protection
> URL: https://xmpp.org/extensions/inbox/xep-downgrade-prevention.html


Any attacker able to manipulate the data coming from the server such that
the client sees a restricted set of TLS channel bindings can also
manipulate the data coming from the server such that the client sees a
restricted set of SASL mechanisms, removing SCRAM entirely.

Moreover, if the client wants to use a stronger mechanism - let's say one
of the OPAQUE mechanisms in development - then it loses this protection.

Either way, I'd like more/different eyes on this - I'd highly recommend
taking this work to the IETF Kitten working group and seeing what they say.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection

[Dave Cridland]

404?

On Wed, 12 Oct 2022 at 17:17, Jonas Schäfer  wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: SASL SCRAM Downgrade Protection
> Abstract:
> This specification provides a way to secure the SASL and SASL2
> handshakes against method and channel-binding downgrades.
>
> URL: https://xmpp.org/extensions/inbox/xep-downgrade-prevention.html
>
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Channel binding and token authentication

[Dave Cridland]

On Tue, 27 Sept 2022 at 12:59, Matthew Wild  wrote:

> On Tue, 27 Sept 2022 at 12:31, Dave Cridland  wrote:
> > On Tue, 27 Sept 2022 at 11:51, Matthew Wild  wrote:
> >> On Tue, 27 Sept 2022 at 11:36, Dave Cridland  wrote:
> >> > - I seem to remember that HT-* derives a lot of its replay protection
> from the channel binding, so we may want to have *something* there.
> >>
> >> What is the attack scenario here? Someone compromised TLS?
> >>
> >
> > Any case where an attacker obtains the SASL exchange itself, or can
> replay it by some other means (I think TLS Early Data has some weaknesses
> here).
> I'm not convinced this is very exploitable in any useful way, but I
> think it might be enough to do something in some cases.
>
> If an attacker is able to do this, they have either compromised your
> client, your server or TLS. In all three cases, I think SASL is the
> least of your worries.
>
> I understand that in some protocols it is more common to send your
> credentials to multiple different third parties, and ensuring that
> authentication is bound to the entity you think you are authenticating
> to fixes a large security hole.
>
> Here in XMPP this is rarely the case - users generally don't send
> credentials for service A to service B. And in this particular
> instance, we're talking about short-lived tokens that are already
> unique to the service you are connecting and authenticating to. There
> is nobody else to replay to that would accept the token.
>
> Looking beyond our own ecosystem, verified TLS and a session cookie
> are considered adequate protection for practically all online services
> today, from webmail to internet banking. They are susceptible to these
> same "replay attacks". Despite this reality, I've had many discussions
> with multiple XMPP community members in recent weeks, practically
> claiming the absolute necessity of channel binding. I just don't see
> it. I get that it's cool, and if you can do it, why not? But I don't
> think it is preventing any practical attacks at all.
>
>
All of which I broadly agree with to various degrees, however that's not
the attack here - the attack is that a passive observer can replay TLS 1.3
Early Data, and if a client developer (fairly sensibly) chooses to send a
SASL exchange there, that might get to the point of an authenticated
connection. It's one the attacker cannot control, mind - confidentiality
has still been assured - but if a client developer were to use TLS Early
Data to send both the SASL exchange *and* a message or something, then that
might be a problem.

In other protocols also using SASL, though, it might be a worse problem -
in principle some uses of Submission (ie, SMTP for sending mails) might be
susceptible here, and there could be some other issues even on broadly
readonly protocols like IMAP.

In any case, given the focus for HT-* is 0-RTT startup, it makes a lot of
sense to try to ensure it has some protection for replay - saying "Well, if
you want to save on round-trips, you can use HT-*-NONE, but then you'll
need to disable TLS Early Data and spend an additional RTT there" doesn't
seem like an ideal situation.

Meanwhile in the HTTP world, verified TLS and a session cookie is *very*
susceptible to replay attacks based on TLS 1.3 Early Data, and it's often
blocked as a result (for example, Cloudflare reject it for anything except
"plain" GET requests, and Go doesn't even implement it, and ... ). Given it
weakens forward secrecy for the Early Data, too, there's not just replay
issues to consider anyway.

Anyway, something to worry over when looking at HT-*-NONE - and to be
explicit, my knowledge here is getting very sketchy, so I don't even know
if HT-* with (say) TLS Exporter channel bindings is any better.


> > But note that there's at least three different problems here:
> >
> > - Do we need to specify an HT-*-NONE (or at least, something similar)?
> The answer to this is "probably, yes".
>
> Agreed. Previous discussions have included talk of stuffing tokens
> into PLAIN (which of course I've seen in multiple real-world
> deployments over the years). I'd rather not sanction that approach in
> a new spec, but it's pretty much the leading alternative.
>
> > - Can we minimize the need to use this, and encourage developers down a
> better path? I think we're in agreement that there's some good advice we
> can usefully give in some cases, but sadly not all.
>
> If we specify it, yes, we can provide guidance on it. As you noted,
> such guidance may already be warranted for tls-server-end-point
> already.
>
> > - Does a simplistic HT-*-NONE have some issues we'll want to address
> carefully - possibly to the point that we actually need some

Re: [Standards] Channel binding and token authentication

[Dave Cridland]

On Tue, 27 Sept 2022 at 11:51, Matthew Wild  wrote:

> On Tue, 27 Sept 2022 at 11:36, Dave Cridland  wrote:
> > On Tue, 27 Sept 2022 at 09:59, Matthew Wild  wrote:
> >>
> >> On Tue, 27 Sep 2022, 09:46 Dave Cridland,  wrote:
> > I'd not considered web clients - can they not obtain the server
> certificate at all, even these days?
>
> I'm not aware of any method to do so (which is certainly a shame).
>
>
Indeed... Never occurred to me there wouldn't be, especially these days
with Crypto.subtle and things.


> > - I'd assumed that all clients could use tls-server-end-point fairly
> easily. If that's not the case for web clients, that's clearly a problem.
> > - As a client, it's impossible to tell whether a server is validating
> the channel binding data or simply blindly accepting it anyway.
> > - Ideally, even with TLS termination before the XMPP server, the XMPP
> server can discover or be configured with its TLS certificate so it can
> verify that.
>
> Sure, in Prosody we default to the configured certificate but allow
> manually providing a hash to allow for setups where TLS is handled
> externally.
>
> > - I seem to remember that HT-* derives a lot of its replay protection
> from the channel binding, so we may want to have *something* there.
>
> What is the attack scenario here? Someone compromised TLS?
>
>
Any case where an attacker obtains the SASL exchange itself, or can replay
it by some other means (I think TLS Early Data has some weaknesses here).
I'm not convinced this is very exploitable in any useful way, but I think
it might be enough to do something in some cases.

I'm not sure that tls-server-end-point doesn't have the same weaknesses
with HT-*, mind. (IoW, I think it might have the same problems as no
channel binding at all, because it's a fixed string).


> >> Unless I'm misunderstanding your proposal.
> >
> > Well, my proposal is to think about it a bit before we commit, so maybe
> you're unwittingly accepting it anyway?
>
> I propose to consider that you might be right.


But note that there's at least three different problems here:

- Do we need to specify an HT-*-NONE (or at least, something similar)? The
answer to this is "probably, yes".
- Can we minimize the need to use this, and encourage developers down a
better path? I think we're in agreement that there's some good advice we
can usefully give in some cases, but sadly not all.
- Does a simplistic HT-*-NONE have some issues we'll want to address
carefully - possibly to the point that we actually need something different
in this case? Again, "probably, yes".

It might be that HT-* in general has much higher security than HT-*-NONE,
and it might be that we just have to live with that.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Channel binding and token authentication

[Dave Cridland]

On Tue, 27 Sept 2022 at 09:59, Matthew Wild  wrote:

> On Tue, 27 Sep 2022, 09:46 Dave Cridland,  wrote:
>
>>  Before committing to this, some observations:
>>
>> - HT-*-NONE is needed for cases where there's no TLS at all. These are
>> rare, but there's legitimate cases where this is a sensible choice.
>> - Channel bindings can be used in cases where TLS is terminated in
>> advance by either:
>>   - Using TLS Endpoint channel bindings, which merely mean the XMPP
>> server needs to know the certificate which is to be used, or
>>   - Just going through the motions and blindly accepting the client's
>> channel binding choice, perhaps most sensibly by again using
>> tls-server-end-point
>>
>> So I'm not *against* a HT-*-NONE, but I wonder if we should promote the
>> second bullet-point above the first?
>>
>
> What would you propose exactly? That web clients just send some junk data
> and servers just accept it?
>
>
I'd not considered web clients - can they not obtain the server certificate
at all, even these days?


> I think any mode that blindly accepts in this way is worse than explicitly
> not using channel binding. With the planned token authentication protocols,
> a token is bound to a specific mechanism. That means if it is obtained with
> support for channel binding, it can only be used for authentication with
> that channel binding. If the server isn't always verifying the channel
> binding data, this undermines the security of this mechanism.
>
>
Yes, but:

- I'd assumed that all clients could use tls-server-end-point fairly
easily. If that's not the case for web clients, that's clearly a problem.
- As a client, it's impossible to tell whether a server is validating the
channel binding data or simply blindly accepting it anyway.
- Ideally, even with TLS termination before the XMPP server, the XMPP
server can discover or be configured with its TLS certificate so it can
verify that.
- I seem to remember that HT-* derives a lot of its replay protection from
the channel binding, so we may want to have *something* there.


> Unless I'm misunderstanding your proposal.
>

Well, my proposal is to think about it a bit before we commit, so maybe
you're unwittingly accepting it anyway?

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Channel binding and token authentication

[Dave Cridland]

On Tue, 27 Sept 2022 at 08:39, Daniel Gultsch  wrote:

> But I agree that it should be optional; I already said this in the ISR
> thread: There are plenty of scenarios where channel binding is not an
> option.
>

 Before committing to this, some observations:

- HT-*-NONE is needed for cases where there's no TLS at all. These are
rare, but there's legitimate cases where this is a sensible choice.
- Channel bindings can be used in cases where TLS is terminated in advance
by either:
  - Using TLS Endpoint channel bindings, which merely mean the XMPP server
needs to know the certificate which is to be used, or
  - Just going through the motions and blindly accepting the client's
channel binding choice, perhaps most sensibly by again using
tls-server-end-point

So I'm not *against* a HT-*-NONE, but I wonder if we should promote the
second bullet-point above the first?

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Dave Cridland]

On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch  wrote:

> And yes we are currently implementing it. That's why I’m providing
> feedback on the XEP. And yes we are using it with compression and yes
> we do terminate TLS early and can’t use HT-* and yes we use PLAIN for
> regular logins too and therefor we don’t have an issue with the
> "downgrade" in security.
>
>
Just on the TLS early termination, could you still support
tls-server-end-point, which (IIRC) doesn't need anything but a static
configuration of the server's certificate?

It's also a SHOULD, I saw, in XEP-0440 - I'd be inclined to raise that to a
MUST, even though I prefer tls-exporter if possible, because it's very easy
to support. Assuming, of course, that any form of channel binding is
possible.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Dave Cridland]

On Wed, 24 Aug 2022 at 12:19, Matthew Wild  wrote:

> On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch  wrote:
> >
>
> > And yes we are currently implementing it. That's why I’m providing
> > feedback on the XEP. And yes we are using it with compression and yes
> > we do terminate TLS early and can’t use HT-* and yes we use PLAIN for
> > regular logins too and therefor we don’t have an issue with the
> > "downgrade" in security.
>
> I'm also looking at potentially implementing it in Prosody very soon,
> as part of the modern auth project (
> https://docs.modernxmpp.org/projects/auth/ ).
>
> My main motivation is support for 2FA, which is impractical without a
> way for devices to re-identify themselves (you don't want an OTP
> prompt every time your mobile reconnects to the server). ISR seems to
> be a good way to fill that gap, while providing other benefits. The
> alternative on my radar is XEP-0399 (Client Key).
>
>
I have implemented Client Key, of course. I have also sketched out an HT-*
implementation.

While I like Client Key for all sorts of reasons - for one thing, the
counter gives you a better binding to the client device - HT-* is way
easier to implement and deploy. We might want XEP-0399's device list
management at some point, for sure, but let's focus on what's easiest to
get out and deploy.

XEP-0400 works for enrolling and requiring a TOTP-based 2FA across an
entire server - there is no optional enrollment, so if we want that we'll
have to consider how. It might be the trigger needed to develop optional
Post Auth Tasks in SASL2.


> I do agree that while the goals of enforcing channel binding are
> noble, it is impractical to enforce across the network. It excludes
> web clients and a bunch of deployments that terminate TLS before the
> XMPP server. What are thoughts on a HT- variant without channel
> binding (and adding RFC 9266's tls-exporter while we're at it)?
> Combined with ISR's mechanism pinning, I think this still provides
> some advantages over just using PLAIN (which is icky, but the
> alternative).
>
>
Thilo Molinar has some thoughts around better negotiation of TLS channel
bindings as part of SASL2.

As for an HT-*-NONPLUS, I think that's reasonable.

I also think - unverified by code or a recent reading of HT-* - that my
suggestion of butchering HT-* into payloading an encrypted
username/password pair works, so that covers that side, in which case we've
a workable solution for most deployment cases.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP Versioning

[Dave Cridland]

Hi,

I like that we're documenting the versioning mechanism we use for XEPs, so
- to be clear - I don't object to this change at all.

I'm not so sure on the rationale given, though:

@horazont  The reason for specifying that
topic was that @wurstsalat3000  wanted
to create a list of XEPs a client, library or server implements and show a
hint if the implemented version is not up-to-date. But such a hint should
not be shown for different patch versions since they are only meant for
editorial changes. The problem was that it was not clear and we could not
find any document that specified it. I will sent a link to this PR to the
corresponding mailing list.


(From GitHub)

So, if the XEP changes but it's purely editorial - that is, an
implementation is very unlikely to require changes - then as this comment
says it's irrelevant to interoperability.

If a major version changes, it is also irrelevant to interoperability,
though, since advancement doesn't change the XEP's content, only its state.

And if the minor version changes, it might have an effect on
interoperability or might not depending on whether the namespace changes.
If the namespace does not change between versions but we break interop,
then we have well and truly fucked up. (And if it was in
Active/Stable/Final, then Council have to buy us all beers or chocolate, as
per XEP-0028).

So should we maybe have that list show the hint based on the namespace, and
not the version number?

I've always assumed the version number to be as Kev says in his comment -
but perhaps more usefully, it's most useful as an opaque label for a
particular version, and semantics are best ignored outside of process
wonkery.

So yes, document away, but don't list XEPs by version - list them by
namespace if we need that level.

Dave.

On Wed, 24 Aug 2022 at 13:57, Melvin Keskin  wrote:

> Hi,
>
> I created a PR for precisely specifying the versioning of XEPs:
> https://github.com/xsf/xeps/pull/1200
>
> Here is the reason:
> https://github.com/xsf/xeps/pull/1200#issuecomment-1225678948
>
> Please let me know what you think.
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Dave Cridland]

On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch  wrote:

> I now realize that I get hung up on PLAIN at little bit in my previous
> e-mail. But what I was really saying is that ISR should allow any SASL
> mechanism with HT-* being just one possible (although good) choice.
>

Right. HT is great, it really is, but the fundamentals of ISR will work
with any SASL mechanism in principle.

Using PLAIN isn't ideal, but there's a number of deployments constrained
into using PLAIN - and probably plenty constrained into using a token-based
1-RTT mechanism too, which has similar outcomes.

Furthermore it would even allow me to use HT-* without ISR.
>

This too. The whole client-key stuff was aimed in a similar direction to
"HT-* without ISR". There's some entertaining work for someone in combining
all this together more coherently than I managed.


> WRT: Compressions. Dave in his email refers to it as XEP-0138 which is
> why a Ctrl-F didn’t yield any results. To add to Daves points. Making
> compression a SASL2 extension also fixes the somewhat weird issue
> where the session can not be resumed and the server thus doesn’t know
> if compression was enabled previously or not. It just makes
> compression explicit rather than handwavey "if it was enabled
> previously".
>
>
Yeah, exactly this. As I said 4 years ago, SASL2 was built so we can
negotiate everything at once without implicit negotiation, so we might as
well use it.


> And yes we are currently implementing it. That's why I’m providing
> feedback on the XEP. And yes we are using it with compression and yes
> we do terminate TLS early and can’t use HT-* and yes we use PLAIN for
> regular logins too and therefor we don’t have an issue with the
> "downgrade" in security.
>

(Well, you might have an issue, but not one you can address).

And yes, been there, done that, do not have a t-shirt but do have a badge
lanyard.

BTW, aside: if you're able to use a pure token mechanism, you can basically
pack the PLAIN response into a Fernet token or similar and keep the
security model identical. And you *can* use HT-* still, then, because of
the details of how GS2 TLS channel binding works, the server is always
given the binding data and can just blind trust it. You don't get actual
channel binding of course, but the authentication side still works.
Although you may never stop crying silently.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388: Extensible SASL Profile - implementations?

[Dave Cridland]

Hi Matthew,

I did an implementation for Openfire some years ago, including TOTP and
other bits, and updated the XEP based on what I discovered.

In practical terms, I think it should work well in its current state.

The code I wrote is open source, but was never in a state to merge to the
upstream, I'm afraid.

Dave.

On Thu, 16 Jun 2022 at 15:48, Matthew Wild  wrote:

> Hi folks,
>
> Is anyone aware of client or server, public or private,
> implementations of XEP-0388?
>
> I'm planning to begin an implementation for Prosody in the near future.
>
> Regards,
> Matthew
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Moving server-side MAM search forwards

[Dave Cridland]

On Sun, 12 Jun 2022 at 18:02, Matthew Wild  wrote:

> Hi Dave,
>
> On Sun, 12 Jun 2022 at 13:19, Dave Cridland  wrote:
> >
> > Hey Matthew,
> >
> > Many thanks for this, and also many thanks for raising these on the list
> first instead of quietly via the document author, and my apologies for a
> slow response.
>
> Thanks for the eventual response - I'm in no particular rush for this.
> I just see people moving ahead and implementing what I see as a
> mistake for the ecosystem, and wanted to provide what I see as a
> better path forwards.
>
> A large part of your response is based on the idea that I (and the
> text I proposed) is advocating only an  "exact substring search". That
> was *not* the intention. In particular, Postgres has plainto_tsquery
> which would absolutely satisfy the requirements for simple search.
> Lucene and ElasticSearch also offer similar solutions that tokenize
> the input terms without any syntax interpretation. I don't see any
> barriers to efficient simple text searches (they happen all the time
> across most online services daily).
>
>
Ah! Then I did indeed misunderstand you.


> What I'm trying to prevent is leaking implementation-defined esoteric
> syntax to end users. That at least one implementation is already
> exposing Lucene's special query syntax via this XEP is enough to
> convince me that simple searches are worth pushing for.
>

Right, exposing something like Lucene is clearly insane on many levels.

I'm not convinced that exposing any sort of syntax is bad, though -
allowing the kind of syntax that websearch_to_tsvector allows seems
harmless. But if we're faced with people that genuinely think exposing a
search language, rather than interpreting an end-user search string, is
sensible then we have clearly lost anyway.


>
> I agree regarding the rest of your email(s). Searching against full
> text indices is essential for any production service. Often these are
> language-specific, which is what led me to add the language indication
> in my proposal as well.
>
> Hopefully this clarifies my intentions with the proposed changes. It
> would appear we're in agreement on the requirements for efficient
> searches.
>
> Regards,
> Matthew
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Moving server-side MAM search forwards

[Dave Cridland]

On Wed, 8 Jun 2022 at 12:20, Matthew Wild  wrote:

> On Mon, 6 Jun 2022, 08:56 Kevin Smith,  wrote:
>
>> Hi Matt,
>>
>> -- Original Message --
>> From: "Matthew Wild" 
>> To: "XMPP Standards" 
>> Sent: 03/06/2022 10:50:03
>> Subject: [Standards] Moving server-side MAM search forwards
>>
>> >   1) Add a "simple" search type, which is recommended to be
>> >implemented as a baseline for interoperability. For simple searches,
>> >the server promises that no search terms or symbols will be
>> >interpreted as special syntax - what you search is what you get.
>>
>
> If it's not a silly question - do we *need* a simple type as well as the
>> default search? I think using  to describe syntax makes sense,
>> but I'm not entirely sold on the need for the simple search (less so for
>> it to be the recommendation) - almost all the search fields people use
>> daily have special syntax (search engines, mail clients, chat clients,
>> OS file search...) and by being well-crafted I strongly suspect most
>> users have never clicked the syntax expansion and never realised there
>> was an advanced syntax (and never suffered for it). Given that even the
>> proposed simple search allows implementation-specific magic to be
>> performed, would we not be better off by sticking to the one field, and
>> providing helpful hints on it (maybe just ) rather than needing
>> to somehow bifurcate the search UI?
>>
>
> My expectation is honestly that the vast majority of clients will just
> expose simple searches to the user, to provide the most consistent
> experience. As you say, most users are unlikely to spend time getting
> familiar with any advanced search syntax anyway. If they do, it's going to
> be quite confusing for them if this syntax changes depending on the service
> they are querying (e.g. different MUC services).
>
> Also, the "simple" search is easiest and safest to expose from a server's
> perspective. Many of the "advanced" queries exposed by backends (e.g.
> Lucene has been mentioned) are not really designed for exposure to a
> general audience. It is possible to craft (intentionally or
> unintentionally) malformed queries, and queries that cause excessive
> resource consumption or worse (
> https://issues.apache.org/jira/browse/SOLR-11477 ).
>
>
Believe me, you don't want table scans over the entire MAM archive table
either. That nearly brought down the entire service at Pando, and we
weren't even doing searching at that point.


> If you think there is still too much wiggle room for
> implementation-defined behaviour in the definition of the simple search,
> I'm happy to restrict it further with more wording. However I personally
> don't feel that's necessary.
>
> To me there are many benefits of defining (and requiring) simple searches:
> implementation simplicity, interoperability, user experience. Advanced
> searches are potentially unsafe from a server perspective and unpredictable
> from a user/client's perspective. We need more consistency in the
> ecosystem, not less- and this is unavoidably a user-facing protocol feature
> that clients can't easily patch a better UX over.
>

At the risk of sounding flippant, the likes of Google and Bing/Microsoft
have managed to deliver non-simple searches very well - and yet have also
not offered the "simple" search you describe at all. Google even managed to
build an entire business off this strategy, all the while keeping the exact
nature of their search and ranking entirely secret. Evidence really does
not suggest that an exact substring search is what anyone at all wants.

We have many specifications where a server can, with malignance and
malice aforethought, do really stupid and unexpected things. We can
advertise MAM, but with a zero retention. We can reject every stanza with a
policy error. We can, in fact, do all manner of things if a server
developer is actively out to get the user.

Yet we still have pretty good interoperability because server developers
don't do this.

I don't see this as a problem that exists in practical terms.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Moving server-side MAM search forwards

[Dave Cridland]

Hey Matthew,

Many thanks for this, and also many thanks for raising these on the list
first instead of quietly via the document author, and my apologies for a
slow response.

On Fri, 3 Jun 2022 at 10:51, Matthew Wild  wrote:

> Hi folks,
>
> Thanks to Guus's persistence, I finally took time to close a few
> issues I have with the current XEP-0431 (Full Text Search in MAM).
>
> The main issue is that the current version of the spec provides no
> guarantees about how the search string (generally input from a user)
> will be interpreted. Usually in such cases, I would say this is
> fine... an implementation that returns all messages containing "bar"
> when you submit a search for "foo" is obviously broken and nobody
> would want to use it, even if it's 100% permitted behaviour by the
> XEP.
>
>
Yes. The problem is I don't believe that one can usefully codify anything
here without going deep into stemming and stop words, and since nobody
(sane) will write their own free-text indexing system explicitly to match
this specification, it's very difficult to know what can be specified.


> But full-text search is actually a complex topic, and there are
> various backend implementations that servers are likely to lean on.
> Each of them has a different search syntax, and there is no way (in an
> open ecosystem) for a user to know which of these may be used.
>
> My proposal does two things to fix this situation:
>
>   1) Add a "simple" search type, which is recommended to be
> implemented as a baseline for interoperability. For simple searches,
> the server promises that no search terms or symbols will be
> interpreted as special syntax - what you search is what you get.
>
>
There was a reason I didn't include this in the original. :-)

Having implemented XEP-0431 server-side in a previous life, I'm not sure
this is universally possible - or rather, it is, but it's so poorly
performant I'm not sure I'd want anyone using it, and would probably
disable it.

Specifically, if we assume a PostgreSQL backend for the MAM archive, with
an extracted body field, the sensible way to handle FTS is to include a
computed index over that text (this isn't quite what I did, in fact,
because I encrypted the body text, but whatevs):

CREATE TABLE mam_archive (
  ...
  body TEXT,
  retracted BOOLEAN,
  ...
);
CREATE INDEX fts_mam_archive ON mam_archive USING gist (to_tsvector(body))
WHERE NOT retracted;

OK, so now I can implement a reasonably good full-text search:

SELECT * FROM mam_archive WHERE websearch_to_tsvector(${search_string}) @@
to_tsvector(body) AND NOT retracted

This will use an efficient index, and thus will be really quite fast.

But if I want to support a Dumb Substring Search, it'll be:

SELECT * FROM mam_archive WHERE body LIKE '%${search_string}%';

There's no index that I could do to help here, and therefore I'll be
forcing a full table scan, and there will be much howling and gnashing of
teeth.

Your suggested change says that supporting this is a SHOULD - in other
words, careful consideration ought to be given to the circumstances where
this might not be offered. But I don't think it's ever reasonable to offer
this - it cannot scale in any meaningful manner - and while it's
functionally possible, any clients relying on it to the exclusion of the
advanced search are surely going to discover it's unsupported. So a SHOULD
becomes, in practical terms, a SHOULD NOT.


>   2) Extend the existing ("advanced") search field with a
> recommendation that the server includes a  element (already
> defined in XEP-0004) to explain the supported syntax to the user, and
> an (entirely optional) machine-readable hint that can be used to
> indicate to a client that a commonly-used syntax is supported.
>
>
Yes, all sounds good.


> Finally, most full-text search engines are not language-agnostic. This
> is because they perform operations such as stemming, and utilize a
> "stop word" list while building the index to help improve the search
> results. Many default to English, and while searches in other
> languages generally work, they may be silently worse. I've added an
> optional tag through which the server can indicate the natural
> languages that the search is optimized for. I feel least strongly
> about this addition, since this information is usually going to be
> apparent to the user already based on the context.
>
>
So, funnily enough, I think this is very sensible, and moreover it may be
useful to offer users a choice about their own language, but also, one
could even change the indexing depending on the language of the stanza.

Note that this can still be performant:

CREATE TABLE mam_archive (
  ...
  body TEXT,
  pglang TEXT,
  retracted BOOLEAN,
  ...
);
CREATE INDEX fts_mam_archive ON mam_archive USING gist (to_tsvector(pglang,
body)) WHERE NOT retracted;

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: 

Re: [Standards] Danish chains too short

[Dave Cridland]

On Thu, 10 Feb 2022 at 04:46, Travis Burtrum  wrote:

> On 1/30/22 11:38, Dave Cridland wrote:
> > But the default choice to maximize interop should be to include the
> > trust anchor.
> >
> > 1) Do people agree?
>
> No. Because...
>
> > 2) If so, where on earth should we specify this? (A Best Practice doc on
> > PKIX/DANE?)
>
> We should instead specify in a best practice document for DANE+XMPP that
> only DANE-EE(3) should be supported/used.


Because?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Danish chains too short

[Dave Cridland]

Hi all,

XMPP servers typically do not include the trust anchor in the X.509 chains
they present to peers during TLS negotiation. This is broadly in line with
advice given in https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2,
where it notes that a certificate representing a trust anchor MAY be
omitted if it is known to the peer. In the typical PKIX world this is a
safe assumption - CAs are known to the peer, and if they're not, nothing
works anyway.

This does not, however, apply in the DANE-TA case (ie,
TrustAnchorAssertion). In this case, the trust anchor can be entirely
unknown to the peer except via the TLSA record (or, in Metre's case, a
synthetic record). Metre struggles even when the record includes the
FullCert data, which we could inject as a trust anchor prior to certificate
verification, but this would not be an option at all with matches based on
hashed or just the SubjectPublicKeyInfo.

Therefore, where servers construct the chain themselves (I'm thinking
ejabberd certainly, but possibly others), I think we should ensure the full
chain - including the trust anchor - is provided by default. This need not
be the case when the trust anchor is known to be known - for example, if
the peer is known to share the trust anchor, or if the trust anchor is
known to be a public CA (I'm thinking built-in ACME support).

But the default choice to maximize interop should be to include the trust
anchor.

1) Do people agree?

2) If so, where on earth should we specify this? (A Best Practice doc on
PKIX/DANE?)

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Compatibility Fallbacks

[Dave Cridland]

On Sun, 9 Jan 2022 at 13:38, Marvin W  wrote:

> Given that (as you know) I originally proposed this for XEP-0428 and you
> argued against, I'd say that updating XEP-0428 *was* my first choice,
> but it is your right as author to refuse this.
>

XEP-0001: XMPP Extension Protocols


No, it isn't! A XEP in Experimental state isn't the property of an author,
the author just gets the responsibility to incorporate feedback from
discussions on this mailing list. All published XEPs are owned, entirely,
by the XSF, and subject to change control under XEP-0001.

We have, as a community, generally deferred to the author to decide how to
(and indeed whether to) incorporate specific suggestions, but if the rough
consensus of the participants of the standards list is to add something, it
should be added even if the author is in the rough. If an author isn't
doing that, we find another author who will (and Council have,
historically, made that kind of decision formally).

But equally, if you're in the rough that doesn't mean you just submit
another XEP. That just gives us fragmentation, and it's something that the
Council has correctly pushed back on over the years (sometimes including
against XEPs I've proposed).

In this case, I don't think we got consensus either way. You made an
argument, I disagreed - but I certainly didn't intend to "refuse". I did
intend to see what other people thought before I went further - that is, I
wanted to get an idea of where the consensus was - but that's why I asked.
Nobody at all replied, and quite honestly I forgot about it, but it doesn't
seem to me that we got any kind of consensus.

The "for" thing I *did* mean to add, since I just didn't really see much
point but wasn't against it. Since everyone else seemed largely for it or
ambivalent, I would have added it - except that one slipped off my todo
list. I think, in my defence, I was waiting for replies to the other
question.

In the case of the other two XEPs you've proposed, it's actually worse -
both have close prior art, but unless I'm missing something these came as a
total surprise to the authors, who are both active (XEP-0353 is being
updated *right now*). As I said, this appears to be a general pattern, and
it's a worrying one to me.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Compatibility Fallbacks

[Dave Cridland]

On Sun, 9 Jan 2022 at 13:38, Marvin W  wrote:

> On 09.01.22 13:24, Dave Cridland wrote:
> > Still, as written, the ability send a message which is rendered in
> > *radically* different ways in different clients just fills me with
> > unease. Fallback bodies are nasty like this - it's why I've never been
> > happy with the "multipart/alternative" style of XHTML-IM, for example
>
> "multipart/alternative" style as you call it is being used in e-Mail for
> centuries. I might also be worth looking at other modern messengers like
> Matrix, which transports html and plain text as alternatives
> [https://spec.matrix.org/unstable/client-server-api/#mroommessage-msgtypes
> ].
>

Yes, I'm aware that "multipart/alternative" is used in email, hence my
usage of that particular MIME type to describe the style (I wouldn't say
centuries though - I remember MUAs getting MIME support as an exciting new
feature).

It doesn't surprise me that it's repeated in Matrix - it seems like a
practical, sensible idea at first, and it was the only reasonable option
for email, which prior to this had just plaintext ASCII email bodies. It
was generally impossible to update software on your workstation as well,
since (for most people) you only had user level access.

I'd still argue that it's a bad idea these days, even if Matrix haven't
learned from the trouble it's caused in email. Most other proprietary
messaging apps just have one form, the only reason email (and us, and
Matrix) went for alternatives is because of an existing deployed base that
only understood plaintext. This causes not only the problem of messages
having potentially wildly different meanings between the alternatives, but
also you can never get rid of the compatibility layer.

We (like Matrix) would have been better off without it - content
negotiation or graceful degradation are always better options when
available, and upgrading client software is vastly simpler than it used to
be as well.

RFC 1341, which introduced multipart/alternative, also introduced the
MIME-Version header. We repeated that error too - both our versions are
stuck forever at "1.0". (Mark Crispin actually predicted that one back in
1990 or so).

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Compatibility Fallbacks

[Dave Cridland]

On Sun, 9 Jan 2022 at 10:58, Marvin W  wrote:

> Hi,
>
> On 08.01.22 23:34, Dave Cridland wrote:
> > In this case, you've got a pre-existing fallback extension that you
> > *could* - and indeed *have* - proposed extending in exactly this way
> > without any problem, but for some reason you've decided to make an
> > entirely new one instead of continuing that discussion, which just feels
> > a bit odd.
> >
> > If you want to just edit that one please let me know, but otherwise, it
> > seems this is trying to do something in the same space but without using
> > the same XEP. This just feels like it's not really following the spirit
> > of our process at all, and it has to be considered an overlap since one
> > of the authors was actively proposing these changes to XEP-0428. What
> > happens if I update XEP-428 to support these use-cases?
> Beside "fallback" in the name, there is really no overlap in
> functionality of this ProtoXEP and XEP-0428. This is also explained in
> the ProtoXEP itself.
>
>
I'm astonished you can simultaneously argue that XEP-428 should have added
this functionality *and* the functionality has no overlap. Surely it must
be one or the other, and not both?


>  as described in XEP-0428 is basically similar to a
>  hint of XEP-0334 (which is hinted to in the XEP itself and
> also was explained by you on list) as such that it instructs
> intermediaries (servers) to handle the message as if there was no body.
> Clients have little use of this specification as they should only ignore
> the body if they understand what the message in question is actually
> supposed to transmit and thus will always know if they should ignore the
> body or not.
>
>
Well, part of the intent was that clients could know that it *was* a
fallback message, and render it as such, so the user knew that the message
wasn't being rendered at the sender intended. I know this isn't in the XEP,
but it was discussed at the time I think.

But yes, also the rejection of XEP-0334 does cause servers some problems,
so '428 fills that gap too. Arguably it shouldn't (or at least, not
always), but the loss of XEP-0334 was rather fresh in my mind, so as
written it is indeed equivalent to .


>  as described in the ProtoXEP in contrast is purely client
> side and only applies to a part of the body, never the full body.
> Intermediaries should not interpret it and if Stanza Content Encryption
> (XEP-0420) is used, this  element should be part of the
> encrypted payload and not outside, so that intermediaries are not even
> capable of interpreting it.
>
> Of course you can update XEP-0428 to divert from its current intended
> meaning. Or you just add new features to XEP-0428. If you feel that is
> more sensible, I'm open for that as well. It's not like it really
> matters in which XEP number this new client-side feature ends up, as
> long as it does end up in a XEP.
>
>
As I said, my concern is that updating '428 isn't the first choice here.
(See also, updating XEP-0353 and reusing any of the prior art at all in
replies). This feels like Not Invented Here.


> > Now, as it happens, my view is broadly unchanged after 18 months - I
> > think it gets very complicated when different extensions add bits of
> > textual markup they then need removing under some circumstances, and so
> > I worry that while this is a desirable UX, it's also a pretty nasty way
> > of getting there. The example given has parallel fallback "trims" for
> > markup and reply, and a client supporting both feature would have to
> > know which to apply and in what order. However, if a client knows that a
> > quoted section should be trimmed for replies, then the fallback trim
> > information is superfluous. It surely must know to remove the markup
> > with markup. I can be persuaded I'm wrong, mind, or simply that the
> > consensus is we should have this part of the protocol - but this is the
> > conversation we were having 18 months ago, and I never got a reply.
>
> Removing parts of the body under circumstances is exactly the only
> purpose of this ProtoXEP. If we were to remove that feature, the
> ProtoXEP would be entirely useless. I wouldn't know what a client should
> do with the information "Parts of the body are only for fallback
> purposes, but we don't tell you which part".
>
>
The examples you've given are:

1) Markup, where removing the quotation marks radically alters the message
(and the markup is intended not to be intrusive anyway), and

2) Replies, where including a quoted message has security problems all of
their own, as I note elsewhere, and

3) Breaking News, where arguably you'd want to send a different renderable
payload element entirely and if a bod

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Dave Cridland]

On Sat, 8 Jan 2022 at 23:04, Maxime Buquet  wrote:

> On 2022/01/08, Dave Cridland wrote:
> > On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer  wrote:
> >
> > > The XMPP Extensions Editor has received a proposal for a new XEP.
> > >
> > > Title: PubSub Namespaces
> > > Abstract:
> > > This extension defines a new PubSub node attribute to specify the type
> > > of payload.
> > >
> > >
> > Oh no it doesn't!
> >
> >
> > > URL: https://xmpp.org/extensions/inbox/pubsub-ns.html
> >
> >
> > What this extension appears to be trying to do, based on the (entirely
> > unreferenced and unmentioned on this list) Github discussion, is to
> define
> > the pubsub node *semantics*. That's a different thing to a namespace, and
> > certainly different from the "type of payload".
>
> Indeed, this is based off a PR[0] that I made a while back on 277, that
> got somewhat-rejected-but-not-really by one of its authors (stpeter). I
> got asked to go to standards but I thought that would get no interest as
> pubsub stuff usually does and we would redo the same discussion just the
> two of us. So I gave up, until this.
>
> > The canonical example given was microblogging with Atom, where you don't
> > just want random Atom payloads - the node might require Atom to work, but
> > it has additional semantics around it that can be expected. IOW, the need
> > is to know it's a microblog node, and not just an Atom node. So this
> isn't
> > really about payload formats, it's about node semantics, and that's a
> > radically different thing. And definitely not a "namespace".
>
> Yes! I think you captured very well what we wanted to say! We do want
> a way to express semantics.
>
> “Payload” may not be the word, then we'll change it. “Namespace” annoys
> people, we're also happy to change it. Suggestions welcome for a
> field(?) name, and also another XEP name!
>
> If that is the meaning that is generally given to (payload) “type” (a
> very generic word), then I understand stpeter's resentment to accept the
> PR.
>
> > The pubsub#type form field we already have (and rarely use) is stipulated
> > as being the "type of node data, usually specified by the namespace of
> the
> > payload (if any)". I think this covers what's needed here, whereas this
> > specification as written actually doesn't - and isn't any clearer than
> > pubsub#type.
>
> Suggestions on how to make the document clearer is also very welcome. As
> you can see edhelas and I are not particularly great at writing,
> especially in english.
>
>
Si j'ai écri en francais je ne peut pas etre tres claire aussi! Mais un
"namespace", ca veut dire une place du noms, comme les rues dans un cité -
c'est un protection contre avez plusiers rues avec le meme nom dans autre
cités.

(And also, apologies for not being able to type accents properly on this
machine - I should have just given up and used on online translator)

Translation to English: If I wrote in French I couldn't be very clear
either! But a "namespace" means a place of names, like the streets in a
city. It's a protection against multiple streets with the same name in
other cities.

So "type", while as you note very generic and horribly overloaded, is
closer to what you're aiming for I think.


> I do want to say though that some more words on pubsub#type would be
> great. I am definitely not the only one to be confused.
>
>
I think pubsub#type is sufficiently underspecified that using it for node
semantics seems fine to me. Usefully, it is *not* specified as being the
type of the payload, just noted as being "usually" the same as the payload
namespace - again, I think that fits your requirements. If I were on
Council, I'd want to understand very clearly why it does not before
accepting the XEP.

However, your specification here contains more functionality than just an
opaque-to-the-service label for the node semantics, so itself may not be
superfluous, but I think the additional field is - and the advantage of
reusing the existing field is that you can roll it out immediately.

Therefore, I would:

* Replace the new field with the existing one.
* Strike section 5.2 (pubsub node, no longer needed)
* Make 5.3 and 5.1 operate on the pubsub#type field.
* Also: Put in a PR against XEP-0060 (sorry Ralph/Peter) to indicate that
the pubsub#type means a label for the node semantics, and while it is often
the same as the payload namespace it can also be any other URN.


> > This specification is also unimplementable as written, due to the
> > requirement in 5.1.1 to have realtime access to the registry, but that's
> > really a non-issue - the specific

Re: [Standards] Proposed XMPP Extension: Message Replies

[Dave Cridland]

On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer  wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Message Replies
> Abstract:
> This document defines a way to indicate that a message is a reply to a
> previous message.
>
> URL: https://xmpp.org/extensions/inbox/replies.html


There's nothing wrong with this, excepting the problem that it introduces
yet another mechanism for referencing one message from another.

It would be nice if Council could figure out a single mechanism for this,
though I know this is a spectacularly thankless task.

If/when published as a XEP, it'd be nice to include that "fake" replies,
which mis-quote the original in order to cast the original author in a bad
light, have been seen in the wild on occasion. Personally, I would always
avoid including a quoted section, fallback or not - clients handling this
as a normal message aren't much more disadvantaged than they were before,
but are subject to this mis-quote attack.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Compatibility Fallbacks

[Dave Cridland]

On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer  wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Compatibility Fallbacks
> Abstract:
> This document defines a way to indicate that a specific part of the
> body only serves as fallback and which specification the fallback is
> for.
>
> URL: https://xmpp.org/extensions/inbox/compatibility-fallback.html
>
>
There seems to have been a flurry of XEPs recently which actively avoid
using any pre-existing designs and their XEPs, and I'm not sure why.

In this case, you've got a pre-existing fallback extension that you *could*
- and indeed *have* - proposed extending in exactly this way without any
problem, but for some reason you've decided to make an entirely new one
instead of continuing that discussion, which just feels a bit odd.

If you want to just edit that one please let me know, but otherwise, it
seems this is trying to do something in the same space but without using
the same XEP. This just feels like it's not really following the spirit of
our process at all, and it has to be considered an overlap since one of the
authors was actively proposing these changes to XEP-0428. What happens if I
update XEP-428 to support these use-cases?

Now, as it happens, my view is broadly unchanged after 18 months - I think
it gets very complicated when different extensions add bits of textual
markup they then need removing under some circumstances, and so I worry
that while this is a desirable UX, it's also a pretty nasty way of getting
there. The example given has parallel fallback "trims" for markup and
reply, and a client supporting both feature would have to know which to
apply and in what order. However, if a client knows that a quoted section
should be trimmed for replies, then the fallback trim information is
superfluous. It surely must know to remove the markup with markup. I can be
persuaded I'm wrong, mind, or simply that the consensus is we should have
this part of the protocol - but this is the conversation we were having 18
months ago, and I never got a reply.

Having a "for" attribute listing the feature that the fallback is for seems
fine to me, though I kind of think it might be superfluous. But as I said
18 months ago, it doesn't do any harm.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Dave Cridland]

On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer  wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: PubSub Namespaces
> Abstract:
> This extension defines a new PubSub node attribute to specify the type
> of payload.
>
>
Oh no it doesn't!


> URL: https://xmpp.org/extensions/inbox/pubsub-ns.html


What this extension appears to be trying to do, based on the (entirely
unreferenced and unmentioned on this list) Github discussion, is to define
the pubsub node *semantics*. That's a different thing to a namespace, and
certainly different from the "type of payload".

The canonical example given was microblogging with Atom, where you don't
just want random Atom payloads - the node might require Atom to work, but
it has additional semantics around it that can be expected. IOW, the need
is to know it's a microblog node, and not just an Atom node. So this isn't
really about payload formats, it's about node semantics, and that's a
radically different thing. And definitely not a "namespace".

The pubsub#type form field we already have (and rarely use) is stipulated
as being the "type of node data, usually specified by the namespace of the
payload (if any)". I think this covers what's needed here, whereas this
specification as written actually doesn't - and isn't any clearer than
pubsub#type.

This specification is also unimplementable as written, due to the
requirement in 5.1.1 to have realtime access to the registry, but that's
really a non-issue - the specification isn't clear enough to even know what
the intent is. Once we understand the intent, we can then compare it with
pubsub#type, and decide if it'd be better to make better use of that.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Dave Cridland]

On Wed, 15 Dec 2021 at 16:14, Florian Schmaus  wrote:

> On 15/12/2021 15.41, Dave Cridland wrote:
> > For the benefit of others wanting context, this is XEP-0060 section
> > 8.2.4. The existing SHOULD in this section is probably wrong, in as much
> > as it's either meaningless (to configure a node, obviously you send the
> > form) or else egregious (if you pull the form and the node seems to be
> > set right, why reconfigure it?).
>
> +1
>
> > On Wed, 15 Dec 2021 at 04:38, Travis Burtrum  > <mailto:tra...@burtrum.org>> wrote:
> >
> >   > The submitted configuration form MAY contain a subset of possible
> > configuration options. In that case, the service MUST only change the
> > submitted configuration options.
> >
> >
> > I don't think that text expresses what is actually intended. I think
> > what you want to say is that if a client doesn't provide all the
> > options, the server fills in the "missing" values from the configuration
> > form defaults, and not global defaults or something.
>
> No, I think this is not why the motivation and intention behind the
> proposed change is. "Filling unspecified values with the configuration
> form defaults" does not sound sensible, assuming that it means
> unspecified values could potentially be reset to their initial default
> values if they have been modified afterwards.


By "the configuration form defaults", I mean the defaults in the
configuration form from 8.2.2, which "SHOULD" be the current node
configuration values, and not any kind of global defaults.

So I think you're agreeing with me, aren't you?

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Dave Cridland]

On Wed, 15 Dec 2021 at 14:51, Kevin Smith  wrote:

> On 15 Dec 2021, at 14:41, Dave Cridland  wrote:
> > So, summary: I'd replace the opening text to 8.2.4 with:
> >
> > "If the owner wishes to change the configuration, they submit a
> completed configuration form. The server MUST treat any fields not included
> as though they are supplied with the default values from the configuration
> form (see 8.2.2)."
> >
> > Honestly I think the MUST there is a bit overkill, but I think the rest
> is OK.
>
> I think what we’re trying to say is (not a prose suggestion): “Accept a
> form with missing fields, and process missing fields as if the client isn’t
> trying to modify them”, is that right?
>
>
That seems reasonable, yes. Although "but":


> I think a small amount of vagueness here is of value, because one might
> imagine a form where setting one field means another must have a value - a
> helpful server might autogenerate the second value when the first is
> enabled, but a MUST synthesise the fields as if they were specified
> prevents that.
>

I see what you're saying, but that implies that a boolean field has three
values, true, false, and not present. And if there's a default for that
boolean field, then that becomes a rathole into which I do not wish to
descend. Maybe this is all OK, though.

That said, I think such things are better discussed in XEP-0004, and not
here.


>
> /K
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Dave Cridland]

For the benefit of others wanting context, this is XEP-0060 section 8.2.4.
The existing SHOULD in this section is probably wrong, in as much as it's
either meaningless (to configure a node, obviously you send the form) or
else egregious (if you pull the form and the node seems to be set right,
why reconfigure it?).

On Wed, 15 Dec 2021 at 04:38, Travis Burtrum  wrote:

>  > The submitted configuration form MAY contain a subset of possible
> configuration options. In that case, the service MUST only change the
> submitted configuration options.
>
>
I don't think that text expresses what is actually intended. I think what
you want to say is that if a client doesn't provide all the options, the
server fills in the "missing" values from the configuration form
defaults, and not global defaults or something.

This is, oddly, not specified in XEP-0004, even though I suspect we all
think it's obvious. Not including the fields at all, however, is - and
therefore this first MAY is not required (and is stipulating a conformance
outside its remit).

Once you have that, then you process the form as 8.2.5.

That makes no stipulations on the server as to how a form is processed, and
whether setting one value will change another, etc, so far.


> The concern here is that adding a MUST where one didn't exist previously
> could make existing compliant implementations suddenly non-compliant.  I
> believe it was said in MUC discussions that prosody follows this anyway,
> can anyone chime in about other implementations they know about ?
>
>
Modulo the MUST being not quite right, I don't think this does actually
change anything.


> It was also proposed that this MUST could be changed to a SHOULD, which
> would get around the protocol-breaking, but I'm not sure it adds a lot
> of value, since, if you can't be sure what the service will do, then you
> can never submit just a subset of config options and hope for the best.
>
>
MUST->SHOULD doesn't change much as regards older servers doing something
different, sorry. SHOULD is not "MAYBE", but "MUST (unless you really think
you know better, and even then, you don't)".


> Any input is appreciated.


But that's not what it said on the form! (Sorry)

So, summary: I'd replace the opening text to 8.2.4 with:

"If the owner wishes to change the configuration, they submit a completed
configuration form. The server MUST treat any fields not included as though
they are supplied with the default values from the configuration form (see
8.2.2)."

Honestly I think the MUST there is a bit overkill, but I think the rest is
OK.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Process Wonkery

[Dave Cridland]

All,

Kev Smith noted that we have been a bit weird about handling updates to
XEPs from authors during the Proposal phase (that is, Proposed state, from
Last Call through to completion of a vote to Stable).

1) When can authors update XEPs?

XEP-0001 is fairly unspecific about when updates to a XEP can be published
(ie, when PRs can be merged). More or less, it says they should be, but
from Stable onward only with Approving Body permission.

This means that during a Last Call updates can be made, changing the XEP
while people are reviewing it, which seems potentially awkward to me.

Once a XEP has gone before Council, we have developed a habit of discussing
PRs before a merge to see if they'll clear Council objections - this
streamlines the logistics but is clearly not what the process demands.

The timeline for a Proposed XEP currently looks like:

t=0 Last Call Starts
t=2w Last Call Ends, Advancement vote in Council

I'd be interested in views on whether we should require authors hold
updates to the XEP during Last Call, which would lead to:

t=0 Last Call Starts
t=2w Last Call Ends, Update Window
t=n Update Window Closes, Advancement vote in Council

Opinions welcome from Authors, Council people (past and present), and
others in the community.

2) Who are Authors anyway?

Authors have special rights with XEPs, especially Experimental - they can
more or less change them at whim, and although the intent here is that they
capture community consensus, there is no oversight. Additionally, there's a
bit of kudos involved in having one's name at the top of a XEP.

In practice, Council has added (and removed?) Authors, and we added an
"escape" to XEP-0001 in the form of Document Shepherds.

What I'd like to propose here is that XEP-0001 properly captures who
Authors are (initially, the original Submitters listed on the document, all
of whom must agree to the IPR policy), how new ones are added (by Council
approval, in consultation with the existing Authors if possible), and how
dormant/inactive Authors are removed (here be tygers; I'd like to propose
maybe marking them as emeritus or something less latinate).

I'm not bound to this approach, but I think done correctly, this can
obviate the need for Document Shepherds entirely, so this might -
astonishingly - simplify our process.

Again, opinions welcome!

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)

[Dave Cridland]

On Mon, 27 Sept 2021 at 11:04, Kim Alvefur  wrote:

> On Mon, Sep 27, 2021 at 10:37:37AM +0100, Dave Cridland wrote:
> >On Tue, 21 Sept 2021 at 16:46, Matthew Wild  wrote:
> >
> >> On Tue, 21 Sept 2021 at 15:24, Tedd Sterr 
> wrote:
> >>
> >>> 4. The original version (XEP-0242/0243) had two simple categories, Core
> >>> and Advanced, and that was all; later versions just continued with
> that.
> >>> The IM Suite, especially, is becoming quite top-heavy, so adding a
> middle
> >>> level would be good - but what to call it? Instead of names, how about
> >>> simply Level 1, Level 2, and Level 3 - right now that would map Core to
> >>> Level 1 and Advanced to Level 3, then a subset of Level 3 could make up
> >>> Level 2. Note that not all Suites require 3 levels (or even 2 in the
> case
> >>> of Web). [This also fits nicely with a compliance badge design idea I
> have.]
> >>>
> >>
> >> I agree with everything you said, but I'm especially in favour of fixing
> >> this one. Part of the goal of these things is to help summarize XMPP
> >> compliance of a piece of software to people who aren't intimate with
> XMPP.
> >> There is no planet on which describing a piece of software as "Core
> Core"
> >> makes sense.
> >>
> >> I'd be in favour of either switching to "Basic"/"Advanced" (I think
> >> "Basic" was frowned upon originally, which is why it wasn't used), or to
> >> numbered levels as you propose.
> >>
> >
> >We originally went for "Core" and "Advanced" with the intent that while
> >"Advanced" clearly sounds pretty damn cool, people would be happy to put a
> >marketing sticker type thing on their product with "Core" on it.
> >
> >This was explicitly up against "Basic", which we didn't think was the kind
> >of thing people would want to brag about.
> >
> >If we were to change things, I think I'd avoid "Basic" still, for the same
> >reasons.
>
> Perhaps "Foundation" is a cool enough word to replace the "Core"
> category, solving the "Core Core" thing by having "Core Foundation",
> "Advanced Foundation", "Core IM", "Advanced IM" etc?
>
>
That seems a simple fix, yes.


>
> --
> Kim "Zash" Alvefur
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)

[Dave Cridland]

On Tue, 21 Sept 2021 at 16:46, Matthew Wild  wrote:

> On Tue, 21 Sept 2021 at 15:24, Tedd Sterr  wrote:
>
>> 4. The original version (XEP-0242/0243) had two simple categories, Core
>> and Advanced, and that was all; later versions just continued with that.
>> The IM Suite, especially, is becoming quite top-heavy, so adding a middle
>> level would be good - but what to call it? Instead of names, how about
>> simply Level 1, Level 2, and Level 3 - right now that would map Core to
>> Level 1 and Advanced to Level 3, then a subset of Level 3 could make up
>> Level 2. Note that not all Suites require 3 levels (or even 2 in the case
>> of Web). [This also fits nicely with a compliance badge design idea I have.]
>>
>
> I agree with everything you said, but I'm especially in favour of fixing
> this one. Part of the goal of these things is to help summarize XMPP
> compliance of a piece of software to people who aren't intimate with XMPP.
> There is no planet on which describing a piece of software as "Core Core"
> makes sense.
>
> I'd be in favour of either switching to "Basic"/"Advanced" (I think
> "Basic" was frowned upon originally, which is why it wasn't used), or to
> numbered levels as you propose.
>

We originally went for "Core" and "Advanced" with the intent that while
"Advanced" clearly sounds pretty damn cool, people would be happy to put a
marketing sticker type thing on their product with "Core" on it.

This was explicitly up against "Basic", which we didn't think was the kind
of thing people would want to brag about.

If we were to change things, I think I'd avoid "Basic" still, for the same
reasons.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Stable is the new Draft

[Dave Cridland]

On Tue, 7 Sept 2021 at 16:44, Peter Saint-Andre  wrote:

> On 8/31/21 9:41 AM, Jonas Schäfer wrote:
>
> > The term "Draft" for our non-Final but also non-Experimental standards
> has
> > been adopted from our "mother" organization, the Internet Engineering
> Task
> > Force. The IETF has since abandoned that term.
>
> In fact, the IETF moved from a three-stage track to a two-stage track:
>
>
As many of us noted in the discussion leading up to that, the IETF moved
from a three-stage to a four-stage by increasingly formalizing the
Internet-Draft stage and raising the bar for Proposed Standard, and then
RFC 6410 executed a "Left Shift" to remove the (now largely redundant)
Draft stage.

The IETF still has a three stage track, it's just that the first stage is
Internet-Drafts, which amounts to our Experimental.

A lot of this shift, looking back on it, was driven by the lack of in-situ
updates to documents once they'd hit RFC status, which doesn't affect us.

It's also why I have resisted adding pre-XEP stages...

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[Dave Cridland]

On Tue, 7 Sept 2021 at 16:23, Georg Lukas  wrote:

> Hello everyone,
>
> given that XEP-0313 is up for recall in tomorrow's Council meeting, I'd
> like to sort my long list of issues into blocking and non-blocking.
> Fixing the blocking ones is a requirement for me to change my vote to
> something different than -1.
>
> Two blocking (non-Editorial) issues:
>
> * Georg Lukas  [2021-03-31 18:50]:
> > Time and again, specifications that use Message Forwarding have
> > fallen victim to impersonation attacks (there is a number of CVEs
> > around, like CVE-2017-5589, CVE-2019-16235, and CVE-2020-26547).
> >
> > The XEP urgently needs a respective section in the Security
> > Considerations, and ideally also a negative example like
> > https://xmpp.org/extensions/xep-0280.html#example-11
>
> I'd also copy a bunch of  elements from XEP-0280, in
> addition to the above text.
>
>
I can agree with this in principle, though the query id within MAM
queries dramatically lessens the scope for an attack here.


> > §6.1.1: the business rules for user archives are inadequate:
> >
> > MUC messages in user archive: I think that implementation practice has
> > clearly shown that storing MUC messages in the user archive is a Bad
> > Idea, and nobody is doing it anyway. Also the server is probably not in
> > a position to track a user's MUC activity and query all MUCs for whether
> > they implement some sort of message storage. This part should be
> > converted into "SHOULD NOT" or "MUST NOT".
>
> After some discussion it was suggested to change the scope of this from
> "should not store" to "should not return by default", which is also fine
> with me.
>
>
I'm unconvinced that trying to "fix" XEP-0045's various deficiencies is a
useful use of what energy we have.

For persistent groupchat protocols (MUC-SUB, Muclight, MIX) storing
groupchat messages in the personal archive is very useful indeed. This is
particularly the case for client implementations that operate in a "low
cache" mode, including (but not limited to) web clients.

For XEP-0045, it's complicated, sometimes entirely undesirable, and
sometimes very useful, and usually weird.

How would a "if you didn't specify, we won't either" model go with you?
That is, we add a flag in the query to specify whether or not
groupchat messages are included, but we explicitly do not include a default
value.


>
> One probably-non-blocking can-of-worms issue:
> > Furthermore, I'm not sure if messages received by a client from offline
> > history are supposed to contain the respective MAM-ID, so deduplicating
> > here might be very adventurous, as the same message might arrive from
> > offline history without a MAM ID and from MAM with a MAM ID, and the @id
> > attribute might not be unique.
>
> I'm not sure how implementations other than prosody handle this, but I'd
> love to see MAM servers to also inject MAM-IDs into offline messages,
> and have that explicitly written in 0313.
>
>
> Non-blocking issues:
> > Storage rules: those look very much like the original ones from the
> > initial specification, and I think we have learned much since then.
> >
> > Prosody will store "normal" messages with a body, or "chat"
> > messages that are not empty after stripped. By default, it will strip
> > chat states, but it will count origin-id or  as elements that are
> > worth of storing.
> >
> > Part of the problem is an implementation issue with storing the stripped
> > message and not the original  but the
> > general problem of clearly defined storage rules remains.
> >
> > This XEP needs something like the 0280 Recommended Rules
> >  but it
> > should be part of the XEP and not a later addition guarded by a separate
> > namespace. Maybe.
> >
> > Also it would be great to persist message errors for sent messages. But
> > this is a separate can of worms.
> >
> >
> > My comment from the last 0313 LC about letting the client know if the
> > MAM preferences are "undefined" yet, so that the client can ask the user
> > once, now applies to XEP-0441, so I hope I'll think of bringing it up in
> > the respective Last Call again.
> >
> >
> > The Business Rules section needs clear guidance to client
> > implementations that want to do "full sync", i.e. obtain all messages
> > received by the account since the client was last online, without too
> > many duplicates.
> >
> > This is a complex problem because offline messages might contain
> > everything that is also in MAM, or might have been drained by another
> > client in the meantime, so that offline messages will only give you the
> > end of chat history.
> >
> >
> > There is a separate standards@ thread regarding how to treat offline
> > history for MAM-enabled clients, but it only solves part of the above
> > problem.
> >
> >
> > There is no "atomic" switch between fetching messages from MAM and
> > receiving live traffic, so a client needs to either 

Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS

[Dave Cridland]

Old Thread Alert!!

On Thu, 13 Feb 2020 at 04:33, Travis Burtrum  wrote:

> In practice, it doesn't matter, the server administrator can't actually
> count on anyone accessing any of the SRV records in any specific order
> because any network could have any types of blocks/constraints on it.
> Therefore pending further comments here I'll submit a PR to propose
> changing:
>
> > Both 'xmpp-' and 'xmpps-' records SHOULD be treated as the same record
> with regard to connection order as specified by RFC 2782 [3], in that
> all priorities and weights are mixed. This enables the server operator
> to decide if they would rather clients connect with STARTTLS or direct
> TLS. However, clients MAY choose to prefer one type of connection over
> the other.
>
> to something like this instead:
>
> > Both 'xmpp-' and 'xmpps-' records MAY be treated as the same record
> with regard to connection order as specified by RFC 2782 [3], in that
> all priorities and weights are mixed. Otherwise clients MAY choose to
> prefer one type of connection over the other.
>

I propose:

Both 'xmpp' and 'xmpps' records MAY be treated as the same record with
regard to connection order as specified by RFC 2782 [3], in that all
priorities and weights are mixed. However, initiating entities MAY choose
to prefer Direct TLS, including by exhausting all 'xmpps' records prior to
attempting any 'xmpp' records.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Dave Cridland]

On Wed, 11 Aug 2021 at 22:49, Peter Saint-Andre  wrote:

> On 8/11/21 3:35 PM, Kim Alvefur wrote:
> > On Wed, Aug 11, 2021 at 02:25:56PM -0600, Peter Saint-Andre wrote:
> >> Too bad we didn't stick to our guns in 2003 and insist on two ports
> >> instead of one, but STARTTLS was the recommended approach back then...
> >
> > We were always at war with STARTTLS?
>
> We would have preferred to keep using port 5223 for TLS-only, but at
> that time (2003/2004) IETF/IESG policy was "don't use so many ports,
> STARTTLS makes it so that you only need one".


That's not the only argument, and was always the least interesting.

See: rfc2595 (ietf.org)


The single biggest change since then (where "then" is 1999) is that all the
other channel encryption technologies have vanished - nobody uses anything
but TLS, whereas back then, TLS was but one encryption possibility, and
Kerberos, for example, was often a better choice. TLS certificates were
annoyingly expensive, most people used self-signed or nothing at all, and
many of us believed Kerberos and similar, lacking the CAs, would take over.
Even the ports argument was slightly more relevant since the significance
of ports below 1024 was still considered important. In the intervening
years, CAs have become cheaper, and indeed free. TLS implementations have
become ubiquitous. Export laws have relaxed. A lot of us hoped for these
events but had no idea of a timeframe.

The change to universally use TLS as the channel encryption means that of
the four points in the RFC, two of them no longer apply, and the first
never applied to XMPP in the first place. XEP-0368 solves the remaining
quibbles over the remaining points, leaving the "twice as many ports" the
remaining argument - which was always weak on a SRV-based protocol anyway.

Hindsight, and existing arguments at the time, make it look in retrospect
like StartTLS was always a poor choice, but nearly 20 years ago the rough
consensus was indeed opposed. Back then I would have comfortably argued for
StartTLS - these days, I'd be arguing the other way. Times change, and we
adapt. Last time I chatted with Chris Newman, who wrote RFC 2595, he said
it was a bad mistake - but I disagree, it was the correct choice for the
time and circumstances. It isn't any longer, and we can, should, and do
encourage "Direct TLS".

We should be pushing XEP-0368 to Final and move it to Core in compliance.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [Council] XMPP Council Agenda 2021-07-21

[Dave Cridland]

Hi all,

I'm (almost certainly) unable to attend this meeting due to travel, but I
have reviewed the Pubsub Caching Hint XEP and have no objection to
publishing. I'm never sure if I can vote in advance or not, but +1 if I can.

Dave.

On Tue, 20 Jul 2021 at 16:00, Jonas Schäfer  wrote:

> Hi everyone,
>
> The next XMPP Council Meeting will take place on 2021-07-21 at 15:00Z in
> xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and add to
> the
> discussions.
>
> This agenda is composed from:
>
> - Editor notifications to standards@
> - xsf/xeps GitHub PRs marked as Needs Council
> - xsf/xeps GitLab MRs marked as Needs Council
> - Suggestions directly sent to me (see below)
>
> Agenda as follows:
>
> 1) Roll Call
>
> 2) Agenda Bashing
>
> * Feel free to pre-bash on-list or directly to me if you think something
> is
> missing.
>
> 3) Editor’s Update
>
> * Deferrals have been executed and … well have been sent all at once
> today.
> Sorry.
> * Proposed XMPP Extension: Pubsub Caching Hints
>
> 4) Items for voting
>
> 4a) Proposed XMPP Extension: Pubsub Caching Hints
> URL: https://xmpp.org/extensions/inbox/pubsub-caching-hints.html
> Abstract: This specification provides a way to get caching information
> from a
> Pubsub node
>
> 5) Pending Votes
>
> - Ge0rG on PR#1064: XEP-0227: New revision 1.1
>
> 6) Date of Next
>
> 7) AOB
>
> 8) Close
>
> End of Agenda.
>
> Note that I am aiming for 30 minutes, but meetings may be extended as
> necessary if all council members agree.
>
> Meetings are normally held every Wednesday at 15:00 UTC in the
> xmpp:coun...@muc.xmpp.org?join chatroom.
> Meetings are open, and anyone (XSF Member or not) may attend, though
> only XMPP
> Council members may vote. Relevant comments from the floor are
> welcomed.
>
> Using your web browser, you can join anonymously via
> https://xmpp.org/chat?council
>
> Note that conversations in the room are logged publicly at
> https://logs.xmpp.org/council/
>
> If you have suggestions for an agenda item, you can message me via XMPP
> or email at this address or at jo...@zombofant.net.
>
> I aim to publish the Agenda on the day before the Council meeting before
> 19:00Z.
>
> Stay safe, smart & healthy,
> Jonas
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] UPDATED: XEP-0458 (Community Code of Conduct)

[Dave Cridland]

Hi all,

There was an interesting discussion, alongside a reference to a free book
I'd not come across, in the XSF Chatroom starting here by "pep.":

XSF Discussion - 2021-06-28 (xmpp.org)


Of particular note here is how we deal with reports concerning members of
the Conduct Team and Board. As noted below, this could benefit from
clarification, but the key points for me are:


   - The Board is subject to the Code of Conduct as leading participants in
   the community, and as noted in Section 4.1, should be held to a
   particularly high standard.
   - Members of the Board can only be removed subject to our bylaws - an
   EGM and 50% vote. Calling an EGM takes 10% of the membership, which is
   currently 5.1 people. Sam's suggestion that the CoC have the ability to
   call an EGM is surprisingly reachable without changing the Bylaws - and the
   moment you involve the Board it should be easy.
   - XSF Members can only be removed with an EGM and 67% of the vote, which
   is somewhat harder to achieve.
   - In both cases, though, a lot of sanctions can still be applied if
   needed.


The book: cocguide.pdf (frameshiftconsulting.com)
, with intro
here: Code of Conduct book – Frame Shift Consulting


It should be noted that the book doesn't cover our exact situation, because
it assumes that a community always has the power of instant expulsion,
which we do not, as noted above.

The book raises a lot of points, and I'm glad to say many of them I'd come
across elsewhere and incorporated, but a few need to be noted and possibly
incorporated:


   - Every sanction or action gets a report. This report might be
   anonymized. I've not discussed the possibility of anonymizing the report,
   and I think that's going to be sensible in most (perhaps all) cases.
   - The report should always be made available at least to those who
   witnessed and/or were affected by the event. The book discusses a case
   where the target of sexist comments left the community, unaware that the
   person making them had been talked to, understood the effect of their
   comments, and had agreed to stop. I think I had this in an unpublished
   draft, but it's not there now as explicitly.
   - The book recommends that decisions made by the Conduct Team are
   unanimous, and the decision-making process isn't discussed outside of the
   team. I think collective responsibility for these decisions is important,
   but I think this may be one of the cases where we differ - the Conduct Team
   has the power to bounce things up to the Board. But we should probably
   stipulate that these discussions should remain confidential.
   - The book also stipulates that a CoC should include that anyone on the
   Board or Conduct Team recuse themselves from a Conduct discussion if
   they've had the report about them. I didn't stipulate this in the document,
   but only because it didn't occur to me that someone so accused wouldn't do
   so - it makes sense to include this.

The book also covers a lot more than this, and if you're considering being
on the Board or the Conduct Team, I'd highly recommend reading it.

Dave.

On Tue, 29 Jun 2021 at 18:27, Jonas Schäfer  wrote:

> Version 0.2.0 of XEP-0458 (Community Code of Conduct) has been
> released.
>
> Abstract:
> This document describes the XMPP Standard Foundation's Code of Conduct
>
> Changelog:
> Integrate various comments from various sources (dwd)
>
> URL: https://xmpp.org/extensions/xep-0458.html
>
> Note: The information in the XEP list at https://xmpp.org/extensions/
> is updated by a separate automated process and may be stale at the
> time this email is sent. The XEP documents linked herein are up-to-
> date.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Dave Cridland]

Updates:

On Fri, 11 Jun 2021 at 15:18, Dave Cridland  wrote:

>
>
> On Fri, 11 Jun 2021 at 13:19, Sam Whited  wrote:
>
>> > Note also that this is not intended to mean that any XMPP developer's
>> > behaviour will be scrutinised constantly - using, for example, racist
>> > language in a talk about your XMPP project would be problematic here,
>> > but using sexualised language in an unrelated setting is likely to be
>> > irrelevant to this Code of Conduct.
>>
>> While I think it's fine to call out that we won't actively police
>> behavior outside of XSF functions (which seems reasonable), I don't
>> think that makes them irrelevant to the CoC. If we do hear about and
>> verify some egregious behavior outside of the XSF we still may not want
>> that person representing the XSF.
>>
>> If nothing else I'd remove "is likely to be irrelevant to this CoC" and
>> put the decision in the hands of the working group.
>>
>>
> There is a lot of history around this particular issue in other
> organisations where the Code of Conduct has been applied unexpectedly to
> activities outside its obvious remit, and to (what some believe) are
> political ends. There are even cases where Codes of Conduct have been
> changed in order to make this the case retroactively. I'm not going to go
> into specifics of cases, but it's an area where I entirely understand that
> people are concerned.
>
> Now, yes, I think there are cases where behaviour in an unrelated setting
> is likely to be an issue for us, but what I don't want to imply is that
> just because using sexualised language in a Summit would be a serious
> problem, that means you can't have a hobby writing erotic fiction. My point
> is that behaviour is often contextual, and unless other people reasonably
> think it reflects on us, we should keep out.
>
> So if someone tweets something that - if said in our chatrooms, for
> example - would be against our Code of Conduct, I would be very reticent to
> suggest the Conduct Team should take any action beyond, at worst, reminding
> that person that their tweet would be seen as exclusionary in our
> community. To do otherwise risks becoming exclusionary ourselves, which is
> counter to the whole point. But, as noted, if they were a Board member,
> say, that changes the dynamic considerably.
>
> That said, a lot of behaviour that's against the Code of Conduct is
> actually flat-out illegal, ranging from hate speech to actual murder, and
> that's a different matter - though jurisdictional differences apply of
> course - I would assume that actual illegal behaviour does reflect on us.
>
> As always, textual suggestions here are welcome.
>
>

I've made the example about explicit language more explicit, as with the
example above; I think that now reads that the exemplar case (of erotic
fiction writing) is likely to be irrelevant, rather than reading like a
general comment.


> > please do call it out to that person at the time
>>
>> Should we define how this is done? I assume it means "gently mention
>> that you don't believe this lives up to the CoC in the venue the
>> behavior occurred in or in the chat" and not "post in every single
>> forum you can find about it and include the users home phone number
>> and email".
>>
>>
> The latter is itself against the CoC, so hopefully not. But yes, my intent
> here was that - if people feel able to do so - to calmly and gently express
> their concerns, privately or otherwise in response - and not escalate
> things into a vicious row.
>


Clarified this, and added some rationale.


>
>
>> > Who you report it to depends on who was involved in the incident.
>>
>> Can this be clarified? I would assume we'd always want to go to the
>> contact team unless it was a member of the contact team (then maybe the
>> board, or if they're the same, the rest of the board).
>>
>>
> Yes, Jonas also pointed out this wasn't obvious, though you're spot on in
> terms of the reasoning here.
>
> That said, I don't know if we want to ignore complaints (and I don't like
> that word) if they have been reported incorrectly. My concern in this is
> that I don't want a level of formality to dissuade people from reporting
> incidents because they're minor, or they feel more intimidated by the
> process than the incident itself.
>
>

Added some text to clarify these thoughts.


> > The Conduct Team will always hand its recommendation on Sanctions or
>> > other Actions to the Board. The Board will discuss and vote on these
>> > "in camera" (ie, not in public and not minuted).
>>
>> It

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Dave Cridland]

Updates:

On Fri, 11 Jun 2021 at 21:12, Dave Cridland  wrote:

>
>
> On Fri, 11 Jun 2021 at 17:10, Kevin Smith  wrote:
>
>> I’m just picking at replies here - as I said in the chatroom I think this
>> is a generally positive direction and want to thank the people involved.
>> (I did make two suggestions there)
>>
>>
> For the record (and my notes), I'll paraphrase these here:
>
> * "No person has any automatic right to join a chatroom, or write a XEP."
> in §3 ought to be something else, since writing a XEP doesn't need the
> XSF's permission as such.
>
> I'm not sure what this can be, but I accept that writing private
> extensions using the XEP format and publishing them independently might be
> considered "writing a XEP", and that's not within the XSF's purview.
>
>
I've reworded this slightly to use "the XEP series" as an example of "XSF
documents"


> * There's limitations on what the XSF (via the Board) can sanction a
> member for; in particular removal of any rights stipulated in the bylaws.
>
> The ramifications of this one are really interesting. Is ejecting a member
> from the members mailing list allowed? Probably, but that may mean they're
> not notified about a meeting, which is a bylaw right (or a
> responsibility of the XSF at least). Members can be removed, but with
> difficulty. I wouldn't want this to be made any easier, either.
>
> It may be as simple as noting that XSF Members, while held to a higher
> standard as regards the Code of Conduct, have certain immunities with
> regards to potential sanctions, and so members may have to take that into
> account when voting them in.
>
>

Done something like this.


> On 11 Jun 2021, at 15:18, Dave Cridland  wrote:
>>
>> > The Conduct Team will always hand its recommendation on Sanctions or
>>> > other Actions to the Board. The Board will discuss and vote on these
>>> > "in camera" (ie, not in public and not minuted).
>>>
>>> It seems like there's not much point having a conduct team if the board
>>> also has to relitigate their decisions. I'd just allow the board to
>>> delegate this authority fully (which presumably they could do anyways
>>> and this document doesn't curtail board power?)
>>>
>>>
>> I was in two minds about this, so thanks for raising it.
>>
>> I went for Board ratification of decisions mostly for the ease of
>> managing the authority, but also in part because then the Conduct Team
>> becomes an investigatory and deliberatory team instead of both judge and
>> jury.
>>
>> But you're right in that this might end up with Board relitigating the
>> decisions rather than just providing the final go-ahead decision and acting
>> as a blame deflector.
>>
>>
>> I think that if we were to find that the Board consistently disagrees
>> with decisions made by the Conduct Team, the Board would likely have to
>> look at who they’d put on the Conduct Team.
>>
>> If the Board has to approve the Conduct Team’s decision by really looking
>> at it and considering if it’s reasonable, is that not basically going
>> through the appeals procedure pre-emptively?
>>
>>
> I don't think so.
>
> Where there are valid appeals, this may mean the Conduct Team hasn't done
> its job right in finding the facts, or it may mean that despite their best
> efforts, there was information they were unaware of.
>
> But equally, I don't think most cases will result in any appeal at all,
> and frequently no actions.
>
> As a real example, two (or three, depending how you count) FOSDEMs ago I
> made a comment to Edwin, saying that I'd noticed - and I quote myself as
> best as I can recall after two and a half years - that there seemed to be
> "a much better proportion of girls in cybersecurity than elsewhere in our
> industry". Edwin rightly pointed out that referring to professional women
> as "girls" was more than a bit condescending, and I accepted that and
> nothing more was said. (As Sam suggests, he did so quietly and calmly, and
> didn't dox me on the mailing list, making it much less likely to put me on
> the defensive and escalate the situation).
>
> Under this Code of Conduct, Edwin (and perhaps also me) would drop an
> email to the Conduct Team, more for them to keep a finger on the pulse than
> anything else. Edwin would note that he called me out on it, and that I
> took the criticism in the way he'd intended. I'd expect the Conduct Team to
> do precisely nothing, maybe double check with me that I did now understand
> how my comment could be perceived - but possibl

Re: [Standards] [Council] XMPP Council Agenda 2021-06-23

[Dave Cridland]

Ahead of the meeting, in case my previous meeting overruns again:

On Tue, 22 Jun 2021, 16:14 Jonas Schäfer,  wrote:

> Hi everyone,
>
> The next XMPP Council Meeting will take place on 2021-06-23 at 15:00Z in
> xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and add to
> the
> discussions.
>
> This agenda is composed from:
>
> - Editor notifications to standards@
> - xsf/xeps GitHub PRs marked as Needs Council
> - xsf/xeps GitLab MRs marked as Needs Council
> - Suggestions directly sent to me (see below)
>
> Agenda as follows:
>
> 1) Roll Call
>
> 2) Agenda Bashing
>
> * Feel free to pre-bash on-list or directly to me if you think something
> is
> missing.
>
> 3) Editor’s Update
>
> * Compliance Suites 2022 accepted as XEP-0459
>
> 4) Items for voting
>
> None.
>
> 5) Pending Votes
>
> - Georg, Dave and Kim on https://github.com/xsf/xeps/pull/1064


I can't recall this being discussed on the standards list.

In any case, I'm concerned that the behaviour isn't entirely clear.

Firstly, it refers to "SCRAM", but I think it needs to refer to the SCRAM
family of mechanisms, to make it a little clearer.

Secondly, it suggests I should use the non-PLUS name, but I'd rather this
were explicit.


> - Dave on Deprecate and Obsolote Compliance Suites 2020
>

Yes, definitely deprecate, and absolutely obsolete.

Dave.

>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] UPDATED: XEP-0377 (Spam Reporting)

[Dave Cridland]

On Tue, 22 Jun 2021, 16:40 Sam Whited,  wrote:

> Thinking about this more I wonder if client authors would have a use for
> a disco#info node that returns the list of supported reporting reasons?
>
> Similarly, if we're going to do that, maybe clients don't need to know
> anything about reporting reasons and the server can return the ones it
> supports (along with a human readable name) and clients can just display
> that. This would get rid of the need for the registry and each server
> could just do whatever it wanted.
>
> Thoughts?
>

وقد تكون هناك مسائل تتعلق بالتدويل في هذا النهج.

;)

Dave.

>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Un-deferring XEP-0377: Spam Reporting

[Dave Cridland]

On Sat, 19 Jun 2021 at 12:35, Sam Whited  wrote:

> Can we undefer XEP-0377: Spam Reporting? I don't have any changes that
> need to be made to it, but it's also in use and not abandoned. It has
> one or two implementations but I don't know of any services actually
> using it so I don't think it's ready for advancement, but it definitely
> shouldn't be deferred.
>

Modulo Kim's comments, there's a simpler answer:

No.

If there are no changes to be made, then it's either ready for enhancement
or needs dropping.

Movement in and out of Deferred is automatic for a reason - it's to
eliminate XEPs which aren't progressing through Experimental.

We don't require implementations at the Experimental->Draft transition; we
require them at the Draft->Final one. Getting widespread implementations
before Draft is, in fact, a problem to the process - look at MAM, Carbons,
and so on, which end up stuck in Experimental.

Because moving things out of Deferred (or stopping them getting there) is
just a minor edit away, there's no need to ask, anyway. But really, if
there's some implementation but you think some more changes will be needed,
then force the issue with a Last Call.

(In this case, of course, sort through the changes Kim found discussed,
first!)

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Dave Cridland]

On Fri, 11 Jun 2021 at 22:02, Kevin Smith  wrote:

> I think there’s an implied statement that actions are somehow more
> significant than non-actions, but I think that’s probably not true. Actions
> are a statement that the behaviour was unacceptable, non-actions are a
> statement that the behaviour (or resolution to it in the ‘girls’ example)
> is acceptable, which is probably just as potentially harmful.  So I’d
> suggest whatever is done for one is done for the other, in terms of checks
> and balances.
>

Yes, that seems reasonable, with the note that as mentioned elsewhere, I am
rather hoping that in most cases, the Conduct Team is getting minor issues
that were sorted out on the spot, and thus has to do nothing. Where issues
weren't sorted out on the spot, a timely informal approach seems best if
possible. None of this should be taken to imply the conduct was acceptable.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Dave Cridland]

On Fri, 11 Jun 2021 at 17:10, Kevin Smith  wrote:

> I’m just picking at replies here - as I said in the chatroom I think this
> is a generally positive direction and want to thank the people involved.
> (I did make two suggestions there)
>
>
For the record (and my notes), I'll paraphrase these here:

* "No person has any automatic right to join a chatroom, or write a XEP."
in §3 ought to be something else, since writing a XEP doesn't need the
XSF's permission as such.

I'm not sure what this can be, but I accept that writing private extensions
using the XEP format and publishing them independently might be considered
"writing a XEP", and that's not within the XSF's purview.

* There's limitations on what the XSF (via the Board) can sanction a member
for; in particular removal of any rights stipulated in the bylaws.

The ramifications of this one are really interesting. Is ejecting a member
from the members mailing list allowed? Probably, but that may mean they're
not notified about a meeting, which is a bylaw right (or a
responsibility of the XSF at least). Members can be removed, but with
difficulty. I wouldn't want this to be made any easier, either.

It may be as simple as noting that XSF Members, while held to a higher
standard as regards the Code of Conduct, have certain immunities with
regards to potential sanctions, and so members may have to take that into
account when voting them in.


> On 11 Jun 2021, at 15:18, Dave Cridland  wrote:
>
> > The Conduct Team will always hand its recommendation on Sanctions or
>> > other Actions to the Board. The Board will discuss and vote on these
>> > "in camera" (ie, not in public and not minuted).
>>
>> It seems like there's not much point having a conduct team if the board
>> also has to relitigate their decisions. I'd just allow the board to
>> delegate this authority fully (which presumably they could do anyways
>> and this document doesn't curtail board power?)
>>
>>
> I was in two minds about this, so thanks for raising it.
>
> I went for Board ratification of decisions mostly for the ease of managing
> the authority, but also in part because then the Conduct Team becomes an
> investigatory and deliberatory team instead of both judge and jury.
>
> But you're right in that this might end up with Board relitigating the
> decisions rather than just providing the final go-ahead decision and acting
> as a blame deflector.
>
>
> I think that if we were to find that the Board consistently disagrees with
> decisions made by the Conduct Team, the Board would likely have to look at
> who they’d put on the Conduct Team.
>
> If the Board has to approve the Conduct Team’s decision by really looking
> at it and considering if it’s reasonable, is that not basically going
> through the appeals procedure pre-emptively?
>
>
I don't think so.

Where there are valid appeals, this may mean the Conduct Team hasn't done
its job right in finding the facts, or it may mean that despite their best
efforts, there was information they were unaware of.

But equally, I don't think most cases will result in any appeal at all, and
frequently no actions.

As a real example, two (or three, depending how you count) FOSDEMs ago I
made a comment to Edwin, saying that I'd noticed - and I quote myself as
best as I can recall after two and a half years - that there seemed to be
"a much better proportion of girls in cybersecurity than elsewhere in our
industry". Edwin rightly pointed out that referring to professional women
as "girls" was more than a bit condescending, and I accepted that and
nothing more was said. (As Sam suggests, he did so quietly and calmly, and
didn't dox me on the mailing list, making it much less likely to put me on
the defensive and escalate the situation).

Under this Code of Conduct, Edwin (and perhaps also me) would drop an email
to the Conduct Team, more for them to keep a finger on the pulse than
anything else. Edwin would note that he called me out on it, and that I
took the criticism in the way he'd intended. I'd expect the Conduct Team to
do precisely nothing, maybe double check with me that I did now understand
how my comment could be perceived - but possibly just take Edwin's word for
it that I do.

And for the record, I do - while referring to "the girls" and "the boys" to
include adults is perfectly common idiom here, I do realise that in a
professional context, and particularly with non-native speakers (and for
all I know, non-UK speakers), it might well come across condescending,
whatever my intent. By avoiding that idiom, I make our community a little
more welcoming (see §2.1) for very little effort on my part.

But back to the point - what am I going to appeal? Am I going to complain
that they should remove me from the stand at FOSDEM? Am I

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Dave Cridland]

On Fri, 11 Jun 2021 at 13:19, Sam Whited  wrote:

> > Note also that this is not intended to mean that any XMPP developer's
> > behaviour will be scrutinised constantly - using, for example, racist
> > language in a talk about your XMPP project would be problematic here,
> > but using sexualised language in an unrelated setting is likely to be
> > irrelevant to this Code of Conduct.
>
> While I think it's fine to call out that we won't actively police
> behavior outside of XSF functions (which seems reasonable), I don't
> think that makes them irrelevant to the CoC. If we do hear about and
> verify some egregious behavior outside of the XSF we still may not want
> that person representing the XSF.
>
> If nothing else I'd remove "is likely to be irrelevant to this CoC" and
> put the decision in the hands of the working group.
>
>
There is a lot of history around this particular issue in other
organisations where the Code of Conduct has been applied unexpectedly to
activities outside its obvious remit, and to (what some believe) are
political ends. There are even cases where Codes of Conduct have been
changed in order to make this the case retroactively. I'm not going to go
into specifics of cases, but it's an area where I entirely understand that
people are concerned.

Now, yes, I think there are cases where behaviour in an unrelated setting
is likely to be an issue for us, but what I don't want to imply is that
just because using sexualised language in a Summit would be a serious
problem, that means you can't have a hobby writing erotic fiction. My point
is that behaviour is often contextual, and unless other people reasonably
think it reflects on us, we should keep out.

So if someone tweets something that - if said in our chatrooms, for example
- would be against our Code of Conduct, I would be very reticent to suggest
the Conduct Team should take any action beyond, at worst, reminding that
person that their tweet would be seen as exclusionary in our community. To
do otherwise risks becoming exclusionary ourselves, which is counter to the
whole point. But, as noted, if they were a Board member, say, that changes
the dynamic considerably.

That said, a lot of behaviour that's against the Code of Conduct is
actually flat-out illegal, ranging from hate speech to actual murder, and
that's a different matter - though jurisdictional differences apply of
course - I would assume that actual illegal behaviour does reflect on us.

As always, textual suggestions here are welcome.


> > please do call it out to that person at the time
>
> Should we define how this is done? I assume it means "gently mention
> that you don't believe this lives up to the CoC in the venue the
> behavior occurred in or in the chat" and not "post in every single
> forum you can find about it and include the users home phone number
> and email".
>
>
The latter is itself against the CoC, so hopefully not. But yes, my intent
here was that - if people feel able to do so - to calmly and gently express
their concerns, privately or otherwise in response - and not escalate
things into a vicious row.


> > Who you report it to depends on who was involved in the incident.
>
> Can this be clarified? I would assume we'd always want to go to the
> contact team unless it was a member of the contact team (then maybe the
> board, or if they're the same, the rest of the board).
>
>
Yes, Jonas also pointed out this wasn't obvious, though you're spot on in
terms of the reasoning here.

That said, I don't know if we want to ignore complaints (and I don't like
that word) if they have been reported incorrectly. My concern in this is
that I don't want a level of formality to dissuade people from reporting
incidents because they're minor, or they feel more intimidated by the
process than the incident itself.


> > The Conduct Team will always hand its recommendation on Sanctions or
> > other Actions to the Board. The Board will discuss and vote on these
> > "in camera" (ie, not in public and not minuted).
>
> It seems like there's not much point having a conduct team if the board
> also has to relitigate their decisions. I'd just allow the board to
> delegate this authority fully (which presumably they could do anyways
> and this document doesn't curtail board power?)
>
>
I was in two minds about this, so thanks for raising it.

I went for Board ratification of decisions mostly for the ease of managing
the authority, but also in part because then the Conduct Team becomes an
investigatory and deliberatory team instead of both judge and jury.

But you're right in that this might end up with Board relitigating the
decisions rather than just providing the final go-ahead decision and acting
as a blame deflector.

I am very open to opinions here.


> > In high profile cases, the result will be announced publicly.
>
> I'd also just say "At the conduct teams discretion" instead of limiting
> it to "high profile" cases which seems vague and confusing.
>
>
Yes, there's a 

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Dave Cridland]

On Fri, 11 Jun 2021 at 09:41, Andrew Nenakhov <
andrew.nenak...@redsolution.com> wrote:

> Yet another irrelevant document masquerading as a protocol extension. I
> suggest stop using XEPs as an unsorted pile of various texts, or else
> you'll soon have cookie recipes there.
> If you want some place for a CoC, just put in on a website in 'community'
> section next to 'membership' page.
>

It's definitely not intending to masquerade as a protocol extension - there
are lots of policy documents in the XEP series, by intent, and this is a
"Procedural" XEP, not a Standards Track document. If we need to make that
clearer, let's do so.

Board did discuss whether to put it on the website only, or a XEP, or both.

Making it a XEP (even if we *also* put it onto the website in a more
traditional format) means we can discuss it as a community while it remains
Experimental, and we have clear procedures on how it gets updated,
approved, and made an Active policy.

As for its relevance, I rather hope it is and remains irrelevant - really
the only reason for it to be relevant is if we have a problem. Cookies seem
a much better outcome.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss

[Dave Cridland]

On Sat, 29 May 2021 at 16:10, Florian Schmaus  wrote:

> On 29/05/2021 13.08, Sam Whited wrote:
> > I'll change the name if using "Working Group" is what's concerning you,
> > fair enough, I can see how that makes this seem "official" somehow,
>
> I could imagine that using 'XSF' in the title is more concerning. Maybe
> simply call it "XEP Modernization Working Group"? Or, perhaps even
> better, "XEP Modernization Discussion Group"?
>
>
"Working Group" does have a particular meaning in the standards world, but
I was more concerned with the "XSF" prefix, yes. Of course, anything where
you've got a Capitalized And Organized Thing looks pretty official, but I'm
concerned with whether a participant could reasonably assume it is a formal
XSF activity.


> > but "it's concerning if anyone discusses XEPs outside the XSF" is not a
> > position that makes any sense and we absolutely don't need permission
> > form the board or council to go ahead as planned.
>
> Agreed, if our IPR prevents people from discussing how XEPs could be
> modernized, we should adjust the IPR, not the discussion venue.
>
>
It does not, and as noted, I didn't say the words in quotation marks.


> Dave's issue is probably that the outcome of such a discussion is
> potentially submitted and accepted into a XEP. And suppose later, a
> participant of that discussion claims part of the submission as his
> work, but is unwilling (or unable) to agree to XSF's IPR policy. In that
> case, the XEP could be viewed as tainted.
>
>
That, yes. I'd hope the problem - figuring out where the text came from and
whether the author agreed to the IPR policy - would be spotted earlier than
that, though, but that would just mean the contribution getting rejected,
meaning lots of people have wasted their time.


> But I don't see how this is different if the discussion took place on a
> XSF mailing list (or even at the XSF summit). I don't remember agreeing
> that every idea I express on an XSF mailing list is automatically
> covered by the IPR policy when subscribing to the list.
>
>
That is a whole other problem.

The IETF does require you to agree to their IPR policies at both in-person
meeting and when joining the mailing lists. We should probably do that as
well, but for clarity, we do have an IPR policy, it is well documented, and
we do explicitly require acknowledgement of it for XEP PRs.

Note that the ideas you discuss on the mailing list or at the summits are
not assigned, the assignment is on making them part of a XEP. The opacity I
referred to in my other note was that on a mailing list, or at a summit, we
have at least some record of where the text (or ideas) came from.


> Hence suggesting that such a venue requires XSF approval appears to me
> just inflicting unnecessary bureaucracy.
>
>
Well, we can flip it around - if our existing discussion venues are
insufficient, then that's clearly a bug, and how do we fix that?


> That said, I would welcome an XSF approved XEP Modernization Working
> Group (if there is enough interest).
>
> - Florian
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss

[Dave Cridland]

On Sat, 29 May 2021 at 12:09, Sam Whited  wrote:

> I'll change the name if using "Working Group" is what's concerning you,
> fair enough, I can see how that makes this seem "official" somehow, but
> "it's concerning if anyone discusses XEPs outside the XSF" is not a
> position that makes any sense and we absolutely don't need permission
> form the board or council to go ahead as planned.
>
>
For clarity, I didn't say the words you have placed in quotation marks, and
I don't think it's a fair representation of what I'm trying to say.

You do not need permission from anyone to discuss XEPs, no, and nor have I
suggested that. You need permission to copy them, quote them, and make
derivative works, but that's already granted to you (and anyone else). The
XSF, on the other hand, *does* need permission to take those derivative
works and copy them, including publishing them. I am concerned that we are
in a position where we cannot clearly get that permission and (due to our
IPR policy) the assignment. An external group which produces
recommendations as a group makes this decision-making process, and the IPR
ownership, opaque. Ordinarily, however XEPs may be discussed, we get
recommendations, requests, new text, etc from individuals, not from a
company, project, or "working group". You are proposing a different way of
working, and I just don't think it's that simple to characterise it as
"discussion".

And you absolutely do need permission from the XSF to call it an "XSF ...
Group". That would be representing this as being an official activity of
the XMPP Standards Foundation, which it is not, and therefore is a
misrepresentation I assume you didn't intend, but which compounds the
issues above.


> We're going to go ahead and discuss some XEPs. Naturally, the council
> doesn't have to take any recommendations we come up with.
>

I honestly don't think getting an OK from the XSF is exactly onerous,
especially when I've said I'll be aiming to get this. I would rather this
thing went ahead, as I said, and do so with the backing of the XSF both as
a community and as an organisation. You appear to be keen that it is not a
sanctioned activity. I'd like to understand why.


>
> —Sam
>
> On Sat, May 29, 2021, at 05:47, Dave Cridland wrote:
> >
> >
> > On Sat, 29 May 2021 at 04:10, Sam Whited  wrote:
> > > I don't understand how this would have anything to do with IPR, can
> > > you expand on that?
> > >
> >
> > Our IPR rules dictate that the XSF owns the IPR in our XEPs, and also
> > the contributions to them. This is straightforward and simple on a
> > mailing list, or a formal XSF activity like a summit.
> >
> > Outside of the XSF, things get murky, since if your group suggests
> > changes, we're going to need to get IPR assignments from all of them.
> >
> > And if you're saying this is, and I quote, an "XSF Modernization
> > Working Group", then things get murkier still, when it's not an XSF
> > activity at all.
> >
> > To be very clear here, I think the actual goal here, and indeed the
> > format, is great. With my Council hat on, I'm absolutely 100%
> > behind this.
> >
> > But with my XSF Member hat on, and my XSF Board hat on, I'm concerned
> > that this looks very like an XSF activity but isn't one, and I'm
> > concerned that there are potential risks here.
> >
> > So what I'd like to propose is that we put this on hold for a bit, and
> > get consensus from the membership and sanction from the Board to turn
> > this into a virtual XMPP Summit (or mini-summit, or something).
> > There's a delay involved because we'll need to get this sorted at the
> > next Board meeting on Thursday, although I'm fine with trying to get
> > agreement from the Board beforehand if the consensus from the
> > membership is clear enough, and I'm happy to help seek and frame that
> > consensus.
> >
> > How does that sound?
> >
> > Dave.
> >
> > > The idea is just to have a discussion about a bunch of XEPs and
> > > where they are in the process. This sort of thing normally happens
> > > on the mailing list, but getting a bunch of people in a room
> > > together (more or less) is also a good way to generate ideas and
> > > spark discussion.
> > >
> > > —Sam
> > >
> > > On Fri, May 28, 2021, at 14:54, Dave Cridland wrote:
> > > > Hey Sam,
> > > >
> > > > I'm a little worried about this, and how it squares with our IPR
> > > > policies.
> > > >
> > > > What do you feel can't be done within the XSF here?
> > > >
> > >

Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss

[Dave Cridland]

On Sat, 29 May 2021 at 04:10, Sam Whited  wrote:

> I don't understand how this would have anything to do with IPR, can you
> expand on that?
>
>
Our IPR rules dictate that the XSF owns the IPR in our XEPs, and also the
contributions to them. This is straightforward and simple on a mailing
list, or a formal XSF activity like a summit.

Outside of the XSF, things get murky, since if your group suggests changes,
we're going to need to get IPR assignments from all of them.

And if you're saying this is, and I quote, an "XSF Modernization Working
Group", then things get murkier still, when it's not an XSF activity at all.

To be very clear here, I think the actual goal here, and indeed the format,
is great. With my Council hat on, I'm absolutely 100% behind this.

But with my XSF Member hat on, and my XSF Board hat on, I'm concerned that
this looks very like an XSF activity but isn't one, and I'm concerned that
there are potential risks here.

So what I'd like to propose is that we put this on hold for a bit, and get
consensus from the membership and sanction from the Board to turn this into
a virtual XMPP Summit (or mini-summit, or something). There's a delay
involved because we'll need to get this sorted at the next Board meeting on
Thursday, although I'm fine with trying to get agreement from the Board
beforehand if the consensus from the membership is clear enough, and I'm
happy to help seek and frame that consensus.

How does that sound?

Dave.


> The idea is just to have a discussion about a bunch of XEPs and where
> they are in the process. This sort of thing normally happens on the
> mailing list, but getting a bunch of people in a room together (more or
> less) is also a good way to generate ideas and spark discussion.
>
> —Sam
>
> On Fri, May 28, 2021, at 14:54, Dave Cridland wrote:
> > Hey Sam,
> >
> > I'm a little worried about this, and how it squares with our IPR
> > policies.
> >
> > What do you feel can't be done within the XSF here?
> >
> > Dave.
> >
> > On Fri, 28 May 2021 at 15:31, Sam Whited  wrote:
> > > Hi all,
> > >
> > > I'm doing another experiment with the office hours. Sometime in the
> > > near future (currently 2021-06-08, but this may change) we're going
> > > to try having a "working" session where we go through a list of XEPs
> > > suggested by you all and write up recommendations for what should
> > > happen to these XEPs. If we don't finish within an hour we will
> > > spread it over multiple days.
> > >
> > > These recommendations won't be actual language or work on any
> > > specific XEP but should be process things like "issue LC",
> > > "deprecate", "obsolete", or "needs rewrite". We'll try to discuss
> > > each XEP and come to consensus on what the future of it looks like,
> > > write it up in a document along with our reasoning and any dissents
> > > if we can't come to consensus, and then present the document to the
> > > council (who of course may or may not choose to use it).
> > >
> > > If this sounds fun to anyone, please submit your ideas of XEPs that
> > > need discussion and work before 08 June to the following list:
> > >
> > >
> https://pad.disroot.org/p/XSF_Modernization_Working_Group_Recommendations
> > >
> > > Consider setting a name for yourself before you edit and please keep
> > > the list sorted. Thank you!
> > >
> > > —Sam
> > >
> > > --
> > > Sam Whited
> > > ___
> > > Standards mailing list Info:
> > > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe:
> Standards-
> > > unsubscr...@xmpp.org
> > > ___
> > ___
> > Standards mailing list Info:
> > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe:
> Standards-
> > unsubscr...@xmpp.org <mailto:Standards-unsubscribe%40xmpp.org>
> > ___
> >
>
>
> --
> Sam Whited
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss

[Dave Cridland]

Hey Sam,

I'm a little worried about this, and how it squares with our IPR policies.

What do you feel can't be done within the XSF here?

Dave.

On Fri, 28 May 2021 at 15:31, Sam Whited  wrote:

> Hi all,
>
> I'm doing another experiment with the office hours. Sometime in the
> near future (currently 2021-06-08, but this may change) we're going to
> try having a "working" session where we go through a list of XEPs
> suggested by you all and write up recommendations for what should
> happen to these XEPs. If we don't finish within an hour we will spread
> it over multiple days.
>
> These recommendations won't be actual language or work on any specific
> XEP but should be process things like "issue LC", "deprecate",
> "obsolete", or "needs rewrite". We'll try to discuss each XEP and come
> to consensus on what the future of it looks like, write it up in a
> document along with our reasoning and any dissents if we can't come to
> consensus, and then present the document to the council (who of course
> may or may not choose to use it).
>
> If this sounds fun to anyone, please submit your ideas of XEPs that need
> discussion and work before 08 June to the following list:
>
> https://pad.disroot.org/p/XSF_Modernization_Working_Group_Recommendations
>
> Consider setting a name for yourself before you edit and please keep the
> list sorted. Thank you!
>
> —Sam
>
> --
> Sam Whited
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Incorrect example in XEP-0198?

[Dave Cridland]

On Tue, 18 May 2021 at 20:38, Peter Saint-Andre  wrote:

> +1. Example 6 looks like a copy-paste error. Who wrote these specs?!?
>
>
Thankfully, for years we either couldn't, or at least normally didn't,
commit directly to the XEP repository ourselves, and left it to the Editor
to actually commit the changes. Nobody will ever know it was probably me.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Incorrect example in XEP-0198?

[Dave Cridland]

On Fri, 7 May 2021 at 14:34, Edwin Mons  wrote:

> On 07/05/2021 14:33, Kevin Smith wrote:
> > The text in question mentions wanting the connection terminated, which
> suggests stream error is right (which also seems logically sound to me).
> >
> > "If a server receives a second  element it SHOULD respond with
> a stream error, thus terminating the client connection.”
>
> This was indeed how I interpreted the text and am inclined to implement.
>

Yes, I think that you want to emit a stream error here.

Rationale:

A client sending a second  is unambiguously broken. There's three
possible outcomes here:

* The server responds , and the client accepts its second
 has failed but its first is still in effect.
* The server responds , and the client turns off stream management
entirely.
* The server responds with a stream error, and the client goes away.

The server cannot know which of the first two a client might do if it sends
, and moreover, even if we tried to specify that, the client is
unambiguously demonstrating it's broken anyway, so we still wouldn't know.

Therefore the only safe thing is to issue a stream error explaining the
situation and disconnect.

Any opinions on what stream error to send? I think we may be in to
 territory; nothing else seems to fit.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP rendering template for CVEs

[Dave Cridland]

On Wed, 28 Apr 2021 at 18:46, Georg Lukas  wrote:

> Therefore, and after some discussions on the xsf@ MUC, I have prepared a
> new XEP element `` that allows the XEP author to add a visually
> distinctive reference to previous failures of implementing that XEP
> properly. The goals of this new element are:
>
> - provide a clear warning to developers when reading a XEP
>
> - have a standardized syntax for CVEs that we can later use for
>   additional benefits
>
> While the `` element can be placed within any section of the XEP
> text, later on it becomes much easier to find CVE references, and to add
> them e.g. to the XEP header or to some place on our web site.
>
>
I think this is a good idea, and worth doing.

Documenting protocols is what we do, documenting security considerations is
an important part of that, and documenting CVEs seems an effective way to
do the latter.

The rest of this email is largely bike shedding.


> This will be rendered as shown here:
> https://op-co.de/tmp/xep-0280.html#security
>
> Questions for bike shedding:
>
> - Should there be a title and a distinct text block to provide a summary
>   (who should write that summary then?)
>
>
A title, yes. Generic text block is fine. All by convention, as a
subsection of the Security Considerations. In general, I'd say we want:


  ...
  
The following CVEs might be related to this specification. Following
the guidance within this specification is expected to ensure application
safety.

  


I think many developers will hit the CVEs straight from the contents, so
let's make it easy for them.


> - Do we need an anchor so that we can link to a CVE reference?
>
>
If we have a section for all CVEs consistently, I'm not sure we need an
anchor, but hey, we might as well.


> - Should there be more visual cues (a big red warning sign? blink?
>   marquee?)
>
>
No, if we're rolling them into this section, the visual cue as-is is
absolutely fine.


> - Will that work across all of our output formats? I only tested HTML.


Don't know. :-)

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0457 (Message Fancying)

[Dave Cridland]

Certainly meets all the use cases.

On Thu, 1 Apr 2021 at 06:20, Jonas Schäfer  wrote:

> Version 1.0.0 of XEP-0457 (Message Fancying) has been released.
>
> Abstract:
> This specification defines a Unicode-formatted fancy text syntax for
> use in instant messages.
>
> Changelog:
> Initial published version. (XEP Editor (jsc))
>
> URL: https://xmpp.org/extensions/xep-0457.html
>
> Note: The information in the XEP list at https://xmpp.org/extensions/
> is updated by a separate automated process and may be stale at the
> time this email is sent. The XEP documents linked herein are up-to-
> date.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Dave Cridland]

On Wed, 24 Mar 2021 at 16:02, Jonas Schäfer  wrote:

> This message constitutes notice of a Last Call for comments on
> XEP-0280.
>
> Title: Message Carbons
> Abstract:
> In order to keep all IM clients for a user engaged in a conversation,
> outbound messages are carbon-copied to all interested resources.
>
> URL: https://xmpp.org/extensions/xep-0280.html
>
> This Last Call begins today and shall end at the close of business on
> 2021-04-06.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
>
Given everyone implements it, I think it's evidently so.


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
>
It does.


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
Implemented.


> 4. Do you have any security concerns related to this specification?
>
>
None.


> 5. Is the specification accurate and clearly written?
>
>
Yes.


> Your feedback is appreciated!
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[Dave Cridland]

On Tue, 16 Mar 2021 at 20:21, Jonas Schäfer  wrote:

> This message constitutes notice of a Last Call for comments on
> XEP-0313.
>
> Title: Message Archive Management
> Abstract:
> This document defines a protocol to query and control an archive of
> messages stored on a server.
>
> URL: https://xmpp.org/extensions/xep-0313.html
>
> This Last Call begins today and shall end at the close of business on
> 2021-03-30.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
>
Well. I mean, as long as we don't mention XEP-0136, right?


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
>
Broadly, yes, though much of the requirements section is actually concerned
with features of XEP-0136 that are not considered requirements.

A possibly minor issue is that the archive identifiers present are assumed
to have an unbounded lifetime. In at least some servers stanza ids are
computed from internal database identifiers, or constrained to being UUIDs,
and so on - and these rules will not be the same between servers. Therefore
if you're switching implementation, copying the data from one to another,
the archive identifiers will necessarily change. No guidance is given in
these cases, but it might be useful to have a validity indicator. Or that
might be catering to a very niche case.

Either way, this is very much a non-blocking comment, but I thought perhaps
worth raising.


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
Yes, I have done.


> 4. Do you have any security concerns related to this specification?
>
>
None beyond the Security Considerations section.


> 5. Is the specification accurate and clearly written?
>
>
Seems so, aside from the typo in the last paragraph of §6.1.1.


> Your feedback is appreciated!
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP Wishlist: Encrypted Information Storage

[Dave Cridland]

Hiya,

On Sat, 13 Mar 2021 at 13:00, Paul Schaub  wrote:

> Hey everyone!
>
> It would be nice to have a way for clients to store end-to-end encrypted
> information on the server (imagine Private XML Storage or private PubSub
> nodes, but encrypted).
>
> As I heard that there are efforts of specifying ways to store signed
> data, I thought storage of encrypted data would come close enough to
> that to be discussed in the same breath.
>
>
I believe that's part of the same project, in fact. I just happened to be
more interested in signed data rather than encrypted, but it is, as you
say, all much the same principles.

The difficulty is always in the key distribution and authentication.


> Since both signed and encrypted data would require some sort of
> asymmetric client/account key pair, we could define that as well? It
> would open the door to many very interesting use cases, one of them
> being a single identity key for end-to-end encryption.
>
> What do you think?
> Paul
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Content Rating Labels

[Dave Cridland]

On Tue, 9 Mar 2021 at 21:18, Jonas Schäfer  wrote:

> On Dienstag, 9. März 2021 21:54:37 CET Florian Schmaus wrote:
> > On 3/9/21 9:11 PM, Jonas Schäfer (XSF Editor) wrote:
> > > The XMPP Extensions Editor has received a proposal for a new XEP.
> > >
> > > Title: Content Rating Labels
> > > Abstract:
> > > This specification provides a wire format in the form of a Service
> > > Discovery extension to allow services of various kinds to publish
> > > information about the kind of content they allow and/or endorse on
> > > their platform.
> > >
> > > URL: https://xmpp.org/extensions/inbox/content-ratings.html
> >
> > Thanks for the ProtoXEP submission.
> >
> > FWIW I find it strange that we put a ProtoXEP up for a vote that has not
> > filled all required sections. I know we have been lax about this
> > regarding the "XML Schema" section of experimental XEPs, and I think
> > this is perfectly fine and understandable. But I like to see every
> > ProtoXEP have a filled-out "Security Considerations" section, as this
> > demonstrates that the authors have, at least briefly, thought about
> > security. XEP-0001 § 12 has some good advice on that section.
>
> I agree with you on all points, in general.
>
>
I disagree with you on all points, in general. :-)

Yes, having these filled in is great, but the purpose of Experimental is to
work on the spec as much as the protocol itself, and I'm generally happy to
worry about mandatory sections later as long as I can understand the
general design and intent.


> I did specifically not fill in some sections (such as Security
> Considerations)
> because I wasn’t sure about them yet. I thought it would be worthwhile to
> develop this section under the XSF IPR because frankly I’m sure I cannot
> cover
> it completely.
>
>
And this is the thing - getting work under the IPR policy is at the very
least as important as getting security considerations etc filled in, and
these have a tension between them.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Syncing multi-device on XEP-0384: OMEMO

[Dave Cridland]

On Wed, 24 Feb 2021 at 22:34, Paul Schaub  wrote:

> I wouldn't be too concerned about periods where the root chain is not
> advanced. The crypto should still be strong enough to protect the message
> contents against offline attacks.
>
>
With MLS and Signal, my understanding is that advancing the ratchet makes
the cryptography simpler to prove, but there's no belief out there that
reusing the various keys might cause any problems. (This is more or less
the same as with ClientInitKey / PreKey reuse, I believe).

But I am not a cryptographer, I just play one on TV or something.


> Take for example OpenPGP with keys over curve25519. There *every* message
> is encrypted with the same key, yet it is not broken at all. I'd rather see
> break-in recovery as a nice bonus.
>
> Paul
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XML Element Ordering

[Dave Cridland]

On Mon, 22 Feb 2021 at 19:02, Florian Schmaus  wrote:

> On 2/18/21 12:16 AM, Dave Cridland wrote:
> > On Wed, 17 Feb 2021 at 19:22, Kevin Smith  > <mailto:kevin.sm...@isode.com>> wrote:
> >
> > On 17 Feb 2021, at 18:42, Florian Schmaus  > <mailto:f...@geekplace.eu>> wrote:
> >  >
> >  > On 2/16/21 4:14 PM, Jonas Schäfer wrote:
> >  >> I think this is the best place in the thread to reply with all
> > my thoughts.
> >  >> Vote change to -0 (or +1 with additional fixes) instead of -1
> > inline.
> >  >> On Sonntag, 14. Februar 2021 21:12:17 CET Florian Schmaus wrote:
> >  >>> Eventually, this is a situation where we cannot avoid that
> somebody
> >  >>> needs to change their code. We need to weigh in the effects of
> > the three
> >  >>> options:
> >  >>>A: clearly state that the order is not guaranteed
> >  >>>B: clearly state that the order is guaranteed
> >  >>>C: state that it should be sent in order, but recipients
> > must be able
> >  >>> to process in any order
> >  >> You are right. You were also right about what you said in reply
> > to my other
> >  >> email about OrderedMap existing in Python (even being the
> > default since some
> >  >> versions).
> >  >> However, here is a specific thing I do not want to see in XMPP:
> >  >> 
> >  >> 
> >  >> 
> >  >> 
> >  >> 
> >  >> with the relative order of foo vs. bar elements (mind, the order
> > of the bar
> >  >> elements to each other mattering is ok!) mattering.
> >  >
> >  >
> >  > I am with you here, with one additional constraint: I think it is
> > relevant where those elements are placed in the stanza.
> >  >
> >  > Element ordering is something that is often overlooked in XMPP
> > land. My stance is that the order of extension elements *which are
> > direct children of a stanza* should be irrelevant (and probably can
> > be unstable, e.g., because it was modified by a hop). However,
> > extension elements are free to impose order constraints of their
> > sub-elements. As it was previously pointed out, we already have such
> > elements.
> >  >
> >  > I wonder if we have consensus for
> >  >
> >  > """
> >  > The XML element order is irrelevant for elements that a direct
> > children of a stanza, and for all other elements unless explicitly
> > specified.
> >  > “""
> >
> > I think the reverse of part two is true, actually.
> >
> > I think the order of stanza children isn’t relevant (extensions can
> > be put in any order),
>
> At least we agree on something. :)
>
> > but within an extension the order should be
> > maintained unless otherwise explicitly stated.
> >
> > /K
>  > I think, broadly, that stanza contents can be re-serialized in any way
>  > that would not alter the canonicalized form, and not otherwise.
>  >
>  > So if you want to reorder attributes, go for it. Reorder elements, not
>  > so much.
>  >
>  > There are some obvious exceptions:
>  >
>  > Servers can insert new elements just fine and - in rare cases - remove
>  > them too, but that's really because those extensions are specifically
>  > designed for it, like  or security labelling.
>  >
>  > Otherwise, I don't really understand why anyone would think reordering
>  > things inside a stanza would be a good idea by default. The fact it
>  > doesn't usually cause a problem is neither an indicator that it cannot,
>  > nor an indicator that it should, and given XML has *always* had order as
>  > a significant thing, I don't understand why "we've never explicitly said
>  > you can't" should be taken as an indicator that therefore you can.
>  >
>  > So broadly, Florian, not consensus from me.
>
> I had my fancy XMPP client developer goggles on when I wrote this. It
> occurred to me that you and Kev are talking about maintaining the order
> when re-serializing XML. Which takes the perspective of a sever routing
> stanzas.
>
>
Ah! Yes, serialization order should remain stable in routing.


> But does it really matter in which order a client emits  and
> other first-level, i.e.

Re: [Standards] Council Minutes 2021-02-03

[Dave Cridland]

On Wed, 17 Feb 2021 at 21:07, Drew Varner  wrote:

> > But also XML C14N-based signing (such as XMLDSIG, which also happens in
> the real world) would be broken by element reordering.
>
> Doesn’t the server adding or overriding a “from” in RFC6120 8.1.2.1
> already break XMLDSIG canonicalization?
>
>
True, but we know what that override will be, so actually we can handle
that trivially either by including that in the signature or removing it
prior to C14N. I don't have a copy of STANAG 4778 to hand, for example, but
I think that's the approach there.


> > You not emitting in the correct order is an interop concern as we've
> seen, but is broadly something we can argue about. You not caring about
> ordering when forwarding seems like it's broken.
>
>
> I emit in the correct order, even if it’s not the original order. I
> maintain order where it matters. In the case of a data forms with
>  after the s, my implementation would forward the
> “correct” version with  first. Is that worse than sending the
> original?
>
>
OK, then I misunderstood - you always emit the right order? Then I think
that's technically wrong but not in any way I care about.


>  I feel like there’s something in the spec I am missing here.
>

XMPP doesn't say anything at all about reordering as far as I'm aware,
meaning we fall back to XML itself, which treats ordering of child elements
as significant.


>
> > On Feb 17, 2021, at 9:44 AM, Dave Cridland  wrote:
> >
> >
> >
> > On Wed, 17 Feb 2021 at 13:31,  wrote:
> >> But you reorder different elements with anything that has a spec when
> forwarding, is that right?
> >
> > Correct. We may change the order in which child elements appear for
> elements in our spec. Order among child elements of the same type (el name
> + namespace) is stable. Child elements of the same type will always appear
> contiguously.
> >
> >
> > OK, this sounds like a bug you may wish to fix.
> >
> > There's nothing in our specifications which says that ordering is
> insignificant, and general principles such as the end-to-end principle very
> strongly suggest you shouldn't be messing with any ordering which could -
> to the endpoints - be significant (even if you think it isn't).
> >
> > There are practical examples which could be covered by your code here,
> like security labelling in PubSub, which (in practise, and contrary to what
> XEP-0314 says on the issue) adds child elements to the  after the
> payload, and consumers assume the first element is always the payload.
> >
> > But also XML C14N-based signing (such as XMLDSIG, which also happens in
> the real world) would be broken by element reordering.
> >
> > You not caring about ordering on parsing is fine. You not emitting in
> the correct order is an interop concern as we've seen, but is broadly
> something we can argue about. You not caring about ordering when forwarding
> seems like it's broken.
> >
> > We don’t have a good way to annotate/enforce that certain child element
> types need to appear before other child element types.
> >
> > Attribute order, namespacing method (xmlns vs. prefix), and
> insignificant white space could also change.
> >
> > Aside from the latter - it's not clear to me how you tell if whitespace
> is truly insignificant - those are all OK, though unexpected.
> >
> >
> >> On Feb 17, 2021, at 7:27 AM, Dave Cridland  wrote:
> >>
> >> 
> >>
> >>
> >> On Tue, 16 Feb 2021 at 15:07, Drew Varner 
> wrote:
> >> > So, for example, XEP-0141 page elements could be reordered?
> >>
> >> No. The spec does not know about markup mini languages like XEP-0141,
> XEP-0071,  XEP-0393 and XEP-0394. Markup is validated at the client. Order
> is maintained because the spec just encodes unknown XML into a struct that
> maintains child order. It’s just a pain to bake those into the spec.
> >>
> >> > Fields in forms are assumed to be ordered as well,
> >>
> >> No. The order of XData fields in a form (“x”) is maintained. It’s a
> list of fields. The order that could change is whether  the list of
> instructions comes after the list of fields.
> >>
> >>
> https://github.com/processone/xmpp/blob/master/specs/xmpp_codec.spec#L2027-L2028
> >>
> >> But you reorder different elements with anything that has a spec when
> forwarding, is that right?
> >>
> >> Dave.
> >> ___
> >> Standards mailing list
> >> Info: https://mail.jabber.org/mailman/listinfo/standards
> >>

Re: [Standards] XML Element Ordering

[Dave Cridland]

I think, broadly, that stanza contents can be re-serialized in any way that
would not alter the canonicalized form, and not otherwise.

So if you want to reorder attributes, go for it. Reorder elements, not so
much.

There are some obvious exceptions:

Servers can insert new elements just fine and - in rare cases - remove them
too, but that's really because those extensions are specifically designed
for it, like  or security labelling.

Otherwise, I don't really understand why anyone would think reordering
things inside a stanza would be a good idea by default. The fact it doesn't
usually cause a problem is neither an indicator that it cannot, nor an
indicator that it should, and given XML has *always* had order as a
significant thing, I don't understand why "we've never explicitly said you
can't" should be taken as an indicator that therefore you can.

So broadly, Florian, not consensus from me.

On Wed, 17 Feb 2021 at 19:22, Kevin Smith  wrote:

> On 17 Feb 2021, at 18:42, Florian Schmaus  wrote:
> >
> > On 2/16/21 4:14 PM, Jonas Schäfer wrote:
> >> I think this is the best place in the thread to reply with all my
> thoughts.
> >> Vote change to -0 (or +1 with additional fixes) instead of -1 inline.
> >> On Sonntag, 14. Februar 2021 21:12:17 CET Florian Schmaus wrote:
> >>> Eventually, this is a situation where we cannot avoid that somebody
> >>> needs to change their code. We need to weigh in the effects of the
> three
> >>> options:
> >>>A: clearly state that the order is not guaranteed
> >>>B: clearly state that the order is guaranteed
> >>>C: state that it should be sent in order, but recipients must be
> able
> >>> to process in any order
> >> You are right. You were also right about what you said in reply to my
> other
> >> email about OrderedMap existing in Python (even being the default since
> some
> >> versions).
> >> However, here is a specific thing I do not want to see in XMPP:
> >> 
> >> 
> >> 
> >> 
> >> 
> >> with the relative order of foo vs. bar elements (mind, the order of the
> bar
> >> elements to each other mattering is ok!) mattering.
> >
> >
> > I am with you here, with one additional constraint: I think it is
> relevant where those elements are placed in the stanza.
> >
> > Element ordering is something that is often overlooked in XMPP land. My
> stance is that the order of extension elements *which are direct children
> of a stanza* should be irrelevant (and probably can be unstable, e.g.,
> because it was modified by a hop). However, extension elements are free to
> impose order constraints of their sub-elements. As it was previously
> pointed out, we already have such elements.
> >
> > I wonder if we have consensus for
> >
> > """
> > The XML element order is irrelevant for elements that a direct children
> of a stanza, and for all other elements unless explicitly specified.
> > “""
>
> I think the reverse of part two is true, actually.
>
> I think the order of stanza children isn’t relevant (extensions can be put
> in any order), but within an extension the order should be maintained
> unless otherwise explicitly stated.
>
> /K
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___