[Standards] Many older XEPs being deferred

[Sam Whited]

I plan on deferring the following XEPs later today. You can of course
undefer them by making a contribution or submitting your favorite XEP
for Last Call. If you notice anything that looks amiss, please let an
editor know by replying to this email.

Because there are so many, I do not plan on sending further notification
emails to avoid spamming this list. If you would like to discuss future
work or advancing any particular XEP in the list, please create a new
thread for discussion.

- XEP-0327: Rayo
- XEP-0329: File Information Sharing
- XEP-0332: HTTP over XMPP transport
- XEP-0337: Event Logging over XMPP
- XEP-0338: Jingle Grouping Framework
- XEP-0339: Source-Specific Media Attributes in Jingle
- XEP-0340: COnferences with LIghtweight BRIdging (COLIBRI)
- XEP-0341: Rayo CPA
- XEP-0342: Rayo Fax
- XEP-0343: Signaling WebRTC datachannels in Jingle
- XEP-0344: Impact of TLS and DNSSEC on Dialback
- XEP-0345: Form of Membership Applications
- XEP-0346: Form Discovery and Publishing
- XEP-0347: Internet of Things - Discovery
- XEP-0348: Signing Forms
- XEP-0349: Rayo Clustering
- XEP-0350: Data Forms Geolocation Element
- XEP-0351: Recipient Server Side Notifications Filtering
- XEP-0353: Jingle Message Initiation
- XEP-0354: Customizable Message Routing
- XEP-0355: Namespace Delegation
- XEP-0356: Priviledged Entity
- XEP-0357: Push Notifications
- XEP-0358: Publishing Available Jingle Sessions
- XEP-0360: Nonzas (are not Stanzas)
- XEP-0361: Zero Handshake Server to Server Protocol
- XEP-0362: Raft over XMPP
- XEP-0365: Server to Server communication over STANAG 5066 ARQ
- XEP-0367: Message Attaching
- XEP-0370: Jingle HTTP Transport Method
- XEP-0371: Jingle ICE Transport Method
- XEP-0372: References
- XEP-0373: OpenPGP for XMPP
- XEP-0376: Pubsub Account Management
- XEP-0377: Spam Reporting
- XEP-0378: OTR Discovery

—Sam

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

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

[Guus der Kinderen]

As an Openfire developer, I can tell you that we find the naming "legacy"
for "direct SSL" unfortunate. We're planning to rename that. Direct SSL. I
happened to create an issue for that in our tracker yesterday:
https://issues.igniterealtime.org/projects/OF/issues/OF-1378

On 23 September 2017 at 14:58, 殷啟聰 | Kai-Chung Yan 
wrote:

> According to the documentations of some XMPP servers (e.g. OpenFire and
> ejabberd), using TLS directly when connecting is described as "legacy",
> "deprecated" or "not recommended". Is this "legacy" connection method the
> same as the one described in this XEP? If so, is this XEP also encouraging
> direct TLS unlike those servers?
>
>
> Guus der Kinderen 於 2017年09月23日 02:08 寫道:
>
>
> Wait, what are we discussing again?
>>
>>
> We were discussing if I was fully, or completely right, of course. :-P
>
> Also, I again have to postpone my bikeshed-warming-party. It's not
> finished yet. Will let you know.
>
>
> ___
> 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] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Jonas Wielicki]

On Samstag, 23. September 2017 20:58:08 CEST 殷啟聰 | Kai-Chung Yan wrote:
> According to the documentations of some XMPP servers (e.g. OpenFire and
> ejabberd), using TLS directly when connecting is described as "legacy",
> "deprecated" or "not recommended". Is this "legacy" connection method the
> same as the one described in this XEP? If so, is this XEP also encouraging
> direct TLS unlike those servers?

It is described as "legacy" etc. because back in the days there was the move 
to STARTTLS as specified in RFC6120. There’s no mention of direct TLS 
connection in RFC6120. (Correct me if I’m wrong :-).)

However, XEP-0368 introduces a mechanism to properly discover direct TLS 
connections (via SRV records). It doesn’t force to use a specific port (which 
is often an argument against direct TLS).

So, in part, yes, this is the "legacy" method those servers support. Make sure 
they support SNI on the direct TLS port.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[殷啟聰 | Kai-Chung Yan]

According to the documentations of some XMPP servers (e.g. OpenFire and 
ejabberd), using TLS directly when connecting is described as "legacy", 
"deprecated" or "not recommended". Is this "legacy" connection method the same 
as the one described in this XEP? If so, is this XEP also encouraging direct 
TLS unlike those servers?

Guus der Kinderen 於 2017年09月23日 02:08 寫道:
>
> Wait, what are we discussing again?
>
>
> We were discussing if I was fully, or completely right, of course. :-P
>
> Also, I again have to postpone my bikeshed-warming-party. It's not finished 
> yet. Will let you know.
>
>
> ___
> 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] UPDATED: XEP-0359 (Unique and Stable Stanza IDs)

[Florian Schmaus]

