[Standards] Re: LAST CALL: XEP-0440 (SASL Channel-Binding Type Capability)

[Peter Saint-Andre]

On 5/8/24 8:12 AM, Sam Whited wrote:

maybe we should have a "how to use 
TLS with XMPP" informational spec of our own at some point?


Thijs Alkemade and I wrote RFC 7590 [1] for that purpose, but it was 
published in 2015 (via the UTA WG) and much has changed since then.


Peter

[1] https://www.rfc-editor.org/rfc/rfc7590.html

___
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))

[Peter Saint-Andre]

On 3/10/24 11:19 AM, Maxime Buquet wrote:

On 2024/03/10, 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?


Yes. The abstract and introduction seem to cover this well.


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


 From RFC 6120 § 8:

Three kinds of XML stanza are defined for the 'jabber:client' and
'jabber:server' namespaces: , , and .


Which seems somewhat restrictive. 


I'd say those restrictions were intentional at the time. Indeed, IIRC 
the original jabberd server just checked for 'm', 'p', or 'i' as the 
first character of the stanza!



It also doesn't take into account 0114
(Component) which I guess was written later? and 0114 itself does little
effort at including itself in this definition (it uses the word as if it
was already defined in this context).


XEP-0114 defines two namespaces, jabber:component:accept and 
jabber:component:connect, and treats top-level elements in those 
namespaces as stanzas (although the handshake element is really a nonza 
in those namespaces). So it's kind of a special exception. We weren't 
necessarily as careful about things in the early days (the Jabber 
component protocol predates our work at the IETF but we didn't document 
it right away, perhaps because so many components used the internal 
component protocol in jabberd).



I guess I would expect 0360 to (re?)define stanza, so it can define what
nonza isn't.


Maybe. I'm not sure it's worth the effort to nail this down precisely, 
but I suppose it can't hurt to try. ;-)


Peter

___
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))

[Peter Saint-Andre]

On 3/10/24 9:18 AM, 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?


I think this spec does a good job of clarifying the use of top-level 
elements other than message, iq, and presence.



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


Yes.


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


N/A


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


Maybe. See below.


5. Is the specification accurate and clearly written?


In Section 4, I suggest a tweak to the following sentence:

OLD
Nonzas are commonly used when it is not necessary to route the exchanged 
information behind the endpoints of an XMPP stream.


NEW
Nonzas are commonly used to exchange information between, but not 
beyond, the endpoints of an XMPP stream (e.g., between a client and its 
server).


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?
- How should the 'from' and especially 'to' attributes be handled in the 
light of RFC 6120 §4.7?

- Could the use of these attributes introduce security issues?
- Would it be better to say MUST NOT here?

Peter

___
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

[Peter Saint-Andre]

On 2/13/24 9:32 PM, Travis Burtrum wrote:

Apologies for the delay on this, but I finally have an update:

On 12/15/23 23:00, Travis Burtrum wrote:
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


I emailed stpeter directly and he responded promptly, thanks for that! 
He asked me to convey his message and he'd respond with a +1 so I'm 
doing so here:


On 2/7/24 21:05, Peter Saint-Andre wrote:
 > On 2/7/24 6:56 PM, Peter Saint-Andre wrote:
 >> Hi Travis!
 >>
 >> On 2/7/24 5:37 PM, Travis Burtrum wrote:
 >>> The council is blocking this pending an answer from '156 authors
 >>> (which I think, of the people still around, is only you) as to
 >>> whether you think this fits best as a new XEP or whether you'd be ok
 >>> with this being an update to and mostly replacing '156?
 >>
 >> I thought I had replied in xsf@ at one point, but it might have been
 >> lost in the noise.
 >>
 >> I'm A-OK with hostmeta-2 but I think it should be in a new XEP that
 >> obsoletes 156, not an overwrite of the existing 156.

So I have created a PR (https://github.com/xsf/xeps/pull/1323) with 
feedback and rationale, will respond shortly to the 2 responses to my 
previous message (again, thank you, and apologies for delay) and would 
like to ask council to re-consider this as a new XEP given the response 
from stpeter.


To be clear, I think this is enough of a diff that a different spec is 
the best way to go.


But I'm removed enough from what's happening here that I would not 
consider my opinion to be a blocker.


Peter

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

[Standards] Re: Feedback requested: SVCB for XMPP

[Peter Saint-Andre]

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?

Peter


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

[Standards] Re: Feedback requested: SVCB for XMPP

[Peter Saint-Andre]

On 2/13/24 11:30 PM, Stephen Paul Weber wrote:


2.
It mentions QUIC, and links to the XEP, but I don't see a way to 
indicate a QUIC connection?


Maybe because QUIC is still experimental, so probably not ready to be 
enshrined in an RFC, especially with WT coming.


QUIC was published as RFC 9000 almost 3 years ago. [1] HTTP/3 (which 
goes over QUIC) is perhaps 30% of traffic at major websites. I'm not 
sure I would call it truly experimental at this point.


Peter

[1] https://www.rfc-editor.org/rfc/rfc9000.html

[2] https://radar.cloudflare.com/

___
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)

[Peter Saint-Andre]

A work-in-progress pull request is here:

https://github.com/xsf/xeps/pull/1301

On 11/30/23 9:01 AM, Peter Saint-Andre wrote:

On 11/30/23 1:55 AM, Guus der Kinderen wrote:

Thanks Peter,

The improvements look good to me. I've left some minor feedback inline.


Great. One comment at the end.

 >      > 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?)

    I suggest that we add a separate section 5.5 to address this point.
    Here
    is proposed text:

    ###

    5.5 Situations Requiring Immediate Action

    The foregoing process assumes that there is time for reporting,
    consideration, and well-reasoned decision-making "in a quiet hour".
    However, two very different kinds of situation might require 
immediate

    action:

    1. Clearly offensive but somewhat minor behaviour, such as "drive-by"
    comments in online chatrooms.

    2. Behaviour that poses a clear and present threat of physical harm,
    such as a fist-fight at an in-person event.

    In both situations, venue moderators are empowered to take immediate
    action (in the first example, banning the sender from a chatroom; in
    the
    second example, breaking up a fight or calling building security).
    However, the actions of venue moderators are always subject to 
appeal.



Do you mean this as _examples_ of situations requiring immediate 
action, or is this intended as the full collection of any situation in 
which immediate action is covered under the XEP? Making it more 
explicit that these are examples may give us a bit of flexibility in 
applying the CoC in unforeseen situations.


Well, "such as" is equivalent to "for example", but I'll change it so 
that it's easier for non-native speakers to understand. :-)


Peter




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

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

[Peter Saint-Andre]

On 11/30/23 1:55 AM, Guus der Kinderen wrote:

Thanks Peter,

The improvements look good to me. I've left some minor feedback inline.


Great. One comment at the end.


 >      > 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?)

I suggest that we add a separate section 5.5 to address this point.
Here
is proposed text:

###

5.5 Situations Requiring Immediate Action

The foregoing process assumes that there is time for reporting,
consideration, and well-reasoned decision-making "in a quiet hour".
However, two very different kinds of situation might require immediate
action:

1. Clearly offensive but somewhat minor behaviour, such as "drive-by"
comments in online chatrooms.

2. Behaviour that poses a clear and present threat of physical harm,
such as a fist-fight at an in-person event.

In both situations, venue moderators are empowered to take immediate
action (in the first example, banning the sender from a chatroom; in
the
second example, breaking up a fight or calling building security).
However, the actions of venue moderators are always subject to appeal.


Do you mean this as _examples_ of situations requiring immediate action, 
or is this intended as the full collection of any situation in which 
immediate action is covered under the XEP? Making it more explicit that 
these are examples may give us a bit of flexibility in applying the CoC 
in unforeseen situations.


Well, "such as" is equivalent to "for example", but I'll change it so 
that it's easier for non-native speakers to understand. :-)


Peter


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

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

[Peter Saint-Andre]

Hi all,

Don't forget that the Last Call ends tomorrow (well, today for many of 
you). If you have comments to share, please send them soon.


As to the specifics of the feedback from Guus, see further comments 
inline...


On 11/2/23 12:23 PM, Dave Cridland wrote:



On Wed, 1 Nov 2023 at 16:59, Peter Saint-Andre <mailto:stpe...@stpeter.im>> 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.


OK, I will incorporate that text or something very much like it.


 > 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".


Here is proposed text for adding to Section 2.3:

"Additionally, because participants in XSF events and venues typically 
do not all share a common native language or culture, take extra care to 
ensure that your words can be understood clearly and without offense."



 > 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.


Guus, do you think we should add text to address that point? I suppose 
it might best belong in the Introduction.



 > 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?)


I suggest that we add a separate section 5.5 to address this point. Here 
is proposed text:


###

5.5 Situations Requiring Immediate Action

The foregoing process assumes that there is time for reporting, 
consideration, and well-reasoned decision-making "in a quiet hour". 
However, two very different kinds of situation might require immediate 
action:


1. Clearly offensive but somewhat minor behaviour, such as "drive-by" 
comments in online chatrooms.


2. Behaviour that poses a clear and present threat of physical harm, 
such as a fist-fight at an in-person event.


In both situations, venue moderators are empowered to take immediate 
action (in the first example, banning the sender from a chatroom; in the 
second example, breaking up a fight or calling building security). 
However, the actions of venue moderators are always subject to appeal.


###

If the text I have proposed above seems mostly acceptable, I will submit 
a pull request to modify XEP-0458.


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

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

[Peter Saint-Andre]

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".


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.

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.


Peter


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

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

[Peter Saint-Andre]

This message constitutes notice of a Last Call for comments on XEP-0458, 
a Procedural XEP that the XSF Board of Directors is considering for 
advancement to a status of Active.


Title: Community Code of Conduct

Abstract: This document describes the XMPP Standard Foundation's Code of 
Conduct.


URL: https://xmpp.org/extensions/xep-0458.html

This Last Call begins today and shall end at the close of business on
2023-11-30.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

1. Is this document needed to fill gaps in the XSF's policies and 
procedures?


2. Does the document address the goals stated in the introduction?

3. If code of conduct defined in this document applied to an interaction 
in which you participated (e.g., if you witnessed a violation of the 
code), would you follow the procedures defined in the document?


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


5. Is the document clearly written and does it avoid unnecessary or 
potentially damaging ambiguity?


Your feedback is appreciated!

Peter
(on behalf of the XSF Board of Directors)

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

[Standards] updated RFCs

[Peter Saint-Andre]

On 2/24/23 8:47 AM, Tedd Sterr wrote:

The original sender of a message stanza SHOULD give it id=UUID. 
Unfortunately, this wasn't a requirement in the RFCs, so now we have 
various hacks to try to deal with that because we can't just fix the 
problem while maintaining compatibility.


At some point we will want to published updated RFCs - probably once the 
SASL2 spec (etc.) is stable and widely deployed. We could then change 
RECOMMENDED to REQUIRED for the 'id' attribute and specify that it MUST 
be a UUID. In the meantime we could strongly suggest this to all 
implementors...


Peter

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

Re: [Standards] uppercase/lowercase of keywords

[Peter Saint-Andre]

Or: hey, it's great that we already did the work, let's merge it!

On 1/18/23 12:46 PM, Thilo Molitor wrote:

So the PR is lying around for ~5 years and nobody merged it even if it was
approved?
Why that?

-tmolitor


Am Mittwoch, 18. Januar 2023, 18:45:30 CET schrieb Florian Schmaus:

On 18/01/2023 17.26, 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?

I think we should add a reference to RFC 8174 to disambiguate these and
make only fully uppercase keywords normative.


https://github.com/xsf/xeps/pull/706

- Flow
___
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
___


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

Re: [Standards] uppercase/lowercase of keywords

[Peter Saint-Andre]

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.


Peter

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

[Standards] Fwd: [kitten] Common Authentication Technology Next Generation (kitten) WG Virtual Meeting: 2023-01-17

[Peter Saint-Andre]

Hi folks, just so you're aware the IETF's KITTEN working group will hold 
an interim virtual meeting tomorrow, and various SASL2-related topics 
are on the agenda. Feel free to join if you're interested!


/psa

 Forwarded Message 
Subject: Re: [kitten] Common Authentication Technology Next Generation 
(kitten) WG Virtual Meeting: 2023-01-17

Date: Mon, 16 Jan 2023 11:25:12 +
From: Alexey Melnikov 
To: kit...@ietf.org

Hi all,

On 03/01/2023 15:41, IESG Secretary wrote:


The Common Authentication Technology Next Generation (kitten) WG will hold
a virtual interim meeting on 2023-01-17 from 17:00 to 18:00 Europe/London 
(17:00 to 18:00 UTC).

Agenda:
Discuss possible extensions to SASL framework (aka SASL2), support for 2FA in 
SASL mechanisms, OPAQUE.

Information about remote participation:
https://meetings.conf.meetecho.com/interim/?short=6011e6f6-2503-40db-b99b-68f88c85a0e9


For people who are new to IETF, please make sure that you create a 
datatracker account on datatracker.ietf.org. (Account creation is free). 
You will use datatracker account credentials to log into Meetecho which 
will be used for the online meeting.


-

Updated agenda:

Tuesday 2023-01-17 (1 hour)
17:00-18:30 (UTC)

Administrivia (5 min; chair)

Proposed SASL2 features above SASL1 [RFC4422]:
  - Upgrade ("password change") tasks
  - 2FA
  - Fast resumption
  - Shared key derivation after successful authentication

SCRAM 2FA draft update: draft-ietf-kitten-scram-2fa

Fast reauthentication SASL mechanism: draft-schmaus-kitten-sasl-ht

OPAQUE SASL mechanism: draft-reitzenstein-kitten-opaque

-

I appreciate that this is probably a lot of topics for 1 hour. Depending 
on how discussions go, we can arrange a followup interim meeting to 
drill down into some these and related topics.


Looking forward to seeing you on Tuesday!

Best Regards,

Alexey

___
Kitten mailing list
kit...@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] standardization process

[Peter Saint-Andre]

[no hats]

On 1/6/23 6:49 AM, Florian Schmaus wrote:

I'd like the XSF to provide infrastructure to publish (and discuss) XEPs 
without Councils approval. Everyone can already publish stuff (cause 
"internet"). So the XSF not allowing this just scatters the documents 
around the web and does more harm.


