Re: [Standards] XEP-0280: vs.

[Dave Cridland]

On 16 September 2015 at 22:21, Florian Schmaus  wrote:

> On 16.09.2015 16:33, Matthew A. Miller wrote:
> > A pull request was submitted to remove  and use the
> >  processing hint:  https://github.com/xsf/xeps/pull/83
>
> A short remark about the changes of the PR: xep334 should be added to
> the xep280 dependencies.
>
> Since it appears that xep280 is going to advance to draft and given that
> xep334 is experimental: Can a draft xep depend on an experimental one?
>

That is a very good point. I'd rather not have dependencies which are
unstable.


>
> > The last time this came up, many many months ago, I recall there not
> > being consensus to change.  But that was then and this is now.
> >
> > What are implementers doing today?
> >
> > * Are implementations using XEP-0280's ?
> > * Are implementations using XEP-0334's ?
>
> Smack's doing 
>
> > * Are implementations supporting both, but favoring XEP-0334's
> ?
>
> I would switch to xep334 in an instant. Kurt has a valid point about
> xep334  being not as strict as . Hence I think we
> should change that bit in xep334 and incorporate the semantics of
> xep280's .
>

The point of '334 is that it's pure a hint and cannot be relied upon to
provide any particular behaviour.

I think changing that would probably be a mistake.

Despite your argument to the contrary, I think you and Kurt have convinced
me that we should keep Carbons (and ) as-is.

Dave.

Re: [Standards] Rayo feedback.

[Dave Cridland]

On 3 September 2015 at 20:15, Ben Langfeld <b...@langfeld.me> wrote:

>
>
> On 2 September 2015 at 12:55, Dave Cridland <d...@cridland.net> wrote:
>
>> (Matthew Miller prodded me that I hadn't replied to this).
>>
>> On 18 August 2015 at 12:39, Ben Langfeld <b...@langfeld.me> wrote:
>>
>>> On 18 August 2015 at 08:13, Dave Cridland <d...@cridland.net> wrote:
>>>
>>>>
>>>>
>>>> On 17 August 2015 at 20:15, Ben Langfeld <b...@langfeld.me> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 17 August 2015 at 13:44, Kevin Smith <kevin.sm...@isode.com> wrote:
>>>>>
>>>>>> On 14 Aug 2015, at 20:11, Ben Langfeld <b...@langfeld.me> wrote:
>>>>>> > > 2) 5.1 (Actors) places requirements that these JIDs for
>>>>>> components/mixers can only be only be under subdomains - why is this?
>>>>>> AFAIK, this is the only part of XMPP that implies any relationship 
>>>>>> between
>>>>>> a domain and a subdomain, and it doesn’t immediately seem like a useful
>>>>>> restriction.
>>>>>> > >
>>>>>> > > Not true. The word I used was "perhaps". This is simply to point
>>>>>> out that full JIDs must be used to address these entities and no
>>>>>> relationship between domains may be assumed.
>>>>>> >
>>>>>> > I think that at least the table in 5.2 is quite explicit in
>>>>>> requiring things to be a subdomain - I take it this wasn’t intended.
>>>>>> >
>>>>>> > Actually quite the opposite:
>>>>>> >
>>>>>> > > where elements in square brackets are optional
>>>>>> >
>>>>>> > @[.]/
>>>>>> >
>>>>>> > Quite explicitly optional, I'd say.
>>>>>>
>>>>>> Sorry, badly expressed. It is optional that it’s a *sub*domain, yes.
>>>>>> But if it’s not the service domain, you’re requiring it to be a subdomain
>>>>>> of the service domain. This is what I was calling out - this is a unique
>>>>>> requirement in XMPP; there’s usually no formal relationship between
>>>>>> different domains like this, and it’s not clear to me that one is needed
>>>>>> here.
>>>>>>
>>>>>>
>>>> I'd like to see the answer to this one. Given a server of
>>>> shakespeare.lit, do I understand that a call must be within either that
>>>> domain or a subdomain of it?
>>>>
>>>
>>> I guess that's what this implies. I have yet to hear why it's a bad
>>> thing though.
>>>
>>
>> Because nothing else relies on this relationship in XMPP. Domain names -
>> whether "subdomains" or not - do not have any relationship, implied or
>> otherwise.
>>
>> So in order to mandate this, you really need to come up with an
>> overwhelming reason why this specification should require this, unlike
>> every other XMPP specification.
>>
>
> Ok. I'll see what I can do to remove that stipulation from the text. AFAIK
> it won't make any technical difference, it's just a logical thing.
>
>
>> >  > 5) 6.1 - if you want to rely on presence here, isn’t an unavailable
>>>>>> presence the best way to signal unavailability? I don’t think it’s 
>>>>>> covered
>>>>>> what receiving unavailable would mean here at the moment.
>>>>>> > >
>>>>>> > > See above.
>>>>>> >
>>>>>> > I think at least the second part of the question stands - what does
>>>>>> receiving unavailable mean?
>>>>>> >
>>>>>> > Means that the client has gone offline and will not interact with
>>>>>> the calls under its control any more. The Rayo server may choose to hang 
>>>>>> up
>>>>>> those calls, wait for the client to come back, or any other
>>>>>> implementation-specific behaviour.
>>>>>>
>>>>>> It seems worth mentioning this, to me.
>>>>>>
>>>>>> > > 8) 6.2.1 How does the client discover the available URI schemes
>>>>>> for to/from?
>>>>>> > >
>>>>>> > > No such discover

Re: [Standards] Rayo feedback.

[Dave Cridland]

(Matthew Miller prodded me that I hadn't replied to this).

On 18 August 2015 at 12:39, Ben Langfeld <b...@langfeld.me> wrote:

> On 18 August 2015 at 08:13, Dave Cridland <d...@cridland.net> wrote:
>
>>
>>
>> On 17 August 2015 at 20:15, Ben Langfeld <b...@langfeld.me> wrote:
>>
>>>
>>>
>>> On 17 August 2015 at 13:44, Kevin Smith <kevin.sm...@isode.com> wrote:
>>>
>>>> On 14 Aug 2015, at 20:11, Ben Langfeld <b...@langfeld.me> wrote:
>>>> > > 2) 5.1 (Actors) places requirements that these JIDs for
>>>> components/mixers can only be only be under subdomains - why is this?
>>>> AFAIK, this is the only part of XMPP that implies any relationship between
>>>> a domain and a subdomain, and it doesn’t immediately seem like a useful
>>>> restriction.
>>>> > >
>>>> > > Not true. The word I used was "perhaps". This is simply to point
>>>> out that full JIDs must be used to address these entities and no
>>>> relationship between domains may be assumed.
>>>> >
>>>> > I think that at least the table in 5.2 is quite explicit in requiring
>>>> things to be a subdomain - I take it this wasn’t intended.
>>>> >
>>>> > Actually quite the opposite:
>>>> >
>>>> > > where elements in square brackets are optional
>>>> >
>>>> > @[.]/
>>>> >
>>>> > Quite explicitly optional, I'd say.
>>>>
>>>> Sorry, badly expressed. It is optional that it’s a *sub*domain, yes.
>>>> But if it’s not the service domain, you’re requiring it to be a subdomain
>>>> of the service domain. This is what I was calling out - this is a unique
>>>> requirement in XMPP; there’s usually no formal relationship between
>>>> different domains like this, and it’s not clear to me that one is needed
>>>> here.
>>>>
>>>>
>> I'd like to see the answer to this one. Given a server of
>> shakespeare.lit, do I understand that a call must be within either that
>> domain or a subdomain of it?
>>
>
> I guess that's what this implies. I have yet to hear why it's a bad thing
> though.
>

Because nothing else relies on this relationship in XMPP. Domain names -
whether "subdomains" or not - do not have any relationship, implied or
otherwise.

So in order to mandate this, you really need to come up with an
overwhelming reason why this specification should require this, unlike
every other XMPP specification.


>
>
>> >  > 5) 6.1 - if you want to rely on presence here, isn’t an unavailable
>>>> presence the best way to signal unavailability? I don’t think it’s covered
>>>> what receiving unavailable would mean here at the moment.
>>>> > >
>>>> > > See above.
>>>> >
>>>> > I think at least the second part of the question stands - what does
>>>> receiving unavailable mean?
>>>> >
>>>> > Means that the client has gone offline and will not interact with the
>>>> calls under its control any more. The Rayo server may choose to hang up
>>>> those calls, wait for the client to come back, or any other
>>>> implementation-specific behaviour.
>>>>
>>>> It seems worth mentioning this, to me.
>>>>
>>>> > > 8) 6.2.1 How does the client discover the available URI schemes for
>>>> to/from?
>>>> > >
>>>> > > No such discovery is specified, and it is assumed that a Rayo
>>>> service would document this.
>>>> >
>>>> > It’s not clear to me what this means for interoperability. Does it
>>>> mean that one can’t implement a Rayo client using this XEP and expect it to
>>>> interoperate with an arbitrary Rayo service, because it won’t know what the
>>>> available URI schemes are?
>>>> >
>>>> > Even if this were available via Disco, it would make no difference.
>>>> You couldn't build your app to compensate. I think
>>>> per-implementation/service documentation is sufficient here.
>>>>
>>>> Doesn’t that mean that one can’t implement a Rayo client without
>>>> reference to per-server documentation?
>>>>
>>>
>>> One could certainly implement a client library/framework, and we have
>>> done. When one builds / deploys an application, however, one must know
>>> some

Re: [Standards] Proposed XMPP Extension: Entity Versioning

[Dave Cridland]

So I think that as far as rosters go, this is duplicating XEP-0237 in a
considerably less efficient form.

XEP-0237§4 gives a fairly intense trip down implementation options, and
none of them require multiple versions of the roster as claimed by this
ProtoXEP. I have a personal preference for §4.3, though it gets complex
with shared groups and so on. Nevertheless, it is possible to get perfect
efficiency if you're willing to store tombstones.

Rosters are a particularly simple case for synchronization, because there
is a single view; disco#items has potentially one view per user, and as
such is more complex.

In particular, assuming a room has configuration A, and then changes to
configuration A' - while we can tell if A' is visible to a user U -- let's
call this V(A',U) -- we cannot tell if V(A,U) == V(A',U) without having A;
and given we don't always know which older configuration needs to be stored
to make that comparison, things can get complex fast.

As such, a '237 style approach would probably be limited in practise to
having a §4.2 approach of hashing the entire list.

This ProtoXEP tackles this problem by having the client upload its view for
comparison, although it also includes an exact-match mechanism.

However, it's not clear from the specification how a server can signal
removal (or lack of visibility), nor what advantages a client has in
exchanging the download of a large amount of data with the upload of a
large amount of data.

In short, I think I need a bit more convincing that this represents a
significant advantage over the XEP-0237 approach.

Dave.

Re: [Standards] Proposed XMPP Extension: Entity Versioning

[Dave Cridland]

On 1 September 2015 at 22:07, Sam Whited <s...@samwhited.com> wrote:

> On Tue, Sep 1, 2015 at 2:35 PM, Dave Cridland <d...@cridland.net> wrote:
> > So I think that as far as rosters go, this is duplicating XEP-0237 in a
> > considerably less efficient form.
>
> The main thing to keep in mind is that it can be used to diff
> arbitrary lists (rosters and MUC disco#items are specified, but you
> could equally use it for caching entity caps or feature lists, or just
> about any other arbitrary list your server felt like versioning).
>
> > XEP-0237§4 gives a fairly intense trip down implementation options, and
> none
> > of them require multiple versions of the roster as claimed by this
> ProtoXEP.
> > I have a personal preference for §4.3, though it gets complex with shared
> > groups and so on. Nevertheless, it is possible to get perfect efficiency
> if
> > you're willing to store tombstones.
>
> In §4.2 Exact-match Conformance you must store multiple versions of
> the roster (or at least the current version of the roster and any
> pending pushes, maybe I should rephrase that statement in the XEP)
> unless you want to re-sync the entire roster every time there's a
> change and the user isn't online to receive a push. Eg. if the user
> signs in and fetches the roster (with a digest version), then signs
> out and a new user is added to his roster, then the user signs back in
> and sends up the digest the server must have cached that new user to
> send a roster push back down. If your new user is added to many
> peoples rosters (but you can't guarantee that it's added to a whole
> groups roster) you now have to store that roster push for every single
> person who's roster it needs to be pushed to (as opposed to a single
> version token in the users database table or somewhere that can be
> diffed against).
>
> In §4.3 Add-only Conformance the assumption is that deletions are rare
> (since this will trigger an entire roster invalidation). This is not
> an assumption that can be made in many environments (eg. large
> organizations where shared rosters may constantly have people being
> deleted as people leave the company, contractors rotate in and out
> etc.). The combined approach that's also described in this section is
> somewhat better, but still requires that we store new additions in
> many places (eg. once for every user that should get the push, or for
> every group that shoud get the push, or both. This starts to
> complicate the data model.)
>
> There are further workarounds for most of the issues I've just
> described, but mostly they just lead to more rabbit holes and more
> problems, and end up resulting in a very complicated solution. Entity
> versioning just does this in a simpler way that works better with our
> data model and distributed architecture (and potentially with others
> architectures as well). We can also then re-use the exact same
> semantics for other lists as previously discussed (instead of
> maintaining two different syncrhonization and diffing mechanisms).
>
>
I think most (or all) of the above only applies if you have rosters that
are computed on demand, rather than managed by users via clients.

Otherwise all you need on a simple roster (no shared groups) is a counter
for the version, the value of the latest tombstone *not* retained (ie, the
last delete if there are no tombstones), and per item, the value of the
last change, and if it's deleted (ie, if it's a tombstone). No multiple
versions of anything. Tombstones are optional; but without them it means
it's only efficient for adds.


> There is actually a part 2 to this XEP which I hadn't submitted yet
> (because we haven't implemented it yet and I didn't want to submit
> until we at least had an implementation on our roadmap) where small
> chunks of an entity list can be diffed (eg. so that you can say "give
> me all changes to this subsection of the list") and then use a
> "search" feature to get more list items later. This lets you receive a
> subset of your roster (eg. if your roster has 10,000 users, you can
> receive 1000 users that your server thinks you need at first, and then
> use the search endpoints eg. if you go to start a chat and want to
> list more users later via an "auto complete" mechanism). This would
> make it so that you can slowly ramp up to full roster consistency
> (note that I say roster a lot, but again, this is for any list). Maybe
> I should go ahead and start working on that and submit it, because
> with this second phase the benefits become more aparent.
>
>
I agree.


>
> > Rosters are a particularly simple case for synchronization, because
> there is
> > a single view; disco#items has potentially

Re: [Standards] Proposed XMPP Extension: Message Deletion

[Dave Cridland]

The usual terms are message recall, or retraction.
On 28 Aug 2015 17:59, Christian Schudt christian.sch...@gmx.de wrote:

 Hi,

 the wording is very inconsistent.

 It sometimes says delete/deletion, sometimes remove/removal, even when
 referring to the same use case (removal request“, deletion request“).

 Even the namespace (delete) is different from the element name (remove).

 I suggest to clean this up. I am no native speaker and the difference
 might be subtle, but from what I’ve read „remove“ feels more appropriate
 here.

 Otherwise looks well. Skype uses this feature, too.

 — Christian



 Am 19.08.2015 um 17:44 schrieb XMPP Extensions Editor edi...@xmpp.org:

  The XMPP Extensions Editor has received a proposal for a new XEP.
 
  Title: Message Deletion
 
  Abstract: This specification defines a method for indicating that a
 message should be removed.
 
  URL: http://xmpp.org/extensions/inbox/message-deletion.html
 
  The XMPP Council will decide in the next two weeks whether to accept
 this proposal as an official XEP.
 

Re: [Standards] XMPP Myths

[Dave Cridland]

On 27 August 2015 at 16:14, Vitaly Takmazov vitalys...@gmail.com wrote:

 Hello!

  It's here: http://wiki.xmpp.org/web/index.php?title=Myths

 I don't understand where is the proper place to comment it, so I will
 comment it here.


Thanks for taking the time to comment; it's really appreciated.

FWIW, most of these hypotheses were drawn from one particular FAQ which
detailed why XMPP was terrible and you should use their stuff instead -
that is, I didn't make them up because they were easier to knock down this
way.


  XMPP is XML, so it's too slow.
 Yes, many novice developers saying exactly the same, but the problem is
 much deeper:
 *development with* XML/XMPP is *much slowly* than with JSON.
 Imagine you are a novice developer, who is not familiar with XML/XMPP but
 wants to build messaging app: almost every programming language and
 framework have a) built-in HTTP server, b) language structures, like
 dictionaries and arrays, which perfectly maps to JSON, and it is enough to
 describe his own Message class with all required fields, serialize it to
 JSON, send it to server app and deserialize it to its own language
 structure. So he get the whole client/server app just easy and quick.


This is all true, but none of it will get you interoperability between
sites, and you'll also have to reinvent your security from scratch again.

JSON works as an ad-hoc tool, of course, very well, for all the reasons you
list - but it's considerably less useful for building an interoperable
extensible protocol.

Of course, I'm not saying people should never use JSON either - and indeed
to could easily put JSON directly into an XMPP stanza without any problems
if you wanted.


 But with XML/XMPP: you have no a) easy to use development XMPP server
 (there are some python/javascript samples, but they are buggy and
 incomplete), b) good XMPP library (in 99% cases you need to go deep into
 XML and add a new experimental XML namespace, well, I will explain it in
 Myth 2 and 3).
 So, with HTTP/JSON - developer only need to know his %language_of_choice%
 and all job will be done with familiar instruments. With XML/XMPP - he need
 to know: XML(and especially namespaces), network ifrastructure - DNS setup,
 XMPP server (ejabberd, openfire, prosody) and setup, strange
 non-mainstreamed languages like Erlang and Lua, to extend server to fit his
 needs, and many other problems. So, JSON - is *faster* :)


You make an interesting point here - XMPP is production-only in a lot of
ways - it's actually harder to setup a quick and dirty XMPP server than it
is to set one up for production. I'm not sure how to address that, but it's
a very valid point.

On the other hand, writing a component should be pretty easy in any
language, and if it's not, that's a problem. Also, I, too, have misgivings
about the use of novelty languages in XMPP; despite Lua being pretty easy,
I do much prefer something sensible. (And Erlang always looks like someone
was snorting Perl and sneezed to me).

That said, the servers do work; I can't complain there.


  Myth Two: The baseline is minimal, therefore XMPP is useless.
 The problem with XMPP baseline is the following: RFC6121 is *not enough*
 to build *modern* messaging app. I will show only *one* example: RFC's
 message / have no widely used IM fields like delivered and read, and
 there is no widely adopted XEP with these fields. XEP-0333? There is no
 libraries/clients/server support of it! So, XMPP baseline is *useless*: you
 need to study all XEPs, find namespace with required extended message
 fields (remember, you already need to understand XML namespaces? There is
 no such problem with JSON!), and add support of it to used XMPP baseline
 library (your programming skills now required to be 10x strong!).


RFC 6121 isn't enough to build even a very basic messaging app, though -
and that's by design.

If we used JSON, we'd still have namespacing somehow, and the choice of
JSON model would not always fit your purposes - in effect, the JSON would
be equally as ugly as the XML.

As a final note, the nice thing about having all these specs is that a
great many people have carefully thought through how these might work most
efficiently, and where the problem areas might be.

The rest of these comments, though, I largely agree with - there's been
talk of putting together both a new profile XEP, listing the things any
modern messaging app should support, and also putting together a bunch of
sensible tutorials. I think you're underlining how important those are.



  Myth Three: It's too bandwidth-inefficient for mobile.
  The hypothesis: XMPP stanzas are just too verbose to work on mobile.
 No, your hypothesis is wrong again!  XMPP is too inefficient on mobile,
 because it was not designed with mobile connection in mind.
 How typical mobile app works: connecting to his server and authenticating,
 storing his auth token, sleeps forever in background - and continue to work
 every time user open app again. Server 

Re: [Standards] XMPP Myths

[Dave Cridland]