On 23.09.2017 10:13, Jonas Wielicki wrote:
> On Freitag, 22. September 2017 17:48:44 CEST Georg Lukas wrote:
>> Hi,
>>
>> the vast number of different IDs can make a developer dizzy. Can we
>> please specify in 0359 that an entity adding an  MUST (or at
>> least SHOULD) set the message-id value of the message to the same ID as
>> the ?
>>
>> It was asked why  would be needed at all then, but when a
>> client is processing incoming messages, it does help to know if the
>> sender was generating strong UUIDs
> 
> How does that help?
> 
>> , and the receiver does not always
>> have access to the sender's entity caps (MUC with MSN, offline
>> messages).
>>
>> This would add a little bit of consistency in a place where we can't go
>> back in time and fix the original design.
> 
> I don’t see a reason against that. Keep in mind that @id rewriting MUCs will 
> lead to inconsistency though, so clients MUST be able to deal with that ... .

I think I don't understand the benefits from Georg's suggestion, so
currently one reason against is that it adds more complexity without any
gain from my PoV.

Plus what you said: The scheme will break as soon as the MUC service, or
any other service doing some sort of reflection, rewrites the 'id'
attribute of the stanza (which MUC services are allowed to, and are the
reason for xep359 existence in the first place).

- Florian



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-0359: make the by attr optional on origin IDs (#516)

[Florian Schmaus]

On 23.09.2017 10:20, Jonas Wielicki wrote:
> On Freitag, 22. September 2017 17:51:43 CEST Sam Whited wrote:
>>> I implicitly assumed that the value of the 'by' attribute of origin-id
>>> is
>>> just the same as the value of the 'from' attribute of the stanza. I know
>>> that this is not true with MUC reflection and semi-anonymous rooms.
>>
>> This was the use case I had in mind; I want to know who set the ID, not
>> necessarily who sent me the message.
> 
> Can you elaborate a use-case for this?
> 
> All I see is a potential privacy issue when clients set the @by in an 
> anonymous MUC, since it leaks their address to the whole room.

This. I also think this change only introduces the possibility of an
information leak.

If you have a semi-anonymous room, then you don't want to put the 'by'
attribute in . If you have a non-anonymous room then you can
get the value of the 'by' attribute by looking up the senders real JID.

This is likely true for most, if not all, other uses cases where you
have some sort of reflection and  involved: Either you are
able to determine the real JID of sender, or the sender doesn't want you
too.

- Florian



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-0359: make the by attr optional on origin IDs (#516)

[Jonas Wielicki]

On Freitag, 22. September 2017 17:51:43 CEST Sam Whited wrote:
> > I implicitly assumed that the value of the 'by' attribute of origin-id
> > is
> > just the same as the value of the 'from' attribute of the stanza. I know
> > that this is not true with MUC reflection and semi-anonymous rooms.
> 
> This was the use case I had in mind; I want to know who set the ID, not
> necessarily who sent me the message.

Can you elaborate a use-case for this?

All I see is a potential privacy issue when clients set the @by in an 
anonymous MUC, since it leaks their address to the whole room.

kind regards,
Jonas



signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0359: make the by attr optional on origin IDs (#516)

[Jonas Wielicki]

There was some discussion on the xeps repository an XEP-0359, which got
technical. I moved this discussion to standards@ so that the whole
community is aware of the issue and can participate.

For your convenience, the technical parts of the discussion have been copied 
below. The full conversation and the changes can be viewed at 
:


On Freitag, 22. September 2017 17:21:59 CEST Florian Schmaus wrote:
> I implicitly assumed that the value of the 'by' attribute of origin-id is
> just the same as the value of the 'from' attribute of the stanza. I know
> that this is not true with MUC reflection and semi-anonymous rooms. But I
> never thought of this of a problem. Could you elaborate on the motivation
> for this change?

On Freitag, 22. September 2017 17:51:43 CEST Sam Whited wrote:
> > I implicitly assumed that the value of the 'by' attribute of origin-id is
> > just the same as the value of the 'from' attribute of the stanza. I know
> > that this is not true with MUC reflection and semi-anonymous rooms.
> This was the use case I had in mind; I want to know who set the ID, not
> necessarily who sent me the message.

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] UPDATED: XEP-0359 (Unique and Stable Stanza IDs)

[Jonas Wielicki]

On Freitag, 22. September 2017 17:48:44 CEST Georg Lukas wrote:
> Hi,
> 
> the vast number of different IDs can make a developer dizzy. Can we
> please specify in 0359 that an entity adding an  MUST (or at
> least SHOULD) set the message-id value of the message to the same ID as
> the ?
> 
> It was asked why  would be needed at all then, but when a
> client is processing incoming messages, it does help to know if the
> sender was generating strong UUIDs

How does that help?

> , and the receiver does not always
> have access to the sender's entity caps (MUC with MSN, offline
> messages).
> 
> This would add a little bit of consistency in a place where we can't go
> back in time and fix the original design.

I don’t see a reason against that. Keep in mind that @id rewriting MUCs will 
lead to inconsistency though, so clients MUST be able to deal with that ... .

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___