Re: [Standards] XEP-0280: vs.

[Kurt Zeilenga]

> On Sep 23, 2015, at 12:38 PM, Kurt Zeilenga  wrote:
> 
> 
>> On Sep 23, 2015, at 10:19 AM, Dave Cridland > > wrote:
>> 
>> Oh, hmmm - is that saying you'd like both, but  should be outbound 
>> only? 
> 
> yes, because one specifically telling my server how I want it to handle 
> stanzas I sent,  the other is providing a hint to whatever entities might 
> handle the stanza.

also my request to tell my server not to carbon my messages to my other clients 
is private to me and my server.  private because I might want to disclose that 
I’m carbon’ing to my communication partners.

and if I’d to hint that they not copy, I’d add that too.

— Kurt

Re: [Standards] XEP-0280: vs.

[Kurt Zeilenga]

> On Sep 23, 2015, at 10:19 AM, Dave Cridland  wrote:
> 
> Oh, hmmm - is that saying you'd like both, but  should be outbound 
> only? 

yes, because one specifically telling my server how I want it to handle stanzas 
I sent,  the other is providing a hint to whatever entities might handle the 
stanza.

Re: [Standards] XEP-0280: vs.

[Dave Cridland]

On 23 September 2015 at 18:14, Kurt Zeilenga 
wrote:

>
> On Sep 23, 2015, at 8:34 AM, Dave Cridland  wrote:
>
>
>
> On 17 September 2015 at 11:12, Florian Schmaus  wrote:
>
>> On 16.09.2015 23:26, Dave Cridland wrote:
>> > On 16 September 2015 at 22:21, Florian Schmaus > > > wrote:
>> > > The last time this came up, many many months ago, I recall there
>> not
>> > > being consensus to change.  But that was then and this is now.
>> > >
>> > > What are implementers doing today?
>> > >
>> > > * Are implementations using XEP-0280's ?
>> > > * Are implementations using XEP-0334's ?
>> >
>> > Smack's doing 
>> >
>> > > * Are implementations supporting both, but favoring XEP-0334's
>> ?
>> >
>> > I would switch to xep334 in an instant. Kurt has a valid point about
>> > xep334  being not as strict as . Hence I think
>> we
>> > should change that bit in xep334 and incorporate the semantics of
>> > xep280's .
>> >
>> >
>> > The point of '334 is that it's pure a hint and cannot be relied upon to
>> > provide any particular behaviour.
>> >
>> > I think changing that would probably be a mistake.
>> >
>> > Despite your argument to the contrary, I think you and Kurt have
>> > convinced me that we should keep Carbons (and ) as-is.
>>
>> I get your point. But it feels wrong to define nearly identical
>> extension elements in two XEPs. The author of xep334, Matthew Wild,
>> already expressed his willingness to change xep334 so that it can be
>> re-used in xep280. Therefore I'm all for changing xep334, then issue a
>> last call for it, ideally advance it to draft, then issue another last
>> call for a xep280 version using xep334 elements, and finally advance it
>> to draft.
>>
>>
> So summarizing...
>
> Procedurally:
>
> If we don't switch, then Carbons goes through to Draft now, and Hints
> either loses  or has a duplicate with softer requirements.
>
> If we do switch, then Carbons is delayed and has a version bump, and Hints
> needs editing and goes through Last Call to Draft.
>
> Technically:
>
>  is a mandatory part of Carbons.
>
>
> I can think of many good reasons why a server might want to deliver the
> message…
>
> This has MY server trusting some other client (and possibly other servers)
> to specify  in some way that doesn’t interfere with MY use of
> carbons.
>
>
>  is an expression of opinion from the sender that Carbon copying
> and similar will not be useful or desirable.
>
> Which semantics make more sense?
>
>
>  at least for senders which don’t have the same bare jid as the
> client which requested the carbons.
>
> That is, I think if I don’t want carbons for traffic I produce, then
>  semantics with a SHOULD NOT would be okay.
>
> But for traffic coming from other bare jids,  should be ignored
> and but  treated as hint (as intended).
>
>
Oh, hmmm - is that saying you'd like both, but  should be
outbound only?