Originally, the JEP Editor (c'est moi) accepted all reasonable proposals 
that passed a truly minimum bar for quality. At some point (I don't 
remember which year) the Council decided that it needed to vote on 
whether a spec could even become a JEP/XEP in the first place, which 
merely made the ProtoXEP stage a thing. Personally I don't think that 
was necessary, and I never was clear on what problem the Council was 
trying to solve by inserting itself that early.


I am not sure which protections you are referring to, given that there 
are implementations out there which not comply with "our" 
specifications. And this can simply not be prevented. Instead, we should 
make it more clear that incubating ProtoXEPs are 1. subject to change in 
any way without any backwards guarantees, and 2. implementations of such 
may not follow the spec (due to 1. and the fact that developers may 
decide to try something a little bit different).


I still want council to have a final word about an incubating ProtoXEP 
being adopted as official and council-approved XEP.


I am not sure even that is necessary. Take a look at, say, the first 50 
JEPs we worked on as a community. Progress happened very quickly, often 
with new versions every few days. As an example, version 0.1 of XEP-0045 
was published on 2002-09-09 and version 0.23 was published on 
2002-11-06, which was the version that the Council advanced to Draft on 
2002-11-21. It took us two months to develop and advance a large, 
foundational spec! Yet at some point we got bogged down in process and 
now things take way too long.


Yes, the Council should be involved with advancing specs to Draft, but 
IMHO it would be more productive for publication to be much more free 
and open to that point.


Peter


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

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

[Peter Saint-Andre]

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...

Peter

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

[Standards] Fwd: [Uta] BCP 195, RFC 9325 on Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

[Peter Saint-Andre]

FYI. The XMPP community should be aware of this document, which 
obsoletes RFC 7525 and thereby updates RFC 7590:


https://www.rfc-editor.org/rfc/rfc7590.txt

https://www.rfc-editor.org/rfc/rfc9325.txt

Peter


 Forwarded Message 
Subject: [Uta] BCP 195, RFC 9325 on Recommendations for Secure Use of 
Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

Date: Wed, 30 Nov 2022 06:06:09 -0800 (PST)
From: rfc-edi...@rfc-editor.org
To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
CC: rfc-edi...@rfc-editor.org, drafts-update-...@iana.org, u...@ietf.org

A new Request for Comments is now available in online RFC libraries.

BCP 195RFC 9325

Title:  Recommendations for Secure Use of 
  Transport Layer Security (TLS) and Datagram 
Transport Layer Security (DTLS) Author: Y. Sheffer,

P. Saint-Andre,
T. Fossati
Status: Best Current Practice
Stream: IETF
Date:   November 2022
Mailbox:yaronf.i...@gmail.com,
stpe...@stpeter.im,
thomas.foss...@arm.com
Pages:  34
Obsoletes:  RFC 7525
Updates:RFC 5288, RFC 6066
See Also:   BCP 195

I-D Tag:draft-ietf-uta-rfc7525bis-11.txt

URL:https://www.rfc-editor.org/info/rfc9325

DOI:10.17487/RFC9325

Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) are used to protect data exchanged over a wide range of
application protocols and can also form the basis for secure
transport protocols.  Over the years, the industry has witnessed
several serious attacks on TLS and DTLS, including attacks on the
most commonly used cipher suites and their modes of operation.  This
document provides the latest recommendations for ensuring the
security of deployed services that use TLS and DTLS. These
recommendations are applicable to the majority of use cases.

RFC 7525, an earlier version of the TLS recommendations, was
published when the industry was transitioning to TLS 1.2. Years
later, this transition is largely complete, and TLS 1.3 is widely
available. This document updates the guidance given the new
environment and obsoletes RFC 7525. In addition, this document
updates RFCs 5288 and 6066 in view of recent attacks.

This document is a product of the Using TLS in Applications Working 
Group of the IETF.



BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.


This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
Uta mailing list
u...@ietf.org
https://www.ietf.org/mailman/listinfo/uta
___
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

[Peter Saint-Andre]

On 10/17/22 5:27 PM, Thilo Molitor wrote:

Thanks for your feedback Dave!

Am Montag, 17. Oktober 2022, 15:36:56 CEST schrieb Dave Cridland:

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.

That's the reason why PLAIN is strongly discouraged.
Of course you'll need mechanisms providing mutual authentication like SCRAM or
the upcoming OPAQUE mechanism.
Yes, this downgrade protection does not work for all scenarios. It's not
perfect, but it's a step in the right direction and really simple to
implement. It's even fully backwards compatible.

Most public servers today support only SCRAM and PLAIN anyways. So encouraging
them to disable PLAIN and adding this downgrade protection would be enough to
secure all these servers against downgrade attacks.
  

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.

Yes, sure, the same protection has to be defined for OPAQUE, too.
That shouldn't be a problem: if I read the early draft of OPAQUE correctly, it
provides support for optional attributes like SCRAM does (it even tries to use
the same characters for mandatory attributes like SCRAM).


In any case, if the client has a local policy not to use PLAIN (or other 
mechanisms that it considers to be too weak), then it simply wouldn't 
use those in case of a downgrade attack. Similar policies are in place 
already for things like old versions of TLS, see here:


https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-11#section-3.2


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.

Sure, I even stated in the XEP that I plan to eventually make this an I-D.
That said, I wanted to gain some implementation and operational experience
before going the next step forward.
Having this as an experimental XEP implemented in, for example, prosody or
ejabberd and Monal/Conversations would allow us to gain exactly this
experience.

This XEP was never meant to advance to stable, but to remain experimental and
be superseded by a proper RFC some day.


IMHO it is fine to advance a XEP to Draft and then obsolete it when the 
proper RFC is published. We have done this before, e.g. XEP-0029.


Peter

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

Re: [Standards] Hash Algorithm Names in Bits of Binary

[Peter Saint-Andre]

Thanks, Sam. This seems like a reasonable approach.

On 7/25/22 10:45 AM, Sam Whited wrote:

Hi all,

There was a brief discussion on  jdev@ today about how Bits of Binary is
not consistent with newer XEPs in terms of the hash algorithm names it
uses. Currently it only mentions using the name "sha1" to refer to the
SHA-1 hash algorithm. However, other XEPs that follow the guidelines
from "XEP-0300: Use of Cryptographic Hash Functions in XMPP"
[1] say to use the names from the "IANA Hash Function Textual Names
Registry" [2] which uses the name "sha-1".

Since BoB does not actually mention what other algorithms are supported
or what they should be called, I have submitted the following text to
clarify that names should be taken from the IANA registry and XEP-0300
except if the algorithm is SHA-1 which must remain "sha1" for historical
reasons. I believe this is simpler than creating a new namespace or
entirely new mechanism for sending binary data around and is backwards
compatible with all existing implementations, but if you have arguments
to the contrary I'd love to hear them. The PR is here if you'd like to
peruse the text or suggest changes:

https://github.com/xsf/xeps/pull/1193

—Sam

[1]: https://xmpp.org/extensions/xep-0300.html
[2]: 
https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml



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

Re: [Standards] What to do about multi-item data forms?

[Peter Saint-Andre]

On 7/19/22 6:46 AM, Sam Whited wrote:

Thinking about this more, I'm not sure that it makes sense to clarify
this in a new XEP. Did we ever come up with something along the lines
of IETF erratas or editors notes that we could put at the beginning of
the document?


We don't have errata, we have "living standards". An Editor's Note might 
be appropriate, or we just update XEP-0004 through the usual process 
even though it's Final.



After re-reading this thread it's still unclear to me what the original
intent was and it doesn't seem like anyone else besides Peter and I
have opinions, so I'm tempted to write something that says "multi-item
forms are a separate thing and can't have
fields/instruction/title/etc." as that seems the simplest solution, but
I'm not sure where we'd put this text.


I'd put it in Section 3.4. :-)

Peter

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

Re: [Standards] What to do about multi-item data forms?

[Peter Saint-Andre]

On 7/17/22 3:03 PM, Sam Whited wrote:



On Sun, Jul 17, 2022, at 14:04, Peter Saint-Andre wrote:

Maybe. The text in effect says "here are some additional elements not
mentioned so far in the spec", not "these new elements are included in
addition to other elements within the XML".


This sounds like the original intent was for this to be a separate data
type 


Could you clarify what you mean by a separate data type? Are you 
suggesting that, say,  might have been cleaner 
than overloading  (if that's what we did)?



that does not include fields, instructions, or title elements.


I believe so. But we cooked this up 20+ years ago and my memory might 
faulty. :-)



(though there are no examples where a form contains reported/items
and any other form element).


The lack of examples is indeed not good.


But this sounds like it should contain those other elements, so it's
still not clear to me what the original intent was :)


I meant the lack of examples in general, not the lack of examples of 
reported + items + field/instructions/title.



What use cases do folks have in mind nowadays for multi-item data
forms of type 'result'?


I think singpolymas example was a good one: the jmp.chat folks would
like to display some form information that includes your account
balance, and below that a table (aka multi-item form) of recent
transactions.


This sounds like "reported" without a prior request. I suppose that's 
OK, but it seems slightly unexpected.



Do these libraries allow multiple items in forms of type 'cancel',
'form', and 'submit', or only 'result'?


As far as I can tell aioxmpp errors if you try to create or parse a form
with multiple items that is of a type other than result [1], but nbxmpp and 
Smack
will let you parse or build a form of any type with items [2, 3].


Interesting. I do think this was intended for use only with 'result' forms.

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

Re: [Standards] What to do about multi-item data forms?

[Peter Saint-Andre]

XEP-0004 co-author here...

On 7/17/22 9:05 AM, Sam Whited wrote:

Several people [1, 2] have recently asked about how to use multi-item
data forms. XEP-0004 when introducing multi-item forms says:


Therefore, a data form of type "result" MAY contain two child elements
not described in the basic syntax above


Then proceeds to give examples using the reported/items. However, the
text makes it sound like these XML elements might be in addition to
existing elements such as title/introduction and various fields 


Maybe. The text in effect says "here are some additional elements not 
mentioned so far in the spec", not "these new elements are included in 
addition to other elements within the XML".



(though
there are no examples where a form contains reported/items and any other
form element). 


The lack of examples is indeed not good.


This would lead to a lot of edge cases (what if you have
a field in between multiple items?) that also aren't described by the
XEP, which makes me wonder what the original intent is and how we should
interpret it going forward.


If I recall correctly, the use case we had in mind was search: send a 
keyword to the form processor and get back a set of results. The 
 element tells you what you searched for, and each  
element defines one of the hits. Of course, later on (in XEP-0055) we 
created a special namespace for search, as well as a method (XEP-0059) 
for managing large results sets.


What use cases do folks have in mind nowadays for multi-item data forms 
of type 'result'?



Looking over a few existing libraries, they appear to interpret this
differently. 


Do these libraries allow multiple items in forms of type 'cancel', 
'form', and 'submit', or only 'result'?



For example:

- aioxmpp and nbxmpp do not allow mixed fields/items, but do allow multi-
   item forms with instructions, although this appears to be incorrect no
   matter how you interpret the spec, but makes a sort of logical sense
- smack allows mixing fields and items but if parsing a form with them
   it loses ordering between fields and items while maintaining ordering
   between fields and items individually, eg. in the form "field1, item1,
   field2, item2" you could ask Smack for fields and it would give you
   "field1, field2" or items and it would give you "item1, item2"

Since the spec is not clear and users of these libraries could easily
write forms that would be compatible with some clients and incompatible
with others (without the user realizing they've done this), I think we
should find a way to clear up the inconsistency, possibly with a new
informational XEP. A few options have been discussed:

1. Disallow mixing fields/items (possibly allowing instructions on both)

2. Allow mixing fields/items and treat them as separate ordered entities
that should be displayed separately
3. Treat individual items as fields to be displayed in a column and
allow them to be ordered together (ie. item is effectively just a
field with multiple values that are themselves fields and it happens
to have a slightly different wire representation)

I'd love to hear what other libraries do or any pros/cons of the above.
In [2] it was suggested that the jmp.chat folks would like to display a
form containing your account balance, followed by a table of recent
transactions. This could be allowed by option 1 only if we also specify
that multiple forms should be displayed one after the other; I am unsure
if this conflicts with the use of multiple-forms in existing specs.
Option 2 and 3 it would just work.

Your thoughts would be appreciated.


Although I'm not sure if (1) is ideal (it depends on what use cases 
people have), but I think it is most consistent with the original intent 
for forms of type 'result' that include a  element.


HTH,

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

Re: [Standards] XMPP Council Agenda 2022-06-15

[Peter Saint-Andre]

On 6/28/22 4:05 AM, Georg Lukas wrote:

* Daniel Gultsch  [2022-06-14 22:07]:

a) Proposed XMPP Extension: WebSocket S2S
(https://xmpp.org/extensions/inbox/websocket-s2s.html)


+1 though I wonder if it makes sense to release a XEP for s2s where we
have an RFC for c2s. Maybe harmonizing both under the same organization
would be more beneficial in the mid- to long term?


That's probably a good idea. Ideally I would suggest that someone author 
an RFC that obsoletes RFC 7395 and includes the s2s bits, but that would 
require someone to navigate IETF process. I'm happy to help as needed.



b) Proposed XMPP Extension: XMPP over QUIC
(https://xmpp.org/extensions/inbox/xmpp-over-quic.html)


+1


One could argue that a transport definition like this belongs at the 
IETF, too. But I suppose it could be included in rfc6120bis (if that 
ever happens).



The wording "Client or server MUST ..." is ambiguous. We should adopt
the "initiating entity" and "receiving entity" wording from XMPP-Core
instead.


+1


I'd like to hear a proper rationale for udp/443 and not the IANA
assigned port (although the assignment is only for tcp/5222), and we
should probably request udp/5222 for XMPP-over-QUIC.


It should be fairly straightforward to request udp/5222. Here again I 
can help with the IANA communications if needed.



The ALPN entries are already assigned, so that part looks good.


Agreed.

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

Re: [Standards] XEP-0072 si-pub namespace inconsistency

[Peter Saint-Andre]

On 3/10/22 2:46 AM, Georg Lukas wrote:

Hi,

I've been looking into our legacy namespaces recently (the ones starting
with `http://jabber.org/`), with a goal to implement HTTP Redirects to
the respective XEPs (first map at https://op-co.de/tmp/namespacemap.txt)

I identified a bunch of inconsistencies in examples, for some of which
I've already opened PRs. 


Thanks for doing this.


One of the things that I'm not sure about is
XEP-0072, where two different SI-Pub namespaces are used:

Within a message element, only mentioned in the example:

https://xmpp.org/extensions/xep-0072.html#example-8




And within an IQ element, mentioned in normative text and in an example:

https://xmpp.org/extensions/xep-0072.html#example-9



I assume that having two different namespaces was not a deliberate
design decision, 


IIRC, sipub is correct and si-pub is incorrect. What does the schema say?


but my question is:

Do these examples reflect the actual in-the-wild use?


Is SOAP over XMPP even used in the wild anymore? Weren't we talking 
about deprecating or obsoleting XEP-0072?



Can we harmonize them / fix the examples?

At least in https://xmpp.org/extensions/xep-0137.html#example-1 and
https://xmpp.org/extensions/xep-0332.html#example-13 it looks
like  is actually a
thing.


More specs to be deprecated? ;-)

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

Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

