Re: [Standards] 2017 Compliance Suites

[Sam Whited]

On Wed, Jan 18, 2017 at 1:07 PM, Guus der Kinderen
 wrote:
> 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?

Yup, definitely a good idea.

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

Re: [Standards] 2017 Compliance Suites

[Florian Schmaus]

On 18.01.2017 17:43, Sam Whited wrote:
> - Add TLS recommendations (I'm working on these already)

I'd eventually also point to

https://bettercrypto.org/static/applied-crypto-hardening.pdf

- Florian



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

Re: [Standards] 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] 2017 Compliance Suites

[Sam Whited]

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
___

Re: [Standards] 2017 Compliance Suites

[Goffi]

Le mercredi 18 janvier 2017, 10:43:23 CET Sam Whited a écrit :
> Hi all,
> 
> We discussed moving forward the 2016 compliance suites today in the
> council meeting, and it was decided to start a mailing list discussion
> about what worked, what didn't, and what should be different for the
> 2017 ones (which will hopefully advance quicker). We've had a few of
> these that included suggestions like:
> 
> - Remove MIX as an optional spec to satisfy the multiuser chat
> category since it's not ready
> - Add TLS recommendations (I'm working on these already)
> 
> Anything else before I submit a first draft of the 2017 suites?
> 
> Thanks,
> Sam
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___


Hi,


the idea is not new, but it would be very nice to have "profiles" for 
compliance suites. 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.


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

[Standards] 2017 Compliance Suites

[Sam Whited]

Hi all,

We discussed moving forward the 2016 compliance suites today in the
council meeting, and it was decided to start a mailing list discussion
about what worked, what didn't, and what should be different for the
2017 ones (which will hopefully advance quicker). We've had a few of
these that included suggestions like:

- Remove MIX as an optional spec to satisfy the multiuser chat
category since it's not ready
- Add TLS recommendations (I'm working on these already)

Anything else before I submit a first draft of the 2017 suites?

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

[Standards] 2017-01-18 Council Meeting

[Sam Whited]

# 2017-01-18 Council Meeting

Logs: http://logs.xmpp.org/council/2017-01-18#16:01:18


## Roll call

- Tobias (chairing)
- Sam Whited
- Dave Cridland

Daniel and Link Mauve sent their apologies.


## Move XEP-0153: vCard-Based Avatars to "Obsolete"

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

- Tobias -1
- SamWhited  +1
- Dave Cridland  -1

Others to vote on list if they want too.

## Specify an encoding in XEP-0300

https://github.com/xsf/xeps/issues/349

Current proposal is to specify an encoding and bump Jingle File Transfer and
Hashes namespace version.
After some discussion on whether a Jingle FT version bump was required, it was
determined that it was since hashes are REQUIRED when offering a file in FT.


## Move 2016 Compliance Suites to LC

- Tobias notes that it probably makes sense just to start new ones for 2017 at
  this point.
- Sam to start a list discussion on 2017 suites.
- Sam suggests deprecating the 2010 ones (or whatever the currently "accepted"
  ones are) to prevent old recommendations from being implemented and for the
  image (looks bad that the only recommendations are so old).
- Tobias suggests that we need a new one first.

## Accept Bind 2.0 as Experimental

https://xmpp.org/extensions/inbox/bind2.0.html

- SamWhited  +1
- Dave Cridland  +1
- Tobias +1

Others on list.

## Lots of deferred XEPs

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

Note that Sam (with his editor hat on) recently deferred a bunch of XEPs that
weren't automatically deferred after 12 months (but should have been).

If you see anything that needs to be advanced instead, please reach out to the
council.

## Consider advancing XEP-0333: Chat Markers to LC

- This is one of the XEPs that Sam deferred, but he thinks its widely used so
  maybe it's worth advancing.
- Tobias, Dev, and Dave question the assumption that it's widely used.
- Dave notes that this is what LC is for, if it's good enough to implement, and
  seems to be working, it should be LCed and people will respond if there are
  issues with it.
- Dave also notes that "widespread use" might matter for Draft->Final but not
  for Experimental->Draft

## Consider advancing XEP-0233: XMPP Server Registration for use with
Kerberos V5

- Dave Cridland notes that Mili should probably be an author because she wrote
  a great deal of that one and that he's happy to LC it as well
- Tobias also is happy to LC this one

## Date of next

2016-01-25 1615Z

## Any Other Business

None

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

Re: [Standards] Easy XMPP

[Sam Whited]

On Wed, Jan 18, 2017 at 7:53 AM, Brian Cully  wrote:
> Whether they know about it or not, people do need to have encryption. 
> It’s a complicated, esoteric thing that they shouldn’t have to know about but 
> do silently benefit from. In the dreaded car analogy: how many users discuss 
> limited slip differentials? Does that mean there shouldn’t be engineering 
> resources behind it?

I took "encryption" in this context to mean "end to end encryption",
and I disagree. I don't want end to end encryption in most situations,
I want searchable history that I can query on the server and sync to
any new devices. Where "I" in this case am assuming the role of "some
random user who just wants to chat and be able to go back and find the
date of an event their friend sent them".

I'm certainly not arguing that e2e encryption is useless or that we
shouldn't throw resources behind it, but we should stop assuming it's
needed 100% of the time for all users and use cases.

(to take this analogy too far, this is the best video I've ever seen
explaining the topic: https://www.youtube.com/watch?v=yYAw79386WI)

> It’s a similar thing, in my mind, with federation. IMHO, it’s 
> dangerous to put so much information in the control of a few huge 
> organizations, and federation is a necessary, but not sufficient, way to 
> alleviate that. It’s more than just whether or not users knowingly care, it’s 
> engineering ways to help keep them safe and in control of what they share and 
> with whom.

I do agree with you here for the general users case here, but also
bear in mind that one use case is "don't share anything with anyone
not allowed on this server", at which point federation probably isn't
necessary (and may be a bad thing).

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

Re: [Standards] [xsf/xeps] Defers many old XEPs (#372)

[Sam Whited]

On Wed, Jan 18, 2017 at 4:43 AM, Peter Waher  wrote:
> As you know, some of these have actually been touched on more recently, but 
> the editorial team chose not to accept the edits, after waiting several 
> months. You yourself chose not to accept the edits, because you thought it 
> was too complicated to have changes made in multiple XEPs in a single PR.

Hi Peter,

Sorry if there was some confusion, but the issue with your PR wasn't
that multiple files were in one commit (that's fine), it was that the
diff was too big and multiple changes were broken up and mixed
together over many commits that didn't have any clear distinction
about what was in them. It was too much effort to review and merge the
changes as submitted.

While email is fine, Git is the preferred way to submit changes; this
does mean learning a bit of Git, and while I try not to be too picky
about it, it requires learning some best practices as well. A single
patch by email that was the size of the changes you submitted would
probably be equally difficult to review, and isn't likely to encourage
people to get it merged quickly. Small, self-contained, logical
changes are much more likely to get accepted.

Thanks for being willing to work with us on this!

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

Re: [Standards] Proposed XMPP Extension: Bind 2.0

[Michal Piotrowski]

I have another question regarding pipelining. From what I understand the
very first connection to the server should be "normal" like - client sends
packet, waits for the response(s) and proceeds. The next time all the
mentioned things in the spec can be pipelined. What makes me wonder are
server responses like stream features. Should server still send them? In my
opinion they are redundant in this case as the client is probably not
interested and already knows what features will be used.


Best regards
Michal Piotrowski
michal.piotrow...@erlang-solutions.com

On 18 January 2017 at 15:01, Evgeny Khramtsov  wrote:

> Wed, 18 Jan 2017 14:24:02 +0100
> Florian Schmaus  wrote:
>
> > Bind2 already tries to solve race conditions an XMPP client encounters
> > when creating a new session by atomically querying the users archive
> > for the ID of the latest stanza, binding the resource *and*
> > activating the stream of live stanzas right after the retrieved ID. I
> > believe you don't not a database with atomic operations to implement
> > that protocol step atomically server-side (by just locking the
> > archive and stanza stream of the user while that action is performed).
>
> Ok, let's say you need to read some different tables (possibly in
> different databases, for example SQL and Redis). In order to do this
> atomically, you need to read one table, cache the results somewhere,
> then read the next table and cache the result and so on. So you need
> to maintain additional cache. And what if you need writes (enabling
> carbons requires writes I believe)? You need to discard all your writes
> if some of the table fails (simulating rollback). Is it's worth the
> effort?
> ___
> 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

[Evgeny Khramtsov]

Wed, 18 Jan 2017 08:53:14 -0500
Brian Cully  wrote:

> Whether they know about it or not, people do need to have encryption.
> It’s a complicated, esoteric thing that they shouldn’t have to know
> about but do silently benefit from. In the dreaded car analogy: how
> many users discuss limited slip differentials? Does that mean there
> shouldn’t be engineering resources behind it?

The analogy with cars is absolutely inadequate, that's the problem a
lot of crypto guys run into. Typical IM user doesn't have such severe
consequences as from a car crash if someone reads his message. Most of
the time IM messages possesses no sensitive data, especially for users
chatting with friends and relatives (the use case we want spread,
right?). For those sending sensitive data encryption is required.
I personally don't need e2e encryption, because I don't want all its
drawbacks: I don't want to lose all my archived messages if I lose a
phone, I don't want to read crap instead of messages from the resource
unsupporting e2e, I don't want to mess with key storage, I don't want to
choose which protocol to use (OTR (several versions), Axolotl, Olm - XSF
repeats the same mistake as with file transfer here).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Bind 2.0

[Evgeny Khramtsov]

Wed, 18 Jan 2017 14:24:02 +0100
Florian Schmaus  wrote:

> Bind2 already tries to solve race conditions an XMPP client encounters
> when creating a new session by atomically querying the users archive
> for the ID of the latest stanza, binding the resource *and*
> activating the stream of live stanzas right after the retrieved ID. I
> believe you don't not a database with atomic operations to implement
> that protocol step atomically server-side (by just locking the
> archive and stanza stream of the user while that action is performed).

Ok, let's say you need to read some different tables (possibly in
different databases, for example SQL and Redis). In order to do this
atomically, you need to read one table, cache the results somewhere,
then read the next table and cache the result and so on. So you need
to maintain additional cache. And what if you need writes (enabling
carbons requires writes I believe)? You need to discard all your writes
if some of the table fails (simulating rollback). Is it's worth the
effort?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Brian Cully]

> On 17-Jan-2017, at 10:49, Evgeny Khramtsov  wrote:
> 
> Tue, 17 Jan 2017 09:29:09 -0600
> Sam Whited  wrote:
> 
>> Of note: security didn't really enter into it from her perspective
> 
> Exactly. Regular users aren't concerned about security and encryption.
> They don't even know if Whatsapp has any sort of encryption. Yet, every
> third discussion on this list is about encryption. Look at the tail
> of the XEPs list: there are 6 encryption related XEPs out of 18 (i.e.
> 30%) WTF? Whom are we building network for?

Whether they know about it or not, people do need to have encryption. 
It’s a complicated, esoteric thing that they shouldn’t have to know about but 
do silently benefit from. In the dreaded car analogy: how many users discuss 
limited slip differentials? Does that mean there shouldn’t be engineering 
resources behind it?

It’s a similar thing, in my mind, with federation. IMHO, it’s dangerous 
to put so much information in the control of a few huge organizations, and 
federation is a necessary, but not sufficient, way to alleviate that. It’s more 
than just whether or not users knowingly care, it’s engineering ways to help 
keep them safe and in control of what they share and with whom.

-bjc

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

Re: [Standards] Proposed XMPP Extension: Bind 2.0

[Kevin Smith]

On 18 Jan 2017, at 13:25, Michal Piotrowski 
 wrote:
> On 18 January 2017 at 14:08, Kevin Smith  wrote:
> How many is many? I don’t see a problem with this scaling to any human IM 
> cases that I can think of. Do you have anything in mind?
> 
> No, nothing particular in mind. Just wanted to make it clear if the spec 
> assumes the server provides complete list of unread conversations, no matter 
> how long it is.  

That’s my assumption, yes.

/K

> 
> 
> Best regards
> Michal Piotrowski
> michal.piotrow...@erlang-solutions.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] Proposed XMPP Extension: Bind 2.0

[Michal Piotrowski]

On 18 January 2017 at 14:08, Kevin Smith  wrote:

> How many is many? I don’t see a problem with this scaling to any human IM
> cases that I can think of. Do you have anything in mind?
>

No, nothing particular in mind. Just wanted to make it clear if the spec
assumes the server provides complete list of unread conversations, no
matter how long it is.


Best regards
Michal Piotrowski
michal.piotrow...@erlang-solutions.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Bind 2.0

[Florian Schmaus]

On 18.01.2017 00:05, Evgeny Khramtsov wrote:
> Tue, 17 Jan 2017 23:09:52 +0100
> Florian Schmaus  wrote:
>
>> atomic mechanism
> 
> While it's easy to say, it's quite hard to implement on the server,
> especially when you're not using relational database (i.e. when you
> cannot perform transactions across several tables).

