[Standards] xmpp namespaces registry lacks rosterver namespace

2017-02-28 Thread Ruslan N. Marchenko

Hi,


I've been trying to find a registration of the 
urn:xmpp:features:rosterver namespace and found it's only mentioned 
once(!) in RFC6121 and nowhere else - namely neither in 
https://xmpp.org/registrar/namespaces.html nor in 
https://xmpp.org/registrar/stream-features.html registry.


Is it not a real namespace? Or why is it having so little attention?


Regards,

Ruslan

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


Re: [Standards] LAST CALL: XEP-0186 (Invisible Command)

2017-02-28 Thread Ruslan N. Marchenko



On 28.02.2017 17:27, XMPP Extensions Editor wrote:

This message constitutes notice of a Last Call for comments on XEP-0186 
(Invisible Command).

Abstract: This document specifies an XMPP protocol extension for user 
invisibility.

URL: https://xmpp.org/extensions/xep-0186.html

This Last Call begins today and shall end at the close of business on 
2017-03-14.

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?

Not really, but is handy nevertheless for client implementation

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?

No, security section list them accurately

5. Is the specification accurate and clearly written?
Spec still refers to XEP-0016 and XEP-0126 however latest amendment 
(probe blocking) directly contradicts to those XEPs making it incompatible.

I think it should be called out in interoperability section (Chapter 5).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___


Re: [Standards] XSF Council Minutes: 28 February 2017

2017-02-28 Thread Dave Cridland
Thanks for doing these! Really appreciated.

On 28 February 2017 at 16:37, JC Brand  wrote:
> XSF Council Minutes: 28 February 2017
> =
>
> Present: daniel, Tobias, Link Mauve, SamWhited, Dave Cridland
> Minute taker: jcbrand
>
> 1). Clarify CSI and Carbons state after SM resumption
>
> Tobias: Flow created PRs which clarify things and asked council to review.
> Would be nice if people could do so.
>
> https://github.com/xsf/xeps/pull/427
> https://github.com/xsf/xeps/pull/428
>
> Daniel asks where we are currently with the NS bump for carbons and whether
> it's necessary.
>
> Tobias mentions that he hasn't read through all the feedback yet.
>
> Link Mauve mentions that a NS bump is required due to the removal of 
> .
>
> Daniel says that some people want to keep .
>
> Dave Cridland says that Georg Lukas has decided to put together a PR
> as a concrete proposal.
>
> https://github.com/xsf/xeps/pull/434
>
> Dave Cridland says he's happy to have a namespace bump as long as implementors
> follow up and don't stick on the old one. He therefore wants some feedback on
> the above pull request.
>
> SamWhited and Tobias say they'll read the proposal.
>
> Daniel says he can live with a version bump but thinks only removing of
>  doesn't make it worth it.
>
> Link Mauve says that the rules definition from Georg also justify a namespace
> bump.
>
> Link Mauve suggests asking that #428 not bump the namespace, and to let
> the editor bump it manually once all of the changes are gathered.
>
> SamWhited says that he prefers that it bumps the namespace and he'll then 
> merge
> several other changes (if there are any) and then do a collective revision
> bump.
>
> Dave Cridland says he'd rather bump than risk incompatible deployments.
>
> 2) Georg opened an PR on MUC private messages, 
> https://github.com/xsf/xeps/pull/436
>
> Tobias suggests that council members give it a review and to vote on it next
> week so that there's time to incorporate a review feedback early on.
>
> Link Mauve is +1 since it does solve the issue.
>
> Dave Cridland thinks it needs some security considerations, in particular
> around replacing/removing client-added  stuff.
>
> daniel says he's going to vote +1 for it.
>
> 3) Date of next meeting
>
> Tobias: that would be 2017-03-08, 16:00 UTC
>
> Everyone agrees.
>
> 4) Any other business
>
> 4.1) Dave Cridland wonders whether a GSoC provides an opportunity to create 
> project
> to help with complex bits of editor automation. Suggests a discussion between
> the editors and Kev. He suggests pre-rendering of PRs.
>
> SamWhited likes the idea of making such a project.
>
> Tobias says we can make a "XSF" project on the GSoC ideas page but warns that
> it must be enough to full a GSoC term.
>
> SamWhited says there's plenty of stuff to keep a student busy.
>
> 4.2) SamWhited mentions that outstanding LCs end tomorrow again.
>
> Tobias says he'll do some reading/voting later today.
>
> Tobias bangs the gavel.
>
> ___
> 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] XSF Council Minutes: 28 February 2017