[Peter Saint-Andre]

Co-author of XEP-0156 here.

Thanks for raising this issue.

I would go even farther and note that DNS TXT records were never a great 
idea for this functionality (they're actively discouraged in the DNS 
community for application-level uses like this).


On 2/9/22 4:29 PM, Travis Burtrum wrote:

Hi all,

The long story short (is outside of DNSSEC) it's impossible to use 
_xmppconnect TXT records to securely connect to BOSH or WebSockets. 
Every client I've been able to find that supported this is vulnerable to 
trivial MITM (Man-In-The-Middle) via DNS spoofing.  If you have a client 
that uses it, switch to grabbing host-meta via HTTPS per [RFC-7395] 
immediately, maybe grab a CVE if you wish.


Sonny commented on your PR that "RFC 7395 doesn't define bosh lookups"; 
this might be true but that raises the issue of whether we should still 
recommend BOSH, since it was a pre-websockets workaround for long polling.


I propose we litter [XEP-0156] with warnings explaining why it's 
insecure and should never be done, and obsolete it, instead referring 
people to the single host-meta method that [RFC-7395] defines, which 
provides secure delegation when grabbed over HTTPS.


In general, +1 to what you propose.

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

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Peter Saint-Andre]

On 1/8/22 4:02 PM, 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.


Yes, that's what I was trying to say in the GitHub thread.

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

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Peter Saint-Andre]

On 1/5/22 5:41 AM, Ralph Meijer wrote:

On 04/01/2022 18.55, Jonas Schäfer (XSF Editor) 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.

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


I am particularly interested in answers this question in section 9:

 > People seem not to want to use |pubsub#type| for this but why?!

Creating a new node config field with the same semantics doesn't seem 
like the right approach. 


+1

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

Re: [Standards] Proposed XEP-0060 Changes

[Peter Saint-Andre]

On 12/21/21 2:54 AM, Florian Schmaus wrote:

On 16/12/2021 14.32, Melvin Keskin wrote:
Hi Melvin,


1. Should I add that as § 3.5 to XEP-0004 (after
https://xmpp.org/extensions/xep-0004.html#protocol-results)?
2. Should I change
https://github.com/xsf/xeps/pull/1126/files#diff-0ede34e71ae8ea7199b84fe09913b235f648e79c1549a055b3ddd90fee3211f8R3734 


  to that?


I fear it is up to you to read the sentiment on the list to determine if 
sufficient consensus has been reached to put in the effort of 
resubmitting an updated version.


In general the answer to this questions is 'yes', because it can not 
hurt to start another iteration. While this is burdensome, and sometimes 
maybe even unrewarding, for the one doing the work, it eventually helps 
to increase the quality.


Furthermore, I've made good experience with negatively phrased 
questions, as in "Does anyone oppose to those changes?", and the 
interpret silence as agreement or disinterest.


https://datatracker.ietf.org/doc/html/rfc7282 has some helpful 
suggestions on reaching consensus. :-)


Peter

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

Re: [Standards] XEP-0353: Rework whole spec, namespace bump

[Peter Saint-Andre]

On 12/8/21 1:42 AM, Philipp Hancke wrote:

Am 07.12.21 um 23:31 schrieb Lance Stout:
+1 on merging. There’s been a lot of foundational improvements since 
mid-2014 that we can safely rely on now, so these changes make sense.


with authors hat: what Lance said!

IIRC the only reason we didn't go for a full carbons + mam dependency 
back in the day because the path forward on those was unclear.


Agreed.

I left some editorial comments on the PR, but in general LGTM.

/psa

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

Re: [Standards] XEP-0371: Jingle ICE Transport Method - Question on ICE Restart detection

[Peter Saint-Andre]

On 11/17/21 2:25 AM, Philipp Hancke wrote:

Am 16.11.21 um 20:31 schrieb Daniel Gultsch:

Hi,

I’m trying to implement ICE Restarts with XEP-0371. The XEP states
that ICE restarts can be detected by a changed ufrag and pwd
attributes in the transport-info.

However what I'm currently unclear about is how I can detect if the
incoming transport-info is a request to restart ICE on its own or a
response to an ICE restart we initiated.

Or to put it into WebRTC terminology how do I know if a transport-info
with changed ufrag/pwd is an Offer or an Answer.


oh this does a fancy variant which doesn't map 1:1 to WebRTC sdp.

Assume the following collision happening in parallel:
initiator: restart, transport-info
responder: restart, transport-info
Upon receiving the messages,
- the initiator consider the second message a response and maps it to an 
answer.

- the responder will also consider it a response and map it to an answer.

Both will then update their respective ufrag/pwd and be happy.

It should actually work no matter what, leaving role conflict handling 
to ICE. Oddly

   https://jsfiddle.net/fippo/ytqmnsxh/5/
never changes the pair in Firefox but i'll go nag someone.


I might know people. ;-)

In general I would always initiate restarts from one side (e.g. the 
intiator), not both. Why bother with glare and conflicts when it is 
trivial to avoid...


+1

/psa

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

Re: [Standards] MPP Council Agenda 2021-10-27

[Peter Saint-Andre]

Regarding the subject line, it's about time that we finally got rid of 
the "X"! ;-)


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

Re: [Standards] Stable is the new Draft

[Peter Saint-Andre]

On 9/8/21 6:19 AM, Dave Cridland wrote:
> 
> 
> On Tue, 7 Sept 2021 at 16:44, Peter Saint-Andre  <mailto:stpe...@mozilla.com>> 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.

That's all true.

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

And let's keep resisting. :-)

Peter

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

Re: [Standards] Stable is the new Draft

[Peter Saint-Andre]

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:

https://datatracker.ietf.org/doc/rfc6410/

This would be the equivalent of removing the "Stable" state entirely.

That said, I'm in favor of the renaming.

Peter

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

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

[Peter Saint-Andre]

On 8/13/21 7:47 AM, Dave Cridland wrote:
> 
> 
> On Wed, 11 Aug 2021 at 22:49, Peter Saint-Andre  <mailto:stpe...@mozilla.com>> 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)
> <https://datatracker.ietf.org/doc/html/rfc2595#section-7>
> 
> 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".

Hey Dave, thanks for the history lesson. :-) It's easy to forget that
the technical landscape was quite different in 1999. Indeed, XML was the
new hotness back then!

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

Agreed.

Peter

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

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

[Peter Saint-Andre]

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".

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

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

[Peter Saint-Andre]

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...

On 8/11/21 2:13 PM, Philipp Hancke wrote:
> tl;dr: its a mess. What is the deployment state of xep-0368?
> 
> Am 11.08.21 um 19:08 schrieb Peter Saint-Andre:
>> Perhaps of interest here...
>>
>>
>>  Forwarded Message 
>> Subject: [Uta] STARTTLS vulnerabilities
>> Date: Wed, 11 Aug 2021 17:42:40 +0200
>> From: Hanno Böck 
>> To: u...@ietf.org
>>
>> Hi,
>>
>> I wanted to share some research we have done on vulnerabilities in
>> STARTTLS implementations:
>> https://nostarttls.secvuln.info/
>>
>> We started analyzing STARTTLS implementations in E-Mail servers and
>> clients based on the 2011 command injection discovered in Postfix. We
>> learned that this vulnerability is still very prevalent in current
>> servers and that clients suffer from simliar vulnerabilities. We also
>> found some IMAP specific vulnerabilities.
>>
>> Focussing on client-to-server communication our recommendations are
>> mostly in line with what this working group has already concluded in
>> RFC 8314, which is that implicit TLS on its own port should be
>> preferred over STARTTLS.
>>
>>
>> Our research has not focussed on the server-to-server part. Still I
>> think particularly the buffering / injection vulnerabilities are
>> a concern if one wants to secure s2s communication with mechanisms like
>> MTA-STS. I strongly recommend that users of MTA-STS audit their
>> STARTTLS implementations for buffering bugs.
>> (We found a buffering bug in Yahoo's MX servers, and Yahoo is one of
>> the companies driving MTA-STS. I was unable to report this properly to
>> Yahoo, I reported it through their Hackerone bugbounty program, but the
>> bug triagers were unwilling to try to understand the issue and didn't
>> forward it to Yahoo.)
>>
> ___
> 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
___

[Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Peter Saint-Andre]

Perhaps of interest here...


 Forwarded Message 
Subject: [Uta] STARTTLS vulnerabilities
Date: Wed, 11 Aug 2021 17:42:40 +0200
From: Hanno Böck 
To: u...@ietf.org

Hi,

I wanted to share some research we have done on vulnerabilities in
STARTTLS implementations:
https://nostarttls.secvuln.info/

We started analyzing STARTTLS implementations in E-Mail servers and
clients based on the 2011 command injection discovered in Postfix. We
learned that this vulnerability is still very prevalent in current
servers and that clients suffer from simliar vulnerabilities. We also
found some IMAP specific vulnerabilities.

Focussing on client-to-server communication our recommendations are
mostly in line with what this working group has already concluded in
RFC 8314, which is that implicit TLS on its own port should be
preferred over STARTTLS.


Our research has not focussed on the server-to-server part. Still I
think particularly the buffering / injection vulnerabilities are
a concern if one wants to secure s2s communication with mechanisms like
MTA-STS. I strongly recommend that users of MTA-STS audit their
STARTTLS implementations for buffering bugs.
(We found a buffering bug in Yahoo's MX servers, and Yahoo is one of
the companies driving MTA-STS. I was unable to report this properly to
Yahoo, I reported it through their Hackerone bugbounty program, but the
bug triagers were unwilling to try to understand the issue and didn't
forward it to Yahoo.)

-- 
Hanno Böck
https://hboeck.de/

___
Uta mailing list
u...@ietf.org
https://www.ietf.org/mailman/listinfo/uta
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] ALPACA attack

[Peter Saint-Andre]

I haven't seen notice of the ALPACA attack on this list, but it might be
of interest to those running XMPP services and non-XMPP services (e.g.,
HTTP or IMAP) on the same machine:

https://alpaca-attack.com/

We've added some text about this to the forthcoming revision of RFC 7525
(on which the XMPP recommendations for TLS, i.e., RFC 7590, depend):

https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-01#section-3.8

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

Re: [Standards] XEP Advancement Shortlist

[Peter Saint-Andre]

On 6/1/21 3:44 PM, Tedd Sterr wrote:
> I'll just leave this here…
> 
> https://mail.jabber.org/pipermail/standards/2020-January/036918.html

Some of those most definitely deserve to be deprecated or obsoleted. For
instance, is anyone still using SOAP, let alone SOAP over XMPP?

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

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

[Peter Saint-Andre]

On 5/7/21 7:33 AM, Edwin Mons wrote:
> On 07/05/2021 14:33, Kevin Smith wrote:
>> On 7 May 2021, at 13:30, Matthew Wild  wrote:
>>> On Fri, 7 May 2021 at 12:10, Edwin Mons  wrote:
 Hi all,

 I was looking at XEP-0198, and noticed something odd in Example 6.
 Shouldn't that have been a stream error instead, as the text above
 states? If so, will send out a PR.
>>> Which is correct? The text or the example? While I was originally
>>> inclined to agree that this should be a stream error, it should be
>>> noted that section 6 "Error Handling" states:
>>>
>>>  "If an error occurs with regard to an  or 
>>> element, the server MUST return a  element."
>>>
>>> and
>>>
>>>  "Stream management errors SHOULD be considered recoverable; however,
>>> misuse of stream management MAY result in termination of the stream."
>>>
>>> It's relevant in the context that a stream error will terminate the
>>> session (such that it can't be resumed).
>>>
>>> I don't feel strongly either way.
>> 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.

+1. Example 6 looks like a copy-paste error. Who wrote these specs?!?

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

Re: [Standards] DEPRECATED: XEP-0013 (Flexible Offline Message Retrieval)

[Peter Saint-Andre]

Finally! :-)

On 5/4/21 11:57 AM, Jonas Schäfer (XSF Editor) wrote:
> Version 1.3 of XEP-0013 (Flexible Offline Message Retrieval) has been
> released.
> 
> Abstract:
> This specification defines an XMPP protocol extension for flexible,
> POP3-like handling of offline messages. The protocol enables a
> connecting client to retrieve its offline messages on login in a
> controlled fashion, without receiving a flood of messages. Messages
> can also be left on the server for later retrieval.
> 
> Changelog:
> Deprecate after council vote of 2021-03-31 (XEP Editor (jsc))
> 
> URL: https://xmpp.org/extensions/xep-0013.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] RFC 8692

[Peter Saint-Andre]

Oops, I meant RFC 8962!

On 4/2/21 4:34 PM, Peter Saint-Andre wrote:
> There's a cute reference to XMPP in RFC 8692, published just yesterday:
> 
> https://www.rfc-editor.org/rfc/rfc8962.html
> 
> /psa
> 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] RFC 8692

[Peter Saint-Andre]

There's a cute reference to XMPP in RFC 8692, published just yesterday:

https://www.rfc-editor.org/rfc/rfc8962.html

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

Re: [Standards] Message Carbons authors and LC

[Peter Saint-Andre]

On 3/11/21 11:02 AM, Joe Hildebrand wrote:
> I have no objections to someone else taking over, and removing my name from 
> the doc.  Feel free to do that for any docs where I'm an author going 
> forward, as needed.

Thanks, Joe. Our long-time practice has been to keep the original
authors but add new authors as maintainers / updaters.

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

Re: [Standards] XEP-0294: update the reference from RFC 5285 to RFC 8285 and add a mapping for a=extmap-allow-mixed

[Peter Saint-Andre]