Depends on what exactly is to be performed atomically.

Bind2 already tries to solve race conditions an XMPP client encounters
when creating a new session by atomically querying the users archive for
the ID of the latest stanza, binding the resource *and* activating the
stream of live stanzas right after the retrieved ID. I believe you don't
not a database with atomic operations to implement that protocol step
atomically server-side (by just locking the archive and stanza stream of
the user while that action is performed).

- Florian



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

Re: [Standards] Proposed XMPP Extension: Bind 2.0

[Florian Schmaus]

On 18.01.2017 14:05, Kevin Smith wrote:
>> On 17 Jan 2017, at 22:09, Florian Schmaus  wrote:
>> On 17.01.2017 16:23, XMPP Extensions Editor wrote:
>>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>> Title: Bind 2.0
>>
>> I could live with Bind2 being hardcoded to MAM and Carbons. But is there
>> any particular reason why the  step should not be a flexible
>> atomic mechanism for resource binding and performing arbitrary actions?
>>
>> Something like
>>
>> 
>>  
>>  
>>  …
>> 
> 
> Dave has similar desires (going further than this, I think), and I don’t 
> think they’re a bad idea. I just wrote what I thought was the minimal 
> complexity to solve the issue. I noted in the body of the XEP that I 
> anticipate aspects of the protocol changing over time - but I feel that one 
> could implement what’s currently in the document (not saying which carbons 
> version notwithstanding) and be done with most of the work such that a 
> protocol change later would be close to trivial.

