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

[Guus der Kinderen]

If I understand the suggested change correctly, it's mostly a cosmetic one.
That, to me, is not worth risking relaxing a definition/restriction that we
made in 0001 (which is quite the core of what we're basing things on). I'm
in camp "let's live with the wart".

 - Guus

On Tue, Mar 12, 2024 at 10:59 AM Dave Cridland  wrote:

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

[Standards] Re: Proposed XMPP Extension: HTTP Online Meetings

[Guus der Kinderen]

Hello!

Thank you for your feedback. Dele and I discussed Marvin's comments, and
agreed with his suggestion. We will provide an update to XEP-0483 to refer
to XEP-0482 for the applicable functionality described therein.

Kind regards,

  Guus

On Mon, Dec 11, 2023 at 6:04 PM Daniel Gultsch  wrote:

> Dear Editor,
>
> Council has accepted this XEP.
>
>
> Dear XEP author: Council has noted some overlap with XEP-0482. Please
> get in touch with the authors of that XEP to see if you can merge
> and/or remove the overlap. See Marvins earlier mail for details.
>
> cheers
> Daniel
> ___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

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

[Guus der Kinderen]

Thanks Peter,

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

 - Guus

On Thu, Nov 30, 2023 at 3:16 AM Peter Saint-Andre 
wrote:

> Hi all,
>
> Don't forget that the Last Call ends tomorrow (well, today for many of
> you). If you have comments to share, please send them soon.
>
> As to the specifics of the feedback from Guus, see further comments
> inline...
>
> On 11/2/23 12:23 PM, Dave Cridland wrote:
> >
> >
> > On Wed, 1 Nov 2023 at 16:59, Peter Saint-Andre  > <mailto:stpe...@stpeter.im>> wrote:
> >
> > Hallo Guus,
> >
> > Thanks for sharing your thoughts. In my comments below, I haven't yet
> > provided suggested text, but I wanted to reply quickly and I will
> send
> > another note when I can make concrete proposals.
> >
> > On 10/31/23 3:18 PM, Guus der Kinderen wrote:
> >  > Hello,
> >  >
> >  > Thank you for the work that has gone into this.
> >  >
> >  > To me, the document is clearly worded.
> >
> > That's good to hear.
> >
> >  > I would appreciate elaboration on
> >  > the sentence "Humour is not a mitigating factor here" in section
> 2.3.
> >
> > I expect that Dave meant "perhaps you were merely trying to be
> > humorous,
> > but that doesn't excuse a poor choice of words".
> >
> >
> > I think I had in mind:
> >
> > HAR HAR I WAS ONLY JOKING CAN'T YOU TAKE A JOKE??!??!!111
> >
> > But yes, as usual, you put it better.
>
> OK, I will incorporate that text or something very much like it.
> >
> >  > An
> >  > additional suggestions is to add a reminder that we do not all
> > share a
> >  > common cultural background or even a native language and that
> > this can
> >  > easily introduce confusion of tongues.
> >
> > That is an excellent point. I will formulate some text about that.
> >
> >
> > This too. What is acceptable humour (or simply phrasing) in one culture
> > isn't in another - see, for example, "bum bags" versus "fanny packs".
>
> Here is proposed text for adding to Section 2.3:
>
> "Additionally, because participants in XSF events and venues typically
> do not all share a common native language or culture, take extra care to
> ensure that your words can be understood clearly and without offense."
>
> >  > To what extent will this document, once adopted, be not only
> > applicable
> >  > to all of the XSF's Activities, but also be the singular source of
> >  > policy? Does that need to be specified?
> >
> > I expect this document would be the single source of policy on the
> > topics it covers. If we learn that we've missed something important,
> > we'll need to update the XEP. Defining policy for the same topic in
> two
> > places would be confusing.
>
> Guus, do you think we should add text to address that point? I suppose
> it might best belong in the Introduction.
>

To be honest, I lost my own train of thoughts on this (and reading back, I
didn't make it clear what I was after). There might be some nitty-picky
details in this causing us to explicitly define if a particular activity is
or isn't an official (c)(r) XSF activity (when there are discussions of
what CoC to apply) - but maybe that's actually a good thing: it forces us
to be clear, in cases where it might not be now (if that's even the case).
I see no reason to add more text for this now.


>
> >  > As for the applicability: much (all?) of the violations that I
> > witnessed
> >  > are simple spamming or abusive behaviours in MUC rooms. The
> > definition
> >  > of desired vs undesirable behaviour that's in this document can
> > help in
> >  > those cases, but the process on section 5 is less applicable. I
> > doubt
> >  > that this document intends to make moderators of a room go
> through a
> >  > procedure of Reporting to the Conduct Team, prior to issuing a
> ban.
> >  > Should this document more explicitly allow for action to be taken
> >  > outside of the procedure defined in section 5?
> >
> > Yes, it should. I'll think about this, as well, and propose text in a
> > future message.
> >
> >
> > I think that there are occasions where an immediate action is warranted,
> > and should be taken by those with the capacity to do so; moderators
> > banning people from chatr

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

[Guus der Kinderen]

Hello,

Thank you for the work that has gone into this.

To me, the document is clearly worded. I would appreciate elaboration on
the sentence "Humour is not a mitigating factor here" in section 2.3. An
additional suggestions is to add a reminder that we do not all share a
common cultural background or even a native language and that this can
easily introduce confusion of tongues.

To what extent will this document, once adopted, be not only applicable to
all of the XSF's Activities, but also be the singular source of policy?
Does that need to be specified?

As for the applicability: much (all?) of the violations that I witnessed
are simple spamming or abusive behaviours in MUC rooms. The definition of
desired vs undesirable behaviour that's in this document can help in those
cases, but the process on section 5 is less applicable. I doubt that this
document intends to make moderators of a room go through a procedure of
Reporting to the Conduct Team, prior to issuing a ban. Should this document
more explicitly allow for action to be taken outside of the procedure
defined in section 5?

Kind regards,

  Guus

Op di 31 okt 2023 19:09 schreef Peter Saint-Andre :

> This message constitutes notice of a Last Call for comments on XEP-0458,
> a Procedural XEP that the XSF Board of Directors is considering for
> advancement to a status of Active.
>
> Title: Community Code of Conduct
>
> Abstract: This document describes the XMPP Standard Foundation's Code of
> Conduct.
>
> URL: https://xmpp.org/extensions/xep-0458.html
>
> This Last Call begins today and shall end at the close of business on
> 2023-11-30.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this document needed to fill gaps in the XSF's policies and
> procedures?
>
> 2. Does the document address the goals stated in the introduction?
>
> 3. If code of conduct defined in this document applied to an interaction
> in which you participated (e.g., if you witnessed a violation of the
> code), would you follow the procedures defined in the document?
>
> 4. Do you have any privacy or security concerns related to this
> specification?
>
> 5. Is the document clearly written and does it avoid unnecessary or
> potentially damaging ambiguity?
>
> Your feedback is appreciated!
>
> Peter
> (on behalf of the XSF Board of Directors)
>
> ___
> Standards mailing list -- standards@xmpp.org
> Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
> ___
>
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] Re: Proposed XMPP Extension: Reporting Account Affiliations

[Guus der Kinderen]

Hi all,

I've been toying with an Openfire-based implementation for the Reporting
Account Affiliations plugin. The plugin has not seen much real-world use
yet (it barely has been smoke tested). So far, I've only implemented the
'reporting' functionality (the Info-request query mechanism, and the
embedding things). I have not yet implemented a consumer part (eg: using
account info to do something with regards to permissions). For the curious,
the code is here:
https://github.com/igniterealtime/openfire-accountaff-plugin

When implementing this, I wondered about the following.

Is embedding worth it?

A (considerable) benefit of embedding account info in stanzas is that it
saves round-trips: whenever an entity wants to know the data, it does not
necessarily need to perform a lookup. Are there other benefits that I've
not yet identified?

The round-trip that's saved comes with a caveat: prior to usage, a
recipient MUST perform a disco/info query to the originating domain, to see
if the provided data can be trusted. This can be optimized (through
caching), and the disco/info result can be re-used for all accounts that
originate from the domain - but still, it's not quite round-trip free.

Something about adding data to a stanza that is inherently 'unsafe'
(something that MUST be verified before use) does not sit well with me. It
is invitingly easy for an implementation to skip, or have an issue in that
second step, which would lead to misinterpretation of data that has
potential to be used for authorization purposes.

I expect that the account information data is rarely used - although I'll
readily admit that I've not coded this part yet, and that there might be
future use-cases that I'm not thinking of. Assuming that I'm right, then
the embedding of data on many stanzas can add considerable overhead: not
only in stanza size (which possibly gets persisted in MAM archives - which
leads to interesting questions around the validity of this data over time),
but also to compute the value at the originating server. The XEP addresses
this by providing guides on when to embed data (more on that below), but a
significant amount of overhead remains. Is that worth the savings of a
round-trip (especially when a verification request might be needed anyway)?

The XEP defines three types of stanzas in which to embed account info. I've
found implementing this to be a lot harder than anticipated (which very
well might be a result of Openfire's API). One thing that I struggled with
was to choose when to act on a stanza that was being processed: when
processing inbound, client-originating stanzas, I worry about missing
stanzas that are generated by the server on the user's behalf. When
applying this to outbound stanzas, it's not straight-forward to identify
stanzas that originated from local users - and even if you do, something
like MUC can have modified the addressing, making identifying the correct
local account even harder. The complexity adds up, which leads to
implementations that are more error-prone.

If I understand the XEP correctly, it specifies that a server must remove
account info from client-originating stanzas if the server has support for
embedding account info for that particular type of stanza (to avoid
spoofing). Given the complexity that I tried to describe above, I believe
that this is error-prone. Can we consider mandating that ALL account info
from client-originating stanzas is to be removed, if the server has support
for any kind of account reporting? Is there any reason to clean up this
data in some, but not all client-originating data?

Given all of the above, I'm cautiously arguing that all of the 'embedding'
should be removed from the XEP. I do not believe that its benefit
(preventing a query, sometimes) outweighs the drawbacks (in added
complexity and overhead). Removing it might lead to implementations that
are easier (faster) to build and are less error-prone.

As a last remark: the explicit query for information is made against the
bare JID of the entity for which information is seeked. XMPP dictates that
a server MUST answer such IQ queries on behalf of the user, so this works.
I do not like how this implies that another entity is being asked to
provide data than the entity that we require to provide the data: the XEP
explicitly does not want a client/user to provide this data (that's even
defined as 'spoofing'). It wants a server to provide this data. In this
light, it would be clearer to address the request to the server JID
(without a node-part) instead of an account JID.

I'm running out of coffee, so I'll leave it at this for now. I hope this
will be helpful.

Kind regards,

  Guus


On Wed, Jul 19, 2023 at 4:12 PM Daniel Gultsch  wrote:

> Hi Kev,
>
> council has accepted this XEP.
>
> cheers
> Daniel
>
> On Tue, Jul 4, 2023 at 3:56 PM  wrote:
> >
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> >
> > Title: Reporting Account Affiliations
> > Abstract:
> > This 

[Standards] Re: Wrapping up the XMPP Lemmy Experiment

[Guus der Kinderen]

I fear that this never lived up to its potential. Unless someone is
actively going to do something with this, I'd not let it linger. That only
adds to fragmentation and overhead. Too bad though.

 - Guus

On Tue, Jun 6, 2023 at 1:45 PM Sam Whited  wrote:

> Hi all,
>
> It's been over a year and the folks hosting the XMPP Lemmy experiment
> at community.xmpp.net have asked us to start transitioning it to our
> own hosting.
>
> I'm writing to see what the community would like to do, or if anyone
> wants to take over hosting? The instance was never very widely used, so
> I think we can probably shut it down safely as well without too much loss.
>
> What do you think?
>
> —Sam
>
> --
> Sam Whited
> ___
> Standards mailing list -- standards@xmpp.org
> Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
> ___
>
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] XEP - 0045: nick attribute in member/owner/admin lists

[Guus der Kinderen]

Dear XMPP aficionados,

XEP-0045 section 9.5[1] defines a to-be returned member list as follows:
"The service MUST then return the full member list to the admin qualified
by the 'http://jabber.org/protocol/muc#admin' namespace; each item MUST
include the 'affiliation' and 'jid' attributes and MAY include the 'nick'
and 'role' attributes for each member that is currently an occupant."

A similar definition exists for lists of other affiliation types ('owner'
and 'admin').

What value for the 'nick' attribute is intended here: the nickname
currently in use by this member, or the nickname that is reserved for the
member?

I'm reading the text as: the 'nick' and 'role' attributes are included if
the member has currently joined the chatroom, which would suggest the
former.

The former definition clashes in a scenario where a member has joined the
same chat room from multiple clients, using different nicknames. I don't
believe that this can be expressed in the member list when using this
definition.

>From experience, some existing client implementations expect the 'nick'
attribute to be present even when the member has not joined the chatroom
(to be used in a display in a UI), in other words, the latter definition.

As a possible benefit from using the latter definition: When using the
former definition, then there is no way for a client to obtain a list of
all reserved nicknames in a room. Using the latter definition, this becomes
possible.

>From the above, the latter definition (include the reserved nickname, not
the nickname-in-use) makes most sense to me. This is not how I read the XEP
though.

I'd like the wording in the XEP to be less ambiguous, and clearly define
one or the other. I'm leaning towards the latter definition, but I'm also
thinking that this is a change to the existing text. Thoughts?

Kind regards,

  Guus

[1] https://xmpp.org/extensions/xep-0045.html#modifymember
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0227 update

[Guus der Kinderen]

Hi Matt,

Thanks for reviving this thing. It was indeed pretty outdated.

Openfire has an implementation too, although I'm not aware if it was ever
tested against other servers.

Should we consider introducing a change to the namespace as used in the
portable data, to more explicitly handle the changes in format? I'm aware
that you mainly introduced new elements, and the one attribute that you
dropped ('password') is defined as a 'should' - but still: the output is
significantly different. Given the nature of the protocol, it is not
unthinkable that data exported by an implementation following the older XEP
version gets imported by one of a newer version, and vice versa - perhaps
with plenty of time between import and export (eg: backup restores).

Why is the chronological order of messages in an archive defined as a MUST?
Does that attempt to safeguard against messages not having a timestamp?

Kind regards,

  Guus

On Wed, 2 Jun 2021 at 18:00, Matthew Wild  wrote:

> Hi folks,
>
> This somewhat forgotten XEP used to be the way to migrate data between
> XMPP services. Unfortunately it didn't keep up with the times, and
> many servers gained tools for importing directly from the native
> formats of other servers (Prosody has an ejabberd importer, ejabberd
> has a Prosody importer).
>
> Even if it never again becomes the standard format for server software
> migrations (XML is not an ideal format when you're dealing with
> massive amounts of data), as part of the XMPP account portability
> project[1] I want to once again bring XEP-0227 up to date with what
> data commonly constitutes an XMPP account.
>
> I've prepared an update that adds some of the missing features:
>
>   - SCRAM hashes (it previously recommended inclusion of plaintext
> passwords)
>   - PEP nodes (configuration and items)
>   - Message archives
>
> I'd appreciate feedback, and also I'd be curious of any wishlist items
> that anyone else may have.
>
> The draft PR is at: https://github.com/xsf/xeps/pull/1064 and a
> rendered version is available at
> https://matthewwild.co.uk/uploads/xeps/xep-0227.html
>
> Regards,
> Matthew
>
> [1]: https://docs.modernxmpp.org/projects/portability/
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

My thoughts: Informational. I believe that the XSF should be concerned more
with maintaining the XMPP standards than it should be concerned with
ensuring that information regarding projects that relate to XMPP is made
available in a structured fashion (which are covered by the other two
options that you provided).

  - Guus

On Wed, 13 Jan 2021 at 18:31, Dave Cridland  wrote:

> Some discussion in Council as to where this fits. I'm quite happy it is
> useful as a XEP.
>
> So, is this:
>
> Informational: It's a Best Practice for the community. We are recommending
> that projects use DOAP.
>
> Standards Track: It's a specification we want to standardize for the
> community to use. Section 4.2 contains new bits of XML and - presumably -
> would be developed via a Standards Track process.
>
> Procedural: It's something the XSF should do (ie, receive the DOAP files
> and process them somehow).
>
> I think there are arguments for all of these, and I've not made up my mind.
>
> What do people think?
>
> Dave.
>
> On Wed, 13 Jan 2021 at 16:13, Jonas Schäfer  wrote:
>
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: DOAP usage in XMPP
>> Abstract:
>> This specification defines how XMPP projects can provide a machine-
>> readable description of their abilities, and how external entities can
>> interact with it.
>>
>> URL: https://xmpp.org/extensions/inbox/doap-usage-in-xmpp.html
>>
>> The Council will decide in the next two weeks whether to accept this
>> proposal as an official XEP.
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Use of XEP-0198 resumption under adverse network conditions

[Guus der Kinderen]

Hi Dave,

Thanks for sharing this. To verify that I got it wrong, can I dumb your
suggestions down by summarizing them as:

   - Increase the timeout after which a connection is considered
   unrecoverably dead (to ... how many minutes?)
   - After a period of inactivity that's a lot shorter than the timeout
   mentioned above (presumable around the existing timeout value) start
   generating push notifications

Regards,

  Guus

On Wed, 4 Nov 2020 at 12:48, Dave Cridland  wrote:

> Hey all,
>
> We (that is, myself and others from Forward Clinical Ltd, my employer)
> have been doing some extensive work to support high latency networks such
> as Satellite Links, in relation to our work with UK Defence Medical
> Services. Our "long thin" links cover the C2S link.
>
> We believe these findings are more generally useful than just SATCOM - in
> particular, we think these will help with the adverse network conditions
> found in hospitals (where people keep putting in lifts and lots of cables,
> giving lots of blackspots), and general applicability with mobile use of
> XMPP.
>
> TL;DR: When the session has a ping timeout, do push notifications, but
> otherwise leave it open - mobile clients will often recover after several
> minutes have passed.
>
> We assume that established sessions may be in several connectivity states
> from the point of view of the server, typically:
>
> "Live" - a session is genuinely live and can be used for communication.
> "Unresponsive" - the session has a TCP connection associated with it, but
> it unresponsive to pings etc.
> "Resumable" - the session has no TCP session, but 198 resumption was
> negotiated and the session remains available.
>
> We expect that the majority of servers will immediately move a session
> detected as unresponsive into the resumable state by closing the TCP
> session, and starting a (relatively short) timeout.
>
> In the process of doing so, unacknowledged stanzas will be processed for
> push notifications etc as needed, and errors will be sent as appropriate.
>
> Due to network analysis (and "thanks" to a bug in the server which caused
> some useful logging), we were able to examine not only when sessions went
> into the unresponsive state, but also when the client subsequently sent
> traffic on that session. This often happened well after the session had
> fallen into the resumable state - this resulted in an error, as the session
> had been closed.
>
> Having seen the result of this in the logging of the server, we followed
> up by looking for the same logging output on the production system, where
> the majority of users are using WiFi or 4G within hospitals. Coverage is
> often poor, and the WiFi overused, so clinicians often operate on a weak 4G
> signal, or highly contented WiFi. Think FOSDEM.
>
> Again, we observed clients recovering sometimes well after the ping
> timeout had triggered. Had these clients been able to, they could have
> continued to use the same TCP session without any disruption (or, for that
> matter, any additional RTTs re-establishing).
>
> The usual approach here seems to be to increase the timeout required to
> move a session from "live" to "unresponsive" when pinged. However, this has
> the effect of delaying push notifications while the session is, in effect
> in limbo.
>
> Our proposal is that when a session is found to be unresponsive, the
> server starts sending push notifications for unacknowledged (and future)
> messages, but otherwise leaves the session live when resumable. Only after
> a significantly longer timeout should the TCP session be terminated (and at
> that point destroy the session entirely).
>
> This means that a client recovering network after several minutes will
> find the connection still live (in effect), whereas if it never recovers,
> it will still get the push notifications in a timely manner.
>
> There are likely to be downsides with this approach; particularly presence
> state will be badly affected. PSA could help here. Overall, though, we
> believe that this will substantially improve the effective performance of
> C2S over high latency, high contention links.
>
> I hope this is useful!
>
> Dave.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Very Simple Questions about Compliance Suites