Hi Fippo!

On 3/10/21 11:04 AM, Philipp Hancke wrote:
> I submitted a PR to update XEP-0294 here:
>   https://github.com/xsf/xeps/pull/1044
> after Chrome 89 (after a lot of time) started shipping the
>   a=extmap-allow-mixed attribute (which old Chrome versions wrongly
> attempted to parse as a=extmap: ...)
> 
> 
> There are two meta issues here (and as the council rightly pointed out
> this should be discussed on standards@ anyway):
> 
> 1/ how do we handle updates to normative IETF references?
> In this case it is not a big issue since, as Jonathan Lennox pointed
> out, RFC 8285 was designed to be backward compatible.
> 
> The addition of the attribute to the schema should be backward
> compatible so doesn't require a namespace version bump imo.

Unfortunately I think we need to look at these on a case-by-case basis.

> 2/ a long-standing issue about not having an equivalent to the session
> level description SDP has.
> I didn't attempt to solve it but this required writing some extra text.
> See XEP-0338 for another instance of this. If you're dealing with
> browser you might be aware that Firefox puts the ice-ufrag/ice-pwd at
> that level.

We might indeed want to address this.

Semi-related, we might want to update various Jingle specs to reflect
publication of all the WebRTC-related RFCs (e.g., 8838 for Trickle ICE).

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

Re: [Standards] Message Carbons authors and LC

[Peter Saint-Andre]

On 3/11/21 9:48 AM, Georg Lukas wrote:
> * Sam Whited  [2021-03-11 15:05]:
>> The authors of message carbons haven't been active for a while if I'm
>> not mistaken.
> 
> As somebody who has done the most non-editorial changes on the XEP in
> the last six years, and saw (and contributed to) it failing Last Calls
> in 2020, 2019, 2018, 2017, and 2015, I'd be glad and honored to
> volunteer as the new maintainer.
> 
> However, given the history of Last Calls, I can not make any promises to
> successfully get the XEP into Draft status.

Thanks, Georg.

That's a lot of Last Calls that didn't lead to advancement of the spec.
Were the same concerns raised each time, or were the concerns different?

Peter

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

Re: [Standards] Message Carbons authors and LC

[Peter Saint-Andre]

On 3/11/21 7:01 AM, Sam Whited wrote:
> Hi all,
> 
> The authors of message carbons haven't been active for a while if I'm
> not mistaken. 

Correct. Also Joe Hildebrand's email address in XEP-0280 won't work
anymore, but I've bcc'd him and Matt Miller on this message.

> Do we have any current authors? 

I don't think so.

> If not, I'd like for us
> to consider appointing someone (I am also happy to volunteer, but
> others who have been more involved with these discussions may be a
> better choice) or just sending it to LC again if the editors would be
> so kind. Thanks!

Makes sense.

Peter

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

Re: [Standards] Important change of process for changes to XEPs under control of the XMPP Council

[Peter Saint-Andre]

On 2/17/21 9:42 AM, Jonas Schäfer wrote:
> Change proposals to XEPs which 
> are under the control of Council do not get put on the Council agenda before 
> there has been a thread on the standards mailing list.

This seems reasonable.

By "XEPs which are under the control of Council" do we mean specs that
have a status of Draft, Final, or Active (well, I suppose also
Deprecated and Obsolete)?

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

Re: [Standards] Proposed XMPP Extension: DOAP usage in XMPP

[Peter Saint-Andre]

On 1/13/21 12:35 PM, Dave Cridland wrote:
> 
> 
> On Wed, 13 Jan 2021 at 18:24, Sam Whited  > wrote:
> 
> I'd like to recommend that we do not publish this spec in its current
> form. The XML community has the tendency to over-engineer everything to
> try and reuse schemas as much as possible which just makes things more
> difficult for no reason. This is a handful of simple key/value pairs, it
> doesn't need to use RDF or whatever the "schema" prefix means.
> 
> If this spec is moved forward please consider either adding a JSON
> representation since this is mostly for the web and is effectively just
> a set of key-value pairs which probably makes JSON a better format for
> storing it, or a simplified XML representation that can be completely
> defined in this document and exists in a single namespace.
> 
> 
> I was under the impression that DOAP was an existing deployed
> specification, and that the use of RDF/XML wasn't unexpected.
> 
> In particular, it appears that both Mozilla and PyPI seem to use it, so
> assuming reuse of existing standards is our thing - and presumably that
> is exactly our thing - then use of DOAP seems like the right choice.

It's unclear to me whether we actually use DOAP at Mozilla, but I'm
double-checking.

Peter

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

Re: [Standards] Deprecating Dialback

[Peter Saint-Andre]

On 12/2/20 8:36 AM, Dave Cridland wrote:
> 
> 
> On Wed, 2 Dec 2020 at 14:09, Sam Whited  > wrote:
> 
> I've been having a think about dialback recently and came to the
> conclusion that it would be nice to begin discouraging its use on the
> public network. This would raise the overall quality of authentication
> on the network by beginning to phase out insecure DNS-based
> authentication as well as simplify the implementation of certificate
> based auth by allowing us to only rely on SASL EXTERNAL without having
> to also implement "dialback without dialing back". Towards that end, I
> would like to propose deprecating XEP-0220 and XEP-0185.
> 
> 
> There are two things here:
> 
> a) Phasing out DNS-based authentication - ie, db:verify.
> 
> b) Phasing out the use of the db:result syntax.
> 
> The DNS side, (a), is easy to suggest deprecation. It's fundamentally
> weak, and it really only served a useful purpose before Let's Encrypt
> came along. 

Well, in 1999/2000 it was hard (for some definition) to get certs at
all. Dialback was a bootstrapping mechanism for server deployment (along
the lines of IBR for c2s) and I agree deserves to be deprecated now.

> But we don't have a solution without  for "piggybacking", as
> described in
> XEP-0220: https://xmpp.org/extensions/xep-0220.html#multiplex
> 
> 
> I think multiplexing has value in a number of cases, particularly where
> S2S bandwidth and/or latency is poor.
> 
> Proposal:
> 
> 1) Pull multiplexing out into its own XEP.
> 
> 2) Give it a new syntax (and a stream feature) that doesn't imply
> XEP-0220 anymore. Reference the old syntax as a historical case.

Will that actually speed things up? Multiplexing would be a new protocol
for server developers to implement and for server operators to deploy.

Just wondering. :-)

Peter

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

Re: [Standards] form field types: text-multi vs list-multi with

[Peter Saint-Andre]

Hi. Florian asked me to reply, so here I am. :-)

On 5/7/20 10:00 AM, Florian Schmaus wrote:
> On 5/5/20 12:35 PM, Matthew Wild wrote:
>> On Sat, 2 May 2020 at 21:29, Florian Schmaus > > wrote:
>>
>> So why go for the slightly more complicated semantic of
>> list-multi+, when we could just go with text-multi?
>>
>>
>> We covered this somewhat in the MUC since you sent this email, but I'll
>> summarize here.
> 
> Thanks for taking the time to reply here. Much appreciated. :)
> 
> 
>> text-multi is defined and intended to be used for submitting a
>> *multi-line string*. It is not (as you might easily interpret from the
>> name) intended for submission of multiple independent text values. The
>> latter is covered by list-multi (which was evidently already found to be
>> restrictive by the time XEP-0122 was written and defined ).
> 
> That is basically the bottom of our dispute. You believe that presenting
> multi line strings on the UI level is the *only* reason text-multi
> exists. But I do not see any reason why it should not *also* be used to
> carry multiple text values. And there are already XEPs which use
> text-multi that way. See XEP-0248 for example. You seem to ignore this
> point.

It's true that Data Forms were defined with UI (not m2m) in mind, and
that text-multi fields were supposed to enable multi-line input,
equivalent to the HTML  element. However, if we look at all
the uses of text-multi in XEPs, it seems that we abandoned the UI focus
or "text blog" construct a long time ago. Here are some examples.

XEP-0060...

  

  

XEP-0068...

  http://example.com/pubsub}time_restrictions;
 type="text-multi"
 label="Limit to these time ranges">
09:00-12:00
13:00-17:00
  

XEP-0115...

  
ipv4
ipv6
  

XEP-0141...

  
  

  
  

XEP-0248...

  

  

XEP-0326...

  
Temperature
Pressure
Power
  

Although some of these specs never advanced beyond Experimental and you
could argue that they might have been "corrected" before advancing,
others are Draft standards in wide use. We might want to face reality
and allow text-multi to treat each line as semantically independent.

Peter

P.S. I realize that this inconsistency is my fault, since I authored
both XEP-0004 and specs that violate XEP-0004. Sorry about that!



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Registrar: disco-categories: Add 'telegram' gateway type

[Peter Saint-Andre]

On 4/5/20 10:44 AM, Maxime Buquet wrote:
> On 2020/04/04, Linus Jahn wrote:
>> Hello,
>>
>> I opened a pull request more than 1.5 years ago and received a +1 from 
>> stpeter,
>> but no further interaction. The pull request was not merged.
>>
>> The pull request can be found here:
>> https://github.com/xsf/registrar/pull/30
>>
>> Can I do something to speed up this? Is writing a mail here the correct way?
>>
>> Thanks in advance,
> 
> 
> Hey Linus,
> 
> Sorry for the lack of response on this issue.
> For some reason I entirely missed this. I'm now subscribing to this
> repo.
> 
> This is editor realm. 

Yes, and handling the registries is just about the only thing I'm doing
for the editor team now.

PR merged.

> The registry has been somewhat "off" for a long
> time now. I don't know the details but I believe not easy to update
> because something something infrastructure.
> 
> As you can see in the xsf/xeps repo[0] some PRs are also blocking on
> this.
> 
> I hope iteam gets to have a look at this soon.

+1 - I haven't looked into these infra issues in quite some time so I no
longer feel competent to fix them.

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Registrar: disco-categories: Add 'telegram' gateway type

[Peter Saint-Andre]

On 4/4/20 12:15 PM, Linus Jahn wrote:
> Hello,
> 
> I opened a pull request more than 1.5 years ago and received a +1 from 
> stpeter,
> but no further interaction. The pull request was not merged.
> 
> The pull request can be found here:
> https://github.com/xsf/registrar/pull/30
> 
> Can I do something to speed up this? Is writing a mail here the correct way?

ACK.

I thought someone else was going to merge this, but with my registrar
hat on I will do that soon.

Peter

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Peter Saint-Andre]

On 1/16/20 2:49 PM, Dave Cridland wrote:

[ historical inaccuracies elided :P ]

> > Peter Saint-Andre (I think) designed our standards process to
> avoid the
> > Internet Draft stage and go straight to the wild-west of Experimental,
> > but it's otherwise the same as the original IETF design.
> 
> Originally, the Editor (me) accepted anything for publication as a JEP,
> after minimal coherence / formatting checks and IPR assignment. Then the
> Council decided it wanted to act as a gate to publication, which is how
> got here. Instead of adding more epicycles, I propose that we remove the
> one we added. Consider me in favor of the "Daniel Plan".
> 
> I can easily be persuaded to go for the Florian Plan (or indeed the
> closely-related Kev Plan), but I rather lean toward the Daniel Plan - as
> you note, it fits the history of the XSF much better. I would be
> fascinated to hear the original reasoning for the Council wanting the
> veto in the first place, and I doubt it has much to do with how it's
> used now.

Control. Power. The usual suspects. ;-)

I don't exactly recall - we'd need to look at the list archives. But I'd
say this happened in 2004 or 2005 because, for instance, XEP-0143 went
directly to version 0.1 on 2004-09-15 whereas subsequent specs underwent
several and sometimes multiple revisions based on Council feedback
before being published as XEPs.

> My concern is that on several occasions the Council has been the only
> thing preventing encumbered specifications from entering the Standards
> Track, so I think this use of the veto is risky to lose entirely.

Did we receive any encumbered specifications before ~2004-2005?

Did this issue even arise back then, and if not does it make sense to
attribute this magical power of saving us from encumbered specifications
to the Council?

How do we determine that specifications are encumbered and do we
actually need the Council for that?

Peter

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Peter Saint-Andre]

On 12/13/19 6:58 AM, Dave Cridland wrote:
> 
> 
> On Thu, 12 Dec 2019 at 16:41, Daniel Gultsch  <mailto:dan...@gultsch.de>> wrote:
> 
> I mean correct me if I'm wrong but the IETF seems to be doing fine
> with just two stages.
> 
> 
> Some history...
> 
> The IETF used to have, essentially, three stages. Proposed Standard,
> Draft Standard, and Internet Standard - the latter getting a STD number
> as well as the RFC number. PS was the wild west,

Actually, the wild west was not so wild. [1]

> with (fairly) low
> requirements. 
>
> Then they formalized the step before, Internet Drafts, and
> gradually the Proposed Standard quality (and gating function by the
> IESG) improved, to the point where it was felt that there was an
> additional stage that added little, so they dropped it.
> 
> Peter Saint-Andre (I think) designed our standards process to avoid the
> Internet Draft stage and go straight to the wild-west of Experimental,
> but it's otherwise the same as the original IETF design.

Originally, the Editor (me) accepted anything for publication as a JEP,
after minimal coherence / formatting checks and IPR assignment. Then the
Council decided it wanted to act as a gate to publication, which is how
got here. Instead of adding more epicycles, I propose that we remove the
one we added. Consider me in favor of the "Daniel Plan".

Peter

[1] https://www.independent.org/publications/tir/article.asp?id=552
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Clarification for XEP-0054: private fields

[Peter Saint-Andre]

On 9/19/19 1:01 AM, Wichert Akkerman wrote:


> I am looking for a clarification on XEP-0054. The history description
> for the XEP mentions that it essentially encapsulates
> draft-dawson-vcard-xml-dtd-01 over XMPP, with changes to using
> xuppercase for elements and adding JABBERID and
> DESC. draft-dawson-vcard-xml-dtd-01 also documents private fields [1],
> with a basic example:
> 
>            VERSION="3.0"
>         PRODID="-//HandGen//NONSGML vGen v1.0//EN">
>    Frank Dawson
>      Dawson
>         Frank
>    +1-617-693-8728
>    O+
>    
> 
> Unfortunately it forgot to include this in the DTD. This was extended
> later in draft 2 [2], and fully defined in the DTD for RFC 2426.

The vcard-temp namespace has always been a mess and its origins are hazy
(it was cooked up even before I joined the project in November 1999). I
would not rely too much on whatever was documented in draft-dawson-* or
described in XEP-0054.