On 27 August 2015 at 21:42, Evgeny Khramtsov xramt...@gmail.com wrote:

 Thu, 27 Aug 2015 17:13:14 +0100
 Dave Cridland d...@cridland.net wrote:

  The rest of these comments, though, I largely agree with - there's
  been talk of putting together both a new profile XEP, listing the
  things any modern messaging app should support, and also putting
  together a bunch of sensible tutorials. I think you're underlining
  how important those are.

 I even think such list is more important than this FAQ. Also clients
 compatibility list would be great. SIP folks are doing something like
 that regularly (https://www.sipit.net/SIPitSummaries). XSF did that in
 the past btw.


The profile XEP is really important, I agree.

A compatibility list might be interesting, but I think the only real
compatibility issues we have are where a protocol has switched namespace
due to incompatible versions, and some clients and/or servers end up
sticking with the older versions. I don't think that situation helps us at
all.


  but as I say, my Solitaire app uses more battery than
  my IM app on my phone even without such a spec. And I don't even play
  solitaire that much.

 I think we should not compare the worst with XMPP. For example,
 Whatsapp doesn't drain battery.


Right; I wasn't intending to compare it with the worst thing I could find.
Solitaire doesn't use much battery - Conversations still uses less.

Dave

Re: [Standards] Proposed XMPP Extension: Server to Server communication over STANAG 50666 ARQ

[Dave Cridland]

Folks,

I've avoided voting on this because I want to seek some community input on
it. Specifically, we (the XMP{P Standards Foundation) claim to be an Open
Standards organization, and it's not clear if this submission qualifies
because it has a dependency on STANAG 5066, which is not publicly available.

STANAG 5066 is a physical layer protocol providing services roughly akin to
IPX/SPX and V.90 combined. It's in use both in the Military world (it's a
NATO specification) and also by commercial HF radio modems in use by
amateur radio operators (hams) worldwide.

Many STANAG documents are available publicly in the NATO Standards
Organisation's online document library, here:
http://nso.nato.int/nso/nsdd/listpromulg.html - but STANAG 5066 is missing
from this list.

I'd like to make it clear that otherwise, I'm thoroughly in favour of this.

Some parallel cases, which people may decide form a precedent (or may
decide are completely different).


1) RTMP as a Jingle transport.

RTMP is (or was) a multimedia realtime transport protocol developed by
Adobe, and in use in the Flash Player. The Council rejected a submission to
allow its use as a Jingle transport, on the basis that it was a closed
standard.

The minutes say:

Council consensus that it is inappropriate to publish this proposal
given the proprietary nature of the RTMP technology on which this
specification depends.

STANAG 5066, although a STANdardization AGreement, is not publicly
available, and therefore certainly doesn't form an open standard.

2) SDN.801c in XEP-0258

As a counter-example of sorts, implementing XEP-0258 in any useful form in
a server requires the use of the document SDN.801c, which (similar to
STANAG 5066) is an unclassified document which is not publicly available.

However, XEP-0258 was, of course, published as a XEP - and indeed it's
relatively simple to implement in a client, and its possible to implement a
server which uses some other labelling model; arguably therefore SDN.801c
is not a hard dependency in the same way.


I could go either way on this; though my ideal outcome would be that STANAG
5066 gets put in the NATO public STANAG library alongside the others.

Opinions welcome.

Dave.

On 24 August 2015 at 23:32, XMPP Extensions Editor edi...@xmpp.org wrote:

 The XMPP Extensions Editor has received a proposal for a new XEP.

 Title: Server to Server communication over STANAG 50666 ARQ

 Abstract:
   This specification defines operation over XMPP over the NATO STANAG 5066
 data link service for point to point links (ARQ).   This enables optimized
 XMPP performance over HF Radio (which STANAG 5066 was designed for) and
 over other data links using STANAG 5066.



 URL: http://xmpp.org/extensions/inbox/s2s-over-s5066.html

 The XMPP Council will decide in the next two weeks whether to accept this
 proposal as an official XEP.

Re: [Standards] Rayo feedback.

[Dave Cridland]

On 17 August 2015 at 20:15, Ben Langfeld b...@langfeld.me wrote:



 On 17 August 2015 at 13:44, Kevin Smith kevin.sm...@isode.com wrote:

 On 14 Aug 2015, at 20:11, Ben Langfeld b...@langfeld.me wrote:
   2) 5.1 (Actors) places requirements that these JIDs for
 components/mixers can only be only be under subdomains - why is this?
 AFAIK, this is the only part of XMPP that implies any relationship between
 a domain and a subdomain, and it doesn’t immediately seem like a useful
 restriction.
  
   Not true. The word I used was perhaps. This is simply to point out
 that full JIDs must be used to address these entities and no relationship
 between domains may be assumed.
 
  I think that at least the table in 5.2 is quite explicit in requiring
 things to be a subdomain - I take it this wasn’t intended.
 
  Actually quite the opposite:
 
   where elements in square brackets are optional
 
  call ID@[call sub-domain.]service domain/component ID
 
  Quite explicitly optional, I'd say.

 Sorry, badly expressed. It is optional that it’s a *sub*domain, yes. But
 if it’s not the service domain, you’re requiring it to be a subdomain of
 the service domain. This is what I was calling out - this is a unique
 requirement in XMPP; there’s usually no formal relationship between
 different domains like this, and it’s not clear to me that one is needed
 here.


I'd like to see the answer to this one. Given a server of shakespeare.lit,
do I understand that a call must be within either that domain or a
subdomain of it?


5) 6.1 - if you want to rely on presence here, isn’t an unavailable
 presence the best way to signal unavailability? I don’t think it’s covered
 what receiving unavailable would mean here at the moment.
  
   See above.
 
  I think at least the second part of the question stands - what does
 receiving unavailable mean?
 
  Means that the client has gone offline and will not interact with the
 calls under its control any more. The Rayo server may choose to hang up
 those calls, wait for the client to come back, or any other
 implementation-specific behaviour.

 It seems worth mentioning this, to me.

   8) 6.2.1 How does the client discover the available URI schemes for
 to/from?
  
   No such discovery is specified, and it is assumed that a Rayo service
 would document this.
 
  It’s not clear to me what this means for interoperability. Does it mean
 that one can’t implement a Rayo client using this XEP and expect it to
 interoperate with an arbitrary Rayo service, because it won’t know what the
 available URI schemes are?
 
  Even if this were available via Disco, it would make no difference. You
 couldn't build your app to compensate. I think per-implementation/service
 documentation is sufficient here.

 Doesn’t that mean that one can’t implement a Rayo client without
 reference to per-server documentation?


 One could certainly implement a client library/framework, and we have
 done. When one builds / deploys an application, however, one must know
 something about the server implementation. I maintain, though, that Disco
 as documentation is no better than normal documentation. I'd love to hear
 your argument for Disco being useful here, but it sounds like we're just
 trying to tick a haz Disco checkbox for no reason.



I'd expect a generically built client to be possible, and I would expect a
baseline that ensured it did the basics if at all possible.

If this isn't possible, I'd like to know why not - I've only seen this with
Jingle video calling in the past due to the intersection of deployment and
patents.

I would have thought that some mechanism for discovering what URI schemes
were possible would be both possible and useful.


   10) 6.2.1.1 Use of presence for sending of notifications like this
 seems off. I realise this boat may have sailed, but it doesn’t seem right
 to me.
  
   We had this discussion during the Last Call, and the only alternative
 that was presented was a dependency on PubSub, against which I believe I
 presented a solid argument previously.
 
  I’m not exactly ignoring this comment, but I don’t have a sensible
 reply either.
 
   16) 6.3 The identifier for calls here is always a JID, isn’t it? If
 that’s the case, it’d make more sense to be using JIDs here, instead of
 adding the layer of indirection of a URI with a fixed scheme.
  
   A call URI will not necessarily always be a JID. It has been the
 intention since the start of this spec to leave open the option of other
 transports for Rayo, such as HTTP.
 
  In such a case, how will an entity know about the available schemes,
 and connect to them? If the implication is that there will need to be
 changes later to express how to interoperate with future systems, it
 suggests it wouldn’t be appropriate to push to Draft now with those changes
 pending.
 
  Any such behaviour is very much a future concern; no-one has given it
 any solid thought yet. Simply remaining generic in using URIs rather than
 protocol-specific 

Re: [Standards] Move Carbons to Last Call (Proposed)

[Dave Cridland]

I'm in full support of both the PRs raised (#50 and #51); these address all
the points I saw raised in discussion.

On 17 August 2015 at 18:37, Georg Lukas ge...@op-co.de wrote:

 * Kevin Smith kevin.sm...@isode.com [2015-08-17 15:47]:
  After discussion in the XSF MUC, I’ve pushed another change, so
  probably best to track via the
  https://github.com/Kev/xeps/commits/carbons branch.

 I'll see your patch and raise you $200.

 https://github.com/ge0rg/xeps/tree/carbons

 After some more discussion in xsf@ we figured out that at least two
 server implementations (prosody, ejabberd) haven't implemented section 6
 of XEP-0280 anyway, and were using identical behavior for full-JID and
 bare-JID messages. Furthermore, section 6 is completely redundant, as
 the same behavior can be achieved under existing RFC 6121 §8.5.2.1.1
 rules.

 OTOH, message forking (as opposed to carbon-copying) introduces several
 problems:

  * a carbons-enabled client with a negative priority can receive chat
messages under the section 6 rules.
  * a carbons-enabled client can not determine if it received a bare-JID