>
> (And by the way I'd rather rephrase XEP-0334 in that way).
>
>
>> If we don't fix it right now, we will potentially never get another
>> chance to fix it.
>>
>
> Not really true, we get to wonder if  is useful in the face of
>  at a later date.
>
> But even if you were right, and certainly some options close on this
> decision, there is the question of whether this actually matters much.
>
> The only path I strongly object to would be making any of XEP-0334's Hints
> have mandatory (or even recommended in the RFC 2119 sense) behaviour.
>
>
>>
>> - Florian
>>
>>
>
>

Re: [Standards] XEP-0280: vs.

[Kurt Zeilenga]

> On Sep 23, 2015, at 8:34 AM, Dave Cridland  wrote:
> 
> 
> 
> On 17 September 2015 at 11:12, Florian Schmaus  > wrote:
> On 16.09.2015 23:26, Dave Cridland wrote:
> > On 16 September 2015 at 22:21, Florian Schmaus  > 
> > >> wrote:
> > > The last time this came up, many many months ago, I recall there not
> > > being consensus to change.  But that was then and this is now.
> > >
> > > What are implementers doing today?
> > >
> > > * Are implementations using XEP-0280's ?
> > > * Are implementations using XEP-0334's ?
> >
> > Smack's doing 
> >
> > > * Are implementations supporting both, but favoring XEP-0334's 
> > ?
> >
> > I would switch to xep334 in an instant. Kurt has a valid point about
> > xep334  being not as strict as . Hence I think we
> > should change that bit in xep334 and incorporate the semantics of
> > xep280's .
> >
> >
> > The point of '334 is that it's pure a hint and cannot be relied upon to
> > provide any particular behaviour.
> >
> > I think changing that would probably be a mistake.
> >
> > Despite your argument to the contrary, I think you and Kurt have
> > convinced me that we should keep Carbons (and ) as-is.
> 
> I get your point. But it feels wrong to define nearly identical
> extension elements in two XEPs. The author of xep334, Matthew Wild,
> already expressed his willingness to change xep334 so that it can be
> re-used in xep280. Therefore I'm all for changing xep334, then issue a
> last call for it, ideally advance it to draft, then issue another last
> call for a xep280 version using xep334 elements, and finally advance it
> to draft.
> 
> 
> So summarizing...
> 
> Procedurally:
> 
> If we don't switch, then Carbons goes through to Draft now, and Hints either 
> loses  or has a duplicate with softer requirements.
> 
> If we do switch, then Carbons is delayed and has a version bump, and Hints 
> needs editing and goes through Last Call to Draft.
> 
> Technically:
> 
>  is a mandatory part of Carbons.


I can think of many good reasons why a server might want to deliver the 
message…  

This has MY server trusting some other client (and possibly other servers) to 
specify  in some way that doesn’t interfere with MY use of carbons.

> 
>  is an expression of opinion from the sender that Carbon copying 
> and similar will not be useful or desirable.
> 
> Which semantics make more sense?

 at least for senders which don’t have the same bare jid as the 
client which requested the carbons. 

That is, I think if I don’t want carbons for traffic I produce, then  
semantics with a SHOULD NOT would be okay.

But for traffic coming from other bare jids,  should be ignored and 
but  treated as hint (as intended).

> 
> (And by the way I'd rather rephrase XEP-0334 in that way).
>  
> If we don't fix it right now, we will potentially never get another
> chance to fix it.
> 
> Not really true, we get to wonder if  is useful in the face of 
>  at a later date.
> 
> But even if you were right, and certainly some options close on this 
> decision, there is the question of whether this actually matters much.
> 
> The only path I strongly object to would be making any of XEP-0334's Hints 
> have mandatory (or even recommended in the RFC 2119 sense) behaviour.
>  
> 
> - Florian
> 
> 

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Florian Schmaus]

On 23.09.2015 17:29, Matthew Wild wrote:
> On 22 September 2015 at 21:53, Peter Saint-Andre - &yet
>  wrote:
>> On 9/22/15 11:48 AM, Florian Schmaus wrote:
>>>
>>> On 26.08.2015 17:59, XMPP Extensions Editor wrote:

 This message constitutes notice of a Last Call for comments on XEP-0352
 (Client State Indication).

 Abstract: This document defines a way for the client to indicate its
 active/inactive state.

 URL: http://xmpp.org/extensions/xep-0352.html

 This Last Call begins today and shall end at the close of business on
 2015-09-07.

 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?
>>>
>>> No.
>>>
 5. Is the specification accurate and clearly written?
>>>
>>> I'd like to see https://github.com/xsf/xeps/pull/44 merged.
>>
>>
>> I'd love to see some list discussion about that suggestion. :-)
>>
>> The proposed text is:
>>
>> ###
>>
>> XMPP requires stanzas to be processed in order as per &rfc6120; 10.1.
>> Especially "If the server's processing of a particular request could have an
>> effect on its processing of subsequent data it might receive over that input
>> stream..., it MUST suspend processing of subsequent data until it has
>> processed the request.". As a result, all actions triggered by a CSI nonza
>> sent to the server must happen before processing further requests from the
>> same client to the server.
>>
>> For example: A client sends a CSI active nonza, followed by an XMPP Ping
>> request to the server. The server first changes the CSI state to active and
>> flushes all eventually queued stanzsa. After the state has been restored to
>> 'active' and all resulting stanzas have been put on the wire, the server
>> sends the pong.
>>
>> 
>>
>> 
>> > type='get'>
>>   
>> 
>>
>> 
>>
>> > type='result'/>
>>
>> 
>>
>> ###
>>
>> Thoughts?
> 
> +1 to Florian's text. It clarifies what I believe to be the correct
> behaviour, and it hopefully satisfies Florian's use-case for CSI :)

It does, the ping result basically acts as notification that the stream
state change has been completed. Thanks to everyone working on this.

- Florian




signature.asc
Description: OpenPGP digital signature

Re: [Standards] LAST CALL: XEP-0320 (Use of DTLS-SRTP in Jingle Sessions)

On 8/26/15 9:59 AM, XMPP Extensions Editor wrote:

This message constitutes notice of a Last Call for comments on XEP-0320 (Use of 
DTLS-SRTP in Jingle Sessions).

Abstract: This specification defines how to use DTLS-SRTP (RFC 5763) in the 
Jingle application type for the Real-time Transport Protocol (RTP) as a way to 
negotiate media path key agreement for secure RTP in one-to-one media sessions.

URL: http://xmpp.org/extensions/xep-0320.html

This Last Call begins today and shall end at the close of business on 
2015-09-07.

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. It's a bit hacky in places but I think it's OK to sacrifice 
elegance to practicality. :-)



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


