Re: [Standards] XEP-0384: Staleness of devices

[Jonas Wielicki]

Note, I’m not familiar with OMEMO and it’s ratchet system, so take this with a 
grain of salt.

On Dienstag, 28. August 2018 13:26:51 CEST Paul Schaub wrote:
> Another countermeasure against stale devices is sending empty
> ratchet-forward messages on a regular basis. Those messages do have the
> same format as KeyTransportMessages [3], in that they do not contain a
> body. Their purpose is to forward the ratchet without user interaction.
> The downside is, that a device has to do this on its own, so this is not
> a good defense against attackers devices.

Would it be possible for devices which exist and are used by a user, but not 
for sending (for whatever reasons) to auto-reply with an empty message with 
e.g. a probability of 1/10 or whatever to each message? This would allow 
advancement of the ratchet (If I Understand This Correctly) without user 
interaction and it puts the burden on the device which still wants to receive 
messages (i.e. if an attacker chooses to not send these messages, they’re 
hurting themselves).

But yeah, I have no idea about OMEMO. Just throwing stuff in.

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] XMPP Council Agenda 2018-08-08

[Jonas Wielicki]

On Dienstag, 7. August 2018 19:38:36 CEST Dave Cridland wrote:
> 3) Items for voting:
> 
> [None!]

Uh. I’d like to mention:

- https://github.com/xsf/xeps/pull/693
- https://github.com/xsf/xeps/pull/692
- https://github.com/xsf/xeps/pull/690

Those have been added since the last meeting. While I acknowledge that they 
may be editorial, I’d at least like to have an opinion from a Council member 
on those. For some it could also be that what is being removed is actually 
supposed to be there (like in the XEP-0050 situation, where a typo was 
corrected for the wrong reasons).

kind regards & thanks,
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] XMPP Council Minutes 2018-08-01

[Jonas Wielicki]

On Montag, 6. August 2018 17:25:57 CEST Tedd Sterr wrote:
> 3d) Proposed XMPP Extension: Schrödinger's Chat -
> https://xmpp.org/extensions/inbox/muc-selfping.html

Georg has submitted an update for the ProtoXEP which I merged today. You can 
find the updated version at the same address.

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
___

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

[Jonas Wielicki]

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:

  

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. At least that’s what I think. There’s no text which 
describes its use in more detail.

So, I have a few questions:

1. So this looks as if we recommend clients to download a piece of code in a 
turing-complete language, execute it on random content and then render the 
result as a Data Form without mentioning that in the Security Considerations. 
Do we *really* want that?

2. Do we know of a use-case for that which warrants to have this in XEP-0060 
itself as opposed to separate extensions? 

  - It seems to me that it is a very bad idea for clients to obtain a XSLT and 
execute it on data and then show the form to the user just because a message 
looks like a pubsub payload. 

  - Given that, a client which would contemplate applying the XSLT would 
already have to be familiar with the broad type of pubsub payload it is seeing 
(because it won’t do that for arbitrary pubsub payloads, of course).

  - Given that, it is likely that some type of PubSub based protocol is 
involved. It would make sense to simply specify in that protocol how to derive 
the Data Form instead of making the clients vulnerable to remote code 
execution.


If the answer to the first question is "no", I propose that we add a section 
to the security considerations which goes over the following issues:

- Don’t execute XSLT from untrusted sources
- Mention that just because a payload looks like a familiar protocol, the 
sender could still be malicious; so the "trust" check needs to happen based on 
the @from and possibly the publisher.
- Mention that the @from/publisher can be spoofed by the pubsub service and 
the users own server.

If the answer to both questions is "no", I suggest to simply drop this field 
out of the form, and/or if that is too harsh for Draft, modify the label/
description to actively discourage its use and implementation (i.e. Deprecate/
Obsolete this part of the XEP, just like we did with XEP-0071 (XHTML-IM)).


Note, there is another field (pubsub#body_xslt) which has similar issues, but 
is supposed to execute on the pubsub service instead of the client. I think 
the text motivates its existence to a certain degree, but at least the 
security considerations need to be mentioned.


kind regards,
Jonas

   [1]: https://xmpp.org/extensions/xep-0060.html#registrar-formtypes-config

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-0060: "entity element" should be "subscription element"

[Jonas Wielicki]

On Freitag, 27. Juli 2018 18:09:35 CEST Melvin Vermeeren wrote:
> I am not yet familiar with sending patches for XEPs. Could someone either
> make the change or give me some directions? Thanks.

There are basically two ways to do this, as Ralph already told:

1. By opening a pull request against https://github.com/xsf/xeps/pulls

2. By sending an email with a patch to edi...@xmpp.org. In this case, make 
sure to include the XEP ID (e.g. in this case "XEP-0060") to facilitate 
sorting (otherwise, your mail might get lost).

In both cases, please be aware of the Intellectual Property Rights policy of 
the XSF [1]; you need to agree to it in order for your patch to be applied. 
You can do so via GitHub (you will be prompted when opening a Pull Request) or 
by including a statement in your email to editor@.

kind regards,
Jonas (XEP Editor)

P.S.: I slightly prefer pull requests against the xeps repository for 
convenience reasons, but if you’re not a GitHub type of person, email to 
editor@ is fine.

   [1]: https://xmpp.org/about/xsf/ipr-policy.html

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-0384] OMEMO: xml:lang + max_items

[Jonas Wielicki]

On Freitag, 27. Juli 2018 17:07:52 CEST Philipp Hörist wrote:
> > but instead limit their queries to the newest item.
> 
> They cant, because thats an optional feature of the Server.

They could still execute the limit on the client side.

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-0384] OMEMO: xml:lang + max_items

[Jonas Wielicki]

On Freitag, 27. Juli 2018 16:41:57 CEST Philipp Hörist wrote:
> I think this is a good addition to the XEP, although i fear this would be a
> namespace bump, but from practical experience every PEP impl sends only the
> last item, so this is until now a  academic problem

This wouldn’t be a namespace bump in my reading of the rules, since setting or 
not setting the item ID does not pose an interoperability issue:

* A new item which is pushed will always be the newest item irrespectively on 
whether it replaced an existing item or not.

* Since the ID wasn’t fixed before, no implementation will be asking for this 
specific ID. We have to write down that implementations SHOULD NOT rely on 
this ID for queries, but instead limit their queries to the newest item.

* No implementation should be relying on getting a history of OMEMO public 
keys, since many PEP implementations do or did not support this.

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] UPDATED: XEP-0198 (Stream Management)

[Jonas Wielicki]

On Mittwoch, 25. Juli 2018 15:44:02 CEST Guus der Kinderen wrote:
> Changelog date is off by a year, I think?

Well spotted. Will fix.

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] Proposed XMPP Extension: File Sharing Notifications

[Jonas Wielicki]

On Montag, 23. Juli 2018 16:26:45 CEST Ненахов Андрей wrote:
> сб, 21 июл. 2018 г. в 1:46, Tedd Sterr :
> > > I'd rather call it 'extended chat state notifications' or something
> > > like that. Recording audio is only distantly related to file sharing.
> > 
> > "Media Stream Activity Notifications (MSAN)", then.
> > 
> > But it's good that we're putting so much effort into arguing over the
> > important details, rather than trivial things like the actual protocol.
> Actual protocol is rather trivial. It took us a grand few hours to
> implement all required functionality with attribute and kinda within
> existing XEP-0085. Would not take much longer to make it like it's
> purposed here. However, I do somewhat object to adding yet another
> XEP, especially with misleading names. 

Feel free to suggest a better name. Naming is hard and easy at the same time.

> This creates barriers for
> developers and requires more bureaucracy work (some people like doing
> bureaucracy work, though). Maybe updating 'final' standard in a
> non-breaking way is a lesser evil than adding more and more XEPs.

See, I understand this, but there’s a trade-off to find here.

I personally find that lean, short, self-contained XEPs are preferrable over a 
single huge XEP. This is for two reasons:

- It promotes separation of concerns on the protocol level, which helps to 
bring that even into the software, which is nice for modularity and thus, in 
the end, code quality.

- It makes the individual documents easier to digest and reason about.

(Of course, "short" is very dependent on the subject matter.)


Now, I understand that having gazillions of XEPs also has its own downsides. 
However, I think that those downsides can be mitigated easier than the 
downsides of a single huge XEP. The downsides are (in my view):

- It is unclear to developers which XEPs are important to implement.

- A large number of documents makes it seem much more intimidating than a 
single large documentation which describes, e.g., a REST API.

We need to work on mitigating those downsides, but this is independent of the 
question whether we want to modify Final XEPs and allow feature creep in 
existing XEPs or not -- because we will eventually end up with a considerable 
number of XEPs (some would argue we’re there already). However, I think that 
issue is out-of-scope for this XEP.


In addition to this, having a point where a standards document becomes -- 
aside from editorial fixes -- immutable is very beneficial, because it allows 
implementations to rely on this exact behaviour. It is certain that it won’t 
change and that other implementations which may implement an older version 
will eventually converge to this state.

Modifying a Final document breaks all those guarantees. As a client developer, 
I find those guarantees appealing.

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] Proposed XMPP Extension: File Sharing Notifications

[Jonas Wielicki]

On Mittwoch, 18. Juli 2018 17:34:08 CEST Jonas Wielicki wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.

Again, the ProtoXEP has been updated. Available under the same URL.

> Title: File Sharing Notifications
> Abstract:
> This specification provides a notification protocol for information
> about ongoing file uploads and media creation by the user.
> 
> URL: https://xmpp.org/extensions/inbox/fsn.html
> 
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___



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] Proposed XMPP Extension: File Sharing Notifications

[Jonas Wielicki]

On Donnerstag, 19. Juli 2018 15:28:20 CEST Jonas Wielicki wrote:
> On Mittwoch, 18. Juli 2018 17:34:08 CEST Jonas Wielicki wrote:
> > URL: https://xmpp.org/extensions/inbox/fsn.html

A few more remarks. I’d normally against giving non-critical feedback in 
ProtoXEP stage, but given that the Council is on vacation next week, it makes 
may sense to sort out the rough edges now.


A requirements section is very much needed. "Requirements" is meant as in 
"What is required of the protocol?" and not as in "Dependencies". So here 
you’d probably have something like:

> * Convey upload state
> * Distinguish media types
> * Convey recording state
> * Signal cancelling of uploads
> * Allow co-existence with XEP-0085
> * Define recommended rules for interop with XEP-0085

Just with fancier words :).


Looking at the first table: I suggest to use the same definition of types for 
both uploading and recording. Animation may not make sense (and we can 
discourage use with SHOULD NOT) for recording, but having the same set of 
values for both seems better to me.

Especially since an audio recording is not necessarily a voice recording (if a 
client chooses to present it if it was, that’s fine; it doesn’t need to be 
reflected on the protocol level.)


In the Business Rules I think you meant "When sending a  or 
 notification […]" (instead of ``composing``)).

I’m also not sure forcing ``paused`` here makes sense. If the upload failed, 
the user may not be actively looking at the screen and thus a ``paused`` state 
may be confusing to the recipient. If the user aborted the upload, they may 
have decided to not share anything after all.

In both cases, going back to ``active`` or ``inactive`` (whichever is true) 
seems more appropriate to me.


Remove the "Of course" from the third paragraph and replace it with a MUST. I 
would suggest to not force  state, because the user might not be 
actively engaged in the conversation or even with the device at the time the 
upload finishes. Use whatever XEP-0085 state is appropriate.


I think this section can use some structural improvement. How’s this? (I also 
changed the rules a bit, see below):

> When a sending client chooses to map FSNs to XEP-0085, it MUST follow the 
> following rules:
> 
> - As long as no upload or creation is in progress, the normal XEP-0085 
>   states are sent.
> - During creation, a client MUST send  state (overriding the
>   state which would normally be sent with XEP-0085 logic).
> - During upload and while the user is active, a client SHOULD continue to 
>   send the  state (overriding the state which would normally be 
>   sent with XEP-0085 logic).
> - During upload and while the user is inactive, a client SHOULD send 
>instead of .
> - After the upload finishes or is aborted, the normal XEP-0085 logic takes
>   over. Normally, this will put the conversation into  or 
>state (but if the user still has input pending, it may also
>   be ).
>
> A client MAY choose not to apply this mapping if it allows text input while 
> creating or uploading media, to allow transmitting normal XEP-0085 states
> for the text input.
> 
> If a client allows a user to pick media which are already created (thus 
> skipping the  state), it MAY treat interaction with the media 
> selection like text input in XEP-0085 (i.e. send  while the user
> is actively engaging with it and switch to  if inactive for a 
> certain time).

Changes:

- Make it clear that after the upload is over, normal XEP-0085 rules take over 
(instead of forcing any XEP-0085 state).
- Use MUST for creating and SHOULD for uploading; I think for uploading we’ll 
have to see how this actually looks and feels to users, especially with long 
uploads (maybe it would be nice to only show  in the last 
(approximately) 10 seconds of an upload?)
- Add rules for clients which allow text input while uploading.
- Add rules for states while picking a file.


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] Proposed XMPP Extension: File Sharing Notifications

[Jonas Wielicki]

On Mittwoch, 18. Juli 2018 17:34:08 CEST Jonas Wielicki wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.

The proposal has been updated. The new version (0.2.0) is available under the 
same address as before.

> Title: File Sharing Notifications
> Abstract:
> This specification provides a notification protocol for information
> about ongoing file uploads and media creation by the user.
> 
> URL: https://xmpp.org/extensions/inbox/fsn.html
> 
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___



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] Proposed XMPP Extension: File Sharing Notifications

[Jonas Wielicki]

On Mittwoch, 18. Juli 2018 17:34:08 CEST Jonas Wielicki wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: File Sharing Notifications
> Abstract:
> This specification provides a notification protocol for information
> about ongoing file uploads and media creation by the user.
> 
> URL: https://xmpp.org/extensions/inbox/fsn.html
> 
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.

I like the intent of this XEP. I think it can be improved by loosening the 
coupling between XEP-0085 and this one.

I suggest to focus on the new functionality provided by this XEP in the Use 
Cases section and add another (sub-)section which describes *suggested* 
XEP-0085 states which MAY be sent alongside of the states described by this 
XEP. This helps untangle the reading a bit and having the "compatibility" part 
in a single place makes it easier to reason about (side-)effects of this.


Also, RECOMMENDED is equivalent to SHOULD, OPTIONAL is equivalent to MAY. The 
statement

> However, adding chat states is RECOMMENDED, but OPTIONAL.

is thus contradictory.


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] File sharing states for XEP-0085: Chat State Notifications

[Jonas Wielicki]

On Dienstag, 17. Juli 2018 16:07:28 CEST Linus Jahn wrote:
> On Tue, 17 Jul 2018 15:36:06 +0200, Jonas Wielicki  
wrote:
> > Yes. Not tying this to  seems like a good idea for
> > flexibility. My suggestion would be to put your new elements next to
> > the existing XEP-0085 elements, not as children of them. E.g.:
> > 
> > 
> > 
> >   
> >>   
> > type='image'
> > progress='0.4'/>
> > 
> > 
> 
> Makes sense. +1
> 
> > @progress would be optional and give the upload progress from 0 to 1.
> > @type would indicate what’s being uploaded (although I’m not 100%
> > sure if that makes sense to have). The valid values for @type should
> > be enumerated; it might make sense to allow use of MIME types here.
> 
> I was thinking about just using an integer from 0-99 for the progress.

There’s no reason to restrict to integer here. Using 0..1 as range is more 
pure mathematically speaking (you can just divide the number of bytes sent by 
the total number of bytes to obtain this, no need to multiply with 100). This 
just as a rationale for my suggestion.

> > > Apart from that, there should be states for uploading media files
> > > and states for the creation of the media files (user is recording
> > > audio/video or taking a picture).
> > 
> > I’m not sure what the use-case for this would be in general.
> 
> As Paul wrote Telegram and I think even Whatsapp use this to display
> something as "recording a voice message" or "recording a video".
> Additionally I would add a state for "taking a photo", when the user
> takes a photo via. the client (mobile clients often have the
> possibility to "take a photo").

Right.

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] File sharing states for XEP-0085: Chat State Notifications

[Jonas Wielicki]

On Dienstag, 17. Juli 2018 15:09:16 CEST Linus Jahn wrote:
> Hello Matthew and Ненахов,
> thank you for your answers.
> 
> On Mon, 16 Jul 2018 13:59:23, Matthew Wild  wrote:
> > Authoring a new XEP for this case would not be hard. Take a look at
> > https://xmpp.org/about/standards-process.html for details about
> > getting started.
> 
> Thanks, I'll do that.
> 
> On Mon, 16 Jul 2018 14:12:11, Ненахов Андрей 
 wrote:
> > Actually, we've recently a 'type' attribute in development Xabber
> > for Web build so we can display messages like 'recording an audio
> > message', 'recording video message', 'uploading file'. Works ok,
> > third-party clients just see it as simple 'typing'.
> 
> I think in the XSF MUC they agreed on that it's a bad idea to add
> attributes to another namespace, so I'll use a subelement.
> 
> While thinking a bit about the new XEP, I came to the conclusion that
> the uploading information could also be added to other states than
> . For example in  to indicate that the user has
> aborted the upload. It should even be possible for , because
> the client can continue to upload while the user is doing something
> else.

Yes. Not tying this to  seems like a good idea for flexibility. My 
suggestion would be to put your new elements next to the existing XEP-0085 
elements, not as children of them. E.g.:


  
  


@progress would be optional and give the upload progress from 0 to 1. @type 
would indicate what’s being uploaded (although I’m not 100% sure if that makes 
sense to have). The valid values for @type should be enumerated; it might make 
sense to allow use of MIME types here.

> Apart from that, there should be states for uploading media files and
> states for the creation of the media files (user is recording
> audio/video or taking a picture).

I’m not sure what the use-case for this would be in general. 

> The third point I thought about was if the uploading progress should
> also be transmitted. I think this can be useful in situations where
> the upload takes very long, so the chat partner can at least estimate
> if the file will be there in a few seconds or it will still take an
> hour. The progress should probably not updated more often than once a
> second.

See above :-).


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-0045: How to signal tombstones for destroyed rooms?