message due to regular message routing or due to Carbons (this is
useful for determining if a notification should be silent or loud,
though a smart client can determine that by watching presence of
the user's other resources).
  * it makes the XEP more complicated for no benefit.

 Therefore, I have gone a step further than Kev and removed section 6
 (and rephrased section 7 accordingly). As this change does not break
 anything, I'd like to have it added to XEP-0280. However, it is based on
 Kev's patches, so please discuss it now, and I'll open a PR as soon as
 Kev's changes are (hopefully) accepted.


 Georg

 P.S: This was already discussed a year ago, the thread can be found here:
 http://mail.jabber.org/pipermail/standards/2014-April/thread.html#28807

Re: [Standards] Move Carbons to Last Call (Proposed)

[Dave Cridland]

On 12 August 2015 at 07:12, Steve Kille steve.ki...@isode.com wrote:

 Given that a MAM based approach may be the  preferred medium term
 approach, it seems to me that we should focus efforts to work out what the
 medium term approach is going to be.   If we end up deciding that a MAM
 based approach is preferred, it would be confusing to progress carbons as
 well.


To paraphrase Carl von Clausevitz, the enemy of a good XEP is the dream of
a perfect one.

The fact is that neither the proponents of a solution based around MAM, nor
those who insist there are serious flaws in Carbons as-is, have proposed
anything concrete. The best proposal we have is a vague suggestion that we
should do something with subscriptions to MAM which might provide
multi-device capability.

Meanwhile, I can switch between desktop and mobile (and tablet) with
comfortable ease, even halfway through a conversation, using the existing
specifications, as provided by Openfire, using Gajim and Conversations as
clients.

The above statement is absolutely crucial, since over the past few days the
only consistent feedback from the Myths wiki page concerning a concrete
missing feature in XMPP has been exactly this. We've had people even on
this very list insist that this is a critical use-case unmet by Carbons -
but I can assure you it works very well for me.

There is no other proposal on the table.

I'm backing the one we have.

Dave.

Re: [Standards] Move Carbons to Last Call (Proposed)

[Dave Cridland]

On 12 August 2015 at 09:01, Georg Lukas ge...@op-co.de wrote:

 * Steve Kille steve.ki...@isode.com [2015-08-12 08:14]:
  Given that a MAM based approach may be the  preferred medium term
  approach, it seems to me that we should focus efforts to work out what
  the medium term approach is going to be.

 +1

  Also, if there is a list of issues that some people view need fixing
  with carbons, I think it would be good to have that list explicitly

 I've tried to compile a more general list of issues some time ago, to
 be found here:

 http://mail.jabber.org/pipermail/standards/2015-April/029722.html


Thanks, this is well worth [re-]reading, as it's a good summary of
multidevice issues.


 The carbon relevant things from that list and from the last 0280 advance
 discussion are:

 * Carbons for non-chat messages. Jingle signalling of incoming calls
   to all interested clients was mentioned IIRC.


That use-case won't work anyway because Jingle calls are initiated with an
iq/.


 * No filtering mechanism. Carbons are only for type=chat, the client
   can't add / remove types according to its needs.


True; do we need this in order to deploy Carbons, though? I suspect we
ultimately do to cover non-IM scenarios, but for normal IM we can probably
handle just type='chat'.


 * False-positive Carbons of MUC private messages (which are of
   type=chat; see
   http://mail.jabber.org/pipermail/standards/2015-May/029819.html and
   following messages for a discussion and possible solutions). I think
   the solutions need to be codified in the XEP.


I think there's a number of cases where a user's server needs to know that
a remote entity is a MUC (and thankfully, with MUC, this is relatively
simple to achieve). FWIW, the same issue also affects PEP (where PEP
doesn't use headline, at least), but is rather simpler to solve on a
stanza-by-stanza basis.

For MUC, I'll summarize our conversation online as servers already have to
track directed presence to chatrooms; it should be relatively low-cost to
check responses and mark those as chatrooms as needed, and then perform a
lookup for Carbons purposes.

I think I can patch Openfire to do this, and I believe you suggested
Prosody may do something like this already (but I may have misunderstood).


 * Carbon notifications (not strictly an XEP issue, rather one of proper
   UX) - when should a client ring a bell? Recommendations for this case
   might or might not be appropriate in the XEP.


I made the comment on HN that, as a community, we tend not to try to get a
consistent UX, and that perhaps we should, and explaining when to notify
(and how) would be a great start - maybe we should kick that off with a
Wiki page and see where it goes?




 Georg
 --
 || http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
 || gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
 || Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
 ++ IRCnet OFTC OPN ||_||

Re: [Standards] Move Carbons to Last Call (Proposed)

[Dave Cridland]

On 12 August 2015 at 10:54, Dave Cridland d...@cridland.net wrote:



 On 12 August 2015 at 09:01, Georg Lukas ge...@op-co.de wrote:

 * Steve Kille steve.ki...@isode.com [2015-08-12 08:14]:
  Given that a MAM based approach may be the  preferred medium term
  approach, it seems to me that we should focus efforts to work out what
  the medium term approach is going to be.

 +1

  Also, if there is a list of issues that some people view need fixing
  with carbons, I think it would be good to have that list explicitly

 I've tried to compile a more general list of issues some time ago, to
 be found here:

 http://mail.jabber.org/pipermail/standards/2015-April/029722.html


 Thanks, this is well worth [re-]reading, as it's a good summary of
 multidevice issues.


 The carbon relevant things from that list and from the last 0280 advance
 discussion are:

 * Carbons for non-chat messages. Jingle signalling of incoming calls
   to all interested clients was mentioned IIRC.


 That use-case won't work anyway because Jingle calls are initiated with an
 iq/.


That sounds more abrupt than I intended.

Matthew Wild suggested just adding 'normal', back in April; that would
cover most use-cases, and 'headline' messages seem to be undesirable at
this stage.




 * No filtering mechanism. Carbons are only for type=chat, the client
   can't add / remove types according to its needs.


 True; do we need this in order to deploy Carbons, though? I suspect we
 ultimately do to cover non-IM scenarios, but for normal IM we can probably
 handle just type='chat'.


 * False-positive Carbons of MUC private messages (which are of
   type=chat; see
   http://mail.jabber.org/pipermail/standards/2015-May/029819.html and
   following messages for a discussion and possible solutions). I think
   the solutions need to be codified in the XEP.


 I think there's a number of cases where a user's server needs to know that
 a remote entity is a MUC (and thankfully, with MUC, this is relatively
 simple to achieve). FWIW, the same issue also affects PEP (where PEP
 doesn't use headline, at least), but is rather simpler to solve on a
 stanza-by-stanza basis.

 For MUC, I'll summarize our conversation online as servers already have to
 track directed presence to chatrooms; it should be relatively low-cost to
 check responses and mark those as chatrooms as needed, and then perform a
 lookup for Carbons purposes.

 I think I can patch Openfire to do this, and I believe you suggested
 Prosody may do something like this already (but I may have misunderstood).


 * Carbon notifications (not strictly an XEP issue, rather one of proper
   UX) - when should a client ring a bell? Recommendations for this case
   might or might not be appropriate in the XEP.


 I made the comment on HN that, as a community, we tend not to try to get a
 consistent UX, and that perhaps we should, and explaining when to notify
 (and how) would be a great start - maybe we should kick that off with a
 Wiki page and see where it goes?




 Georg
 --
 || http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
 || gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
 || Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
 ++ IRCnet OFTC OPN ||_||

Re: [Standards] Move Carbons to Last Call (Proposed)

[Dave Cridland]

On 12 August 2015 at 11:22, Kevin Smith kevin.sm...@isode.com wrote:

 While falling into the good/perfect/now/later trap, we do at least have a
 story here that would solve this. MUC2 (which is being specced) should
 solve the shared-nickname issues of MUC, and Dave’s
 pubsub-to-account-not-to-client spec that he’s working on then provides a
 neat way around the ‘clients that aren’t joined’ issue.


(My sticking point here is PEP+notify; the rest is pretty trivial).

Dave.

Re: [Standards] XEP-0060 (and dependent ones): overwriting an item of somebody else

[Dave Cridland]

On 11 August 2015 at 00:05, Goffi go...@goffi.org wrote:

 G'day,

 It seems that in XEP-0060 nothing prevent a publisher to overwrite an item
 published by somebody else (or at least it's ambiguous)

 while that may be desirable in some cases, it's pretty bad with XEP-0277
 comments.

 In XEP-0060 § 7.1.1, it's said that
 Any entity that is allowed to publish items to a node (i.e., a publisher
 or an owner)  [...]
  and The item/ element provided by the publisher MAY possess an 'id'
 attribute, specifying a unique ItemID for the item.

 in § 7.1.2 it's said Note: If the publisher previously published an item
 with the same ItemID, successfully processing the request means that the
 service MUST overwrite the old item with the new item and then proceed as
 follows.

 Well the ambiguous part is the publisher: in the case of XEP-0277
 comments, the publish model if most of time subscribers, so any
 subscriber is a publisher. It's not explicit in the XEP that the service
 should prevent a publisher to overwrite an item from an other publisher.


Agreed. I think this parallels the notes on permissions in §4.1 Table 1,
where it notes that Publishers MAY be able to retract other people's items
but SHOULD NOT allow this for Publish-Only.


 Im my opinion the following points should be modified:

 - this case should be made explicit in the XEP-0060, with e.g. a security
 warning


Agreed.


 - a node configuration option can be used to specify if a publisher can
 overwrite an item initially published by somebody else


I think we - probably - want to split out these two as distinct
affiliations, long-term. Buddycloud does this, having an additional
affiliation which has broad rights, compared to normal publishers which can
only publish/retract their own content.


 - if this option is present, it MUST default to false (i.e. a publisher
 can't overwrite something that he didn't publish).


This would, in turn, means that publisher affiliation could only retract
and re-publish their own content, whereas the new affiliation could retract
and republish any items - that is, no configuration option would be needed.



 Thanks
 Goffi

[Standards] XMPP Myths

[Dave Cridland]

I've noticed that a large well-funded group have been attending a number of
conferences and making unfortunately ill-informed statements about XMPP, in
favour of their own solution in a number of spaces in which we overlap.

In conformity with Napoleon's suggestion that one should never attribute to
malice that which can adequately be explained by incompetence, I have tried
to address these statements directly, but sadly while representatives of
the organization were willing to agree they would correct their website,
they have remained too incompetent to do so.

This is terribly unfortunate, and so to help address this I knocked up some
answers to specific myths on a Wiki page, intended (by me) as a draft
blog post (but it could just as well stay on the Wiki, get reused as
website content, or whatever).

It's here: http://wiki.xmpp.org/web/index.php?title=Myths

Suggestions and corrections would be very much welcome; feel free to either
edit directly, or (possibly preferable) discuss in the XSF chatroom at
x...@muc.xmpp.org

Thanks!

Dave.

Re: [Standards] XMPP Myths

[Dave Cridland]

On 10 August 2015 at 18:37, Dominik Renzel ren...@dbis.rwth-aachen.de
wrote:

 Nice compilation, Dave.

 As one of the guys from xmppresearch.org, I might add a bit from the
 academic side. There is quite a body of literature available on XMPP
 research (and - yes, we keep collecting!). We're currently working on a
 survey paper on a collection of XMPP research from 2003 till today. I can't
 reveal too much, but a little bit of overview allows me to wield the
 academagic battle-axe at least for two myths.

 Myth Two:

 Although I don't know if the scientific use of XMPP extensions mirrors
 practical deployment, I would assume that there are certain similarities.
 In response to a request during this year's summit in Diegem, Belgium, my
 dear colleague Daniel Schuster from TU Dresden created a tag cloud of the
 XEPs in scientific use, extracted from 250 different papers:
 http://www.xmppresearch.org/posts/xeps-used-in-xmpp-research/


That's awesome; I'll link to that in the Myth Two section.


 Myth Three:

 There is quite some scientific evidence on the use of XMPP in
 bandwidth-critical, mobile settings, especially in the last five years.
 You find literature on mobile sensor networks, mobile apps, IoT, etc.,
 some of them applied in disaster scenarios with no or very impaired public
 communication infrastructure. Bandwidth-efficiency is hardly ever mentioned
 as a problem.


Yes, I'll poke about and see how much of the use-cases I'm aware of can be
talked about openly, since there's sectors using XMPP over low-bandwidth
for mission-critical messaging that are really eye-opening - and I didn't
even know about the disaster cases - links would be great.


 Best,
 Dominik




 Am 10.08.2015 um 18:02 schrieb Dave Cridland:

 I've noticed that a large well-funded group have been attending a number
 of
 conferences and making unfortunately ill-informed statements about XMPP,
 in
 favour of their own solution in a number of spaces in which we overlap.

 In conformity with Napoleon's suggestion that one should never attribute
 to
 malice that which can adequately be explained by incompetence, I have
 tried
 to address these statements directly, but sadly while representatives of
 the organization were willing to agree they would correct their website,
 they have remained too incompetent to do so.

 This is terribly unfortunate, and so to help address this I knocked up
 some
 answers to specific myths on a Wiki page, intended (by me) as a draft
 blog post (but it could just as well stay on the Wiki, get reused as
 website content, or whatever).

 It's here: http://wiki.xmpp.org/web/index.php?title=Myths

 Suggestions and corrections would be very much welcome; feel free to
 either
 edit directly, or (possibly preferable) discuss in the XSF chatroom at
 x...@muc.xmpp.org

 Thanks!

 Dave.

Re: [Standards] XMPP Myths

[Dave Cridland]

On 10 August 2015 at 17:02, Dave Cridland d...@cridland.net wrote:


 It's here: http://wiki.xmpp.org/web/index.php?title=Myths



I've added Myth Five : XMPP is unsuited to the web.

This is really an area I know very little about, so if Lance and Lloyd want
to check I'm not taking their names in vain that'd be great.

Dave.

Re: [Standards] Proposed XMPP Extension: HTTP File Upload

[Dave Cridland]

On 29 July 2015 at 16:36, Daniel Gultsch dan...@gultsch.de wrote:

 Don't get me wrong. There is definitely a place for Jingle and Jingle FT.
 I don't want to deprecate Jingle at all. But Jingle is not always the right
 tool for the job.


I see your point, but I'd prefer to see client developers only have to
implement one thing instead of several (and have to select which file
transfer mechanism to use in different circumstances).

Dave.

Re: [Standards] Minor clarifications to XEP-0198

[Dave Cridland]

On 28 July 2015 at 10:11, Christian Schudt christian.sch...@gmx.de wrote:

 Hi,

 What about a client sending delayed stanzas upon stream resumption? Should
 it add Delayed Delivery as well?

 E.g. client sends a message, but no ack is received, so it stays in the
 unacknowledged queue. Eventually client detects a broken connection,
 reconnects and resends the unacknowledged message.


If the patch doesn't say that clearly enough, that's an error on my part.
I'll try to make that clear.



  2) It was noted that redelivery attempts for stanzas require delay stamp
 handling.

[Standards] Minor clarifications to XEP-0198

[Dave Cridland]

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

Two things came up during community review of a patch to Openfire which are
not specified in the XEP. Both seem to be uncontentious, but will require
Council review, etc.

1) The specification makes no recommendation on what to do if the server
receives multiple requests.

This is resolved in this instance by recommending (SHOULD, not MUST) that
the
server generates a stream error, and stipulates that clients MUST NOT do
this.

2) It was noted that redelivery attempts for stanzas require delay stamp
handling.

It is arguably not within this specification's remit to require this,
however
it seems compelling that it be documented somewhere and this seems the best
place.

Dave.

Re: [Standards] Move CSI to Last Call (Proposed)

[Dave Cridland]

On 28 July 2015 at 10:00, Florian Schmaus f...@geekplace.eu wrote:

 On 28.07.2015 10:20, Dave Cridland wrote:
 
 
  On 28 July 2015 at 08:22, Florian Schmaus f...@geekplace.eu
  mailto:f...@geekplace.eu wrote:
 
  On 27.07.2015 23:29, Sam Whited wrote:
   Hi all,
  
   I'd like to propose that the Council vote to move XEP-0452: Client
   State Indication into last call (the Proposed State), and then
   hopefully into draft afterwards.
  
   The XEP has been sitting dormant since it was last updated almost a
   year ago (2014-08-28).
 
  I've talked to Matt at the Summit this year about a message
 notification
  send by the server to the client indicating a successful CSI state
  change. We agreed on the change and I sent a patch to Matt a while
 ago.
  But the patch was not applied since then. I've created a PR now:
  https://github.com/xsf/xeps/pull/34
 
 
  What? Why? What can a client do in response to the information?

 The client knows for example that the roster presence information is
 up-to date. Basically I've an use case of a client using CSI which needs
 to take a decision based on the current presence state of the roster
 items. Imagine the following scenario: Client is in CSI inactive state,
 an external event triggers the client so that he needs to make an
 decision based on the presence state of the roster items. In order to
 get the latest presence information, the client switches to CSI active
 and waits for the queued presence stanzas to arrive. Without the CSI
 state change message notification, the client can't decide when the last
 queued presence stanza has arrived.

 And yes, I know that presence information can be always considered as
 outdated. Because even if you don't use CSI, the client's view of the
 presences could not reflect the state the client's roster items actually
 have.

 But having such a CSI message notification is a trivial change to CSI,
 and provides a huge benefit for this use case.


So switch mode and ping.


  Also, why wrap the server notification in a message,

 And not using a Nonza? Because most libraries provide a mechanism for
 callbacks matching a given filter only for Stanzas. It's my impression
 as as XMPP client library developer, that we don't want Nonzas to
 trigger callbacks on the client side, as it would increase the
 complexity of XMPP client software stacks.


It's very wrong.

Consider a case where the client goes active, then switches to inactive but
loses connection and recovers via '198. The response - which is tightly
bound to the session - would indicate that the client was inactive, but
would arrive on a subsequent connection which is not inactive.


  and do I assume
  that the use of two namespace versions is in error?

 Yes assumption is correct.

 - Florian

Re: [Standards] Move CSI to Last Call (Proposed)

[Dave Cridland]

On 28 July 2015 at 08:22, Florian Schmaus f...@geekplace.eu wrote:

 On 27.07.2015 23:29, Sam Whited wrote:
  Hi all,
 
  I'd like to propose that the Council vote to move XEP-0452: Client
  State Indication into last call (the Proposed State), and then
  hopefully into draft afterwards.
 
  The XEP has been sitting dormant since it was last updated almost a
  year ago (2014-08-28).

 I've talked to Matt at the Summit this year about a message notification
 send by the server to the client indicating a successful CSI state
 change. We agreed on the change and I sent a patch to Matt a while ago.
 But the patch was not applied since then. I've created a PR now:
 https://github.com/xsf/xeps/pull/34


What? Why? What can a client do in response to the information? What would
it not do without it?

Also, why wrap the server notification in a message, and do I assume that
the use of two namespace versions is in error?


 That said: I don't think that CSI has sufficient adoption at the moment
 to move to draft.

 - Florian

Re: [Standards] Move CSI to Last Call (Proposed)

[Dave Cridland]

On 28 July 2015 at 10:11, Edwin Mons j...@edwinm.ik.nu wrote:

  On 28/07/15 11:05, Dave Cridland wrote:

   Also, why wrap the server notification in a message,

 And not using a Nonza? Because most libraries provide a mechanism for
 callbacks matching a given filter only for Stanzas. It's my impression
 as as XMPP client library developer, that we don't want Nonzas to
 trigger callbacks on the client side, as it would increase the
 complexity of XMPP client software stacks.


  It's very wrong.

  Consider a case where the client goes active, then switches to inactive
 but loses connection and recovers via '198. The response - which is tightly
 bound to the session - would indicate that the client was inactive, but
 would arrive on a subsequent connection which is not inactive.


 If you're doing in-band signalling, you really need to be able to
 distinguish signals from actual data.  If you use stanzas, you're making it
 very hard for yourself.


I'm considering writing an I-D for likes for email just for this.

Re: [Standards] Move CSI to Last Call (Proposed)

[Dave Cridland]

On 28 July 2015 at 10:13, Florian Schmaus f...@geekplace.eu wrote:

 On 28.07.2015 11:05, Dave Cridland wrote:
 
 
  On 28 July 2015 at 10:00, Florian Schmaus f...@geekplace.eu
  mailto:f...@geekplace.eu wrote:
 
  On 28.07.2015 10:20, Dave Cridland wrote:
  
  
   On 28 July 2015 at 08:22, Florian Schmaus f...@geekplace.eu
  mailto:f...@geekplace.eu
   mailto:f...@geekplace.eu mailto:f...@geekplace.eu wrote:
  
   On 27.07.2015 23:29, Sam Whited wrote:
Hi all,
   
I'd like to propose that the Council vote to move XEP-0452:
 Client
State Indication into last call (the Proposed State), and
 then
hopefully into draft afterwards.
   
The XEP has been sitting dormant since it was last updated
 almost a
year ago (2014-08-28).
  
   I've talked to Matt at the Summit this year about a message
 notification
   send by the server to the client indicating a successful CSI
 state
   change. We agreed on the change and I sent a patch to Matt a
 while ago.
   But the patch was not applied since then. I've created a PR
 now:
   https://github.com/xsf/xeps/pull/34
  
  
   What? Why? What can a client do in response to the information?
 
  The client knows for example that the roster presence information is
  up-to date. Basically I've an use case of a client using CSI which
 needs
  to take a decision based on the current presence state of the roster
  items. Imagine the following scenario: Client is in CSI inactive
 state,
  an external event triggers the client so that he needs to make an
  decision based on the presence state of the roster items. In order to
  get the latest presence information, the client switches to CSI
 active
  and waits for the queued presence stanzas to arrive. Without the CSI
  state change message notification, the client can't decide when the
 last
  queued presence stanza has arrived.
 
  And yes, I know that presence information can be always considered as
  outdated. Because even if you don't use CSI, the client's view of the
  presences could not reflect the state the client's roster items
 actually
  have.
 
  But having such a CSI message notification is a trivial change to
 CSI,
  and provides a huge benefit for this use case.
 
 
  So switch mode and ping.

 ?


Either a XEP-0199 request or a XEP-0198 r/ would typically flush the
queue, in as much as the server is likely to flush it anyway, in the rare
case you want to have up-to-date presence information immediately after
switching to active/. Is this really every time, in every case?

But your PR doesn't actually compel the server to flush presence state and
have this extra non-stanza stanza act as a sentinel indicating the other
stanzas which are not sentinels have all been sent.


   Also, why wrap the server notification in a message,
 
  And not using a Nonza? Because most libraries provide a mechanism for
  callbacks matching a given filter only for Stanzas. It's my
 impression
  as as XMPP client library developer, that we don't want Nonzas to
  trigger callbacks on the client side, as it would increase the
  complexity of XMPP client software stacks.
 
 
  It's very wrong.
 
  Consider a case where the client goes active, then switches to inactive
  but loses connection and recovers via '198. The response - which is
  tightly bound to the session - would indicate that the client was
  inactive, but would arrive on a subsequent connection which is not
 inactive.

 That's why https://github.com/xsf/xeps/pull/34 adds

 CSI enabled Servers MUST send an lt;active/gt; CSI notification after
 stream resumption (xep0198;),


What does after stream resumption mean? You'd need to ensure it was sent
after the replayed messages, and the client would still receive the
inactive/ notification message stanza. So when the client receives it, it
needs to know to ignore it because this is only a replay. Now we need to
distinguish '198 resumption replay stanzas from normal stanzas, in order to
avoid the stanzas affecting the client's perception of stream state. Except
now the CSI active non-stanza stanza acts as a sentinel here, meaning that
it's serving double duty. Only we have to track whether the extension was
in use at all in the previous stream in order to know whether to send it or
not.


 and

 The CSI state MUST NOT be keept when a stream is resumed by means of
 citeStream Management (XEP-0198) § 5. Resumption/cite;.


So in order to remove a special case you're adding more special cases.

You're also changing a Draft spec by the back door, which doesn't appeal to
me.

Dave.

Re: [Standards] Fwd: [Council] Minutes 2015-07-22

[Dave Cridland]

On 23 July 2015 at 08:43, Kevin Smith kevin.sm...@isode.com wrote:

 FYI

  Begin forwarded message:
 
  From: Kevin Smith
  Subject: [Council] Minutes 2015-07-22
  Date: 23 July 2015 08:41:27 BST
  To: XMPP Council
 
  Logs: http://logs.xmpp.org/council/2015-07-22/
 
  1) Roll call
  Kev, Dave, Lance, Fippo, MattJ present
 
  2) XEP-0327 Move to Draft?
  http://xmpp.org/extensions/diff/api/xep/0327/diff/0.6/vs/0.7
 
  Dave abstains, Fippo, Kev, Lance, Matt to vote on list.
 


For the record, I didn't abstain.

Advancement requires a majority vote, and Council members also have a veto.
I didn't vote for it, but didn't veto it  - I just voted. You could
describe it as a vote against (but not a veto). If three of my colleagues
vote the same way, it won't pass, lacking the required majority.

My reasoning is that it's not clear to me that there exists any demand
within the community for an interoperable protocol here. I've no objection
(in fact, I quite like) Experimental XEPs of this nature, but it's not
clear we want or need a Draft Standard which is based solely on the
experience and intent of a single actor within the community.

However, that is not to suggest there is anything *wrong* with the XEP.

The only alarm bell which did cause me to consider an actual veto was that
because few members of the community and/or industry as a whole seem
interested in the protocol, I worry that it lacks the required review and
sufficiently broad perspective required to make a quality, fully
interoperable, specification - however, I lack any evidence that this has
been the case.


  3) http://xmpp.org/extensions/inbox/mobile-concerns.html
  Accept as Experimental?
 
  All -1 for a new XEP, in favour of it being submitted as an update to
 XEP-0286.
 
  4) http://xmpp.org/extensions/inbox/raft.html
  Accept as Experimental.
 
  Dave, Matt +1. Fippo, Kev, Lance to vote onlist
 
  5) Date of next meeting
 
  2015-08-05 15:00Z. Kev sends potential apologies (not sure if I’ll be
 about or not).
 
  6) Any other business
 
  Kev started a discussion about Council’s role in review of XEPs vs
 ensuring adequate review is done - sometimes adequate review is done by a
 small number of people (or even one) if most of Council are too busy in the
 two-week period. Everyone to think about it before the next meeting to
 discuss whether it’s a problem, and how to improve it.
  (More discussion in the logs)
 


This, of course, ties in closely to XEP-0327. I suspect only Kev and Fippo
gave it the kinds of review needed, and it's not clear it's had review
outside of Council either.


  Fini.

Re: [Standards] Fwd: [Council] Minutes 2015-07-22

[Dave Cridland]

On 23 July 2015 at 10:23, Kevin Smith kevin.sm...@isode.com wrote:

 On 23 Jul 2015, at 08:58, Dave Cridland d...@cridland.net wrote:
   Dave abstains, Fippo, Kev, Lance, Matt to vote on list.
  
 
  For the record, I didn't abstain.

 He who writes the minutes…

 But less flippantly, I think this was an abstention. XEP-0001 uses the
 word ‘neutral’ to describe a vote of 0, (with +1 being approve and -1 being
 disapprove, with reasons), and formally stating that you are not voting for
 or against is, at least by the only dictionary I have to hand, the
 definition of abstention - meaning a neutral vote is an abstention.


Neutral is probably the better term, but not abstention.

An abstention would not count in terms of finding at least a simple
majority, and would also be illegal by XEP-0001, too, which says we must
vote.


  Advancement requires a majority vote, and Council members also have a
 veto. I didn't vote for it, but didn't veto it  - I just voted. You could
 describe it as a vote against (but not a veto). If three of my colleagues
 vote the same way, it won't pass, lacking the required majority.

 But there isn't the opportunity to vote against and not veto, per
 XEP-0001. One can informally say they don’t like it or have concerns, and
 formally abstain (0) in the vote, which I think is what this is.

 /K

Re: [Standards] XEP-0206

[Dave Cridland]

On 22 July 2015 at 09:48, Max Beloborodko f1ashhims...@gmail.com wrote:

 I'm messing with XEP-0206 and can't figure out

 quote
 If the BOSH body/ wrapper is not empty, then it SHOULD contain
 ...
 One or more complete message/, presence/, and/or iq/ elements
 qualified by the 'jabber:client' namespace.
 /quote

 should connection manager handle these stanzas if namespace is missing or
 not?



They're not stanzas if they're not in the right namespace, so no.

Re: [Standards] XEP-0206

[Dave Cridland]

On 22 July 2015 at 10:19, Kevin Smith kevin.sm...@isode.com wrote:

 On 22 Jul 2015, at 09:57, Dave Cridland d...@cridland.net wrote:
 
 
  On 22 July 2015 at 09:48, Max Beloborodko f1ashhims...@gmail.com
 wrote:
  I'm messing with XEP-0206 and can't figure out
 
  quote
  If the BOSH body/ wrapper is not empty, then it SHOULD contain
  ...
  One or more complete message/, presence/, and/or iq/ elements
  qualified by the 'jabber:client' namespace.
  /quote
 
  should connection manager handle these stanzas if namespace is missing
 or not?
 
 
  They're not stanzas if they're not in the right namespace, so no.

 If you actually want to interop with stuff, I don’t think that’s true.
 Various implementations just treat jabber:client as being implicit inside
 BOSH.


Ah, charming. I slouch disheartened, but corrected.


 /K

Re: [Standards] Initial thoughts on Raft over XMPP

[Dave Cridland]

On 21 July 2015 at 10:53, Peter Membrey pe...@membrey.hk wrote:

 Hi guys,

 Thanks for the encouragement and feedback!

 I'm working on the ProtoXEP now and I think it's coming along quite
 nicely. I hope to be able to submit it soon.

 I could use some guidance on how to best approach describing this
 protocol. The challenge is that I want to describe a transport layer for
 Raft, but I don't actually want to end up trying to describe Raft itself.
 For example, when I have an element with a number of attributes, should I
 be defining and explaining those attributes? Should I be explaining
 different conversations that two Raft nodes might under different (Raft
 related) circumstances, even though the message structure from XMPP's point
 of view is the same?

 I guess what I'm asking is, where should I draw the line between
 explaining what messages are needed in XMPP to support Raft and Raft
 itself...


It needs to make clear sense to someone who is not currently familiar with
Raft; so you need to explain where to find the supporting information. You
should avoid defining things defined in the Raft spec.

Examples are always good, especially if there are examples in the
literature that you can recast into your XMPP transport.


 Thanks in advance!

 Kind Regards,

 Peter Membrey


 - Original Message -
 From: Matthew A. Miller linuxw...@outer-planes.net
 To: XMPP Standards standards@xmpp.org
 Sent: Tuesday, 21 July, 2015 01:17:17
 Subject: Re: [Standards] Initial thoughts on Raft over XMPP

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512



 On 7/20/15 5:39 PM, Matthew Wild wrote:
  Hi Peter,
 
  On 20 July 2015 at 10:11, Peter Membrey pe...@membrey.hk wrote:
  Hi guys,
 
  As the subject suggests, I'm really interested in using the Raft
  consensus protocol over XMPP. I'll give you some background on
  the project I'm working on, some info on Raft and will then try
  to explain why I think XMPP is a great choice for transporting
  the raft data. It's the first time I've considered working on an
  XEP, so any constructive or critical feedback will truly be
  welcome! Also, thanks in advance for taking the time to read
  through all this.
 
  I am already working on a prototype to let me do this using
  custom message/ stanzas. It would be easy enough to do this as
  'chat' and place the payload in body/, but because the data
  fits structured XML so nicely, it just seemed plain wrong to
  overload 'chat'.
 
  So, as I'm probably going to have to do this work anyway, I
  wanted to get in touch with the community and see whether or not
  it thinks this would be a suitable case for an XEP. To be clear,
  I'm not suggesting we implement Raft itself in XMPP, but merely
  define a mechanism for transporting Raft messages within a
  cluster. I'm very happy to do the leg work and I'll certainly
  take on board all feedback that I get. If the overall vibe is
  positive, I'll start putting together a proto-XEP for submission
  to the XEP Editor.
 
  This sounds great, definitely something I'd be interested in seeing
  a XEP for :)
 
  I would omit the message type (it defaults to 'normal') and just
  put your XML inside the message instead of a body/. Unless you
  have something transactional (request/response), in which case use
  an iq/. It should be pretty straightforward, as you say.
 
  Finally, if this is your first XEP, some handy links:
 
  - https://xmpp.org/extensions/xep-0134.html -
  https://xmpp.org/extensions/xep-0143.html
 

 Just a note regarding XEP-0143.  It is now possible to submit
 proposals as a github Pull Request; the repository is at 
 https://github.com/xsf/xeps.git .  It's not instantaneous (the XEP
 Editors are not paid to do this job, after all), but we try to be
 quick and responsive.


 Look forward to the protoXEP!

 - --
 - - mm

 Matthew A. Miller
  http://goo.gl/LK55L 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2
 Comment: GPGTools - https://gpgtools.org

 iQEcBAEBCgAGBQJVrS0dAAoJEDWi+S0W7cO1V10IAKV9gPkBrNXyq+qO5vb9fExf
 qDYd/gpLsYgQCSzxn21IJi5WdgzkallBn2fbmZPK58j7Oxf1IAkF8QPFSeLwwhar
 y3TJ+ToQPwroyhRggKO8UjJVomf9WmXiSx/eK52cwh4uz2u0j21F+MJGV2mUUXAS
 uQRKsZUiQODGprMgRr5qiP2yCaCHS+S1vZyfIP486y5iDNdmDarJEvQ2zfvRcWLW
 zod/3Aj5vptyx0T5b/KFuvJdRDZqBZHoPe+/r4pVXGj2+9xinV+zVLU4FD+RcP+M
 c2jEpmgz43iNj6kWtREWzE+WbJ76lOKgmF5UOETm65djhVCHajlP3eqD9qRXofo=
 =ngYC
 -END PGP SIGNATURE-