> My question is: are implementation of XEP-0054 supposed to a) strictly
> use the DTD from XEP-0054, and thus required throw away any extra
> elements not mentioned there, b) support private fields since they are
> mentioned in draft-dawson-vcard-xml-dtd-01, or c) be liberal and
> preserve unknown elements?

Sadly, I don't think we can say definitively what to do. Typically we
don't consider DTDs and schemas to be normative and we have often not
strictly documented extension points such as the private field you've
noted in draft-dawson-vcard-xml-dtd-01.

Personally I think it's best for us to migrate to vCard4 (which as
Matthew notes has a better-defined extension mechanism) and I would
favor discarding unknown elements in the context of vcard-temp because
there's a possibility of abuse.

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

Re: [Standards] Clarification for XEP-0054: private fields

[Peter Saint-Andre]

On 9/19/19 1:24 AM, Matthew Wild wrote:

> Prosody also historically preserved everything (it basically treated
> the vcard as an XML blob). However now we have moved to vcard4, our
> compatibility code can obviously only convert fields it knows and
> understands - therefore any custom fields would also get discarded.
> However I also see that there is a defined way to handle unknown
> fields in conversion ( https://tools.ietf.org/html/rfc6351#section-6
> ), so it's not impossible to preserve them.
> 
> That said, our vcard4 implementation largely handles the submitted
> vcard as an XML blob also - putting stuff into a custom namespace is
> totally possible.

Perhaps it's time to move forward with XEP-0292?

Peter

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

Re: [Standards] XEP-0184: normative message @type rules (Was: Council Voting Summary 2019-04-14)

[Peter Saint-Andre]

On 5/8/19 12:23 PM, Florian Schmaus wrote:
> On 25.04.19 21:09, Georg Lukas wrote:
>> * Kevin Smith  [2019-04-17 20:28]:
 PR #779 - XEP-0184: add a box about types and JIDs - 
 https://github.com/xsf/xeps/pull/779
>>>
>>> This seems a little backwards to me - it’s only saying the completely
>>> non-normative 'is a good practice’ for doing the right thing, while
>>> saying ’should’ (yes, I realise lower case) accept the wrong thing.
>>> Should we not SHOULD doing the right thing?
>>
>> You've done a good job of hiding this remark (even from me), and the
>> topic didn't fit into our last Council Meeting, so pulling this back up
>> on the list, with a greppable subject.
>>
>> If you prefer to have normative value-add, I'd replace the figleaf-box
>> with something akin to this strawman text:
>>
>> -
>> The receiving client should consider the following when generating a
>> Receipt, depending on the message type of the message that contained
>> the Receipt Request:
>> …
>>
>> - "error": this should not actually be possible, so the client SHOULD
>>   NOT (MUST NOT) respond.
> 
> I think this is actually possible: Consider a bounced Delivery Receipt
> Request where the bouncing entity followed RFC 6120 § 8.3.1. 6., i.e.,
> "The entity that returns an error stanza MAY include the original XML
> sent…".
> 
> I think this is a typical case where we have to break an endless cycle,
> therefore it should be "MUST NOT".

Agreed.

Peter



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0184: normative message @type rules (Was: Council Voting Summary 2019-04-14)

[Peter Saint-Andre]

On 5/8/19 9:27 AM, Jonas Schäfer wrote:
> On Donnerstag, 25. April 2019 21:09:04 CEST Georg Lukas wrote:
>> * Kevin Smith  [2019-04-17 20:28]:
 PR #779 - XEP-0184: add a box about types and JIDs -
 https://github.com/xsf/xeps/pull/779> 
>>> This seems a little backwards to me - it’s only saying the completely
>>> non-normative 'is a good practice’ for doing the right thing, while
>>> saying ’should’ (yes, I realise lower case) accept the wrong thing.
>>> Should we not SHOULD doing the right thing?
>>
>> You've done a good job of hiding this remark (even from me), and the
>> topic didn't fit into our last Council Meeting, so pulling this back up
>> on the list, with a greppable subject.
>>
>> The rationale for #779 was not to change normative language while
>> providing additional value to new developers.
>>
>> If you prefer to have normative value-add, I'd replace the figleaf-box
>> with something akin to this strawman text:
>>
>> -
>> The receiving client should consider the following when generating a
>> Receipt, depending on the message type of the message that contained
>> the Receipt Request:
>>
>> - "chat", "normal": the Receipt message SHOULD have the same @type as
>>   the Request message.
>>
>> - "groupchat": it is NOT RECOMMENDED to request Receipts in a MUC. A
>>   client choosing to respond despite of this SHOULD send the Receipt
>>   with type="groupchat" to the bare JID of the room and not to the full
>>   JID of the sender. It MAY be useful to limit this feature to private
>>   MUCs with a small number of participants, or to instead send the
>>   Receipt as a MUC-PM.
>>
>> - "headline": the Receipt message SHOULD have type="normal".
>>
>> - "error": this should not actually be possible, so the client SHOULD
>>   NOT (MUST NOT) respond.
>>
>> A client MUST be able to Process a Receipt message with a different type
>> than the original Receipt Request message.
>> -
>>
>> However, this is obviously a normative language change to a Draft XEP
>> and so I didn't dare to do it, initially.
> 
> This sounds good to me, except for the rule for "headline". I have no idea 
> whether that’s good or bad.

The 'headline' rule seems fine to me.

Peter



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0418 (DNS Queries over XMPP (DoX))

[Peter Saint-Andre]

On 4/4/19 11:08 AM, Dave Cridland wrote:
> 
> 
> On Thu, 4 Apr 2019 at 17:26, Peter Saint-Andre  <mailto:stpe...@mozilla.com>> wrote:
> 
> On 4/1/19 12:59 PM, Florian Schmaus wrote:
> > On 30.03.19 16:48, Jonas Schäfer (XSF Editor) wrote:
> >> Version 0.1.0 of XEP-0418 (DNS Queries over XMPP (DoX)) has been
> >> released.
> >>
> >> Abstract:
> >> This specification defines an XMPP protocol extension for sending DNS
> >> queries and getting DNS responses over XML streams. Each DNS query-
> >> response pair is mapped into an IQ exchange.
> >>
> >> Changelog:
> >> Accepted by vote of Council on 2019-03-13. (XEP Editor (jsc))
> >>
> >> URL: https://xmpp.org/extensions/xep-0418.html
> >
> > Love it. Although I don't have an immediate use case, I could imagine
> > that one will come up possibly.
> 
> It's been noted on the DNSOP list:
> 
> https://mailarchive.ietf.org/arch/msg/dnsop/hbRHqdvQZquBtNx3IVede9VMSE8
> 
> In general I'm not a fan of working on things that "don't have an
> immediate use case". Are folks here actively interested in implementing
> and deploying DoX or is it just a thought experiment so far?
> 
> 
> Yes, people have actually implemented and deployed it.

Sweet. :-) Because I'm on a team that's working to deploy DoH at
Internet scale, I'd love to hear more about the DoX deployments (feel
free to ping me offlist).

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

Re: [Standards] NEW: XEP-0418 (DNS Queries over XMPP (DoX))

[Peter Saint-Andre]

On 4/1/19 12:59 PM, Florian Schmaus wrote:
> On 30.03.19 16:48, Jonas Schäfer (XSF Editor) wrote:
>> Version 0.1.0 of XEP-0418 (DNS Queries over XMPP (DoX)) has been
>> released.
>>
>> Abstract:
>> This specification defines an XMPP protocol extension for sending DNS
>> queries and getting DNS responses over XML streams. Each DNS query-
>> response pair is mapped into an IQ exchange.
>>
>> Changelog:
>> Accepted by vote of Council on 2019-03-13. (XEP Editor (jsc))
>>
>> URL: https://xmpp.org/extensions/xep-0418.html
> 
> Love it. Although I don't have an immediate use case, I could imagine
> that one will come up possibly.

It's been noted on the DNSOP list:

https://mailarchive.ietf.org/arch/msg/dnsop/hbRHqdvQZquBtNx3IVede9VMSE8

In general I'm not a fan of working on things that "don't have an
immediate use case". Are folks here actively interested in implementing
and deploying DoX or is it just a thought experiment so far?

Peter



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Peter Saint-Andre]

On 3/27/19 12:24 PM, Sam Whited wrote:
> On Wed, Mar 27, 2019, at 17:14, W. Martin Borgert wrote:
>> 0393 is not bad, IMHO. It might need two or three additions, esp.
>> hyperlinks, but most typical use cases are covered.
> 
> What is the use case for hyper links and who does it benefit? I
> keep hearing people say they want them, but I don't really
> understand why they're necessary over just auto linking things that
> look like URLs. Thanks.

+1

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

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

[Peter Saint-Andre]

On 3/14/19 11:05 AM, Dave Cridland wrote:
> 
> 
> On Thu, 14 Mar 2019 at 15:14, Peter Saint-Andre  <mailto:stpe...@mozilla.com>> wrote:
> 
> On 3/14/19 5:05 AM, Dave Cridland wrote:
> >
> >
> > On Wed, 13 Mar 2019 at 21:46, Ralph Meijer  <mailto:ral...@ik.nu>
> > <mailto:ral...@ik.nu <mailto:ral...@ik.nu>>> wrote:
> >
> >     On 13/03/2019 22.16, Kevin Smith wrote:
> >     >
> >     >
> >     >> On 13 Mar 2019, at 17:37, Peter Saint-Andre
> mailto:stpe...@mozilla.com>
> >     <mailto:stpe...@mozilla.com <mailto:stpe...@mozilla.com>>> wrote:
> >     >>
> >     >> I can help, but I would not object to adding a more active
> co-author
> >     >> (preferably an implementor of the spec).
> >     >
> >     > Do you want to request a last call? Under the new rules Council
> >     aren’t allowed to trigger an LC any more unless either the authors
> >     request it or the authors abandon the XEP.
> >
> >     Kev,
> >
> >     I think this is a very narrow reading of the new text, and I don't
> >     agree
> >     that this says the Approving Body cannot issue (=/= trigger) a
> Last
> >     Call, via the Editor, if it so sees fit. What the changed text
> is meant
> >     to ensure is that once a Last Call is issued, there's
> somebody, either
> >     an author or document shepherd, to process feedback of that
> Last Call
> >     and during the approval process of the Approving Body. And
> that there's
> >     a defined way to propose advancement by authors, or others in
> case it
> >     appears that the authors are no longer interested in such
> advancement.
> >
> >     If you think this new wording suggests that the Approving Body
> (in this
> >     case Council) is no longer in full control of the process,
> then please
> >     propose changes so this can be rectified.
> >
> >
> > I think the way that XEP-0001 is currently written suggests that
> if the
> > Council triggered a Last Call without the author(s) involved, the
> > Author(s) could complain on the grounds that we have not followed
> > XEP-0001 as written.
> 
> Has this ever happened or is it purely hypothetical?
> 
> 
> It is hypothetical. Hopefully it will remain so.
>  
> 
> > Since we do not have a complaints procedure, what happens then is
> > anyone's guess. (I think they need to complain to the Board, and
> if that
> > fails to achieve a resolution, to the Members - but that's a
> suggestion
> > and is in no way supported by any of our process documents).
> 
> It seems to me that the Board is the appropriate escalation path,
> although raising an issue among the membership would also work.
> 
> Personally I don't see the need for every possible eventuality to be
> captured in process documents...
> 
> 
> No, me neither, but I go back and forth over whether we should have some
> kind of appeals process for where people think Council actions are
> "Wrong" - it'd be painful to have to figure one out on the fly, anyway.

IMHO the Board should be the body to which appeals are directed, and I
will write that up for discussion among the membership. Naturally, if
the members don't like how the Board has handled something, they have
other remedies.

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

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

[Peter Saint-Andre]

On 3/14/19 5:05 AM, Dave Cridland wrote:
> 
> 
> On Wed, 13 Mar 2019 at 21:46, Ralph Meijer  <mailto:ral...@ik.nu>> wrote:
> 
> On 13/03/2019 22.16, Kevin Smith wrote:
> >
> >
> >> On 13 Mar 2019, at 17:37, Peter Saint-Andre  <mailto:stpe...@mozilla.com>> wrote:
> >>
> >> I can help, but I would not object to adding a more active co-author
> >> (preferably an implementor of the spec).
> >
> > Do you want to request a last call? Under the new rules Council
> aren’t allowed to trigger an LC any more unless either the authors
> request it or the authors abandon the XEP.
> 
> Kev,
> 
> I think this is a very narrow reading of the new text, and I don't
> agree
> that this says the Approving Body cannot issue (=/= trigger) a Last
> Call, via the Editor, if it so sees fit. What the changed text is meant
> to ensure is that once a Last Call is issued, there's somebody, either
> an author or document shepherd, to process feedback of that Last Call
> and during the approval process of the Approving Body. And that there's
> a defined way to propose advancement by authors, or others in case it
> appears that the authors are no longer interested in such advancement.
> 
> If you think this new wording suggests that the Approving Body (in this
> case Council) is no longer in full control of the process, then please
> propose changes so this can be rectified.
> 
> 
> I think the way that XEP-0001 is currently written suggests that if the
> Council triggered a Last Call without the author(s) involved, the
> Author(s) could complain on the grounds that we have not followed
> XEP-0001 as written.

Has this ever happened or is it purely hypothetical?

> Since we do not have a complaints procedure, what happens then is
> anyone's guess. (I think they need to complain to the Board, and if that
> fails to achieve a resolution, to the Members - but that's a suggestion
> and is in no way supported by any of our process documents).

It seems to me that the Board is the appropriate escalation path,
although raising an issue among the membership would also work.

Personally I don't see the need for every possible eventuality to be
captured in process documents...

Peter

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

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

[Peter Saint-Andre]

On 3/14/19 6:17 AM, Dave Cridland wrote:
> 
> 
> On Thu, 14 Mar 2019 at 11:25, Ненахов Андрей
> mailto:andrew.nenak...@redsolution.ru>>
> wrote:
> 
> 
> People send comments on the list, and we answer their questions,
> propose
> modifications to the text of the document, submit or process pull
> requests, etc. For a small spec like this, it should be pretty
> simple.
> Plus if you are a co-author if you will be famous forever. ;-)
> 
> 
> Ok, I think I can handle it. Plus, vanity is my favourite sin.  
> 
> 
> It used to be mine until Carly Simon wrote a song about me.