[Jonas Wielicki]

On Mittwoch, 11. Juli 2018 04:02:23 CEST Kim Alvefur wrote:
> Hello list,
> 
> I have implemented tombstones for destroyed MUC rooms. My reading of the
> sacred texts did not give me enlightenment as how to inform someone
> who's attempting to enter the remains of such a place. I've so far opted
> to return an  with the same  child
> that was in the inital announcement of the rooms destruction.
> 
> Of the clients I’ve tested so far, only Gajim seems to understand this.
> Swift says something unspecific about failure to enter the room, while
> Pidgin and poezio say nothing.
> 
> So basically, this is the reply one gets to a MUC join:
> 
> ``` xml
>  from="a@gc.localhost/n"> http://jabber.org/protocol/muc#user;>
> 
> You see only a crater.
>   
> 
> 
> ```
> 
> Does this make sense?

Is there a reason to not use a presence type="error"? I’d expect clients to 
handle those already. 

I’d use a  type error, which encodes the semantics perfectly.  
also allows for permanent redirects (which I think  does, too).

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] XMPP Council Minutes 2018-06-20

[Jonas Wielicki]

On Samstag, 23. Juni 2018 13:28:54 CEST Tedd Sterr wrote:
> Contrary to vicious rumours floating around, I have no interest in
> supplanting Dave's position as Chair. With only a few hours remaining and
> no agenda forthcoming, I thought a meeting with some agenda would be better
> than with none - and the agenda is largely straightforward.

FWIW, since I was one of those (if there even were multiple) who made a joke 
about that, I want to make sure it’s received as a joke, too.

It’s good that someone picks up the work when Dave (the chair) is massively 
busy, I like your minutes & agenda a lot :-).

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] XMPP Council Minutes 2018-06-06

[Jonas Wielicki]

First of all, thanks to Georg for making Sam clarify his position, which I 
misread similarly. Thanks to Sam for clarifying, this makes *much* more sense 
now. I think you two rehashes the key parts. I’d like to chime in as a 
developer who recently implemented support for the MUC voice request flow in a 
client library and as the author of the proposed change.


On Dienstag, 12. Juni 2018 20:34:26 CEST Sam Whited wrote:
> On Tue, Jun 12, 2018, at 13:19, Georg Lukas wrote:
> > The complexity isn't added by this change (except for adding another
> > element to disco#info), it is there already. Clients don't have a way to
> > check for this feature right now, so they need to implement whatever
> > workaround the authors come up with. Therefore, we are just better
> > documenting the situation (Maybe somebody can even provide a
> > recommendation for how to handle this uncertainity, which would be a
> > good addition at this place).
> > …
> > Except that now the author is explicitly made aware of the situation,
> > instead of stumbling into a  situation reported by a
> > small subset of their users.
> 
> Documenting seems like the thing to do here then; especially if whatever
> workarounds people are using right now could be a part of this
> documentation.

Okay. I don’t actually know how a MUC implementation behaves when the voice 
request flow is used without support. I heard that you get a  
back for trying to send a (non-groupchat) message to the bare MUC JID. This 
might be worth documenting after investigating whether this is true.

I am still in favour of a disco#info feature. I would personally make my 
client depend on that disco#info feature. Full stop. I think the voice request 
flow is used rarely enough (if at all) to allow it being not available unless 
the server explicitly announces support.


> > Maybe the right next step would be to get rid of the invitation flow
> > completely instead?

I assume that Georg meant the "voice request", not the "invitation" flow.

> I wouldn't mind this, I don't like all of MUCs complicated IRC-like
> features. Unfortunately, I suspect  that we can't at this point. I'd be
> curious to know how the community and other council members feel about this
> idea.

I would be totally fine with cutting out the voice request flow out of '45 
into a separate XEP, or dropping it altogether. It is a weird bit of protocol 
which, even with the disco#info feature, is not reliable: the MUC service has 
no way to know that any of the moderators will be able to handle the voice 
request form. So even *if* the service announces that feature, the client will 
have to provide a UX flow which makes it clear that the voice request may be 
handled in +infty time (i.e.: not at all, because no moderator supports that 
feature). This makes it pretty useless / prone to extremely horrible UX. I 
think this may be one of the things which work in a closed system (like 
Ephemeral Messages), but don’t make too much sense in generic IM clients.


I only realized this after making the pull request, and I fully understand if 
Council rejected the suggestion based on this argument and suggests to remove 
the voice request flow altogether (possibly by cutting it out into a 
Historical XEP).


kind regards & thanks all,
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] Business rules of Last Message Correction

[Jonas Wielicki]

On Montag, 11. Juni 2018 18:29:50 CEST Tedd Sterr wrote:
> Upon receiving an RMC message, an LMC client would check whether the ID
> matches its last message and see that it doesn't -- the first business rule
> suggests that means it is a correction to a message directed to another
> resource, and so this client would quietly eat the message (because the
> correction is for another resource.)

This wouldn’t be an issue if clients use sufficiently unique IDs.

Also funny is by the way the question what counts as "Message" in this 
context. If I send a message and my client sends a CSN afterwards (because I 
switched to another tab maybe) and then I do a correction, is the CSN (which 
comes in its own ) a new message, which should be prohibiting me 
from correcting my last actual text message?

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] NEW: XEP-0409 (IM Routing-NG)

[Jonas Wielicki]

So here comes my feedback to this.

> URL: https://xmpp.org/extensions/xep-0409.html


First of all, I like how this worked out. I think the compatibility between 
IM-NG and non-IM-NG realms is well-addressed. Kevin really did some good work 
distilling the lengthy discussion we had in the weeks around summit about this 
topic to a good base specification.


Section 3.3:

> When an entity wants to send a non-error message to be received exclusively 
> by a single resource, they include an  
> element in the message. An IM-NG server receiving this MUST then send it to 
> only the specified resource, if available, or respond with an error 
> consistent with RFC-6121 ("return an error stanza to the sender, which 
> SHOULD be ").

Is there a specific reason why a client which has enabled IM-NG needs to 
include the  element? I’d prefer if the server would tack it on any 
full-JID-addressed message it receives from the client (just like it stamps 
over the @from). Simple clients and so on.


On a similar point in Section 4:

> An IM-NG client SHOULD ignore any IM-related messages that are sent to a 
> full-JID with an  element (see Security 
> Considerations).

This could be a SHOULD for servers too. Prevents sending them to clients in 
the first place. Servers could even reject them with  or 
something similar to give feedback.


Again Section 4:

> In order for interoperability with other entities (contacts, remote servers 
> etc.) that don't support IM-NG, old-style full-JID messages also need to be 
> handled. When a server receives a message with type other than than 
> 'groupchat' or 'headline' that does not contain an  xmlns='urn:xmpp:im-ng:0'> element it is to be routed by the above rules as 
> if they were sent to the bare JID

Is there any reason to not also re-write the message to look as if it came 
from IM-NG? I.e. make the destination JID bare. 


More section 4:

> Any message of normal type, or type 'chat', 'groupchat' or 'headline' sent 
> to a bare JID is distributed to all IM-NG clients (error messages sent to 
> the bare JID are in response to server-generated stanzas, and so are not 
> routed to clients).

I would suggest to simplify the wording here, to something along the lines of:

| Any message which is not of type 'error' sent to a bare JID is distributed
| to all IM-NG clients. Messages of type 'error' sent to a bare JID are in
| response to messages sent by the service and so are not routed to clients.

Two reasons:

- I think this is much easier to read -- with the original version, I first 
had to look up if this covers all message types or not.

- RFC 6121 defines that unknown message types are to be treated like 'normal', 
so if we ever extend message types, this provides defined behaviour in that 
case which is in line with RFC 6121 (I am only a bit serious with this reason; 
the first one is the important one).


More section 4:

> When reflecting an IM-NG client's outbound bare-JID messages, the server 
> SHOULD reflect the archived version (i.e. after any transforms have taken 
> place).

This is a good start. I would suggest to amend it with:

| Specifically, if MAM is supported, the server MUST include the archive 
|  on the reflected message.


---


And I also put some minute-style notes from discussion which took place in 
xsf@:

Archiving Chat State Notifications: As per the current rules, chat states are 
archived (because they’re not headline and not groupchat (typically)). Georg 
mentions that this is a problem because of the high load on databases this 
causes.

Kevin mentions three independent solutions:

- Chat State Notifications should move into , as discussed at 
summit. I raised the point that we might need to look carefully at the uses of 
directed presence and how things (e.g. MUC, Invisible Command and possibly 
others) interact with clients sending directed presence all the time. (It 
would be directed presence because you’d send the CSN to the contact/chat/room 
whom it concerns.)

- We could specify a  hint which would work roughly like  except that:

  - It is specified in IM-NG.
  - Servers MUST NOT archive anything with 
  - Clients MUST ignore/reject anything with  which is not 
supposed to be transient. I.e. if they receive any stanza with any
payload where the specification doesn’t say that it should be 
transient, the client drops it. The effect of that is that the client
behaves as if it had been offline when the stanza was received
(since it’s not going to be archived). This prevents an attacker from
maliciously making stanzas not archived while still being shown to the
user.
  - CSN would become such a use-case where  is mandatory on
the stanzas.

- We requisition type='headline' messages for this purpose. Kevin thinks that 
this might be even more dangerous than the other two options (but doesn’t 
elaborate).

I think we should do the second thing ( in IM-NG) in any case, 
because it seems simple enough to 

Re: [Standards] XMPP Council Minutes 2018-05-30

[Jonas Wielicki]

On Mittwoch, 6. Juni 2018 18:42:47 CEST Dave Cridland wrote:
> I really don't want to have any IQ based flows prior to login if possible -
> with my server-dev hat on, I find it worrying to have to do deep inspection
> of IQ stanzas during pre-auth.

With my client hat on, I agree 100%.

But SASL2 can only solve this to a certain extent, because of pre-registration 
things. We can of course have three different flows (Ad-Hoc, SASL2, and IBR) 
using a similar wire format (where possible).

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] Proposed XMPP Extension: Ephemeral Messages

[Jonas Wielicki]

On Mittwoch, 6. Juni 2018 13:13:23 CEST Marcel Waldvogel wrote:
> I understand that time synchronization is important, but I would
> recommend not to burden XMPP with timer synchronization. We do have a
> reliable NTP infrastructure including pool.ntp.org; mobile devices
> often have the capability to synchronize to other time sources (mobile
> phone infrastructure, GPS, …); etc.

Sorry, I fail to see how this spec does anything close to NTP. I might have 
missed it.

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] XMPP Council Minutes 2018-05-30

[Jonas Wielicki]

On Mittwoch, 6. Juni 2018 16:52:27 CEST Sam Whited wrote:
> I'm not af an of how this one was done. -1 for now. I'd like to discuss how
> this can be done better though; it seems to me that it would fit very well
> as part of extensible IBR and/or SASL2.

I agree that IBR or SASL2 or whatever integration is needed, but restricting 
it to that is not sufficient. I planned to add this post-acceptance. (I don’t 
want to open the "Develop things in Experimental vs. in ProtoXEP state" box 
now.)

Here’s why I think only IBR/SASL2/other-pre-auth-things is not sufficient:

1. Long-living sessions need to be notifiable. You could of course kill the 
connection, have it re-authenticate, show the user the info box, and hope they 
read it in time for stream management resumption to work, but I don’t believe 
that to be a good flow. I’d like to avoid blocking clients on authentication 
until absolutely necessary (i.e. deadline for agreement reached). Until then, 
a way to notifiy users about changes and a way for them to acknowledge those 
changes (and give agreement to whatever necessary/wanted) seems useful.

2. This kind of doubles as kind of privacy settings, and I agree that this 
might be feature creep and we might want to split this off. I find it logical 
to combine those two things though. Especially in GDPR-land a service might 
want to offer their opt-in things next to the terms of service so that users 
don’t have to dig for them. In non-GDPR-land where there may exist mandatory 
opt-in things, it makes sense to have them right next to the ToS in the 
client. For non-mandatory opt-in things, it makes sense to be able to change 
them even when a ToS change is not around the corner, so having an IQ/Ad-Hoc 
flow for that makes sense.


I see that the IQ-based pre-auth flow is an issue, and integrating this in 
SASL2 or something is probably the better way to handle this. However, this 
also needs to work pre- or during IBR in some way.

I am hesitant to base anything on SASL2 with the current state of deployment 
there.


I also accept the criticism I got from other folks (Kev I think, but don’t 
quote me on that) that the Ad-Hoc workflow looks out of place. I’ll work on 
that, but first I want to be on the same page with you, Sam, because I don’t 
want to waste more time on a spec which will be -1'd.


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] XMPP Council Agenda 2018-06-06

[Jonas Wielicki]

Hi Dave,

you seem to have missed:

https://github.com/xsf/xeps/pull/653 which Needs Council and has been open for 
a few days.

Can this be appended to AOB or the main Agenda?

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] NEW: XEP-0409 (IM Routing-NG)

[Jonas Wielicki]

On Dienstag, 5. Juni 2018 11:26:46 CEST Jonas Wielicki wrote:
> Version 0.1.0 of XEP-0409 (IM Routing-NG) has been released.
> 
> Abstract:
> This specification provides a new set of routing rules for modern
> instant messaging.
> 
> Changelog:
> Accepted by vote of Council on 2018-04-11. (XEP Editor (jwi))

Sorry for the delay on this one. There was a vote pending on list and I missed 
the expiry.

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] Addressing for IQs in MIX-CORE

[Jonas Wielicki]

On Montag, 4. Juni 2018 15:37:00 CEST Kevin Smith wrote:
> On 4 Jun 2018, at 12:15, Dave Cridland  wrote:
> >> On 4 June 2018 at 11:37, Steve Kille  wrote:
> >> 
> >> To support IQs in MIX-CORE, there needs to be an addressing  and routing
> >> scheme.
> >> 
> >> I am proposing that this uses a different scheme to messages from the
> >> channel (this is Kev's variant 4).
> >> 
> >> The rationale for having a different scheme is that you want to be able
> >> to
> >> distinguish from a stanza that comes from the channel, from a stanza 
> >> (IQ)
> >> that is relayed by the channel.
> > 
> > I think that's a false dichotomy. 
> 
> I think calling out the language here might be a fair call (although I don’t
> find it too confusing), but I think the underlying dichotomy is still
> there. Some stanzas are sent in the context of fanout to potentially all
> participants, and some are sent to be distributed in private to a single
> participant.
> >> A message distributed by the channel would come from:
> >> channel@domain/stable-participant-id
> >> 
> >> Bare JID is the channel, reflecting that the message comes from the
> >> channel.>> 
> >> An IQ message being relayed by the channel would come from:
> >> stable-participant-id#channel@domain/resource
> >> 
> >> Bare JID reflects the sender, which will enable the receiver to clearly
> >> distinguish that this is not coming from the channel.
> >> 
> >> We want to use this scheme for PMs (MIX-ANON), and here the difference
> >> becomes more important.   You want to clearly distinguish messages from
> >> the
> >> channel from PMs, and this approach gives a framework to achieve this.
> > 
> > So type='groupchat' is no longer enough?
> 
> Yes, that’s surprising isn’t it?
> 
> I came to this realisation a couple of days ago, not just that it’s no
> longer enough, but that it never was really adequate and definitely not
> ideal. A few reasons:
> 
> * Elsewhere in XMPP, the ‘to’ alone is used to determine which entity
> receives a stanza (I’m terminating entities at the user, not each of their
> devices, for these purposes). That here the difference between sending to a
> whole group of people and a single person is predicated not on the address,
> but the message type, is cause for us to think twice. * I have seen
> multiple bugs from people who are not XMPP-naive in this area, because it’s
> very easy to slip when the to no longer gives you addressing (including
> security issues). This makes it easy to shoot yourself in the foot. * Even
> where it doesn’t end up in a bug, I’ve seen bad UX resulting from this. *
> Querying a MAM archive becomes ‘interesting’ when you want to query just
> room messages, or just PMs with a particular occupant
> 
> there are others, but this is a reasonable flavour, I think.
> 
> Now, one might assert that it’s not worth changing this in MUC, but in MIX
> where we have the chance to avoid all these issues it seems worth giving
> serious thought to alternatives.

I think this is a good point, and I’ve run into this quite a few times when 
implementing MUC. Branching on the message type where 'groupchat' is somehow 
special, but then again only if it does *not* come from the bare JID, and if 
it *does* come from the bare JID, you may be confused (but that happens, in 
fact). And non-groupchat messages from the bare JID have a different semantics 
than non-groupchat messages from the occupant JID (I’m only talking about MUC 
here). This is weird, and I think if MIX does away with that, that would not 
be too bad.


A random side note: I found another argument against the variant where the 
client resource is encoded together with the participant id in the resource: 
The client resource is -- in contrast to the channel name and participant id 
-- not under control of the MIX service. A client resource can be very long 
(although it probably isn’t right now), and that would break things. Combining 
the participant ID and channel name in the nodepart allows the MIX channel to 
control both parts to always fit in a nodepart (restricting the length of the 
channel name most likely).


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] Another proposal - Handling JIDs for MIX-CORE, MIX-PRESENCE and MIX-PAM

[Jonas Wielicki]

On Sonntag, 3. Juni 2018 01:33:12 CEST Steve Kille wrote:
> Sam's message made me realize that none of the variant 1/2/3/4 stuff is
> needed for MIX-CORE.There are some things that might be needed in
> MIX-ANON, but let's worry about these in the MIX-ANON spec and keep them out
> of MIX-CORE.
> 
> In MIX-CORE, messages/presence go to a channel or are distributed by a
> channel.  There is no participant to participant (PM style) communications.

This makes sense.

> I suggest.
> 
> 1.  Messages come from the channel  (channel@domain).   This is what is
> happening as the channel is distributing messages.  Inside each message you
> have a mandatory sender information: (Nick and Bare JID).   There would be
> an elegance to putting this information into the JID, but I do not think it
> is practical and it does not gain you anything.

This sounds great.

> 2.  Presence come from the channel  (channel@domain).   This reflects that
> the channel is distributing presence.  Inside each presence stanza you have
> a mandatory sender information: (Nick and Full JID).