Re: [Standards] Proposed XMPP Extension: Mobile Considerations

[Dave Cridland]

I think this is a very high-quality submission, and there's no doubt in my
mind that we want this to be a XEP.

However, I expected this to be a (sorely-needed) major edit to XEP-0286,
which I wrote some years ago and has lagged behind the times. For the
record, I'm perfectly happy to completely hand over authorship of that
specification to Sam.

It's not clear that XEP-0286 offers anything particularly worth keeping if
this protoXEP were to be accepted; any discussion about which bits of
XEP-0286 should be kept or removed is something of a moot point, and
secondary to the question of whether we need a new mobile XEP, or just
update the old one (potentially with entirely new text).

I'd be very interested in hearing any opinions on this one. Unless I get a
sense of what the community prefers by the meeting tomorrow, I'll likely
not vote in order to ensure I get a reasonable understanding.

On 21 July 2015 at 10:51, XMPP Extensions Editor edi...@xmpp.org wrote:

 The XMPP Extensions Editor has received a proposal for a new XEP.

 Title: Mobile Considerations

 Abstract:
 This document provides background information for XMPP
 implementors
 concerned with mobile devices operating on an LTE cellular
 network.


 URL: http://xmpp.org/extensions/inbox/mobile-concerns.html

 The XMPP Council will decide in the next two weeks whether to accept this
 proposal as an official XEP.

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

[Dave Cridland]

Can we add something into the security considerations for this document
which discusses the exposure of the jid in by, please?

Dave.

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

[Dave Cridland]

On 15 July 2015 at 16:12, Florian Schmaus f...@geekplace.eu wrote:

 On 15.07.2015 10:12, Dave Cridland wrote:
  Can we add something into the security considerations for this document
  which discusses the exposure of the jid in by, please?

 I had the same though, but then discarded adding such a consideration
 because the only JIDs worth protecting are the ones of clients. And
 those don't have a need to set the 'by' value.


If you considered it, then it's a security consideration. ;-)

More seriously, it exposes non-terminal jids in a manner that may or may
not leak something to an attacker - it may not ever leak anything useful in
the ways you've considered using it, but a protocol requiring id stamping
of some intermediary that's otherwise not exposed could be problematic.


 But, adding an explicit statement about (client) JID leaks can't hurt.
 Noted for the next version bump of XEP-SID.

 - Florian

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

[Dave Cridland]

While we're on the subject, is there any benefit to having a reestablish
mechanism in a more general sense? I'm thinking about the number of times I
tell colleagues that I'll call them right back - would we save much effort
in negotiation if we chose to repeat a previous session rather than create
a new one?

In this specific case, I don't see that jingle pub provides the same
semantic, without considerable effort and fiddling.
On 20 Jun 2015 13:09, Yann Leboulanger aste...@lagaule.org wrote:

 Hi all,

 I just read the version 0.16 of Jingle File Transfer XEP, and saw that
 you removed the request flow.
 Just to mention that it is used in Gajim to re-request the file at the
 end of a tranfer when hash was wrong.
 I don't think it's a good thing to removed a feature without a
 replacement, that's not very nice for clients to remove a feature they
 implemented.
 Please note also that this request thing was used by XEP-0329 that is
 now no more implementable!

 Is there a way to have it back in the XEP or have a replacement XEP for
 that feature?

 --
 Yann

Re: [Standards] Proposed XMPP Extension: Zero Handshake Server to Server Protocol

[Dave Cridland]

I think it's worth noting that low-bandwidth support is a key
differentiator for Isode's implementation, and so it's especially pleasing
to see this low-bandwidth binding of XML Streams be submitted for
standardization in this way. While I appreciate it's relatively niche, I
think it will benefit the community, and exemplifies the nature of the
community's relationship with industry, and our common desire for open
standards.

Non-blocking comments follow:

With this specification as written, what happens is, roughly, that a TCP
session is opened and then XML fragments sent as if a stream open had
been sent, something like:

message to='bob@nato.example' from='alice@mod.example' type='chat'
id='foo'bodyHi!/body/message
stream:error.../stream:error

Two questions:

1) What defines what the default namespace is? (I think it's mandatorily
defined as 'jabber:server')

2) When a stream is closed, should a close tag be exchanged? (I suspect
yes, for all the reasons given in XEP-0190)

3) What defines what the stream prefix means? (I think it's fixed as '
http://etherx.jabber.org/stream')

(1) and (3) can be specified as being due to an unsent stream:stream
xmlns:stream='...' xmlns='...' tag, or by configuration. I'd prefer to fix
the prefixes used, and minimize their use (ie, maybe require that stream
errors should be explicitly namespaced).

It's tempting, as a result, to define more, such as XEP-0198's namespace
for use with r/ and a/ elements, but this is rapidly increasing the
complexity of the approach.

An alternate design (changing the wire protocol) would be to send,
pipelined, the stream-open, which XML namespaces properly defined. I think
this is the most flexible approach, but I appreciate that accurately
defining what has been implemented is the right first step.

Bandwidth constraints for the deployment of this protocol suggest we want
to avoid explicitly namespacing elements if we can avoid it, so the
approach used in the WebSocket binding, for example, is likely
inappropriate.


On 14 July 2015 at 15:35, Steve Kille steve.ki...@isode.com wrote:

 Let me give a bit more background on this proto-XEP.

 We (Isode) have been involved with a number of systems operating over very
 high latency (several second) slow and flakey links.
 Using standard XMPP over these links is barely useable - many minutes to
 establish communications.

 The approach here of eliminating server to server handshakes has been
 implemented and tested in a number of UK and NATO trials.

 It seems desirable to make this useful approach available as a XEP.  NATO
 are keen to see this happen, and I prefer to avoid
 proprietary approaches.

 This proto-XEP writes up what we implemented. I'd welcome any input on
 this.

 Regards


 Steve


  -Original Message-
  From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of XMPP
 Extensions Editor
  Sent: 14 July 2015 14:31
  To: standards@xmpp.org
  Subject: [Standards] Proposed XMPP Extension: Zero Handshake Server to
 Server Protocol
 
  The XMPP Extensions Editor has received a proposal for a new XEP.
 
  Title: Zero Handshake Server to Server Protocol
 
  Abstract:
This specification defines an approach for a pair of servers to
 eliminate initial handshakes and associated
data transfer when using the XMPP S2S Protocol.  This approach may
 only be used with a priori agreement and configuration
of the two servers involved.  This is of significant benefit in high
 latency environments.
 
 
  URL: http://xmpp.org/extensions/inbox/optimized-s2s.html
 
  The XMPP Council will decide in the next two weeks whether to accept
 this proposal as an official XEP.

Re: [Standards] [editor] XEP-0082 errounously states that CCYY has four digits

[Dave Cridland]

On 2 July 2015 at 18:42, Peter Saint-Andre - yet pe...@andyet.net wrote:

 As to years with more than 4 digits, those would be needed starting in the
 year 1. Although I see no harm in mentioning the possibility of that, I
 doubt that XMPP will still be in use 7985 years from now. ;-)


Sometimes you're so pessimistic..

Dave.

Re: [Standards] Push and headline messages

[Dave Cridland]

On 1 July 2015 at 09:20, Mickaël Rémond mrem...@process-one.net wrote:

 Hello,

 XEP-0160 clarify the best practice for offline message and states for
 offline messages that headline message should not be stored for offline
 delivery:

  headline -- Messages with a 'type' attribute whose value is headline
 SHOULD NOT be stored offline, since such messages are usually
 time-sensitive.


 I think it implies that they should not be pushed as well. Otherwise, you
 may receive a push notification for a message you will never be able to
 receive if you reconnect.

 Am I wrong ?
 Do you think it could be useful to clarify the push XEP on that point ?


I don't think you're wrong in your interpretation, but it's not clear this
is a desirable outcome. Things that are time-critical information seem to
be exactly the things we need to ensure can be received via mobile push.

Dave.

Re: [Standards] XEP-0322: EXI for constrained processing environments

[Dave Cridland]

On 30 June 2015 at 18:40, Peter Waher peter.wa...@clayster.com wrote:

 Thanks for your input. For small devices, that do not wish to (or cannot)
 perform a dynamic handshake, there's the concept of quick configurations
 (§2.6). With a quick configuration ID, the entire setup is predefined. It
 can be defined, either in-band using a normal handshake, as described
 earlier, perhaps by a more powerful device, or out-of-band, by manual
 configuration of the server.


There is no §2.6 - did you mean §2.2.6?

Also this negotiation of quick configuration happens in XML prior to the
EXI switch doesn't it? Rick's problem is that he wants to have no XML
processing.

On that basis, I'm thinking a distinct port is the most sensible, which
would mean a different SRV name. It may be possible to combine these ports
into a single autodetecting port, but I'd rather leave that experiment
outside a spec for now.

Dave.

Re: [Standards] XEP-0322: EXI for constrained processing environments

[Dave Cridland]

On 26 June 2015 at 05:41, Rick van Rein r...@openfortress.nl wrote:

 I am thinking of constrained processing environments, such as clients on
 microcontrollers.  These may want to use EXI to avoid having to deal
 with the full XML notation, and they would most certainly not be
 serviced if they have to go through an initial handshake based on XML.


It's remarkable how small XML processors can be these days, but in any
case, have you considered how encryption fits into this, or were you
assuming a trusted network?

Dave.

Re: [Standards] Proposed XMPP Extension: Publishing Available Jingle Sessions

[Dave Cridland]

I was looking at that earlier. I'm not wholly convinced that this replaces
the use case lost from jingle file transfer.

I'll go into this more when I'm not on my mobile, but I think the hey,
that didn't work case is the one missing.
On 29 Jun 2015 17:30, Peter Saint-Andre - yet pe...@andyet.net wrote:

 Old thread alert!

 This document was considered by the Council in its meeting on August 13,
 2014:

 http://logs.xmpp.org/council/2014-08-13/

 Several Council members (Kev and Tobias) said they would vote on the list,
 and according to the minutes Kev was subsequently +1 but Tobias never
 voted. In any case, this document should have been published last August
 but apparently the Editor Team lost track of it (for which I take
 responsibility).

 IMHO since it was approved for publication, it can be published now. I'll
 poke the Editor Team about that. :-)

 Peter

 On 8/12/14 12:07 PM, XMPP Extensions Editor wrote:

 The XMPP Extensions Editor has received a proposal for a new XEP.

 Title: Publishing Available Jingle Sessions

 Abstract: This specification defines an XMPP protocol extension that
 enables an XMPP entity to advertise the fact that it is willing accept a
 particular Jingle session request. The protocol is used mainly to inform
 other entities that a particular file is available for transfer via the
 Jingle File Transfer protocol defined in XEP-0234.

 URL: http://xmpp.org/extensions/inbox/jingle-pub.html

 The XMPP Council will decide in the next two weeks whether to accept this
 proposal as an official XEP.

Re: [Standards] Request HTTP upload slots over XMPP

[Dave Cridland]

https://xkcd.com/927/

On 28 June 2015 at 21:43, Daniel Gultsch dan...@gultsch.de wrote:



 2015-06-28 20:36 GMT+02:00 Christian Schudt christian.sch...@gmx.de:

 Jingle File Transfer might be rarely implemented currently, because it is
 still in Experimental status. But a new (experimental) protocol (yet
 another one for file transfer), which will probably evolve as well, would
 certainly be implemented far less than Jingle FT and add more confusion to
 the question „how does file transfer work in XMPP“.


 I don't think the lack of implementation of jingle and jingle ft is due to
 the 'experimental status' but due to the complexity. I think people try to
 implement a general stack for all jingle applications and then get stuck
 because it is just so much work. (Like I said I was trying to do exactly
 this and was researching libraries that come with jingle support and I
 found many unfinished jingle implementations across all sort of libraries
 and languages)



  I don't see any upside of sticking with Jingle besides that it is
 somewhat the XMPP-way“.

 - Reuse of existing protocols
 - Less complexity for developers who already have to do a stretch to
 support the different file transfer protocols under a general API.
 - Different transports can be used for upload. Not only HTTP but also
 SOCKS5 and IBB.
 - Jingle (File Transfer) semantics can be reused, e.g. to cancel or
 reject a file upload or to communicate the hash, the file name, the file
 size, etc...

 I don’t know if Jingle (FT) is really suitable for the use case, but at a
 first glance it feels like the most obvious approach.


 Jingle FT would suitable (It doesn't provide an easy way to communicate
 the GET-URL back to the sender but that could for example be solved by some
 convention thing in the service discovery like always use a fixed prefix
 for the GET urls followed by a file name provided by the user)

 I fully agree with you that having a jingle based approach maybe including
 a HTTP Transport method would be the ideal and perfect solution for this.
 However I doubt that this will happen any time soon. Multiple vendors are
 already moving to their own niche solutions. (Kontalk is using a similar
 approach. One XMPP based social network (I forgot which one) is doing
 something similar. Many users are already doing exactly the same thing but
 manually (upload files to owncloud and sharing the link))

 If we look at this from a business point of view using HTTP upload is imho
 the most cost effective way of doing this. If someone comes to me and says:
 hey we want an xmpp based instant messenger with the ability to send files
 to groups and multiple instances and we don't really care about standards
 just make this happen I would always go with the HTTP based solution.

 The question is do we wait another 10 years and try to come up with a
 perfect jingle standard and have people that need a solution now come up
 with their own incompatible custom extensions or do we provide those people
 with a very small XEP that is easily implemented and can serve as a
 temporary solution until the perfect solution is ready.


There's two interesting cases. First, you need to send someone a URL for
where to get the file.

Second, you need to put the file there.

A mechanism for denoting files available over HTTP seems pretty
straightforward, and since I'm not sure how many server operators really
want to get into the Dropbox/Box/Adrive/GoogleDrive/OneDrive/etc market,
maybe the upload isn't something you need to do over XMPP at all.

Re: [Standards] guest access

[Dave Cridland]

On 26 June 2015 at 13:40, Peter Saint-Andre - yet pe...@andyet.net wrote:

 On 6/26/15 5:57 AM, Dave Cridland wrote:



 On 26 June 2015 at 00:51, Peter Saint-Andre - yet pe...@andyet.net
 mailto:pe...@andyet.net wrote:

 Lance Stout and I had a conversation the other day about what we
 call guest access to an XMPP application. As example, consider a
 chat service (text, video, what have you) that has registered users
 and the ability for registered users to invite ad-hoc users to a
 session or meeting. This kind of functionality is quite common with
 applications like video conferencing (Talky, Jitsi Meet, WebEx, etc.).

 If this kind of application is based on XMPP, the invited user needs
 to gain access to the network (i.e., authenticate somehow) in order
 to join the conference. However, for security and scaling reasons it
 makes sense to have these ad-hoc users authenticate at a different
 place than the registered users. (Often, but not always, the ad-hoc
 users might authenticate using the SASL ANONYMOUS mechanism, but
 other methods are possible such as token auth.)

 Thus we need a way for a client to discover where it can
 authenticate as an ad-hoc or guest user. We don't want to use a DNS
 SRV Service name of xmpp-client because that will point clients to
 the service endpoint for registered users. What we came up with was
 to use a new DNS SRV Service name of xmpp-guest, which would point
 to the service endpoint for guest access.


 Can't the invitation include the connection detail?


 At least for Talky as it's current structured, the invitation is just a
 URL. Using standard URL-based and DNS-based methods seems best:

 1. Strip off the room name (path) and the URL scheme to get the domain
 2. Query the domain (via SRV) about where to gain guest network access


What does this URL look like?

I'm assuming that the inviter knows that the invitee needs guest access, in
which case the invitation URL can presumably encode what's needed, even if
it's just a guest domain to be looked up in the normal manner. Or even if
it's an HTTP URL which derefs for more extensive information.

Dave.

Re: [Standards] MUC2 - The case for removing semi-anonymous

[Dave Cridland]

On 26 Jun 2015 07:24, Steve Kille steve.ki...@isode.com wrote:

 
  I would like us to Get This Right, though. People have been mumbling
about replacing MUC for years, and I’ve always been resistant;
  the discussions at the summit this year persuaded me that we finally
have requirements that MUC1 can’t easily meet, but I really do
  not want us to do MUC2 now and MUC3 in 2017 to fix the stuff we got
wrong in MUC2.

 [Steve Kille]
 Kev -  I strongly agree with this goal.


I think a key criterion for success will be if MUC2 can meet all commonly
deployed use-cases across both XEP-0045 and other multiparty chat
(including non-XMPP cases).

 It seems to me that the default semi-anonymous MUC1 is generally seen as
the way MUC works and is not a conscious option selection choice.


It's tempting to go that way, but it's very close to saying I disagree
with the outcome, so the evidence must be wrong.

The problem is that the only evidence we have as to how desirable this
feature is is the number of chatrooms commonly using it. That *could*
easily be that it's the default in many servers, but that in turn raises
the question of why that's so.

In short, I don't claim to know, but I hesitate to ascribe all such use to
ignorance on behalf of the administrators.

What I can tell you is that when I asked about the Prosody default (it's
semi-anonymous), the response was that we try to make the defaults privacy
friendly; this implies that the default, at least, was a conscious choice.

I've a feeling that M-Link defaults the same way for the same reason -
maybe that's changed (and if not, maybe it should).

 I've not seen use where this behaviour seems particularly desirable.   I
have seen significant customer concern about controlling mis-leading use of
nicks and people misrepresenting themselves in MUCs. I suspect that
non-anonymous would be better behaviour for many MUC users, but there has
not been active consideration to use it.


So what you're saying is that in all the chatrooms I'm usually in, only the
Openfire project leads have considered how to configure their chatroom? I'd
note for the record that I'm usually present in both Prosody chatrooms and
XSF chatrooms (xsf@ and jdev@), all of which are semi-anonymous. It seems
odd to me that anonymity is such a problem if the administrators there are
content to leave it in place - they're hardly unaware of the way MUC
works. After all, many of those administrators are on this thread.

I think within government, military, and enterprise, strong identity is an
absolute requirement, but I'd note that misleading use of nicks and people
misrepresenting themselves in MUCs is soluble already by nickname
enforcement and registration, as part of XEP-0045. So if your customers are
concerned about that, you should show them that, as well as (of course) the
non-anonymous configuration.

Finally, I'd note that under the semi-anonymous model, both the chatroom
itself and any administrators are fully aware of the real jid of the
occupant, and can act directly upon it - so the scope for abuse is limited
entirely to what the chatroom allows. (Unless the abuse is also possible by
non-anonymous users).

 MUC2 will allow MUCs to allow users to read MUCs without sharing
presence.   This seems a highly desirable option (lots of reasons).   This
option will allow people to read MUCs anonymously, which I think for some
MUCs can be a sensible and desirable privacy option.


I don't think that the absence of presence means (or should mean) that
subscriptions are anonymous or invisible. Part of basic privacy would be
being aware of people reading your messages, even those messages to a group.

The only way to read such messages would be if the archive was available to
unsubscribed users.

 I think that if you want to share your presence with the group or send a
message to a group, that enforcing that you also share your jid is highly
desirable.In XMPP the jid is who you are.   I can't see a clear use
case for allowing people to post to a MUC without clearly identifying
themselves.

I absolutely agree that making non-anonymous better is highly desirable.
In a number of markets, and certainly in Isode's and Surevine's, hiding
the real jid behind an occupant jid is problematic, and the relative
obscurity of the real jid in MUC means that non-anonymous rooms are
somewhat of a second-class citizen. From a technical standpoint, having the
address of an occupant, and therefore the identity, selected by that
occupant causes a number of issues, including security ones.