I feel like it is so trivial to change bind2 towards a flexible approach
that it's worth having that specified right from the beginning. I could
imagine use cases where I want MAM but not Carbons. Or MAM, Carbons and
SM, Or just MAM and Carbons.

And I'm curious what Dave further desires. @Dave: Care to drop a few
lines to elaborate?

- Florian



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

Re: [Standards] Proposed XMPP Extension: Bind 2.0

[Kevin Smith]

Thanks.

> On 17 Jan 2017, at 20:30, Michal Piotrowski 
>  wrote:
> 
> Hi, 
> 
> Thanks for the protoXEP, this is step in a good direction! The part which I 
> find the most important is the information about unread messages. Here are my 
> questions regarding this:
> 1. How messages should be marked as read? Is this subject of another XEP or 
> maybe XEP-0333: Chat Markers could be used here?

We (probably I) should write another XEP covering this - I left a note in the 
Bind2 spec that this needs doing. I don’t think 333 is the right way to signal 
this stuff to the server, but I think the protocol for doing it is 
straightforward.

> 2. What in a situation when the client have many contacts with unread 
> messages? Should the response indicate that there maybe more unread 
> conversations?


How many is many? I don’t see a problem with this scaling to any human IM cases 
that I can think of. Do you have anything in mind?

> > Note: this gets rid of manual resource binding altogether. For discussion 
> > on standards@
> 
> This maybe tricky. On one hand I think it'd be better if only the server 
> could assign resource, on the other hand I worked with some installations 
> (closed ones) where the resource where well though and contained some 
> informations about the client like app version or platform. This was later 
> used by some other parts of the entire system.