[Guus der Kinderen]

We have not, for Openfire. We've never had anyone ask us if the product has
a particular level of compliance either. That's not to say that there is no
interest, but I believe there's not much interest, at least not in our
community.

I'd be happy to start including compliance claims, but, especially given
that this all was very much a moving target over the last decade or so, it
feels more like an administrative chore than something that'd add much
value.

I'm seeing more value in (online) test frameworks, that provide feedback of
the realtime state of a particular instance of the server. We _do_ get
questions about those from our users.

 - Guus

On Wed, 2 Sep 2020 at 18:08, Thilo Molitor  wrote:

> > If you have an XMPP product or public project, do you claim compliance
> with
> > XEP-0423?
>
> For Monal we are aiming for compliance in the long run.
>
> - tmolitor
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)

[Guus der Kinderen]

Hi Jonas,

Thanks for all of the effort that you're putting into this. A concern that
I have with the shared gitlab/github solution is that it has a lot of
moving parts, a lot of dependencies, and a lot of places where things can
go wrong. Complexity of the implementation increases (to save complexity in
the editoring process, which is a worthy cause). I'd like us to consider if
the implementation that we're going for will be maintainable in the future,
after the architects of the implementation move on to greener pastures.

Regards,

  Guus

On Tue, 16 Jun 2020 at 18:59, Jonas Schäfer  wrote:

> Hi again,
>
> Thanks Sam and Kevin for your valuable feedback. I think what you say
> definitely has merit.
>
> In light of that, we came up with a hybrid solution which may be better or
> worse. We need input on that.
>
> - We keep the GitHub xeps (and registar) repositories.
> - We create mirror repositories on GitLab.
> - We configure a two-way sync between the GitLab and GitHub repositories
> for
> the main branch, but not for pull/merge requests or issues or non-main
> branches.
> - We disable the issue tracker on GitHub (or GitLab) so that there’s only
> one
> place to report and track issues.
> - MRs/PRs will be handled by editors on both platforms (but still with
> less
> work than before), with equal priority
> - MRs on GitLab will gain additional features (like HTML-rendered diffs
> etc.)
> for users; this is because we cannot trivially add those features to
> GitHub
> due to lack of support, but they’re cheap to add over there.
> - In the mid-term, we move xep-*.xml into a subdirectory so that the
> README of
> the repositories is more accessible and can be augmented with an "end
> user"
> guide more easily.
> - xep-attic moves completely over to GitLab for simplicity.
> - Thanks to the two-way sync, we can use the advanced GitLab CI features
> to do
> the automagic.
>
> Assume that we’ll update all relevant documentation to state that "XEP
> contributions are accepted on GitLab, GitHub and via email to
> edi...@xmpp.org". We’ll also update the repository descriptions to
> indicate
> that they are mirrors of each other.
>
> We would still have to sort out a few legal bits (e.g. around the CLA/IPR
> stuff) as well as actually test if this plan is workable on a technical
> level
> in practice. Before we do that work, we’d like to hear from the
> (rightfully!)
> cautious voices about this approach.
>
> Again, thank you very much for your feedback.
>
> kind regards,
> Jonas
>
>
> P.S.: Consider the timeline from the previous email void. We don’t want to
> rush ahead of the community, even though that will further delay the
> recovery
> of the registry. A few weeks won’t matter on this, and we don’t want a
> half-
> baked solution which does more harm than
> good.___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0289 FMUC: Do joined nodes know what mode is configured?

[Guus der Kinderen]

I've had some one-on-one conversations which lead me to believe that
expecting the joined FMUC node to echo a stanza back in master-slave mode,
but not in master-master mode, is something that's not adequately covered
in the XEP. Assuming that this indeed is an oversight, I'd like to work
towards a fix. I'll offer a few suggestions:

a) Somehow negotiate the configuration mode between both nodes.
b) Have the joining node include a flag on each stanza it sends to the
joined node that signals whether a callback is desired or not
c) Have the joined node include a flag on a stanza that is echoed back,
indicating that it is an echo (a 'status 110'-like solution).
d) Have the joining node persist each stanza that it sends to the joining
node, allowing it to evaluate each inbound stanza to determine if it's an
echo.

Thoughts?


On Mon, 4 May 2020 at 12:53, Guus der Kinderen 
wrote:

> Hello all,
>
> A XEP-0289 FMUC question, related to section 5.2 (
> https://xmpp.org/extensions/xep-0289.html#messages ).
>
> The example describes how a joining FMUC node (elsinore) sends a message
> to the joined FMUC node (rabbithole). Federation is configured to use the
> master-slave mode (where rabbithole is the master). This sentence makes me
> wonder if I misunderstand a key part of the XEP:
>
> This example is for master-master mode, so rabbithole does not echo the
>> message back to elsinore and elsinore does not need to wait for receipt of
>> this stanza from rabbithole (...)
>
>
> As I understand the XEP, the federation is initiated by elisnore. This is
> where the configuration lives. No negotiation of the configuration
> (specifically, the type of mode that's used) seems to take place. This is
> also referenced to in section 5.1:
>
> Note that this configuration only needs to be one way (that is: there is
>> no protocol reason why rabbithole needs to know that elsinor will be
>> federating with it in advance)
>
>
> How does rabbithole determine that it needs not echo the message back to
> elsinore?
>
> Regards,
>
>   Guus
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0289 FMUC: Do joined nodes know what mode is configured?

[Guus der Kinderen]

Hello all,

A XEP-0289 FMUC question, related to section 5.2 (
https://xmpp.org/extensions/xep-0289.html#messages ).

The example describes how a joining FMUC node (elsinore) sends a message to
the joined FMUC node (rabbithole). Federation is configured to use the
master-slave mode (where rabbithole is the master). This sentence makes me
wonder if I misunderstand a key part of the XEP:

This example is for master-master mode, so rabbithole does not echo the
> message back to elsinore and elsinore does not need to wait for receipt of
> this stanza from rabbithole (...)


As I understand the XEP, the federation is initiated by elisnore. This is
where the configuration lives. No negotiation of the configuration
(specifically, the type of mode that's used) seems to take place. This is
also referenced to in section 5.1:

Note that this configuration only needs to be one way (that is: there is no
> protocol reason why rabbithole needs to know that elsinor will be
> federating with it in advance)


How does rabbithole determine that it needs not echo the message back to
elsinore?

Regards,

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

Re: [Standards] Call for Experience: XEP-0198: Stream Management

[Guus der Kinderen]

You've clearly never experienced my parent's WiFi.

Op vr 21 feb. 2020 09:25 schreef Daniel Gultsch :

> Only someone who hasn't been on a German high speed train can say with
> confidence that desktop and web clients don't need stream management.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-02-05

[Guus der Kinderen]

On Mon, 10 Feb 2020 at 11:10, Dave Cridland  wrote:

> PEDANTRY WARNING!
>
>
Welcome back.



> On Thu, 6 Feb 2020 at 23:03, Tedd Sterr  wrote:
>
>> http://logs.xmpp.org/council/2020-02-05?p=h#2020-02-05-9b7fab88b70a9fc4
>>
>> *1) Roll Call*
>> Present: Georg, Jonas, Daniel, Zash
>> Apologies: Dave
>>
>> *2) Agenda Bashing*
>> Jonas apologises for the lack of agenda; suggests a CFE for XEP-0198 -
>> Georg thinks 0198 is one of the less controversial ones.
>>
>> *3a) Call for Experience: XEP-0198 (Stream Management)* -
>> https://xmpp.org/extensions/xep-0198.html
>> Jonas: +1
>> Georg: +1
>> Zash: +1
>> Daniel: +1
>> Dave: [pending]
>>
>>
> I do not need to vote on this, because the Council doesn't vote on a Call
> For Experience.
>
>
>> *3b) Call for Experience: XEP-0423: (XMPP Compliance Suites 2020)* -
>> https://xmpp.org/extensions/xep-0423.html
>> Jonas reasons "why not" - Georg thinks it might be a bit early to have
>> implementations - Jonas thinks it might be interesting to gather
>> implementation feedback. Daniel is unsure how a CFE for the Compliance
>> Suites would look. Jonas still thinks it's an oddity in the Standards Track.
>>
>> Jonas: +1
>> Georg: +1
>> Daniel: +1
>> Zash: [pending]
>> Dave: [pending]
>>
>> Daniel realises this is all highly illegal, as XEP-0423 is not yet six
>> months old; Jonas quickly aborts the vote and hopes to evade any legal
>> ramifications.
>>
>>
> Quite; and also we don't vote on CFEs anyway.
>
>
>> Daniel was considering suggesting XEP-0368 (SRV records for XMPP over
>> TLS).
>>
>
> That'd be interesting to do a CFE around as well.
>
>
>>
>> *4) Outstanding Votes*
>> Everyone is up-to-date, apart from those pending today.
>>
>> *5) Date of Next*
>> 2020-02-12 1600 UTC
>>
>> Georg is hoping to have an appointment that day.
>>
>> *6) AOB*
>> Georg doesn't have any AOB.
>>
>> Ralph thanks Council for actively pushing XEPs through the process.
>>
>> *7) Close*
>> Thanks.
>>
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Guus der Kinderen]

On Tue, 14 Jan 2020 at 22:42, Jonas Schäfer  wrote:

> This message constitutes notice of a Last Call for comments on XEP-0363.
> The
> Last Call was restarted after the Council election, because the previous
> Council did not vote on the ongoing LC.
>
> Title: HTTP File Upload
> Abstract:
> This specification defines a protocol to request permissions from
> another entity to upload a file to a specific path on an HTTP server
> and at the same time receive a URL from which that file can later be
> downloaded again.
>
> URL: https://xmpp.org/extensions/xep-0363.html
>
> This Last Call begins today and shall end at the close of business on
> 2020-01-28.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
>
Functionally, existing specs cover "transferring data". This protocol,
however, fill the gap of the unavailability of one such protocol that's
easily implemented/adopted.


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
> Yes - the last requirement is worded a bit awkwardly perhaps (not doing
something makes for a weird requirement).


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
I have (server-sided)


> 4. Do you have any security concerns related to this specification?
>
>
None other than that are explicitly stated in the specification.


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


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

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Guus der Kinderen]

This XEP might want to add an implementation note that relates to
https://xmpp.org/extensions/xep-0245.html. When XEP-0245 is used, clients
often use a different representation of the message from what's in the body
(eg: replacing "/me" with a nickname). This makes it very easy to make
mistakes in calculating a character-count based offset (eg: to identify the
position of a mention), as a nickname is likely to have a different
character count than the three in "/me". It's kind of a silly problem, but
easy enough to make. Protecting against it by adding it to this XEP can
help.

On Tue, 17 Dec 2019 at 12:20,  wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Character counting in message bodies
> Abstract:
> This document describes how to correctly count characters in message
> bodies. This is required when referencing a position in the body.
>
> URL: https://xmpp.org/extensions/inbox/charcount.html
>
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)

[Guus der Kinderen]

Thanks for the effort to push this well before the end of the year. :)

On my first reading, I noticed two things:

XEP-0385 "Stateless Inline Media Sharing (SIMS)" is mentioned both in
section 1.1 "Changes since 2019", but also in section 3 "Future
Development". Is that an error, or intended? I'd argue that if you're
including something in this edition of the CS, then there's no point of
adding it also as a 'keep an eye on this one for the future'

I am surprised to see XEP-0392 "Consistent Color Generation" in the CS.
What's the rationale to include it? Without giving this to much thought,
I've regarded this XEP more as a useful guide for those who'd explicitly
choose to implement a, rather than something that is required to implement
to be considered 'compliant'. I'm expecting that there are projects that
explicitly not want this (in favor of marketing-driven decisions on
look-and-feel, themes, colors, etc). Is the functionality described this
XEP of such a nature that we'd be willing to mandate it?

Regards,

  Guus

On Wed, 23 Oct 2019 at 17:07, Jonas Schäfer  wrote:

> This message constitutes notice of a Last Call for comments on
> XEP-0423.
>
> Title: XMPP Compliance Suites 2020
> Abstract:
> This document defines XMPP application categories for different use
> cases (Core, Web, IM, and Mobile), and specifies the required XEPs
> that client and server software needs to implement for compliance with
> the use cases.
>
> URL: https://xmpp.org/extensions/xep-0423.html
>
> This Last Call begins today and shall end at the close of business on
> 2019-11-06.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
> 4. Do you have any security concerns related to this specification?
>
> 5. Is the specification accurate and clearly written?
>
> Your feedback is appreciated!
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0059 RSM Before, after, index combinations

[Guus der Kinderen]

Hello,

As far as I can tell, XEP-0059: Result Set Management does not clearly
state how requests that include a combination of the before, after and
index elements should be handled.

It does not appear to make much sense to allow for this. Without having
identified explicit use cases, I'd argue that the added complexity of
allowing combinations probably to outweigh any functional benefit. In any
case, I'd like to see the XEP updated to be more explicit.

Thoughts?

Regards,

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

Re: [Standards] Whitespace "ping"

[Guus der Kinderen]

I'd have to check, but I think we're sending a IQ Ping when the client
misses it's first white space ping interval (whatever we deem is
appropriate in that server config), and define the client to be
disconnected when it doesn't respond in a timely manner. This covers both
of your "the client is being silly" scenario's: to many whitespace pings
aren't adding much overhead to the server, while to few pings are covered
by the IQ Ping. I agree with you that it's all very unspecified, which
could be improved on. I'm not seeing much of a direct  _need_ to do that,
but I'd not oppose it either.

On Tue, 11 Jun 2019 at 14:24, Mickaël Rémond 
wrote:

> Hello Guus,
>
> On 11 Jun 2019, at 14:00, Guus der Kinderen 
> wrote:
>
> What we need basically is a way to negotiate the interval with server
>
>
> I'm not sure if this is _needed_? Without this being a requirement, much
> of the complexity of "making this more standard" falls away.
>
>
> Well, I think if the server does not have to approve the value, client
> could expect to set it to something extreme (like 1s) or useless (like 1
> days). The server could thus reply with a different value. And still the
> server needs to know at which rate the client is expected to send the keep
> alive.
> But, yes, it is always possible to do something like that in a non
> standard way. My point was trying to agree on something to make life of
> client developers easier :)
>
> A server could, before determining that a connection is lost, attempt to
> send any IQ stanza (PING is an obvious choice, but any query will do). As
> the client is obliged to respond, if anything with an error, the server
> knows if the connection is, in fact, lost.
>
>
> What would be the trigger for determining that the connection is lost and
> send the ping? Is it whitespace keep-alive or anything else?
>
> Thanks!
>
> --
> Mickaël Rémond
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Whitespace "ping"

[Guus der Kinderen]

Yeah, I remember our then-CEO telling us that his phone "would not get warm
anymore", after we changed the interval from 30 seconds to 2 minutes. That
was over a decade ago though. I think that you're right in that patterns
change with evolving mobile phone components.

Unless I'm mistaking, Push Notifications are one-way. As far as I know,
they can't be used to tell if a client has dropped offline (and do all
kinds of follow-up / cleanup actions, server sided).

On Tue, 11 Jun 2019 at 14:11, Ненахов Андрей 
wrote:

> Btw, from a mobile client developer perspective, if a server pings an app
> every 30 seconds, the battery drain is very high and is significantly
> higher than if interval is set to 2 minutes. What's interesting is that
> dependency is not linear: drain seems to rise sharply with intervals less
> than 60 seconds. I don't recall the exact details though, it was 5+ years
> ago since we tested it. Also, I think that in current state of affairs the
> way to go are push notifications, and thus the need for ping is somewhat
> diminished.
>
> вт, 11 июн. 2019 г. в 17:01, Guus der Kinderen <
> guus.der.kinde...@gmail.com>:
>
>> What we need basically is a way to negotiate the interval with server
>>
>>
>> I'm not sure if this is _needed_? Without this being a requirement, much
>> of the complexity of "making this more standard" falls away.
>>
>> A server could, before determining that a connection is lost, attempt to
>> send any IQ stanza (PING is an obvious choice, but any query will do). As
>> the client is obliged to respond, if anything with an error, the server
>> knows if the connection is, in fact, lost.
>>
>>
>> On Tue, 11 Jun 2019 at 11:50, Mickaël Rémond 
>> wrote:
>>
>>> Hello,
>>>
>>> The RFC 6120 mentions whitespace ping to keep the connection alive and
>>> help the server detects that the client is gone.
>>> I also see that there was some attempt to bring consistency in the way
>>> server handles this in XEP-0304:
>>> https://xmpp.org/extensions/xep-0304.html
>>> It is rather old and today has also probably a bit of overlap with
>>> XEP-0198 Stream Management, and possibly also with XEP-0199 XMPP ping.
>>> I guess many client use the XEP-0198 acks, but still, XEP-0198
>>> recommends the use of TCP level whitespace keepalive.
>>> Having a way to check connection from client without generating load on
>>> parsers and limiting bandwidth used is important, so whitespace keepalive
>>> are goods.
>>>
>>> What do you think of pushing forward a way to make whitespace ping
>>> behaviour more standard?
>>> What we need basically is a way to negotiate the interval with server,
>>> so that client can be considered disconnected when that whitespace trafic
>>> is not receive in time.
>>>
>>> I am not really fond of making this a new stream feature, like XEP-0304
>>> suggest, as maybe what would make more sense is to define that feature in
>>> Stream management XEP itself (and thus could be part of the stream
>>> management negotiation)
>>>
>>> What do you think ?
>>>
>>> --
>>> Mickaël Rémond
>>>
>>>
>>> ___
>>> Standards mailing list
>>> Info: https://mail.jabber.org/mailman/listinfo/standards
>>> Unsubscribe: standards-unsubscr...@xmpp.org
>>> ___
>>>
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>
>
>
> --
> Andrew Nenakhov
> CEO, Redsolution, Inc.
> https://redsolution.com <http://www.redsolution.com>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Whitespace "ping"

[Guus der Kinderen]

>
> What we need basically is a way to negotiate the interval with server


I'm not sure if this is _needed_? Without this being a requirement, much of
the complexity of "making this more standard" falls away.

A server could, before determining that a connection is lost, attempt to
send any IQ stanza (PING is an obvious choice, but any query will do). As
the client is obliged to respond, if anything with an error, the server
knows if the connection is, in fact, lost.


On Tue, 11 Jun 2019 at 11:50, Mickaël Rémond 
wrote:

> Hello,
>
> The RFC 6120 mentions whitespace ping to keep the connection alive and
> help the server detects that the client is gone.
> I also see that there was some attempt to bring consistency in the way
> server handles this in XEP-0304: https://xmpp.org/extensions/xep-0304.html
> It is rather old and today has also probably a bit of overlap with
> XEP-0198 Stream Management, and possibly also with XEP-0199 XMPP ping.
> I guess many client use the XEP-0198 acks, but still, XEP-0198 recommends
> the use of TCP level whitespace keepalive.
> Having a way to check connection from client without generating load on
> parsers and limiting bandwidth used is important, so whitespace keepalive
> are goods.
>
> What do you think of pushing forward a way to make whitespace ping
> behaviour more standard?
> What we need basically is a way to negotiate the interval with server, so
> that client can be considered disconnected when that whitespace trafic is
> not receive in time.
>
> I am not really fond of making this a new stream feature, like XEP-0304
> suggest, as maybe what would make more sense is to define that feature in
> Stream management XEP itself (and thus could be part of the stream
> management negotiation)
>
> What do you think ?
>
> --
> Mickaël Rémond
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XMPP Compliance Badges, prototype feedback requested.

[Guus der Kinderen]

Hello,

There's an effort under way to have developed visual badges associated to
the XMPP Compliance Suites.

To my knowledge, three variants of badges are under development:

   - https://op-co.de/tmp/xmpp-compliance-badges/
   - https://bitbucket.org/mrtedd/compliance-badges/src
   -
   
https://opensourcedesign.net/jobs/jobs/2019-03-19-design-of-badges-for-different-xmpp-compliance-levels

We're looking for feedback on the visual quality and content of these
prototypes. Anything that will help the authors to improve them, as well as
for us to eventually choose between them, is highly appreciated.

Kindly provide feedback. :)

Regards,

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