However, just because non-anonymous is useful for some markets should not
preclude anonymity for others.

Dave.

Re: [Standards] guest access

[Dave Cridland]

On 26 June 2015 at 00:51, Peter Saint-Andre - yet pe...@andyet.net wrote:

 Lance Stout and I had a conversation the other day about what we call
 guest access to an XMPP application. As example, consider a chat service
 (text, video, what have you) that has registered users and the ability for
 registered users to invite ad-hoc users to a session or meeting. This kind
 of functionality is quite common with applications like video conferencing
 (Talky, Jitsi Meet, WebEx, etc.).

 If this kind of application is based on XMPP, the invited user needs to
 gain access to the network (i.e., authenticate somehow) in order to join
 the conference. However, for security and scaling reasons it makes sense to
 have these ad-hoc users authenticate at a different place than the
 registered users. (Often, but not always, the ad-hoc users might
 authenticate using the SASL ANONYMOUS mechanism, but other methods are
 possible such as token auth.)

 Thus we need a way for a client to discover where it can authenticate as
 an ad-hoc or guest user. We don't want to use a DNS SRV Service name of
 xmpp-client because that will point clients to the service endpoint for
 registered users. What we came up with was to use a new DNS SRV Service
 name of xmpp-guest, which would point to the service endpoint for guest
 access.


Can't the invitation include the connection detail?

Dave.

Re: [Standards] MUC2

[Dave Cridland]

On 25 June 2015 at 15:28, Peter Saint-Andre - yet pe...@andyet.net wrote:

 On 6/25/15 2:27 AM, Kevin Smith wrote:

 Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon.


 s/had/has/

  We’ve pretty much killed off fully anonymous rooms in MUC1.


 I think those were never supported.

  Can people share their thoughts on usecases for semi-anon, please?


 Semi-anonymous rooms are like IRC channels. Draw your own conclusions for
 whether that's good or bad.

  It’s not entirely clear to me what these are (users who want
 anonymity seem to already be using throw-away JIDs to achieve that,
 instead of relying on MUC configuration).


 We didn't have throw-away JIDs (well, SASL anonymous JIDs anyway) in the
 old days.

  There seems to be some significant merit in having MUCs always be
 non-anonymous in MUC2, to solve some of the addressing messes we’ve
 found ourselves in.


 I do think that a system needing anonymity (say, a helpline) can handle
 that using anonymous JIDs, not anonymous roomnicks.


I vaguely recall that many years ago we discussed that individuals have
anonymity requirements, and not rooms. If you predicate the existence of
services which act as pseudonymizers (if you're one of the ancients,
anon.penet.fi), then chaining a few of these together gives much stronger
assurances than an anonymous MUC room ever could.




 Peter

 --
 Peter Saint-Andre
 https://andyet.com/

Re: [Standards] MUC2

[Dave Cridland]

On 25 Jun 2015 18:05, Kevin Smith kevin.sm...@isode.com wrote:

 On 25 Jun 2015, at 16:59, Dave Cridland d...@cridland.net wrote:
  Removing a widely deployed feature doesn't strike me as a viable option.

 Well, if we s/widely deployed/widely required/ then I agree. But not
baking something into the MUC2 core doesn’t necessarily mean removing the
feature. If we’re going to try to blank-canvas a MUC replacement, I’d like
to try and look at options as widely as we can.


Well, what you're trying to avoid is addressable occupants, correct?

That removes private messages, rather than anonymity, I think. Private
messages do cause problems in a variety of interesting ways, but equally I
find it interesting that they provide me with an immediate indicator of
where someone has found me.

 For example, (assuming semi-anonymousness is a requirement) is it
possible to not require anything other than non-anonymous in MUC2, but
discuss (either in spec or out of spec) how one would do anonymising if one
wanted to?

 I don’t know.


Maybe the better idea is to look at how chatrooms are actually used, and
run UX interviews with people who are regular users. It's not very
technical, I admit, but I find it very hard to gauge whether some of these
features are desirable or confusing, since I've simply got used to this
being the way things work.

People keep telling us that Slack has ask these things right, but aside
from having a nice user interface and plenty of integration, I'm not clear
if there's anything else that makes it a clear winner.

 I would like us to Get This Right, though. People have been mumbling
about replacing MUC for years, and I’ve always been resistant; the
discussions at the summit this year persuaded me that we finally have
requirements that MUC1 can’t easily meet, but I really do not want us to do
MUC2 now and MUC3 in 2017 to fix the stuff we got wrong in MUC2.

 /K

Re: [Standards] MUC2

[Dave Cridland]

On 25 June 2015 at 09:27, Kevin Smith kevin.sm...@isode.com wrote:

 Thinking a bit about the MUC2 stuff. MUC1 had Anon/semianon/nonanon. We’ve
 pretty much killed off fully anonymous rooms in MUC1.

 Can people share their thoughts on usecases for semi-anon, please? It’s
 not entirely clear to me what these are (users who want anonymity seem to
 already be using throw-away JIDs to achieve that, instead of relying on MUC
 configuration).

 There seems to be some significant merit in having MUCs always be
 non-anonymous in MUC2, to solve some of the addressing messes we’ve found
 ourselves in.


Some thoughts:

I think almost every MUC room I'm in is semi-anonymous.

The only exception I could immediately find was the Openfire chatroom,
open_c...@conference.igniterealtime.org - it seems pretty unlikely that
this is by accident, but perhaps every server does this by default, and
none of the admins have ever noticed. Removing a widely deployed feature
doesn't strike me as a viable option.

I (personally, mind you) would be happy if pseudonymized users in chatrooms
reduced available features. For example, it seems bizarre that in the
typical [semi-]anonymous MUC, I can query a vCard of an anonymous user.
So for example I can join the XSF chatroom, and while I cannot discover
Zash's jid, I can find his real name and email address. This strikes me as
nuts.

I also suspect that if we promoted the usage of anonymizers as a day-to-day
way to shield one's jid, this might have detrimental effects on chatroom
abuse.

Dave.

Re: [Standards] Proposed changes to XEP-0233

[Dave Cridland]

Is this for any client connecting to a server running on Windows, or for
clients running on Windows connecting to any client, or some other
permutation?

On 24 June 2015 at 12:40, Mili Verma mili.ve...@isode.com wrote:

 Hi,

 I've proposed some changes to XEP-0233, mainly about how to construct the
 Kerberos Principal Name for an XMPP server on Windows.

 Could I please have some feedback on the attached xep before I submit it?

 Cheers!
 Mili

Re: [Standards] {Core|Advanced} {Client|Server} 2015

[Dave Cridland]

On 18 Jun 2015 15:01, Kurt Zeilenga kurt.zeile...@isode.com wrote:

 What’s the bar for “core”?  I would think it at least mature Draft
standard if not Full standard.

 I don’t think it’s appropriate to add Carbons to core when it seems that
there’s not consensus that it’s the best solution for any problem the
majority of XMPP IM/MUC deployments are facing.


There's consensus, I would argue, given that it's extremely well supported
in servers, desktop and mobile clients. In fact, finding servers that
didn't support it a year ago is hard.

 — Kurt

  On Jun 17, 2015, at 2:41 PM, Peter Saint-Andre - yet pe...@andyet.net
wrote:
 
  On 6/17/15 3:33 PM, Dave Cridland wrote:
 
 
  On 17 June 2015 at 20:52, Curtis King ck...@mumbo.ca
  mailto:ck...@mumbo.ca wrote:
 
 
  On Jun 17, 2015, at 8:46 AM, Dave Cridland d...@cridland.net
mailto:d...@cridland.net wrote:
 
  Folks,
 
  Many moons past, before the dawn of a couple of years ago, we had
things like XEP-0302, which declared that - excitingly - advanced servers
might want to implement PEP.
 
  I think that these days, any server should be doing PEP. I
suspect we're nearing the point where we need to consider Carbons as a
Core, rather than Advanced”.
 
 When was Carbons even listed as Advanced?
 
 
  Yeah... I read that back and wondered what the hell I meant, sorry,
that
  was hopelessly unclear of me.
 
  I meant to say that Carbons wasn't even on there before, whereas it's
  now pretty much essential.
 
  Agreed with respect to the technology. With respect to the process, the
Carbons XEP is still Experimental. I think that it's not right to make a
XEP part of a compliance suite if it's still Experimental. But that can be
solved by moving the XEP forward on the standards track.
 
  Peter
 
  --
  Peter Saint-Andre
  https://andyet.com/

Re: [Standards] {Core|Advanced} {Client|Server} 2015

[Dave Cridland]

On 18 Jun 2015 15:40, Curtis King ck...@mumbo.ca wrote:


 On Jun 18, 2015, at 7:25 AM, Dave Cridland d...@cridland.net wrote:

 There's consensus, I would argue, given that it's extremely well
supported in servers, desktop and mobile clients. In fact, finding servers
that didn't support it a year ago is hard.


 Two servers and maybe 5 clients does not make for well supported in my
book.

Which two were you thinking of?

Ejabberd has supported it for two years, Openfire for 18 months or so on
trunk, prosody for ages. I don't know about the others, but those three
account for a very high percentage of deployed domains, once one excludes
Google, who don't implement anything anyway.

 But, how well an extension is supported doesn’t give it special rights to
skip the standardization process.


Supported isn't the same as deployed, and I'm not arguing high deployment
skips the standards process. However, it does offer evidence that it works,
and is desirable, and high deployment does suggest high consensus.

Arguing against it on the basis that an unwritten perfect protocol would be
better is a much weaker argument.

 ck

Re: [Standards] {Core|Advanced} {Client|Server} 2015

[Dave Cridland]

On 18 Jun 2015 19:21, Curtis King ck...@mumbo.ca wrote:


 On Jun 18, 2015, at 8:45 AM, Dave Cridland d...@cridland.net wrote:


 On 18 Jun 2015 15:40, Curtis King ck...@mumbo.ca wrote:
 
 
  On Jun 18, 2015, at 7:25 AM, Dave Cridland d...@cridland.net wrote:
 
  There's consensus, I would argue, given that it's extremely well
supported in servers, desktop and mobile clients. In fact, finding servers
that didn't support it a year ago is hard.
 
 
  Two servers and maybe 5 clients does not make for well supported in my
book.

 Which two were you thinking of?

 Ejabberd has supported it for two years, Openfire for 18 months or so on
trunk, prosody for ages. I don't know about the others, but those three
account for a very high percentage of deployed domains, once one excludes
Google, who don't implement anything anyway.



 Ok three servers if count a 3rd party plugin for Prosody.


Yeah, I'd misunderstood prosody.

  But, how well an extension is supported doesn’t give it special rights
to skip the standardization process.
 

 Supported isn't the same as deployed, and I'm not arguing high
deployment skips the standards process. However, it does offer evidence
that it works, and is desirable, and high deployment does suggest high
consensus.



 You keep making general statements with out any supporting facts. From
where I sit, I see zero deployment. I can’t find a single iOS XMPP client
which supports 280, Trillian has rolled their own solution, all I can find
is a few Android clients, some web frameworks, and after 30 minutes of
looking zero desktop clients. Far from an exhaustive survey but from your
statements I figured it would be easy to find clients which support 280.


Gajim, for one. And as for iOS XMPP clients, those are thin on the ground
anyway.

 Arguing against it on the basis that an unwritten perfect protocol would
be better is a much weaker argument.



 I did no such thing. I will rephrase.

 Is XEP-0280 a complete solution to it’s stated problem? I say no because
it does not support the offline case.

I don't think it's aiming to support offline use, so I'd disagree with this
assertion.

 Should a XEP with an incomplete solution be included in the Compliance
Suites? If yes, at what level?

An incomplete solution to what? 198 is an incomplete solution to the two
generals problem, but I wouldn't say it's a waste of time as a result.

Extensions solve specific use cases, and mobile is really broad,
consisting of many different aspects.

 Should a XEP be able to be added to the Core level by-passing the
Advanced level?


If we'd had a compliance suite since 2012, and mind you, that one was
deferred, then I'd say no.

I suppose it really depends on what the suits are for. I see them as a way
of saying, if you want a basic server, a sensible minimum is this stuff in
Core. Those are your cut-off features.

If you want a really good all round experience, you want Advanced.

But you here is typical internet usage, we're not talking tactical, or
IoT, or any of the other use cases.

I imagine reaching consensus on what the compliance suites mean would be a
useful first step.

 ck

Re: [Standards] {Core|Advanced} {Client|Server} 2015

[Dave Cridland]

On 17 June 2015 at 20:08, Sam Whited s...@samwhited.com wrote:

 On Wed, Jun 17, 2015 at 10:46 AM, Dave Cridland d...@cridland.net wrote:
  I think that these days, any server should be doing PEP. I suspect we're
  nearing the point where we need to consider Carbons as a Core, rather
 than
  Advanced.

 I agree, but before the XSF recommends Carbons as a core feature they
 should probably advance it beyond Experimental (but that's a topic for
 another thread). There are many good implementations of Carbons out
 there in servers and clients; making it draft is possibly the best way
 to recommend it and should be seen as a pre-requisite to adding it
 to a new recommendations XEP I think. Glancing back at the 2012
 compliance suite XEP, it looks like this might have been a matter of
 policy? They were all draft or higher, I think.


That's a good point. But I'd rather get a shopping list together and then
figure out how to make things Draft if they're not.


  1) Is anyone else interested in putting together a new set of
  recommendations for XEPs to implement?

 I'd be happy to help put together the list of recommendations,
 unfortunately my time for working on things like this has become
 extremely limited in recent months.


  2) If so, does anyone have some solid ideas about what's minimum, and
  sensible, these days?

 A few things that should probably be looked into (other stuff from the
 old XEPs should be on there too, these just need changes, IMO) off the
 top of my head:

 - PEP (Core)
 - Message carbons (Core)
 - Blocking command (moved to Core)
 - MUC (moved to Core)
 - Stream management (moved to Core)
 - XEP-0048: Bookmarks (not sure where; probably Core)
 - MAM (advanced)
 - CSI (not sure where; probably advanced, but I'm tempted to say Core
 given the benefits for mobile)


 — Sam


 --
 Sam Whited
 pub 4096R/54083AE104EA7AD3
 https://blog.samwhited.com

Re: [Standards] {Core|Advanced} {Client|Server} 2015

[Dave Cridland]

On 17 June 2015 at 22:41, Peter Saint-Andre - yet pe...@andyet.net wrote:

 On 6/17/15 3:33 PM, Dave Cridland wrote:

 I meant to say that Carbons wasn't even on there before, whereas it's
 now pretty much essential.


 Agreed with respect to the technology. With respect to the process, the
 Carbons XEP is still Experimental. I think that it's not right to make a
 XEP part of a compliance suite if it's still Experimental. But that can be
 solved by moving the XEP forward on the standards track.


Well, I think it's OK (and possibly even useful) to include Experimental
extensions in the compliance suite while the suite is itself Experimental.

As I said to Sam, I think it'd be useful to build the shopping list, and
then we can figure out where additional work is needed.

Dave.

Re: [Standards] {Core|Advanced} {Client|Server} 2015

[Dave Cridland]

On 17 Jun 2015 22:56, Curtis King ck...@mumbo.ca wrote:


 On Jun 17, 2015, at 2:33 PM, Dave Cridland d...@cridland.net wrote:

 Two years ago I agreed with you entirely. I maintained this position
until I switched to a server and set of clients that supported it, and then
found it actually works pretty well. I know there's potential theoretical
holes, but i suspect those are more plugged than not with 198 and MAM.


 So, the quality standard we are aiming for is pretty well, with the holes
plugged by other XEPs :-)

Perfect being the enemy of pretty well, to paraphrase von Clausewitz.

In this case, pretty well means that for a user, the edge cases don't
appear to get hit. Maybe I'm not experiencing them, though.

 Since you always have to fall back to MAM in the multi-client case why
not just use MAM always?


You can't. You would need to add in a bunch of stuff. If carbons weren't
implemented by almost every server and a whole bunch of clients, that would
be a more compelling argument.

 ck

Re: [Standards] {Core|Advanced} {Client|Server} 2015

[Dave Cridland]

On 17 June 2015 at 20:52, Curtis King ck...@mumbo.ca wrote:


  On Jun 17, 2015, at 8:46 AM, Dave Cridland d...@cridland.net wrote:
 
  Folks,
 
  Many moons past, before the dawn of a couple of years ago, we had things
 like XEP-0302, which declared that - excitingly - advanced servers might
 want to implement PEP.
 
  I think that these days, any server should be doing PEP. I suspect we're
 nearing the point where we need to consider Carbons as a Core, rather
 than Advanced”.

 When was Carbons even listed as Advanced?


Yeah... I read that back and wondered what the hell I meant, sorry, that
was hopelessly unclear of me.

I meant to say that Carbons wasn't even on there before, whereas it's now
pretty much essential.


 I’m still at a loss to find a problem which Carbon fully solves. It always
 fails in the case were a carbon is lost and it sure doesn’t save any
 bandwidth.


Two years ago I agreed with you entirely. I maintained this position until
I switched to a server and set of clients that supported it, and then found
it actually works pretty well. I know there's potential theoretical holes,
but i suspect those are more plugged than not with 198 and MAM.

Dave.

[Standards] {Core|Advanced} {Client|Server} 2015

[Dave Cridland]

Folks,

Many moons past, before the dawn of a couple of years ago, we had things
like XEP-0302, which declared that - excitingly - advanced servers might
want to implement PEP.

I think that these days, any server should be doing PEP. I suspect we're
nearing the point where we need to consider Carbons as a Core, rather
than Advanced.

At the Council meeting, we briefly discussed the idea of a new suite XEP or
two.

So I have three questions for you:

1) Is anyone else interested in putting together a new set of
recommendations for XEPs to implement?

2) If so, does anyone have some solid ideas about what's minimum, and
sensible, these days?

3) Anyone want to edit it?

Dave.

Re: [Standards] Dealing with offline messages in times of MAM

[Dave Cridland]

On 10 June 2015 at 05:58, Daniel Gultsch dan...@gultsch.de wrote:

 Even though not yet quite perfect (see the discussion about Message-ID and
 MR2) MAM works reasonable well. A MAM capable client has no trouble to
 automatically catch up with lost messages.  However if the MAM capable
 client is the only client in the game it will (with normal setups)
 regularly receive both the offline messages and the messages downloaded
 from the MAM archive. Now client side de-duplication usually works good
 enough for the average user not to notice however this is far from being an
 ideal solution.

 Is there a solution to this problem that can simply be solved by server
 side configuration?
 Will simply disabling offline message return all messages to the sender
 even though they are stored in MAM?

 Maybe it is time to develop some business rules or best practises that
 deal with this scenario and the maybe similar scenario of what should
 happen with messages that get failed due to a SM time out.


SM is easy - discard all presence/, bounce all iq/ set/get, and
redeliver all message/. (Technically, you can bounce a presence
type='probe'/ too).

For offline messages and MAM-capable clients, there's always XEP-0013,
though that's rather more heavyweight than we need.

Re: [Standards] Dealing with offline messages in times of MAM

[Dave Cridland]

On 10 June 2015 at 15:37, Sam Whited s...@samwhited.com wrote:

 Slightly OT:

 On Wed, Jun 10, 2015 at 2:55 AM, Georg Lukas ge...@op-co.de wrote:
  Still, we can not get rid of one as long as not all clients support the
 other.

 I disagree; the point of a standards body isn't to maintain every
 solution that all clients support, it's to guide clients in what they
 SHOULD support.


Actually, it's to do both.

Breaking existing clients, or for that matter just ignoring them, isn't an
option. What we need to do is ensure there's a transition from simple
offline messaging to MAM, and ensure that simple offline messaging
continues to work properly even a few years from now.

I think that's probably what you're saying below, but I don't want people
to get the impression that old methods for doing things will become invalid.

One thing we've not done in recent years is to provide profiles of what
clients and servers ought to support these days. If you'd like to have a
crack at putting together such a guide, I'd be keen to see those restarted.


 Deprecating old XEPs when something new (full
 replacement or just similar functionality that works better) comes
 along (after it has a few stable implementations to prove that there
 are no bariers to adoption) is a desirable outcome. You're not telling
 clients that they must upgrade right away and drop support for the old
 thing, just nudging them in that direction. As it stands there are
 already too many XEPs with similar enough functionality that they're
 effectively duplicates (eg. Blocking Command and Privacy Lists is one
 I've been known to complain about in the past; they're not identical,
 but it leads to odd client incompatibilities and a bad user
 experience), and this sort fo thing should not continue.

 Best,
 Sam


 --
 Sam Whited
 pub 4096R/54083AE104EA7AD3
 https://blog.samwhited.com