Dave, how old were you in 1971? ;-)

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

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

[Peter Saint-Andre]

On 3/13/19 11:46 AM, Ненахов Андрей wrote:
> 
> 
> ср, 13 мар. 2019 г. в 21:54, Dave Cridland  >:
> 
> Philipp, Peter,
> 
> Do either of you want to remain involved with this one?
> 
> Andrew,
> 
> If they don't, would you be able to handle processing Last Call
> feedback?
> 
> 
> Probably, I can, but I don't know exactly what exactly 'handle
> processing Last Call feedback' means (Sorry for my ignorance). We do
> plan to implement it, though.

People send comments on the list, and we answer their questions, propose
modifications to the text of the document, submit or process pull
requests, etc. For a small spec like this, it should be pretty simple.
Plus if you are a co-author if you will be famous forever. ;-)

Peter

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

Re: [Standards] Proposed XMPP Extension: DNS Queries over XMPP (DoX)

[Peter Saint-Andre]

Many years ago, people in Cuba used XMPP to get to the web because HTTP
ports were blocked. :-)

However, with DoH I am not sure we need DoX, too.

Peter

On 3/13/19 2:02 AM, Sergey Ilinykh wrote:
> I guess it's something about accessing forbidden resources from
> restrictive corporate networks. 
> 
> ср, 13 мар. 2019 г., 10:40 Philipp Hörist  >:
> 
> Whats the use case for this XEP?
> Until now i only needed DNS querys to connect to the XMPP Server, i
> see this XEP is not helping with that as it already needs an active
> connection to the XMPP Server.
> 
> regards
> Philipp
> ___
> 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
> ___
> 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

[Peter Saint-Andre]

I can help, but I would not object to adding a more active co-author
(preferably an implementor of the spec).

Peter

On 3/13/19 10:53 AM, Dave Cridland wrote:
> Philipp, Peter,
> 
> Do either of you want to remain involved with this one?
> 
> Andrew,
> 
> If they don't, would you be able to handle processing Last Call feedback?
> 
> On Wed, 13 Mar 2019 at 13:14, Ненахов Андрей
> mailto:andrew.nenak...@redsolution.ru>>
> wrote:
> 
> Hello, everyone.
> 
> Could we please advance XEP-0353: Jingle Message Initiation
>  to draft, please?
> 
> We need it because bare XEP-0166 does not work well with push
> notifications, and does not support 'ring an all devices' behaviour.
> 
> 
> -- 
> Andrew Nenakhov
> CEO, Redsolution, Inc.
> https://redsolution.com 
> ___
> 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
> ___
> 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0013 Flexible Offline Message Retrieval, MAM and smacks

[Peter Saint-Andre]

On 2/27/19 5:18 AM, Georg Lukas wrote:
> * Thilo Molitor  [2019-02-17 14:03]:
>> Does anyone of you use XEP-0013 in your client other than for purging 
>> offline 
>> messages when you support MAM?
> 
> To write down our discussion from the MUC: I think this is a bad idea
> for multiple reasons.
> 
> 1. 0013 is just a workaround for a problem that should be solved by MAM
> instead (duplication between offline messages and the data from MAM).
> 
> 2. 0013 is prone to race conditions between the deletion of the offline
> messages, the MAM query and the available presence, where messages will
> be duplicated in the best case and lost in the worst case.
> 
> 3. Use of 0013 does not imply MAM.

IMHO it's time to declare XEP-0013 obsolete. It served a purpose when we
defined it in 2003, but we have much better solutions now.

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 (SASL2): Format of tasks, internationalisation of messages, Security Considerations

[Peter Saint-Andre]

On 1/31/19 8:58 AM, Jonas Schäfer wrote:
> So since during the summit, it was desired to have a breaking change to SASL2 
> (that’s rare, isn’t it?), I have two suggestions for things which could use 
> fixing and which could trigger a namespace bump and one thing which should be 
> mentioned independently:
> 
> 
> 1. xml:lang on : The error messages could use xml:lang support, like 
> stanza and RFC 6120 sasl errors do (with multiple  elements in 
> different languages).
> 
> 2. Is there a particular reason why the  thing uses plain strings as 
> its values instead of a mechanism like , where namespaced 
> elements with possible child elements / text are used?
> 
> 3. We should mention in the security considerations that clients should be 
> careful which requests they include in the initial  especially 
> when no transport security is in use; if the SASL method allows mutual 
> authentication (e.g. SCRAM), a client might find that they’re not actually 
> connected to the server and have just sent possibly private data to them.

That all seems reasonable.

Peter



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0292: vCard4 - advance?

[Peter Saint-Andre]

> On Jan 19, 2019, at 5:50 PM, Kim Alvefur  wrote:
> 
>> On Sun, Jan 20, 2019 at 12:29:43AM +, Philipp Hörist wrote:
>> Only thing i would change is this sentence
>> 
>>> When a client stores items at this node, it SHOULD NOT include an
>>> ItemID, so that the pubsub service can assign those identifiers.
>> 
>> Maybe i dont understand why this was written but it seems unnecessary
>> to me. It should be the implementors choice if it stores the data in a
>> way that allows to pull all changes to the vcard since first publish,
>> or use a singleton node item id "current".
> 
> This part is about storing custom vcards for your contacts, implying
> that you probably want to be able to store as many as you have contacts.
> Therefore the singleton "current" method is not appropriate. Using the
> contacts bare JID might be a better idea?

WFM

/psa

> 
> -- 
> 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] XEP-0292: vCard4 - advance?

[Peter Saint-Andre]

+1. It sure would be great to kill off vcard-temp after all these years.

Another benefit: vcard4 is extensible and thus can be used in a wide
variety of specialized applications (gaming, IoT, etc.).

Peter

On 1/19/19 1:44 PM, Kim Alvefur wrote:
> Hi,
> 
> I would like to see XEP-0292: vCard4 Over XMPP advanced. Since
> popularity and deployment of XEP-0084 appears to be on the rise, much
> thanks to XEP-0398, now seems like a good time to dust it off and finish
> it.
> 
> One benefit over vcard-temp is improved and configurabel access control,
> if XEP-0222 & 0223 are supported. vcard-temp has historically been
> completely public, something that may not be clear to users.
> 
> I'm not sure if the IQ based protocol defined is really worth it over
> simply storing the vcard4 data per XEP-0222, but it's not hard to
> implement or use, so it might be okay.
> 
> The current version of Prosody includes support for XEP-0292 in the form
> of a plugin that provides access to the relevant PEP node via the IQ
> protocol described as well as an exception that allows such requests to
> pass trough MUC. There is also an implementation of XEP-0398 that
> translates between vcard-temp and vcard4+xep84.
> 
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
> 



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Tidying Deferred

[Peter Saint-Andre]

On 1/17/19 3:43 AM, Ralph Meijer wrote:
> On 17/01/2019 11.25, Evgeny wrote:
>> On Thu, Jan 17, 2019 at 1:05 PM, Dave Cridland  wrote:
>>> we do not require it until Final - not even Draft has an absolute
>>> requirement.
>>
>> I thought transitioning to Draft requires Call For Implementors,
>> but whatever. Again this raises a question about how sane all
>> those XEP statuses nowadays. I know this is copied from IETF
>> workflow, but they have the same problems: a large number of RFCs
>> without implementations or with abandoned partial implementations.
>>
>> But since the XSF standards development is severely understaffed
>> I think raising these questions makes even less sense (actually
>> this is true for almost any XSF workflow nowadays because of this).
> 
> I don't see large numbers of specifications being abandoned as a
> problem. It is a trove of thought experiments, some with code to go with
> it, that might be of use later. Leaving them as Deferred doesn't costs
> us anything.

+1!

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

Re: [Standards] Confusing Language in XEP-0261 (Jingle In-Band Bytestreams Transport Method)

[Peter Saint-Andre]

On 1/12/19 1:01 PM, Jonas Schäfer wrote:
> On Montag, 17. Dezember 2018 16:50:17 CET Sebastian Riese wrote:
>> XEP-0261  uses "bytestream"
>> for the overall Jingle session and "session" for the IBB session (at
>> least it does so consistently). This is *extremely* confusing. For
>>
>> example section 2.5 reads:
>>> Whenever a party is finished with a particular session within the
>>
>> bytestream, it SHOULD send an IBB  as shown above. This applies
>> to all sessions, including the last one.
>>
>>> To close the bytestream itself (e.g., because the parties have
>>
>> finished using all sessions associated with the bytestream), a party
>> sends a Jingle session-terminate action as defined in XEP-0166.
>>
>> This nomenclature is just wrong: The Jingle session manages multiple
>> In-Band Bytestream sessions. If you close the Jingle session there may
>> be zero or more bytestream sessions that are closed (and perhaps other
>> transport sessions – Jingle does not prescribe uniform transports in a
>> session).
>>
>> If you all agree I would make a PR to fix this issue. My proposal is to
>> use "session" for Jingle sessions and "bytestream" for IBB sessions, if
>> this is deemed to be too confusing also, I could spell out "Jingle
>> session" and "IBB session".
> 
> I suggest you take the silence as agreement.

WFM



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Should we split XEP-0300 (Use of Cryptographic Hash Functions in XMPP) up?

[Peter Saint-Andre]

On 12/16/18 2:37 AM, Jonas Schäfer wrote:
> This may sound ridiculous at first, given that the text easily fits on less 
> than 10 pages in font size, but bear with me.
> 
> I was proposing an LC for it to Kevin, because the protocol IMO is rather 
> mature, but then I realized that we have a slight issue here:
> 
> - The protocol could probably even be put in Final right now, it seems very 
> "done" to me.
> - We can never put the required support of hash functions to Final.
> 
> So I suggest to split XEP-0300 into two parts:
> 
> 1. A Standards Track part which includes only the protocol.
> 2. An Informational part which includes only the hash function 
> recommendations, as well as the related XEPs section.

+1, although the hash function *recommendations* don't exactly feel
informational to me.

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX (XEP-0369) channel discovery

[Peter Saint-Andre]

On 9/25/18 10:58 AM, Steve Kille wrote:
> Ralph,
> 
> 
>> -Original Message-
>> From: Standards  On Behalf Of Ralph Meijer
>> Sent: 20 September 2018 08:43
>> To: XMPP Standards 
>> Subject: [Standards] MIX (XEP-0369) channel discovery
>>
>> Hi,
>>
>> Recently I have been looking at discovery of entities to determine what
> kind of
>> thing it is, knowing nothing more than its JID. The starting point is a
> client that
>> shows a list of entities, based on past conversations (MAM), ordered by
> last
>> interaction. Entities could be regular user accounts, bots, group chat
> rooms, etc.
>>
>> The core idea behind XEP-0030 (Service Discovery) is that given a JID, you
> can
>> find out what kind of entity it is, by sending a Disco Info request and
> getting one
>> or more identities in return. Additional information like supported
>> features/protocols, and meta-data as Disco Extension Data Forms
> (XEP-0128),
>> can be included there, too.
>>
>> Reading XEP-0369, section 6.3, on discovering channel information, I see
> that it
>> currently requires the node attribute to be set to 'mix'. From what I
> understand
>> this is to allow a particular JID to support both MUC and MIX, and have a
> way to
>> request the MIX specific information.
> [Steve Kille] 
> 
> Yes, this was the rationale (set out in 6.3).
> 
>>
>> The problem I have with this, is that it requires prior knowledge of a
> certain JID
>> (also) being a MIX channel. So you can't find out the identity (the thing
> that's
>> telling you what a JID is) without knowing what the thing is. I do
> understand this
>> works if you start out with discovering the MIX service first, but I don't
> believe
>> that should be the only entry point.
> [Steve Kille] 
> 
> Your logic for this extra entry point is spot on. I propose to remove
> the specification of node=mix, as you suggest.
> 
> I have checked over, and agree with you that there is no conflicting
> information.
> 
> 
> The consequence of this is that:
> 1.  A MIX client may see MUC information.   This should not be an issue
> 2.  A MUC client will see new MIX information.Is this going to cause any
> significant breakage?

It shouldn't cause breakage.

> I was specifically asked to make this node=mix change (I cannot remember by
> whom, but it was not something that I designed).   I could not find any
> notes or emails.   I'd like confirmation from my co-author before making
> this change.   
> 
> Can anyone else involved in early MIX discussions think back?This was
> put in for a reason, and I'd prefer not to break something by making this
> change.

The idea behind the 'node' attribute for an information request is to
"filter" on desired information for a particular feature supported by
the entity; the best example I know of is ad-hoc commands (XEP-0050),
where you might want to find more detailed information about a specific
command. Such a scenario does not apply in the case of MIX, as far as I
can see.

>> I don't see the need for explicitly asking for the MIX information (only).
> XEP-
>> 0030 and XEP-0128 support returning multiple identities as well as
> multiple
>> extension forms. So a Disco Info result, without node, could look like
> this:
>>
>> >  id='ik3vs715'
>>  to='hag66@shakespeare.example/UUID-c8y/1573'
>>  type='result'>
>>
>>  >  category='conference'
>>  name='A Dark Cave'
>>  type='mix'/>
>>  >  category='conference'
>>  name='A Dark Cave'
>>  type='text'/>
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>
>>  urn:xmpp:mix:core:0
>>
>>
>>  Witches Coven
>>
>>
>>  A location not far from the blasted heath where
>> the three witches meet
>>
>>  
>>  
>>
>>  http://jabber.org/protocol/muc#roominfo
>>
>>>   label='Description'>
>>  The place for all good witches!
>>
>>  
>>
>> 
>>
>> Note that I included the channel info from section 6.5 here. I was
> surprised to
>> find we aren't using XEP-0128 disco extensions instead of doing a pubsub
> items
>> request here. I /do/ see the value for having the pubsub node as way to
> get
>> notifications on changes, so having both would be even better. If you have
> to do
>> a Disco Info request anyway, it saves one request.
>>
>> Finally, section 12, on Registrar Considerations, doesn't mention the
> required
>> registration [1] of the identity conference/mix. Unfortunately one
> identity can
>> have at most one extension form, so reusing conference/text is probably
> not a
>> good idea.
>>
>> [1] https://xmpp.org/registrar/disco-categories.html#conference
> [Steve Kille] 
> 
> Good catch.   Need to put something in registrations section.I agree
> that conference/text is a bad idea.
> 
> Does anyone see any issues with  conference/mix  ?

Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items