At &yet we're using this in jingle.js:

https://github.com/otalk/jingle.js


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


Not really, and this improves the security situation because DTLS-SRTP 
is highly desirable (and required for WebRTC).


In an ideal world we would all have a clearer understanding of Jingle 
security preconditions, which is unhelpfully spread across XEP-0166 and 
an expired Internet-Draft:


http://xmpp.org/extensions/xep-0166.html#preconditions

https://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02

I talked with the author of XEP-0320 last week about that (hi Fippo!) 
and I got mostly comfortable with the approach he's taken in XEP-0320, 
i.e., advertising the keying material for the transport layer by making 
the  element a child of the  element. Another 
approach would be to make the  element a child of the 
 element as we did in draft-meyer-xmpp-e2e-encryption. 
However, Fippo mostly convinced me that this  element is 
used for DTLS-SRTP encryption and thus is associated with the transport 
layer. What exactly we use the  element for is another 
question that we need to sort out separately.


Thus I'm OK with this approach to setting up DTLS-SRTP.


5. Is the specification accurate and clearly written?


I think the spec needs to make it clear which values of the 'setup' 
attribute must be supported from RFC 4145. In particular, I think the 
value "holdconn" (which means "The endpoint does not want the connection 
to be established for the time being") doesn't make sense in the Jingle 
context because we're not really using the 'setup' attribute here as 
part of an offer/answer exchange (see RFC 3264).


Peter

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Matthew Wild]