Re: [Standards] Proposed XMPP Extension: Nonzas (are not Stanzas)

[Dave Cridland]

On 5 Jun 2015 08:44, Florian Schmaus f...@geekplace.eu wrote:

 On 05.06.2015 09:36, Dave Cridland wrote:
  On 5 June 2015 at 07:24, Florian Schmaus f...@geekplace.eu
  mailto:f...@geekplace.eu wrote:
 
  On 04.06.2015 09:39, Kevin Smith wrote:
   On 3 Jun 2015, at 16:02, XMPP Extensions Editor edi...@xmpp.org
mailto:edi...@xmpp.org wrote:
   http://xmpp.org/extensions/inbox/nonza.html
 
   The definition here seems potentially useful. I would add a
‘generally’ to 4 so that it becomes “...they are generally used in a
more…”, so as not to be seen as prescriptive.
 
  Good point, going to change it.
 
   None of the current nonzas are routed, but it doesn’t seem
impossible that one might be in the future, and I don’t see a reason to
forbid it here. Noting that they’re not expected to be routed seems useful
and sufficient, to me.
 
  If you want to send something that is supposed to get routed, why
  wouldn't you use simply a Stanza instead? I consider it a security
  improvement if routing of Nonzas is explicitly forbidden.
 
 
  I think the definition of a stanza is a routed top-level element, so an
  extension that negotiated routed Nonzas is actually negotiating a new
  stanza type. My reading of RFC 6120 seems to leave room for negotiating
  new stanzas (and moreover, they needn't have the common attributes of
§8.1).

 I don't think so. It appears to me that Stanzas are very well defined in
 RFC 6120. See below.

  However, I don't think that RFC 6120 actually defines what a stanza
  *is*.

 From XEP-Nonza:

 Stanzas ... are specified in RFC 6120 [2] § 4.1 Stream Fundamentals
 and § 8. XML Stanzas


Ah, yes. Hadn't noticed the 4.1 definition. That's very much more
restrictive, and doesn't seem to leave room for new stanza types.

Moreover, it also suggests that XEP-0114 stanzas aren't actually stanzas.
Therefore under this proposal they would be unroutable nonzas.

  3) Some convenient term of art for first child elements of the stream -
  ie, the collective term for both Stanzas and Nonzas.

 Top-level stream element?


We've used TLE in the past, I think.

 - Florian

Re: [Standards] Proposed XMPP Extension: Nonzas (are not Stanzas)

[Dave Cridland]

On 5 June 2015 at 07:24, Florian Schmaus f...@geekplace.eu wrote:

 On 04.06.2015 09:39, Kevin Smith wrote:
  On 3 Jun 2015, at 16:02, XMPP Extensions Editor edi...@xmpp.org wrote:
  http://xmpp.org/extensions/inbox/nonza.html

  The definition here seems potentially useful. I would add a ‘generally’
 to 4 so that it becomes “...they are generally used in a more…”, so as not
 to be seen as prescriptive.

 Good point, going to change it.

  None of the current nonzas are routed, but it doesn’t seem impossible
 that one might be in the future, and I don’t see a reason to forbid it
 here. Noting that they’re not expected to be routed seems useful and
 sufficient, to me.

 If you want to send something that is supposed to get routed, why
 wouldn't you use simply a Stanza instead? I consider it a security
 improvement if routing of Nonzas is explicitly forbidden.


I think the definition of a stanza is a routed top-level element, so an
extension that negotiated routed Nonzas is actually negotiating a new
stanza type. My reading of RFC 6120 seems to leave room for negotiating new
stanzas (and moreover, they needn't have the common attributes of §8.1).

However, I don't think that RFC 6120 actually defines what a stanza *is*.
Sending an unknown top-level element gives you an
unsupported-stanza-type/ error, and it lists what stanzas it defines, and
talks a lot about them. But nowhere does it say, much to my surprise,
something like Stanzas are first-child element of the stream that are
routable between XMPP entities addressable by jids.

This leaves this XEP in something of a quandry. It defines Nonzas as
non-stanzas, but since there's actually no definition of a stanza, so the
definition isn't defining much.

So what I'd like to see is that this document actually defines three terms,
not just one:

1) Stanza. I think we understand what this means. (We may disagree over
whether entities could add to the existing set, mind).

2) Nonza. I really hate the term, actually, even Non-Stanza or Unstanza
would be better, but this is a matter of taste rather than anything more.

3) Some convenient term of art for first child elements of the stream - ie,
the collective term for both Stanzas and Nonzas.

It might help to go further, and make this a glossary of the terms of art
we use, either providing canonical definitions or pointing to those defined
elsewhere.

Dave.

Re: [Standards] Proposed XMPP Extension: Unique and stable message IDs

[Dave Cridland]

I'm in broad agreement with what Kurt writes below.

I think the only point where we differ is that the does MUC issue new ids
question is really one we could answer now (and if not directly answer,
certainly fix).

I would also add that using the stanza's id and from attributes, plus a
(possibly server-provided) public tracking identifier for the stream,
should be unique - and in at least most cases where we care we can mandate
it.


On 4 June 2015 at 11:56, Kurt Zeilenga kurt.zeile...@isode.com wrote:

 It’s not clear to me that the problems that this extensions proposes to
 address can be addressed through use an extension to XMPP.  Extensions
 ought to be truly optional.  This ProtoXEP appears to be making mandates
 which are more appropriate made, if the community were to support them
 being made, in a revision of the XMPP base specification.

 For instance, the ProtoXEP not only says XMPP entities, which are
 routing stanzas, MUST NOT strip the message-id element from message
 stanzas” but seems to be rely on all servers adhering to this MUST NOT.
 That’s never going to be case… certainly not for implementations not
 purporting to implement this extension… and likely not for some
 implementations which might purport to implement this extension.   This
 spec needs to consider and discuss what happens in face of elements it
 suggests be added are stripped by another entity.

 I have a big problem with one ID to rule them all… and a bigger problem
 with the last ID being that ID (the overrride requirement).   To the extent
 IDs are needed, they need to “stable”.  This means they cannot be
 overridden.

 For operational and security reasons, it unwise for one entity to rely on
 IDs for services it provides (such as MAM) provide by some other entity.
 To the extent IDs are needed, we need per-entity IDs… possibly even
 per-enitty handling IDs (that is, when an IM handles a stanza for the
 second time (such as after being handled by an MUC service, it might need
 to separately ID the stanza).  This because stanza content can and will
 change as its handled by other entities.

 It’s not clear to me how this id provided by this extension would or could
 be used in message type=error stanzas.  It’s not clear to me why this
 extension proposes a message/ only solution, when it seems likely that
 stanza id= problems are not necessarily specific to message stanzas.

 It seems that there’s many security risks here associated with ID forgery,
 replay, etc., but I’m not sure what, if any, mitigation is needed.

 I suggest instead an element allowing entities to provide IDs in stanzas
 they originate or handle.

 stanza-id xmlns=‘…’ id=‘ID’ provider=“JID”/

 where ID is some opaque ID and JID is the providers JID.  Servers which
 need to provide different IDs in different contexts can use different JIDs.
  (or possibly better to allow a context attribute or something).

 I’m not convinced having an extension providing an ID (whether by the
 ProtoXEP suggestion or mine or other) reliably solves any problem I’m faced
 with.

 For the MUC use case, I rather we solve this as part of the MUC2 effort…

 For the MAM case, to the extent what it offers in the current Experimental
 XEP is not sufficient, I suggest MAM XEP be modified to provide for
 reliable identification of archived content.

 — Kurt

Re: [Standards] XEP-0198 minor enhancement

[Dave Cridland]

On 3 June 2015 at 00:48, John Williams (johnwi3) john...@cisco.com wrote:

 Thanks for the clarification.
 Hum,.. not sure how useful this is, since a lot of stanzas are of little
 long term interest (eg: chatstates), but as you describe it seems pretty
 harmless.


So as things stand, if a TCP virtual circuit is lost (due to, for example,
wandering out of signal), then the choices are:

a) Drop the session (the only option without XEP-0198).
b) Keep the session live (with XEP-0198).

If a server keeps the session live, it's got to keep the state (things like
current presence broadcast, directed presence, and so on). In addition,
other users will see the session as live, and while PSA might help indicate
this by annotating the presence, it's still a bit weird. Fine for handover
periods, but not so good across a half-hour underground train journey. It's
worse if the client never resumes, of course.

So servers in effect have to timeout such zombie sessions, and it needs to
happen within a few minutes before the UX issues pile up.

Whether a session is dropped immediately or later, a server can essentially
redeliver the outstanding stanzas; risking duplication.

On the other hand, when the session is dropped, stanzas that are in
flight from the client are lost. Many of these may well be unimportant in
a non-resumption case, but it's useful for a client to know if that message
saying I'm just jumping on the train, be there in 30 actually got as far
as the server.

What this minor addition does is allow the server to tell a client, That
message got through, but I don't have the rest of your session state -
you'll have to start a new one. In principle it could also figure out
which of the pending offline messages the client already has and discard
them, too. The cost for this is storing one server-chosen string, plus one
or two integers - that volume of data can be persisted fairly cheaply, and
possibly even offline.

Think of it as a failure with benefits.

Dave.

Re: [Standards] XEP-0198 minor enhancement

[Dave Cridland]

On 31 May 2015 at 04:00, Kurt Zeilenga kurt.zeile...@isode.com wrote:

 Why not consider the new feature an extension to the extension… and hence
 something which doesn’t require a bump of the extension being extended?


Yes, that's another option.

It possibly means using a namespaced attribute in XMPP; not a problem, but
we've historically not done this. So the resultant protocol would look
something like:

failed xmlns='urn:sm:3' old:h='47' xmlns:old='urn:sm:partial-failure'/

Adding a new attribute to the schema, such that it's not namespaced, is
more or less what I propose by not having a version bump.

failed xmlns='urn:sm:3' h='47'/

Or else the version bump:

failed xmlns='urn:sm:4' h='47'/

I suppose the real difference is if we feel the latter forms require
negotiation; in which case the first and last forms are essentially
equivalent, with the latter form being more streamlined (but breaking
compatibility on Draft).

Dave.

Re: [Standards] XEP-0198 minor enhancement

[Dave Cridland]

On 30 May 2015 at 08:33, Georg Lukas ge...@op-co.de wrote:

 * Steffen Larsen zoo...@gmail.com [2015-05-30 08:37]:
  No, I would go for a version bump, because it could break some clients.

 A version bump, on the other hand, would break all clients. Some clients
 haven't yet implemented the sm:2 to sm:3 bump, and implementing
 different versions of the protocol in parallel is not always trivial.


In fairness, a version bump is only problematic because of inertia and
lethargy, not because of any real difficulty, especially where the two
versions are identical in practice (as with sm:2 and sm:3). It does
introduce a delay in implementation, but then, clients supporting sm:3
wouldn't be supporting sm:3+h anyway. The question is really whether we
want servers to have to support sm:2, sm:3, and a new sm:4 all of which are
virtually identical.


 +1 for the new feature.
 -1 for the version bump.


FTR, I would be +1 on the feature obviously, but I'm ambivalent to the
version bump. I'd simply like to have the discussion so that Council can
advise the Registrar properly.


 Georg
 --
 || http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
 || gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
 || Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
 ++ IRCnet OFTC OPN ||_||

[Standards] XEP-0198 minor enhancement

[Dave Cridland]

What if, on a resumption failure, a server could include the 'h' attribute,
to mean I can't actually resume your state, but I did get all the stanzas
up until H.

I think this allows servers to hold onto this small amount of state for
considerably longer than it's desirable to keep a disconnected session
live, and it also makes a halfway house between ack-only and full
resumption possible for other servers.

Thoughts?

Also, do you think we could add this attribute without a version bump?

Dave.

Re: [Standards] Proposed XMPP Extension: REST with XMPP

[Dave Cridland]

On 27 May 2015 at 07:51, Lance Stout lancest...@gmail.com wrote:

 /Puts on Council hat

 I'm -1 on this for now because this really needs some more discussion on
 the list as this duplicates quite a bit.


Likewise; my comments are unanswered.



 Technical nitpicks for proposal as is:

 - The 'jabber:iq:rest' name should not be used. The 'urn:xmpp:xml-rest'
 namespace could be used instead.
 - If the resource / element can only have the child method /, why not
 use resource method=X /, or method name=X path=/foo /?
 - An example showing retrieving the value of a resource would be useful.




 Given that XMPP nodes can represent resource paths, the proposal reduces
 to providing a new call/response mechanism that places the action name in
 an attribute value of a generic element (iqresourcemethod
 name=ACTION //resource/iq) instead of an action-specific namespaced
 IQ child element (iqACTION xmlns='ACTION-NS' //iq).

 Likewise, a new form description schema is provided instead of using
 Dataforms. I do see that there are some special types introduced, but those
 few special cases could be added as an extension to Dataforms instead of a
 full replacement.

 A discovery method is introduced for finding methods that a resource
 supports, but that is already provided by Disco#info features. Of course,
 Disco does not itself provide parameter definitions, but we traditionally
 do that by using an IQ-GET to retrieve an empty data form, followed by an
 IQ-SET to apply the data form.


 If the goal is to provide easy mappings for CRUD behaviour, then consider
 this straw man:



(XEP-0050 straw-man also added)



 Let Resource be represented by a node named /the/resource.


It's not totally clear what these resources represent, but I'm going to
push back very hard on introducing a path-like semantic.



 To find methods supported by the Resource:

 iq type='get'query xmlns='http://jabber.org/protocol/disco#info'
 node='/the/resource' //iq
 iq type='result'
   query xmlns='http://jabber.org/protocol/disco#info'
 node='/the/resource'
 ...
 feature var=urn:example:xmpp:rest:get /
 feature var=urn:example:xmpp:rest:put /
 feature var=urn:example:xmpp:rest:post /
 feature var=urn:example:xmpp:rest:delete /
 ...
   /query
 /iq


I'm thinking that well-known command names would work just as well.

An interesting point here is that XEP-0050 operates at the Jid level, and
not the Node level - this is problematic with its potential operation with
PubSub as well, so that would be a problem worth solving.



 Discovering parameters of the post method for the Resource:

 iq type='get'post xmlns='urn:example:xmpp:rest' node='/the/resource'
 //iq
 iq type='result'
   post xmlns='urn:example:xmpp:rest' node='/the/resource'
 x xmlns='jabber:x:data'.../x
   /post
 /iq


 Performing a post to the Resource:
 iq type='set'
   post xmlns='urn:example:xmpp:rest' node='/the/resource'
 x xmlns='jabber:x:data'.../x
   /post
 /iq
 iq type='result'.../iq



The above two are identical to Ad-Hoc.



 Such an approach would still need refining, but it would fit in better
 with existing XEPs without creating a parallel track of extensions for new
 method types.


Another approach might be to allow the definition of XEP-0050 command
side-effects to be published... That would allow REST-like semantics to be
built, but also allow multiple create commands, etc, to be made -
eliminating the somewhat clunky REST API semantics of having to have the
method name as part of the payload of a super method. Much as it amuses
me to have an object inheritance hierarchy of polymorphic messages, it's
pretty ugly.

Knowing, on the other hand, that a particular XEP-0050 command is
idempotent, or will change a node, or will create one, and so on, seems
useful.

Dave.

Re: [Standards] Proposed XMPP Extension: REST with XMPP

[Dave Cridland]

On 11 May 2015 at 19:21, XMPP Extensions Editor edi...@xmpp.org wrote:

 Title: REST with XMPP


How is this materially different to XEP-0050?

The reason I ask is because my initial reaction was that the specification
essentially reinvents XEP-0004, but when I considered how it looked once
that change had been made, you then notice that resources are what XEP-0050
calls nodes, and the net result is that this specification becomes XEP-0050
restricted to a single-step form.

Assuming that's fair comment, then I'd be moved to reject this as a
duplication of existing, well-deployed, work - however I'd welcome
clarifications from the author.

Dave.

[Standards] Fwd: Veto against namespaces protoXEP

[Dave Cridland]

FYI.

I'll discuss this with the protoXEP author; I suspect he'll be quite
understanding.

Dave.

-- Forwarded message --
From: Dave Cridland d...@cridland.net
Date: 22 April 2015 at 17:42
Subject: Veto against namespaces protoXEP
To: XMPP Council coun...@xmpp.org


There is some possibility that XEP-0001 might be interpreted such that my
protoXEP would go through by default; for the avoidance of doubt I'm
therefore placing a veto on this until (at least) the next Council meeting.

Dave.

Re: [Standards] Nonzas: What are they and do we need them?

[Dave Cridland]

On 20 April 2015 at 18:40, Philipp Hancke fi...@goodadvice.pages.de wrote:

 Am 20.04.2015 um 06:27 schrieb Florian Schmaus:

 In order to make the following easier, I'd first like to define the term
 Nonza:

 A Nonza is every top level XMPP stream element which is not a Stanza.
 (see also [1]).


 http://geekplace.eu/xeps/xep-nonza/xep-nonza.html#rules

 db:result/ and db:verify/ violate those rules. But they're legacy
 which we can't fix anyway.


Yeah, but I think the rules are wrong.

The risk of saying Nonzas have no to/from is that the converse doesn't
apply - there are only three stanzas ever, and you'd never want to route
anything else.

Dave.

Re: [Standards] Encrypted Storage (Was: off-server archives with MAM)

[Dave Cridland]

On 18 Apr 2015 11:34, Thijs Alkemade th...@xnyhps.nl wrote:


  On 18 apr. 2015, at 11:59, Thijs Alkemade th...@xnyhps.nl wrote:
 
 
  On 18 apr. 2015, at 11:42, Georg Lukas ge...@op-co.de wrote:
 
  1. When a user logs in for the first time, an asymmetric keypair is
  created (I was thinking of Curve25519, where key creation is almost
  free). The private key is encrypted with a key derived from the user
  password / SASL state (https://www.zash.se/mod_storage_encfs.lua.html
is
  a PoC for that).
 
  2. All data that is stored for the user is encrypted with their public
  key and appended to their container.
 
  What do you mean with “SASL state”? All of the data the server has
after a
  SCRAM-SHA-1 exchange is either a) stored on the server, b) session
specific.
  You can’t derive a key from that which the server could not derive on
its own.

 Zash pointed out to me that I was wrong. The ClientKey does not change
between
 sessions, is not stored on the server (during normal operation) and the
server
 does compute it during login. It could be used to derive a key.


However it's pretty weak for such usage, and would tie clients into a
specific SASL mechanism; I don't see an upgrade path should that mechanism
develop an exploit.

I think you'd be better off going along with Peter's suggestion that trying
to store encrypted archives on the server.


 Thijs

Re: [Standards] off-server archives with MAM

[Dave Cridland]

On 18 Apr 2015 03:58, Peter Saint-Andre - yet pe...@andyet.net wrote:
 Ideally, to me, my message archive would be stored on a trusted device
that is under my control (say, a limited-access storage medium that I keep
in my house). This device could authenticate to my account and advertise
its existence to my other resources. Using Carbons (XEP-0280) it could
obtain copies of all the messages I send and receive. When one of my
messaging devices wants to retrieve message history, it would do so by
querying this trusted storage device, not the server (which only handles
messages for purposes of realtime delivery).

 I would really like to see the wording in XEP-0313 adjusted to take this
scenario into account. I am happy to propose text.

Between XEP-0355 and carbons, I think you're covered already, at first
thought.

Dave.

Re: [Standards] Marking up messages with metadata and XEP-0071

[Dave Cridland]

On 9 April 2015 at 08:27, Kevin Smith kevin.sm...@isode.com wrote:

 1) I’m not sure that adding data-* to XEP-0071 would aid interoperability,
 as the use of the data-* needs to be understood by both ends (e.g. in your
 case it isn’t enough for xep71 to just say ‘you can use data-*’, because a
 third-party client receiving your data-* markup wouldn’t understand what to
 do with it).


Agreed.



 2) As you’re controlling the clients at both end, I can’t immediately see
 any problem with just shipping data-* attributes inside the generated
 XHTML, although -71 says not to. The importance of following the specs is
 to ensure you can interop fully; if you’re controlling the clients at both
 ends and need special logic to do so you can add non-standardised markup
 reasonably safely.


Adding a (private) disco feature and checking for it in caps would be
better. Then, by all means, add custom attributes and markup.

Not doing discovery/negotiation would mean a potential clash with clients
you don't control; it also allows you to have multiple versions of your own
clients deployed safely.

As a rule of thumb, everything that XMPP does to allow interop between
entirely different codebases also allows stability with multiple versions
in a closed environment - you're not *really* controlling the clients
totally at each end except in vanishingly rare, and very small-scale, cases.


 I’m not sure if others will agree or disagree with me here.

 /K