[Peter Saint-Andre]

On 7/27/18 11:21 AM, Goffi wrote:
> Le vendredi 27 juillet 2018, 17:24:27 CEST Peter Saint-Andre a écrit :
>> On 7/27/18 8:03 AM, Goffi wrote:
>>> Hello,
>>>
>>> I'm currently working on OMEMO implementation in Salut à Toi thanks to
>>> the work of Syndace (https://github.com/Syndace/python-omemo), and I
>>> have two issues with it:
>>>
>>> - SàT is using xml:lang attribute, and I don't see a way to specify it
>>> with OMEMO, how should I do? What are business rules when several
>>> bodies are available (I know it's not common, but it's allowed by
>>> RFCs)?
>>
>> Could you describe in more detail what you're trying to accomplish?
>> Section 5.2.3 of RFC 6121 talks about xml:lang for message bodies, but
>> perhaps you need more information.
>>
>> Peter
> 
> An (animated) picture worth thousand words :)
> 
> https://repos.goffi.org/sat_docs/raw-file/tip/screenshots/0.7/
> language_filtering.gif
> 
> The experimental language detection put aside, I'm using xml:lang here to 
> display the language used, and this allow language filtering, which is 
> really useful in a multilingual room. This data can also be used to propose 
> translation, and probably other neat features.

https://xmpp.org/extensions/xep-0171.html might be of interest.

> With OMEMO I'm loosing the xml:lang (the  disappear), and I'm not 
> sure where I could put it (I think this information should be encrypted 
> too).

Hmm, I'm not sure how to solve that problem...

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] field report on authentication methods

[Peter Saint-Andre]

On 8/9/18 9:51 AM, Sam Whited wrote:
> This is great stuff, thanks Peter! I'd love it if we could use jabber.org 
> more; it's easy to forget that we have a great source of data about the 
> network at our fingertips.
> 
> Given how small the percentage of logins over CRAM-MD5 and XEP-0078 are, can 
> we disable those? Anything under 10% feels worth killing to me.

I'd be curious what cutoff percentages other services use, for instance
when stopping support for earlier versions of SSL or TLS. Less than 1%
for CRAM-MD5 seems fine (I don't even know what clients support that and
why), whereas 4% for XEP-0078 is a fairly large percentage. I'd want to
do further investigation regarding client versions before shutting off
4% of our users...

Peter



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0060: Affiliations vs. access models

[Peter Saint-Andre]

On 8/8/18 2:05 PM, Matthew Wild wrote:
> And another question... (for Ralph? :) )
> 
> There are some cases which are not clear regarding the permission model.
> 
> These two things contradict for example:
> 
> Table 1: "Affiliations and their Privileges" states that entities with
> affiliation "none" may not retrieve items.
> 
> Table 6: "Node Access Models" states that for "open" nodes (which it
> says SHOULD be the default), "any entity may retrieve items from the
> node".
> 
> Would it be fair to say that for an "open" node, an unaffiliated
> entity would have the same permissions as a "member" would on a more
> closed node?

Yes. Intuitively, it makes sense that on a more closed node (e.g., where
subscriptions need to be authorized), there is a difference between
"member" and "none". But that distinction doesn't apply to a node with
an open access model.

HTH,

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0163: support for "subscriber" affiliation

[Peter Saint-Andre]

On 8/8/18 1:11 PM, Matthew Wild wrote:
> This seems like a bug in the XEP, but I wanted to run it past the list
> before I submit a PR.
> 
> According to https://xmpp.org/extensions/xep-0163.html#defaults -
> 
> "
> A PEP service MUST:
> 
> [...]
> * Support the "owner" and "subscriber" affiliations.
> [...]
> "
> 
> However there is no "subscriber" affiliation defined in XEP-0060 (or
> XEP-0163). Therefore I think this should be removed.

XEP-0060 says:

   Support for the "owner" and "none" affiliations is REQUIRED.

A subscriber has an affiliation of "none", so it seems that XEP-0163
adds nothing beyond XEP-0060 in this regard. Thus the entire sentence
can be removed.

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0060: Item ordering

[Peter Saint-Andre]

On 8/8/18 3:17 AM, Philipp Hörist wrote:
> I always thought the most recent refers to the publish date/time of the
> item, hence if i override a item it also changes the updated time/date
> and it becomes the most recent

That seems reasonable. So it's really "last modified item". I'm curious
what Ralph thinks.

Peter

> 
> Regards
> Philipp
> 
> 2018-08-08 11:06 GMT+02:00 Matthew Wild  >:
> 
> The XEP is not very explicit about the order of items within a pubsub
> node. The closest it gets is referring to the ability to fetch "the
> most recent items".
> 
> Item IDs are unique, so publishing an item with an existing ID
> replaces the original item.
> 
> Is this new item "the last published item" (a term from the XEP), or
> does it sit in place of the item that originally had that ID?
> 
> 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
> ___
> 



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0060: pubsub#dataform_xslt (yes, but why?)

[Peter Saint-Andre]

[replying on-list]

On 8/7/18 12:37 PM, Jonas Wielicki wrote:
> On Dienstag, 7. August 2018 18:28:45 CEST you wrote:
>> On 8/5/18 4:59 AM, Jonas Wielicki wrote:
>>> Hi all,
>>>
>>> So while running the XEP-0060 node_config data form [1] through the thing
>>>
>>> which builds aioxmpp code to process it, I came across this funny field:
>>>   >>   
>>>  type='text-single'
>>>  label='The URL of an XSL transformation which can be
>>>  
>>> applied to the payload format in order to generate
>>> a valid Data Forms result that the client could
>>> display using a generic Data Forms rendering
>>> engine'/>
>>>
>>> I was at first confused, but then figured out that this is an XSLT which
>>> can be applied to the payload in the node items to extract a XEP-0004
>>> Data Form which is then renderable.
>>
>> It seems to be a data forms result, not a form one would fill out.
> 
> Ahh, that makes slightly more sense.
> 
>>> At least that’s what I think. There’s no text which
>>> describes its use in more detail.
>>
>>> So, I have a few questions:
>> A simpler question: is anyone using this feature?
>>
>> I doubt it, and I'd be inclined to remove it.
> 
> Me too.
> 
> However, even if we decide to keep it, and even if the XSLT is actually 
> supposed to be executed on the server side of things, the security issues of 
> that *very much* need to be documented.

I'm suggesting we delete the feature - most likely it was something we
thought might be useful someday, which turned to be false (leaving aside
the many security issues!).

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Council Minutes 2018-08-01

[Peter Saint-Andre]

On 8/6/18 9:53 AM, Dave Cridland wrote:
> 
> 
> On 6 August 2018 at 16:45, Kevin Smith  > wrote:
> 
> On 6 Aug 2018, at 16:25, Tedd Sterr  > wrote:
> > 
> > http://logs.xmpp.org/council/2018-08-01/#14:59:59
> 
> > 
> > 1) Roll Call
> > Present: Sam, Dave, Kev, Georg
> > Pursuing business interests in the Middle Kingdom: Daniel
> > 
> > 2) Agenda Bashing
> > No agenda changes; Georg liked it, but didn't put a ring on it.
> > 
> > 3a) PR #681 - XEP-0050: Remove the status attribute from the request - 
> https://github.com/xsf/xeps/pull/681
> 
> > Dave thinks this seems like a pretty straightforward case of fixing the 
> optional inclusion of an attribute that the receiver is mandated to ignore. 
> Kev thinks it was the result of a typo ('status' instead of 'action'), and 
> fixing the typo might be the better fix.
> > Sam wonders why there should be an optional attribute at all; Dave 
> suggests it makes more sense if it's restating a default. Sam thinks it 
> should still be required so it can be relied upon, otherwise it's cumbersome 
> to have to check whether it's the default value or if it exists; Dave 
> clarifies that if it's not the default value then it could be cancelling.
> > Dave asks Kev to make a comment noting the typo possibility [reply to 
> minutes?], to spur Dave into investigating in more detail (and maybe there's 
> an example that clarifies.)
> > Georg thinks Kev is right regarding the typo, but the PR is 
> self-consistent and also removes the typo.
> > 
> > Dave: +1
> > Sam: +1 (seems very sensible)
> > Georg: +1
> > Kev: [pending]
> 
> I’m pending being persuaded that the PR is right, rather than the
> original issue being a typo, BTW. -1 unless someone manages that (or
> similar).
> 
> 
> So after digging, I think Kev's right:
> 
> 1) The schema includes an optional "status" attribute, but it doesn't
> have "execute" as a possible value.
> 2) The schema does, however, include "action", which has the "execute"
> value.
> 3) §4.1 notes that "action" is only set by the requester, and further
> notes that "execute" is the default value.
> 4) All the examples are consistent with this being a typo - many
> requests include "action" set to "execute" whereas none contain a status
> attribute.

FWIW I agree with this analysis.

Peter



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0060: Inconsistency between SHIM registration and SHIM registry

[Peter Saint-Andre]

On 8/2/18 2:02 PM, Melvin Vermeeren wrote:
> Hi,
> 
> In XEP-0060, Publish-Subscribe, there appears to be an inconsistency 
> regarding 
> the SHIM registration and the current listing in the SHIM registry.
> 
> XEP-0060, in the examples, reads:
>> 
> 
> This is also consistent with the "SHIM Headers" section of the XEP:
> https://xmpp.org/extensions/xep-0060.html#registrar-shim
> 
> However, the SHIM registry lists it as "pubsub#subid" and not "SubID":
> https://xmpp.org/registrar/shim.html
> 
> The question is which of these is actually correct? When resolving this we 
> may 
> want to add a note since implementations can expect both "SubID" and 
> "pubsub#subid", unless I misunderstand the SHIM registry list.

I suspect this is a copy and paste error in the registry.

> The same applies to "Collection" and "pubsub#collection". I also note there 
> is 
> an entry in the registry for "pubsub#expire", but I cannot find anything 
> regarding this SHIM Header in XEP-0060. Am I missing something?

That also sounds like an error in the SHIM registry - IIRC that token is
used only in data forms, not SHIM.

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items

[Peter Saint-Andre]

On 7/27/18 8:03 AM, Goffi wrote:
> Hello,
> 
> I'm currently working on OMEMO implementation in Salut à Toi thanks to the 
> work of Syndace (https://github.com/Syndace/python-omemo), and I have two 
> issues with it:
> 
> - SàT is using xml:lang attribute, and I don't see a way to specify it with 
> OMEMO, how should I do? What are business rules when several bodies are 
> available (I know it's not common, but it's allowed by RFCs)?

Could you describe in more detail what you're trying to accomplish?
Section 5.2.3 of RFC 6121 talks about xml:lang for message bodies, but
perhaps you need more information.

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] message encryption session at IETF 102

[Peter Saint-Andre]

I see activity in the chatroom anyway.

Sent from mobile, might be terse 

> On Jul 19, 2018, at 7:39 AM, Peter Saint-Andre  wrote:
> 
> Hmm, that doesn’t sound right, let me check.
> 
> Sent from mobile, might be terse 
> 
>> On Jul 19, 2018, at 7:34 AM, Peter Waher  wrote:
>> 
>> Hello
>>  
>> Tried to join the IETF 102 meeting, but it said it has concluded. It is now 
>> July 19 (”tomorrow, as seen on the 18th”), 13:33 UTC. When is the next 
>> meeting?
>> 
>> Best regards,
>> Peter Waher
>>  
>> 
>> > Hi folks, the first meeting of the Messaging Layer Security working
>> > group will be held tomorrow at IETF 102 from 09:30 to 12:00 EDT (i.e.,
>> > starting at 13:30 UTC):
>> >
>> > https://datatracker.ietf.org/meeting/102/materials/agenda-102-mls-00
>> >
>> > Remote participation is available via the following links:
>> >
>> > * Chat room: xmpp:m...@jabber.ietf.org?join
>> >
>> > * Audio stream: http://ietf102streaming.dnsalias.net/ietf/ietf1028.m3u
>> >
>> > * Video conferencing: http://www.meetecho.com/ietf102/mls/
>> >
>> > Peter
>> 
>> ___
>> 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] message encryption session at IETF 102

[Peter Saint-Andre]

Hmm, that doesn’t sound right, let me check.

Sent from mobile, might be terse 

> On Jul 19, 2018, at 7:34 AM, Peter Waher  wrote:
> 
> Hello
>  
> Tried to join the IETF 102 meeting, but it said it has concluded. It is now 
> July 19 (”tomorrow, as seen on the 18th”), 13:33 UTC. When is the next 
> meeting?
> 
> Best regards,
> Peter Waher
>  
> 
> > Hi folks, the first meeting of the Messaging Layer Security working
> > group will be held tomorrow at IETF 102 from 09:30 to 12:00 EDT (i.e.,
> > starting at 13:30 UTC):
> >
> > https://datatracker.ietf.org/meeting/102/materials/agenda-102-mls-00
> >
> > Remote participation is available via the following links:
> >
> > * Chat room: xmpp:m...@jabber.ietf.org?join
> >
> > * Audio stream: http://ietf102streaming.dnsalias.net/ietf/ietf1028.m3u
> >
> > * Video conferencing: http://www.meetecho.com/ietf102/mls/
> >
> > Peter
> 
> ___
> 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
___

[Standards] message encryption session at IETF 102

[Peter Saint-Andre]

Hi folks, the first meeting of the Messaging Layer Security working
group will be held tomorrow at IETF 102 from 09:30 to 12:00 EDT (i.e.,
starting at 13:30 UTC):

https://datatracker.ietf.org/meeting/102/materials/agenda-102-mls-00

Remote participation is available via the following links:

* Chat room: xmpp:m...@jabber.ietf.org?join

* Audio stream: http://ietf102streaming.dnsalias.net/ietf/ietf1028.m3u

* Video conferencing: http://www.meetecho.com/ietf102/mls/

Peter



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Best practices for GDPR compliant deployment of XMPP

[Peter Saint-Andre]

On 5/25/18 2:00 AM, W. Martin Borgert wrote:
> On 2018-05-25 09:13, Winfried Tilanus wrote:
>> Beside that informative XEP, I (or a group of people willing to do so)
>> publish an own document discussing XMPP & the GDPR in detail.
> 
> Having XEPs explaining best practices for
> 
>  - retrieving all data belonging to one user
>  - removing all data of a particular user
>  - agreeing to terms of service and withdrawing again
>  - etc.
> 
> is certainly needed by many people in an outside the EU.
> It is not necessary to even mention GDPR in those XEPs.