Re: [Standards] MIX Implementation (Prosody module)

[Guus der Kinderen]

Your cat has skills!

On Mon, 1 Apr 2019 at 11:04, Tedd Sterr  wrote:

> I wasn't at the Berlin sprint, so I held my own mini-sprint - at home,
> pair-programming with my cat - which mainly involved me coding and her not
> paying any attention. After an extended weekend, too much caffeine, and
> meals consisting mainly of unhealthy snacks, I present to you a somewhat
> working MIX implementation!
>
> https://bitbucket.org/mrtedd/mixosaurus/
>
> Please note: this is unfinished and there will be bugs, but it works well
> enough for testing.
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0313 / XEP-0359 interaction

[Guus der Kinderen]

XEP-0313 "Message Archive Management" (v0.6.3) relies on XEP-0359 "Unique
and Stable Stanza IDs" to identify content in the archive.

MAM provides an archive on the server, which can be efficiently
synchronized with a client-sided archive. It does this using the IDs from
XEP-0359. It's a simple query: the client provides an ID of a message in
the archive, the server responds with all later messages.

Although this is a simple, elegant solution, it breaks when the client
receives messages that have XEP-0359 IDs, but are not part of the
(server-sided) archive. This puts quite a restrication on XEP-0359 use in
other contexts than MAM. Can this be improved upon?

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

Re: [Standards] Is the World Ready for Compliance Suites 2019?

[Guus der Kinderen]

I'm very much in favor of not applying changes to the 2019 suite that can
wait for the 2020 edition.

On Thu, 7 Mar 2019 at 08:39, Daniel Gultsch  wrote:

> Am Mi., 6. März 2019 um 21:07 Uhr schrieb Georg Lukas :
> > Example 1: "Modern" Use of OOB for Inline Images
> > 
> >   https://xmpp.org/theme/images/xmpp-logo.svg
> >   
> > https://xmpp.org/theme/images/xmpp-logo.svg
> >   
> > 
> >
> > While XEP-0066 is less than ideal for the purpose of embedding images,
> > and the body=url requirement isn't written down anywhere, it is
> > something that client developers should know about, at least to
> > implement it on the receiving side.
>
> Independently of whether or not you want the Compliance Suite to
> become a document describing the quirks of a particular client (which
> I don’t think is a good idea) I'd wait with those modifications for
> the 2020 compliance suite.
> Just get the 2019 out now and then start working on 2020.
>
> That’s the thing about the compliance suites. There will always be one
> more new thing that should be documented. But at some point we will
> have to decide that we are done for the year. That's why we are
> planning on doing this every year.
>
> For the future I'd actually suggest that we do some kind of 'feature
> freeze' in ~October and then spend the remainder of the year clearing
> up the wording and getting it to Draft.
>
> cheers
> Daniel
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Third month with no updated compliance suites

[Guus der Kinderen]

I do not dislike publishing the Compliance Suite content as part of the
website. It will make things more clear. I do not believe, however, that
the process of choosing what goes on that page is going to be faster, as
compared to doing this as a XEP. If anything, for a XEP, we have a process.

On Mon, 4 Mar 2019 at 11:14, Severino Ferrer de la Peñita 
wrote:

> On Monday, March 4, 2019 5:42:24 AM CET Ненахов Андрей wrote:
> > I think that the whole idea of making compliance suites as a xep is
> flawed
> > and creates unnecessary bureaucracy for bureaucracy sake.
> >
> > It could have been just a page on xmpp.org website, listing XEPs that
> > council currently consideres part of a compliance suites. No bureaucracy,
> > no need to update them every year, win-win for everyone.
> >
> > If someone won't be happy with just a current list, well, add versions to
> > it, in the simplest way possible.
> >
> > On Sun, 3 Mar 2019, 20:41 Severino Ferrer de la Peñita,  >
> >
> > wrote:
> > > On Sunday, March 3, 2019 3:41:44 PM CET Sam Whited wrote:
> > > > On Sun, Mar 3, 2019, at 13:51, Dave Cridland wrote:
> > > > > Who are you arguing *with*?
> > > >
> > > > The council and new authors. Also specifically the "Pot, kettle,
> etc."
> > > > statement, if you meant my last email.
> > > >
> > > > > I agree it's ridiculous, but I also note that the number of
> comments
> > > > > on the 2019 one is considerably below 20, and possibly less than
> 15,
> > > > > depending on how one counts. The number of people involved in the
> > > > > discussion outside Council is less than 5 (and I'm including your
> > > > > comments here, which are simply that we should have some Compliance
> > > > > Suites).
> > > >
> > > > Then even if we don't think the new ones are ready, let's at least
> > > > deprecate the old ones so we don't look like we're not doing our jobs
> > > > and no one is working on this. The external perception here isn't
> great.
> > > >
> > > > The next step would then be to try and figure out why the new ones
> > > > aren't ready. I think there are two important things to realize
> here: 1.
> > > > most of the arguments have already been had in previous years suites
> and
> > > > the new ones are similar enough that there aren't likely to be lots
> of
> > > > new comments, and 2. they don't have to be perfect because we'll get
> > > > another chance next year. These are guidelines that can be fluid,
> they
> > > > can even have mistakes without it being the end of the world (though
> of
> > > > course we should try to minimize these, but not at the cost of not
> > > > having any published).
> > > >
> > > > > If the community isn't interested in working on these, I'm not sure
> > > > > how we advance them faster.
> > > >
> > > > If the 2019 suites were finalized right now and the 2020 suites were
> > > > already being worked on, we'd have plenty of time for comments. This
> is
> > > > the only way I see the compliance suites working, and what I was
> trying
> > > > to do with previous years.
> > > >
> > > > When it comes down to it though, I don't particularly care how the
> > > > situation is resolved, rename the 2018 suites to 2019, just make
> sure we
> > > > have something with a current date on it which is the only way we're
> > > > going to be able to get people to take the compliance suites
> seriously
> > > > and not end up in a situation like we had before we picked them up
> again
> > > > where the 2012 suites (or somewhere around there) were the latest
> ones.
> > > >
> > > > —Sam
> > >
> > > I agree with Sam, current situation is not very good marketing for
> XMPP.
> > > How I see it, we should be focusing on discussing next year's instead.
> > > If there is not enough people engaging with compliance suites I trust
> > > Council
> > > to figure out a solution. Sam mentioned pretty valid ways of solving
> the
> > > problem I think.
> > >
> > > Seve.
>
> I've been asked this a couple of times as well, why the compliance suite
> is
> not a page at xmpp.org with the current situation instead of a XEP.
> People usually assume XEPs are protocol specifications to be implemented.
>
> Seve.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

Hi Larry,

I don't think that this mailinglist is the right place to discuss your
questions.

Although I'm not familiar with your issue, I think you should address them
at Google, not the XMPP standards mailinglist. I suggest that you start at
https://support.google.com/ and see where that gets you.

Regards,

  Guus

On Tue, 15 Jan 2019 at 13:17, larry martz  wrote:

> I have a couple questions... While looking into my Google account after a
> factory reset I was asked to choose what phone I Wanted to restore. But my
> options were exactly the same. In addition Google didn't recognize my phone
> number, I had changed my password the week before but the old one was the
> one I had to use.
> And çan someone explain the G-suite, and how that site can be a administor
> to numerous devices at one time. Last how can I not allow that type of an
> administrator.tnx
>
> On Mon, Jan 14, 2019, 11:49 AM Peter Saint-Andre  wrote:
>
>> On 1/12/19 1:01 PM, Jonas Schäfer wrote:
>> > On Montag, 17. Dezember 2018 16:50:17 CET Sebastian Riese wrote:
>> >> XEP-0261  uses "bytestream"
>> >> for the overall Jingle session and "session" for the IBB session (at
>> >> least it does so consistently). This is *extremely* confusing. For
>> >>
>> >> example section 2.5 reads:
>> >>> Whenever a party is finished with a particular session within the
>> >>
>> >> bytestream, it SHOULD send an IBB  as shown above. This applies
>> >> to all sessions, including the last one.
>> >>
>> >>> To close the bytestream itself (e.g., because the parties have
>> >>
>> >> finished using all sessions associated with the bytestream), a party
>> >> sends a Jingle session-terminate action as defined in XEP-0166.
>> >>
>> >> This nomenclature is just wrong: The Jingle session manages multiple
>> >> In-Band Bytestream sessions. If you close the Jingle session there may
>> >> be zero or more bytestream sessions that are closed (and perhaps other
>> >> transport sessions – Jingle does not prescribe uniform transports in a
>> >> session).
>> >>
>> >> If you all agree I would make a PR to fix this issue. My proposal is to
>> >> use "session" for Jingle sessions and "bytestream" for IBB sessions, if
>> >> this is deemed to be too confusing also, I could spell out "Jingle
>> >> session" and "IBB session".
>> >
>> > I suggest you take the silence as agreement.
>>
>> WFM
>>
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Council Minutes 2018-12-19

[Guus der Kinderen]

/me points at dwd
What he said.

On Fri, 21 Dec 2018 at 10:11, Dave Cridland  wrote:

> Hi folks,
>
> There were two heavy chunks of "Process" in this meeting. Surprisingly, I
> hate process - as anyone I've worked with can attest - but I'm usually the
> one defending it, so here I go again.
>
> The reason we have a process is not to make our lives more difficult, but
> to make everyone's lives - particularly participants' - easier. With a
> typical open source project on Github, there's so much tooling around the
> process people often think it doesn't exist, but there usually is some
> process. A contributor comes along and suggests a change, it's reviewed by
> the maintainers, and if approved, it's merged. If a new contributor turns
> up and sees a project hosted on Github, they know roughly how things are
> going to work.
>
> That's kind of what we have, except the "people who merge", and the
> "people who review" are different - they're the "XMPP Extensions Editor"
> and the "XMPP Council" respectively a lot of the time - for experimental
> XEPs, or process XEPs, it's different. When it's different is covered by
> XEP-0001, and what changes can be approved is also covered by XEP-0001.
> That is, in a nutshell, our process.
>
> But the idea is that a new participant in our standards ought to be able
> to read XEP-0001, and from that gain a set of expectations on how to
> contribute to documents and what will happen. Moreover, if Council (for
> example) do not follow this, they can be called out on it. Every now and
> then, people do try to insist that the XSF does something unusual with
> their favourite document, for reasons ranging from commercial
> considerations to deciding they want the document moved to another
> Standards Development Org that will do what they want. Having a defined
> process means both that the Council has a simple defence here, and that all
> the other participants - and that's you, if you're reading this - aren't
> going to be taken by surprise.
>
> That is not to say that our process is either perfect, nor immutable. I
> find it as irritating as anyone else when we find ourselves trapped by the
> process, or having to jump through hoops in order to satisfy it. Process
> should not be a stick with which to beat people. Our process should simply
> describe what we do - so sticking to it should be easy. If we can improve
> it, we should do so, and anyone - XSF Member or not - can suggest process
> improvements (such as simplifications), and ask the Board to approve them.
>
> So, "We'd like to move a XEP from Deferred to Obsolete" is not a
> suggestion that is intrinsically wrong, but one we cannot do. But if (in
> this case) Emmanuel wants this to be possible, it's possible to change
> things so we can. We've changed it recently for largely similar things.
>
> On the other hand, Jonas's slip-up can be resolved. In this case, Council
> were generally not worried, and offered a suggestion to Board. Board
> rejected it, and have insisted on a different resolution. And I'm delighted
> with the way this has worked out, even though Board disagreed with what
> Council (including myself) wanted to do.
>
> The real test of openness, fairness, and transparency in an organisation
> is when things go wrong. In this case - and many thanks to Jonas for
> providing the opportunity - I'm very comfortable that we passed that test.
>
> Dave.
>
> On Thu, 20 Dec 2018 at 20:27, Tedd Sterr  wrote:
>
>> http://logs.xmpp.org/council/2018-12-19/#16:00:41
>>
>> *1) Who's Here?*
>> Present: Jonas, Georg, Dave, Link
>> Fashionably late: Kev
>>
>> Dave asks if there is anything new to vote on - Jonas points to PR #727 (
>> https://github.com/xsf/xeps/pull/727); Georg would like to ask for an LC
>> on XEP-0410.
>>
>> [PR #727 moves three XEPs from Deferred to Obsolete, as they were
>> deferred long ago and appear to be no longer useful.]
>> Jonas thinks XEP-0008 should be made Active (it's historical), and
>> XEP-0051 can be obsoleted with a reference to the  stream
>> error, but has no idea about XEP-0038.
>> Dave doesn't think XEPs can be moved from Deferred to Obsolete; Jonas
>> concurs.
>> Link suggests skipping a few states in the path to Obsolete for XEPs that
>> will obviously no longer be needed; Dave says it would be possible to do:
>> Deferred → Experimental → Proposed → Rejected, with a well-placed Last Call.
>> Dave asks what Link is actually trying to achieve, and why Deferred is
>> not good enough - Link would like to sort the deferred XEPs into "no longer
>> needed" and "should be LC-ed"; Jonas likes that plan.
>> Link would like to eventually deprecate the Obsolete state; Dave says the
>> point of the state is to de-clutter Experimental. Jonas suggests focusing
>> more on saving those that might be useful.
>> Dave concludes that current process doesn't allow for this, and is
>> therefore not keen on voting on it. Link queries escalating the matter to
>> Board - Dave suggests putting it to 

Re: [Standards] NEW: XEP-0412 (XMPP Compliance Suites 2019)

[Guus der Kinderen]

Hi Jonas,

To clarify:

   - There is absolutely no indication that anyone tried to pressure anyone
   into doing anything. Board's comment can be seen as to wanting to prevent
   such leverage to become possible in the future, by establishing a precedent
   of keeping prematurely published XEPS published.
   - Board had another reason for wanting the prematurely published XEP to
   be retracted: by publishing a XEP, the XSF might (or even: "intends to")
   trigger third parties to start spending resources (on implementing the
   XEP). When a XEP is published by mistake, it is therefor important to
   reduce the risk of more people starting to base work off of it, by
   retracting it as soon as possible.

Thank you for flagging this, and act swiftly to rectify. Mistakes happen.
It's how they're followed up on that characterizes them.

Regards,

  Guus

On Thu, 20 Dec 2018 at 17:37, Dave Cridland  wrote:

> Hi Jonas,
>
> Thanks for sorting this out, and my apologies for the formal process hoops
> to jump through.
>
> I'm amazed this has never happened before, actually.
>
> Dave.
>
> On Thu, 20 Dec 2018 at 16:13, Jonas Schäfer  wrote:
>
>> Hi list,
>>
>> 
>> I published this specification (XEP-0412) ahead of time. The vote of
>> council
>> (which I am embarrassingly part of) has not yet completed.
>>
>> While the stance of Council (including the member who hasn’t voted yet
>> and me)
>> on this matter was to wait it out and deal with the issue of retraction
>> should
>> the vote be a -1, the Board has decided to prevent to set a precedent by
>> the
>> premature publication, which could be used by the Editor to exert
>> pressure on
>> the not-yet-voted Council members.
>>
>> I personally fully support the decision of the Board.
>>
>> I understand the delicacy of the situation especially since in this play,
>> I’m
>> both the Editor *and* the Author of the specification; I do not want to
>> be
>> seen as someone who would abuse any role like that, so I’m happy to
>> execute
>> the Board’s ruling.
>>
>> I’d also like to sincerely apologize especially to Kev whose vote I have
>> forgotten (actually I was 100% sure that everyone had voted, and only
>> while
>> checking results for other votes I came across the "on list" from Kev :()
>> and
>> to the community for the extra noise and possible temporary confusion and
>> misguidance due to the published compliance suites you had to endure. I’d
>> also
>> like to apologize for not bringing this matter up to Board immediately.
>>
>> The specification has been un-published and replaced with a tombstone XEP
>> (the
>> build is still in progress; the website will thus be updated shortly). It
>> will
>> stay a tombstone should Kevin decide to vote -1, and it will be replaced
>> with
>> the actual XEP again should Kevin decide to vote 1 or 0.
>> 
>>
>> kind regards,
>> Jonas___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Server status pages

[Guus der Kinderen]

I need to hurt my eyes to squint hard enough for this to fit in XEP-0157. I
don't have an alternative available, though.

 - Guus

On Mon, 3 Dec 2018 at 11:03, Matthew Wild  wrote:

> Hi all,
>
> I'd like to allow servers to advertise status pages to their users.
> See for example https://statut.jabberfr.org/
>
> This information could be cached by clients, and linked to in case of
> problems connecting, for example.
>
> The question is where and how to advertise it. Someone suggested it
> might fit into XEP-0157, as if you squint hard enough, it is a
> communication channel about the service. The link could also be a URL
> to a Twitter, Mastodon feed, or whatever.
>
> This is one possibility, there are others. Anyone have thoughts to
> contribute?
>
> Regards,
> Matthew
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Summit 23 (Brussels, Belgium) announcement

[Guus der Kinderen]

Hello,

The XMPP Standards Foundation (XSF) will hold its 23th XMPP Summit in
Brussels, Belgium, on Thursday January 31st and Friday February 1st 2019.
These are the two days preceding FOSDEM 2019.

The XSF invites you all to attend, and discuss all things XMPP!

If you're interested in attending, please make yourself known by filling
out your details on the wiki page for Summit 23 at
https://wiki.xmpp.org/web/Summit_23 (to edit the page, you'll need a wiki
account, which we'll happily provide for you. Find us either in the
j...@conference.jabber.org chatroom, or via the Summit mailing list).

Please note that, although we welcome everyone to join, you must announce
your attendance beforehand, as the venue is not publicly accessible (and we
need badges printed for you).

If you haven't already, make sure that you're signed up to the Summit
mailling list at https://mail.jabber.org/mailman/listinfo/summit

See you there! Regards,

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

Re: [Standards] UPDATED: XEP-0198 (Stream Management)

[Guus der Kinderen]

Changelog date is off by a year, I think?

On Fri, 6 Jul 2018 at 09:18, Jonas Wielicki  wrote:

> Version 1.5.3 of XEP-0198 (Stream Management) has been released.
>
> Abstract:
> This specification defines an XMPP protocol extension for active
> management of an XML stream between two XMPP entities, including
> features for stanza acknowledgements and stream resumption.
>
> Changelog:
> Improve the note about stream management counters in section 4.
> (fs/mw)
>
> URL: https://xmpp.org/extensions/xep-0198.html
>
> Note: The information in the XEP list at https://xmpp.org/extensions/
> is updated by a separate automated process and may be stale at the
> time this email is sent. The XEP documents linked herein are up-to-
> date.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] the meaning of "MUST be empty"

[Guus der Kinderen]

On Tue, 19 Jun 2018 at 13:47, Kevin Smith  wrote:

> On 19 Jun 2018, at 12:09, Bartłomiej Górny <
> bartlomiej.go...@erlang-solutions.com> wrote:
> >
> > Hi
> >
> > If a XEP states that an attribute "MUST be empty", does it mean that it:
> > a) must be present and have a value ""
> > b) must not be there
> > c) can be either of the two
> >
> > The question arose because of XEP-0313, which in point 5.1.2 says:
> >
> >"When sending out the archives to a requesting client,
> >the 'to' of the forwarded stanza MUST be empty"
> >
> > and then gives an example where forwarded stanzas have no 'to'
> attribute. We just hit a situation where there are conflicting
> implementations, and we want to sort it out The Right Way, hence the
> question.
>
> Sounds like we messed up the text, sorry. The right thing is to not
> include a to, rather than including a to=“” (which is illegal).
>
>
Is it (illegal)? It's valid in XML 1.0 and XML 1.1, if my Google skills are
not failing me. Differentiating between not having a to attribute, and
having a to attribute with an empty value seems needlessly complicated to
me.


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

Re: [Standards] the meaning of "MUST be empty"

[Guus der Kinderen]

I don't remember ever making use of a. I'd expect implementations to
generate b, but accept c.

On Tue, 19 Jun 2018, 13:11 Bartłomiej Górny, <
bartlomiej.go...@erlang-solutions.com> wrote:

> Hi
>
> If a XEP states that an attribute "MUST be empty", does it mean that it:
> a) must be present and have a value ""
> b) must not be there
> c) can be either of the two
>
> The question arose because of XEP-0313, which in point 5.1.2 says:
>
>  "When sending out the archives to a requesting client,
>  the 'to' of the forwarded stanza MUST be empty"
>
> and then gives an example where forwarded stanzas have no 'to'
> attribute. We just hit a situation where there are conflicting
> implementations, and we want to sort it out The Right Way, hence the
> question.
>
> BG
>
> --
> Leże, oglądam mecz, pije piwo, zagryzam czipsem i jeszcze głaszcze psa.
> Nagle wchodzi żona i awanturuje się, że nic nie robie.
>
> (piniol, bash.org.pl)
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

>
>  I'm curious as to what the concerns with the XSF offering anything that
> might be considered "legal advice" actually are.
>

1. Liability.
2. Giving the wrong advice.

On Fri, 25 May 2018 at 23:08, Dave Cridland  wrote:

> Since we're sitting on this for a bit, I'm curious as to what the concerns
> with the XSF offering anything that might be considered "legal advice"
> actually are.
>
> I'm aware there's always been a lot of "IANAL" around on mailing lists,
> but I'm not even clear if that's just a bit of folk-legal or if it has any
> useful effect either way.
>
> On the other hand, given that not only is the GDPR itself having
> implications beyond simply the EU, but the British Standards Institute
> seems to be leading a broad privacy standards effort at ISO, which they
> intend
>
> I think having detail of what server operators should consider when trying
> to align themselves with the GDPR is useful, and the XSF should be
> providing it.
>
> If we have to kick around some weasel wording to avoid it being seen as
> definitive legal advice (which the XSF is unable to offer), then we should
> figure that out.
>
> On 22 May 2018 at 18:19, Jonas Wielicki  wrote:
>
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: Best practices for GDPR compliant deployment of XMPP
>> Abstract:
>> This informational XEP provides information on deploying XMPP in way
>> that is compliant with the General Data Protection Regulation (GDPR)
>> of the European Union.
>>
>> URL: https://xmpp.org/extensions/inbox/gdpr.html
>>
>> The Council will decide in the next two weeks whether to accept this
>> proposal as an official XEP.
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

[Guus der Kinderen]

On 18 March 2018 at 18:56, Jonas Wielicki <jo...@wielicki.name> wrote:

> On Sonntag, 18. März 2018 18:48:49 CET Guus der Kinderen wrote:
> > Having implemented 0048 via 0223 earlier this week, I can only applaud an
> > effort of making the documentation easier to digest. Thanks for this!
> >
> > I am, however not sold on the idea of having a bookmark-per-item: what
> > problem is that solving, or what benefit does this give us?
>
> Two or more clients updating different bookmarks at the same time (or
> maybe at
> different times, but one had a network outage inbetween and can only
> actually
> perform the update at a later time). Currently, it requires a nasty loop
> [1]
> until convergence to make that work.
>
>
I didn't think of that. It does, however, seem like a very unlikely problem
to have occur. On top of that, I don't think that the new XEP fixes the
address when both clients are updating the same bookmark.


> > I appreciate
> > how it fits in nicely with the way how pubsub is designed - but in
> > practice, I suspect that one would easily work with entire sets of
> > bookmarks anyways. By not splitting up the bookmarks, we wouldn't need a
> > new namespace, and we can re-use the existing 0048/0049 data structure.
> > That will improve interoperability, and make adoption easier.
>
> We’ve been advocating this (split into items) move for quite a while and
> we’re
> happy to see that it’s happening now.
>
> > Unrelated: I'd like the XEP to have a "complete" example of a bookmark,
> one
> > that includes the room JID. Although the text is clear, having an example
> > like that will be a useful illustration.
>
> The text doesn’t seem to be that clear then; the idea is that the JID is in
> the pubsub item ID (§ 4.1) -- which also has the nice sideeffect of
> resolving
> the ambiguities which arise when multiple bookmarks for the same room with
> different nicknames exist.
>
>
For what it's worth, I did get that from the text. My point was that it'd
be helpful to have the pubsub details in an example.


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

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

[Guus der Kinderen]

Having implemented 0048 via 0223 earlier this week, I can only applaud an
effort of making the documentation easier to digest. Thanks for this!

I am, however not sold on the idea of having a bookmark-per-item: what
problem is that solving, or what benefit does this give us? I appreciate
how it fits in nicely with the way how pubsub is designed - but in
practice, I suspect that one would easily work with entire sets of
bookmarks anyways. By not splitting up the bookmarks, we wouldn't need a
new namespace, and we can re-use the existing 0048/0049 data structure.
That will improve interoperability, and make adoption easier.

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

  - Guus

On 18 March 2018 at 16:25, Sam Whited  wrote:

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

[Standards] Private Data storage discrepancy

[Guus der Kinderen]

Hello,

I'm working on migrating Bookmarks (
https://xmpp.org/extensions/xep-0048.html) from Private XML Storage (
https://xmpp.org/extensions/xep-0049.html) to PEP (
https://xmpp.org/extensions/xep-0223.html). I'm was surprised to find a
difference between the Pubsub node defined in 0048 example 3 (the published
item root element is 'storage', that itself contains 'conference') and
0233's example 3 (the published item root element is 'conference' directly,
without the wrapping 'storage'). I expected those two examples to have the
same structure. What's going on there?

Regards,

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

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Guus der Kinderen]

Primarily due to security concerns. There's a lot of discussion available
in the mail archive. This is a good place to start:
https://mail.jabber.org/pipermail/standards/2017-October/033546.html

On 7 March 2018 at 17:13, Kozlov Konstantin  wrote:

> I wonder, why this one was obsoleted?
> Yes, this XEP has its disadvantages, but almos all of modern clients do
> implement it and there is no XEP right now, which can substitute it.
>
>
>
> 28.02.2018, 21:24, "Jonas Wielicki (XSF Editor)" :
>
> Version 1.5.3 of XEP-0071 (XHTML-IM) has been released.
>
> Abstract:
> This specification defines an XHTML 1.0 Integration Set for use in
> exchanging instant messages that contain lightweight text markup. The
> protocol enables an XMPP entity to format a message using a small
> range of commonly-used HTML elements, attributes, and style properties
> that are suitable for use in instant messaging. The protocol also
> excludes HTML constructs that may introduce malware and other
> vulnerabilities (such as scripts and objects) for improved security.
>
> Changelog:
> Per a vote of the XMPP Council, advanced to Obsolete. (XEP Editor
> (ssw))
>
> URL: https://xmpp.org/extensions/xep-0071.html
>
> Note: The information in the XEP list at https://xmpp.org/extensions/
> is updated by a separate automated process and may be stale at the
> time this email is sent. The XEP documents linked herein are up-to-
> date.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Guus der Kinderen]

On 22 February 2018 at 12:34, Kevin Smith  wrote:

> On 21 Feb 2018, at 21:35, Ruslan N. Marchenko  wrote:
> >
> > Am Mittwoch, den 21.02.2018, 16:17 + schrieb Kevin Smith:
> >> On 21 Feb 2018, at 13:21, Jonas Wielicki  wrote:
> >>>
> >>> On Mittwoch, 21. Februar 2018 11:57:56 CET Kevin Smith wrote:
>  On 21 Feb 2018, at 09:41, Jonas Wielicki 
>  wrote:
> > On Mittwoch, 21. Februar 2018 10:32:37 CET Kevin Smith wrote:
> >> At first glance, its seems to me like this can only happen
> >> when an
> >> entity’s
> >> 198 support is broken in some way. If that’s the case, would
> >> we expect
> >> the
> >> same entity to reconnect and do the same thing again? If so,
> >> is it better
> >> to continually disconnect due to bad-h, reconnect, etc., or
> >> to do the
> >> best
> >> we can to keep the stream up?
> >
> > The entity shouldn’t be reconnecting after a stream error, so
> > the loop
> > you’re talking about won’t happen (unless the entity is also
> > broken in
> > other ways, but one can construct arbitrary failure modes if we
> > assume
> > that).
> 
>  I don’t think this is true.
> >>>
> >>> I meant to say resumption instead of reconnection, sorry.
> >>>
> >>> For resumption this is true I think. A stream which died with a
> >>> stream error
> >>> is properly closed (), thus all stream management
> >>> state is
> >>> discarded on both sides.
> >>
> >> For resumption it’s true, but reconnection was what I was talking
> >> about.
> >>
> >>
> >
> > Why would you adopt the *protocol* to the broken *implementation* in
> > the first place?
>
> While I’m not high-F on this, my reasoning is:
>
> For some reason we think that entities broken in this way are likely
> common enough to be worth discussion in the spec.
> If such things are likely, it makes sense to do what is best for the
> not-broken implementation and user experience.
> If an entity is broken in this way, it is likely to be persistently
> broken, and just reconnecting will result in the same error again.
> So to avoid continual reconnections, just treating it as an ack-all avoids
> the good entities getting continual disconnections, and users being unable
> to get messages through.
>
> But, as I say, not high-F.
>
>
Users not being able to get messages through, _without them realizing_ is
what caused me to suggest this change in the first place. For me, the
downside of that outweighs a potential server-sided issue with continuous
reconnects.

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

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Guus der Kinderen]

Thank you for all feedback.

The general consensus appears to be in favor of this change, but that a
stream error definition should be added.

None of the other RFC-6120-defined conditions appear to be fitting here, so
I suggest that `undefined-condition` is used.

Additionally, we should add an application-specific condition element. I
suggest to add a single `mismatch` element, qualified by the namespace as
defined for this feature in the XEP.

If we do more explicitly define the steam error, then it would be fitting
to also further specify the stream termination that's now defined in the
last lines of section 3:

Note that a client SHALL only make at most one attempt to enable stream
> management. If a server receives a second  element it SHOULD
> respond with a stream error, thus terminating the client connection.


What would be a fitting error condition here?

Lastly, section 5 defines another stream termination here:

If the former stream is resumed and the server still has the stream for the
> previously-identified session open at this time, the old stream SHOULD be
> terminated.


Is this intended to be a termination without stream error? That might cause
confusion in the client being terminated.

Regards,

  Guus

On 7 February 2018 at 20:57, Ruslan N. Marchenko <m...@ruff.mobi> wrote:

> Am Mittwoch, den 07.02.2018, 08:40 +0100 schrieb Guus der Kinderen:
>
>
> I propose that the XEP is updated with an instruction to, upon detection
> of an invalid acknowledgement, terminate the stream with stream error.
>
> Thoughts?
>
>
> I was always pretty sure this is actually de-facto behaviour. Ack
> non-existing stanza means SM is out of sync or there's stream injection -
> both non-recoverable and/or dangerous cases falling in SM misuse category.
> No harm making it explicit though.
>
> --RR
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Guus der Kinderen]

Hello,

XEP-0198 Stream Management relies on a stanza count that is being send as
an acknowledgement that a certain amount of session data has been received
(the 'h' value). The XEP does not specify what should happen if the
acknowledgement is off - when the remote entity appears to acknowledge data
that was never / not yet sent.

This situation was discussed briefly in the sidelines of the summit.
Terminating the stream came up as the suggested way to handle such a
situation. It is worth noting that such behavior is already allowable:
"misuse of stream management MAY result in termination of the stream." (but
this is not further specified in the XEP).

I propose that the XEP is updated with an instruction to, upon detection of
an invalid acknowledgement, terminate the stream with stream error.

Thoughts?

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

Re: [Standards] Proposal: Server selection for user-registration

[Guus der Kinderen]

We currently have a pre-existing central directories of XMPP domains at
https://xmpp.net/directory.php - the code powering the observatory is
available (the most up-to-date code is in Jonas' repo:
https://github.com/horazont/xmppoke-frontend-docker )

The upside of that project is that it's an established code base, publicly
available as open source and functionally already performs a variety of
checks against XMPP domains. Additionally, Jonas and the XSF iteam spent
quite some time to make it run in Docker, which making it easy for anyone
to run their own instance. The downside is that feature checks (and perhaps
an API to be used by clients?) still need to be put in.

0.02$

On 9 January 2018 at 07:39, Daniel Gultsch  wrote:

> Just do it.
> Some building blocks like the compliance tester and the uptime monitor
> (status.conversations.im) are already here. You just need to turn the
> compliance tester from a command line tool into a webservice.
> Worry about things like where to host later. It's more important to
> have the tools than to bikeshed about how to use them.
>
> cheers
> Daniel
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Guus der Kinderen]

On 29 November 2017 at 20:16, Jonas Wielicki  wrote:

> This message constitutes notice of a Last Call for comments on
> XEP-0363.
>
> Title: HTTP File Upload
> Abstract:
> This specification defines a protocol to request permissions from
> another entity to upload a file to a specific path on an HTTP server
> and at the same time receive a URL from which that file can later be
> downloaded again.
>
> URL: https://xmpp.org/extensions/xep-0363.html
>
> This Last Call begins today and shall end at the close of business on
> 2017-12-12.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
>
Yes


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


> 4. Do you have any security concerns related to this specification?
>
>
Perhaps warnings should be added that explicitly state that the TLS
configuration of the file transfer might differ from that of the XMPP
client connection, and that the receiving end might not want to
auto-display/execute data.


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


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

Re: [Standards] Proposed XMPP Extension: Styling

[Guus der Kinderen]

On a side-note: please try to keep discussions positive. Not only does that
make for a friendlier conversation, arguments are much more likely to be
taken into consideration if you don't start off by putting people off.


On 15 November 2017 at 08:45, Evgeny Khramtsov  wrote:

> Wed, 15 Nov 2017 08:48:42 +0100
> Jonas Wielicki  wrote:
>
> > That is in fact incorrect. The whole council needs to be convinced,
> > since voting is veto-based. A single "-1" counters a proposal.
>
> Oh, we have a hope
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Rename XEP status identifiers

[Guus der Kinderen]

Hello all,

Should we rename the status names that we use in XEPs? One of the recurring
criticisms about XMPP that I read is "Pretty-standard-feature XYZ has a XEP
that is only "experimental"! By doing some window dressing, we will improve
the perceived maturity and stability of the protocol.

Regards,

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

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

[Guus der Kinderen]

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

On 23 September 2017 at 14:58, 殷啟聰 | Kai-Chung Yan <seamli...@gmail.com>
wrote:

> According to the documentations of some XMPP servers (e.g. OpenFire and
> ejabberd), using TLS directly when connecting is described as "legacy",
> "deprecated" or "not recommended". Is this "legacy" connection method the
> same as the one described in this XEP? If so, is this XEP also encouraging
> direct TLS unlike those servers?
>
>
> Guus der Kinderen 於 2017年09月23日 02:08 寫道:
>
>
> Wait, what are we discussing again?
>>
>>
> We were discussing if I was fully, or completely right, of course. :-P
>
> Also, I again have to postpone my bikeshed-warming-party. It's not
> finished yet. Will let you know.
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

> Wait, what are we discussing again?
>
>
We were discussing if I was fully, or completely right, of course. :-P

Also, I again have to postpone my bikeshed-warming-party. It's not finished
yet. Will let you know.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

On 22 September 2017 at 19:15, Florian Schmaus <f...@geekplace.eu> wrote:

> On 22.09.2017 13:50, Guus der Kinderen wrote:
> > I suggest to improve the wording of this XEP by replacing the command
> > name "STARTTLS" with the technique name "Opportunistic TLS".
>
> I'm pretty sure STARTTLS is not the same as Opportunistic TLS. I also
> think that XEP-0368 does not explicitly talk about opportunistic TLS.
>

Wikipedia says it is: https://en.wikipedia.org/wiki/StartTLS
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

On 22 September 2017 at 15:58, Peter Saint-Andre <stpe...@stpeter.im> wrote:

> On 9/22/17 5:50 AM, Guus der Kinderen wrote:
> > I suggest to improve the wording of this XEP by replacing the command
> > name "STARTTLS" with the technique name "Opportunistic TLS".
>
> "Opportunistic Security" usually means encryption without authentication:
>
> https://tools.ietf.org/html/rfc7435
>
>
To me, that wouldn't be a problem. "Security" is rather generic, distinct
from the very specific "TLS".

I've also seen "Opportunistic Encryption" being used, described as
"Opportunistic encryption (OE) refers to any system that, when connecting
to another system, attempts to encrypt the communications channel,
otherwise falling back to unencrypted communications."

I still favor "Opportunistic TLS" over "STARTTLS" in this text - but adding
a clear description to the glossary would be good.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

I suggest to improve the wording of this XEP by replacing the command name
"STARTTLS" with the technique name "Opportunistic TLS". This way, we're not
comparing apples to oranges, when mentioning both in the same text.

To retain clarity, this term should be added to the glossary, with a
mention of STARTTLS.

I didn't invent the term, by the way: Wikipedia redirects to a page named
"Opportunistic TLS" from the "STARTTLS" page.

On 19 September 2017 at 18:04, Jonas Wielicki  wrote:

> Dear list,
>
> With my XEP Editor hat on, we’d like to issue a Call for Experience for
> XEP-0368. This is the step taken before proposing advancement of a XEP to
> Final status to Council.
>
>
> During the Call for Experience, please answer the following questions:
>
> 1. What software has XEP-0368 implemented? Please note that the protocol
> must be implemented in at least two separate codebases (at least one of
> which must be free or open-source software) in order to advance from
> Draft to Final.
>
> 2. Have developers experienced any problems with the protocol as defined
> in XEP-0368? If so, please describe the problems and, if possible,
> suggested solutions.
>
> 3. Is the text of XEP-0368 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
> developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.
>
> If you have any comments about advancing XEP-0368 from Draft to Final,
> please provide them by the close of business on Tuesday, October 3rd,
> 2017. After the Call for Experience, this XEP might undergo revisions to
> address feedback received, after which it will be presented to the XMPP
> Council for voting to a status of Final.
>
>
> You can review the specification here:
>
> https://www.xmpp.org/extensions/xep-0368.html
>
> Please send all feedback to the standards@xmpp.org discussion list.
>
> Thanks!
>
> Jonas
>
> P.S.: Procedural note: I’m not entirely clear on what is allowed to
> trigger a
> CFE (I don’t think that’s spelled out in XEP-0001). In this specific case,
> the
> author asked for it.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Meetup during T-DOSE in Eindhoven (NL) in November

[Guus der Kinderen]

Hi all,

A quick update on T-DOSE 2017.

As the amount of responses to Tim's suggestion to have a meetup was very
low, we've opted to not follow-up on the offer of a dedicated room for
XSF/XMPP. We did, however, request a booth. If you're interested in joining
us there, please let us know (either here, or at
https://wiki.xmpp.org/web/T-DOSE_2017 )

Regards,

  Guus

On 22 August 2017 at 09:59, Timothée Jaussoin <edhe...@movim.eu> wrote:

> Hello everyone,
>
> I've created a page on the Wiki for the project
> https://wiki.xmpp.org/web/T-DOSE_2017.
> If you are interested to come, do a conference, a XMPP meetup or something
> related, please put it on this page :)
>
> Regards,
>
> Timothée
>
> Le lundi 31 juillet 2017 à 12:18 +0200, Guus der Kinderen a écrit :
> > Hi Timothée,
> >
> > Thanks for taking the time to organize this! I'd certainly be interested
> in attending.
> >
> > As for XSF support: what exactly do you need? This year, the XSF created
> the SCAM (somethingsometing, Conferences And Meetups)
> > workgroup (of which I may or may not be a part). I am not aware of any
> activity of that workgroup other than its inception. This
> > event might be a good first event to get SCAM-things going though.
> >
> > Regards,
> >
> >   Guus
> >
> > On 30 July 2017 at 22:50, Timothée Jaussoin <edhe...@movim.eu> wrote:
> > > Hi everyone,
> > >
> > > I'm currently in contact with an organizer of the T-DOSE event. For
> those that don't know T-DOSE.
> > >
> > > T-DOSE is a free and yearly event held in The Netherlands to
> promote use and development of Open Source Software. During this
> > > event
> > > Open Source projects, developers and visitors can exchange ideas
> and knowledge. This years event will be held at the Fontys
> > > University of Applied Science in Eindhoven on November 18 and 19.
> > >
> > > More info here http://www.t-dose.org/.
> > >
> > > I think that it could be a nice opportunity to meet-up there and maybe
> have conferences to promote the XMPP protocol :)
> > > The organizers told me that they have classrooms available where we
> could talk and that they are open for conferences proposal
> > > (deadline September 30).
> > >
> > > For those that are interested to take part of it and help with the
> organization do not hesitate to answer that mail.
> > > I don't have a clear idea how we organize our participation into such
> event in the XSF, should I create a Wiki page? Is it possible
> > > to
> > > put it in the agenda for the next meeting?
> > >
> > > On my side I can help with the communication with the T-DOSE team, I'm
> also interested to propose a conference (around
> > > Movim/social-
> > > networking on XMPP…) and participate in discussion if we meet-up to
> talk about the current XEP in progress.
> > >
> > > Kind regards,
> > >
> > > Timothée Jaussoin
> > > ___
> > > Standards mailing list
> > > Info: https://mail.jabber.org/mailman/listinfo/standards
> > > Unsubscribe: standards-unsubscr...@xmpp.org
> > > ___
> > >
> >
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Any XMPP Extension for sharing JIDs?