[Standards] ProtoXEP - Namespaces in XMPP

[Dave Cridland]

Folks,

I found myself in error about our namespaces recently, and noticed another
misconception floating about. While looking for a useful explanation of how
and why our slightly weird-looking namespaces work, I found this:

http://mail.jabber.org/pipermail/standards/2011-May/024561.html

So I'd somehow written one about 4 years ago, and failed to submit it
properly for some reason (it went to standards@, but nowhere else). It has
a co-authorship of Peter; I've no idea whether he helped write it or if I
just lifted some of his text.

So, copying the editors, I hereby [re-]submit the XEP, and shamefully can't
quite recall if all the IPR is mine or if some of it might be Peter's.

Dave.
?xml version='1.0' encoding='UTF-8'?
!DOCTYPE xep SYSTEM 'xep.dtd' [
  !ENTITY % ents SYSTEM 'xep.ent'
%ents;
]
?xml-stylesheet type='text/xsl' href='xep.xsl'?
xep
header
  titleNamespace Versioning in urn:xmpp/title
  abstractThis document describes the common practise of namespace versioning for the urn:xmpp URN namespace, and how this affects (and does not affect) the protocols which have such namespaces./abstract
  LEGALNOTICE;
  number/number
  statusExperimental/status
  typeInformational/type
  sigStandards/sig
  supersedesNone/supersedes
  supersededbyNone/supersededby
  shortnamenamespace/shortname
  dcridland;
  stpeter;
  revision
version0.1/version
date2011-05-19/date
initialsdc/initials
remarkpAfter the third person in a single month thought that namespace versioning is a bad idea, wrote this background informational XEP to explain the rationale behind XEP-0053§4./p/remark
  /revision
  revision
version0.2/version
date2015-04-07/date
initialsdc/initials
remarkpNoticed two conversations in two weeks. Must be time to reify this one. Added two new misconceptions; the author vs registrar one was mine./p/remark
  /revision
/header

section1 topic='Introduction' anchor='intro'
  pOver the years that the XMPP registrar has been issuing namespaces for protocols, a number of namespace formats and issuance strategies have been attempted. As of the time of writing, the current one, defined in XEP-0053 Section 4, has proven successful, but many newcomers to the XSF are surprised to see version numbers in namespaces and have often misconstrued these to be in violation of XML namespace handling./p
  pThis document attempts to provide rationale behind why these were adopted, why they are successful, and why they are not in violation of the XML namespace rules./p
/section1

section1 topic='Rationale' anchor='rationale'
  section2 topic='Before The Dawn Of Time' anchor='before'
pIn the beginning, namespaces were simply minted, but relatively early on, it was observed that experimental protocols were often deployed, leading to pollution and devaluation of the namespace. If two incompatible variants of a protocol used the same namespace, then this could easily lead to a situation whereby Draft or Final stage protocols had difficulty deploying because they'd fail to interoperate, and often choke, when faced with older variants of the protocol./p
pIn order to combat this, during the switchover to the urn:xmpp URN namespace, URNs of the form urn:xmpp:tmp:foo were used for Experimental stage protocols. Only on their advancement to Draft would the tmp be removed, meaning that non-tmp forms were sure to be the Draft variant./p
  /section2
  section2 topic='Namespace Versioning' anchor='versioning'
pAlthough this prevented Draft/Final protocol implementations from being choked by Experimental protocols, and therefore retained the value of the Draft/Final namespace, it left Experimental protocols with weak interoperability. In particular, since a namespace was certain to change at Draft, implementors were discouraged from implementing Experimental protocols to some extent, and it was observed that the benefit of early implementation experience was harmed./p
pNamespace versioning was therefore introduced. Each new XEP is, in effect, allocated an arc or tree of the URN namespace, and any time the protocol is changed such that it would fail to interoperate with older versions of the protocol, a new namespace from this arc is minted. To avoid reuse, limit the creativity needed, and provide some indication to implementors of which variant is newer, numbers are used./p
pHowever, each new namespace is indeed an entirely new namespace, and not only is no assertion of compatibility made, but it is only when there is either known (or high risk of) incompatibility that a new namespace is minted, so in effect there is an assertion made that the two variants are incompatible. This assertion is, of course, precisely in conformance with the definition (and even spirit) of XML namespaces./p
  /section2
/section1

section1 topic='Misconceptions' anchor='protocol'
  section2 topic=Namespaces can't be versioned!
pWith alarming frequency, someone new to the process usually suggests that the XSF has 

Re: [Standards] Advancing XEP-0280 Carbons

[Dave Cridland]

On 1 April 2015 at 18:33, Matthew Wild mwi...@gmail.com wrote:

 On 1 April 2015 at 17:37, Dave Cridland d...@cridland.net wrote:

 Folks,

 Matthew Miller and Joe Hildebrand's Carbons XEP has been unchanged for 18
 months, and represents a useful and well-deployed protocol, implemented in
 most (if not all) of the mainstream servers.

 Mobile and Desktop clients alike appear to implement this widely.

 I appreciate that the last Summit raised suggestions that it needed to do
 more, but it is not clear to me that the more cannot be phrased as a new
 XEP, and moreover that breaking compatibility given the deployment status
 is warranted.

 It is also not clear to me what, exactly, the more consists of. I have
 heard:

  - Reflection of messages to the source.


 I think this only really makes sense in XEP-0280.


...
feature var='urn:xmpp:carbons:2'/
feature var='urn:xmpp:carbons:advanced:0'/
...

iq type='set'
  enable xmlns='urn:xmpp:carbons:2'
adv:xmlns='urn:xmpp:carbons:advanced:0'
adv:reflection/




  - Addition of MAM identifiers.


 This can (and should) be a separate XEP.



adv:archive-id/


  - Other types beyond 'chat'.


 Not sure about this.


adv:msgtype type='groupchat'/
adv:msgtype type='normal'/
adv:msgtype type='chat'/
/enable
/iq


 There is one more item, switching from private/ to XEP-0334 Message
 Processing Hints.


Does anyone use the private element? I'm wondering how practical it is to
deprecate it.


 Regards,
 Matthew

[Standards] Advancing XEP-0280 Carbons

[Dave Cridland]

Folks,

Matthew Miller and Joe Hildebrand's Carbons XEP has been unchanged for 18
months, and represents a useful and well-deployed protocol, implemented in
most (if not all) of the mainstream servers.

Mobile and Desktop clients alike appear to implement this widely.

I appreciate that the last Summit raised suggestions that it needed to do
more, but it is not clear to me that the more cannot be phrased as a new
XEP, and moreover that breaking compatibility given the deployment status
is warranted.

It is also not clear to me what, exactly, the more consists of. I have
heard:

 - Reflection of messages to the source.
 - Addition of MAM identifiers.
 - Other types beyond 'chat'.

Therefore I would like to suggest that this specification be advanced to
match its de-facto state of Draft.

Dave.

[Standards] Fwd: XMPP Council Minutes, 20150325T1600Z

[Dave Cridland]

FYI.

-- Forwarded message --
From: Dave Cridland d...@cridland.net
Date: 25 March 2015 at 16:20
Subject: XMPP Council Minutes, 20150325T1600Z
To: XMPP Council coun...@xmpp.org


Present: Dave Cridland (Acting Chair), Philipp 'Fippo' Hancke, Lance Stout,
Matthew Wild
Apologies: Kevin Smith (Chair)

0. Agenda Bashing

  1. Actions
  2. AOB
  3. Time and Date of next

1. Actions

 - Dave has action to write a XEP Life Cycle blog post; he's sent this to
the Council list. Fippo has reviewed these, Lance said in the meeting it
looks good.

2. AOB

 - Fippo reminded Dave that there is a new version of the DNA I-D to review
within the IETF's XMPP Working Group.
 - Fippo also reminded Council that Kev asked all members to sign up as
GSoC Mentors.

3. Time and Date of Next

** TIMEZONE SHIFT **

Since the timezone changes for all EU countries this weekend, the next
meeting will move time slot in UTC (and US local times), but stay the same
for EU residents.

Therefore the next meeting will be 20150401T1500Z (this is either an hour
earlier or the same time depending on your timezone).

** TIMEZONE SHIFT **

4. Ite, Meeting Est

Re: [Standards] Service Discovery + dependent features

[Dave Cridland]

On 16 March 2015 at 23:11, Lance Stout lancest...@gmail.com wrote:

 This one may need to go to Peter for a philosophy question: what is to be
 done when an implementation of feature Y MUST support X as a fallback, but
 the user chooses to disable X.


MTI != MTD

Mandatory To Implement does not mean Mandatory To Deploy - so if Y requires
X as a fallback (or a server MUST implement SCRAM, or whatever) this
doesn't imply that it must be deployed and activated at all times.

Dave.

Re: [Standards] XEP-65 erratum in § 9.4

[Dave Cridland]

On 3 March 2015 at 17:54, Florian Schmaus f...@geekplace.eu wrote:

 Hi everyone,

 I think I found an error in XEP-65:

 Section 9.4 activate/ Element states that

 This element is always empty and has no defined attributes.

 when it should be

 This element's XML character data contains always the JID of the target
 and has no defined attributes.

 because 'activate/' is not an empty element.

 The Schema is correct (as far as I can tell).


This seems like a valid erratum to me - something to fix prior to Final.

[Standards] Fwd: [kitten] AD sponsoring draft-hansen-scram-sha256

[Dave Cridland]

Since XMPP folks are particularly interested in scram, I'd like to draw
attention to this work.

Note the venue for comments!
-- Forwarded message --
From: Stephen Farrell stephen.farr...@cs.tcd.ie
Date: 12 Feb 2015 01:25
Subject: [kitten] AD sponsoring draft-hansen-scram-sha256
To: s...@ietf.org s...@ietf.org, kit...@ietf.org kit...@ietf.org, 
http-a...@ietf.org http-a...@ietf.org
Cc:


Hiya,

I've been asked to AD sponsor draft-hansen-scram-sha256 [1] as it's
needed for some work in http-auth but doesn't quite fit with any
current WG. I plan to start an IETF LC for that shortly, but please
do let me know if there are any issues.

This was previously discussed on the kitten WG list, so (with
the WG chairs' permission) I'd ask that you send any comments
there if you've any before I start the IETF LC. (Reply-to is
set to the kitten WG list.)

Thanks,
S.

[1] https://tools.ietf.org/html/draft-hansen-scram-sha256

___
Kitten mailing list
kit...@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

Re: [Standards] Using XMPP In A Mobile Environment

[Dave Cridland]

I don't have anything useful to add here, really, but please can you guys
capture your knowledge into XEP-0286?​ It's clearly behind the times, as
it's 5 years old, but if we could capture some more modern thinking it
might become useful again.

Thanks,

Dave.

[Standards] MUC 2

[Dave Cridland]

At the summit, a bunch of us decided to have a serious effort at a redesign
of multi user chat, to address shortcomings and emerging use cases.

The overall model was a service domain which exposed, at bare jid level, a
set of rooms, which acted more or less as pubsub services, with subsidiary
nodes exposing information such as messages, occupants, and so on.

I think this general concept would work well for both traditional chatrooms
and the different demands of things like buddy cloud. Unifying MUC and
buddy cloud is a personal goal, but I think it's a useful yardstick to see
if we're capturing the use cases right.

However, this model doesn't address three other use cases I feel are
important. Firstly, there's XEP-0277, which I suspect fits in the same
concept. Secondly, multi party chat.

I'm using the term multi party chat to mean ephemeral conversations between
more than two people. Currently these are handled, badly, by hosting the
conversation on an existing third party chatroom service. This means that
one participant locates a chatroom service and invites the other; meaning
the first party needs to use a server that has a chatroom service, and the
second party needs to be willing to use it.

I suspect that both of these use cases are addressed, at least partly, by
being able to host chatrooms on the pep service of the user. This means,
possibly, making the model one of a single pubsub mode with multiple
strands of publication, which I've previously called facets.

The third missing use case is that I'd like to have room level federation
in from the outset. It's proven really hard to retro fit, and it's work
usefully in the multi party chat scenario, too, as well as several other
use cases.

Dave.

Re: [Standards] MUC 2

[Dave Cridland]

On 12 Feb 2015 14:00, Christian Schudt christian.sch...@gmx.de wrote:

 Dave, maybe could you (or somebody else) elaborate on the shortcomings
and the different demands of things like buddycloud you have discussed
for those who didn't attend the summit.

 Also what's so bad about multiple parties chatting via a third party chat
service (your 2nd use case)?


In the case of a private conversation between three people, it feels wrung
to introduce a fourth.

 For me one shortcoming of XEP-0045 is that there's no good concept for
the offline case of an occupant (member).
 E.g. you create a members-only room with three friends. They exchange
messages, while you are one week offline. You then enter the room and only
receive messages according to your discussion history request while
entering, let's say the last 25 messages. But missed most of the messages
your friends have exchanged, while you were absent.
 That's of course unfortunate, because you would expect to not miss any
conversations.


Right, and this was discussed in detail at the summit. Presence and MUC are
going to be split. MAM is part of the solution here, as I'd the account
model based pubsub.

 It's like if my mail client would only request the last few mails from
this mailing list, when I start it and any older messages could only be
read in an archive via a browser, if available. (well, maybe this could be
solved with pubsub).

 Although I don't know the real shortcomings and demands you discussed
about, I imagine doing MUC with PubSub adds extra complexity. XEP-0045 is
already complex, XEP-0060 is even more complex and maintaining two very
different MUC approaches (from a technical point of view) is a burden for
any developer, while end users probably won't see many differences (e.g.
they don't care if their MUC is hosted by an traditional chat service or by
a PEP service).


Well, pubsub is actually simpler than MUC, since MUC is essentially an all
or nothing, whereas pubsub is a tiny core with lots of optional parts.

Secondly, I think that we do want to maintain basic protocol compatibility
with old MUC, so clients joining via presence we probably want to support,
and clients sending messages would be unchanged.

I'm reasonably confident that MUC 2 should be okay to implement on both
server and client. Luckily, clients won't have to change much, and we can
almost certainly keep full protocol compatibility.

 Isn't it possible to eliminate the shortcomings of XEP-0045 by just
evolving it?

 Christian

Re: [Standards] [Council] component-s2s

[Dave Cridland]

On 4 February 2015 at 21:29, Kevin Smith kevin.sm...@isode.com wrote:

  I’m -1 on the component-s2s spec. I’ve been backwards and forwards a
 number of times on whether to use the veto or not, and I’m using it in the
 lightest sense.


I'll elide the flame war if that's OK? I appreciate it's traditional, but...

Anyway, a link to the inbox XEP for those that haven't read it yet:

http://xmpp.org/extensions/inbox/s2s-components.html


 I think we should have a wider discussion before we publish an experiment
 to replace the existing historical and ST component XEPs with this. If
 discussion leads to a generally positive results, that’s all I’ll need to
 accept it.


Right, it's an interesting case - it's clearly duplicating existing XEPs,
which is generally held as an exemplar reason to veto a XEP. The existence
of '225 indicates there are issues with '114, but the continued use of '114
over '225 suggests the advantages of '225 are insufficient.


 My current thoughts are that this is re-using S2S (good) but in such a way
 as to require special-casing anyway (reducing the utility of reuse), and
 that requiring the TLS auth and bidi makes the potential attack surface
 here a little higher than I’d like (bidi hasn’t had great success of
 successful implementations).


I suspect that when I sketched out the idea, the special cases involved
weren't really clear in my head.

For one thing, I chose to signal the component-ness of the session using a
special 'to' domain. My gut feeling is that it's wrong, actually, but I
can't think of anything better.

For another, I essentially suggest that authentication and authorization of
the stream is special-cased. This is problematic, because I only really
specified (and therefore thought properly about) the initial case, and
sketched over the piggybacking, and didn't consider the host server's
authentication to the component at all.

Now I think the reuse of TLS here is fine, and I don't think there's an
alternative to BiDi - and I'd love to see that better used anyway.

However, if we don't think that there are going to be architecturally clean
solutions to the authentication/authorization, then this design is broken
and cannot be fixed, and good on you for calling me on it.

Dave.

Re: [Standards] MAM and Pubsub

[Dave Cridland]

On 3 Feb 2015 11:58, Goffi go...@goffi.org wrote:

 Having a node attribute is defined in 313 as specifying you want to
 search a pubsub archive instead of another type of archive.  I don't see
 the confusion.


 It's explained in XEP-0313, but I think it's a bad idea to use common
terminology to associate MAM with an other XEP, without namespace.

 If tomorrow a XEP uses this same terminology of node, it will starts to
be confusing.



 No, you're not.  Consider you have a node to which someone has published
 with the same item id repeatably, e.g. id='myitem'.  MAM will allow you
 to recover previous versions of that particular item, whereas 60 does
not.


 OK, but that doesn't prevent of showing pubsub namespace somewhere. Or at
least something less generic than node



 Letting this one settle in for a bit.  Delegation is a tough problem to
 do properly without breaking things, especially if the namespace
 delegated has relations to other specs.


 We can work around this in namespace delegation by adding an attribute
check in addition to namespace check, that would be better than sending
back the traffic to the server, even if it complicate the XEP. I would
still be more happy with an other attribute name to link MAM and PubSub.


I think this would affect disco, for example, as well?


 Goffi

Re: [Standards] OTR

[Dave Cridland]

On 3 Feb 2015 09:37, Florian Schmaus f...@geekplace.eu wrote:

 On 03.02.2015 10:04, Dave Cridland wrote:
  On 2 Feb 2015 18:49, Peter Saint-Andre - yet pe...@andyet.net
  mailto:pe...@andyet.net wrote:
  On 2/2/15 5:22 AM, Hund, Johannes wrote:
  Since it was undisclosed that even the NSA seems to have problems
  breaking into OTR [1], it gained a lot of attention it seems and thus
  does a good deal in supporting XMPP as a choice for applications with
  high requirements in privacy and security as its often the case for
  IoT applications.
 
 
  OTR secures only the character data of the XMPP body/ element within
  message stanzas. That's appropriate for IM but doesn't really help with
  things like IoT (which often use extended namespaces).
 
 
  Exactly, and this is the kind of thing I was hoping that documenting the
  current OTR usage in XMPP would show clearly.

 Isn't documenting the current OTR usage in XMPP simply

 message …
  body
 … put OTR stuff here …
  /body
 /message


That's certainly the core of it, though the devil is usually in the
details. I suspect there's all sorts of weird stuff with multiple
resources, for instance, and html, and...

 where OTR stuff is defined at
 https://otr.cypherpunks.ca/Protocol-v2-3.1.0.html (I think most
 implementations use OTR v2) and
 https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html

 So OTR is IM protocol-agnostic. You can see how OTR tries to negotiate
 using whitespaces at the end of String within the /body element at
 https://github.com/python-otr/gajim-otr/issues/9#issue-40676864

 I'm also not sure if, not only because it's IM protocol-agnostic, OTR
 would be a good fit for IoT. Some research in this direction would sure
 be interesting.

 - Florian


It'd be nice to have a document which held our consensus view on what OTR
in XMPP protects against, and what it fails to protect against, and how one
implements it. Currently it's one of those things that everybody knows,
and I'm willing to admit that I am not everybody.

Dave.

Re: [Standards] Proposed XMPP Extension: S2S Components

[Dave Cridland]

On 21 January 2015 at 07:29, Lance Stout lancest...@gmail.com wrote:

 I recall Ralph once noted that many of the major XEPs were each the third
 try at the concepts. So here's hoping for components v3 :)


We can but hope. '114 just about does the job, '225 hasn't caught
anyone's imagination it seems. I believe this is functionally identical to
'225, but aligns with the internal models of servers more readily. In
particular, I think I could implement this easily enough in Openfire,
Prosody, and (if I had access) M-Link. On the component library side, I
have less experience, and would welcome opinion.



 The motivation for using __xmpp-component as a domain name is unclear to
 me, but I'm probably lacking the imagination at the moment to create the
 enlightening example. (It also makes me want to reserve an actual domain
 name for this use case like how we use bob.xmpp.org in XEP-0231, but that
 is probably a bad idea.)



The problem here is that S2S streams mandate a to attribute; so I wanted
something there. In addition, I wanted a simple early signal that this was
intended as a subordinate component, rather than an inbound session. Since
the host server answers to the component's domain, most other cases would
be indistinguishable from loop errors.

It's a hack, though, and you're quite right for zeroing in on it. I'd
forgotten about bob.xmpp.org - I'd have probably gone that route (I went
for a special label form instead, of course).



 Can a component establish S2S sessions with multiple host servers? This
 might seem odd in the context of most existing component implementations,
 but the proposed XEP is essentially allowing an XMPP server to act as a
 connection manager for another server using S2S. So I can easily imagine
 the component to be a true XMPP service (that could typically handle
 multiple S2S sessions), and the host servers acting as connection
 managers. Maybe an implementation note?