2017-02-28 Thread JC Brand
XSF Council Minutes: 28 February 2017
=

Present: daniel, Tobias, Link Mauve, SamWhited, Dave Cridland
Minute taker: jcbrand

1). Clarify CSI and Carbons state after SM resumption

Tobias: Flow created PRs which clarify things and asked council to review.
Would be nice if people could do so.

https://github.com/xsf/xeps/pull/427
https://github.com/xsf/xeps/pull/428

Daniel asks where we are currently with the NS bump for carbons and whether
it's necessary.

Tobias mentions that he hasn't read through all the feedback yet.

Link Mauve mentions that a NS bump is required due to the removal of .

Daniel says that some people want to keep .

Dave Cridland says that Georg Lukas has decided to put together a PR
as a concrete proposal.

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

Dave Cridland says he's happy to have a namespace bump as long as implementors
follow up and don't stick on the old one. He therefore wants some feedback on
the above pull request.

SamWhited and Tobias say they'll read the proposal.

Daniel says he can live with a version bump but thinks only removing of
 doesn't make it worth it.

Link Mauve says that the rules definition from Georg also justify a namespace
bump.

Link Mauve suggests asking that #428 not bump the namespace, and to let
the editor bump it manually once all of the changes are gathered.

SamWhited says that he prefers that it bumps the namespace and he'll then merge
several other changes (if there are any) and then do a collective revision
bump.

Dave Cridland says he'd rather bump than risk incompatible deployments.

2) Georg opened an PR on MUC private messages, 
https://github.com/xsf/xeps/pull/436

Tobias suggests that council members give it a review and to vote on it next
week so that there's time to incorporate a review feedback early on.

Link Mauve is +1 since it does solve the issue.

Dave Cridland thinks it needs some security considerations, in particular
around replacing/removing client-added  stuff.

daniel says he's going to vote +1 for it.

3) Date of next meeting

Tobias: that would be 2017-03-08, 16:00 UTC

Everyone agrees.

4) Any other business

4.1) Dave Cridland wonders whether a GSoC provides an opportunity to create 
project
to help with complex bits of editor automation. Suggests a discussion between
the editors and Kev. He suggests pre-rendering of PRs.

SamWhited likes the idea of making such a project.

Tobias says we can make a "XSF" project on the GSoC ideas page but warns that
it must be enough to full a GSoC term.

SamWhited says there's plenty of stuff to keep a student busy.

4.2) SamWhited mentions that outstanding LCs end tomorrow again.

Tobias says he'll do some reading/voting later today.

Tobias bangs the gavel.

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


[Standards] LAST CALL: XEP-0186 (Invisible Command)

2017-02-28 Thread XMPP Extensions Editor
This message constitutes notice of a Last Call for comments on XEP-0186 
(Invisible Command).

Abstract: This document specifies an XMPP protocol extension for user 
invisibility.

URL: https://xmpp.org/extensions/xep-0186.html

This Last Call begins today and shall end at the close of business on 
2017-03-14.

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] LAST CALL: XEP-0381 (Internet of Things Special Interest Group (IoT SIG))

2017-02-28 Thread XMPP Extensions Editor
This message constitutes notice of a Last Call for comments on XEP-0381 
(Internet of Things Special Interest Group (IoT SIG)).

Abstract: This document proposes the formation of a Special Interest Group SIG) 
within the XSF devoted to the application of XMPP technologies to the Internet 
of Things (IoT).

URL: https://xmpp.org/extensions/xep-0381.html

This Last Call begins today and shall end at the close of business on 
2017-03-14.

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
___