I’m not 100% happy with that, because this breaks with the usual semantics of 
 a lot. I’m not sure if at that point, handling presence via PubSub 
wouldn’t be better.


> That is it.   Very simple.   No variant JID addressing.  There are some
> issues for MIX-ANON, but lets worry about these in MIX-ANON, and not make
> the core more complex than it needs to be.

I like this.


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] Another proposal - Handling JIDs for MIX-CORE, MIX-PRESENCE and MIX-PAM

[Jonas Wielicki]

On Sonntag, 3. Juni 2018 09:29:13 CEST Daniel Gultsch wrote:
> 2018-06-03 1:33 GMT+02:00 Steve Kille :
> > (Nick and Bare JID).
> 
> I’m just on my way home from a very productive and interesting meetup
> with designers and artists. And without knowledge of the current MIX
> debate - just by analyzing the way Conversations currently implements
> group chats / MUC - people very quickly challenged the need for having
> per room nicks. And the very few arguments I was able to make in
> defense of having nicks in groups chats are only valid for anonymous
> groups.
> 
> Just wanting to put this out there…

This is also a good point. Maybe we want to move nicknames to MIX-ANON (or 
maybe another extension), too. The display name could be drawn from the 
roster, the vcard, XEP-0172, or similar.

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] MIX Addressing

[Jonas Wielicki]

On Freitag, 1. Juni 2018 09:21:45 CEST Kevin Smith wrote:
> On 31 May 2018, at 20:12, Jonas Wielicki  wrote:
> > On Donnerstag, 31. Mai 2018 13:45:06 CEST Kevin Smith wrote:
> >> We’ve had some discussions recently about whether presence should come
> >> from
> >> the channel’s JID, the user’s proxy JID, or be encoded in pubsub.
> >> Similarly
> >> whether messages should be coming from the channel’s JID or the user’s
> >> proxy JID. I think the argument that things should come from the user’s
> >> in-channel JID rather than the channel’s is reasonable - this is also
> >> what
> >> happens already in MUC and is familiar.
> >> 
> >> The reason for the proxy JIDs is that we need a stable identifier for the
> >> user in the channel, and we need it to be addressable per client. In MUC
> >> we
> >> don’t have this, we have room@server/nick, which is not stable for the
> >> user, which makes several things unpleasant, nor is it unique for a
> >> client
> >> (no resource), which makes routing (e.g. iq, which has to be to go to a
> >> unique client) and other issues annoying.
> >> 
> >> This means that we want a routable address that encodes up to four pieces
> >> of information:
> >> 
> >> The channel’s domain
> >> The channel’s identifier (I don’t want to use ‘name’, because that’s
> >> confusing - I mean the bit that in MUC would be the node of the JID). The
> >> user’s stable identifier
> >> A thing representing a resource of the user (Although not necessarily the
> >> exact resource they’re using)
> >> 
> >> I shall call these ‘domain’, ‘channel’, ‘user’, ‘resource’ respectively,
> >> because I’m tremendously creative.
> >> 
> >> The current approach is to have a unique ‘proxy JID’ per user:
> >> user#channel@domain
> >> and this in turn can have resources hanging off it as
> >> user#channel@domain/resource1, etc.
> >> 
> >> This is not the most elegant thing in the world (and some people have
> >> objected to having proxy JIDs at all), and has implications for e.g.
> >> servers that block messages from anyone that isn’t in your roster or
> >> receiving directed presence.
> >> 
> >> We could alternatively encode it as
> >> channel@domain/user and channel@domain/user/resource (Note carefully that
> >> user is *not* nick, so this doesn’t fall into the issues of MUC
> >> stability,
> >> and it allows encoding resources, so doesn’t fall into the MUC issues of
> >> routing).
> >> 
> >> Then there are no more proxy JIDs, everything is hanging off
> >> channel@domain, much like people are familiar with from MUC but without
> >> (as far as I can see at the moment) those issues of conflating nick with
> >> both user and client identity.
> >> 
> >> I think if we want routability we need to choose one of these two things:
> >> 
> >> 1) Stick with proxy JIDs and user%channel@domain[/resource] (or similar),
> >> with the resource missed off for bare-JID traffic, where
> >> ‘user%channel@domain’ as the proxy JID is the user’s identifier used
> >> everywhere. 2) Drop proxy JIDs, use channel@domain/user[/resource] and
> >> then
> >> ‘user’ is just a string identifier for the user, of whatever format (as
> >> long as it doesn’t contain ‘/‘).
> >> 
> >> What are people’s thoughts here?Are there any advantages of (1) over (2),
> >> or vice versa?
> > 
> > I very much prefer the semantics of (1). The reason is that about
> > everywhere (except MUC) you can assume that equal bare JID implies equal
> > identity.
> Ah, but it’s more complicated than that.
> 
> In most of XMPP you have the concept that identity (of the sender) = routing
> (of a reply) = context (e.g. the chat window in your client, or the entity
> you need queries for in your MAM archive). If you receive a normal 1:1 chat
> message, the from on the stanza (less the resource) shows you the identity
> of the sender (it’s just them), the routing to reply to them (it’s just
> them) and the context of the messages (the chat with that person). With MUC
> or MIX you now have this changed.
> 
> For MUC currently:
> Identity of the sender: full JID (although this is broken, as we know, by
> the conflating of identity/nick etc. in MUC) Routing of a reply (type=gc):
> bare JID
> Routing of a reply (type=chat, sent through channel): full JID
> Context (type=gc): bare JID
> Context (type=chat, sent through the 

Re: [Standards] MIX Addressing

[Jonas Wielicki]

On Freitag, 1. Juni 2018 09:29:15 CEST Kevin Smith wrote:
> > So here’s a straw-man proposal, Variant 3 (because, creating many variants
> > is what we’re good at!):
> > 
> > An occupant is identified by an occupant-identifier. The occupant JID is
> > occupant-identifier@mix-service. The channel to which a message belongs is
> > 
> > identified with a payload item. Example message:
> >   >  
> >   from="4973d5d365f8@mixservice.domain.example/client-resource"
> >   to="user@other.example">
> >
> >
> >...
> >  
> >  
> > 
> > Advantages:
> > 
> > - No re-write of resources needed (good for MIXes)
> > - Bare JID refers to occupant identity (good for clients)
> > - Servers can simply filter on message/mix/@channel (not perfect, but
> > better than requiring a new JID processing function)
> > - Opens up the possibility of re-using the same proxy JID for the same
> > occupant across different channels (may be useful in some deployments, via
> > MattJ)
> > - No non-RFC6122-based operations required on JIDs.
> > 
> > Disadvantages:
> > 
> > - All (including 1:1) stanzas exchanged between occupants require the  > channel="…"/> element for MIX channels to be able to easily route them
> > - Entities filtering on MIX channel identity still need to know about MIX
> > (and the  element)
> > - The namespace of MIX channel JIDs and occupant JIDs needs to be
> > separated in some way. This can be achieved with a single bit, so a
> > forced prefix on occupant JIDs (and a forbidden prefix on channel JIDs),
> > such as "%", would work for that. (I’m not sure if we would have to
> > standardize the method by which services do this split.)
> > 
> > 
> > What do you folks think?
> 
> I don’t want to go as far as saying I hate it, but I certainly don’t like
> it, I think it’s the worst of the three (now four) options. It completely
> removes all context from the header, and you have to go snooping inside
> every packet to work out where it’s really from (

> because for almost all
> processing concerns it’s the channel that’s regarded as the sender, not the
> originator

See, here’s where I disagree. In the client, the only processing which is 
based on the channel is the first fanout to distribute it to the right 
conversation window. Everything afterwards is very much concerned with the 
occupant identity. I think that this is the discrepancy between server and 
client concerns I was talking about.

> ). Now your archive will be completely broken without quite
> excessive DPI on the MAM server, 

This is a good point (selecting MAM from a MIX channel is now hard). I didn’t 
consider this because my MAM workflow is a "sync everything" one, so I 
wouldn’t care. However, I know that this isn’t the only workflow and a way to 
select messages from a MIX channel is important.

How would that work with Variant 1?


> and your client’s internal routing is no
> longer straightforwardly hierarchical based on the from.

That would only be the case with Variant 2 anyways. I see the appeal of 
hierarchical routing, but I’m not quite ready to let go of "equal bare JID 
implies equal identity". This has been one of the things I looked forward to 
most in MIX (as a client developer).


> You’re also
> opening the door to fun types of exploits (as now you’ve got an entity
> saying “My routing information says I’m coming from X, but really I’m from
> Y, honest” and you need protection against this throughout the system.

Also very good point against Variant 3.


> I appreciate trying to come up with better solutions than 1/2 (neither of
> which is ideal) and the space is complicated, but in this case I very much
> don’t think this is the best option.


I tend to agree.

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] MIX Addressing

[Jonas Wielicki]

On Donnerstag, 31. Mai 2018 13:45:06 CEST Kevin Smith wrote:
> 1) Stick with proxy JIDs and user%channel@domain[/resource] (or similar),
> with the resource missed off for bare-JID traffic, where
> ‘user%channel@domain’ as the proxy JID is the user’s identifier used
> everywhere.
> 2) Drop proxy JIDs, use channel@domain/user[/resource] and then
> ‘user’ is just a string identifier for the user, of whatever format (as
> long as it doesn’t contain ‘/‘).

While discussing about both options in xsf@ with MattJ, we realized that both 
approaches have the same issue, but in a different part of the JID: 
Information about identities is merged in a part of the JID. 

Different infrastructure components will have different issues with this:

- Servers might want to block a MIX channel from sending stuff to the user, so 
they want to know the MIX identity a message is coming from. For this, Variant 
2 is more convenient (bare JID == Channel).

- Clients might want to operate on occupant identities (as I mentioned 
elsewhere), and for this Variant 1 is more convenient (bare JID == Occupant).

In both variants, one component will have to deal with special-casing MIX JIDs 
in places which normally would not have to know about MIX. The bad thing here 
is that a non-RFC6122 operation on JIDs is needed, which are otherwise fairly 
well defined. This also has implications with respect to length limits in the 
different parts of the JID. In variant 2, the server would have to Address-
Translate the users resource to prevent the resourcepart from exceeding limits 
in edge cases. In variant 1, the MIX channel identifier would be restricted by 
the length of user identifiers on the service.


So here’s a straw-man proposal, Variant 3 (because, creating many variants is 
what we’re good at!):

An occupant is identified by an occupant-identifier. The occupant JID is 
occupant-identifier@mix-service. The channel to which a message belongs is 
identified with a payload item. Example message:

  

...
  

Advantages:

- No re-write of resources needed (good for MIXes)
- Bare JID refers to occupant identity (good for clients)
- Servers can simply filter on message/mix/@channel (not perfect, but better 
than requiring a new JID processing function)
- Opens up the possibility of re-using the same proxy JID for the same 
occupant across different channels (may be useful in some deployments, via 
MattJ)
- No non-RFC6122-based operations required on JIDs.

Disadvantages:

- All (including 1:1) stanzas exchanged between occupants require the  element for MIX channels to be able to easily route them
- Entities filtering on MIX channel identity still need to know about MIX (and 
the  element)
- The namespace of MIX channel JIDs and occupant JIDs needs to be separated in 
some way. This can be achieved with a single bit, so a forced prefix on 
occupant JIDs (and a forbidden prefix on channel JIDs), such as "%", would 
work for that. (I’m not sure if we would have to standardize the method by 
which services do this split.)


What do you folks think?

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] MIX Addressing

[Jonas Wielicki]

On Donnerstag, 31. Mai 2018 13:45:06 CEST Kevin Smith wrote:
> We’ve had some discussions recently about whether presence should come from
> the channel’s JID, the user’s proxy JID, or be encoded in pubsub. Similarly
> whether messages should be coming from the channel’s JID or the user’s
> proxy JID. I think the argument that things should come from the user’s
> in-channel JID rather than the channel’s is reasonable - this is also what
> happens already in MUC and is familiar.
> 
> The reason for the proxy JIDs is that we need a stable identifier for the
> user in the channel, and we need it to be addressable per client. In MUC we
> don’t have this, we have room@server/nick, which is not stable for the
> user, which makes several things unpleasant, nor is it unique for a client
> (no resource), which makes routing (e.g. iq, which has to be to go to a
> unique client) and other issues annoying.
> 
> This means that we want a routable address that encodes up to four pieces of
> information:
> 
> The channel’s domain
> The channel’s identifier (I don’t want to use ‘name’, because that’s
> confusing - I mean the bit that in MUC would be the node of the JID). The
> user’s stable identifier
> A thing representing a resource of the user (Although not necessarily the
> exact resource they’re using)
> 
> I shall call these ‘domain’, ‘channel’, ‘user’, ‘resource’ respectively,
> because I’m tremendously creative.
> 
> The current approach is to have a unique ‘proxy JID’ per user:
> user#channel@domain
> and this in turn can have resources hanging off it as
> user#channel@domain/resource1, etc.
> 
> This is not the most elegant thing in the world (and some people have
> objected to having proxy JIDs at all), and has implications for e.g.
> servers that block messages from anyone that isn’t in your roster or
> receiving directed presence.
> 
> We could alternatively encode it as
> channel@domain/user and channel@domain/user/resource (Note carefully that
> user is *not* nick, so this doesn’t fall into the issues of MUC stability,
> and it allows encoding resources, so doesn’t fall into the MUC issues of
> routing).
> 
> Then there are no more proxy JIDs, everything is hanging off channel@domain,
> much like people are familiar with from MUC but without (as far as I can
> see at the moment) those issues of conflating nick with both user and
> client identity.
> 
> I think if we want routability we need to choose one of these two things:
> 
> 1) Stick with proxy JIDs and user%channel@domain[/resource] (or similar),
> with the resource missed off for bare-JID traffic, where
> ‘user%channel@domain’ as the proxy JID is the user’s identifier used
> everywhere. 2) Drop proxy JIDs, use channel@domain/user[/resource] and then
> ‘user’ is just a string identifier for the user, of whatever format (as
> long as it doesn’t contain ‘/‘).
> 
> What are people’s thoughts here?Are there any advantages of (1) over (2), or
> vice versa?

I very much prefer the semantics of (1). The reason is that about everywhere 
(except MUC) you can assume that equal bare JID implies equal identity. I 
would very much like to have that in MIX. This is one of the issues with 
overloading the resource.

The variant (1) will still require to do parsing of the node part to determine 
which MIX a message is from, which is also not ideal. However, the 
distribution of messages to different (local) MIX endpoints (read: 
conversation windows) needs to be done anyways and can be done in a central 
place.

On the other hand, working with JIDs as means to compare identities is spread 
throughout all the code (think: using JIDs as cache keys e.g. for avatars).

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] Taking a Machete to MIX

[Jonas Wielicki]

On Montag, 21. Mai 2018 18:06:30 CEST Tedd Sterr wrote:
> My point is that it's difficult to tell what's mandatory and what's
> optional, and so it's still going to require combing through all eight
> documents first to find out what's necessary and second to decide what's
> desirable.

I’ve heard this from a few places now. Maybe we can have a table in XEP-0369 
(or maybe even all of them), prominently at the top before going too deep in 
any technicalities or background, which clearly states for each XEP where it 
is {mandatory,recommended,optional}-to-implement?

Like:

XEP-0369:
- User server: not needed
- MIX server: REQUIRED
- Client: REQUIRED

XEP-0405:
- User server: REQUIRED
- MIX server: not needed
- Client: REQUIRED (needs to support the IQ protocol to join a MIX)

etc. (in table form of course because that’s easier to digest; but tables are 
hard in emails)

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] Proposed XMPP Extension: Terms of Services

[Jonas Wielicki]

Hi,

Thanks for your feedback, Ivan.

On Mittwoch, 23. Mai 2018 16:38:08 CEST Ivan Vučica wrote:
> ---
> 4.2.1.1 Protocol support required
> 
> If the client did not include a  element in the initiating
> request and the server requires support for the Terms of Service protocol,
> it replies with an error:
> ---
> On first reading, it's unclear what is the "initiating request" that
> 4.2.1.1 addresses. Is this intended to be a response for
> jabber:iq:registration-related requests? When does the user get the
> opportunity to respond with or without ?

You rightfully expect IBR to play a role in the ProtoXEP. Right now, it does 
not, because I didn’t have the time yet to integrate IBR. The initiating 
request is w.r.t. the Ad-Hoc Command session flow (id='cmd1' in the examples).

> For that matter -- why is  in the adhoc command required in
> the first place? The point is to show the adhoc command dialog for TOS to
> the user upon request.

Ad-Hoc commands may be invoked by clients which do not support the TOS 
protocol. This is a feature to allow legacy clients to interact with a less 
fancy version of the ToS flow. However, a service may require the fancy 
version (for whatever reason). At the moment, the XEP does not contain 
anything which would require  to be enforced by the server. It 
is there as a provision for the future.


> Next up:
> ---
> 
>   Your client does not support the Terms of Service protocol.
>   Please review the Terms of Service online at
>   https://service.example/tos.
> 
> ---
> If the protocol is not supported, how does the user indicate acceptance
> before IBR? 

Not at all. But keep in mind that existing users may need to be migrated to 
new TOSes and servers might want to do this in-band.

In addition, the Ad-Hoc Command is useful to modify privacy settings connected 
with the ToS (as given in the example) later on.

> Or in general -- if the user reviews the TOS, how do we know
> they accepted them? 

If a server requires explicit "acceptance" of the ToS, it has to request that 
using a checkbox as shown in the examples. The client presents the boolean 
field (checkbox) to the user, the user ticks it and submits the command, at 
which point the server knows the user has accepted it.

> Should we standardize a chat session where the user is
> displayed the same messages, and required to enter "agree/disagree" _in
> addition_ to providing better UX through adhoc commands?

No, I find chat sessions weird and flaky for this type of thing.

> Next up:
> ---
> 4.4.1 Reject bind attempt before agreement
> 
> If a client attempts to bind a resource before agreeing to the Terms of
> Service, the server rejects the request with a  type
> 'cancel' error including an application defined condition of
>  in the namespace of this protocol.
> ---
> 
> In 4.4.1, should a mention of in-band registration be made? How is IBR
> affected? Is it affected at all?