On 22 September 2015 at 21:53, Peter Saint-Andre - &yet
 wrote:
> On 9/22/15 11:48 AM, Florian Schmaus wrote:
>>
>> On 26.08.2015 17:59, XMPP Extensions Editor wrote:
>>>
>>> This message constitutes notice of a Last Call for comments on XEP-0352
>>> (Client State Indication).
>>>
>>> Abstract: This document defines a way for the client to indicate its
>>> active/inactive state.
>>>
>>> URL: http://xmpp.org/extensions/xep-0352.html
>>>
>>> This Last Call begins today and shall end at the close of business on
>>> 2015-09-07.
>>>
>>> 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?
>>
>> No.
>>
>>> 5. Is the specification accurate and clearly written?
>>
>> I'd like to see https://github.com/xsf/xeps/pull/44 merged.
>
>
> I'd love to see some list discussion about that suggestion. :-)
>
> The proposed text is:
>
> ###
>
> XMPP requires stanzas to be processed in order as per &rfc6120; 10.1.
> Especially "If the server's processing of a particular request could have an
> effect on its processing of subsequent data it might receive over that input
> stream..., it MUST suspend processing of subsequent data until it has
> processed the request.". As a result, all actions triggered by a CSI nonza
> sent to the server must happen before processing further requests from the
> same client to the server.
>
> For example: A client sends a CSI active nonza, followed by an XMPP Ping
> request to the server. The server first changes the CSI state to active and
> flushes all eventually queued stanzsa. After the state has been restored to
> 'active' and all resulting stanzas have been put on the wire, the server
> sends the pong.
>
> 
>
> 
>  type='get'>
>   
> 
>
> 
>
>  type='result'/>
>
> 
>
> ###
>
> Thoughts?

+1 to Florian's text. It clarifies what I believe to be the correct
behaviour, and it hopefully satisfies Florian's use-case for CSI :)

Regards,
Matthew

Re: [Standards] XEP-0280: vs.

[Dave Cridland]

On 17 September 2015 at 11:12, Florian Schmaus  wrote:

> On 16.09.2015 23:26, Dave Cridland wrote:
> > On 16 September 2015 at 22:21, Florian Schmaus  > > wrote:
> > > The last time this came up, many many months ago, I recall there
> not
> > > being consensus to change.  But that was then and this is now.
> > >
> > > What are implementers doing today?
> > >
> > > * Are implementations using XEP-0280's ?
> > > * Are implementations using XEP-0334's ?
> >
> > Smack's doing 
> >
> > > * Are implementations supporting both, but favoring XEP-0334's
> ?
> >
> > I would switch to xep334 in an instant. Kurt has a valid point about
> > xep334  being not as strict as . Hence I think we
> > should change that bit in xep334 and incorporate the semantics of
> > xep280's .
> >
> >
> > The point of '334 is that it's pure a hint and cannot be relied upon to
> > provide any particular behaviour.
> >
> > I think changing that would probably be a mistake.
> >
> > Despite your argument to the contrary, I think you and Kurt have
> > convinced me that we should keep Carbons (and ) as-is.
>
> I get your point. But it feels wrong to define nearly identical
> extension elements in two XEPs. The author of xep334, Matthew Wild,
> already expressed his willingness to change xep334 so that it can be
> re-used in xep280. Therefore I'm all for changing xep334, then issue a
> last call for it, ideally advance it to draft, then issue another last
> call for a xep280 version using xep334 elements, and finally advance it
> to draft.
>
>
So summarizing...

Procedurally:

If we don't switch, then Carbons goes through to Draft now, and Hints
either loses  or has a duplicate with softer requirements.

If we do switch, then Carbons is delayed and has a version bump, and Hints
needs editing and goes through Last Call to Draft.

Technically:

 is a mandatory part of Carbons.

 is an expression of opinion from the sender that Carbon copying
and similar will not be useful or desirable.

Which semantics make more sense?