It may be tricky, yes. I thought it best to raise the issue so we can discuss 
it, rather than just assuming we have to keep the legacy stuff. If we end up 
with reasons we need to keep client-requested resources, at least we’ll have 
concrete understanding why that is :)

> > Note: also enable acks? discuss on standards@
> 
> Does acks mean stream management? If so then I think it's worth enabling them 
> by default for clients using bind 2.0


Yes, the acks from 198.

/K

> 
> 
> 
> 
> Best regards
> Michal Piotrowski
> michal.piotrow...@erlang-solutions.com
> 
> On 17 January 2017 at 16:23, XMPP Extensions Editor  wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Bind 2.0
> 
> Abstract: This specification provides a single-request replacement for 
> several activities an XMPP client needs to do at startup.
> 
> URL: http://xmpp.org/extensions/inbox/bind2.0.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: Bind 2.0

[Kevin Smith]

> On 17 Jan 2017, at 22:09, Florian Schmaus  wrote:
> 
> On 17.01.2017 16:23, XMPP Extensions Editor wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>> 
>> Title: Bind 2.0
>> 
>> Abstract: This specification provides a single-request replacement for 
>> several activities an XMPP client needs to do at startup.
>> 
>> URL: http://xmpp.org/extensions/inbox/bind2.0.html
> 
> How do clients know which version of carbons got enabled?