IBR needs to be considered in the XEP. It is not affected by 4.4.1 because 
4.4.1 is post-authentication (IBR is pre-authentication, obviously).

> Finally:
> 
> Why does the client care about version of the documents -- is this so it
> can avoid bothering the user to agree?

If the service is in the process of switching TOS documents, it is important 
to know which version the client is currently acting on. This eliminates a 
race condition between a client/user reviewing and modifying their privacy 
settings and the service rolling out a new version of their documents.

> The server is the one that remembers
> whether the user agreed to TOS (it should do so, so it can be proven that
> the user has indeed agreed to a revision of TOS); does the client need to
> remember the last agreed version of the TOS?

No.

> The server could simply send
> an adhoc form that says "your acceptance is not required" if the user has
> already agreed. 

It should not do that to allow users to easily (re-)discover the ToS documents 
of the service and modify opt-ins/opt-outs later on.


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] Proposed XMPP Extension: Terms of Services

[Jonas Wielicki]

On 22 May 2018 22:02:16 CEST, Jonas Wielicki <jo...@wielicki.name> wrote:
>The XMPP Extensions Editor has received a proposal for a new XEP.
>
>Title: Terms of Services
>Abstract:
>This specification provides an in-band, unauthenticated way to request
>the Terms of Service of an XMPP service.
>
>URL: https://xmpp.org/extensions/inbox/tos-old.html

Sorry, hiccup of the mailer due to local files, the correct URL is:

https://xmpp.org/extensions/inbox/tos.html

>The Council will decide in the next two weeks whether to accept this
>proposal as an official XEP.
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___


-- 
Sent from my mobile device. Please excuse my brevity.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Council Agenda 2018-05-16

[Jonas Wielicki]

On Donnerstag, 17. Mai 2018 15:11:45 CEST Kevin Smith wrote:
> Although I was -1 yesterday on HACX, I’d like to update that to +0. I think
> there’s sufficient difference in business rules that having its own number
> might not be inappropriate.

It would still make sense to re-base it to re-use the syntax from XEP-0156, 
wouldn’t it?

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] Maintaining a list of ongoing conversations

[Jonas Wielicki]

On Montag, 14. Mai 2018 12:28:17 CEST JC Brand wrote:
> I'm interested in finding a way to keep track of ongoing conversations and
> whether any new messages were added to them since the user was last online.
> 
> I think this is the so-called "Inbox" feature that was brought up at the
> 2018 summit.
> 
> At the summit the suggested approach was a private PEP node with a list of
> JIDs.
> 
> Besides that, in order to know whether new messages were added to these
> conversations (while the user was offline), we'll also need to store the
> date of the last seen message.

I’d prefer the MAM stanza-id, because that’s what should be used to sync 
anyways. Adding a date may be good if you want to show an overview though.


> I imagine, if done right, that this functionality might in many cases remove
> the need for bookmarks as currently used.
> 
> Is anyone already working on something like this? I'm not aware of a
> relevant protoXEP being created already.

Not that I knew.

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] Disappearing timers for OMEMO proposal

[Jonas Wielicki]

On Sonntag, 13. Mai 2018 15:37:18 CEST Alexander Krotov wrote:
> On Sun, May 13, 2018 at 12:40:40PM +0200, Jonas Wielicki wrote:
> > On Sonntag, 13. Mai 2018 00:07:32 CEST Alexander Krotov wrote:
> > > For unencrypted timed messages we need to require hinting the server
> > > not to store the message, by the way.
> > 
> > You do realize that this will make the user not see the message, at all,
> > ever, if their only clients supporting Timers aren’t online at the time
> > the message is sent?
> 
> Well, it should be , not :
> https://xmpp.org/extensions/xep-0334.html#no-permanent-store

Yes, no-permanent-store excludes MAM. And MAM-enabled clients won’t fetch 
Offline Messages because they can’t sync them with MAM. (And Offline Messages 
don’t help when there is another non-timer client online.)

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] Disappearing timers for OMEMO proposal

[Jonas Wielicki]

On Sonntag, 13. Mai 2018 00:07:32 CEST Alexander Krotov wrote:
> For unencrypted timed messages we need to require hinting the server
> not to store the message, by the way.

You do realize that this will make the user not see the message, at all, ever, 
if their only clients supporting Timers aren’t online at the time the message 
is sent?

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] Disappearing timers for OMEMO proposal

[Jonas Wielicki]

On Samstag, 12. Mai 2018 19:55:52 CEST Paul Schaub wrote:
> Hi!
> 
> I get what you want to achieve, but I think it would be easier to define
> disappearing messages for general XMPP (not only OMEMO).
> 
> As already stated, you cannot trust devices that announce support, to
> actually delete messages after the timer expired. Lets assume you do
> trust all involved devices. Lets see how to deal with legacy devices.
> Why not specify ephemeral messages like this:
> 
> 
> 
> This is an ephemeral message
> 
> 

This is awful. It will require the message to carry a non-empty  to 
deal with the MAM/Carbons mess (and also to help users of clients which do not 
support this feature).

In addition, this breaks all XEPs which depend on the , like References 
and 394.

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] Disappearing timers for OMEMO proposal

[Jonas Wielicki]

On Samstag, 12. Mai 2018 15:31:41 CEST Alexander Krotov wrote:
> On Sat, May 12, 2018 at 10:45:49AM +0200, Florian Schmaus wrote:
> > On 12.05.2018 10:14, Alexander Krotov wrote:
> > > On Fri, May 11, 2018 at 10:24:35AM +0200, W. Martin Borgert wrote:
> > >> Quoting Alexander Krotov :
> > >> Therefore it is orthogonal to any encryption and it does also not
> > >> matter, whether your peer or one of your peers devices or resources
> > >> does implement the feature or not. No need to check. As sender, just
> > >> use the timers and let the problem of deleting messages to the
> > >> recipient.
> > > 
> > > I want to be able to advertise to my contacts which of my devices
> > > support timers, so devices that don't support them are not able to
> > > decrypt the message.
> > 
> > What prevents ("malicious") devices from announcing the feature and not
> > deleting the message afterwards? What do you gain from coupling
> > encryption and timers?
> 
> Nothing prevents "malicious" devices from announcing the feature
> and not implementing it correctly. "Malicious" user devices are not
> a part of my threat model. I have just explained it in detail in
> another message.[1]

Then I don’t see a reason to *require* a *specific type* E2EE. If you are 
worried about the server attacking, fine, use the  with OMEMO.


> Announcing the feature is a way to tell my contacts that if they want to
> send me an ephemeral message, they have to encrypt it only for those of
> my devices that will delete them. For example, if I use a desktop client
> that implements ephemeral messages, but still use a legacy mobile client
> that does not, my contacts will only include a key for my desktop
> client, and my mobile client will not be able to decrypt a message.

See, this is extremely horrendous User Experience. One side of the 
conversation picks an encryption mode which makes messages only appear on a 
subset of the devices on the other side. People are already complaining about 
this with plain OMEMO, due to whatever-is-going-wrong (I’m not familiar with 
OMEMO on a development level).

(Then again, if we introduce a thing where having the message only on a subset 
of devices is a feature, we might use that as a diversion! /sarcasm)


> Coupling encryption and timers prevents plaintext messages from
> being stored forever on *my own* legacy clients, so I don't have
> to upgrade them all at once to make this feature works properly, and
> my contacts don't have to worry if I have already upgraded all my
> devices or not.

Why would your contacts worry? In your other message, you explained:

> In the part of my message that you quote, though, I was not even
> talking about making sure message is deleted on a device that I
> don't own, which is a matter of trust. I was talking about not being
> able to decrypt the message on *my* devices by advertising that I
> only want to receive ephemeral messages on some subset of my devices.

So what is it now? Is this about data hygiene on your own devices (in which 
case we don’t even need wire format at all, just add a "delete last N hours" 
button, or if you want to default to deletion, add a "do not delete last N 
hours" button; actually, probably not the worst idea), is it about data 
hygiene on other peoples devices and servers (E2EE not required at all to make 
this work, since it’s a matter of "trust" anyways; and I think this might 
actually be a useful feature sometimes), or is it about security and actually 
safely deleting timed messages (not possible, as you know)? I feel that you’re 
shifting goalposts all the time.


> Even if backwards compatibility was not a problem, some client
> developers may not implement this feature at all, for various reasons.
> They may not be convinced that this feature is useful; they develop for
> a platform that can't offer strong enough security guarantees (for
> example, Web) and securely delete a message; 

Great, so now we have a subset of clients not able to receive messages from a 
subset of users who think that enabling timers by default is a good idea. And 
since your messages don’t arrive, you won’t know.


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] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

[Jonas Wielicki]

On Freitag, 11. Mai 2018 15:27:53 CEST Jonas Wielicki wrote:
> Version 0.10.0

This is the 0.9.7 people have been talking about already. We chose 0.10.0 
because the update included non-editorial changes and that deserves a version 
bump in the second number.

Sorry for the confusion.

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] Disappearing timers for OMEMO proposal

[Jonas Wielicki]

On Donnerstag, 10. Mai 2018 08:23:04 CEST Daniel Gultsch wrote:
> I implemented this several times for various closed systems. I always
> attached a per message timeout that started the moment the message was
> read.

How is this state synchronized across clients? "Displayed" Markers?

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] Disappearing timers for OMEMO proposal

[Jonas Wielicki]

On Donnerstag, 10. Mai 2018 14:31:27 CEST VanitasVitae wrote:
> Am 10. Mai 2018 14:24:47 MESZ schrieb "Remko Tronçon" :
> >I don't see why a XEP for data retention hints needs to be tied to
> >other XEPs like
> >OMEMO, though.
> 
> I'd also rather not tie it to OMEMO. 

Agreed, if implemented, this should not be tied to OMEMO or any other E2EE.

We already have enough proliferation of E2EE technologies (and enough issues 
with partial support of the various technologies in clients). We don’t need 
another OMEMO mode.

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] Disappearing timers for OMEMO proposal

[Jonas Wielicki]

On Donnerstag, 10. Mai 2018 14:36:46 CEST Ненахов Андрей wrote:
> 2018-05-10 17:31 GMT+05:00 VanitasVitae :
> 
> 
> > I'd also rather not tie it to OMEMO.
> 
> By the way ,self-destructing messages should also be deleted from
> message archives on both sender and recipients servers. For e2ee
> messages one can argue that it's not really important if messages are
> not deleted from server, however, it's just yet another way to make
> such 'ephemeral' messages reappear on recipient's device - just by
> reading from archive.

We *can* technically "delete" from MAM-based archives, with tombstoning.

Also, if the client uses MAM for sync purposes, it won’t re-show the same 
message because internally it knows that it has already synced that part of 
the archive and won’t re-sync it. So this will actually work neatly in sync-
based clients.

Clients which use MAM in a "surf through your archives server-side" way 
without copying it locally will of course still see the message. They could 
still show it as "expired" or simply hide it from the view.

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] Thoughts on MIX adoption (and will MIX ever happen?)

[Jonas Wielicki]

Hi Steve,

I’m interested in implementing MIX in aioxmpp and JabberCat. I consider the 
model of MUC broken (I’m not going to list the brokenness here) and unfixable 
within the existing specification.

MIX is huge, I agree. Splitting the spec seems like a good idea, but it will 
not be easy (to split it in a way that clients implementing only Base can 
interact (or detect incompatibility) with services implementing more than 
Base. If we can get this right, splitting would be tremendously useful.

The splitting point suggested by Daniel (essentially Joining, Leaving and 
Messaging, without any presence things) seems like a very good start to me.

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-0363 (HTTP Upload): Privacy Considerations & Deletion

[Jonas Wielicki]

On Freitag, 27. April 2018 14:58:02 CEST Daniel Gultsch wrote:
> If this is about local law I don’t think a delete function will do that
> justice. · Clients might not implement the delete part of the XEP and as a
> service provider I can not solely rely on my users using the right
> client. Therefor I will have to offer a stand alone delete
> functionality on my website or over customer support anyway.
> · Clients might no longer have a reference to a file anyway. (The
> sending client might have been uninstalled, local history might have
> been cleared etc etc). Therefor I believe once we go down the rabbit
> hole of deleting files we will probably need an list/index operation
> as well.
> 
> Since a simple delete won’t do local law justice anyway we should
> think about whether or not we want to have delete in this XEP
> independently of local law.
> 
> I haven't seen a lot of requests for file deletion from client (or
> server) developers yet. So I don’t think there will be a strong demand
> that justifies the KISS approach of this XEP. Furthermore HTTP File
> deletion - just like individual MAM message deletion - can - if there
> is in fact a demand - easily go into it's own XEP.

I agree with your stance about deletion. Which is why I made it a separate PR.

What do you think about the independent extension to the text I proposed in  
https://github.com/xsf/xeps/pull/625 ?

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-0369: MIX - Forced room ownership

[Jonas Wielicki]

On Donnerstag, 26. April 2018 09:52:08 CEST Steve Kille wrote:
> I really don't want to mandate this sort of thing in the core.
> 
> However,  I will place a hook into the text, so it can be developed as a
> bolt-on XEP later

I think this is a good way forward. Thanks.

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-0363 (HTTP Upload): Privacy Considerations & Deletion

[Jonas Wielicki]

On Freitag, 27. April 2018 04:59:25 CEST Travis Burtrum wrote:
> On 04/26/2018 10:35 AM, Jonas Wielicki wrote:
> > As it turns out, several implementations are making it not trivial for
> > operators to be GDPR compliant. One of the things definitely necessary (as
> > far as our understanding goes) is that users must be able to have their
> > data deleted in a reasonable timeframe; it must also be possible to
> > create a bundle of all data the service currently has from the user.
> 
> Many implementations don't even track who uploaded what, isn't that
> better?  No records, no problems?

No. It’s not about the association, it’s about the users data (the uploaded 
files) which must be deletable. At least that’s my understanding of the 
situation.

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 announcements delay?

[Jonas Wielicki]

On Freitag, 27. April 2018 02:59:31 CEST Ludovic BOCQUET wrote:
> Dear all,
> 
> Today I have received new announcements about 4 XEPs (0363/0223/0122/0373):
> - https://xmpp.org/extensions/xep-0363.html -> Version: 0.6.0 / Last
> Updated:2018-04-21
> - https://xmpp.org/extensions/xep-0223.html -> Version: 1.1 / Last
> Updated:2018-03-28
> - https://xmpp.org/extensions/xep-0122.html -> Version: 1.0.2 / Last
> Updated:2018-03-21
> - https://xmpp.org/extensions/xep-0373.html -> Version: 0.3.0 / Last
> Updated:2018-04-16
> 
> Why there is a delay for announcement ?

This isn’t so much a delay for the announcement.

The revision date is the date at which the change was made by the author (of 
the change). It is not necessarily the date on which the revision will have 
appeared on the website.

Do we want those dates to be fixed to the date of publishing? We can do 
that---it’s an extra step of editor work.

As for the delay itself, editors have been busy with non-editor stuff. Sorry 
for that. We could still use support in the editor team FWIW.

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-0068 and MAM

[Jonas Wielicki]

Hi Ivan,

On Donnerstag, 26. April 2018 14:03:15 CEST Ivan Vučica wrote:
> Today I learned about XEP-0068 which seems to specify an IDL-like XML
> for data forms. It also defines a registry for FORM_TYPEs maintained
> by the XMPP Registrar. I feel this could be very useful to client
> libraries, which can generate code with structs for predefined types
> a-la protocol buffers or thrift or  -- presumably that was the
> intention.
> 
> Is anyone using the  definitions for code generation? If
> so, for which language are you generating the stubs?

Yes. aioxmpp has an (inofficial and not shipped) utility for this [1]. It 
works and has been used for the MUC config form for example.

> So: Should these /at least/ include the  definition?
> Should this be then updated in the registry?

My understanding is that the registry will normally be updated once a XEP 
enters Draft status.

> Next up: XML version of the registry (formtypes.xml) would be much
> more useful if it included the  themselves. How are the
> HTML and XML versions generated?

The XML data is in [2].

kind regards,
Jonas

   [1]: https://github.com/horazont/aioxmpp/blob/devel/utils/
form_type_to_code.py
   [2]: https://github.com/xsf/registrar/blob/master/formtypes.xml

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
___

[Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion

[Jonas Wielicki]

Hi all,

During the last "XSF & GDPR" meeting (minutes pending), we were discussing 
HTTP Upload.

As it turns out, several implementations are making it not trivial for 
operators to be GDPR compliant. One of the things definitely necessary (as far 
as our understanding goes) is that users must be able to have their data 
deleted in a reasonable timeframe; it must also be possible to create a bundle 
of all data the service currently has from the user.

Some implementations do not allow this. I have prepared [PR #625] which adds 
wording to inform implementations about these requirements.


In addition, it would be useful if users could delete files they uploaded 
themselves. This is rather optional (which is why I made separate PRs), since 
services are likely to auto-expire files anyways. I can however see use-cases 
where a user wants a file deleted immediately, and this saves the interaction 
with the operator. I prepared [PR #624] for this.


I’d like to hear your (especially Daniels) opinions on this.


kind regards,
Jonas

   [PR #625]: https://github.com/xsf/xeps/pull/625
   [PR #624]: https://github.com/xsf/xeps/pull/624

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] Removal of GC1.0 from MUC / XEP-0045

[Jonas Wielicki]

On Dienstag, 10. April 2018 10:29:36 CEST Georg Lukas wrote:
> It is this time of the month again. Georg is trying to fix MUC.
> This time, I'm asking the Council to remove GC1.0 support from XEP-0045.

+1.

> In case this motion is approved, I'd prepare a PR against 0045 where the
> respective section will be replaced by a stub, and where servers will be
> advised to respond to join-less presence with either 
> or a  presence (I think the former is more elegant).

I’m torn on the specifics and we’ll have to think about the explanations. 
While the former is more clear and elegant, it would possibly require 
additional code in existing clients to make use of. A status 307 + status 333 
may do the trick for that, while not being confusing to conforming clients.

(Bonus independent of the specific approach: servers may remove a presence 
subscription from the roster when they encounter such a presence stanza.)


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] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

[Jonas Wielicki]

On Donnerstag, 22. März 2018 08:36:10 CET Matthew Wild wrote:
> On 21 March 2018 at 18:37, Jonas Wielicki <jo...@wielicki.name> wrote:
> > On Mittwoch, 21. März 2018 18:07:53 CET Sam Whited wrote:
> >> On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote:
> >> > I’d argue (and did at the Summit) that the opposite is true and that if
> >> > we want (especially impromptu) MUC to start working nicely across
> >> > multiple accounts we need clients to react to the user leaving rooms
> >> > manually by disabling the autojoin and then having other clients leave
> >> > as well. They only joined because the autoflag was set, so isn’t it
> >> > logical for them to leave when it’s no longer set?
> >> 
> >> I agree with this; when I do something on one client, I almost always
> >> want
> >> it synced to my other clients. Room joining and parting is the same.
> >> Similarly, just because my connection dropped and came back up a moment
> >> later doesn't mean I should suddenly not be joined to rooms anymore.
> > 
> > This is what I meant primarily, sorry. I was unclear.
> > 
> >> If I'm
> >> in a room, I should autojoin it from all my clients on startup,
> > 
> > Now, I disagree here. I have several rooms which I don’t want on my mobile
> > device for battery reasons (my go-to example is #openstack on
> > irc.freenode.net). But I have multiple desktop-like devices which I would
> > like to join and leave those rooms synchronously.
> > 
> > But as it was said elsewhere, I guess this can very well be solved with
> > per- device-class (notification) settings plus CSI.
> 
> I really don't think we should go down the road of trying to define
> "device classes". This will only end up with a complex protocol and
> complex UIs in clients.
> 
> As per the logic described in my previous email, you can either set
> autojoin and explicitly leave the room on your mobile when it
> autojoins - the client should remember that you left, and this should
> override the bookmark - why would e.g. the mobile OS killing the app
> in the background and auto-restarting it cause you to rejoin rooms
> that you left?

Didn’t we argue before that leaving autojoined rooms should remove the 
autojoin flag, for synchronization?

> Alternatively for your case you can join on one of your desktop
> clients, choose not to have all your clients join (i.e. don't set
> autojoin), and then manually join it from your other desktop clients -
> in the room join dialog, they should let you select from your
> bookmarks.

So with the "leave synchronizes to all devices" part, this is the only way to 
achieve this. I guess this is fine. This is a power-user use-case anyways.

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] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

[Jonas Wielicki]

On Mittwoch, 21. März 2018 18:07:53 CET Sam Whited wrote:
> On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote:
> > I’d argue (and did at the Summit) that the opposite is true and that if
> > we want (especially impromptu) MUC to start working nicely across
> > multiple accounts we need clients to react to the user leaving rooms
> > manually by disabling the autojoin and then having other clients leave
> > as well. They only joined because the autoflag was set, so isn’t it
> > logical for them to leave when it’s no longer set?
> 
> I agree with this; when I do something on one client, I almost always want
> it synced to my other clients. Room joining and parting is the same.
> Similarly, just because my connection dropped and came back up a moment
> later doesn't mean I should suddenly not be joined to rooms anymore. 

This is what I meant primarily, sorry. I was unclear. 

> If I'm
> in a room, I should autojoin it from all my clients on startup, 

Now, I disagree here. I have several rooms which I don’t want on my mobile 
device for battery reasons (my go-to example is #openstack on 
irc.freenode.net). But I have multiple desktop-like devices which I would like 
to join and leave those rooms synchronously.

But as it was said elsewhere, I guess this can very well be solved with per-
device-class (notification) settings plus CSI. If we are going for that. In 
that case, I don’t care if my mobile has joined #openstack; it would not be 
woken up unnecessarily because of that, and it would not generate 
notifications from that; but if I wanted to take a peek, I could, which is 
arguably nicer than having to join it manually on that device.

> if I close
> the room, it should close immediately in my other clients and no longer be
> autojoined on startup.

For closing I agree.

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-0394: too weak to replace XEP-0071

[Jonas Wielicki]

On Mittwoch, 21. März 2018 10:19:34 CET Kozlov Konstantin wrote:
> Hello, Jonas!
>  
> 19.03.2018, 10:51, "Jonas Wielicki" <jo...@wielicki.name>:
> A client can use 394 without support 393 just fine. I don’t see where you
> got this notion from, I guess my initial mail on this was unclear.
> 
> Maybe. It was originally my idea: I just can't figure out how client, which
> supors XEP-0394 only and knows nothing about XP-0393 may understand which
> parts of styled text fragment to remove? 

It’s going to be written down in XEP-0394. As mentioned, a major update is 
pending. I’m currently not having the time to do it.

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] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

[Jonas Wielicki]

On Dienstag, 20. März 2018 19:12:57 CET Georg Lukas wrote:
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> > Title: Bookmarks 2 (This Time it's Serious)
> 
> A number of issues I have with the current Bookmarks XEPs, and that I'd
> like to see addressed in the mid-term future (ideally by adding them to
> Bookmarks2):
> 
> 1) Auto-Join
> 
> The 'autojoin' flag name is a bit misleading in the time of always-on
> clients.  Maybe we should change the text to indicate that a client is
> supposed to join and stay joined(!) if this flag is set, and maybe also
> to automatically leave when the flag is unset.

I’d argue that clients should always stay joined in MUCs the user hasn’t 
explicitly left. So autojoin is just saying "join the MUC on startup" (and 
thus, by extension, stay joined).

> 2) Per-Client Join Lists
> 
> Sometimes it is desirable to have different clients joined into
> different chatrooms (i.e. to remove high traffic public MUCs from a
> mobile client). I'm not sure if we can place that here or if this
> should better be a part of the Post-XMPP2 centralized per-JID
> notification settings.

Good point. I’m not sure on the structure of that information though. We don’t 
have client IDs, nor do we have client categories (aside from XEP-0030 
identiteis). Maybe XEP-0030 identities actually could work here? (I.e.: What 
would be the "key" in the key-value store which maps clients to autojoin 
values?)

> 3) Roster Groups
> 
> MIX allows us to put MIXes into the roster, and by extension into roster
> groups. It would be great to have roster group support for MUCs as well,
> so that we can put the family MUC into the family roster group. All that
> is needed is to allow a set of named tags per bookmarks, no need to
> actually change our roster XML.

Yes please.

> 4) Nicknames
> 
> With MSN widely in use, we lack a mechanism to synchronize our per-MUC
> nickname between our clients. This leads to a situation where a
> widely-used Android client will leak our username to pseudonymous MUCs
> by auto-joining them with nickname=localpart when invited.
> 
> I think we should either mandate that the  attribute SHOULD be
> used, or at least specify XEP-0172 §4.3 as a fallback if it's not.

@nick should be moved to an attribute while we’re at it. Setting it as SHOULD 
also makes sense.

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] XMPP Extension Editor

[Jonas Wielicki]

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.

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] Proper SRV Record Fallback

[Jonas Wielicki]

Hi all,

Let’s do a neat TOFU mail to bump this thread (you’ll find a more detailed 
inline reply from me at the start of the thread).

In aioxmpp, we now (v0.10+) implement the following:

- pre-auth stream errors are treated like any other connection error (e.g. 
connection refused). This notably includes bad-format from receiving HTML 
where we expect XML. We try the next SRV record option in that case.

- if SASL is unavailable (e.g. no matching mechanism), we also try the next 
option.

- authentication failures are treated as fatal and abort everything 
immediately.

- TLS errors are like any other connection error and trigger the next option.

This plays nicely when connecting to a multiplexed server without ALPN 
support.

(also, we now have ALPN support.)

Any comments?

kind regards,
Jonas

On Dienstag, 9. Januar 2018 05:19:36 CET Travis Burtrum wrote:
> Hi all,
> 
> I have not been able to find proper SRV record fallback behavior
> documented, and could not come to a clear consensus in the XSF MUC
> earlier, so I thought I'd bring the discussion on-list. (and hopefully
> document it in implementation notes of XEP-0368[1])
> 
> The main question is when you should fall back to lower priority SRV
> records and when should you give up and fail the connection.
> 
> First, what do docs say:
> 
> RFC-6120[2] Section-3.2.1 #7 says:
> > 7. If the initiating entity fails to connect using all resolved IP
> > 
> >   addresses for a given FDQN, then it repeats the process of
> >   resolution and connection for the next FQDN returned by the SRV
> >   lookup based on the priority and weight as defined in [DNS-SRV].
> 
> 'fails to connect' does this mean the TCP connection fails, or the XMPP
> connection fails?
> 
> #8 might leave a hint:
> > 8. If the initiating entity receives a response to its SRV query but
> > 
> >   it is not able to establish an XMPP connection using the data
> >   received in the response, it SHOULD NOT attempt the fallback
> >   process described in the next section (this helps to prevent a
> >   state mismatch between inbound and outbound connections).
> 
> This clearly says XMPP connection, but does it apply to #7 ?
> 
> It is also clear I didn't think about this too hard when writing
> XEP-0368, because I clearly (to me) assume SRV fallback will happen if a
> complete XMPP connection is not successful, because under Implementation
> 
> Notes I say:
> > Server operators should not expect multiplexing (via ALPN) to work in
> > all scenarios and therefore should provide additional SRV record(s)
> > that do not require multiplexing (either standard STARTTLS or
> > dedicated direct XMPP-over-TLS). This is a result of relying on ALPN
> > for multiplexing, where ALPN might not be supported by all devices or
> > may be disabled by a user due to privacy reasons.
> 
> While I don't explicitly say it, if a port required ALPN to multiplex,
> it will generally end up connecting you to a non-XMPP server without
> ALPN, meaning you will get back invalid XML, other junk, and/or an
> invalid TLS cert.
> 
> RFC-2782[3], defining SRV records, makes no mention of this.  Which
> actually makes sense because it doesn't even define possible protocols,
> UDP for example has no connection concept.
> 
> Now that the docs are out of the way, on to the discussion:
> 
> In my opinion, at least all of cannot-connect-to-port, non-XML,
> not-proper-stream and invalid TLS cert should trigger a fallback to the
> next highest priority SRV record.  Everyone in the MUC seemed to agree
> if authentication fails a fallback would be a bad idea.
> 
> Sam Whited said that if a TCP connection is established fallback should
> cease, that it shouldn't have anything to do with or any knowledge of
> XMPP, and that it might have security implementations to do otherwise.
> (please correct and forgive me if I misunderstood)  I disagree with
> this, I think if Eve has control over DNS (and no DNSSEC) she can return
> arbitrary records anyway so SRV fallback doesn't matter.  If Eve
> controls a higher priority server, or the network between client and
> that server, she can trigger fallback or not regardless of what we
> decide.  The difference is if we decide not to fallback, then she can
> effectively DOS us by messing with 1 server instead of all.
> 
> I think my proposal is even more generic than the above, I think
> authentication-response should be the point when fallback ceases.
> Regardless of what happens before that point, you fall back to the next
> SRV record, and after authentication, whether it's successful or not,
> you no longer fall back anymore.
> 
> As to what actual clients do in the wild, Conversations falls back
> regardless of junk or invalid cert, dino does not.  I am unsure what
> gajim does (though from talking to lovetox 1.0-beta might also not
> fallback in all cases).
> 
> Depending what we decide, I plan to set up various domain/SRV record
> combinations for testing, probably 

Re: [Standards] XEP-0394: too weak to replace XEP-0071

[Jonas Wielicki]

On Freitag, 16. März 2018 12:11:31 CET Kozlov Konstantin wrote:
> Yes. CSS is really a hard part. But we don't need full support of CSS for IM
> message styling. Maybe it's better to simplify XEP by specifying a small
> subset of CSS rules needs to be implemented, as it was done with XHTML tag
> subset?

XEP-0071 already did that. This doesn’t save an application from having to 
parse all inline CSS and sanitize it, which is the hard part.


> But I don't like the idea of sacrificing ability to compose rich
> text in WYSIWYG editor in favour to "accessibility". Yes, anyone is annoyed
> when interlocutor sends messages abusing rich text formatting. But you can
> abuse any good feature. WYSIWYG is always preferred by end user.

This is true, and in general, '394 does not prevent you from creating a 
WYSIWYG-style editor. If you are concerned about the weak definition of 
"emphasis", I think it would be fine to say it SHOULD be italic/bold (weak vs. 
strong emphasis respectively).

This will allow WYSIWYG to work in *most* cases, and where it does not 
represent exaclty "what you get", there will be good reasons for that.


> Especially
> when it comes to messaging. Especially on mobile devices, where you need to
> switch between different keyboards every time you want to type special
> characters like ',~,`{},_,* and so on.

This was never and will never be a necessity with '394. A client *may* choose 
to offer this as a way to input text, because many are used to this from other 
(albeit probably non-mobile-centric) messengers.


> Yes, I'll be annoyed receiving a lot
> of messages with strange fonts, different font sizes and colors. But for
> many years of exploiting XHTML-IM enabled client I never was in such
> situation, 'cause most of the people in this world are adequate. 

I am in this situation every other day because stupid clients allow people to 
paste XHTML from websites. Websites tend to default to black-on-white. My 
client is white-on-black. Now I get black on black. Neat!

This is of course primarily an issue with my receiving client, which should 
prevent this from happening; except that it can’t know the background color 
because it runs in a terminal. It would have to set the background color, 
which has other portability issues in itself (i.e. it would also have to set 
the foreground color and thus ignore all the theming settings I do in my 
terminal).

On the other hand, the XEP-0392 (Consistent Color Generation) implementation I 
wrote for that client works just fine; which is why I’m confident that 
XEP-0394 using XEP-0392 hues would be a great middle-way to this.


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-0394: too weak to replace XEP-0071

[Jonas Wielicki]

On Freitag, 16. März 2018 15:03:28 CET Tedd Sterr wrote:
> I like the idea and design of 0394, and look forward to seeing these
> extensions; the unholy hybrid attempting to shoehorn in 0393, not so much.
> 
> Attempting to extend the inline text styling to support all of the
> additional formatting features is going to result in plain text messages
> that resemble Perl programs, which is really not good for readability. And
> essentially forcing clients to support 0393,

A client can use 394 without support 393 just fine. I don’t see where you got 
this notion from, I guess my initial mail on this was unclear.


> while also including
> additional styling that 0393 does not support will do nothing to aid
> compatibility.

The "unholy hybrid" is not about '393 compatibility in particular. It is about 
gracefully falling back to plaintext in general. Making this compatible (to a 
certain extent [1]) with '393 is just an added bonus.


> Regarding graceful degradation: there should be a service discovery string
> to indicate support for 0394; thus a sending client knows in advance
> whether to send 0394 formatting to another client.

This is the Feature Discovery fallacy (for the lack of a better term). Feature 
Discovery does (currently) not really work. We have Carbons and MAM. You can’t 
be sure whether the other side has clients which support or do not support a 
feature and which are just currently not online. Not to mention MUCs and other 
broadcast/multicast protocols. Is it reasonable to remove formatting options 
just because one lurker in a MUC with 20 users does not have support? You also 
generally won’t be able to see features of all clients in a Multi-Session Nick 
situation. Relying on feature discovery is not going to solve anything.


> The sending client can still degrade gracefully - there are four
> possibilities: […]

See above.


kind regards,
Jonas

   [1]: Full compatibility with '393 can’t be achieved anyways, because of
the intentional restrictions of '393. It would at most be an 
approximation which---just like '393 itself and as designed---works
in *most* cases.

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] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

[Jonas Wielicki]

On Sonntag, 18. März 2018 18:48:49 CET Guus der Kinderen wrote:
> Having implemented 0048 via 0223 earlier this week, I can only applaud an
> effort of making the documentation easier to digest. Thanks for this!
> 
> I am, however not sold on the idea of having a bookmark-per-item: what
> problem is that solving, or what benefit does this give us?

Two or more clients updating different bookmarks at the same time (or maybe at 
different times, but one had a network outage inbetween and can only actually 
perform the update at a later time). Currently, it requires a nasty loop [1] 
until convergence to make that work.

> I appreciate
> how it fits in nicely with the way how pubsub is designed - but in
> practice, I suspect that one would easily work with entire sets of
> bookmarks anyways. By not splitting up the bookmarks, we wouldn't need a
> new namespace, and we can re-use the existing 0048/0049 data structure.
> That will improve interoperability, and make adoption easier.

We’ve been advocating this (split into items) move for quite a while and we’re 
happy to see that it’s happening now.

> Unrelated: I'd like the XEP to have a "complete" example of a bookmark, one
> that includes the room JID. Although the text is clear, having an example
> like that will be a useful illustration.

The text doesn’t seem to be that clear then; the idea is that the JID is in 
the pubsub item ID (§ 4.1) -- which also has the nice sideeffect of resolving 
the ambiguities which arise when multiple bookmarks for the same room with 
different nicknames exist.

kind regards,
Jonas

   [1]: https://github.com/horazont/aioxmpp/blob/devel/aioxmpp/bookmarks/
service.py#L416

> 
> On 18 March 2018 at 16:25, Sam Whited <s...@samwhited.com> wrote:
> > Looks great, thanks Dave and JC!
> > 
> > The only feedback I'd like to give is that the password field should be
> > removed. If use of the password field is not recommended, why have it? It
> > seems perfectly fine to say that you can't autojoin password protected
> > MUCs
> > without a prompt or that individual clients must store the password (so
> > you'd have to log in once on each client the first time it fetches the
> > bookmarks and joins the room).
> > 
> > —Sam
> > 
> > On Sun, Mar 18, 2018, at 08:34, Jonas Wielicki wrote:
> > > The XMPP Extensions Editor has received a proposal for a new XEP.
> > > 
> > > Title: Bookmarks 2 (This Time it's Serious)
> > > Abstract:
> > > This specification defines a syntax and storage profile for keeping a
> > > list of chatroom bookmarks on the server.
> > > 
> > > URL: https://xmpp.org/extensions/inbox/bookmarks2.html
> > > 
> > > The Council will decide in the next two weeks whether to accept this
> > > proposal as an official XEP.
> > > ___
> > > Standards mailing list
> > > Info: https://mail.jabber.org/mailman/listinfo/standards
> > > Unsubscribe: standards-unsubscr...@xmpp.org
> > > ___
> > 
> > --
> > Sam Whited
> > s...@samwhited.com
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___



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] [STANDARDS] XEP-0394: too weak to replace XEP-0071