+1 - that's what I'm suggesting, too.

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Best practices for GDPR compliant deployment of XMPP

[Peter Saint-Andre]

On 5/23/18 7:11 AM, Winfried Tilanus wrote:
> On 23-05-18 10:47, Kevin Smith wrote:
>>> It's also expressly not legal advice(!)
>> I’m not convinced that saying “this isn’t legal advice” while giving
>> advice on how to interpret/comply with law actually makes it so :)
> 
> Yeah, showing a picture of a pipe and saying "this is not a pipe" never
> works in court. That is why I put some other safety valves in there too,
> like 'this is general' and 'this topic is still subject to debate'.

We could recast the document as "privacy considerations for XMPP server
operators" and at relevant points informationally cite the GDPR (as the
most advanced regulation on the topic).

Peter





signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Best practices for GDPR compliant deployment of XMPP

[Peter Saint-Andre]

On 5/22/18 11:19 AM, Jonas Wielicki (XSF Editor) wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Best practices for GDPR compliant deployment of XMPP
> Abstract:
> This informational XEP provides information on deploying XMPP in way
> that is compliant with the General Data Protection Regulation (GDPR)
> of the European Union.
> 
> URL: https://xmpp.org/extensions/inbox/gdpr.html

Thanks to Winfried for putting this together; it will be a helpful
document once it's all filled in.

I do wonder how careful the XSF needs to be about making recommendations
that could be construed as legal advice (despite including all of the
appropriate provisos).

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Fwd: [new-work] WG Review: Messaging Layer Security (mls)

[Peter Saint-Andre]

Hi all,

Please take a look at the charter for this proposed IETF working group
and consider getting involved! The XMPP community's experience with
end-to-end encryption is extremely relevant here.

Peter


 Forwarded Message 
Subject: [new-work] WG Review: Messaging Layer Security (mls)
Date: Mon, 14 May 2018 07:04:18 -0700
From: The IESG 
To: new-w...@ietf.org

A new IETF WG has been proposed in the Security Area. The IESG has not made
any determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list (i...@ietf.org) by 2018-05-23.

Messaging Layer Security (mls)
---
Current status: Proposed WG

Chairs:
  Nick Sullivan 
  Sean Turner 

Assigned Area Director:
  Benjamin Kaduk 

Security Area Directors:
  Eric Rescorla 
  Benjamin Kaduk 

Mailing list:
  Address: m...@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/mls
  Archive: https://mailarchive.ietf.org/arch/browse/mls/

Group page: https://datatracker.ietf.org/group/mls/

Charter: https://datatracker.ietf.org/doc/charter-ietf-mls/

Several Internet applications have a need for group key establishment
and message protection protocols with the following properties:

o Message Confidentiality - Messages can only be read
  by members of the group
o Message Integrity and Authentication - Each message
  has been sent by an authenticated sender, and has
  not been tampered with
o Membership Authentication - Each participant can verify
  the set of members in the group
o Asynchronicity - Keys can be established without any
  two participants being online at the same time
o Forward secrecy - Full compromise of a node at a point
  in time does not reveal past messages sent within the group
o Post-compromise security - Full compromise of a node at a
  point in time does not reveal future messages sent within the group
o Scalability - Resource requirements have good scaling in the
  size of the group (preferably sub-linear)

Several widely-deployed applications have developed their own
protocols to meet these needs. While these protocols are similar,
no two are close enough to interoperate. As a result, each application
vendor has had to maintain their own protocol stack and independently
build trust in the quality of the protocol. The primary goal of this
working group is to develop a standard messaging security protocol
so that applications can share code, and so that there can be shared
validation of the protocol (as there has been with TLS 1.3).

It is not a goal of this group to enable interoperability/federation
between messaging applications beyond the key establishment,
authentication, and confidentiality services.  Full interoperability
would require alignment at many different layers beyond security,
e.g., standard message transport and application semantics.  The
focus of this work is to develop a messaging security layer that
different applications can adapt to their own needs.

While authentication is a key goal of this working group, it is not
the objective of this working group to develop new authentication
technologies.  Rather, the security protocol developed by this
group will provide a way to leverage existing authentication
technologies to associate identities with keys used in the protocol,
just as TLS does with X.509.

In developing this protocol, we will draw on lessons learned from
several prior message-oriented security protocols, in addition to
the proprietary messaging security protocols deployed within
existing applications:

o S/MIME - https://tools.ietf.org/html/rfc5751
o OpenPGP - https://tools.ietf.org/html/rfc4880
o Off the Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html
o Signal - https://signal.org/docs/

The intent of this working group is to follow the pattern of
TLS 1.3, with specification, implementation, and verification
proceeding in parallel.  By the time we arrive at RFC, we
hope to have several interoperable implementations as well
as a thorough security analysis.

The specifications developed by this working group will be
based on pre-standardization implementation and deployment
experience, generalizing the design described in:

o draft-omara-mls-architecture
o draft-barnes-mls-protocol

Note that consensus is required both for changes to the current
protocol mechanisms and retention of current mechanisms. In
particular, because something is in the initial document set does
not imply that there is consensus around the feature or around
how it is specified.

Milestones:

  May 2018 - Initial working group documents for architecture and key
  management

  Sep 2018 - Initial working group document adopted for message protection

  Jan 2019 - Submit architecture document to IESG as Informational

  Jun 2019 - 

Re: [Standards] Abolishing 'proposed' status for XEPs

[Peter Saint-Andre]

On 4/23/18 8:09 AM, Matthew Wild wrote:
> We have a number of XEPs stuck in 'proposed' with an expired Last Call.
> 
> I think the reality is that the council "rejected" these, or last call
> feedback is awaiting to be incorporated. By "rejected" I mean to imply
> that the council didn't want to advance the XEP yet (presumably based
> on LC feedback), but they did not want development on the XEP to
> discontinue.
> 
> However XEP-0001 doesn't specify a way back to 'Experimental' from
> 'Proposed', which is why I think our documented process is not being
> followed here.
> 
> I think we wither need to fix that process (by specifying Proposed ->
> Experimental), or... and this is what I think I personally prefer,
> remove the 'Proposed' status entirely (unless someone can state what
> purpose it serves).

+1 to removing Proposed.

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Council Minutes 2018-04-11

[Peter Saint-Andre]

On 4/12/18 5:47 PM, Tedd Sterr wrote:
>> But we might never know if someone is building an application or service
>> on top of a library...
> 
> Isn't this the point of the CFE - to find out?
> There is always the **possibility** that somebody somewhere could
> possibly maybe have implemented a given feature, but if nobody knows
> about it, do we just assume it does anyway? In which case, we can always
> assume there are enough implementations because there **might** be.
> 
> A CFE asks whether anyone has implemented the feature and what their
> experiences were (was it straightforward, well documented, any issues,
> etc.) While a library implementation could answer /_those_/ questions,
> questions of whether the feature is good in practice or what issues
> arise from its use can only really be answered by somebody using the
> library's implementation of said feature.

Sometimes the library developers know these things because of feature
requests they've received or questions they've answered, so it's worth
asking them. But you can't necessarily find this out first-hand from
those who are using the library. I'm just saying don't discount entirely
the fact that there are multiple library implementations.

Peter

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

Re: [Standards] XMPP Council Minutes 2018-04-11

[Peter Saint-Andre]

On 4/12/18 3:58 PM, Sam Whited wrote:
> On Thu, Apr 12, 2018, at 16:41, Christian Schudt wrote:
>> here some implementation for XEP 131 and 141 because you said „doesn’t 
>> have enough implementation“.
> 
> In general I think "implementations" is meant to read "clients or 
> applications", here. If something is implemented in a library (or several 
> libraries), but then never used in a real client or application then we still 
> can't really claim to have any experience with the protocol in a "real-world" 
> scenario. I'm not sure there's anything official saying this has to be the 
> case, but that's my take on what "implementations" means.

But we might never know if someone is building an application or service
on top of a library...

Peter

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

Re: [Standards] Error requesting own vcard

[Peter Saint-Andre]

On 3/23/18 3:48 PM, Matthew Wild wrote:
> On 23 March 2018 at 21:42, Kevin Smith  wrote:
>>> On 23 March 2018 at 21:15, Kevin Smith  wrote:
> 
>>> However the XEP explicitly states that they are semantically
>>> equivalent, so I guess it doesn't matter much either way.
>>
>> I don’t think that’s true, is it? The XEP says both are possible responses, 
>> but doesn’t say anything about when one should be chosen over the other, nor 
>> on their equivalence.
> 
> It's always worrying when standards discussions come down to analysing
> the structure of sentences :)
> 
> It says both cases apply to "If no vCard exists [...]". That is, both
> of the responses mean the same thing - the vcard does not exist.

That is my interpretation of the sentence. Why we defined things that
way, I cannot recall.

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Extension Editor

[Peter Saint-Andre]

On 3/20/18 1:30 AM, Jonas Wielicki wrote:
> Hi Ludovic,
> 
> On Montag, 19. März 2018 22:19:26 CET Ludovic BOCQUET wrote:
>> I have known the "XMPP Extention Editor" with edi...@xmpp.org email
>> address, but "recently" I have seen some editors with his personal email
>> address and with "XSF Editor" in sender name and without too.
> 
> Yes, this is true. The reason is that the editor emails are now sent from 
> private machines instead of the XSF servers. Thus we cannot really use 
> @xmpp.org addresses. I use the "Jonas Wielicki (XSF Editor)" alias when 
> sending such "automated" emails.
> 
>> I think that a lot of people have rules and search emails in inbox...
> 
> For this reason, all emails sent with the (new) editor tooling have several 
> headers which identify them as XEP announcements. I suggest to filter on the 
> presence of the XSF-XEP-Number header. 
> 
>> It will be good to have only one solution.
> 
> Hopefully, in addition to the headers, we can go back to sending emails from 
> editor@ at some point, at least for automatable announcements like XEP 
> updates.

We have never sent all messages from editor@ - only automated messages
generated by various Python scripts. The Call for Experience messages
and such were always sent from personal email accounts.

Peter






signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Extension Editor

[Peter Saint-Andre]

The editor@ address is just a mailman alias and there's no way to send
from it, so people acting in the editor role have always send from their
own email addresses. Naturally, that could be changed...

On 3/19/18 3:19 PM, Ludovic BOCQUET wrote:
> Hello all,
> 
> I have known the "XMPP Extention Editor" with edi...@xmpp.org email
> address, but "recently" I have seen some editors with his personal email
> address and with "XSF Editor" in sender name and without too.
> 
> I think that a lot of people have rules and search emails in inbox...
> 
> It will be good to have only one solution.
> 
> Thanks in advance.
> 
> Regards,
> 
> BOCQUET Ludovic
> 
> 
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
> 




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

[Peter Saint-Andre]

On 3/8/18 9:12 AM, Denver Gingerich wrote:
> On Thu, Mar 08, 2018 at 08:47:50AM -0700, Peter Saint-Andre wrote:
>> On 3/8/18 2:33 AM, Dave Cridland wrote:
>>> I'm aware of people experimenting with this on ad-hoc networks such as
>>> emergent vehicle networks.
>>
>> I heard about such things years ago, too. Are those active projects?
> 
> I can't speak for emergent vehicle projects, but ad-hoc networks are becoming 
> increasing popular for person to person communication given new hardware 
> technology (more on that below).  I suspect related XEP-0174 projects will 
> soon be quite active.
> 
>>> While I agree that it's probably flaky as hell in practise, I think it
>>> remains our best shot at this.
>>
>> Do *we* need to take a shot at this?
>>
>> What scenarios are we or other folks trying to solve for these days?
>>
>> The original use case was ad-hoc 1:1 chat at conferences and local
>> networks not connected to the wider Internet. While that was interesting
>> 12 years ago, is it interesting now? Is there some other interesting
>> problem that serverless messaging can solve?
> 
> I believe "local networks not connected to the wider Internet" are definitely 
> still interesting, perhaps even more interesting today than before.

The XEP-0174 use case was originally for people connected to the same
WiFi hotspot or other link-local network. The technology was driven
forward by Apple (remember when Bonjour was called Rendezvous?) and
hasn't received much attention since they stopped featuring it in iChat.

> There are a number of new devices that allow people to create their own 
> networks when away from an Internet connection.  In particular, see 
> https://www.sonnetlabs.com/ and similar projects.  Sonnet creates an IP 
> network with other Sonnets within a few kilometres - this would be a great 
> place to be able communicate via XMPP without a server, i.e. using mobile 
> XMPP clients on wifi-connected phones.
> 
> Similar devices include https://gotenna.com/pages/mesh - goTenna does not 
> create an IP network like Sonnet, but instead uses its own proprietary 
> protocols over the air and with connected Bluetooth devices.  I suspect we'd 
> be able to go far beyond goTenna's capabilities by using XMPP with a less 
> proprietary device like Sonnet.

Yes, I'm familiar with such technologies, having worked on peer-to-peer,
end-to-end encrypted, long-range radio communication devices for IoT (no
longer my current project). There are significant challenges involved in
building such things - battery life, power consumption, sleepy nodes,
firmware size, OTA updates (!), bandwidth limitations (our devices
operated at ~900 MHz), eliminating a dependency on centralized towers
(LoRaWAN, LTE-M, etc.), strong security including use a secure enclave
and a proper manufacturing process to bootstrap trust (hardware is
hard), protecting privacy over a radio frequency transport through
techniques like channel hopping and seemingly random time schedules,
etc. I am not convinced that XMPP is the right approach for such
applications. Something like Apache Mynewt might a more appropriate
foundation (it's being driven forward by some of the original technical
minds behind Silver Spring Networks), but even then there's a lot of
work required to build a true mesh protocol in a private and secure way
(e.g., the native LoRaWAN security is not strong and that architecture
depends on towers anyway).

> It is the long-term goal of the Soprani.ca family of projects that I'm 
> working on (which includes https://jmp.chat/ among others) to build and/or 
> integrate a device like Sonnet into existing phones so that we can replace 
> some of the cell network functionality with something that gives people a bit 
> more freedom.  See https://wiki.soprani.ca/ThePlan#Long-range_radios (where 
> we explicitly call out XEP-0174 as a way of doing this) for more details.

Those are great aspirations. However, I am skeptical that XMPP meets the
design goals in this space.

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___