A fair question. I think for now simply encoding the versions in the bind spec 
would make sense (for reasons in next paragraph).

> I could live with Bind2 being hardcoded to MAM and Carbons. But is there
> any particular reason why the  step should not be a flexible
> atomic mechanism for resource binding and performing arbitrary actions?
> 
> Something like
> 
> 
>  
>  
>  …
> 

Dave has similar desires (going further than this, I think), and I don’t think 
they’re a bad idea. I just wrote what I thought was the minimal complexity to 
solve the issue. I noted in the body of the XEP that I anticipate aspects of 
the protocol changing over time - but I feel that one could implement what’s 
currently in the document (not saying which carbons version notwithstanding) 
and be done with most of the work such that a protocol change later would be 
close to trivial. So we could start getting simple test (or even deployment) 
solving these problems soon, while we work out the very best way to do it - I 
think some details of the perfect approach may end up ratholing, and I’m keen 
that we have a baseline we can work towards while we deal with those issues.

> and  returns the result of the action(s) (if any). Or an
> meaningful error is returned, if one or more actions could not be
> performed. That would also ensure that the versions requested by the
> client got enabled.
> 
> +1 for removing client suggested resource parts.
> 
> Nit: Example 3 contains a comma

Thanks. I’ll try to add hard-coded Carbons versions, and fix the comma this 
afternoon if I get some cycles.

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

Re: [Standards] [xsf/xeps] Defers many old XEPs (#372)

[Kevin Smith]

Hi Peter,

> On 18 Jan 2017, at 10:43, Peter Waher  wrote:
> 
> Is it possible for me to mail updates to these XEPs to the editor e-mail, as 
> was possible before? 

Sending patches by email remains an option, yes. You could probably even get 
away with sending the entire source file if you can’t work Git, as long as you 
don’t do anything obviously broken, althoug this is clearly forcing the Editors 
to do more work!

/K

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

Re: [Standards] [xsf/xeps] Defers many old XEPs (#372)

[Peter Waher]

Hello Sam (and others)

As you know, some of these have actually been touched on more recently, but the 
editorial team chose not to accept the edits, after waiting several months. You 
yourself chose not to accept the edits, because you thought it was too 
complicated to have changes made in multiple XEPs in a single PR.

I therefore ask you to return the following to Experimental:

  *   M xep-0323.xml (2)
  *   M xep-0324.xml (2)
  *   M xep-0325.xml (2)
  *   M xep-0326.xml (2)
  *   M xep-0331.xml (2)
  *   M xep-0336.xml (2)
I also request another method, since you didn’t approve of the way I use Git. 
Is it possible for me to mail updates to these XEPs to the editor e-mail, as 
was possible before? If not, I request more patience on the editor side for any 
lack of profitiency using Git. I don’t know how to edit multiple XEPs and push 
changes in different PRs. The Windows client I use collects all commits I make 
into one PR.

Best regards,
Peter Waher


Från: Sam Whited
Skickat: den 17 januari 2017 18:02
Till: xsf/xeps
Kopia: Subscribed
Ämne: [xsf/xeps] Defers many old XEPs (#372)


Lots of old XEPs that haven't been touched in 12+ months and need deferring. 
Some of these are widely used and should probably be advanced; I'll ask the 
various people involved if they want to continue pushing them forward or try to 
advance them and we can undefer them if anyone wants to take over and champion 
an XEP on a case by case basis.

Fixes #369


You can view, comment on, or merge this pull request online at:

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

Commit Summary

  *   Defers many old XEPs

File Changes

  *   M xep-0215.xml (2)
  *   M xep-0233.xml (2)
  *   M xep-0264.xml (2)
  *   M xep-0286.xml (2)
  *   M xep-0292.xml (2)
  *   M xep-0298.xml (2)
  *   M xep-0318.xml (2)
  *   M xep-0320.xml (2)
  *   M xep-0323.xml (2)
  *   M xep-0324.xml (2)
  *   M xep-0325.xml (2)
  *   M xep-0326.xml (2)
  *   M xep-0330.xml (2)
  *   M xep-0331.xml (2)
  *   M xep-0333.xml (2)
  *   M xep-0334.xml (2)
  *   M xep-0335.xml (2)
  *   M xep-0336.xml (2)

Patch Links:

  *   https://github.com/xsf/xeps/pull/372.patch
  *   https://github.com/xsf/xeps/pull/372.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on 
GitHub, or mute the 
thread.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___