[Jonas Wielicki]

On Samstag, 17. März 2018 21:33:54 CET Tedd Sterr wrote:
> I didn't expect this to turn into a drawn-out argument; I merely suggested a
> simple solution to something that could otherwise be seen as a problem. Nor
> am I continuing it for my own amusement, but I genuinely don't understand
> why it's such a contentious issue for some.
> 
> So far the main argument against including text colouring seems to be
> "because I don't want it, so nobody else should have it either" which is
> really quite ridiculous, especially when there are genuine arguments that
> could be made. In search of clarity, here are all of the reasons against
> that I can think of, and replies to those. Please correct me if I've
> misunderstood anything; and additional sensible reasons are also welcome.

I have to admit I haven’t followed the whole thread, but how did you folks 
overlook that text colouring is on my todo, using XEP-0392-based support?

Which essentially means: you can use any colour, but you can’t select 
brightness and saturation. Those will be selected by the receiving client 
based on the background so that the colour is always contrastful and not hard 
to read. Bonus for Color Vision Deficiency corrections.

I think this is a very valid compromise. XEP-0392 is designed so that 
perceptually, you’ll see the same color as reasonably possible, even though it 
might have quite different RGB values on your side than on the receiving side 
(due to the inverse-background mixing).

I’ll catch up with the thread later and argue specific points if I find 
further unclarities.

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-0394: too weak to replace XEP-0071

[Jonas Wielicki]

On Donnerstag, 15. März 2018 19:19:30 CET W. Martin Borgert wrote:
> Quoting Jonas Wielicki <jo...@wielicki.name>:
> > If you are doing graphics/text design/publishing with your IM client,
> > you’re doing it wrong, in my opinion.
> 
> But XMPP is not only IM. What about blogging or social networks like
> Movim or Salut à Toi or before Jappix, which present a rich web
> interface? No need for specific fonts or colours, I agree, but people
> want probably a little bit more output control then in the IM world.

That’s true, I’ll point edhelas and maybe some others at this thread for 
feedback. Thanks for reminding me.

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-0394: too weak to replace XEP-0071

[Jonas Wielicki]

I’m sorry for the messed up quoting, but the plaintext part of these HTML 
emails is unusable.

On Donnerstag, 15. März 2018 16:24:58 CET Kozlov Konstantin wrote:
> Hello!
>  
> 15.03.2018, 17:40, "Sam Whited" :
> On Thu, Mar 15, 2018, at 02:22, Kozlov Konstantin wrote:
> 
>   1. Embedding pics into messages: ~80%. Pics are used to display memes,
>  as custom smilies, as parts congratulation cards, as small parts of
>  screenshots to explain something and so on.
> 
> Custom smileys should probably be its own XEP, but I agree we should make
> something for that at some point. Attatching images is better handled by
> XEP-0066 and does not need to be a part of a message formatting spec. It's
> likely that even if you don't support formatting you may want to include an
> image.
> 
> I don't think XEP-0066 suits for attaching inmages.
> It provides no way to tell client softwarem that provided link contains
> image.

This is true and why people suggest to use SIMS instead (XEP-0385). It’s a 
work-in-progress.


> Right now we have just  element whch sugested to be rendered
> either bold or italic. It's up to other party's client how to render it. I
> just want to be able to specify bold, italic or underlined explicitly.
> Otherwice I'll be unable to have WYSIWYG in my client, won't be sure what
> other party will see.

Specifically using bold/italic/underline is also an antipattern. What we 
should provide is a way to convey emphasis, possibly in two ways (usually 
rendered as italic (weak) and bold (strong)). The key point is to have 
semantics here, which are useful for accessibility and usability.

If you are doing graphics/text design/publishing with your IM client, you’re 
doing it wrong, in my opinion. If you need specific font styles, sizes, 
families etc., you should be using publishing software.

Again, I’m not advocating or even suggesting that it is a good idea to give 
users Rich Text editing capabilities by default in an IM client. I think it 
would make sense to have a way to convey those messages, but also that it is 
probably wisest to only create them automatically.


> 4. Using different fonts, font sizes and colors, for
> the same as in 3 or as parts of congratulation cards: ~3%.
> This is an anti-pattern. It's bad for users and bad for accessibility. There
> is a reason most modern messaging systems leave it out. If I have a black
> background and you send me messages with your text color set to black, I
> can no longer read it. If you set your font to be tiny and I'm hard of
> seeing, I can no longer read it. If you set it to be huge and I'm on my
> phone, it takes up half the screen and I'm annoyed. etc.
> 
> That's mostly abuse. Most of the features of any client could be abused. 

My mother certainly doesn’t think it’s abuse to set her email font to Comic 
Sans in orange on purple background with 18pt. For me it is still annoying, 
hard to read, and (one of) the reason why my client strips HTML.

It hinders clean UI design a lot.


> A user should have a feature, and it's up to him how to use it. If he abuses
> font or color customization, other party will tell him not to do it or just
> ban him that or other way.

Speaking of which, please, turn HTML off when sending to the list. Thanks.


> Yes. Embebbed links are useful when link itself is too long and contains no
> useful information. I beleive that only human friendly content should be
> displayed in the message and the technical parts (like URLs) should be
> hidden.

This has a bunch of security implications. See the phishing mess HTML emails 
have gotten us into.


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-0394: too weak to replace XEP-0071

[Jonas Wielicki]

On Donnerstag, 15. März 2018 15:46:43 CET Kozlov Konstantin wrote:
> It sounds promising. I just wonder why no links and no font customization?

Yeah, I forgot to mention links (and possibly other things).

Font customization is out-of-scope, for the reasons Daniel stated. Just like 
setting background color.

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] [STANDARDS] XEP-0394: too weak to replace XEP-0071

[Jonas Wielicki]

On Donnerstag, 15. März 2018 11:31:37 CET W. Martin Borgert wrote:
> On 2018-03-15 10:22, Kozlov Konstantin wrote:
> > I don't want to discuss XEP-0393, 'cause the whole idea of using LML in IM
> > sounds bad. Flaws if it is obvious, so it's needless to mention them
> > again.
> 
> I disagree. Yes it is ugly, but having a widely used LML, such
> as Markdown (in contrast to some strange homebrew) in XMPP would
> be a pragmatic approach, IMVHO.
> 
> Many people know Markdown syntax nowadays, there are parsers for
> it in many different programming languages, and we already know
> how ugly and illogical it is. Just needs a new XEP :~)

The rationale against Markdown or RST was that people would do virtually the 
same they did for XHTML-IM which lead to funny security issues (which lead to 
XHTML-IM being deprecated): use arbitrary markdown parser, put result in HTML 
DOM.

Now many markdown parsers allow pass-through of HTML by default. 
reStructuredText allows .. raw:: html. Both is not desirable, which is why the 
author of '393 (with support from the community, afaict) decided to *not* do 
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
___

Re: [Standards] Call for Experience: XEP-0066: Out of Band Data

[Jonas Wielicki]

On Mittwoch, 7. März 2018 20:17:29 CET Jonas Wielicki wrote:
> 1. What software has XEP-0066 implemented?

We have support for the  flow in JabberCat (GPLv3), like in gajim 
and Conversations as already mentioned elsewhere in this thread.

We do not implement the IQ workflow, nor do we intend to do so. This is not 
due to lack of peers which support this (even though if a large number of 
clients were actively using that, we would probably follow), but we think that 
there are better alternatives out there.


> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0066?

The  flow is super straightforward. However, I think it is too 
simple to be really useful. Things like MIME types, possibly a file size, 
would be good to have to allow for easier UI handling. I think that SIMS is 
more appropriate for this use-case.


> 3. Is the text of XEP-0066 clear and unambiguous?

Frankly, I didn’t read most of the text. I implemented this for compatibility 
with Conversations and others.

For the same reason, I don’t think that the XEP as-is should go to Final. Much 
of it seems to not be implemented as evidenced by the list feedback. It also 
feels superseded by more modern methods of transfer.


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-0394: too weak to replace XEP-0071

[Jonas Wielicki]

On Donnerstag, 15. März 2018 14:02:41 CET Daniel Gultsch wrote:
> What intrigues me on something markdown ish (albeit probably something
> more than Styling currently has to offer) are its limitations.
> Particularity no color (that will never work in a federated
> environment where you don't know the design language and color scheme
> of the receiving application) and the lack of tables and such (tables
> will never work if you don't know the size of the displaying device)
> If we want to go with something more xml~ish I would prefer to
> annotate meaning (headline, importance, et al) instead of the
> availibilty of color and absolute font sizes and font family was
> something that annoyed me the most in XHTML-IM (despite the security
> flaws in the implementations)

Okay, so since I’m not going to get around to updating '394 this month and 
there’s considerable interest, I’ll write down what I have in mind:

* Emphasis, Strong emphasis, inline-preformatted (code)
* Enumerations
* Itemized lists
* Headings (two or three levels)
* Paragraphs
* XEP-0392-based colors (i.e. you only give a hue and the remainder is handled 
by the recipient)
* Code blocks with annotation of the language for optional receiver-side 
highlighting
* Maybe inline images

Now there has been a lot of discussion around how to make this degrade 
gracefully. I’m thinking of the following:

Each markup annotation has a mandatory pre- and postfix in the body which is 
stripped once the markup is applied. That works like this (just a rough 
outline, don’t take the syntax for literal):

This is the *new* markup.

  


Now  would be defined so that the selected range of  MUST 
start with "*" and MUST end with "*". If-and-only-if (iff) that is the case, 
the prefix and postfix is removed and the text is displayed with emphasis 
applied on the word "new".

This is complex, and will not get less complex with more complex constructs 
like enumerations.

The reason for this complexity is that it allows a '393-compatible  
message, and also in general a good human-readable representation in clients 
which do not support it (if we chose the requirements well), while at the same 
time not allowing to "delete" arbitrary characters for some readers (it has 
been pointed out that this type of discrepancy can lead to problems).

So as a timeline, before updating '394, I want to:

- Draft an actual implementation of this scheme in JabberCat
- Figure out ways to represent the more complex elements

Unfortunately and as I mentioned, I have other priorities currently which is 
why this won’t happen this month. Sorry. However, I’d be interested in 
feedback to this approach and in general.

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-0394: too weak to replace XEP-0071

[Jonas Wielicki]

On Donnerstag, 15. März 2018 13:36:50 CET VanitasVitae wrote:
> I would claim that a huge part of XMPP nowadays happens on mobile devices
> and I haven't seen a single rich text editor in any mobile application.
> Thats why I think that markdown is the way to go.
> 
> Sending greeting cards in html sounds like an idea from the 90s to me (not
> saying that it isn't a usecase, I just haven't come across it yet).

I’m going to repeat why I think that Markdown-ish things aren’t enough: There 
is interest especially in the kind of groups which would use Slack or 
Mattermost to have rich-text messages. Those are usually not generated by 
users, but by automated systems (for example monitoring). I’m not saying that 
we should slap a rich-text editor in front of a user (even though I certainly 
won’t stop anybody). I’m also saying that '393 is a really good input format, 
which is why I want to make '394 compatible to that (as mentioned in the 
threads back then).

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-0372: References

[Jonas Wielicki]

On Montag, 12. März 2018 16:31:57 CET Sam Whited wrote:
> On Mon, Mar 12, 2018, at 10:17, Jonas Wielicki wrote:
> > This is true, XML restricts to Scalar Values. Thanks, I didn’t know that
> > term.
> Your entire reply seems to be hinged on the fact that all XML libraries
> return scalar values

No, I’m arguing in terms of the XML standard, not implementations. But let’s 
go down that route.

> , but this isn't true to my knowledge. Most XML
> libraries are going to do whatever the language they're written in does. If
> you're using Python 3, you're going to get scalar values

Yep. (There are numerous XML library bindings for Python all of which, to my 
knowledge, return str (a sequence of codepoints), I’m not quoting each 
individual one)

> (assuming it's
> returning a string which in Python 3 is scalar values… more or less), if
> you use libxml2, or expat, or the 

libxml2 uses UTF-8 internally, but aliases the xmlChar type, which is intended 
to be used with the xmlUTF8 family of functions providing access to the 
Codepoints. [1]

libexpat uses UTF-8 or UTF-16 (compile time switch, XML_UNICODE) and leaves  
the developer alone with that, as far as I can tell. [2]

> Go encoding/xml library, etc. you're probably going to get bytes.

This one’s funny. It doesn’t specify which encoding you get when you unmarshal 
into a []byte. string is clear, and UTF-8 internally, but string uses the 
concept of runes which are Codepoints [3]. Unmarshaling has the option of 
using either.


I have no knowledge about Java or Rust though. AFAIK with JavaScript one is 
doomed anyways, since it can only do UTF-16, which will be a PITA no matter 
which route we go.


Acknowledging that XMPP enforces UTF-8 (so it would be a reasonable choice to 
use UTF-8 for everything in an implementation which chooses to go down that 
route), I’m not going to die on this hill. Still, using bytes of UTF-8 in a 
layer which clearly operates on Character Data defined in terms of Scalar 
Values is breaking abstractions for no gain (on the contrary, we’ll have to 
add wording on how to handle mid-UTF-8-word ranges; in the case of 
implementations which already get code points one needs an additional encode-
to-utf8-step + validation; implementations which already work on UTF-8 need 
the utility functions to operate on code points anyways).


kind regards,
Jonas

   [1]: http://www.xmlsoft.org/html/libxml-xmlstring.html
   [2]: https://www.xml.com/pub/1999/09/expat/index.html

If this isn’t up-to-date, sorry. I wasn’t able to find anything more 
recent on the expat website.
   [3]: https://blog.golang.org/strings

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-0372: References

[Jonas Wielicki]

On Montag, 12. März 2018 15:56:04 CET Sam Whited wrote:
> On Mon, Mar 12, 2018, at 09:20, Jonas Wielicki wrote:
> > FWIW, I’d argue that using codepoints is much saner,
> > because those are readily available and consistent across all receiving
> > entities of the same message. (Even though this potentially introduces
> > some
> > interesting edge-cases when somebody creates a references starting in the
> > middle of, e.g., an emoji sequence.)
> 
> I agree that "characters" needs to be specified, but codepoints (or, to be
> pedantic, "scalar values" which is a subset of codepoints and is all we
> need to worry about in XMPP/UTF-8 land) 

This is true, XML restricts to Scalar Values. Thanks, I didn’t know that term.

> is probably the wrong way to do it.
> Codepoints doesn't really get us anything over bytes, 

They do, because implementations may not even have the bytes representation 
around or accessible, because, as you say, XML operates on Unicode Scalar 
Values, not on Scalar Values encoded to UTF-8 bytes.

(Now, you could argue that XMPP on its lowest level indeed is UTF-8 encoded, 
which is true. However, having an XML parser inbetween usually abstracts you 
away from that and you might still not have access to UTF-8 encoded bytes but 
only sequences of Scalar Values and still have a perfectly good (I would 
personally even argue, superior) XML imlpmentation.)

> because just as
> scalar values can be made up of multiple bytes, glyphs (or "grapheme
> clusters") may be made up of multiple scalar values (and, as you pointed
> out, the range could end in the middle of a grapheme cluster that uses
> multiple scalar values).
> 
> In my mind there are only two things that make sense here:
> 
> - Use bytes and come up with a way to handle bad ranges that end in the
> middle of a UTF-8 sequence 

That proposal does not make sense at all. It doesn’t solve the issue of having 
a range start or end in the middle of a grapheme cluster, and it introduces 
extra complexity by requiring implementations to re-obtain a UTF-8 
representation of the character data (or keep it around). Sounds like the 
worst of both worlds (Grapheme Clusters vs. Scalar Values). XML Character Data 
is specified in Scalar Values (they call it Characters, but it really is a 
Scalar Value minus \u and \uFFFE), so it makes most sense to re-use that.

> - Use grapheme clusters and require that
> everyone implement the segmentation algorithm

This will bring us all kinds of issues with different unicode versions.

> I lean towards bytes because it keeps things simple and 

Then let’s stay with Scalar Values, which is what XML works with, instead of 
using a lower-level representation.

> I doubt we'd see
> much adoption if we used grapheme clusters

I agree.


If we want to find a middle way, I would suggest the following (in addition to 
switching to Scalar Values as index base for @start and @end):

> If an implementation uses references to apply any kind of markup to the 
> text range referred to by the reference, it SHOULD ensure that the @start 
> points to the beginning of a Grapheme Cluster and @end to the end of a 
> Grapheme Cluster.

An implementation may also just attach something to the whole message or in 
another way interpret the reference without paying attention to @start and 
@end.

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-0283 Moved - Security and Usability

[Jonas Wielicki]

Hi Georg,

Thanks for taking this up.

On Freitag, 9. März 2018 17:53:27 CET Georg Lukas wrote:
> XEP-0283 "Moved" provides the signaling mechanism to make this possible,
> with two "little" issues:
> 
> 1) the Security Considerations spoil all the fun of automatic account
> 
> transfers:
> | In order to prevent other users from maliciously altering contacts the
> | client SHOULD NOT automatically subscribe to a  JID when it
> | receives an unsubscribe and SHOULD NOT automatically unsubscribe to a
> |  JID when it receives a subscribe.
> 
> I think that if our contact proves ownership of both accounts by
> publishing a  element on each, containing the respective other
> JID, there should be no security problems with automatically replacing
> the contact's JID on our roster.
> 
> While in theory, someone with short-term access to our account will be
> able to permanently steal all our contacts, I would consider that
> account as fully compromised anyway, and the attacker can well perform
> any other kind of impersonation or social engineering attack they want.

This only works for mutual subscriptions. Non-mutual subscriptions can’t 
easily be transferred this way I think. I also don’t think that non-mutual 
subscriptions are a common case to worry about and manual intervention (as 
described in §3.7.1) may be acceptable there. If we really want to make this 
work automatically, additional protocol (outside of ) could be 
invented for that.