You could certainly use this to bridge two sets of domains, or use it as
a special-case link between two ordinary servers, too. But I don't think
it's special in this; the only thing preventing '114 from acting this way
is that it's restricted to a single domain, and '225 will do this now.



 Can a component create or accept S2S sessions to non-host servers? I would
 expect the answer to be no (what's the point of having the host server
 then?), but it isn't called out.


I don't see why it couldn't, and I certainly don't see why it would need to
be prevented.




 Overall, I like the idea. I also would be very interested in any attempts
 (or past ones) to define things in reverse: connection managers that can
 sit in front of any traditional XMPP server, and thus any S2S-style
 component, implementation.


I think once you consider component connections as simply an alternate
form of S2S, then the obvious case is Isode's M-Link Edge product which
does this for a living.

Actually this relates to the thing that interests me most about
re-interpreting components as a server-to-server case - I think some really
interesting use-cases become much more immediately obvious and
understandable. We've tended to fall into a sort of cognitive trap of
seeing components as special clients bound to a particular host server,
whereas I think it's quite helpful to consider them as special servers
instead. For one thing, any sentence beginning you could have a component
that more easily becomes you could have a remote service that.




 — Lance

Re: [Standards] Comments on Privilege Component(0.0.4)

[Dave Cridland]

On 21 January 2015 at 14:55, Kevin Smith kevin.sm...@isode.com wrote:

 My last point, though, is that this doesn’t allow a component to implement
 presence-based pubsub stuff (not even the limited PEP profile), which it
 sets out to do, as it doesn’t have any way of delegating the incoming
 publishes, manual subscribes/unsubscribes, configuration etc. to the
 component. This seems significant!


Isn't that handled by XEP-0355, submitted at the same time?

Re: [Standards] Proposed XMPP Extension: S2S Components

[Dave Cridland]

Thank you, Mr Miller!

On 20 January 2015 at 15:51, XMPP Extensions Editor edi...@xmpp.org wrote:

 The XMPP Extensions Editor has received a proposal for a new XEP.

 Title: S2S Components

 Abstract: This document describes a modernized method of connecting
 'components' to a server, expressed as a profile of the existing standard
 server-to-server protocol.

 URL: http://xmpp.org/extensions/inbox/s2s-components.html

 The XMPP Council will decide in the next two weeks whether to accept this
 proposal as an official XEP.

Re: [Standards] XEP or not to XEP

[Dave Cridland]

On 14 January 2015 at 05:57, David Bolack dbol...@missingworldsmedia.com
wrote:


 On Monday, January 12, 2015 03:14 EST, Dave Cridland d...@cridland.net
 wrote:

  In general, proposing a XEP that's rejected because it's a terrible idea
  adds more value than doing something that's a terrible idea without
  discussing it. Even if you choose not to go as far as a formal protoXEP,
  it'll hopefully be useful to all parties.

 Bear in mind, I've never attempted a standards body draft of anything, so
 here's the general ideas.

 We're going to use XMPP for internal coms for a game. As such, users have
 both a global and an instance identity and should be reachable by either
 the global name ( at all times when logged in ) and the active
 instance/character name.  And we intend to use MUC as a channel analog.


So there's the player's login name - jid - and a character name. I
understand what you've written to mean there's only one active character
(though there may be multiple characters).


 With our own clients, this is easy to control, we can enforce the MUC
 Nicknames to the character name, etc, but I've been asked to make sure that
 standard, third party XMPP clients can hook in as well.  This complicates
 things slightly. :)


Well, you can enforce nicknames using standard clients too. Either just
rejecting the join, or responding with a different nickname - the latter
I've not actually seen in production, but in principle it should work. I
suspect the more difficult part would be indicating the currently active
character.


 The best solution I have come up with is:

 Use the resource id to identify the character


Resource ids are opaque; I think trying to ascribe meaning to them is
likely to cause heartache and pain. Aside from anything else, you'll break
multi-device.


 Have the authentication method verify user ( node ) and character (
 resource id ) against the login password
 Have the MUC code force the room nick for the user to the Resouce ID. (
 and I'm dubious we can control that in a third party app )

 But again, I'm not sure if  ( assuming the above is all functionally
 possible ) that a XEP is appropriate.


In order to do this, you've got to control the entire XMPP server; I think
that's going to cost you in the long term. Most servers allow you to have
custom authenticators, but very few allow fine control over the resource
id. Obviously if you use an open-source server as your base, you can do
whatever you like, but I suspect the merge costs will be significant.

Instead, I think you want to stick with a customized MUC component/plugin,
and a custom authenticator (and that only if you *really* need it).

For the current character, you could just do another custom component that
simply tracks the current character selected. You could have an ad-hoc
interface for character selection to support third-party clients, and some
way of querying for the MUC component (unless it just handles that
internally).

I think if you did that, your engineering costs would be reasonably low,
and you'd get multi-device, third-party client support - in particular
mobile.

Dave.

Re: [Standards] XSF Board Minutes 20150112T1600Z

[Dave Cridland]

Also from the XSF Board minutes (sent to XSF Members):

On 12 January 2015 at 16:47, Dave Cridland d...@cridland.net wrote:

 Dave reported that we are (based on previous years) approximately €1000
 short of breaking even


While it's not absolutely essential that we break even with the Summit, and
we don't run it as a fund-raising venture, it's always nice if we can break
even while giving Summit participants a nice meal as well.

I understand that companies sending people is far more important than
sending money, but we really appreciate XSF Dinner sponsors as well. The
money is used to directly fund both the dinner itself, and food over the
Summit, and I think I speak for everyone when saying that attendees
particularly like those companies who cover the food bills. Certainly
there'll be cheers when Laura thanks the XSF Dinner sponsors at the Dinner
itself.

If it's a choice between paying for an extra attendee or sponsoring, please
send that extra person - the XSF won't go bust as a result - but a handful
of sponsors will keep the XSF's cash reserves healthy, put a smile on a lot
of faces, and put your company's name on their lips.

Thanks,

Dave.

Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)

[Dave Cridland]

Noting that this last call is over, I'd personally like to see the
rationale below captured in the document. It really wasn't clear to me, and
I don't think I'm unique here.

This is not intended to be a blocking comment for advancement.
On 16 Dec 2014 21:32, Lance Stout lancest...@gmail.com wrote:

  1. Is this specification needed to fill gaps in the XMPP protocol stack
 or to clarify an existing protocol?

 It removes several sources of ambiguity from XEP-0256, which have been
 discussed on standards@ before (e.g.,
 http://mail.jabber.org/pipermail/standards/2012-October/026887.html)

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

 Yes

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

 I have, in SleekXMPP and stanza.io.

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

 No

  5. Is the specification accurate and clearly written?

 Yes



  XEP-256 allows to announce idle since time, but only when the show
  type is 'away' or 'xa'. It further allows you announce when the user
  went offline before the current session (was last online at).

 That's the crux of the issue. XEP-0256 actually can't distinguish
 between idle  last online in practice, precisely because its
 semantics change depending on the presence's show value (or lack
 thereof).

 Why is that a problem?

 1) We don't have any standard for how auto-changing the show value
should behave. For example, if I set my presence to 'dnd', should
my client change it to 'away' or leave it at 'dnd'? I've seen both
options used by clients; I actually would prefer to keep the 'dnd'
show value because it is more useful for expressing intention.

 2) Client apps tend to try to be helpful and re-use your last sent
presence as the initial presence when you start the app again. So
if I manually set myself to 'xa', when I open the app again I will
typically happen to have an 'xa' initial presence.

 In the end, the *only* entities that can in practice reliably
 distinguish an 'initial presence' from any other presence update, are
 the client itself and the client's server.


 I would say that our experience using XEP-0256 in the field indicates
 that it is only useful for idle time (by ignoring the show value), and
 that the last online use case ought to be removed. Hence the start of
 XEP-0312 Pubsub Since to make the offline time distinct and explicit.


 Because updating XEP-0256 to solve this issue would change the
 existing semantics (for anything that is currently trying to
 distinguish between idle  last online), I think it would be best to
 make a clean break with a new element and namespace.



 - Lance

Re: [Standards] XEP-0163: listing subscriptions

[Dave Cridland]

On 8 January 2015 at 16:28, Edwin Mons j...@edwinm.ik.nu wrote:

  Say I have the following situation:

 1) a client with interest in mood publishes a PEP node
 2) the client will receive said event back from the server

 Would Retrieve Subscriptions list a subscription for that node?  And what
 about Manage Subscriptions, would that list the owner as a subscriber?  I'm
 inclined to say they won't, but 163 is quite vague on that.


When I implemented this, I *think* I decided that it doesn't -
XEP-0060§9.1.1 says the account owner is implicitly subscribed, which to
my eyes suggested that there wasn't a subscription visible. If there were,
it'd raise the question of what happens if an owner tries to remove that
subscription, and so on.

Dave.

Re: [Standards] OTR

[Dave Cridland]

On 29 December 2014 at 17:12, Sam Whited s...@samwhited.com wrote:

 Regardless, I think this is out of the scope of what the OTR document
 would define.


I think it'd be far more useful to define what current OTR usage is, and
what it protects against (and what it doesn't).

Writing what OTR *should* be doing is a whole other document - just as
important, but I'm keener on seeing the first.

Dave.

Re: [Standards] Blocking command and Privacy Lists

[Dave Cridland]

On 22 December 2014 at 01:19, Sam Whited s...@samwhited.com wrote:

 Hi all,

 XEP-0191 (Blocking command) specifies that once a contact is blocked, no
 stanzas are delivered from them to the user:

  Once the user has blocked communications with the contact, the
  user's server MUST NOT deliver any XML stanzas from the contact to
  the user. The block remains in force until the user subsequently
  unblocks commmunications with the contact (i.e., the duration of the
  block is potentially unlimited and applies across sessions).

 However, Gajim (and possibly other clients that use privacy lists) seems
 to block everything but presence information.


Slightly confused by this. XEP-0191 is server-side enforced, so the
behaviour will be applied and controlled by the server, not the client.


 From a user perspective, this seems like the expected behavior (I block
 someone, they can't receive information about my presence or send me
 messages, but I can still see their presence unless they block me).

 Am I interpreting everything correctly, and if so, is this something
 that would be considered for change? I'd like to propose that the line
 from XEP-0191 be rewritten to read something like:

  Once the user has blocked communications with the contact, the
  user's server MUST NOT deliver any XML stanzas from the contact to
  the user except for presence stanzas. ...


This would mean that probes still get sent, which seems inappropriate.

Otherwise we're in the slightly weird situation that we're predicating on
remote servers sending presence without a probe - this is quite possible,
but could lead to some very odd behaviour when this get out of sync. Also,
there's the RFC 3921 optimization; that reduces the presence to just
online/offline in some cases.

Dave.

Re: [Standards] Blocking command and Privacy Lists

[Dave Cridland]

On 22 December 2014 at 13:51, Sam Whited s...@samwhited.com wrote:



 On 12/22/2014 04:19 AM, Dave Cridland wrote:
  Slightly confused by this. XEP-0191 is server-side enforced, so the
  behaviour will be applied and controlled by the server, not the client.

 Gajim uses Privacy lists without the XEP-0191 frontend. Sorry, I was
 unclear there.


Ah, so it's not really doing XEP-0191 at all.


  This would mean that probes still get sent, which seems inappropriate.

 My language probably needs to be tweaked (and updated in several other
 places in the XEP); outgoing probes (from the user to the blocked
 client) should remain the same (dropped so the user appears offline).
 Incoming probes should be handled like they currently are:

 From XEP-0191:
  For presence stanzas (including notifications, subscriptions, and
  probes), the server MUST NOT respond and MUST NOT return an error.

 The server must not respond, but it could still pass notifications on to
 the user.


As Kurt says, the spec is pretty clear - if a contact is blocked via
XEP-0191, then the user neither sends nor receives any stanzas to/from the
contact. I don't think we want to play spec-lawyer games here.


  Otherwise we're in the slightly weird situation that we're predicating on
  remote servers sending presence without a probe - this is quite possible,
  but could lead to some very odd behaviour when this get out of sync.
 Also,
  there's the RFC 3921 optimization; that reduces the presence to just
  online/offline in some cases.

 Good point; I hate to potentially leak information by sending probes to
 the server. I'll have to think about this one.


Also bear in mind that XEP-0191 was designed to be a simple replacement to
XEP-0016, the observation being that with the exception of some extremely
rare cases, everything people actually used XEP-0016 for could be wrapped
up into XEP-0191 and XEP-0186. I don't really want to make this more
complex than it absolutely has to be.

So overall, I'm bound to entirely agree with Kurt's line of reasoning and
recommended resolutions.

Dave.

Re: [Standards] Blocking command and Privacy Lists

[Dave Cridland]

On 22 December 2014 at 14:47, Holger Weiß hol...@zedat.fu-berlin.de wrote:

 * Kurt Zeilenga kurt.zeile...@isode.com [2014-12-22 05:31]:
  I think if anything in XEP 191 needs to change, it's the discussion of
  how one maps XEP 191 onto XEP 4 privacy lists that should change.  It
  should be clearly stated that the blocking entity is required to perform
  the mapping in such a way that all communications with the blocked JID
  are blocked.

 And how should that entity map privacy rules that just block _some_ of
 the communication back to XEP-0191 rules?



XEP-0191 maps to XEP-0016, not the other way around. I think internally,
I'd mark the privacy lists that are really XEP-0191.

Dave.

Re: [Standards] OTR

[Dave Cridland]

On 19 December 2014 at 20:31, Mathieu Pasquet mathi...@mathieui.net wrote:

 On Fri, Dec 19, 2014 at 02:51:02PM -0500, Sam Whited wrote:
 
 
  On 12/17/2014 11:46 AM, Winfried Tilanus wrote:
   In response to my comment that it left a lot of information
   unencrypted he suggested to start a second OTR protocol in XMPP, one
   that does proper service discovery and properly encrypts everything
   of the stanzas that should be encrypted. Optionally embedding the
   plain version within it when you need to transverse to an other
   protocol.
 
  Agreed (that there should be an XMPP flavor of OTR); I'm not so sure
  that embedding the plain version within the XMPP discovered version
  would be helpful, this sounds like an edge case that won't often happen
  in 'real life' to me.
 


Also, minor point, I didn't think it was possible to do that in a secure
manner with OTR as-is. I think the library would force you to sacrifice the
ephemeral integrity. But I may very easily be wrong.


  One of the major problems with XMPP in general as I see it, is that
  extensions try to cover too many little edge cases that aren't ever
  likely to arrise and be a one size fits all solution. This leads to
  them being difficult to implement properly, which leads to
  incompatibilities and fragmentation among clients.
 
  Keeping things simple, and straightforward is the way to go IMO,
  especially in a security sensitive environment.
 
  That being said, embedding the normal OTR exchange isn't that
  complicatedm it just seems unnecessary to me; sorry, got a little
  sidetracked there.
 
   Well... I think the first step should be documenting the most common
   case, OTR'ing the content of a message in the OTR way
 
  Also agreed. Let's pump out a basic informational XEP that describes the
  state of OTR today, and in the mean time we can be discussing how we
  want to expand it in future.
 
  —Sam

 Once the work is started, it might be useful to eventually move (or
 share) the discussions to otr-dev [1] in order to have relevant feedback.


I'd assume that any future OTR protocol would be OTR encoding XML, instead
of just encoding plain text.

But you know what? That's the easy bit - the hard bit is all the subtle
bits that aren't documented. How it plays with resources, what the security
flaws are, and so on.

To get this what we need is an OTR XEP that describe what people do today.


 P.S.: I would love to have a standardized OTR where I don't have to
   guess if the message is an HTML4 mess or plain text, something
   the original OTR spec does not provide.


 [1]: https://lists.cypherpunks.ca/mailman/listinfo/otr-dev

 --
 mathieui (poezio developer)

Re: [Standards] XMPP or NodeJS ?

[Dave Cridland]

Further to the other comment, you suggested that implementing your own
system, designed from scratch, would be easier than implementing a system
which adheres to XMPP. This is absolutely correct.

XMPP is not a trivial protocol to implement. It's possible to build
something that will work to some degree much quicker. In fact, if you look
at the very early Jabber systems, they are indeed much simpler; however
you'll also note that problems with the simplistic approach were found and
identified, and while these made the protocol more complex, the result is a
better solution.

So the one clear negative that your friend has shown you is actually the
flip-side of a important positive - if you use XMPP, then many people will
have worked on refining the protocol to cope with a number of cases you'll
likely encounter with time.

In addition, as has already been noted, you don't have to implement XMPP;
there are libraries in virtually every language - often more than one
library in a given language - which will handle most of the complexity for
you.

Dave.

Re: [Standards] Veto on Privileged Entity

[Dave Cridland]

On 17 December 2014 at 05:15, Kurt Zeilenga kurt.zeile...@isode.com wrote:

 While your OP implies that “we” (presumedly “the community”) should take a
 step back and consider model and terminology issues, in your latest
 comments, it seems more that you want the authors to adopt a this model and
 terminology you originally wanted “we” to consider.

 While I would not have issue if you. independent of consideration of this
 ProtoXEP opened a discussion about how to model XMPP authorization services
 and what terminology should be used, I think it inappropriate to put this
 ProtoXEP on “hold” pending such discussions.  As you note in your OP, such
 an effort might not pan out.


Further to the note on members@, I would note that if I had not used a
veto, the proposal would now be almost a XEP due to timeouts on voting
which expire in a few hours. So please note that I've not actually held the
protoXEP in any meaningful manner up until now.

We'd also probably not be having this discussion, which is beginning to
become quite useful.


 But now your demand seems now that the authors recast their protoXEP to
 use the ABAC model and terminology when there hasn’t been the greater
 discussion and for which you think might actually be “way too difficult”.
 This seems like a absurd request to make of the protoXEP authors.


No, you asked specifically what the authors could do; I gave an answer to
that.


 As you put it, this is a “specification (that) describes a very specific
 solution to a very specific problem”.  Your goal is a single model for
 access control”, aside from being simply unrealistic given that XMPP is a
 general messaging framework supporting a wide range of applications, should
 be viewed as completely beyond the scope of this ProtoXEP.  And even if you
 limit the scope of your goal to some particular application using XMPP such
 as say IM or MUC, you are going to have a hard time getting to a single
 model of access control, especially where the one you are promoting is one
 of the two access control (role and rule based) models explicitly specified
 for us.


I'll assume a missing not there.

I dispute that we actually have a model. Also I dispute that such a model
is impossible, given that web services - which are at the very least just
as wide-ranging - can manage it just fine. Finally, I don't think
Role-Based Access Control really fits what we're doing anyway, and even
if it did, we need a better system.

By Rule-Based Access Control, I assume your intent is to refer to
XEP-0258. There's two server implementations of this that I'm aware of, one
based around the security label model described in FIPS 188 et al, and the
other based around an entirely opaque model. I'm not too concerned with
this, since it's a relatively specialist case, and while it's possible to
express a security labelling policy in something like XACML, it's not a
whole lot of fun. So while I've included mention of this for completeness,
I'm not sure if XEP-0258 is really part of the problem. This does, of
course, imply that we may be best off with two models instead of one, but I
think explicit labelling is somewhat a different problem.

By Role-based Access Control, I assume you're referring to the
Affiliations systems present in both MUC and PubSub. The primary problem
here is that there are a very small number of fixed roles, and the fixed
mapping of rights to roles is limiting actual applications in the real
world. The roles are also per-Object, which makes management of these
pretty convoluted - there's no mechanism in the current model for saying
MUC Service Administrator or Server Administrator, despite those roles
existing in many servers.

The existence of XEP-0317 should tell us that there are perceived problems
with MUC affiliations, and Buddycloud - for example - requires additional
affiliation types for its use of PubSub because its use-cases don't quite
fit.

As for this ProtoXEP, this is either Identity Based Access Control, or
else it's Role-Based with one Role (or, hey, one Role per Identity,
depending on which way you squint). In any case it's a new model (which, in
turn, is a very simplistic one). As defined, it's possible to grant rights
over PEP services via this mechanism - these are actually used in the
examples - which has the effect of having a different, conflicting, model.

I suppose one could argue that the proposal actually does specify a
universal model for XMPP authorization and Discretionary Access Control;
but it's not a very good one.

So summary:

There are problems with the inconsistent and simplistic model we have for
authorization in XMPP, and this proposal would make the situation worse.

You are asking the authors to re-cast their work away from a model they
 understand, which the community understands, and which has already been
 used in XMPP and arguably patterned after after existing use in XMPP, to a
 model which is likely alien to the authors, alien to many in this
 community,