[Guus der Kinderen]

Hello,

There are several ways that you could go about this. There is extended
stanza addressing, "https://xmpp.org/extensions/xep-0033.html which lets
you add additional addresses to a stanza. It's very bare-boned though. A
more elaborate option would revolve around creating multi-user chat rooms,
as defined in https://xmpp.org/extensions/xep-0045.html. A more specific,
support desk oriented specification exists for that in the form of
https://xmpp.org/extensions/xep-0142.html

Hope this helps!

Regards,

  Guus

On 18 September 2017 at 15:19, vaibhav singh 
wrote:

> Hi,
>
> Today I was having a chat with a colleague who is working on certain XMPP
> related usecases. As neither he nor I am not much familiar with XMPP we
> need help with a particular usecase he is stuck at:
>
> *Usecase: Customer Support implementation requires messages to and from
> one JID (think "c...@abc.com ") to be sent to/received from
> multiple support guys (think "s...@abc.com ", "s...@abc.com
> " etc), all of whom are registered users on an XMPP server,
> with their own separate JIDs.*
>
> Any message to "custo...@abc.com" should be redirected to one and only
> one of the support guys, and not to anyone else.
>
> I found *XEP-0280: Message Carbons* which seemed promising but
> unfortunately  deals with one user having multiple resources, and (at a
> first glance) seems to naively broadcast the same message to all resources
> of one user.
>
> Is there any RFC/XEP which my colleague could refer to? Is it even
> possible? If not, how do you propose we target this usecase?
>
> Regards,
> Vaibhav Singh
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

Not all blocking comes from SPAM reports. XEP-0191 isn't duplicated by
creating a SPAM report, as it also allows you to block entities for any
other reason (annoying automated messages, in-laws, etc).

As for delivery: at the very least, you can do the same as what the current
XEP tells you to do: report it to the server that manages your blocklist.
Furthermore, you *can* report it to any entity that reports the capability.
Maybe I'm missing the point that you're trying to make here?

As for modern/popular UIs. These were the first three I had open (yes, I
should get back to work, I know):

   - GMail gives me a button for spam reporting, but a distinct (and more
   elaborate) "Filters and Blocked Addresses" settings panel.
   - Facebook gives two distinct options: "Block" and "Report"
   - Twitter gives me three distinct options: "Mute", "Block" and "Report"

I'm all for a single report-spam-and-dont-get-any-from-that-jid-anymore,
but I don't feel that we should require this to be built on XEP-0191.

On 12 September 2017 at 13:35, Matthew Wild <mwi...@gmail.com> wrote:

> On 12 September 2017 at 12:10, Guus der Kinderen
> <guus.der.kinde...@gmail.com> wrote:
> > I'd much more prefer a solution where spam is reported (as a stand-alone
> > action, not embedded in a block), with an implementation guideline that
> > reads something like "Upon receiving a report, the server SHOULD ensure
> that
> > the reporter does not receive any more data from the reported JID" (but
> then
> > in better XEP-speak). That text could even suggest that a block / privacy
> > list entry is made on behalf of the reporting entity.
>
> But now the client doesn't know if it needs to also send a blocking
> request to the server, or if this is going to happen automatically.
>
> Reasons not to make spam reporting separate:
>
>   - If we always make it block JIDs, we're essentially duplicating
> (and obsoleting) XEP-0191 for one specific use-case. Needless and
> confusing XEP overlap.
>   - Ambiguity as to where the spam reports should go (we've been down
> this road before - send them to the originating server?)
>   - New (but overlapping) protocol for clients to implement
>   - The separation will encourage implementations to show separate UI
> actions with ambiguous consequences, even though are both "blocking"
> at the end of the day.
>
> Reasons to do combined block-and-report:
>
>   - Because why wouldn't you want to block a spammer?
>   - All other popular/modern communication systems work this way from
> the user's perspective, and it's what they would expect
>   - The annotation is useful information to the server, but it's not
> essential. Clients don't *have* to include it.
>   - If they do include it, it's a nice atomic operation.
>
> Reasons to base this on XEP-0191:
>
>   - Already implemented in clients and servers
>   - Spam annotation is optional for clients, basic blocking will
> always work with no changes to client or server.
>   - Servers will ignore the annotation if they don't understand it
>   - No ambiguity about whether a spam report also blocks. It's a
> blocking request with optional report, not a report with optional
> block.
>
> Reasons why we need spam reporting at all:
>
>   - As many have mentioned, blocking individual spammer JIDs is
> futile, but reports will allow the server to gain insight into what
> spam is slipping through,
>  which may be fed back into $algorithms and help prevent more spam
> from reaching more users.
>
> Spam reporting is by no means the thing that will end all spam, but
> it's an essential component.
>
> Regards,
> Matthew
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

Although I agree that not receiving messages from the reported entity is a
good thing. I'm still not comfortable with embedding the spam-reporting in
blocking functionality.

I'd much more prefer a solution where spam is reported (as a stand-alone
action, not embedded in a block), with an implementation guideline that
reads something like "Upon receiving a report, the server SHOULD ensure
that the reporter does not receive any more data from the reported JID"
(but then in better XEP-speak). That text could even suggest that a block /
privacy list entry is made on behalf of the reporting entity.

You'd still not have the inconvenience of needing two queries, while you
keep the XEP more open to processing the report in any other way than only
blocking the reported JID - which in my opinion is under-utilizing the
potential power of this XEP.

By not tying this XEP to Blocking, the XEP becomes even easier to
implement, but also more versatile. As a slightly embarrassing, but
truthful, illustration: if this XEP would not have been dependent on
Blocking, it would now already be in Openfire (I tried, but failed, as the
privacy list implementation in Openfire is too complex to easily integrate
this).


On 12 September 2017 at 12:11, Daniel Gultsch  wrote:

> I have implemented the XEP in Conversations and find it very useful.
>
> I actually like the bundling with the blocking XEP for two reasons.
>
> 1) 'Reporting' a JID comes at a cost of not being able to receive
> messages from that JID again. Yes it is reversible and yes this
> doesn't protect us from scripts reporting arbitrary jids but it does
> create some inhibition for the casual user. (Unblocking is at least
> some clicks away in Conversations). => Bundling it with blocking will
> reduce the noise.
> 2) By bundling it with blocking we 'force' a consistent UI among
> clients. Clients don't have to offer two different actions for
> blocking and reporting. Instead reporting is just another checkbox in
> the block dialog. Yes; if those are two separate IQ commands I *can*
> use the same bundled UI but I don't have to.
>
> Re: What Dave said about not bothering to block spammers; a) when all
> clients bundle the UI there is no cost for blocking b) especially
> domain blocking can be rather useful - I've personally blocked a
> couple of 'weird' domains under the assumption that I will never ever
> receive legitimate message from that domain.
>
> cheers
> Daniel
>
>
> 2017-09-11 19:13 GMT+02:00 Jonas Wielicki :
> > XEP-0377 (Spam Reporting) has been Deferred because of inactivity.
> >
> > Abstract:
> > This document specifies a mechanism by which users can report spam and
> > other abuse to a server operator or other spam service.
> >
> > URL: https://xmpp.org/extensions/xep-0377.html
> >
> > If and when a new revision of this XEP is published, its status will
> > be changed back to Experimental.
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

Blocking Reason and Spam Reporting 2.0 could happily coexist. :-)

On 11 Sep 2017 23:32, "Sam Whited"  wrote:

> On Mon, Sep 11, 2017, at 16:29, Evgeny Khramtsov wrote:
> > Let me answer. Because he thinks that those two actions should be
> > always performed together. But in this case why do we need to have a
> > spam reporting mechanism? Let's assume that the blocked person is
> > always a spammer.
>
> Maybe this should hav been called "blocking reason". The reason for a
> block might not always be spam, but if it is a spam report you probably
> always want it to result in a block.
>
> —Sam
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

I'm not arguing that the XEP should define anything but the payload (and
how entities do the initial reporting to their domain).

Although there's no harm in blocking the sender of the spam that you
reported, tying the two XEPs together implies that there are no other ways
to prevent the spam after the report.

To draw a parallel: when I mark an email as spam, I don't get a new inbound
mail filter rule. I'm depending on my service provider to ensure that I,
but perhaps also others, won't be bothered by the reported spam.

I'd propose to modify this XEP a little to do only pretty basic reporting
(to allow an end-user to send in a spam report) and have some
recommendations on what implementations could do with such reports
(blocking, sharing, what not), but leave the details of those actions to be
described in XEPs.


On 11 September 2017 at 22:32, Sam Whited <s...@samwhited.com> wrote:

> On Mon, Sep 11, 2017, at 15:29, Guus der Kinderen wrote:
> > I'm not sure if the "reporting" bit should automatically go hand in hand
> > with "blocking" specifically. There might be value in defining an entity
> > that simply just receives spam reports. Obviously, end-users generally
> > report spam because they want it to stop, but the goal of reporting could
> > be broader. I'd not be opposed to a XEP that does just that: manage spam
> > reports. The blocking bit is a logical extension to that, but there might
> > be other extensions: things like analysis, and reports sharing with
> > trusted
> > other parties, etc.
>
> That's fair, and maybe you could reuse the same payload for that, but I
> don't think this XEP should be expanded to cover anything else like
> report sharing. It's just about sending the report to the server in the
> first place. I don't see why you'd want to report spam without also
> blocking the sender personally.
>
> —Sam
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

I'm not sure if the "reporting" bit should automatically go hand in hand
with "blocking" specifically. There might be value in defining an entity
that simply just receives spam reports. Obviously, end-users generally
report spam because they want it to stop, but the goal of reporting could
be broader. I'd not be opposed to a XEP that does just that: manage spam
reports. The blocking bit is a logical extension to that, but there might
be other extensions: things like analysis, and reports sharing with trusted
other parties, etc.



On 11 September 2017 at 22:24, Sam Whited <s...@samwhited.com> wrote:

> On Mon, Sep 11, 2017, at 15:21, Guus der Kinderen wrote:
> > The integration with block is an optional part of the XEP, isn't it? I'm
> > reading it as: spam can be reported to any entity that advertises
> > support,
> > and could be inlined with Block if/when desired.
>
> Right now the only mechanism for reporting is the blocking command.
> However, the payload was described in such a way
> that it could be reusable if we wanted it to have its own special IQ
> later.
>
> In retrospect this flexibility feels poor to me; let's just have one way
> to do things (which should be an extension of the blocking command,
> IMO).
>
> —Sam
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

The integration with block is an optional part of the XEP, isn't it? I'm
reading it as: spam can be reported to any entity that advertises support,
and could be inlined with Block if/when desired.

On 11 September 2017 at 21:56, Evgeny Khramtsov  wrote:

> Mon, 11 Sep 2017 12:32:09 -0500
> Sam Whited  wrote:
>
> > Is there anything missing you think a spam reporting XEP must do? Was
> > your implementation experience (clients and servers) smooth? Did you
> > find any part of using it especially painful? How are you using it and
> > is the data it provides you useful or should more information be
> > attatched? etc.
>
> I actually reported the issue here:
> https://mail.jabber.org/pipermail/standards/2017-January/031883.html
>
> TL;DR: I don't like the inclusion of  element inside 
> element and, thus, will not implement it in such form. There should be
> a separate request for blocking.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] HTTP-Upload: Content-based slots

[Guus der Kinderen]

Clearly, benefits, but I do wonder what can of worms this opens with
regards to confidentiality. "Wait, someone else uploaded this?"

There is also talks about being able to update content (which I personally
dislike) - but your proposal adds quite a bit of complexity there too.

>From a storage perspective, the component can de-dupe content like you
propose, without this being visible to the end-user. That would not prevent
the retransmission of the same data though.

On 8 September 2017 at 12:05, Remko Tronçon  wrote:

> Hi,
>
> A server may want to provide optimized write-once storage of files that
> stores data based on hashes of file contents (such that identical files are
> only stored once, and that filenames are opaque). In this light, I was
> wondering whether the following extensions to XEP-0363 would make sense:
>
> - Provide a hash of the contents in the , such that the server
> can make decisions on upload slot response based on the hash (e.g. give a
> response that this file has already been uploaded).
> - The ability to omit the  from the slot response, and have it be
> returned as the HTTP PUT response, such that the server can delay deciding
> what the GET URL will be after it has seen the contents).
>
> thanks,
> Remko
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Permanent slots for HTTP Upload

[Guus der Kinderen]

I didn't mean to suggest advocating a retention period, but a policy:
permanent or temporary - not an explicit period. This would allow clients
to request a specific policy, which can be handy. The server-sided
complexity should be minimal - more so if you allow servers to offer just
one of the policies.

I'm a fan of not overwriting a slot at all, but have the HTTP resource be
completely static. That keeps things simple, from a caching and acces
control mechanism. When an avatar (or $thing) changes, I think I'd prefer
that the reference to the data changes too.

On 8 September 2017 at 11:46, Daniel Gultsch <dan...@gultsch.de> wrote:

> 2017-09-08 11:04 GMT+02:00 Guus der Kinderen <guus.der.kinde...@gmail.com
> >:
> > Perhaps it'd be sensible to always add a reference to the desired
> retention
> > policy - also for temporary slots. Perhaps the server should answer with
> the
> > applied policy too?
>
>
> I see your point. However there are two potential problems with it.
> Just specifying the retention period doesn't provide a way to easily
> overwrite the previous avatar (or $thing). And server developers need
> to come with a way to store the desired retention period.
>
> But maybe we don't need that overwrite feature but instead put a lower
> overall storage space limit on files that do not have a retention
> period.
>
> cheers
> Daniel
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Permanent slots for HTTP Upload

[Guus der Kinderen]

Hi Daniel,

Perhaps it'd be sensible to always add a reference to the desired retention
policy - also for temporary slots. Perhaps the server should answer with
the applied policy too?

Regards,

  Guus

On 8 September 2017 at 10:58, Daniel Gultsch  wrote:

> Hi all,
>
> when I first came up with HTTP Upload it was intended to also provide
> storage space for avatars and other permanent and public information.
> The introduction even mentions this.
>
> However most servers currently have rather low retention periods of 10
> days or 30 days (which is fair). Uploading an avatar for example under
> those conditions however isn't very feasible.
>
> That's why I propose to add the ability to optionally request slots
> that are permanent.
> Those permanent slots would have multiple types (avatar,...) and would
> always overwrite each other.
>
> Syntax would probably look something like this.
>
> 
>
> But I have a few questions:
>
> Do you think these types should be registered?
> Should we use types at all? Or rather have some other limitation on
> permanent slots? (Like user can only have 10? And old ones will always
> be overwritten)
>
> cheers
> Daniel
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Jingle Encrypted Transports

[Guus der Kinderen]

On 31 August 2017 at 15:37, Peter Saint-Andre  wrote:

> On 8/31/17 1:59 AM, Dave Cridland wrote:
> > On 30 August 2017 at 21:32, Daniel Gultsch  wrote:
> >> 2017-08-30 22:10 GMT+02:00 Paul Schaub :
> >>> First things first: My intention for submitting JET to the XSF inbox
> was
> >>> to get some comments and first feedback in order to discover caveats
> and
> >>> pitfalls in the protocol.
> >>> By no means I'd consider JET ready to be implemented or accepted :D
> >>
> >> OK. Fair enough. I think what people usually do at this stage is
> >> render the XEP themselves, put it up somewhere and show it around to
> >> get some feedback. That way you don't trigger council action and it is
> >> way easier to make changes because you don't have to go through the
> >> editor.
> >>
> >
> > This is getting a bit meta, but the reason I really dislike that is
> > that you're asking people to work on protocol stuff outside the IPR
> > policy of the XSF. This exposes people implementing, or discussing, to
> > all sorts of legal shenanigans that are somewhat mitigated by the
> > copyright assignment in submission.
> >
> > If there's something preventing this, we really need to fix it.
>
> There is: the Council blocking publication of XEPs. Publish the thing,
> get it into XSF processes, and work on the spec in the right way. Ship
> and iterate!
>
> Which has been improved upon greatly in the past few weeks! I'm hoping
that we can keep that up, and improve where needed.


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

Re: [Standards] Call for participation for a XMPP-based EU Funded project on data portability

[Guus der Kinderen]

I think it'd be interesting to have XMPP be used as an EU standard for data
portability (or for any other purpose, for that matter). That sounds like a
good opportunity to further improve and promote the application of XMPP.
I'm hopeful that the Board will act on this. I'm certainly interested in
contributing to the effort.

 - Guus

On 10 August 2017 at 11:57, edhelas  wrote:

> Hi everyone,
>
> I already talked with some of you about a really interesting project that
> could involve people from the XMPP community or the XSF itself. I really
> think that this project can brings interest on the XMPP protocol regarding
> data portability within the European Union and can boost its deployment in
> related infrastructures and services.
>
> Here is more details about it, if you are interested, please answer this
> message (or send me a message directly) I'll put you in contact with the
> responsible of the project.
>
> *What we are applying for?*
> „Cybersecurity PPP: privacy, data protection, digital identities“ under
> „Horizon 2020“, look up at: http://ec.europa.eu/research/
> participants/portal/desktop/en/opportunities/h2020/topics/ds-08-2017.html
> The call at 24th of August 2017.
>
> *What we are planing to do?*
> We are planning to develop a best practice implementation of the new user
> right to data portability (Art. 20 GDPR) based on XMPP within a project
> duration of 24 months.
>
> *What we are searching for?*
> We are searching for a company within the EU that is offering XMPP-based
> services such as IM, video conference system, IoT etc. to their customers
> and that would like to participate in a 24-months project that is funded by
> the European Union. We are searching for a company that wants to
> participate especially in the designing the architecture, in implementing
> and evaluating as well as being in contact with the relevant
> standardization such as XSF. The minimum participation should be 12 person
> months within the 24-months project (= 1 person works 50% of it´s time on
> the project, 2 persons work 25% of their time for the project etc.), the
> maximum participation should be 24 person months.
>
> Pro: The proposal is almost done. The company we are searching for
> therefore does not need to participate much in the proposal (we only need
> you to register with the EU Horizon 2020 and send us a description of your
> expertise and planned work). So its minimal work for potentially a maximum
> outcome of being funded 24 months.
>
> Con: We need your final decision until 15th of August.
>
> *What else are we searching for?*
> We would be interested in the XSF, as an organization itself, to join our
> project´s External Advisory Board. The EAB would meet twice within the
> projects duration to discuss the main ideas and outcome of the project. The
> travel costs of one XSF-member (hotel and plane) to those two workshops can
> be funded.
>
> Kind regards,
>
> Timothée Jaussoin
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Meetup during T-DOSE in Eindhoven (NL) in November

[Guus der Kinderen]

Hi Timothée,

Thanks for taking the time to organize this! I'd certainly be interested in
attending.

As for XSF support: what exactly do you need? This year, the XSF created
the SCAM (somethingsometing, Conferences And Meetups) workgroup (of which I
may or may not be a part). I am not aware of any activity of that workgroup
other than its inception. This event might be a good first event to get
SCAM-things going though.

Regards,

  Guus

On 30 July 2017 at 22:50, Timothée Jaussoin  wrote:

> Hi everyone,
>
> I'm currently in contact with an organizer of the T-DOSE event. For those
> that don't know T-DOSE.
>
> T-DOSE is a free and yearly event held in The Netherlands to promote
> use and development of Open Source Software. During this event
> Open Source projects, developers and visitors can exchange ideas and
> knowledge. This years event will be held at the Fontys
> University of Applied Science in Eindhoven on November 18 and 19.
>
> More info here http://www.t-dose.org/.
>
> I think that it could be a nice opportunity to meet-up there and maybe
> have conferences to promote the XMPP protocol :)
> The organizers told me that they have classrooms available where we could
> talk and that they are open for conferences proposal
> (deadline September 30).
>
> For those that are interested to take part of it and help with the
> organization do not hesitate to answer that mail.
> I don't have a clear idea how we organize our participation into such
> event in the XSF, should I create a Wiki page? Is it possible to
> put it in the agenda for the next meeting?
>
> On my side I can help with the communication with the T-DOSE team, I'm
> also interested to propose a conference (around Movim/social-
> networking on XMPP…) and participate in discussion if we meet-up to talk
> about the current XEP in progress.
>
> Kind regards,
>
> Timothée Jaussoin
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Password-protecting a MUC room

[Guus der Kinderen]

XEP-0045  defines two
`room_config` fields that relate to the password protection of a room:

  
  

Arguably, setting the room password implies that a user wants the the room
to be password protected.

What is the purpose of having two fields? Should setting the latter imply
that server-sided, the former is switched to 'true'?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP Authors

[Guus der Kinderen]

I'm not dead set against defining "previous authors". The only disadvantage
that I see is introducing more complexity to the editorial process. If that
is needed to resolve issues, legal or otherwise, we should accept that.

On 9 June 2017 at 12:41, Dave Cridland <d...@cridland.net> wrote:

> On 9 June 2017 at 08:49, Guus der Kinderen <guus.der.kinde...@gmail.com>
> wrote:
> > You're making sense to me (which appears to be a habit of yours
> *hattip*).
> >
> > Dave's original question was if he should propose a policy change to the
> > Board. Although Dave certainly has a keen perspective of things, I think
> he
> > falls in the "engineer" category, more than in the "legal counsel"
> category.
> > Apologies to Dave if I sell him short here. Perhaps it'd be good to take
> one
> > step back, and propose that the Board finds legal advise on the subject.
> We
> > could look at larger standards development organizations, as Peter
> > suggested. Another option would be to reserve a certain amount of money
> and
> > seek legal counsel of our own. Also, some of our larger sponsors might
> have
> > inhouse legal departments. Perhaps they could help out.
> >
>
> I am, indeed, not any kind of lawyer.
>
> However, I don't think this is particularly contentious. We have lots
> of documents for which one of the "Authors" hasn't made any input for
> several revisions. I see three cases for moving Authors to a "Previous
> Authors" section:
>
> a) This legal issue, which might expose authors and their employers.
> By clearly marking that an author is not current, it should address
> the concerns of (for example) Cisco's legal department.
> b) The case where an Author discovers their name still against a XEP
> and is concerned that the XEP misrepresents their views. I believe we
> have had such cases, and although obviously Authors can already
> request their removal in entirety, this also removes all
> acknowledgement for previous hard work.
> c) The case where Authors are simply unresponsive to concrete
> proposals and stall the standards process. While Council can again
> remove an Author entirely, this often seems like a nuclear option - as
> if Council is punishing, rather than simply moving things along.
>
> I see, on the other hand, no advantage to *not* having a Previous
> Authors section which properly acknowledges those who have put
> considerable effort into the document. I'm also happy to list these at
> the top of the document, maybe just like:
>
> Authors: Peter Saint-Andre, Dave Cridland (Previous)
>
> Dave.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP Authors

[Guus der Kinderen]

You're making sense to me (which appears to be a habit of yours *hattip*).

Dave's original question was if he should propose a policy change to the
Board. Although Dave certainly has a keen perspective of things, I think he
falls in the "engineer" category, more than in the "legal counsel"
category. Apologies to Dave if I sell him short here. Perhaps it'd be good
to take one step back, and propose that the Board finds legal advise on the
subject. We could look at larger standards development organizations, as
Peter suggested. Another option would be to reserve a certain amount of
money and seek legal counsel of our own. Also, some of our larger sponsors
might have inhouse legal departments. Perhaps they could help out.

On 9 June 2017 at 00:52, Peter Saint-Andre <stpe...@stpeter.im> wrote:

> Well...
>
> First, the XSF does not currently have legal counsel. Engineers
> typically aren't good at devising solutions to legal problems. It might
> be advisable to see how larger standards development organizations (such
> as the IETF and W3C) deal with this problem before we jump to conclusions.
>
> Second, this problem applies to authors whose employers are tempting
> targets for litigation. That's certainly the case with the company
> (Cisco) referenced in the WebRTC-PC issue mentioned in the original
> message. Certain XEP authors happen to have been employees of that same
> company (me, Joe Hildebrand, and Matt Miller foremost among them)
> although we're not employed there any longer.
>
> Third, this gets complicated very quickly because of specification
> versioning. In the IETF, RFCs never change so you could know that (say)
> I was employed at Cisco when RFC 6120 was published but not when 6120bis
> is published (if we decided to work on that spec). When you have a
> "living standard" then those assurances aren't in place.
>
> Fourth, if you're a spec author and you (or your company) are worried
> about patent litigation, then it's incumbent upon you to pay attention.
> I'm not convinced that it's the SDO's job to protect you from yourself.
> My sense of the WebRTC-PC issue is that the spec author involved is very
> busy and wasn't necessarily paying attention all the time. The solution
> is to pay attention or remove yourself from the authoring team.
>
> Peter
>
> On 6/8/17 4:16 PM, Guus der Kinderen wrote:
> > I am the first to admit that I have next to no legal knowledge, and I'm
> > not familiar with the background other than reading the comment that
> > Dave linked to, but: this feels like an overreaction to me. Because
> > (American - how does this apply to other countries?) juries assume
> > things, we need to consider making these changes? Isn't that to
> preemptive?
> >
> > On 8 Jun 2017 23:52, "Peter Saint-Andre" <stpe...@stpeter.im
> > <mailto:stpe...@stpeter.im>> wrote:
> >
> > Sadly, I think this is necessary.
> >
> > On 6/8/17 3:08 PM, Dave Cridland wrote:
> > > Folks,
> > >
> > > I came across an interesting case recently where a listed author
> of an
> > > open standard was presumed to know the contents of the
> specification
> > > fully - that is, as if they had written every word. Moreover, by
> > > inference so was their employer. This came up in an IPR court case.
> > >
> > > The (very high) level detail is here:
> > >
> > > https://github.com/w3c/webrtc-pc/issues/942#issuecomment-277034696
> > <https://github.com/w3c/webrtc-pc/issues/942#issuecomment-277034696>
> > >
> > > I'm considering advising Board that we should address this by
> > > instituting a policy whereby changes to XEPs result in all listed
> > > authors being notified (a PR will do, I imagine), and those who do
> not
> > > respond within a reasonable time (hand-wave, hand-wave) must be
> > > de-listed and moved to a "Previous Authors" section of the XEP.
> > >
> > > Note that this is *NOT* intended as a punishment for unresponsive
> > > authors, hence the "Previous Authors" section - it's to protect
> > > authors and their employers from legal action.
> > >
> > > I have to admit I'm surprised that such legal considerations exist,
> > > but the central argument - that if your name is on a document,
> you're
> > > presumed to know what it contains - seems sufficiently intuitive
> that
> > > we should take notice.
> > >
> > > Comments?
> > >
> > > Dave.
> >
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP Authors

[Guus der Kinderen]

I am the first to admit that I have next to no legal knowledge, and I'm not
familiar with the background other than reading the comment that Dave
linked to, but: this feels like an overreaction to me. Because (American -
how does this apply to other countries?) juries assume things, we need to
consider making these changes? Isn't that to preemptive?

On 8 Jun 2017 23:52, "Peter Saint-Andre"  wrote:

> Sadly, I think this is necessary.
>
> On 6/8/17 3:08 PM, Dave Cridland wrote:
> > Folks,
> >
> > I came across an interesting case recently where a listed author of an
> > open standard was presumed to know the contents of the specification
> > fully - that is, as if they had written every word. Moreover, by
> > inference so was their employer. This came up in an IPR court case.
> >
> > The (very high) level detail is here:
> >
> > https://github.com/w3c/webrtc-pc/issues/942#issuecomment-277034696
> >
> > I'm considering advising Board that we should address this by
> > instituting a policy whereby changes to XEPs result in all listed
> > authors being notified (a PR will do, I imagine), and those who do not
> > respond within a reasonable time (hand-wave, hand-wave) must be
> > de-listed and moved to a "Previous Authors" section of the XEP.
> >
> > Note that this is *NOT* intended as a punishment for unresponsive
> > authors, hence the "Previous Authors" section - it's to protect
> > authors and their employers from legal action.
> >
> > I have to admit I'm surprised that such legal considerations exist,
> > but the central argument - that if your name is on a document, you're
> > presumed to know what it contains - seems sufficiently intuitive that
> > we should take notice.
> >
> > Comments?
> >
> > Dave.
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0387 (XMPP Compliance Suites 2017)

[Guus der Kinderen]

Thanks for getting the ball rolling on this one again, Sam.

Is footnote 10 "Support can be enabled via an external component or an
internal server module/plugin." relevant?

I suggest o remove footnote 6, and simply make CAPS a requirement on it's
own.

- Guus

On 9 February 2017 at 00:32, XMPP Extensions Editor  wrote:

> Version 0.1.0 of XEP-0387 (XMPP Compliance Suites 2017) has been released.
>
> Abstract:
>   This document defines XMPP protocol compliance levels for 2017.
>
>
> Changelog: [See revision history] (ssw)
>
> Diff: N/A
>
> URL: http://xmpp.org/extensions/xep-0387.html
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] 2017 Compliance Suites

[Guus der Kinderen]

Sam, you recently sparked a discussion on competing XEPs - obsoleting one
of those is currently under vote at the council, if I skimmed over my
emails correctly. Perhaps that's something that could be addressed in these
suites - promote one XEP over another similar one?

 - Guus

On 18 January 2017 at 19:36, Sam Whited  wrote:

> On Wed, Jan 18, 2017 at 12:15 PM, Goffi  wrote:
> > the idea is not new, but it would be very nice to have "profiles" for
> > compliance suites.
>
> Hi Goffi,
>
> The current compliance suites actually do this for Core, Web, IM, and
> Mobile: https://xmpp.org/extensions/xep-0375.html
>
> > Today there is nothing for file transfer or video (actually
> > it could be a new section in the current XEP), and I would love to see
> Jingle
> > mentioned somewhere.
>
> I think file transfer would make sense in the IM suite; thanks, I'll
> look into adding this!
>
> Video in my mind would be its own suite. I'd also like to see
> something from the new IoT SIG. Either of these things just needs
> someone who knows something about video or IoT to do it!
>
> —Sam
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Guus der Kinderen]

What I am doing here, first, and foremost, is having fun. Having gotten
that out of the way: the discussion so far revolves around the use-case of
a single user, wanting to do IM with friends. Undoubtedly that's an
important part of the ecosystem (on which we can and should improve) but
I've seen much value in XMPP in other settings too. XMPP offers a mature
ecosystem in which to develop custom data-exchange driven systems, even
when those are not oriented to instant messaging.

On 16 January 2017 at 19:08, Evgeny Khramtsov  wrote:

> Mon, 16 Jan 2017 17:59:21 +
> Dave Cridland  wrote:
>
> > That's not what I said, I said that federation was an important
> > feature.
>
> You have said exactly that:
> > And if your business plan doesn't involve federation, why bother with
> > the additional overhead and complexity?
>
> Which means it doesn't make sense to deploy XMPP if you don't need
> federation.
>
> > But anyway, I'll rephrase: businesses want to communicate with their
> > supply-chain and with their customers, and want a communications
> > platform that allows this.
>
> You repeated, not rephrased.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] "Self-destruct" message timeout deletion hints

[Guus der Kinderen]

Do I understand this correctly: this feature depends on the author of a
message enabling an 'auto-destruct' flag? From a user perspective, I'd be
terribly annoyed by that. There is hardly any added security or privacy
value in this feature, and the the data hygiene that applies to my data is
something that I want control myself. Unless I'm chatting with my mother, I
don't expect my peer to tell me when I need to clean my archive. If it were
me in control of my messages (and the messages that I can retrieve from
persistent storage, server side), that'd be another story.

On 18 October 2016 at 23:58, Chris Ballinger  wrote:

> Many other messaging apps are implementing features for self-destructing
> messages. I dismissed the idea for a long time because of the impossibility
> of actually enforcing deletion on the other side, but now I believe it
> could be useful to help users "automate minimalist data hygiene" [1].
>
> As far as an XMPP extension would be concerned, I think that it would be
> important that clients can discover if another client claims to support
> message timeouts, to allow for configurable timeouts, and work within the
> context of a MUC. None of these hints would affect the current message
> archiving specs because the timeouts are strictly for when a client views a
> message, but could be used in combination with , for
> example.
>
> Are there other scenarios that I'm missing? Would people be willing to
> implement this into their apps? Is formalized spec for this something that
> XSF would consider?
>
> Thanks!
>
> 1. https://whispersystems.org/blog/disappearing-messages/
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Deletion

[Guus der Kinderen]

Not sure if I get what you're trying to say. I don't think that deletion
should be an edit-to-empty, I think we're in agreement there.

When defined in distinct XEPs, I think both XEPs would be (or should be)
near copies of each-other, which would be needlessly complex.

I propose to have one XEP, that defines distinct keywords for 'correction'
and 'deletion'. A reference to the original message is desirable for a
correction for many of the same reasons as it is desirable for a deletion.


On 18 October 2016 at 11:18, Kevin Smith <kevin.sm...@isode.com> wrote:

> On 18 Oct 2016, at 10:16, Guus der Kinderen <guus.der.kinde...@gmail.com>
> wrote:
> > On 18 October 2016 at 11:12, Kevin Smith <kevin.sm...@isode.com> wrote:
> >> On 18 Oct 2016, at 10:09, Guus der Kinderen <
> guus.der.kinde...@gmail.com> wrote:
> >> > I don't have much of an argument other than the obvious: both affect
> data 'after-the-fact'. Concerns raised against one should likely also be
> tested against the other - it's pretty much the same thing. As for the
> non-IM case: that could also apply to 'correction' of data, rather than
> only deletion. Implementation-wise, it'd make sense to combine both efforts
> too, I'd say.
> >>
> >> I agree with all of this, but believe these are distinct operations
> that deserve distinct protocol.
> >>
> > Why, when the use case, business rules and security considerations are
> pretty much the same (or perhaps: should be pretty much the same)? Wouldn't
> it be enough to perhaps have a distinct operation identifier in the same
> protocol?
>
> I don’t see a difference between "different protocol" and “the same
> protocol with different identifiers”. If it’s which XEP number this goes
> into, I care much less than that I don’t think deletion should be an edit
> to zero length.
>
> /K
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Deletion

[Guus der Kinderen]

Why, when the use case, business rules and security considerations are
pretty much the same (or perhaps: should be pretty much the same)? Wouldn't
it be enough to perhaps have a distinct operation identifier in the same
protocol?

On 18 October 2016 at 11:12, Kevin Smith <kevin.sm...@isode.com> wrote:

> On 18 Oct 2016, at 10:09, Guus der Kinderen <guus.der.kinde...@gmail.com>
> wrote:
> > I don't have much of an argument other than the obvious: both affect
> data 'after-the-fact'. Concerns raised against one should likely also be
> tested against the other - it's pretty much the same thing. As for the
> non-IM case: that could also apply to 'correction' of data, rather than
> only deletion. Implementation-wise, it'd make sense to combine both efforts
> too, I'd say.
>
> I agree with all of this, but believe these are distinct operations that
> deserve distinct protocol.
>
> /K
>
> >
> > On 18 October 2016 at 10:57, Dave Cridland <d...@cridland.net> wrote:
> > On 18 October 2016 at 09:55, Guus der Kinderen
> > <guus.der.kinde...@gmail.com> wrote:
> > > Has the functional overlap with XEP-0308 "Last message correction"
> already
> > > been discussed? What's the reason for creating a distinct XEP? Would
> it be
> > > good to have the new XEP include 'correction', and replace 308?
> > >
> >
> > It was discussed - we could do this as a message correction to a
> > zero-length message - but firstly I think the semantics are somewhat
> > different, and secondly I think this might be usable in some non-IM
> > cases.
> >
> > I'm open to argument, mind.
> >
> > > On 18 October 2016 at 10:44, Dave Cridland <d...@cridland.net> wrote:
> > >>
> > >> On 17 October 2016 at 20:45, XMPP Extensions Editor <edi...@xmpp.org>
> > >> wrote:
> > >> > 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 retracted.
> > >> >
> > >> > URL: http://xmpp.org/extensions/inbox/message-retraction.html
> > >> >
> > >> > The council will decide in the next two weeks whether to accept this
> > >> > proposal as an official XEP.
> > >> >
> > >>
> > >> Blocking:
> > >>
> > >> The XEP title hasn't changed; we really need to avoid the "Deletion"
> > >> word to properly describe what this XEP is doing. (Or rather, what
> > >> it's not doing).
> > >>
> > >> Non-Blocking (feel free to dispute these):
> > >>
> > >> 1) MAM access.
> > >>
> > >> I'm concerned that there exists a mechanism for abuse if messages are
> > >> ever truly expunged from the archive. I think this XEP should include
> > >> a MAM extension for accessing the unexpunged message for
> > >> administrative users.
> > >>
> > >> The risk here is that an abusive and/or spam message is sent to a
> > >> chatroom, that is then (immediately) removed from the archive. We want
> > >> administrators to be able to see the original message, I think.
> > >>
> > >> It could be that administrators *always* see the original message and
> > >> the  indicator.
> > >>
> > >> 2) Tombstone Privacy
> > >>
> > >> At the opposite end of the scale, I wonder if by requiring the
> > >> original JID in the tombstone, we expose more data than we need to. If
> > >> the administrator can see the full data (as above), then i think we
> > >> can safely remove more data from the retraction tombstone.
> > >>
> > >> > ___
> > >> > Standards mailing list
> > >> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > >> > Unsubscribe: standards-unsubscr...@xmpp.org
> > >> > ___
> > >> ___
> > >> Standards mailing list
> > >> Info: https://mail.jabber.org/mailman/listinfo/standards
> > >> Unsubscribe: standards-unsubscr...@xmpp.org
> > >> ___
> > >
> > >
> > >
> > > ___
> &

Re: [Standards] Proposed XMPP Extension: Message Deletion

[Guus der Kinderen]

I don't have much of an argument other than the obvious: both affect data
'after-the-fact'. Concerns raised against one should likely also be tested
against the other - it's pretty much the same thing. As for the non-IM
case: that could also apply to 'correction' of data, rather than only
deletion. Implementation-wise, it'd make sense to combine both efforts too,
I'd say.

On 18 October 2016 at 10:57, Dave Cridland <d...@cridland.net> wrote:

> On 18 October 2016 at 09:55, Guus der Kinderen
> <guus.der.kinde...@gmail.com> wrote:
> > Has the functional overlap with XEP-0308 "Last message correction"
> already
> > been discussed? What's the reason for creating a distinct XEP? Would it
> be
> > good to have the new XEP include 'correction', and replace 308?
> >
>
> It was discussed - we could do this as a message correction to a
> zero-length message - but firstly I think the semantics are somewhat
> different, and secondly I think this might be usable in some non-IM
> cases.
>
> I'm open to argument, mind.
>
> > On 18 October 2016 at 10:44, Dave Cridland <d...@cridland.net> wrote:
> >>
> >> On 17 October 2016 at 20:45, XMPP Extensions Editor <edi...@xmpp.org>
> >> wrote:
> >> > 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 retracted.
> >> >
> >> > URL: http://xmpp.org/extensions/inbox/message-retraction.html
> >> >
> >> > The council will decide in the next two weeks whether to accept this
> >> > proposal as an official XEP.
> >> >
> >>
> >> Blocking:
> >>
> >> The XEP title hasn't changed; we really need to avoid the "Deletion"
> >> word to properly describe what this XEP is doing. (Or rather, what
> >> it's not doing).
> >>
> >> Non-Blocking (feel free to dispute these):
> >>
> >> 1) MAM access.
> >>
> >> I'm concerned that there exists a mechanism for abuse if messages are
> >> ever truly expunged from the archive. I think this XEP should include
> >> a MAM extension for accessing the unexpunged message for
> >> administrative users.
> >>
> >> The risk here is that an abusive and/or spam message is sent to a
> >> chatroom, that is then (immediately) removed from the archive. We want
> >> administrators to be able to see the original message, I think.
> >>
> >> It could be that administrators *always* see the original message and
> >> the  indicator.
> >>
> >> 2) Tombstone Privacy
> >>
> >> At the opposite end of the scale, I wonder if by requiring the
> >> original JID in the tombstone, we expose more data than we need to. If
> >> the administrator can see the full data (as above), then i think we
> >> can safely remove more data from the retraction tombstone.
> >>
> >> > ___
> >> > Standards mailing list
> >> > Info: https://mail.jabber.org/mailman/listinfo/standards
> >> > Unsubscribe: standards-unsubscr...@xmpp.org
> >> > ___
> >> ___
> >> Standards mailing list
> >> Info: https://mail.jabber.org/mailman/listinfo/standards
> >> Unsubscribe: standards-unsubscr...@xmpp.org
> >> ___
> >
> >
> >
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
> >
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Deletion

[Guus der Kinderen]

Has the functional overlap with XEP-0308 "Last message correction" already
been discussed? What's the reason for creating a distinct XEP? Would it be
good to have the new XEP include 'correction', and replace 308?

On 18 October 2016 at 10:44, Dave Cridland  wrote:

> On 17 October 2016 at 20:45, XMPP Extensions Editor 
> wrote:
> > 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 retracted.
> >
> > URL: http://xmpp.org/extensions/inbox/message-retraction.html
> >
> > The council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> >
>
> Blocking:
>
> The XEP title hasn't changed; we really need to avoid the "Deletion"
> word to properly describe what this XEP is doing. (Or rather, what
> it's not doing).
>
> Non-Blocking (feel free to dispute these):
>
> 1) MAM access.
>
> I'm concerned that there exists a mechanism for abuse if messages are
> ever truly expunged from the archive. I think this XEP should include
> a MAM extension for accessing the unexpunged message for
> administrative users.
>
> The risk here is that an abusive and/or spam message is sent to a
> chatroom, that is then (immediately) removed from the archive. We want
> administrators to be able to see the original message, I think.
>
> It could be that administrators *always* see the original message and
> the  indicator.
>
> 2) Tombstone Privacy
>
> At the opposite end of the scale, I wonder if by requiring the
> original JID in the tombstone, we expose more data than we need to. If
> the administrator can see the full data (as above), then i think we
> can safely remove more data from the retraction tombstone.
>
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0359 Client vs. non-client IDs

[Guus der Kinderen]

I appreciate the implementation-related argument too. I don't think that
that argument should outweigh the value of applying clear, concise
naming. Removing the "client/server" role is a big improvement there.
There's no use-case for this XEP where the 'by' is left out by an entity
that's not an 'origin' entity?

On 3 October 2016 at 11:11, Kevin Smith <kevin.sm...@isode.com> wrote:

>
> > On 2 Oct 2016, at 18:46, Florian Schmaus <f...@geekplace.eu> wrote:
> >
> > On 29.09.2016 20:18, Kevin Smith wrote:
> >> On 29 Sep 2016, at 19:08, Florian Schmaus <f...@geekplace.eu> wrote:
> >>>
> >>> On 29.09.2016 19:22, Guus der Kinderen wrote:
> >>>> Hi,
> >>>>
> >>>> What's the purpose of the distinction between "Unique Stanza IDs" and
> >>>> "Client generated stanza IDs"? Why not add a unbounded list of
> stanza-id
> >>>> elements (each with a unique 'by' attribute value), and not worry
> about
> >>>> what entity is serving in a client-capacity?
> >>>
> >>> It was designed that way to avoid leaking the client's XMPP address in
> >>> cases like MUC. Notice that  has a 'by' attribute whereas
> >>>  has not. I should add that rationale to the XEP.
> >>
> >> That makes sense, but why not just say something like “the stanza-id
> without a by is the originating entity”.
> >
> > That's the other approach I could have taken when designing the protocol
> > (and I find myself often in the situation where I have to decide between
> > those two approaches when working on new extension protocols for XMPP).
> >
> > I personally find the variance it introduces, that the 'by' attribute
> > can either exit or not, less desirable. Instead I enjoy the fact that I
> > can look at the element's name and tell if it requires a non-empty 'by'
> > attribute or that it must not have one. I find this preferable when
> > writing parsers, designing classes for extension elements (e.g. a method
> > "getBy()" will always return a JID for the class 
> > represents), or writing the XEP itself.
>
> I can buy that argument.
>
> >
> >> Else sometimes the orginating entity stamps with a client-id (when it’s
> a client) or doesn’t (when it’s a server), or you have servers stamping
> with client-id, or whatever.
> >
> > Fair point. How about 's/client-id/origin-id/‘?
>
> Or just origin? Either way, I think an improvement, yes.
>
> /K
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0359 Client vs. non-client IDs

[Guus der Kinderen]

I agree with Kev. If an entity does not wish to expose its address, it can
simply choose to not provide the 'by' attribute. There's need to explicitly
define the client/server role in that action too, right?

 - Guus

On 29 September 2016 at 20:18, Kevin Smith <kevin.sm...@isode.com> wrote:

> On 29 Sep 2016, at 19:08, Florian Schmaus <f...@geekplace.eu> wrote:
> >
> > On 29.09.2016 19:22, Guus der Kinderen wrote:
> >> Hi,
> >>
> >> What's the purpose of the distinction between "Unique Stanza IDs" and
> >> "Client generated stanza IDs"? Why not add a unbounded list of stanza-id
> >> elements (each with a unique 'by' attribute value), and not worry about
> >> what entity is serving in a client-capacity?
> >
> > It was designed that way to avoid leaking the client's XMPP address in
> > cases like MUC. Notice that  has a 'by' attribute whereas
> >  has not. I should add that rationale to the XEP.
>
> That makes sense, but why not just say something like “the stanza-id
> without a by is the originating entity”. Else sometimes the orginating
> entity stamps with a client-id (when it’s a client) or doesn’t (when it’s a
> server), or you have servers stamping with client-id, or whatever.
>
> /K
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0359 Client vs. non-client IDs

[Guus der Kinderen]

Hi,

What's the purpose of the distinction between "Unique Stanza IDs" and
"Client generated stanza IDs"? Why not add a unbounded list of stanza-id
elements (each with a unique 'by' attribute value), and not worry about
what entity is serving in a client-capacity?

Regards,

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

[Standards] SASL's DIGEST-MD5: host or domain?

[Guus der Kinderen]

Hi,

Over the last few days, some of us at IgniteRealtime have been having fun
with the DIGEST-MD5 SASL Mechanism - specifically, with it's digest-uri
value. The syntax of this value is:

serv-type "/" host [ "/" serv-name ]


It's generally accepted [1] that the applicable value for the serv-type
part is "xmpp". So far, we've not used the optional "serv-name" part. The
"host" part is a cause of confusion though.

We found that, when handling the server side of things, Openfire expects
the "host" part of the digest-uri value to be an XMPP domain name. This
conflicts with the specification in RFC2831, which defines the "host" part
as follows:

"*The DNS host name or IP address for the service requested.  The DNS host
name must be the fully-qualified canonical name of the host. The DNS host
name is the preferred form; see notes on server processing of the
digest-uri."*


Clearly, this defines a host name to be used, not the service domain name.
This is further confirmed on "our" wiki [3] where "host" is defined as:


"*The DNS hostname or IP address for the service requested (though the DNS
hostname is preferred). For XMPP, this should be set to the hostname of the
remote server.*"


All of the above let me to experiment with changing our implementation:
instead of expecting the client to send the domain name, let's have a fully
qualified host name [4].

Interoperability problems galore!

The change above, although "correct" in the terms of following the RFC,
appears to clash with existing XMPP client implementations. So far, we've
found that Smack, Conversations, and Gajim will use the XMPP domain name,
instead of the fully qualified host name when constructing the digest-uri
value. They were the first three implementations that we checked. With the
three out of three score, I'm assuming that most other implementations will
behave the same. (How does your implementation do this?)

How, as a community, should we tackle this, if at all? On one hand: if
indeed everyone is doing the same thing now, it would probably hurt
interoperability when "fixes" are applied. Then again, there's bound to be
some implementations that actually follow the specifications, and now fail
to authenticate.

For Openfire (and perhaps all server implementations), I'd love to work
towards a solution in which the DIGEST-MD5 mechanism implementation will
accept both the domain name as well as the fully qualified host name. That
will allow both variants to connect successfully, but has practical issues
[5].

Regards,

  Guus

   1. Now that Dave has come around
   2. https://tools.ietf.org/html/rfc2831
   3. http://wiki.xmpp.org/web/SASLandDIGEST-MD5
   4. This change was needed to resolve another, unrelated issue, which is
   why we started looking into this in the first place
   5. We either have to implement our own implementation (daunting task),
   or find a suitably licensed third party implementation (haven't found one
   yet)
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] How many delay elements?

[Guus der Kinderen]

When more than one delay element is added - assuming that only the defined
attributes are used - is there a way to distinguish what element was added
for what purpose?

The delay element should reference the timestamp on which the stanza was
originally send. Is there reason that for one stanza, that time changes? As
in, would multiple delay stanzas, if allowed, be anything other than exact
duplicates?

  Guus

On 13 July 2016 at 21:04, Holger Weiß  wrote:

> This came up before, but I fail to find a clarification.
>
> XEP-0203 says:
>
> | Information about the delivery delay is communicated by adding to the
> |  or  stanza one and only one  child
> | [...].  This information is added by the server or component that
> | delivers the stanza.
>
> Does this mean that
>
> 1. a given stanza should never contain more than a single direct 
>child element, or that
> 2. a given server or component should never add more than a single
>direct  child element to a given stanza, or that
> 3. no more than a single direct  child element should be added
>to a given stanza for a given delay cause?
>
> For example, if a groupchat message delivery is delayed because the
> sending client was offline when it was written, and then because the MUC
> service sends it as part of the discussion history, and then because
> it's queued by CSI¹, and then because it's queued by stream manegement;
> how many  elements should the stanza end up with?
>
> Holger
>
> ¹ Queueing groupchat messages might be weird, but XEP-0352 permits the
>   server to do weird things, AFAIK.
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Guus der Kinderen]

That makes sense. I'm not against having a core as well as an advanced
definition in principle. Dave's suggestion to take XEP status as a guide to
what goes where sounds like a good rule of thumb, at the very least.
On 12 Jul 2016 17:02, "Dave Cridland" <d...@cridland.net> wrote:



On 12 July 2016 at 15:55, Guus der Kinderen <guus.der.kinde...@gmail.com>
wrote:

> Perhaps we shouldn't mention MIX at all in this particular compliance
> suite. The MIX specification isn't definitive by a long shot, and although
> there are some early implementations, it hardly qualifies for something to
> be compliant with nowadays. I'd save it for the next editions of the
> complicance suite specification.
>
> I'd like to see the "core server" specifications to be removed completely.
> As it stands, it's of little use, and I doubt if there are server
> implementations that strive to be "core", but not "advanced".
>
>
I think we have four levels of XEP, from an XSF point of view.

- XEPs that are widely implemented, and client developers could consider
hard fails if the support is not present. I'm not recommending refusing to
connect if, for example, XEP-0313 access to personal archives is not
available, but (within this example) a client might be written to consider
its absence as exceptional, rather than attempting to degrade terribly
gracefully. (Note: MAM here is *just* an example). I'd expect these
specifications to be Final, incidentally, so maybe we don't have many of
these right now (and that's an issue we should address). This is basically
"Core" in my mind.

- XEPs that it is the consensus of the Standards SIG that implementations
should aspire to support at this point in time. These would be
specifications we believe are ready (and I would expect these to be Draft -
and if they're Experimental, we should be working hard to move them on).
This is basically "Advanced" in my mind.

- XEPs that are promising, but not there yet. These are Experimental.

- XEPs that we've dropped. These are Deferred, Deprecated, etc.

Not *all* Final XEPs are going to be in Core in a Compliance Suite, simply
because we might not have a compliance suite covering, say, IoT yet. And
maybe there'll be exceptions to the XEP states (XEP-0054 is Historical, yet
I'd argue it's Core), but we should be examining mismatches.

Given all this rambling:

- I do think there's a place for Core, and it's not aspirational.
- MIX doesn't (yet) belong here.

Dave.

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

Re: [Standards] XEP-0375: View from Openfire

[Guus der Kinderen]

Perhaps we shouldn't mention MIX at all in this particular compliance
suite. The MIX specification isn't definitive by a long shot, and although
there are some early implementations, it hardly qualifies for something to
be compliant with nowadays. I'd save it for the next editions of the
complicance suite specification.

I'd like to see the "core server" specifications to be removed completely.
As it stands, it's of little use, and I doubt if there are server
implementations that strive to be "core", but not "advanced".

- Guus

On 12 July 2016 at 15:04, Kevin Smith  wrote:

>
> > On 12 Jul 2016, at 13:49, Ralph Meijer  wrote:
> >
> > On 2016-07-12 05:11, Sam Whited wrote:
> >> I've tried to address some of this feedback here:
> >>
> >> https://github.com/xsf/xeps/pull/206
> >>
> >> I think the only thing I left out was getting rid of the IM compliance
> >> suites (in case any of the IoT crowd chime in).
> >>
> >> I also added MIX as a possible provider of "Group Chat" and merged the
> >> web compliance suites into a single item, making BOSH and Websockets
> >> interchangeable. More suggestions for web-friendly features would be
> >> appreciated from web client authors (maybe they're similar to mobile
> >> concerns?).
> >>
> >> Let me know what you think. It could probably use a bit of description
> >> about what the providers column means now; I envision a comma as being
> >> an OR as in "MUC or MIX".
> >
> > Although I strongly believe in the prospects of what MIX will bring to
> > the table, to me, it doesn't make sense to put in any reference to MIX
> > at this point in time. The point of this suite is to get
> > interoperability between a wide array of client and server
> > implementations so that things Just Work™. MIX is nowhere near mature
> > enough that this is achievable within 2016.
>
> I think that’s right. I think a note about MIX might be well-placed, but
> not as part of the compliance tables.
>
> /K
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0375 (XMPP Compliance Suites 2016): caps as a server requirement?

[Guus der Kinderen]

The XEP lists "Entity Capabilities (XEP-0115)" as a requirement for
"Advanced Server", although with this footnote: "Necessary to support
Personal Eventing Protocol (PEP)."

If there is no reason to include caps as a _server_ requirement, other than
as a dependency for another requirement, it should not be mentioned at all.
There is the implementation note warning that each requirement can have its
own dependencies, after all.

Sam mentioned in https://github.com/iNPUTmice/ComplianceTester/issues/4 :

> I went back and looked at this, and I think the footnote was a holdover
> from an earlier version of the compatibility suites hand is specifically
> on the server requirement for caps because otherwise it's not immediately
> obvious from looking at the spec that the caps dependency is for the server
> as well as the client.


I feel that the XEP is improved by splitting up the server and client
requirements into two different tables, instead of listing them in the same
table. That way, the client requirements can list caps as a requirement,
without there being a need to define that caps is a server
requirement-only-by-dependency-reference.

Regards,

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

Re: [Standards] disco identity for client/smartphone?

[Guus der Kinderen]

I'm wondering to what extend the new definition would add value, or is more
likely to introduce confusion.

Smartphones might be more likely to offer specialized functionality, but as
the set of functionality that's offered by a particular model will likely
be different from another model, you'd have to discover support for
individual functionality anyway.

Perhaps 'smartphone' would suggest better/more stable connectivity, as a
smartphone is more likely to utilize a higher generation of mobile
telecommunications technology and/or WiFi, but that's an iffy deduction at
best.

Any other distinctive characteristics that I'm missing? If not, I'd prefer
not to add another identity (although I'll not be a vocal opponent either).

Regards,

 - Guus


On 30 November 2012 15:11, Kozlov Konstantin yag...@yandex.ru wrote:



 30.11.2012, 12:26, Kevin Smith ke...@kismith.co.uk:
  On Thu, Nov 29, 2012 at 11:39 PM, Peter Saint-Andre stpe...@stpeter.im
 wrote:
 
   Looking at http://xmpp.org/registrar/disco-categories.html I notice
   that we have disco identities for client/handheld (e.g., PDA) and
   client/phone (e.g., mobile phone), but I think those are a bit
   old-fashioned by now. We might want to add an identity for
   client/smartphone (i.e., a phone that can do a lot more than the
   old-style phones we had in mind when we defined client/phone).
 
  If this thing is capable of running an XMPP client on it, it's a
 smartphone.
 Why?! Any cheap J2ME-enabled phone can run XMPP client without any problem.
 Usually we call smartphones only mobile devices with operating system
 (Symbian, Windows CE/Mobile/Phone, iOS or Android).
 So, if you call any Java-enabled mobile phone smartphone, you should
 agree that no mobile phones produced today at all. Only smartphones!

[Standards] RSM and order

[Guus der Kinderen]

Hello,

Was it a deliberate choice not to include an explicit attribute that
relates to 'order' in XEP-0059 - Result Set Management?

XEP-0059 RSM is oriented towards a GUI that contains a scrollable list (in
which order is often implied, I guess). A different common GUI element is
that of a paginated table. That would work well with RSM (as long as you do
not relax the requirement of accuracy on the 'index' value). A common
feature of such tables is the ability to sort data by column - which is how
I noticed that any form of 'ordering' is missing from the XEP.

Any form of iteration (using more than one request) depends on the fact
that each request uses a result set that's ordered in the same way. There
is no reference to such ordering in the XEP at all. Strictly speaking, I
think the XEP could use (well, it's been in use for years and no-one missed
it, but hey) a reference to ordering, even if its to be implicit.

If functionality could be added that can be used to define ordering of a
result set, the XEP becomes a lot more flexible. I'm not advocating that a
lot more flexibility should be added - although I'm not denying that it
could have considerable added value.

Regards,

  Guus

[Standards] Incorrect example in XEP-0059 Result Set Management

[Guus der Kinderen]

Hello,

Regarding http://xmpp.org/extensions/xep-0059.html: In example 13,
shouldn't the value of the 'index' attribute be 371 rather than 10?

Regards,

  Guus

Re: [Standards] Correcting last message

[Guus der Kinderen]

First thoughts: perhaps you should add a section that informs how to handle
child elements of the message stanza other than body. XHTML-IM adds an
child element that's typically related to the message body content, for
example. Other child elements might not (nicknames, for example). Should the
XEP allow overriding other child elements like that (for XHTML-IM, I would
think so). What should be the business rules if:

   - the original stanza contains such additional child elements, and the
   replacement one has not?
   - the original stanza does not contains suchs additional child elements,
   but the replacement one does?
   - both stanzas have different additional child elements?

On 20 July 2010 05:19, Kevin Smith ke...@kismith.co.uk wrote:

 Following a discussion in jdev, I've thrown together the skeleton of a
 XEP for correcting previous messages.
 I'll clean it up before submitting, but the rough gist is at:
 http://www.doomsong.co.uk/extensions/render/xep-correct.html
 Discussion welcome.

 /K

Re: [Standards] XEP-0136: comments about auto save and preferences

[Guus der Kinderen]

2010/6/13, Steven te Brinke s.tebri...@student.utwente.nl:
 Hello,

 When reading XEP-0136 I discovered some confusing properties. I will
 describe
 these and propose changes that make them more intuitive to me. I am not sure
 whether the things I propose are better than the official XEP, so let me
 know
 what you think about it.

 The auto save preference is quite confusing to me. If I am right, all
 preferences are global, except the auto save preference, which can be set
 per
 stream by using scope='stream'. The idea that it can be set per stream
 sounds
 quite good, but the way it is done is quite strange to me:
 1) The usage of scope is explained in the XEP, but the scope element is not
 part of the given schema.
 2) The auto element can be set as well inside as outside the pref element
 without having different semantics.
 3) Setting an auto with scope='stream' implies removing the auto with
 scope='global'.

 Maybe number 3 is done for a specific reason, but I do not know in which use
 case it is useful. Consider the following situation:
 My server has archiving disabled by default and I want to archive all
 messages, so I set auto save='true' scope='global'/. At home I use a
 client
 with built in archiving, so I set auto save='false' scope='stream'/ to
 disable archiving for this session only. However, when I now login with any
 other client, archiving is disabled because the server default is used.
 (Setting auto with scope='stream' was overwriting the one with
 scope='global'.)

 Thus, IMO it is undesired that the setting for a stream overwrites the
 global
 setting. Therefore I propose the following change: remove the scope
 attribute
 from the auto element and define two separate elements: one inside the prefs
 and one outside. The former should be global and the latter per stream. If
 both are present, the server should use the latter. This way, no
 functionality
 is lost and now both properties can be configured independently.
 Furthermore,
 it makes all preferences in the prefs element global, which is more
 intuitive.

 Regarding the streams, there is one more thing that is unclear to me. The
 spec
 states: Server implementations SHOULD remove all session/ elements when
 stream is closed.
 However, a user can have multiple streams (e.g. by being online on multiple
 PCs) and there is no definition to which stream a session element belongs.
 My
 propose is to remove this sentence altogether, because I think it is not
 really desired to have sessions removed at the end of a stream. The
 expiration
 will remove the session when appropriate. Consider the following situation:
 During a secret conversation with Bob we both turn off archiving for this
 session only. For a reason unknown to me, Bob goes suddenly offline. Because
 I
 was busy typing, I only notice this after I have send another message. This
 message will be archived at Bobs side because his stream was closed before I
 send the message. This is not what we desired. Only if the session element
 had
 expired normally, the desired effect would have been achieved.

 Another point are changes to preferences. These are pushed to every resource
 which has retrieved the preferences before. I assume this is done to allow
 the
 client to have an up to date view of the preferences. However, item removes
 are not pushed to the clients, so clients cannot maintain an up to date view
 from the pushed changes. Therefore, IMO this behaviour should be changed.
 Because I do not know how clients will use this information, I cannot say in
 which way it should be changed. There are many possibilities:
 1) Also push removes. This adds additional complexity to the protocol, but
 allows clients to stay updated with minimal overhead.
 2) Always push the full settings on a change, not only the changes. Provides
 the same functionality as 1 using less complexity, but more overhead.
 3) Push no information about changes. Minimal overhead, but removes the
 ability to stay up to date.
 4) Use 3, but additionally store the settings in a pubsub node, so all
 interested clients can stay up to date. Has many good properties: no
 overhead
 when clients are not interested, less complexity in this protocol. Downside
 is
 that in order to use it, pubsub support is required (but that will be
 required
 for many features anyway).

 Note that when sessions are expired, they can be removed from the
 configuration
 by the server. IMO this should also be considered a change of configuration,
 but at least the expected behaviour in this situation should be documented
 too.

 Cheers,
 Steven