> 2) the flow in §3.1 does an 'unsubscribe' with a payload, and most
> servers won't keep that payload after processing the unsubscribe.
> However, we could just set the  payload to a normal (directed or
> broadcasted) presence as proof of account ownership and let the
> receiving entity auto-unsubscribe once the "new" account has also
> signalled the intent to move.

This has the downside that the receiving entity needs to support the protocol 
for the unsubscribe to work automatically (while the unsubscribe would work 
automatically without support on the receiving side; the subscribe would 
obviously not).

If we assume that this feature is to be implemented server-side, I don’t see 
the benefit changing this.


> I'd like to resurrect the XEP, allow automatic approval of contacts' JID
> changes (and maybe also invent some way to also move local/MAM history
> for that contact).

Seems like a plan.


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
___

[Standards] XEP-0372: References

[Jonas Wielicki]

Hi list,

Some feedback on XEP-0372 references from me after reading it thoroughly for 
the first time [1].

First, it uses ranges of "characters" into , but doesn’t specificy 
which language. Since there can be multiple  elements with different 
effective xml:lang values, this is ambiguous. I think this needs resolving in 
one way or the other. FWIW, I’d argue that using codepoints is much saner, 
because those are readily available and consistent across all receiving 
entities of the same message. (Even though this potentially introduces some 
interesting edge-cases when somebody creates a references starting in the 
middle of, e.g., an emoji sequence.)


Second, I think that the way the type of the reference is specified isn’t 
actually great. There is no way to "subclass" this protocol in a sane manner 
due to the lack of (standardised) namespacing of the @type attribute. Also, 
while it may make sense to have some very generic attributes like @uri on the 
reference, other type-specific things don’t belong there, IMO (it makes 
validation much harder).

I would suggest to follow an approach which allows a bit more extensibility by 
having the type of the reference determined by a child element, like so:






This also prevents us from having to cram a thousand different meanings into a 
URI, creating ambiguity on the way. A pubsub node publication could be much 
cleaner referenced by:





Likewise for messages:





If we want to keep generic URI references:






Now I’m not sure how to integrate the  idea into that. The idea is 
neat, but the lack of standardization for URIs for different objects (such as 
pubsub items, MUC messages, MIX messages, one-on-one messages etc.) in XMPP 
makes it seem that using an URI is not a great idea at this point. In general, 
it would be neat to have such URIs properly specified.

kind regards,
Jonas

   [1]: I’m doing this while evaluating how to implement Emoji Reactions. cf.
https://github.com/jabbercat/jabbercat/issues/80. But the commentary
is not focused on this use-case at all.

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-0283 Moved - Security and Usability

[Jonas Wielicki]

On Freitag, 9. März 2018 18:16:25 CET Sam Whited wrote:
> On Fri, Mar 9, 2018, at 10:53, Georg Lukas wrote:
> > as part of Easy XMPP I wanted to have a way to completely migrate from
> > one account to another, or to be able to move a subset of your contacts
> > to another (local) JID.
> 
> What is the use case you're trying to address here? And who do you expect to
> use this feature? It doesn't seem like something that's broadly useful or
> that would make normal users lives easier in any significant way.

IANAL, but it might actually be a mandatory (or at least strongly suggested) 
feature for entities offering services within the EU due to the EU-GPDR. See 
Article 20 :

> In exercising his or her right to data portability pursuant to paragraph 1, 
> the data subject shall have the right to have the personal data transmitted 
> directly from one controller to another, where technically feasible.


Aside from that, Georgs arguments for "servers which become unmaintained" are 
very sound.

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-0393 and XEP-0394 naming

[Jonas Wielicki]

On Donnerstag, 8. März 2018 17:18:02 CET Kozlov Konstantin wrote:
> Hello!
>  
> 08.03.2018, 19:03, "Sam Whited" :
> On Thu, Mar 8, 2018, at 10:01, Kozlov Konstantin wrote:
> 
>  I think "Markup" more suits
>  for XEP-0393 and "Styling" for XEP-0394.I guess, we should think about
>  renaming those XEPs to make their names
>  less confusing.
> 
> I'm not against this (as the author of 0393) if people find this confusing,
> but swapping the names seems even more confusing to me.
> 
> The XEPs are not so widely implemented for the moment to care much about it.
> Anyway, we can just give new, less confusing names for both XEPs.
> For example we may rename XEP-0393 to "Markdown" 'cause its syntax somewhat
> similar to Markdown  language. 

For the love of whatever is holy to you, don’t call it Markdown. You don’t 
know which pandoras box you’re opening there.

I’ll rename XEP-0394 on the next update to something more unique.

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] OBSOLETED: XEP-0071 (XHTML-IM)

[Jonas Wielicki]

On Donnerstag, 8. März 2018 10:38:55 CET Kozlov Konstantin wrote:
> Hello!
>  
> 08.03.2018, 12:18, "Dave Cridland" :
> The personal choice of Council was to deprecate XHTML-IM based on
> these facts. The previous Council decided to ensure there were
> alternates for XHTML-IM use-cases instead of deprecating.

This was an editors mistake. The Council voted to Deprecate, not to Obsolete. 
I rectified the issue and I’m going to send out an email when the update is 
live on the website. Thanks for bringing this up and sorry for the 
inconvenience.

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: XEP-0048: Bookmarks

[Jonas Wielicki]

On Donnerstag, 8. März 2018 08:28:27 CET Daniel Gultsch wrote:
> 2018-03-08 8:22 GMT+01:00 Jonas Wielicki <jo...@wielicki.name>:
> > On Donnerstag, 8. März 2018 07:38:42 CET Daniel Gultsch wrote:
> >> It feels a bit sad that we aren't able to advance a XEP that is widely
> >> deployed (in a way) but I think it is just too late.
> > 
> > Can’t we revert to XEP-0049 (if no other XEP-0223 implementations show
> > up),
> > advance *that* to final and make a new thing properly based on XEP-0223,
> > with multi-item layout and fancy stuff? I would love if we could take
> > that opportunity to add roster-like groups to bookmarks.
> 
> I don’t think XEP48 over 49 solves the requirements we have today as
> outlined in my previous mail.

That’s very true, even though it *does* reflect the reality. Deprecation 
maybe? Wouldn’t be the first thing we deprecate without real replacement…


> Further advancing that would benefit nobody (I don‘t think we would
> see even more implementations and on the other hand it might confuse
> new comers and guide them towards something that is just not up the
> requirements we have today)

In any case, having the XEP strongly suggest a mechanism which is in fact not 
deployed is also adding (frustrating, because you end up implementing 
something only to learn that it doesn’t work; similar for XEP-0084 vs. 
XEP-0153) confusion for newcomers.

I also think that that the 223 version of things may need more experimentation 
than Draft state may be able to deliver (for example, the single vs. multi-
item issue). Not to mention that multi-item PEP may have even more deployment 
restrictions than persistent, private PEP itself.

But sure, leaving this in Draft as-is would work. But it doesn’t alleviate the 
confusion caused.


> Advancing this only for the sake of advancing something is misguided.

That’s for sure.


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] OBSOLETED: XEP-0071 (XHTML-IM)

[Jonas Wielicki]

On Donnerstag, 8. März 2018 07:54:04 CET Evgeny Khramtsov wrote:
> Wed, 07 Mar 2018 21:33:13 +0300
> 
> Kozlov Konstantin  wrote:
> > So, the only reason to obsolete the XEP is not the XEP itself, but
> > bad implementations?
> 
> Yes. This is kinda religion among some Council members that if a
> technology can be misused then it should be deprecated. Their religion
> is, however, quite picky: there is a well-known list of security
> problems in XML (including the famous billion laughs attack), but they
> don't consider to get rid of XML.

How many XMPP clients have you seen which were owned by Billion Laughs (which 
uses entities which are explicitly forbidden in RFC6120 and trivial to turn 
off in all XML parsers I’ve seen so far) compared to the amount of XMPP 
clients Sam has found which were vulnerable to XHTML-IM XSS attacks? I think 
the comparison might not hold up, but I’m open for data. (Likewise for any 
other XML vulnerability.)

Maybe you could make a server module which stress-tests clients against that 
type of input. I’d be interested, but that’s off-topic to the XHTML-IM 
discussion.

Also, XML vulnerabilities are both well-known and easy to test against (in the 
sense: it is easy to write an automated test which ensures that code is not 
vulnerable). I don’t think that’s so trivial with XSS attacks. During the 
XHTML-IM debate I learnt that even CSS can be an XSS vector (in some really 
broken implementations; not to mention possible privacy implications by using 
background: url(…) etc.), at which point I concluded for myself that XHTML-IM 
as it is is irresponsible because sanitization is so complex that nobody is 
going to do it completely, and those who are will most likely get it wrong. 
(My proposal to have someone create a reference implementation of a sanitizer 
in a language which would be most-reusable in this domain (probably JS) and 
have it professionally reviewed unfortunately didn’t gain traction.)

In contrast to XML, XHTML-IM is a custom thing which needs to be re-
implemented in ~every client. Well-known XML libraries exist for most 
languages (even if they only FFI to libxml2 or libexpat).

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: XEP-0048: Bookmarks

[Jonas Wielicki]

On Donnerstag, 8. März 2018 07:38:42 CET Daniel Gultsch wrote:
> It feels a bit sad that we aren't able to advance a XEP that is widely
> deployed (in a way) but I think it is just too late.

Can’t we revert to XEP-0049 (if no other XEP-0223 implementations show up), 
advance *that* to final and make a new thing properly based on XEP-0223, with 
multi-item layout and fancy stuff? I would love if we could take that 
opportunity to add roster-like groups to bookmarks.

This would also solve the documentation issue regarding XEP-0049 usage in this 
XEP which also has been brought up. Not sure if this is cannons against 
sparrows here, just throwing an idea into the 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] Call for Experience: XEP-0048: Bookmarks

[Jonas Wielicki]

On Mittwoch, 7. März 2018 20:17:24 CET Jonas Wielicki wrote:
> 1. What software has XEP-0048 implemented?

We have support for Private XML (XEP-0049)-based bookmarks in aioxmpp (LGPLv3) 
and based on that in JabberCat (GPLv3). We haven’t gotten around to implement 
PEP-based bookmarks, even though PEP is generally supported. Lack of proper 
server-side support has delayed that.

> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0048?

- The lack of deployment support for private PEP storage is unfortunate. Until 
recently, documentation was lacking that one should be supporting XEP-0049 
storage at least read-only, too.

- The PEP-based protocol is not ideal. It still stores everything in a single 
item, which makes it prone to race condition issues when multiple clients 
modify the bookmarks at the same time (which could, e.g., happen while an 
invitation is processed). Ideally, PEP storage would use one item per 
bookmark.

> 3. Is the text of XEP-0048 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
> Have developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.

We might want to specify how unknown child elements/attributes on bookmark 
data shall be treated (discard/keep on update). Some implementations have been 
putting extra things there. Maybe the default behaviour follows from RFC 6120 
(which would be discard, I think), but I’m not sure.

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] OBSOLETED: XEP-0071 (XHTML-IM)

[Jonas Wielicki]

Due to popular request, I’m going to re-post the reply I gave earlier on 
GitHub:

The core reason is that it caused quite a few XSS vulnerabilities. There are 
lengthy threads on the standars mailing list:

* starting with Security issues with XHTML-IM (again) [1]
* some discussion on replacement in Rich(er) text in IM vs XHTML docs [2] 
* collection of replacement requirements in Formatting Use Cases [3]

And much more. I recommend you to browse the archives if you really want to 
get the whole picture. The XMPP standards community has discussed this at 
length and the final ruling of the council is in the respective meeting 
minutes: Council Minutes 2018-02-14 [4] and MUC logs of the meeting [5]. 

---

As for an replacement, it depends on your use-case. There’s [XEP-0393] 
(Message Styling) which should cover many IM use-cases. I started to work on 
[XEP-0394] (Message Markup) which intends to do a bit more, with a more 
flexible approach. Note that I intend to overhaul XEP-0394 and I don’t know of 
any implementations. XEP-0393 is implemented in a few clients already (I know 
of Conversations and yaxim).


kind regards,
Jonas

   [1]: https://mail.jabber.org/pipermail/standards/2017-October/033546.html
   [2]: https://mail.jabber.org/pipermail/standards/2017-October/033596.html
   [3]: https://mail.jabber.org/pipermail/standards/2017-October/033702.html
   [4]: https://mail.jabber.org/pipermail/standards/2018-February/034302.html
   [5]: http://logs.xmpp.org/council/2018-02-14/#16:03:14
   [XEP-0393]: https://xmpp.org/extensions/xep-0393.html
   [XEP-0394]: https://xmpp.org/extensions/xep-0394.html


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-0313 missing features

[Jonas Wielicki]

On Dienstag, 6. März 2018 14:19:41 CET Kevin Smith wrote:
> On 6 Mar 2018, at 13:14, Jonas Wielicki <jo...@wielicki.name> wrote:
> > I think it would be great to have a way to limit the MAM query to an
> > end-ID
> > indeed. Matt, Kevin, any chance we get that in?
> 
> Set both the before and after IDs. Done. Just need to make sure 313’s clear
> that this is supported, and that if done you page backwards.

Would you be updating RSM in the process or would this be a MAM-specific 
addition to RSM? The latter would be unfortunate both for client 
implementations (separation of concern) and for possible future development of 
RSM. The former would be unfortunate because reverse paging may not always be 
desirable for all RSM users when both  and  are given.

Am I missing something?

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-0313 missing features

[Jonas Wielicki]

On Dienstag, 6. März 2018 13:23:21 CET Lazar Otasevic wrote:
> Conclusion:
> 
> 1. it is not possible to iterate efficiently backwards by including both
> & in the query because once  is included in the query
> then it iterates forwards. that means when iterating backwards client has
> to omit  and fetch entire pages and then the last page will mostly
> overlap with some of the local messages, which is a waste.
> 2. it is not possible to determine "holes" in the archive reliably, because
> client can not know what is the last message archive-id, because our own
> sent messages have no feedback from the server once the message is archived
> what is its archive-id ... that means that client has to fetch ALL messages
> from MAM once again just to be sure that holes are filled, even though many
> message-bodies are already received/sent during live communication.
> 
> Basically In the current state all our own messages are "holes" in the
> local archive, not to mention all kind of "bad network" scenarios,
> multi-device and longer offline periods.
> 
> Making separate requests, one for archive ids and one for content would
> make:
> - much less waste in the sync because only ids would be wasted, and not the
> content
> - possible to fill multiple holes in one request by fetching content that
> is really needed
> - make possible for push payloads to contain only message ids (when clients
> want to handle encrypted messages locally by fetching them and only them)
> currently it is doable by giving to the push one id before the wanted
> message

So I might be wrong, but for the sake of it, I think there is a sane and not 
too complex way to do archive sync with MAM:

1. On startup, you put a "hole marker" at the end of your local archive. A 
hole marker is essentially just the stanza-id of the last message at the time 
the marker is created.
2. Iterate over all hole markers, from newest to oldest. Download everything 
between the last message *before* and the first message *behind* the hole 
marker. During download, move the hole marker accordingly to deal wtih 
disconnects while downloading. When finished, remove the hole marker; move on 
to the next hole marker if there’s any.

This should work and should also work with current semantics. I appreciate 
that there *might* be some overlap between the last page of a hole and already 
received messages. This is unfortunate, but can trivially be solved by 
comparing stanza-id (if available locally) or origin-id or message id in that 
order. (N.B.: once we get self-carbons, we’ll always have the stanza-id)

I also wrote that down in more detail here: 
https://github.com/jabbercat/jabbercat/issues/26#issuecomment-370333729


I think it would be great to have a way to limit the MAM query to an end-ID 
indeed. Matt, Kevin, any chance we get that in?

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-0313 missing features

[Jonas Wielicki]

On Dienstag, 6. März 2018 14:02:49 CET Philipp Hörist wrote:
> You dont need to determine holes, maybe you should first come up with a
> scenario where this "hole" of yours can even happen.
> 
> 1. if you receive a message live you get the archive-id, then you save it.
> 2. You go offline
> 3. Once you come later you request after = archive-id
> 4. repeat

Disconnect *while* (3) is in progress and after you have received at least one 
live message.

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] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

[Jonas Wielicki]

Hi Peter,

Thank you very much for the clarification, comments inline.

On Dienstag, 6. März 2018 02:59:04 CET Peter Saint-Andre wrote:
> On 3/5/18 12:17 AM, Jonas Wielicki wrote:
> > On Sonntag, 4. März 2018 19:42:39 CET Peter Saint-Andre wrote:
> >> On 3/4/18 10:54 AM, Jonas Wielicki wrote:
> >>> On Sonntag, 4. März 2018 17:02:07 CET Peter Saint-Andre wrote:
> >>>> If we want to specify this, I would recommend the UsernameCaseMapped
> >>>> profile defined in RFC 8265.
> >>>> 
> >>>> However, there's a twist: if a node ID can be a full JID, then do we
> >>>> want to apply the normal rules of RFC 7622 to all the JID parts,
> >>>> instead
> >>>> of one uniform profile such as UsernameCaseMapped to the entire node
> >>>> ID?
> >>>> For instance, the resourcepart of a JID is allowed to contain a much
> >>>> wider range of Unicode characters than is allowed by the
> >>>> UsernameCaseMapped profile of the PRECIS IdentifierClass (which we use
> >>>> for the localpart).
> >>>> 
> >>>> Given that a node ID can be used for authorization decisions, I think
> >>>> it's better to be conservative in what we accept (specifically, not
> >>>> allow the wider range of characters in a resourcepart because
> >>>> developers, and attackers, could get too "creative").
> >>> 
> >>> I would argue that adding those restrictions / any kind of string
> >>> prepping
> >>> to XEP-0060 or XEP-0030 nodes is (a) too late and (b) ambiguous at
> >>> least,
> >>> as you mentioned (depending on the data).
> >> 
> >> I would argue that not specifying normalization rules is a security hole
> >> (e.g., allowing an attacker to gain unauthorized access to a node). Just
> >> because we should've done this years ago doesn't mean we can fix it now.
> > 
> > Hm, okay, I don’t seem to understand the attack vector. Could you spell it
> > out more clearly to me?
> 
> Here's a true, non-XMPP example: I have the account stpe...@gmail.com.
> However, Google ignores "." in the localpart. Therefore I receive some
> email messages intended for st.pe...@gmail.com. I could probably reset
> passwords (via email-based authentication) and take over other accounts
> associated with st.pe...@gmail.com.
> 
> Similarly, let's say you create a node "foo2" at pubsub.example.com. If
> I know that this service decomposes superscript characters to their
> compatibility equivalents, I could create a node "foo²" (the last
> character is U+00B2 = SUPERSCRIPT TWO) and the service would consider it
> to be the same as "foo2". Now I can publish notifications to your node
> without ever trying to take over your account - I just use my "foo²" node.