(And by the way I'd rather rephrase XEP-0334 in that way).


> If we don't fix it right now, we will potentially never get another
> chance to fix it.
>

Not really true, we get to wonder if  is useful in the face of
 at a later date.

But even if you were right, and certainly some options close on this
decision, there is the question of whether this actually matters much.

The only path I strongly object to would be making any of XEP-0334's Hints
have mandatory (or even recommended in the RFC 2119 sense) behaviour.


>
> - Florian
>
>

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Kevin Smith]

On 22 Sep 2015, at 21:53, Peter Saint-Andre - &yet  wrote:
> 
> On 9/22/15 11:48 AM, Florian Schmaus wrote:
>> On 26.08.2015 17:59, XMPP Extensions Editor wrote:
>>> This message constitutes notice of a Last Call for comments on XEP-0352 
>>> (Client State Indication).
>>> 
>>> Abstract: This document defines a way for the client to indicate its 
>>> active/inactive state.
>>> 
>>> URL: http://xmpp.org/extensions/xep-0352.html
>>> 
>>> This Last Call begins today and shall end at the close of business on 
>>> 2015-09-07.
>>> 
>>> 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?
>> No.
>> 
>>> 5. Is the specification accurate and clearly written?
>> I'd like to see https://github.com/xsf/xeps/pull/44 merged.
> 
> I'd love to see some list discussion about that suggestion. :-)
> 
> The proposed text is:
> 
> ###
> 
> XMPP requires stanzas to be processed in order as per &rfc6120; 10.1. 
> Especially "If the server's processing of a particular request could have an 
> effect on its processing of subsequent data it might receive over that input 
> stream..., it MUST suspend processing of subsequent data until it has 
> processed the request.". As a result, all actions triggered by a CSI nonza 
> sent to the server must happen before processing further requests from the 
> same client to the server.
> 
> For example: A client sends a CSI active nonza, followed by an XMPP Ping 
> request to the server. The server first changes the CSI state to active and 
> flushes all eventually queued stanzsa. After the state has been restored to 
> 'active' and all resulting stanzas have been put on the wire, the server 
> sends the pong.
> 
> 
> 
> 
> /balcony' id='ping1' type='get'>
>  
> 
> 
> 
> 
> /baclony' 
> from='capulet.lit' id='ping1' type='result'/>
> 
> 
> 
> ###
> 
> Thoughts?

That text seems consistent with in-order processing requirements, so it doesn’t 
hurt to spell it out.

/K

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Kurt Zeilenga]

I support adding of the proposed text.  — Kurt

> On Sep 22, 2015, at 1:53 PM, Peter Saint-Andre - &yet  
> wrote:
> 
> On 9/22/15 11:48 AM, Florian Schmaus wrote:
>> On 26.08.2015 17:59, XMPP Extensions Editor wrote:
>>> This message constitutes notice of a Last Call for comments on XEP-0352 
>>> (Client State Indication).
>>> 
>>> Abstract: This document defines a way for the client to indicate its 
>>> active/inactive state.
>>> 
>>> URL: http://xmpp.org/extensions/xep-0352.html
>>> 
>>> This Last Call begins today and shall end at the close of business on 
>>> 2015-09-07.
>>> 
>>> 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?
>> No.
>> 
>>> 5. Is the specification accurate and clearly written?
>> I'd like to see https://github.com/xsf/xeps/pull/44 merged.
> 
> I'd love to see some list discussion about that suggestion. :-)
> 
> The proposed text is:
> 
> ###
> 
> XMPP requires stanzas to be processed in order as per &rfc6120; 10.1. 
> Especially "If the server's processing of a particular request could have an 
> effect on its processing of subsequent data it might receive over that input 
> stream..., it MUST suspend processing of subsequent data until it has 
> processed the request.". As a result, all actions triggered by a CSI nonza 
> sent to the server must happen before processing further requests from the 
> same client to the server.
> 
> For example: A client sends a CSI active nonza, followed by an XMPP Ping 
> request to the server. The server first changes the CSI state to active and 
> flushes all eventually queued stanzsa. After the state has been restored to 
> 'active' and all resulting stanzas have been put on the wire, the server 
> sends the pong.
> 
> 
> 
> 
> 
>  
> 
> 
> 
> 
>  type='result'/>
> 
> 
> 
> ###
> 
> Thoughts?
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://andyet.com/