-- 
Verzonden vanaf mijn mobiele apparaat

Re: [Standards] XEP-0136: comments about auto save and preferences

[Guus der Kinderen]

I'm sorry guys. It appears that every time I start the gmail app on my
phone, a new, empty response is sent.

On 24 June 2010 01:19, Matthew Wild mwi...@gmail.com wrote:

 On 13 June 2010 15:22, Steven te Brinke s.tebri...@student.utwente.nl
 wrote:
  Hello,
 

 Hello!

 Ignoring Guus's mobile's fascination with your message...

  When reading XEP-0136 I discovered some confusing properties. I will
 describe
  these and propose changes that make them more intuitive to me. I am not
 sure
  whether the things I propose are better than the official XEP, so let me
 know
  what you think about it.
 

 Most of what you have said makes sense. A new version of XEP-0136 was
 recently published, and the council have added a note about the
 perceived complexity of the current spec, and that it could likely be
 drastically simplified.

 The XEP is currently being implemented server-side in Prosody for
 Google Summer of Code - I expect some feedback to result from that,
 and given the resulting client and server experience we should be able
 to start banging this protocol into good shape at last.

 Matthew

Re: [Standards] XEP-0136: comments about auto save and preferences

[Guus der Kinderen]

 --
 Verzonden vanaf mijn mobiele apparaat


Not quite sure why my mobile decided that it was a good move to reply to the
original e-mail message with a blank message. Certainly was not intentional.
Sorry for this.

 - Guus

Re: [Standards] XEP-0136: comments about auto save and preferences

[Guus der Kinderen]

2010/6/13, Steven te Brinke s.tebri...@student.utwente.nl:
 Hello,

 When reading XEP-0136 I discovered some confusing properties. I will
 describe
 these and propose changes that make them more intuitive to me. I am not sure
 whether the things I propose are better than the official XEP, so let me
 know
 what you think about it.

 The auto save preference is quite confusing to me. If I am right, all
 preferences are global, except the auto save preference, which can be set
 per
 stream by using scope='stream'. The idea that it can be set per stream
 sounds
 quite good, but the way it is done is quite strange to me:
 1) The usage of scope is explained in the XEP, but the scope element is not
 part of the given schema.
 2) The auto element can be set as well inside as outside the pref element
 without having different semantics.
 3) Setting an auto with scope='stream' implies removing the auto with
 scope='global'.

 Maybe number 3 is done for a specific reason, but I do not know in which use
 case it is useful. Consider the following situation:
 My server has archiving disabled by default and I want to archive all
 messages, so I set auto save='true' scope='global'/. At home I use a
 client
 with built in archiving, so I set auto save='false' scope='stream'/ to
 disable archiving for this session only. However, when I now login with any
 other client, archiving is disabled because the server default is used.
 (Setting auto with scope='stream' was overwriting the one with
 scope='global'.)

 Thus, IMO it is undesired that the setting for a stream overwrites the
 global
 setting. Therefore I propose the following change: remove the scope
 attribute
 from the auto element and define two separate elements: one inside the prefs
 and one outside. The former should be global and the latter per stream. If
 both are present, the server should use the latter. This way, no
 functionality
 is lost and now both properties can be configured independently.
 Furthermore,
 it makes all preferences in the prefs element global, which is more
 intuitive.

 Regarding the streams, there is one more thing that is unclear to me. The
 spec
 states: Server implementations SHOULD remove all session/ elements when
 stream is closed.
 However, a user can have multiple streams (e.g. by being online on multiple
 PCs) and there is no definition to which stream a session element belongs.
 My
 propose is to remove this sentence altogether, because I think it is not
 really desired to have sessions removed at the end of a stream. The
 expiration
 will remove the session when appropriate. Consider the following situation:
 During a secret conversation with Bob we both turn off archiving for this
 session only. For a reason unknown to me, Bob goes suddenly offline. Because
 I
 was busy typing, I only notice this after I have send another message. This
 message will be archived at Bobs side because his stream was closed before I
 send the message. This is not what we desired. Only if the session element
 had
 expired normally, the desired effect would have been achieved.

 Another point are changes to preferences. These are pushed to every resource
 which has retrieved the preferences before. I assume this is done to allow
 the
 client to have an up to date view of the preferences. However, item removes
 are not pushed to the clients, so clients cannot maintain an up to date view
 from the pushed changes. Therefore, IMO this behaviour should be changed.
 Because I do not know how clients will use this information, I cannot say in
 which way it should be changed. There are many possibilities:
 1) Also push removes. This adds additional complexity to the protocol, but
 allows clients to stay updated with minimal overhead.
 2) Always push the full settings on a change, not only the changes. Provides
 the same functionality as 1 using less complexity, but more overhead.
 3) Push no information about changes. Minimal overhead, but removes the
 ability to stay up to date.
 4) Use 3, but additionally store the settings in a pubsub node, so all
 interested clients can stay up to date. Has many good properties: no
 overhead
 when clients are not interested, less complexity in this protocol. Downside
 is
 that in order to use it, pubsub support is required (but that will be
 required
 for many features anyway).

 Note that when sessions are expired, they can be removed from the
 configuration
 by the server. IMO this should also be considered a change of configuration,
 but at least the expected behaviour in this situation should be documented
 too.

 Cheers,
 Steven


-- 
Verzonden vanaf mijn mobiele apparaat

Re: [Standards] Syncing legacy contact list

[Guus der Kinderen]

On 6 June 2010 11:51, Dave Cridland d...@cridland.net wrote:

 On Sat Jun  5 20:23:05 2010, Guus der Kinderen wrote:

 That would work indeed. I'm not thrilled by the prospect of having to
 duplicate all legacy rosters in local persistent storage, but at least
 this
 way, we can make the XEPs work properly.

 Should the XEP suggest how roster syncing should take place in more detail
 than it does now?


 No.

 Many years ago, before the dawn of time - okay, last summer - there was
 much enthusiastic discussion, as I recall, about the concept of a remote
 roster.

 What this would do, in effect, is allow a remote fan-out of presence to a
 distinct roster membership, and that roster would be owned by the remote
 entity, and managed by it.

 So, gateways would operate by owning the legacy contacts in the roster,
 and effectively the client treats it as a sub-roster, incorporating it
 into the local display. Even cleverererer, the client can cache it using
 XEP-0237, manipulate it using RFC 3921 core commands, and really, the only
 special thing is that you'd have to send the controlling entity presence
 in order to have presence sent onward to those contacts. Of course, by
 placing the remote entity in your local server roster - the one you have now
 - this would happen anyway when you send presnece to *that* controlling
 entity - ie, your account, in your broadcast presence.

 The entire sync issue then goes away, I think, and the interaction between
 client, server, and gateway looks a whole heap simpler to my eyes.

 My understanding is that at least some client and gateway developers are
 interested in playing about with some experimental code to see how this
 works out in practise, but it all sounds sane to me.

 One interesting case is where the remote roster is not a gateway as such,
 simply an ordinary XMPP account that you've been granted access to, perhaps
 because you own them both...


I was no witness to the rejoice that apparently happened many moons ago, but
I like the idea that you're base lining here. The downside is that to get it
working, a lot of redesign and implementation needs to happen.

Although I'm not opposing that, I would like to see the current XEPs being
fixed/improved in a way that doesn't require structural changes. I think the
suggestions made by both Brian and myself will make the existing XEPs work
as intended, without changing them in a structural way. Low-hanging fruits?
Can we simple pick one (or another alternative to the same extend),
incorporate that as a guideline in the existing XEPs, and continue work on
the sub-roster idea in a parallel effort?


Dave.
 --
 Dave Cridland - mailto:d...@cridland.net - 
 xmpp:d...@dave.cridland.netxmpp%3a...@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
 Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Standards] Syncing legacy contact list

[Guus der Kinderen]

Hello,

XEP-0100 (Gateway Interaction), paragraph 7 states that if legacy roster
items are to be added to the XMPP roster of the entity that registered with
the gateway, Roster Exchange SHOULD be used.

XEP-0144 (Roster Item Exchange), section 7.2 reads:
(...) In order to maintain synchronization between the user's contact list
on a legacy IM service and the user's Jabber roster, the gateway SHOULD send
roster items with an 'action' attribute of add, delete, or modify as
appropriate (...)

I believe that this leaves room for error. As long as the XMPP entity makes
use of the legacy account through the XMPP gateway exclusively, all is well.
If the entity does not, problems might occur, as shown by example below.



For the purpose of this example, I will use a scenario that involves three
users: Romeo, Juliet and Benvolio. All three have accounts on a legacy IM
domain, in which they are on each-others roster (whatever that might mean
in the legacy domain). Romeo is the only user that has an account on both an
XMPP and the legacy service:

xmppro...@example.org - Romeo's XMPP user representation
legacyromeo - Romeo's user representation in the legacy domain
legacyjuliet - Juliet's user representation in the legacy domain
legacybenvolio - Benvolio's user representation in the legacy domain.

Romeo registered with a legacy gateway, available at: gateway.example.org

After Romeo logs in, the gateway initiates a session on his behalf on the
legacy domain. The legacy domain will most likely allow the gateway to
obtain a copy of Romeo's legacy roster representation. Following the
guidelines in XEP-0100 and XEP-0144, the gateway implementation sends Roster
Exchange Addition suggestions for each item on the legacy roster. Romeo's
XMPP happily accepts these suggestions, and the roster items are added to
Romeo's XMPP roster. The changes are thus persisted on the XMPP domain. This
XMPP Roster now includes:

legacyjul...@gateway.example.org
legacybenvo...@gateway.example.org

Now, Romeo logs out of his XMPP client, logs into a client that connects to
the legacy domain directly, and removes Benvolio from his contact list.
Then, Romeo logs out of the legacy domain, switches back to his XMPP client,
and logs on again.

Again, the gateway will initiate a session on Romeo's behalf to the legacy
domain. The legacy roster representation is obtained, which now includes
Juliet only. A typical gateway representation will send out a roster-add
suggestion for legacyjul...@gateway.example.org to the XMPP client of Romeo.
As this item already exists on the XMPP roster, it is silently ignored.
Benvolio's representation however, is also still there. Unless the gateway
has either direct access to Romeo's XMPP roster, or obtains somehow the
delta of roster changes on the legacy domain since the last login that the
gateway did (both are unlikely), there's no way that the gateway can
determine that it should send out a Roster Item Deletion suggestion. Romeo's
XMPP roster will continue to include both:

legacyjul...@gateway.example.org
legacybenvo...@gateway.example.org

Benvolio is still there, even though it was removed from the roster on the
legacy domain.



I have not been able to find a documented solution for this problem. Does
one exist? If not, I would suggest that a paragraph is included in the XEPs
that instruct clients to remove all roster items of which the
domain-identifier matches the domain-identifier of the legacy gateway
component, if the gateway is using Roster Exchange to populate the roster.
This will synchronize the local and legacy roster each time a new session to
the legacy domain is created.

To avoid complexity, I would suggest that the gateway implementation does
not initiate other Roster Exchanges after the initial roster sync. Note that
this does not prevent Roster Exchanges being initiated by a representation
of a legacy user (node at gateway.domain) if the legacy domain happens to
offer such functionality.

I would like to hear your take on this.

Regards,

  Guus

Re: [Standards] Syncing legacy contact list

[Guus der Kinderen]

On 5 June 2010 19:58, Brian Cully bcu...@gmail.com wrote:

 On 5-Jun-2010, at 05:35, Guus der Kinderen wrote:

 Again, the gateway will initiate a session on Romeo's behalf to the legacy
 domain. The legacy roster representation is obtained, which now includes
 Juliet only. A typical gateway representation will send out a roster-add
 suggestion for legacyjul...@gateway.example.org to the XMPP client of
 Romeo. As this item already exists on the XMPP roster, it is silently
 ignored. Benvolio's representation however, is also still there. Unless the
 gateway has either direct access to Romeo's XMPP roster, or obtains somehow
 the delta of roster changes on the legacy domain since the last login that
 the gateway did (both are unlikely), there's no way that the gateway can
 determine that it should send out a Roster Item Deletion suggestion. Romeo's
 XMPP roster will continue to include both:

 legacyjul...@gateway.example.org
 legacybenvo...@gateway.example.org

 Benvolio is still there, even though it was removed from the roster on the
 legacy domain.


 This is a general issue with roster item exchange, but soluble. We have our
 roster item exchange component cache it's latest suggestions in a database
 so it can detect deletions from the legacy service. IOW, our server
 remembers that it once sent out adds for both legacyjuliet and
 legacybenvolio. When romeo logs in again, it sees that only legacyjuliet is
 in the current legacy roster, but that it previously suggested an add for
 legacybenvolio, so now it should suggest a removal.

 -bjc


That would work indeed. I'm not thrilled by the prospect of having to
duplicate all legacy rosters in local persistent storage, but at least this
way, we can make the XEPs work properly.

Should the XEP suggest how roster syncing should take place in more detail
than it does now?

- Guus

Re: [Standards] XEP-0277 Microblogging over XMPP and the Atom data format

[Guus der Kinderen]

Hi Bear,

Thanks for taking the time to respond. I'm completely new to Atom, so
getting feedback from someone who has used it intensively before is very
valuable to me.

I've included my replies inline.

 - Guus

On 16 May 2010 20:44, bear bea...@gmail.com wrote:

 On Sun, May 16, 2010 at 09:03, Guus der Kinderen
 guus.der.kinde...@gmail.com wrote:
  Hi all,
 
  Recently, I have been working on an XMPP gateway (XEP-0100 Gateway
  Interaction style) that exposes Twitter functionality in a way compliant
  with XEP-0277 Microblogging over XMPP. While coding, a number of
 questions
  and remarks related to this last XEP popped up.
 
  The XEP specifies that pubsub to publish and receive microblog posts (the
  XEP does indicate that for posting, an alternative interface can be
 used).
  The pubsub items used in the examples are using an Atom-based data
 format.
 
  My first question: the XEP does not specify explicitly that the Atom data
  format MUST/SHOULD be used. Can other formats be used as well? I feel
 that
  there is room for interpretation here. This can lead to implementations
 that
  are XEP compliant, but are not compatible with other implementations.
 Should
  the Microblogging XEP specify more exact what data format should be used?

 I think that would be a good change as Atom has become the default
 canonical format for this realm.

  Why was the Atom-based data format chosen? In my opinion, there are a
 number
  of characteristics that do not make it fit to the purpose:

 Atom has been chosen, from what I can gather and also from my own
 opinion, because it is now the format used for ActivityStreams,
 PubSubHubbub, OStatus and the majority of the large consumers and
 providers of feed data.

 It is also a proper XML format which gives it a lot of advantages in
 the XMPP world, but that's secondary to the prior reasons IMO.


I'm not a big fan of re-inventing the wheel myself, but I do feel that for
the purpose of simple microblogging, Atom is overkill. It adds a lot of
complexity (us having this conversation as an early result), which we can do
without. XMPP can be complex enough in itself - adding yet another
technology in the mix raises the bar considerably.

Having the microblogs be very portable could be valuable, I agree with you
there completely. However, I think that ensuring portability is not a core
responsibility of the Microblogging XEP itself. Instead, I believe that this
could be the responsibility of some kind of extension to the XEP (or a
gateway implementation perhaps). Such an extension to the Microblogging XEP)
could be used to translate a light-weight XMPP representation of a microblog
entry into the more complex, but more portable Atom-based representation,
for example.

The current XEP appears to be open to something like this. It reads: Romeo
can publish a post via any interface provided by his service, such as a
website, the Atom Publishing Protocol (see RFC
5023http://tools.ietf.org/html/rfc5023[
8 http://xmpp.org/extensions/xep-0277.html#nt-id298333]), SMS, an IM bot,
or XMPP pubsub. Here we assume that the post is provided via XMPP pubsub.
Then, it continues to wrap Atom in Pubsub in the following examples, but as
I wrote earlier, there doesn't appear to be a requirement that the pubsub
entries are Atom-formatted. I would like to see such a formatting
requirement to be explicitly defined (as that would help interoperability,
but I think we both agree there), and, for the reason mentioned above, be a
lot simpler than the current suggested Atom format.


  Atom requires a title for each entry. In the context of a microblog, this
  requirement doesn't make much sense to me. The examples in the XEP use
 the
  atom:title element to hold the text of the post. I would argue that this
 is
  done more appropriately in a atom:content element instead.

 In the case of a post or update that does not have a Title per se, the
 Atom spec says that the content of the post should be placed in the
 Title element and the Content element should be empty.  This rule is
 also listed as a MUST in the ActivityStreams spec:

 http://activitystrea.ms/schema/1.0/activity-schema-01.html#article


I believe you are referring to the definition of a title property of an
Article object, which reads:

The title of the entry. Included as the content of the atom:title element.
This element MUST be included with empty content if the entry does not have
a title.

I believe that this means something different than what you say. I think the
line above instructs us to include an empty title element (eg:
title/title) if the article does not have a title. The usage of the word
content is horrible in this definition, as the same word is used to
describe another property of the Article later on in the text.


As for the Atom specs, are you referring to paragraph 4.1.1.1 of RFC4287?

(...) It is advisable that each atom:entry element contain a non-empty
atom:title element, a non-empty atom:content element when