Okay, that all makes sense, but it seems to me that this is due to the 
*presence* of a normalization, not the absence. That’s where my confusion came 
from. I think the absence of a normalization (or specifying that absence) is 
not going to do us harm. That is what I was trying to say when I said that 
"I’d also argue that nodes aren’t shown or typed into a field by users 
normally, so I would not worry about that kind of normalization here.": Since 
users aren’t confronted with them, lookalikes etc. should not be an issue and 
do not need to be normalized.

If we’re going to specify that "node names etc. need to be taken as-is and 
compared codepoint-by-codepoint [I can’t look up the name of that collation 
right now] and must not be normalized in any way by the service", that makes 
sense to me; I think most services, if not all, already operate this way.

Otherwise, I think we’ll have to think hard about the implications of 
introducing a normalization/preparation method this far into deployment and 
how to handle unnormalized input [1]. XEP-0030 is Final and used ~everywhere, 
XEP-0060 is Draft and a key dependency to a few modern features (via PEP). 
Having the ecosystem move from "no preparation" to "some preparation" feels 
like it’s bound to introduce exactly the type of bugs you were talking about.

Add to that the trickiness if we want to use JIDs as node names, I’d argue 
that a "don’t touch this" directive to the server makes sense. If a protocol 
has specific requirements for node names specifically in PubSub, I think it 
could still specify that.

Does this make sense?

kind regards,
Jonas

   [1]: Given the lack of even resourceprep validation in current servers,
I’d also not put my money on "servers will validate and reject any
invalid node names".

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
___

[Standards] XEP-0390: use of separators which are valid (but discouraged) in XML 1.1 (as opposed to 1.0)

[Jonas Wielicki]

Dear list,

Florian discovered that the ASCII separators we use, while invalid in XML 1.0 
(upon which RFC 6120 bases), are only discouraged in XML 1.1. 

I wonder whether we should be concerned about this. While the XML parsers I 
tested back then *did* reject those ASCII characters, I wonder whether we can 
rely on that.

Another solution would be to use some kind of length field instead of 
separators. Or use unary NUL separators (though I haven’t checked whether 
those are valid in XML 1.1).

Opinions?

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] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

[Jonas Wielicki]

On Sonntag, 4. März 2018 19:42:39 CET Peter Saint-Andre wrote:
> On 3/4/18 10:54 AM, Jonas Wielicki wrote:
> > On Sonntag, 4. März 2018 17:02:07 CET Peter Saint-Andre wrote:
> >> If we want to specify this, I would recommend the UsernameCaseMapped
> >> profile defined in RFC 8265.
> >> 
> >> However, there's a twist: if a node ID can be a full JID, then do we
> >> want to apply the normal rules of RFC 7622 to all the JID parts, instead
> >> of one uniform profile such as UsernameCaseMapped to the entire node ID?
> >> For instance, the resourcepart of a JID is allowed to contain a much
> >> wider range of Unicode characters than is allowed by the
> >> UsernameCaseMapped profile of the PRECIS IdentifierClass (which we use
> >> for the localpart).
> >> 
> >> Given that a node ID can be used for authorization decisions, I think
> >> it's better to be conservative in what we accept (specifically, not
> >> allow the wider range of characters in a resourcepart because
> >> developers, and attackers, could get too "creative").
> > 
> > I would argue that adding those restrictions / any kind of string prepping
> > to XEP-0060 or XEP-0030 nodes is (a) too late and (b) ambiguous at least,
> > as you mentioned (depending on the data).
> 
> I would argue that not specifying normalization rules is a security hole
> (e.g., allowing an attacker to gain unauthorized access to a node). Just
> because we should've done this years ago doesn't mean we can fix it now.

Hm, okay, I don’t seem to understand the attack vector. Could you spell it out 
more clearly to me?

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] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

[Jonas Wielicki]

On Sonntag, 4. März 2018 17:02:07 CET Peter Saint-Andre wrote:
> If we want to specify this, I would recommend the UsernameCaseMapped
> profile defined in RFC 8265.
> 
> However, there's a twist: if a node ID can be a full JID, then do we
> want to apply the normal rules of RFC 7622 to all the JID parts, instead
> of one uniform profile such as UsernameCaseMapped to the entire node ID?
> For instance, the resourcepart of a JID is allowed to contain a much
> wider range of Unicode characters than is allowed by the
> UsernameCaseMapped profile of the PRECIS IdentifierClass (which we use
> for the localpart).
> 
> Given that a node ID can be used for authorization decisions, I think
> it's better to be conservative in what we accept (specifically, not
> allow the wider range of characters in a resourcepart because
> developers, and attackers, could get too "creative").

I would argue that adding those restrictions / any kind of string prepping to 
XEP-0060 or XEP-0030 nodes is (a) too late and (b) ambiguous at least, as you 
mentioned (depending on the data).

I’d also argue that nodes aren’t shown or typed into a field by users 
normally, so I would not worry about that kind of normalization here.

If a specific XEP-0030/XEP-0060-based protocol needs more guarantees, I think 
those can be defined there.

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] Releases

[Jonas Wielicki]

On Sonntag, 4. März 2018 10:29:02 CET Gerion Entrup wrote:
> Hi,
> 
> I'm a user of XMPP and have very mixed experiences with different clients.
> 
> There are clients that do very well and implement a lot of availabe XEPs,
> but other clients only implement a fraction of available XEPs. The XEPs are
> optional, if I get it right, but the user experience varies a lot with
> dfferent set of XEPs.
> 
> I found it difficult to get a list of supported XEPs by client and it is
> time consuming to understand what XEPs are for what feature. So a propasal
> I have is to do releases (of the standard).
> 
> A release contains a set of new (final) XEPs and a list of obsolete XEPs and
> all clients and servers that support XMPP version X have to implement this
> XEPs.

I tend to like this idea, as already mentioned in a past post in another 
thread:

https://mail.jabber.org/pipermail/standards/2018-February/034314.html
plus the context in
https://mail.jabber.org/pipermail/standards/2018-January/034181.html

I would extend it beyond Final (at least Draft) though :-).

> That would allow users to see, what a client is capable of. That would also
> allow client to show a message to there users about the client on the other
> end does not support XMPP version X and so there are some features that are
> not supported. 

Technically, we can already do that for each individual feature, thanks to 
XEP-0030 Service Discovery features. However, the trickiness is when Message 
Carbons, multiple devices and Message Archive Management come into play. 
Example:

You might detect that one of the two clients you’re currently talking to does 
not support Last Message Correction. Would you still allow the user to use 
LMC? The other device supports it; and since the messages will be archived, 
the user may be using other devices which support it, too.

> This also adds the abbility to generate some easy press
> coverage about the state of XMPP.

Possibly seconded.


I am still hoping for some feedback of the Council or other more experienced 
members of the community in regard to 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
___

Re: [Standards] xep-0313 missing features

[Jonas Wielicki]

On Samstag, 3. März 2018 23:53:21 CET Lazar Otasevic wrote:
> Hi, I think I miss some features here:
> 
> 1. fetching messages by giving a set of ids, also similar like xep-013
> 
> Fetching message by id(s) is needed  for example when i have a custom push
> notification with a given message id(s) and client needs to get that one
> message asap and show it in the chat.

From my limited understanding of MAM, it should be possible if your custom 
push thing gives you the stanza-id instead of the message-id. Query by stanza-
id is kinda what MAM is really good at.


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] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

[Jonas Wielicki]

On Donnerstag, 1. März 2018 08:52:29 CET Florian Schmaus wrote:
> On 01.03.2018 01:17, Peter Saint-Andre wrote:
> > On 2/28/18 3:18 PM, Timothée Jaussoin wrote:
> >> Hi,
> >> 
> >> I came across a database limitation while implementing Pubsub in Movim.
> >> 
> >> I'd like to know if we have a limitation for the size of the node and
> >> items ids in Pubsub (like we have for the JIDs). Also do we have some
> >> specific forbid characters, basically what is the format of such
> >> attributes? If noting is already specificed I think that it would be
> >> wise to update the 0060 to do so.> 
> > My inclination is to specify a length of 1023 octets
> 
> Which would break applications and protocols using JIDs as node or item
> identifier. This includes for example MIX. If we want to allow this, we
> need at least (3x1023)+2 octets, and then I would probably go for 4096
> octets.

This is bikeshedding territory. But given that databases have limits on the 
size of keys, using as many as needed and as few as possible octets (the 3071 
you quoted) is probably sensible.

Do those protocols use bare or full JIDs? If they only use bare and if we 
agree that full JIDs (due to their transience) do not make sense, the limit 
could conceivably be as low as 2047, which is probably comfortable for 
databases to handle.

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] Message-IDs

[Jonas Wielicki]

On Mittwoch, 28. Februar 2018 10:28:01 CET Kevin Smith wrote:
> On 26 Feb 2018, at 15:59, Simon Friedberger  wrote:
> > So, lest this discussion just die. Here is a proposal:
> Thanks for the proposal. Bashing follows.
> 
> >Client-A generates message-ID based on HASH(connection_counter,
> >server_salt). The connection_counter needs to be maintained only for
> >one connection. The server salt is server generated, anew for each
> >connection and is sent to.
> >
> >Server-A checks that this is correct and uses it for MAM. This
> >should make life easier for clients because they only need to deal
> >with one ID.
> 
> I think stopping servers being able to use their own IDs for DB storage is
> probably disadvantageous. Although I see the appeal of a client knowing its
> own MAM IDs, I’m not sure that simply knowing it is sufficient - you also
> need to know where it fits into the order of the archive, if you’re going
> to use it for archive sync, so I’m not sure this is actually buying
> anything, at the cost of of lack of flexibility in server implementations.

Good point about the order. This essentially means that we need a reflection. 
Self-carbons essentially. At which point we can simply let the server generate 
the ID(s).

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] Message-IDs

[Jonas Wielicki]

On Montag, 26. Februar 2018 16:59:46 CET Simon Friedberger wrote:
> So, lest this discussion just die. Here is a proposal:
> 
>   *
> 
> Client-A generates message-ID based on HASH(connection_counter,
> server_salt). The connection_counter needs to be maintained only for
> one connection. The server salt is server generated, anew for each
> connection and is sent to.
> 
>   *
> 
> Server-A checks that this is correct and uses it for MAM. This
> should make life easier for clients because they only need to deal
> with one ID.
> 
>   * Two problems need to be considered here:
>   o The client needs to maintain a counter. I don't know if there
> are cases where the client cannot persist this counter but keeps
> a connection. In this case a sufficiently fine grained timestamp
> to make it strictly monotonically increasing is suffcient. Even
> though I called it a counter, it does not need to be contiguous.
> It just needs to be increasing that the server can easily check
> that for a given salt value it is unique.
>   o The server needs to check the validity of the counter. If the
> server is actually replicated and consists of multiple machines
> this is not strictly possible. However, assuming normal
> operations the IDs generated by the client will be fine and if
> the servers have any mechanism for eventual consistency a
> misbehaving client will be detected. I think this fits the XMPP
> model of "robust cooperation".
>   *
> 
> Server-B gets the message via s2s. It changes the message-ID to a
> new one and stores the original as "origin-ID".
> 
>   *
> 
> Client-B gets a message with only TWO IDs. message-ID is for
> referencing locally for MAM, origin-ID is for referencing when
> talking to the sender i.e. read receipts.
> 
>   *
> 
> If a server generates follow-up messages it makes up a new
> sender-ID. It should maybe set a “triggered-by-ID” so the client can
> determine that it triggered this message. Maybe this is unnecessary.
> The server definitely must send the message it inserted back to the
> client to ensure a common view of history.
> 
>   *
> 
> If a server changes a message it can keep the sender-ID but it MUST
> notify the client who sent the message to make sure that clients
> have the same view of the history.
> 
> In this proposal stanza-IDs are not required. The message-ID is
> authoritative and when rewriting the original message-ID is kept as
> origin-ID.
> 
> From my original mail this solves C1, C2, C3, C4 and C5. Mostly just by
> defining them. This does not give us a global message-ID (C6) or
> unforgeable message-IDs (C7).
> 
> 
> Note, that I would prefer to have a globally unique ID. This is possible
> under the assumption that everybody tries to generate unique IDs and
> that non-unique IDs and misbehaving parties can be removed from the
> system. Essentially, it would look just like this except that the
> message-ID would have to include an ID for the originating server. That
> would allow recipients to check that connection_counter is increasing
> and the server_salt is unique for this server. The latter check might be
> hard to perform, though. It can still be solved using timestamps. This
> proposal seems much simpler, and it solves most of the problems.
> 
> 
> Also note, to make this a simpler change the clients could set both
> origin-ID and message-ID. The stanza-ID for MAM would turn out to be the
> same. This would be very similar to what is probably currently the most
> widespread behavior. Except that the origin-ID should be used for
> read-receipts, etc.
> 
> 
> Opinions?

I find the overall concept very appealing. Thank you for taking the time to 
work this out.

I think you overestimate some complexities there (which is good) regarding to 
clustering etc. If a server uses a 128bit random number for the server salt 
and we enforce the counter to be continuous and monotonic, I don’t see any 
interaction between cluster nodes needed.

Likewise for the state keeping on the client side: If a client can keep a 
connection, it should be able to keep an 8 byte counter state along with it.

What needs to be specified is counter overflow. Could be done with a simple 
request from the client for a new salt.

I don’t see a good way to integrate the date in the message ID though (cc @ 
Zash). Even if we let the server define a must have prefix which they could 
incidentally set to the date, a way to handle date changes during a connection 
would be needed.

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
___

[Standards] Council Agendum: Re: XEP-0153: Encoding of photo hash?

[Jonas Wielicki]

On Sonntag, 25. Februar 2018 21:39:03 CET Tedd Sterr wrote:
> > For me the text and examples are not clear.
> > 
> > „sha1-hash-of-image“ in the example doesn’t say anything about the
> > encoding.
> True. It appears to defer that to RFC-3174, but that document only specifies
> how to calculate the hash value, not how to represent it (as a hex string.)
> It seems to be more a de facto understanding this will be as a string of
> hexadecimal characters.
> > Jonas, I have no objections to clarify the usage of lower-case hex
> > encoding.
> Third-ed; though a hex string may be upper or lower case and still retain
> the same meaning.

I proposed some wording here and I am sending this to Council: 
https://github.com/xsf/xeps/pull/593/files

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-0153: Encoding of photo hash?

[Jonas Wielicki]

Hi Christian,

On Samstag, 24. Februar 2018 20:22:39 CET Christian Schudt wrote:
> I’ve got a question about XEP-0153. Its XML schema defines that the photo
> hash is encoded as Base64:
> 
> 

Re: [Standards] NEW: XEP-0401 (Easy User Onboarding)

[Jonas Wielicki]

On Freitag, 23. Februar 2018 12:36:01 CET Georg Lukas wrote:
> * Jonas Wielicki <jo...@wielicki.name> [2018-02-23 11:39]:
> > - This is a larger one: If we’re changing XEP-0077 flow in a backward-
> > incompatible manner, wouldn’t it make more sense to do this in a wholly
> > new
> > namespace, with a new stream feature to advertise support? That would save
> > a round-trip (to detect that it *won't* work) and allows to passively
> > detect support.
> 
> The client advertises suport by adding a  element into the
> initial IQ. AFAIU IBR, the initial IQ needs to be sent anyway, so we are
> piggy-backing here without additional round-trips.

Right. I forgot for a moment that it doesn’t make sense to attempt  
with any domain except the domain where the token comes from, and that domain 
should better be supporting  ;-)

> The server either ignores the element or returns a modified data form /
> IBR pseudo-form if supported.

Having this as a stream feature and in a separate, new namespace still feels 
cleaner to me.

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] NEW: XEP-0401 (Easy User Onboarding)

[Jonas Wielicki]

I found a few other nits to pick:

- The command @node values should probably be namespaced somehow (e.g. with 
urn:xmpp:invite#)

- This is a larger one: If we’re changing XEP-0077 flow in a backward-
incompatible manner, wouldn’t it make more sense to do this in a wholly new 
namespace, with a new stream feature to advertise support? That would save a 
round-trip (to detect that it *won't* work) and allows to passively detect 
support.

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-0234] Jingle File Transfer, Last Call and File Sharing

[Jonas Wielicki]

On Freitag, 23. Februar 2018 09:47:00 CET Goffi wrote:
> 1) XEP-0234 is in Last Call which is supposed to be finished, what the
> status about that?

The Council vote isn’t over yet (but from what it looks like, advancement will 
be rejected since Daniels feedback has not been addressed; it looks like it 
will stay in Experimental).

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] undefined state in XEP-0050

[Jonas Wielicki]

On Donnerstag, 22. Februar 2018 10:29:18 CET Kevin Smith wrote:
> FWIW, I think this isn’t what the standard already says, although may be
> sensible.

Hmm… I think you are right there. "execute" is equivalent to whatever the 
Responder says in the "execute" attribute on . Which unfortunately 
does *not* have a default value. The interpretation of being equivalent to 
"next" is only done in a "typical interpretation" of a requester:

> The action "execute" is always allowed, and is equivalent to the action 
> "next".

(this is the passage which is to be changed) and later on:

> If the  possesses the "execute" attribute, that value is the 
> default button or option. If the  does not possess the "execute" 
> attribute, there is no default button or option.

Also, there is (for empty/no ):

> The action "execute" is equivalent to the action "complete".

So given all that, I wonder whether the proposed wording should be adapted to 
reflect that the value of the "execute" attribute should always take 
precedence over the interpretation of what "execute" means?


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
___