Re: [Standards] Proposed XMPP Extension: WebSocket S2S

[Lance Stout]

> Everything mentioned in RFC 7395 [1] should be followed with the following 
> changes:

Chiming in as an author of RFC 7395  :)


> For c2s, RFC 7395 [1] requires replacing the 'jabber:client' namespace with 
> 'urn:ietf:params:xml:ns:xmpp-framing', for s2s, the 'jabber:server' namespace 
> should be replaced with 'urn:ietf:params:xml:ns:xmpp-framing-server’.

First, I need to point out that is not quite what 7395 requires. The framing 
mechanism defined in 7395 was intended to be generically reusable and not 
directly tied to C2S, or even WebSocket (WebRTC data channels were particularly 
in mind).

Yes, in a C2S stream, http://etherx.jabber.org/streams;> is replaced by . But importantly, each framed 
stanza MUST include its own correct namespace, which is still jabber:client for 
C2S stanzas. A very abbreviated example:

C: 
…
C: …

So, for S2S we’re already good in terms of namespacing to send jabber:server 
namespaced stanzas:

S1: 
…
S1: …

However, we still would want to distinguish between opening up a C2S or S2S 
WebSocket connection to know how to respond. The fact that a 7395 WebSocket 
connection is interpreted as a C2S connection is entirely because it sets the 
WebSocket Subprotocol  header to “xmpp”. I suggest that we define a Subprotocol 
of “xmpp-server” to signal S2S connections instead of creating a new, otherwise 
duplicate, namespace.

Defining a new WebSocket Subprotocol entry with IANA probably would be best 
done in an Internet-Draft/RFC, but we’ve migrated things from XEPs to RFCs 
before.



> Connection details are discovered by using Discovering Alternative XMPP 
> Connection Methods (XEP-0156) [2]


This is what 7395 says to follow already.

Although, XEP-0156 might be where we _would_ want to define a server namespace 
(urn:xmpp:server-alt-connections:* maybe?) for S2S vs C2S discovery.



There are two other matters to consider for S2S: connection directionality and 
dialback.

For connection directionality, traditional S2S connections are one-way, 
requiring a pair or more of connections for back-and-forth communication. As 
someone that’s worked with XMPP for a while, _I_ would not be surprised if 
server developers used existing logic and sent data one-way on a WebSocket 
connection, unless the bidi stream feature from XEP-0288: Bidirectional 
Server-to-Server Connections was negotiated. But that might need to be called 
out explicitly in this XEP/I-D because people will otherwise probably consider 
a WebSocket connection to always be bidirectional as a matter of course.


For XEP-0220 Dialback, nothing particularly special needs to be done to 
accommodate it, but it would be helpful to include an example of what it would 
look like due to the framed stream namespacing rules. Something like:

S: …
   
In particular, noting that a dialback element would need the xmlns:db defined 
on the element because there is no wrapping  element to inherit it from.

It would also be acceptable to include a xmlns:db declaration on the  
element to match what is done for , even though it does nothing on its 
own.

S: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0353: Rework whole spec, namespace bump

[Lance Stout]

+1 on merging. There’s been a lot of foundational improvements since mid-2014 
that we can safely rely on now, so these changes make sense.


There is one scenario that the :0 version with its split accept/proceed allows 
that I don’t think the :1 does: stop your other devices ringing while silently 
ignoring the request. Debatable if that should be a supported case, but :1 does 
require leaking a JID resource to stop your other devices ringing.


/Lance

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

Re: [Standards] LAST CALL: XEP-0339 (Source-Specific Media Attributes in Jingle)

[Lance Stout]

> 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, I have.

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

No.

> 5. Is the specification accurate and clearly written?

Yes.

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

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

[Lance Stout]

> 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, I have.

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

No.

> 5. Is the specification accurate and clearly written?

Yes.

___
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

[Lance Stout]

An additional reference from XEP-0301 (In-Band Real Time Text) in support of 
this:

https://xmpp.org/extensions/xep-0301.html#unicode_character_counting



> On Dec 17, 2019, at 3:18 AM, p...@bouah.net 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] Detecting an ended file transfer

[Lance Stout]

> 1) The transport method has a way of closing the stream. This exists for
> IBB, via the `` element. It also exists for S5B, via closing the
> TCP connection.

Potential race condition since signaling and media are flowing in different 
planes.

You can’t be sure that the ‘done sending’ signal arrives after the peer has 
finished
receiving all of the data. IBB can do it, because signaling and data _are_ 
flowing
in the same plane, since it is in-band.

> 2) Counting the bytes until you receive as many bytes as promised by the
> file offer. This works if the non-mandatory `` tag is present in
> the file offer.

That is the intended method, yes.

The size is listed as a SHOULD specifically to allow the case where the file 
being
sent is actually being generated on demand. In which case, the size wouldn’t
be known until the end. For any other case, the size would be known and would
be included.

> Could the XEP be amended to clarify how to do this? If 2) is the
> supposed method, could the XEP be changed so that the `` tag is
> mandatory for offering a file?

Mandating the size in the offer wouldn’t suffice, as covered above. What would 
be
an appropriate change would be to have the checksum update include the final
size information (especially if it wasn’t included in the offer). The schema 
already
allows it, the XEP just needs to mention it. I honestly thought it already did, 
but this
particular situation did get overlooked.

I would consider such an update safe enough to keep in the current namespace.


/Lance

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

Re: [Standards] PR #793 - XEP-0166: Relax transport element requirement

[Lance Stout]

My review of the PR is that, although I agree entirely with the sentiment, this 
change would be breaking, and by itself is not worth the namespace fracturing.

Looking at Jingle code I currently have deployed in production systems, the 
expectation that a session or content accept action includes a transport 
element is present, and this change would trigger bad-request errors.

Generating and sending an “empty answer” transport element (for whatever an 
empty answer would look like for the transport in question) is the cleanest 
solution that still works in the existing namespace. I would prefer not sending 
the element at all, but again, not worth the namespace bump for such a minor 
detail.

/Lance

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

Re: [Standards] Jingle (File Transfer) Session termination

[Lance Stout]

Both sides locally terminated the session, so both sides should be in the ENDED
state. Period. Full stop.

The fact that one side ended up getting an error response to their
session-terminate is irrelevant, because (as you quoted) when locally
terminating the session, the session state moves to ENDED without regard to any
ack from the other side, whether that be a success, error, or no response at
all.

So the session still showing as hanging in the Gajim UI is a client/library bug.
It seems to be waiting for a successful IQ-result before fully cleaning up and
treating the session as ended.



That said, here's a summary of the traffic logs you sent:

  |ruff (gajim)  me (tp)

 1| session-initiate -->
 2|  <--session-info
 3|  <--iq-result(1)
 4|  <--  content-reject
 5| iq-result(2) -->
 6| iq-result(4) -->
 7|  <--   session-terminate
 8| session-terminate-->
 9|  <-- iq-error(8)
10| iq-result(7) -->


Again, none of this changes the conclusion from above, but looking through this
could be helpful anyway.


The telepathy side is sending a session-info for RTP ringing before even sending
iq-result(1) acknowledging the session-initiate. That's not particularly
harmful here, but it 1) really shouldn't be there at all since there are no RTP
applications involved in the session and 2) should at least have been sent after
iq-result(1). It suggests that Telepathy is probably not queueing local actions,
which could lead to state bugs.

As you stated, the telepathy side doesn't understand the offered file-transfer
application. Telepathy has the correct interpretation here that it should reject
that particular content. To do so, it is sending a content-reject action, which
is perfectly legal. And immediately after doing so, it notices that there are no
remaining contents, and so sends a session-terminate.

That is a perfectly legal sequence of actions to take, but this particular
combination suggests that the Jingle library could be improved here. The spec
mandates that the _receiving_ side of a content-reject or content-remove send
a session-terminate if there are no remaining contents. The, unfortunately
unwritten, implication is that the _sending_ side should just go ahead and send 
a
session-terminate if it is going to reject or remove the last content. This 
whole
scenario would have been avoided if Telepathy behaved that way.

The Gajim side of the session after receiving the content-reject dutifully
follows the spec and terminates the session because there are no remaining
contents.

We are left in what would otherwise be a tie-breaking situation. Notice
that both sides send a session-terminate before receiving the respective
iq-result/iq-error replies, which means both sides attempted to change the
session in the same ways without being aware of the other also trying to do
so. The tie-breaking rules don't explicitly cover session-terminate (because
once sent, the session is over and tie-breaking wouldn't change anything), but
Gajim (as the tie-winning initiator side) would be valid to reply with an
iq-error(7) with a tie-break error condition.


/Lance


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

Re: [Standards] JingleFT XEP encryption conflicts

[Lance Stout]

> Lance might have other opinions, but I read XEP-0234 as saying "this isn't 
> the place to look for transport-layer encryption, if it's defined anywhere it 
> would be in XEPs 260 and 261", whereas the latter specs are saying "um, our 
> authors haven't defined that yet but maybe we need to be updated with some 
> proper security methods, eh?”

Right :)


E2E security in Jingle can be negotiated in three different places:

1) As part of the application
2) As part of the transport
3) As an additional layer between the transport and the application


In order for a Jingle content to be considered ‘secure’, at least one of those 
three options needs to be ticked.



An example of (1) is the RTP application, which handles its own E2E encryption 
(using the SRTP profile). That is why the  for an RTP application 
can include an  element to specify parameters for SDES or ZRTP 
(and technically could be updated to allow indicating the use of DTLS-SRTP). 
This is also why RTP never needed to use the Jingle  element.



We don’t quite have a XEP that fully shows (2), but WebRTC datachannels would 
fall into this category because they are SCTP on top of DTLS. That is, you 
*have* to negotiate DTLS in order to even have a WebRTC datachannel transport; 
the transport never operates as ‘plaintext’.



The original design of Jingle was that option (3) would be the common approach. 
The Jingle  element would allow negotiating TLS or DTLS on top of 
any transport. Thus things like SOCKS5 and IBB didn’t need to include how to do 
TLS, etc, because that was going to be defined by 
https://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02. Unfortunately, 
that spec was never finished for some reason. (Probably because it wasn’t a 
requirement for RTP?)

The integration of OMEMO with Jingle would be to define this style of generic 
security layer.




/Lance


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

Re: [Standards] Proposed XMPP Extension: Spoiler messages

[Lance Stout]

The  element can be used to display human readable text via
the `hint` attribute, so it should be noted that multiple 
elements could be present with different `xml:lang` values.

It might be worth making the hint text the character data of the 
 element instead of an attribute.



/Lance

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

[Standards] 2016-05-25 Council Meeting Minutes

[Lance Stout]

Logs: http://logs.xmpp.org/council/2016-05-25/#15:15:36

0) Roll call

All present

1) Accept as Experimental?  http://xmpp.org/extensions/inbox/spam-report.html

All +1

2) Accept as Experimental? http://xmpp.org/extensions/inbox/userrating.html

MattJ +1
Rest to vote on list

There are concerns about similarity with XEP-0275 Entity Reputation.

3) Date of next

2015-06-01 16:15Z

4) AOB

A question about how PRs from Github are added to the agenda.


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

Re: [Standards] A new SASL Profile strawman

[Lance Stout]

> On May 4, 2016, at 7:00 AM, Dave Cridland  wrote:
> 
> Folks,
> 
> I had a nice chat with Ralph Meijer, and we idly discussed replacing the SASL 
> profile in order to gain access to 2FA, fold in the Stream Resumption 
> (Florian Schmaus's design, in effect), and make it a little more extensible, 
> particularly with more detailed error messaging.
> 


The basic proposal here looks sensible to me, and support for 2FA would be 
awesome. However, it does carry the cost of needing to upgrade one of the 
fundamental parts of XMPP session negotiation.


To be honest, if any such price is to be paid, I want it to bring significant 
benefits that can simplify the startup process.


The proposal is already tying itself to stream management, so let's push that 
further:

1. Opting to use new-SASL is also enabling stream management. This seems to be 
implied already for the proposal to meet its goals, but it would need to be 
more explicit.
2. JID binding included in new-SASL success response, so no need to manually 
request a binding (maybe even go so far as to not allow requesting a resource, 
just be assigned one)


Yes, this combines several existing, but related, stream features. This 
combination of features is one of the most well-trod of cow paths, and is what 
inflates the number of round-trip requests needed to start a usable session.


/Lance


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

[Standards] 2016-03-16 Council meeting minutes

[Lance Stout]

# 2016-03-16 Council Meeting

Logs: http://logs.xmpp.org/council/2016-03-16/#16:15:04

## Roll call

- Lance
- Dave
- Tobias
- MattJ

Peter was absent


## Last Call on XEP-0371: Jingle ICE Transport Method (supersedes XEP-0176)

Lance, Matt, Tobias, Dave +1

Dave would like to see discussion on the standards list.

Peter to vote on list.


## Proposed Extension: Instant Stream Resumption (ISR)

Resubmission addressing council feedback.

All to vote on list.


## https://github.com/xsf/xeps/pull/82

Agenda item was added by Peter, but it is unclear what Council is meant to 
address.

Will raise again at next meeting.


## Date of next

Next week, same time, same place.


## AOB

Dave brought up compliance suites, and asked who, if anyone, had volunteered to 
write those.

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

Re: [Standards] Commands in the context of a conversation

[Lance Stout]

> This smells quite a bit like XEP-0050 to me.  Perhaps like the following:
> 
> 
>   Hello, bot!
> 
> 
> 
>   Welcome! What can I get you today?
> 
>node='http://jabber.org/protocol/commands'>
>   
>   
>   
> 

Yep. This is Section 2.3 of XEP-0050 
(http://xmpp.org/extensions/xep-0050.html#announce)


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

Re: [Standards] proposal to remove Managing Multiple IBB Sessions from XEP-0261

[Lance Stout]

I'm +1 for removing Section 2.4.


After taking a glance through existing implementations I'm aware of, I'm not 
seeing that anyone has implemented this feature.




To clarify on-list for future reference, here is why Section 2.4 is problematic:


The Jingle IBB transport is limited in only being able to signal a single IBB 
channel at a time, like so:



Well, if I'm trying to signal an application type that wants to use multiple 
channels, I'm now stuck with a problem: I can only send one of the channels in 
my session-initiate or content-add (so which channel?) and have to send the 
rest via transport-info (before or after the other side accepts?). My initial 
offer will always be incomplete due to this protocol design, which makes IBB 
different from other transport types.


But why do I want to use multiple channels under one transport? That's 
generally only needed if the application type needs to use 'components' (like 
how the RTP application needs a socket for RTP and optionally a second for 
RTCP). The trick with components is that they need predefined names so that 
application instances can reliably identify them. E.g., RTP uses component "0" 
for RTP and component "1" for RTCP. Can we do that with Jingle IBB and its 
multi-session feature? No, we can't reliably identify components. There is a 
'sid' attribute which comes close, but can't be reliable since we're using that 
in the XEP-0047 IBB layer, running the risk of multiple IBB sessions with the 
same sid between the same two peers.

Consider an application type that needs a component named "A". If we tried to 
use the 'sid' attribute, and I have a single session with two contents with 
this application, there will be a collision trying to open an IBB session with 
a sid of "A" twice.


There are three ways of addressing these problems:

1) Ignore it
2) Remove the section (as Peter and I are proposing)
3) Update the spec to fix the problem


While I would like to go with option 3, the fact that Jingle IBB is meant to be 
the common fallback of last resort makes me extremely hesitant to introduce a 
new version.

That said, an ibb:2 protocol that fixed these issues would look something like 
this:


  
  





/Lance





smime.p7s
Description: S/MIME cryptographic signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Jingle updates (WIP)

[Lance Stout]

> Folks, I've been working (slowly) on updates to the Jingle specs so that we 
> can incorporate feedback, fix a few bugs, and track some of the more modern 
> RFCs and Internet-Drafts on these topics.


Thanks Peter for working on the Jingle specs!



> Jingle (core definition):
> http://xmpp.org/extensions/tmp/xep-0166-1.2.html


Some additional items to consider:


1) Using content-add/content-accept before session-accept

There is no guidance on how to use content-add and content-accept before
the session itself has been accepted. For example:

   Romeo --- session-initiate ---> Juliet

   Romeo <--- content-add --- Juliet

Should Romeo accept the content now, or does he need to wait for Juliet to
send the session-accept first?

The key issue here is content disposition. XEP-0269 (Jingle Early Media)
explains how accepting contents before session-accept is doable, but only
when the content disposition is "early-session".

The question is thus: Is it allowed to accept a content with "session"
disposition before the session itself has been accepted?

If the answer is yes, we have the odd case where the responder could
individually accept all offered contents (and start the application media
flows), without ever accepting the session itself. And maybe that's OK,
but it is something I ran across on accident while button mashing with a
live system (it caused a crash as I had never considered this case when
implementing).



2) content-reject vs content-remove

These two actions are very similar in that they both result in expunging
a content from the session. The main distinction between these actions is
that content-reject is specifically used in response to a content-add.

The question here is: If the responder does not want one of the contents in
the session-initiate, which action should be used to get rid of it?

The answer appears to be content-remove.

Which means that a responder can "reject" content two different ways.

This leads to a hidden state variable for contents: was the content
included in the initial session-initiate, or did it come from a later
content-add.

Declining a content from the initial session-initiate is a content-remove
action, and declining a content introduced via content-add is a
content-reject action.


Now, I know that the current text specifies this behaviour, but in a
roundabout way; a more explicit note that the origin action of a content
needs to be tracked would be good.

I would suggest that we don't need content-reject, in the same way that
we only have session-terminate for both rejecting and removing a session,
but that would be a backwards incompatible change. However, should we just
say that these are two names for the same action, and clients need to handle
both equivalently?



3) Framed Transports

Jingle currently classifies transports into two categories: Datagram and
Streaming. These are of course meant to mirror the behaviors of UDP and
TCP.

However, I would like to propose a third category: Framed. A framed
transport is packet based like a datagram transport, but also provides
reliability.


  | Transmission Mode | Reliability
===
Datagram  |Data packet| Unreliable
Framed|Data packet| Reliable
Streaming | Continuous Stream | Reliable


There are several network transports that can fit the framed model:

- WebSocket
- BOSH!
- WebRTC Data Channels (SCTP over DTLS)
- "Raw" SCTP (eg. DTLS over SCTP)




> Jingle RTP:
> http://xmpp.org/extensions/tmp/xep-0167-1.1.html

I don't think removing  is worth a namespace version bump by
itself. The  info is easy enough to process as it is.




> The primary TODO items now are adding some implementation notes to XEP-0166 
> (which Lance Stout has volunteered to do)

I am still working through writing up implementation notes. If you are
interested in reading about implementation experiences, here is a link:

https://gist.github.com/legastero/fa80e2366c448fd6e141

NB: This is still being written/edited, and is currently more of a blog
post to flesh out thoughts before formalizing into updates for XEP-0166.


/Lance






smime.p7s
Description: S/MIME cryptographic signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Jingle ICE Transport Method

[Lance Stout]

The prose has the original  but the example shows 
.


Aside from that nit, I'm +1 on publishing this version.


/Lance



smime.p7s
Description: S/MIME cryptographic signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Jingle ICE Transport Method

[Lance Stout]

Regarding the  end-of-candidates signal:

>  id='xv39z423'
> to='romeo@montague.example/dr4hcr0st3lup4c'
> type='set'>
>  action='transport-info'
>   initiator='romeo@montague.example/dr4hcr0st3lup4c'
>   sid='a73sjjvkla37jfea'>
> 
>   
> 
>   
> 


Placing a new element as a direct child of  is a bit more difficult 
for an implementation to process (it requires a new special case to look for it 
as opposed to being carried along in the  element data already). It 
also would be better to drop the :info: namespace and just include it in the 
new ice:0 namespace, especially since there is already the remote-candidate 
signal.


So something like:

>  id='xv39z423'
> to='romeo@montague.example/dr4hcr0st3lup4c'
> type='set'>
>  action='transport-info'
>   initiator='romeo@montague.example/dr4hcr0st3lup4c'
>   sid='a73sjjvkla37jfea'>
> 
>   
> 
>   
> 
>   
> 



- Lance




smime.p7s
Description: S/MIME cryptographic signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final

[Lance Stout]

> 1. What software has implemented XEP-0301? 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. [1]

Several open-source libraries now support RTT:

- Babbler (https://bitbucket.org/sco0ter/babbler)
- Strophe (via https://github.com/cvogler/trophyjs)
- Stanza.io (https://github.com/otalk/stanza.io + 
https://github.com/otalk/rtt-buffer)

Additionally, RTT is now being used in production by Talky (https://talky.io).


> 2. Have developers experienced any problems with the protocol as defined
> in XEP-0301? If so, please describe the problems and, if possible,
> suggested solutions.

Quite the contrary! Implementing XEP-0301 was a very enjoyable experience, as
every question I had while implementing ended up being directly answered in the 
XEP.

I believe the XEP fully covers the problems it sets out to address.


> 3. Is the text of XEP-0301 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.

It is very clear and unambiguous.

Seriously, Mark and Gunnar have gone remarkably out of their way to provide
all of the guidance needed to create an implementation. Not only for a complete 
implementation, there is guidance on how to extract the most value out of 
partial
support of RTT.



— Lance



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: Entity Versioning

[Lance Stout]

> This should be fine, I don't think I specified that it must use a bare
> JID anywhere, but I may try to find an example later that uses a full
> JID with resource part just to make it clear. I didn't throw it in
> with this round of edits though.

There is this text about constructing the aggregate token:

This aggregate token is calculated by constructing a string of
comma separated "bare JID:version" pairs



I don't think this will affect anything, but there is the odd item
to note, which is that ',' is a valid character in the localpart of a
JID. If you are depending on that as a separator for some reason, that 
might need to be adjusted.


> I've added a statement to make it clear how this should be handled.
> Since the actual value doesn't matter, we just sort as usual (and
> since we're constructing the JID:version pairs before sorting, we just
> end up sorting based on the version token).

Does that mean we really don't even need to use JIDs in the source string
for the aggregate token? Use a comma separated sorted list of version tokens?


> Unless I'm misunderstanding, this is already handled. You should be
> querying the same node for the aggregate token list (eg. if you're
> querying for a list of rooms, you query the MUC component or server,
> if you're querying for pubsub items, you might query the MUC component
> if it also provides pubsub, or you might query a separate entity which
> provides pubsub for that server. Wherever you would send a pubsub
> request would be where you'd query for a pubsub aggregate token).


Specifically, how would I request an aggregate token for the list that
this disco query would return:

http://jabber.org/protocol/disco#items; node="archived-rooms" />


I think that you'll need to update the aggregate token query to look like:

http://jabber.org/protocol/disco#items; node="archived-rooms" />



— Lance







smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: Entity Versioning

[Lance Stout]

>> However, it's not clear from the specification how a server can signal
>> removal (or lack of visibility)
> 
> That was an oversight on my part; I appear to have dropped our
> mechanism for that somehow when compiling this from our internals
> system into an XEP. I'll update soon. Thanks.


This was where I got tripped up when reviewing, so thanks for sending the PR to 
fill in that missing piece :)




I do have some questions about Section 5.3 Aggregate Tokens.

The spec describes its use with MUC rooms, but is providing versioning for 
disco#items to do it (which makes sense given that providing this sort of 
universal API is one of the stated goals for entity versioning).

So, because this is versioning disco#items in addition to rosters, there are 
some things that need additional consideration when using aggregate tokens:

- Items could have a JID with a resource, so not just bare JIDs.
- Results might contain multiple items with the same JID, but different node 
values.
- Queries can specify a node

These concerns can still apply to MUC services, because a MUC host could 
include any of the above forms in its disco#items responses (even with no node 
specified). For example, I've worked with MUC domains that also provided 
PubSub, so the disco#items results included a mixture of PubSub nodes and MUC 
rooms.


The mechanism for requesting the aggregate token only accepts a namespace as 
input (or at least that is what I gathered from the examples, the text doesn't 
explain the relationship here). This is workable for rosters, but starts having 
issues with disco#items because we would also need to specify the queried node. 
Using this beyond disco#items could face additional challenges where there 
might be multiple request types under the same namespace but with different 
element names.


Given that, I would be tempted to explore something like the below, but even 
this has its drawbacks:


  


  0

  



  
0514fc90e6c7981b06bbb2173bb8ef03

  42

  


Meaning: use the existing protocol method to fetch the list, using RSM to 
request sending back 0 items, but include the aggregate token that would match 
the parameters of the query.

It was mentioned that there was a second piece to the versioning work HipChat 
has done to specify requesting/providing subsets, so these issues might already 
be solved in that portion, but I would like to see them addressed here.



For basic MUC, the situation is certainly simplified and is a good starting use 
case, but I don't see how I could reuse this part of the spec as-is to do 
aggregate tokens for, say, listing PubSub nodes and items.



- Lance





smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method

[Lance Stout]

 I don't see this XEP resolves any of these.

That is correct.

However, this XEP was never intended to solve those issues, in the exact same 
way that no other Jingle transport (IBB, SOCKS5, ICE, raw UDP, etc) is intended 
to directly solve those problems. These are things that apply to *all* Jingle 
session types, not just file transfer, independent of transport mechanisms. 

This XEP is not to be confused with the HTTP upload storage slot proposal 
(http://xmpp.org/extensions/inbox/http-upload.html), which addresses the 
problem of provisioning and populating some URIs in the first place, a related 
but different problem from exchanging and negotiating how those URIs will be 
used by a peer (which is the purpose of this XEP). A client using a Jingle HTTP 
transport is very likely to first use the HTTP slot provisioning process in 
order to have URIs it can then use for Jingle negotiation.

The impetus for this XEP indeed was to allow clients to use Jingle FT with the 
proposed HTTP storage slots, and at the same time provide a simpler 
implementation target for JingleFT (don't need to implement the transport 
complexities of IBB/SOCKS5/ICE, just the basics of Jingle session management).



 1) How is it possible to get several URLs during HTTP Upload? For
 example, an HTTP server may generate previews and return
 them with the main URL. This is done in a lot of pics hostings and is
 very handy for a client.

What happens happens to data after the Jingle transfer has completed is beyond 
the scope of a transport mechanism.

As far as a client using a Jingle HTTP transport is concerned, the URIs might 
as well be considered one-time-use. There is no requirement or guarantee made 
by this XEP that a URI be usable after the session has ended. That is left to 
whatever mechanism is used to provision the URIs in the first place (e.g. HTTP 
upload slots).

Negotiating the uploading of multiple files should be done with multiple Jingle 
contents as described in XEP-0234, in which case you would have a single upload 
URI for each.


 2) How is it possible to offer HTTP Download (see 7.1) with multiple
 files and some of those are thumbnails? So, for example, a receiving
 entity sees a thumbnail first and downloads the original content if she
 likes it.

This is addressed by XEP-0264 (File Transfer Thumbnails), but it does have some 
limitations in its current form. Namely, it requires the use of XEP-0231 (Bits 
of Binary) for retrieving the thumbnail data, which limits their use.

To that end, I submitted an update to XEP-0264 today to get it out of the 
Deferred state, allow it to use other URI types, and expand its scope to more 
than just file transfer thumbnails (for example, attaching a thumbnail preview 
to RTP video streams). A rendered version of the PR is available at 
http://legastero.github.io/customxeps/extensions/xep-0264.html.


 3) How this XEP can be combined with MUC? Let's say a client did HTTP
 Upload, how will it share the URL in MUC? Will it use procedures from
 7.1 directly to MUC room jid?

Use within MUC is an issue with any Jingle session type and transport. XEP-0358 
(Publishing Available Jingle Sessions, aka JinglePub) is intended as a solution 
for that problem. JinglePub works via a similar mechanism as what is proposed 
in 
https://github.com/processone/ejabberd-saas-docs/blob/master/xmpp-specs/http-filetransfer/http-filetransfer.md,
 but is usable with any type of Jingle session.


 4) How this XEP can be used when a user wants to share an HTTP Uploaded
 URI with an offline contact?

Starting a Jingle session with an offline user is naturally an issue with any 
Jingle session type. Using XEP-0353 (Jingle Message Initiation) or XEP-0358 in 
combination with XEP-0357 (Push Notifications) is intended as a foundation for 
a general solution.




- Lance







smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] [Council] Minutes 2015-08-05

[Lance Stout]

 On Aug 13, 2015, at 7:11 AM, Kevin Smith kevin.sm...@isode.com wrote:
 
 2) Accept as experimental? http://xmpp.org/extensions/inbox/http-upload.html
 
 All to vote on list
 
 I’m ever so marginally +1 on this. I am very uncomfortable with introducing 
 another file transfer negotiation mechanism, and I believe this should be 
 done with Jingle (for the negotiation), which has many advantages (the server 
 could offer HTTP upload as well as other mechanisms, etc.), so this does meet 
 one of my criteria for blocking a protoXEP.


So, based on discussion in the other thread about the HTTP Upload proposal, I 
wrote up what a Jingle transport based on HTTP transfers could look like: 
http://legastero.github.io/customxeps/extensions/http-transport.html


There were a few things I learned in the process:

1. While it would be possible to use this to negotiate uploading a file to a 
server, there is not yet any Jingle mechanism telling the server that it should 
in turn expose the shared content with others (COLIBRI kinda does this, but 
that's just for RTP streams and is still outside of the Jingle negotiation 
process). We would need to do something like expand JinglePub (XEP-0358) so 
that including a jinglepub / element in the session-initiate signals that we 
want the session content to be available for others to request. While I think 
this is desirable as a long term and more general solution, it gets further 
from the simplicity of the original proposal here.

2. The HTTP upload proposal is more accurately discussed in term of storage 
space and URI provisioning, not file transfer directly. For example, using the 
Jingle HTTP transport above, I could request a storage slot and signal the 
details of that slot to another client, requesting that other client to upload 
a particular file to my file server. That is powerful, and it requires a URI 
provisioning process outside of Jingle. We've had a similar situation for 
Jingle RTP with COLIBRI (XEP-0340). Any client-client transfer situation will 
end up with one of the clients needing to ask *something* to provision URIs.



(puts on council voting hat)

All of that said, I am +1 on a modified form of HTTP-Upload (Sam and Mickaël 
had some good improvements that should be reviewed and incorporated).





- Lance



smime.p7s
Description: S/MIME cryptographic signature

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

[Lance Stout]

The reasoning behind creating a FT:4 was to leverage the core semantics of 
Jingle versus continuing to reinvent them inside of FT to solve some of the 
remaining open items in the FT:3 spec.

(The idea here being that a general Jingle session management implementation 
should have a well lit path for how to use its existing session management 
tools  data to support file transfer.)


Thus, instead of a bundle of files inside a single Jingle Content, there is a 
separate Content per file. That solves the unresolved issues in FT:3 about how 
to add (and remove!) additional files to the transfer session while it is in 
progress. In FT:4, we use the standard Jingle content-* actions. A nice side 
effect is that it means that the files do not need to wait for each other to 
download over a single connection, the data can be sent in parallel via 
multiple connections.

However, in the process of editing and creating FT:4, the request/ and 
offer/ wrappers were removed, which appears to have removed the ability to 
request a file, but that case is still doable with FT:4. It now requires using 
core Jingle semantics instead of something inside FT itself. Namely, Jingle 
Contents may specify which side of the session is supposed to send data. This 
is an example of requesting files using FT:4


iq to=fri...@example.org id=ft4 type=set
  jingle xmlns=urn:xmpp:jingle:1 action=session-initiate 
sid=jrk2o4oi24i3u24o
content name=file-request-1 creator=initiator senders=responder
  description xmlns=urn:xmpp:jingle:apps:file-transfer:4
file
  hash xmlns=urn:xmpp:hashes:1 
algo=sha-165ea0164c91de2197956ed143099b90ff37d699e/hash
  nametest.txt/name
  range/
/file
  /description
/content
content name=file-request-2 creator=initiator senders=responder
  description xmlns=urn:xmpp:jingle:apps:file-transfer:4
file
  hash xmlns=urn:xmpp:hashes:1 
algo=sha-1da39a3ee5e6b4b0d3255bfef95601890afd80709/hash
  namefor-good-measure.txt/name
  range/
/file
  /description
/content
  /jingle
/iq


(Likewise for transfer offers, the Content should include `senders=initiator` 
to indicate as such.)



I'm currently writing up patches to submit as a PR to add a section covering 
requesting files and the use of the content senders attribute, along with some 
additional examples and editorial fixes.


- Lance



smime.p7s
Description: S/MIME cryptographic signature

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

[Lance Stout]

 I have some questions regarding the business rules:
 
 - Why enforce a single id at a time ? I think it can be useful to have
  multiple ids in a message:
 
  message ...
[...]
stanza-id by=r...@muc.example.org id=aaa/
stanza-id by=arch...@myserver.com id=bbb/
  /message
 

This is allowed. The restriction here is that you can only have one stanza-id 
/ with a given JID in the 'by' attribute. So the above is ok, but this is NOT 
ok:

 message ...
   [...]
   stanza-id by=r...@muc.example.org id=aaa/
   stanza-id by=r...@muc.example.org id=bbb/
 /message


 - Why put the client-id in the stanza-id ? 

It has been suggested (but not yet incorporated into 359) that client-id be 
replaced by the simple lack of a 'by' attribute. (If no 'by' is present, the 
entity that stamped the ID is the stanza sender, pending the support checks 
that should be added in the security considerations that I mentioned on list 
earlier.)


- Lance



smime.p7s
Description: S/MIME cryptographic signature

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

[Lance Stout]

 Version 0.1 of XEP-0359 (Unique and Stable Stanza IDs) has been released.


\o/


Some feedback on this new version:


1. Disco feature is needed to discover that an entity generates ids, and that 
it therefore is able to assure that ids attributed to it are valid by stripping 
 overwriting ids that it routes.

2. Security considerations needs to include that a given id should only be 
accepted for use if the by attribute is for the JID that is expected and that 
the JID is able to assert the id. (Don't trust ids from room messages unless 
the by attribute is the room JID AND the room lists the stanza-id feature in 
its disco features)



- Lance



smime.p7s
Description: S/MIME cryptographic signature

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

[Lance Stout]

/Puts on Council hat

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


Technical nitpicks for proposal as is:

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




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

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

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


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



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


To find methods supported by the Resource:

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


Discovering parameters of the post method for the Resource:

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


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



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



- Lance




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: Push

[Lance Stout]

 On Mar 25, 2015, at 8:34 PM, Anu Pokharel i...@monal.im wrote:
 
 Hi all, 
 I make an XMPP app on iOS called Monal. Much of my comments are based on my 
 experiences developing  an XMPP client on iOS  for the past 6 years. My 
 concerns may be Apple specific in some places but since the intent of the XEP 
 is for a very general implementation,  these issues should be considered.  
 Apologies for resurrecting this discussion. 

No apologies necessary! The discussion is still underway.


 The proposed XEP  does not seem to address token expiration. On Apple 
 platforms (and likely others) the push token will change periodically.  This 
 information is provided on a feedback channel to the App server but there is 
 no way for it to communicate this to the XMPP server. There is really no way 
 for the client to know it’s token has expired so It will not know to request 
 a new one from the push service and the messages will just be lost.  In 
 addition even if the client were to somehow know, there doesn't seem to be a 
 way for the client to refresh its token with the XMPP server. 

On iOS, and I expect this to be a general case on mobile, your app is supposed 
to register itself for remote push notifications every time it launches, 
precisely because the tokens/deviceIDs can expire and change.

Which means, on startup, an iOS app will need to:

1. Register with the OS/APNS for a device ID (call it DeviceToken)
2. Register itself with the App Server (e.g., 'push.monal.im') to optionally 
receive AppToken.
3. Send an enable / request to the XMPP server.

Now, that enable/ request needs to include some data, and there are a few 
ways to do this:

1. enable jid='push.monal.im' node='DeviceToken' /

In this case, your app server will more or less be acting as a straight proxy 
to APNS. This will add a new entry to the user's set of push endpoints if the 
DeviceToken did change, but old ones should get cleaned up when the app server 
returns errors.

2. enable jid='push.monal.im' node='AppToken' /

In this case, the AppToken abstracts the DeviceToken so that things work even 
when the DeviceToken changes, when there are multiple DeviceTokens for a user, 
etc.


Note that the XMPP server can't actually distinguish between those cases, nor 
should it need to. The semantics of that node value are meaningful only to the 
app server ('push.monal.im'); the XMPP server only cares that it can publish to 
that node. The app server could even be able to speak to both APNS and GCM, 
delivering notifications to both iOS and Android clients for the same event.


Personally, I prefer and will be using the second option.


 It may also be nice if the client could define what events it cared about. 
 Most mobile clients are  probably not going to care much about anything other 
 than ping and message stanzas when operating in the background.  There would 
 be significant battery life improvements if a client could take advantage of 
 XEP-0198 (with a very long expiration) to close the socket unless a message 
 or ping arrived.  While  XEP-0198 is probably beyond the scope of this 
 document, it’s probably how I and others will try to use push, so it may 
 warrant mentioning. 

Yes, Christian had some thoughts on selecting what gets pushed out. I'll be 
adding a way to do that in the XEP soon. In particular, I want to add that 
mechanism to handle the case where my XMPP server might include message content 
in the push data (because I the user am ok with that tradeoff), but an App 
server could wish to *never* receive that information. I believe Monal would 
fall into that group.

As it currently stands, when and what constitutes a push-worthy event is left 
to the server implementation. Christian has been working on an implementation 
for Ejabberd that uses XEP-0198 to determine when to start sending 
notifications. I expect we'll be able to start standardizing some of those with 
a bit more implementation experience.




- Lance




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Service Discovery + dependent features

[Lance Stout]

 True from a pure protocol point of view, but less true from a client's UI 
 features point of view.
 http://xmpp.org/extensions/xep-0297.html#support says:
 Clients that implement this specification to display simple forwarded 
 messages (i.e. those not part of another extension)“
 
 which reads like „A client could be able to display XEP-0280 messages, but 
 might not be able to interpret/display XEP-0297 messages (’simple forwarded 
 messages’)“.
 
 = client would advertise support for XEP-0280, but not for XEP-0297 !?!?!?!?


That is the interpretation I've always used.


Disco features come in two flavors: purely descriptive and advertised allowed 
behaviour. Purely descriptive and informative features would be ones like 
hashes, supported pubsub options, etc. Features that control allowed behaviour 
are concerned about top-level traffic.

For example, nearly everything ends up requiring the use of XEP-0004. But 
including 'jabber:x:data' in your feature list doesn't mean that you are able 
to work with data forms in the context of all the various XEPs, it means that 
you are able to handle and will allow receiving messages with bare top-level 
data forms. Removing 'jabber:x:data' from your feature list does not and should 
not imply that you've turned off nearly every XEP as a consequence.

So yes, a client can certainly advertise that it supports 'urn:xmpp:carbons:2' 
(which implies only supporting enough of forwarding to implement carbons), but 
does not advertise 'urn:xmpp:forward:0' because it either does not support 
displaying forwarded messages or simply does not want to receive them.


As a user, I would not expect turning off support to display forwarded messages 
from my friends to suddenly mean I can no longer see chats I sent from my other 
IM clients. Element re-use does not mean user-meaningful feature dependency.


 
 From a user experience perspective: should checking the „XEP-0280“ checkbox 
 implicitly check the „XEP-0297“ checkbox as well? And should unchecking the 
 „XEP-0297“ implicitly uncheck the „XEP-0280“ checkbox?
 (checked features would be directly reflected to disco#info)
 
 There are even more complex dependency trees, like:
 
 urn:xmpp:jingle:apps:file-transfer:4
   == urn:xmpp:hashes:1
   == urn:xmpp:jingle:1
   == urn:xmpp:jingle:transports:s5b:1
   == http://jabber.org/protocol/bytestreams
   == urn:xmpp:jingle:transports:ibb:1
   == http://jabber.org/protocol/ibb
 
 Which I’d interpret as: if 'http://jabber.org/protocol/ibb' is disabled, it 
 implicitly disables all dependent features („parents“) as well 
 (urn:xmpp:jingle:transports:ibb:1, urn:xmpp:jingle:apps:file-transfer:4)!?
 
 No, because you can use file-transfer without ibb.
 
 
 In this case I disagree.
 Both, XEP-0234 and XEP-0096 *require* IBB:
 
 http://xmpp.org/extensions/xep-0096.html#protocol-tech
 http://xmpp.org/extensions/xep-0234.html#impl-mti
 
 Which for me means, if the user chooses to disable IBB for whatever reasons, 
 he implicitly disables file transfer as a whole, at least from a XEP-0030 
 point of view.

Yeah, I'm torn on this one. If I disabled IBB, then I would not be surprised 
that Jingle file transfers wouldn't work with IBB anymore. So removing both 
'http://jabber.org/protocol/ibb', and 'urn:xmpp:jingle:transports:ibb:1' at the 
same time at least makes sense. While it could be argued that including the 
Jingle feature and not the plain IBB feature means that you would only accept 
IBB requests that had first been negotiated via Jingle, I don't think I'd ever 
use or recommend doing it that way.

On the other hand, I *would* be surprised that disabling IBB meant that I 
couldn't transfer files at all anymore, especially when I had other transports 
enabled. That is behaviour I would only expect from knowingly toggling file 
transfer as a whole on or off.



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


- Lance




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: Push

[Lance Stout]

 On Mar 10, 2015, at 8:51 AM, Christian Ulrich christian...@rechenwerk.net 
 wrote:
 
 On Di, 2015-03-10 at 00:43 -0700, Lance Stout wrote:
 The intent in the security section is to not allow changing in-band what 
 content gets delivered via the push notifications, not the 
 enabling/disabling of push services. 
 
 Otherwise, a client could surreptitiously change the settings to include 
 private information like full message bodies and contact JIDs when the user 
 had previously chosen not to allow publishing that data.
 
 I'll add some clarifying language.
 
 Of course, the same sort of opportunities exist for bad clients already, 
 such as adding to a user's roster without their consent. However, such 
 things are generally noticeable by the user and correctable. Push services 
 are more shielded from the user's notice and thus much easier to exploit.
 
 
 I must have skipped the in-band-configuration not recommended
 paragraph the first time, so my suggestion of including settings in the
 enabled stanza is not recommended.

Well, the text would need changing once that form is included in the XEP. The 
point though is that using that form will only be able to disable information 
in practice, not enable it. Even if you try enabling `include-message-bodies`, 
message bodies wouldn't actually be included if the user had previously 
disabled that option.


I would gladly concede that I'm being overly paranoid here. Feedback welcome on 
if this cautious approach is even useful.


 An example for out-of-band configuration would be logging into a web
 interface and deselect include-message-bodies, right? That's a lot of
 effort, so maybe the server should at least tell the user how it's
 configured. Then the user can decide if re-configuring is necessary.
 Service discovery could return the user-specific configuration:
 
 iq from='jul...@capulet.lit'
to='jul...@capulet.lit/balcony'
id='disco1'
type='result'
  query xmlns='http://jabber.org/protocol/disco#info'
identity category='account' type='registered'/
feature var='urn:xmpp:push:0'/
x xmlns='jabber:x:data'
  field var='FORM_TYPE'
valueurn:xmpp:push:0#configuration/value
  /field
  field var='include-message-count'value1value/field
  field var='include-message-bodies'value0value/field
  field var='include-senders'value0value/field
  field var='include-pending-subscription-count'
value1value
  /field
/x
  /query
 /iq

+1, I imagine this will end up working like the disco features for pubsub.





smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: Push

[Lance Stout]

 On Mar 10, 2015, at 8:12 AM, Christian Ulrich christian...@rechenwerk.net 
 wrote:
 
 Thanks for clarifying. Do we allow a client to send an enable stanza
 before resource binding then? We should not, if we want to allow the
 first two options you mentioned.

I don't see a need to particularly restrict that ability since it's an App 
Client
that will be making the enable call, so if the app needs to have a resource 
association
it should wait until after binding.

At the least, a suggestion to wait until binding would be good, right?

 more details I came across: 
 The XEP defines the push notification field last-message-body. RFC 6120
 says:
 
 Multiple instances of the body/ element MAY be included in a message
 stanza for the purpose of providing alternate versions of the same body,
 but only if each instance possesses an 'xml:lang' attribute with a
 distinct language value
 
 Quite a rare case I think, should the server just pick the first body or
 should it include all bodies like this:

Ah, right. That's going to get tricky very quickly, but I'm not seeing anything 
better than your
suggestion right now. 

 Is there a reason why jingle events (like in the old version) are not
 included in the field list?

The summary form is meant to be just that — a summary of information you will 
always want to
have in a push so you can keep counters and badges, etc, synced properly. Not 
everything needs
to be forced to fit into the summary form; you can include any other payload 
elements you wish.

I've (maybe incorrectly?) thought of the summary data to be 'passive' data. So 
I'm undecided how
Jingle would fit there yet, since it is more of a call-to-action that could 
need special treatment.

I am anticipating an update to http://xmpp.org/extensions/xep-0353.html to 
define how to use it
with push, which would cover this case.


 Could a server shutdown be a push event?

No reason why not. I'm not sure what you'd do with the information, but if 
that's interesting
to applications, then yeah.



- Lance

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: Push

[Lance Stout]

 2.1 Push Service, 'is what' is extranous.
 
 3.2 Business Rules paragraph 3, Care SHOULD be taken.  'ought' is too relaxed 
 a word to use here, and it doesn't fit in with the SHOULDs used in paragraph 
 2.

Fixed

 5 Enabling Notifications, Note.  This reiterates the assumption that the
 App Client is aware of the push service, and can interact with the push 
 client on the host device, AND can interact with the XMPP server for the 
 setup phase.  To pull an 'evil' use case out of the hat, what about the case 
 where the App Client can only communicate with the XMPP server via the push 
 service?

Do you have a specific example in mind for that case?

 The App Server should accept the push service token also via out-of-band 
 mechanisms.
 6 Disabling Notifications.  The App Server should also provide an out-of-band 
 mechanism for disabling push notifications.

While I agree with these behaviours, is it a standards scope creep to introduce 
SHOULDs for App Servers?

 Speaking of out-of-band mechanisms, I notice that they're mentioned in 
 section 9 Security (Wheel of Fortune types miss 'implementations') as a 
 SHOULD, while in-band modifications are not recommended.  Even though that's 
 what is being described in sections 5 and 6 ;).

The intent in the security section is to not allow changing in-band what 
content gets delivered via the push notifications, not the enabling/disabling 
of push services. 

Otherwise, a client could surreptitiously change the settings to include 
private information like full message bodies and contact JIDs when the user had 
previously chosen not to allow publishing that data.

I'll add some clarifying language.

Of course, the same sort of opportunities exist for bad clients already, such 
as adding to a user's roster without their consent. However, such things are 
generally noticeable by the user and correctable. Push services are more 
shielded from the user's notice and thus much easier to exploit.

 7.1 Publish Errors
 
 The second paragraph describes how the server MAY consider the endpoint still 
 active until a certain number of errors have been accumulated.  I think there 
 should also be language declaring that the server may also retry an 
 errored-out endpoint at a later time, something like (as para3):
 
   A server MAY also retry a disabled JID and node combination after
   period of time (eg, 1 day) in a disabled state.

+1, added

 Example 13 before this section has one too many 't's in its title.  You'd 
 confuse the poor Wheel of Fortune contestants with 'notifictation'.

:)  Fixed

 8 Remote Disabling of Notifications.  to stop accepting notifications _from_ 
 the user's XMPP server

Fixed



New update of the XEP with the above changes has been sent to the editors.

— Lance

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: Push

[Lance Stout]

 So I think using the node name as a device identifier (or more
 precicely: an identifier for entities that want to receive the same push
 notifications and are thus registered for the same node) is sufficient
 for the xmpp server.

Yes, that is the correct interpretation. Imagine for example that Apple's push
service was actually implemented as an XMPP Push Service. The 'device ID' given
to your iOS app would be the node.

What a node actually represents is 100% completely arbitrary and decided by
the App Server. The App Server you create for your new app could treat node ==
device ID so that it can target specific devices, or you might want to just
always notify all of a user's devices (or none!) and thus node == user. All
of which means that your XMPP server has no internal knowledge of phones or
devices, only of applications/services. 


 When a client sends an enable stanza the server
 updates an existing record for the client's full jid with the stanza's
 new 'node' value. That's actually already described in the XEP.

I may need to add additional clarifying language to the XEP then. Enabling
and disabling as defined is for the bare JID account level. However,
servers could keep track of which services a particular resource connection
enabled and use that information to do more intelligent notifications.

The defined workflow is that when the XMPP server detects something interesting
happened, then it has a set of JID+node endpoints that can be informed of that
interesting event via pubsub publishes. We could let the server have the option
to pick which of those JID+node combos it will publish to, but there is not a
defined way to choose any particular subset. However, there are options 
available to
pick from, for example:

- Was the interesting event associated with a particular resource that also had 
  enabled push services? Send the publish to only those services.
- Are there push services for a user which have not been enabled by any of the 
  user's current online sessions? Send the publish only to those services.
- Publish to all enabled services regardless of if the user has any online
  resources.

I expect that the XEP will expand to cover this topic once we have some more
implementation experience on what works well in practice.

Of course, what defines interesting (and the levels and kinds of interesting) is
left to the server implementation and to future XEPs, but there are a lot more
potential things than just offline messages.


 One of your requirements is still not met: you have to know the resource
 to enable / disable push.
 
 So what if my phone gets stolen and I want disable push notifications
 for it? I could log in from another device using the same full jid. But
 you also mentioned random strings as resources…

Then your App Server needs to provide a way to disable notifications to your
phone, which is already the case today for mobile apps. The topic of push is
hard to talk about without assuming everything is directed to mobile devices,
but the point is that XMPP servers really shouldn't need to know what a phone
even is. Consider XMPP Push Services whose associated App Server is nothing more
than a daily 'things you missed' email summary generator — a case with no mobile
app, no mobile device, and no particular associated resource.


 One solution to the stolen phone problem would be an emergency-off
 switch (disable all resources of the user on all nodes):
 
 iq type='set' id='x97'
  disable-all xmlns='urn:xmpp:push:0' jid='push-5.client.example' /
 /iq

That is already the defined behaviour for the disable / element when no node 
is provided, but
you would need to know the JID of the service.


— Lance

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: Push

[Lance Stout]

 On Mar 2, 2015, at 4:11 PM, Christian Ulrich christian...@rechenwerk.net 
 wrote:
 
 I started implementing an older version of the XEP [1] as an ejabberd
 module. It's on github [2]. Currently I'm updating it to the new
 version. 

Awesome and ^5!

 My implementation includes the app server (currently only for Ubuntu
 push), so the app server and the XMPP server are one instance. In order
 to explain why I chose to do this I have to expand the scope a little.

I understand why you'd want to set things up that way, but IMO this is not 
going to be tenable in the long run (explained below).


 In case of Apple's, Google's and Microsoft's push services the app
 server needs secret authorization data (certificate or secret key) to
 send push notifications. So all client app instances need to register
 with a central app server. In Ubuntu's push service [3] it's different.
 The app server only needs the client's token and app_id for
 authorization with ubuntu's server. I'd like to keep decentrality alive
 where possible and in case of Ubuntu Push it is (at least in the
 non-proprietary part). So I'd like to enable an arbitrary XMPP server
 to send notifications to Ubuntu's push service.

Given that you read the previous draft, I'm sure you appreciate that the topic
of push comes with a very tangled knot of terminology, so please bear with me
trying to explain my thoughts here.

I think this approach is trying to decentralize the wrong aspect.

The goal for the XEP is to let an XMPP server notify the App Servers for the 
user's apps when something interesting happens. What those apps do once notified
is up to the app's purpose and implementation. Of course, the common case we
expect is for those apps to in turn publish a push notification to the user's
devices which have the app installed. But that is not actually required, and 
the fact that multiple apps may forward their notices via the same third-party
mechanism to user devices is only coincidence.

It comes down to that apps have purpose and will do different things. For 
example, say that I have two apps which both happen to use Ubuntu Push to send
data to my device. One is a typical general IM client. The other is a video call
app. The App Server for the video call app will only send data through Ubuntu
Push when it receives a notification that includes Jingle data. The App Server
for the general IM client might only send data through Ubuntu Push when chat
message data was included in a notification, and it could also keep track of 
all 
the chat message notifications it received for me during a day and send me a
summary email every evening of things I might have missed.

Forcing those two apps to use the same App Server will not work, because their
App Servers are different, even if they do some things in common. Even if
they did the exact same things now, that is not guaranteed to be true forever.
Apps change, gain and lose features. App Client and App Server necessarily
need to be kept in sync.

That said, what you do want to do to preserve decentralization is to let the 
user of an app run their own instance of the App Server. Once you allow that, 
it remains an implementation detail how the App Client discovers and registers 
with the App Server.


 - apps that need to register with one central app server will know its
  app server's hostname, but for an app supporting arbitrary app
  servers there's no way of dicovering a hostname. So it should be able
  to ask its xmpp server for a hostname serving a specific push service
  type. Maybe something like this (up means ubuntu push):
 
  iq type='get'
  from='ro...@montague.net/orchard'
  to='montague.net'
  id='items3'
query xmlns='http://jabber.org/protocol/disco#items'
   node='urn:xmpp:push:0#up'/
  /iq
 
  iq type='result'
  from='montague.net'
  to='ro...@montague.net/orchard'
  id='items3'
query xmlns='http://jabber.org/protocol/disco#items'
   node='urn:xmpp:push:0#up'
  item jid='push-up.montague.net'/
/query
  /iq


So from my point above, in this case you would not search for an XMPP Push
Service for Ubuntu Push. You would search for an XMPP Push Service for your app.
This is an interesting idea to pursue. Perhaps we need to define how to create
disco#info identities for this? Would this be a follow-up XEP or defined here?

iq type='result'
from='my-app-server.montague.example'
id='x13'
  query xmlns='http://jabber.org/protocol/disco#info'
identity category='pubsub' type='push' /
identity category='app-server' type='my-cool-app-name' /
  /query
/iq

This needs more implementation experience to hammer out.



 - arbitrary app servers require a unified registration process. The 
  draft suggests to use XEP-0077, that's ok I think, but then we need to
  define what data the client has to provide. My suggestion for XEP-0077
  registration fields:
 
  * token (mandatory)
  * app-id 

Re: [Standards] Proposed XMPP Extension: S2S Components

[Lance Stout]

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


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



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


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



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



— Lance

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Reusing thread in chat sessions after receiving gone/ chat state?

[Lance Stout]

It makes sense to me, given that XEP-0085's rules are overriding the general 
guidelines in XEP-0201.


I think the confusing part between the two XEPs is that they use the same 
example action in two different contexts.


In XEP-0201, closing a chat window exemplifies merely disengaging from the chat 
session. In XEP-0085, closing a chat window exemplifies terminating a chat 
session.

Similar but different semantics. 





Unfortunately, most clients treat closing a chat window as terminating the chat 
session, but that doesn't have to always be the case.


Consider an app that works like Apple Messages does, which lists all of your 
recent conversations in a side bar alongside the main chat window, but can also 
pop open individual chats inside their own windows.

Closing an individual chat session window in this case would be disengaging 
from a chat session, but the session is still alive (and listed in the 
conversations sidebar). Triggering a gone event would not be appropriate here.

However, clicking the X to remove a conversation from the sidebar would be 
terminating the chat session, and trigger a gone event. Starting a new 
conversation with the same person (or the other person sending messages) should 
start a new thread.



Of course, the recipient might never have received the gone, because they were 
offline at the time and the message was dropped. So if they wanted to continue 
sending a message in the same conversation, it would have the old thread id 
because it doesn't know otherwise. I would say there is an implicit business 
rule that maybe should be made explicit, which is that a client should handle 
receiving a message from a thread that it has tried to terminate; the chat 
session isn't truly terminated until the other side starts using a new thread 
id or the client starts using a new thread id itself.


— Lance

smime.p7s
Description: S/MIME cryptographic signature

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

[Lance Stout]

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

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

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

Yes

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

I have, in SleekXMPP and stanza.io.

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

No

 5. Is the specification accurate and clearly written?

Yes



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

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

Why is that a problem?

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

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

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


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


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



- Lance

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] XEP-0332 Last Call comment summary

[Lance Stout]

 2) The revision of the XEP in question is 0.3; note that there are comments 
 in the thread about the update to this revision which do not appear to be 
 answered:

I would also add:

h) The use of an xml/ element is prohibited by the XML spec (can't start tags 
with 'xml' or variants thereof), and would need to be renamed.


- Lance

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: Privileged Entity

[Lance Stout]

This is a relevant proposal for some stuff I'm working on, so ^5 for writing 
this.


It looks like there's a clear path for mapping these permissions to and from 
OAuth scopes, which
I'm glad to see since that's how permissions would be managed for the systems 
I've worked on.


*puts council hat on*

- It doesn't look like there is a defined way to edit or remove permissions 
once granted 
  (at least for the client case). There is text saying that should be possible, 
using
  XEP-0050, which is good. However, a well-defined node where that permissions 
editing command lives
  should be provided (similar to how MAM provides the command node 
urn:xmpp:mam#configure).

- There is an interesting case here: Could something request permission for the 
'urn:xmpp:privilege:0'
  namespace? That feels like a bad thing to allow. There is text suggesting 
that namespaces should be
  filterable or whitelisted, but this case warrants an explicit mention.

- What is the intention behind Business Rule #2? If I'm logged in with two 
clients which support this XEP, 
  one of which also supports XEP-0050 and the other not, and I happen to accept 
the permission request with
  the one that does not support XEP-0050, what is supposed to happen?


  

Lance


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] XEP-0319 vs. XEP-0256

[Lance Stout]

On Jun 23, 2014, at 12:53 PM, Christian Schudt christian.sch...@gmx.de wrote:

 Hi,
 
 I've read about XEP-0319: Last User Interaction in Presence and wonder 
 where's the difference to XEP-0256: Last Activity in Presence?
 
 For me both cover the same use cases.

Right. XEP-0319 is intended to replace XEP-0256.


 When should a client use one over the other? Ok… for now XEP-0319 is still 
 experimental, so a client would prefer XEP-256, but assuming both were in the 
 same status, where are the differences?

The issue with XEP-0256 (and XEP-0012) is that it is fuzzy by only including a 
'seconds' value, which could be further coupled with a delay/ element. 
XEP-0319 does the simple thing and just states the timestamp that the user went 
idle. No need to try and calculate that time based on seconds, stanza arrival 
times, and delays. That simplifies the work needed by both clients generating 
this data  those receiving it.


It's possible for a server to translate the XEP-0256 data to the XEP-0319 
format, see 
http://hg.prosody.im/prosody-modules/file/ae1d7665cde9/mod_idlecompat/mod_idlecompat.lua


— Lance


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Lance Stout]

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

This is a feature that has received a lot of end-user requests, and we have no 
other good way to do it, so yes.

If anyone is going to ever implement this feature, let's have a thought out 
approach for them instead of horrible hacks.


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

Yes, it does.


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

I've implemented this twice already on the client side - in SleekXMPP and 
stanza.io.

However, I'm not aware of any server-side implementation to use those with.


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

As mentioned in the XEP, it's still very easy to expose the fact that you're 
online, but any method of accomplishing presence invisibility will have that 
issue.


One thing I notice not mentioned in the XEP is client handling of bookmarks set 
to auto join.


 5. Is the specification accurate and clearly written?

Yes.



- Lance



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] Proposed XMPP Extension: Data Forms Geolocation Element

[Lance Stout]

This looks reasonable  straight forward to me, at first glance.


However, I think that it should also be using XEP-0122 (Data Forms Validation) 
to indicate a 
geoloc datatype is expected.

Having been implementing data form related things recently, I've found that two 
places to 
determine a field's type (type attribute + validation datatype) is more than 
enough. I don't 
want to have to start making a laundry list of things to check as we add new 
form extensions
in the future.


It turns out that we've done this sort of extension before in XEP-0137 
(Publishing Stream 
Initiation Requests). The annoying difference is that sipub includes an id 
field that could 
be inserted as the field's value, and so the sipub/ element was added as a 
child to the form, 
not the field. Here we would have to add the geoloc/ element to the field, as 
shown in the proposal.

That difference is not a huge deal: I'm not sure anyone ever actually 
implemented file uploads with
sipub in data forms, and we're working on a Jingle version of sipub that would 
be more consistent.


I note that XEP-0315 (Data Forms XML Element) also should define a datatype for 
the same reasons.


With Council hat on:

* This needs to define a XEP-0122 datatype



— Lance

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: Recipient Server Side Notifications Filtering

[Lance Stout]

On Jun 2, 2014, at 9:48 AM, XMPP Extensions Editor edi...@xmpp.org wrote:

 The XMPP Extensions Editor has received a proposal for a new XEP.
 
 Title: Recipient Server Side Notifications Filtering
 
 Abstract: This specification defines a modern efficient way to deliver PubSub 
 notifications.
 
 URL: http://xmpp.org/extensions/inbox/rsf.html
 
 The XMPP Council will decide in the next two weeks whether to accept this 
 proposal as an official XEP.
 


I'm a -1 based on the reasons Fippo explained concerning XEP-0033 use. 


However, the event filtering by the receiver's server via caps part of this 
proposal is useful and could stand on its own without the XEP-0033 parts. 

That enters into SIFT-like territory, but maybe that's a direction we need to 
experiment in so that we can actually have things that implement SIFT features.

- Lance



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] Disco presence subscription confusion

[Lance Stout]

On Jun 11, 2014, at 11:16 AM, Graham King gra...@gkgk.org wrote:
 
 Is this a correct reading? From the code I think this is how Prosody 
 interprets it, and it makes intuitive sense (to me at least!). If this 
 reading is correct, could I submit a patch to the XEP to clarify?


Sounds right. Send a patch.

—Lance



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] New revised version of proposal: Signing Forms

[Lance Stout]

On May 16, 2014, at 10:01 AM, Peter Waher peter.wa...@clayster.com wrote:

 The reason was to stick to the OAUTH algorithm as defiend for the web, where 
 BStr is defined as:
  
 BStr:=Escape(method)+''+Escape(url)+''+Escape(PStr)
  
 (method=GET/POST; etc..)
  
 The closest match in XMPP the method parameter has is the type attribute used 
 when submitting the form, and the closest match to the url parameter is the 
 to-attribute. It is the actual ‘type’ attribute that is referred to. (I’ve 
 made a small change to highlight this.) The form_type parameter is already 
 included in PStr:
  
 BStr:=Escape(type)+''+Escape(to)+''+Escape(PStr)
  
 Clarification now reads:
  
 “The Signature Base String (BStr) is then formed concatenating Escape(type) 
 (the 'type' attribute of the form used when submitting the form), Escape(to) 
 (the full destination address, including resource, if any) and Escape(PStr), 
 using ampersands ('') as delimiter.“
  
 OK?
  
 Note however, that you can include any parameter in the signature, by posting 
 hidden parameters on the form.


-- without council hat --

Since signing forms uses OAuth 1, how much from XEP-0235 (OAuth over XMPP) can 
be reused here? XEP-0235 already specifies some of these parameters for 
generating signatures, which differ from ones in this proposal.


Having spent some time reviewing signing forms against some use cases I might 
have for it, I'm really left wondering why not just use XEP-0235 directly? It 
clearly separates the OAuth data from the user's form data, and provides error 
elements for explicit feedback on incorrect or missing parameters which signing 
forms currently lacks. I understand that embedding OAuth information inside a 
form is quick  easy, but 235 is very simple too and can be used in places 
where forms aren't used. I'd rather we have a single established way to do 
OAuth generally rather than two almost-the-same-but-not-quite methods.


iq type='set'
from='jul...@capulet.com/balcony'
to='contests.shakespeare.lit'
id='reg4'
  query xmlns='jabber:iq:register'
x xmlns='jabber:x:data' type='submit'
  field type='hidden' var='FORM_TYPE'
valuejabber:iq:register/value
  /field
  field type='text-single' label='Given Name' var='first'
valueJuliet/value
  /field
  field type='text-single' label='Family Name' var='last'
valueCapulet/value
  /field
  field type='text-single' label='Email Address' var='email'
valuejul...@capulet.com/value
  /field
  field type='list-single' label='Gender' var='x-gender'
valueF/value
  /field
/x
oauth xmlns=urn:xmpp:oauth:0
  oauth_version1.0/oauth_version
  oauth_signature_methodHMAC-SHA1/oauth_signature_method
  oauth_token.../oauth_token
  oauth_token_secret.../oauth_token_secret
  oauth_consumer_key.. ./oauth_consumer_key
  oauth_nonce.. ./oauth_nonce
  oauth_timestamp.. ./oauth_timestamp
  oauth_signature.. ./oauth_signature
/oauth
  /query
/iq


I will admit that right now XEP-0235 does need some editing  review, and that 
it lacks two key features: indication that OAuth is required, and the optional 
inclusion of form fields in the signature. As for requirement indication, I 
think we can do that rather easily:

oauth xmlns=urn:xmpp:oauth:0
  required /
  oauth_version1.0/oauth_version
  oauth_signature_methodHMAC-SHA1/oauth_signature_method
/oauth

And for form values in the signature, we can state that if the OAuth request is 
used in conjunction with a data form, then the signature process may include 
those form values, in the manner described here.





-- with council hat --

XEP-0235  Signing Forms have overlapping use cases, and while similar have at 
least one subtle difference  gotcha (notably the method values are currently 
inconsistent). Editing and updating of XEP-0235 could be done to cover the 
cases addressed by Signing Forms. However, Signing Forms can *not* be updated 
to cover all of the cases addressed by XEP-0235, namely cases which don't 
involve data forms (e.g., PubSub subscription requests).

As such, I'm inclined to vote -1 for Signing Forms as-is in preference that we 
expand and fix XEP-0235 so that it addresses the use cases for Signing Forms.


-- Lance





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] Tags and Pubsub subscriptions in XEP-0048 (Bookmarks)

[Lance Stout]

 My proposal is quite simple. Take the subscription tag used in the 
 XEP-0330 (
 http://xmpp.org/extensions/xep-0330.html
 ) to store the informations of the subscribed node and put them in Bookmark 
 items.

The only hesitation that I have here is that this is going to create some nasty 
surprises due to how
bookmarks work with private XML storage. Ie, you have to fetch, edit, and save 
the entire XML blob
any time you want to make a change. Which is generally fine, but bookmarks are 
old and there is a lot
of existing code that assumes you are only storing MUC bookmarks (since no one 
ever actually used the
URL bookmark feature). So if you happen to use the wrong client somewhere, all 
of your subscription
bookmarks could disappear because they didn't know about subscriptions.


That's certainly wrong behaviour for clients, but such behaviour does exist in 
the wild.


The safest route is to use what you already have defined in XEP-0330. However, 
I'll note that PEP services
have not done well in allowing multiple items to be published to a single node 
like this requires.

XEP-0330 could be changed to save the full set of subscriptions in a single 
item to work around that, though
I'd really prefer the multi-item PEP nodes.


As a last resort, saving the full set in a new private XML storage element 
would work.


 Furthermore it would be great to add some tags on the Bookmark items to 
 organize and filter them.

+1 for this idea. However, it does carry the same consideration as above that 
older clients could cause you to lose this information.




—Lance


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] XEP-0170: Recommended Order of Stream Feature Negotiation

[Lance Stout]

On Apr 29, 2014, at 9:12 AM, Kim Alvefur z...@zash.se wrote:

 Hello list,
 
 I noticed that XEP-0170 1) talks about the old RFCs and 2) does not
 mention XEP 198, Stream Management.  198 doesn't use a stream restart,
 so some description about that could be useful.  Is it perhaps time for
 an update to this XEP (or replacement)?
 
 -- 
 Kim Zash Alvefur
 


I'm +1 for reviewing and updating XEP-0170.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] Proposed XMPP Extension: Buddycloud Channels

[Lance Stout]

I've started reviewing Buddycloud Channels, and have some questions/comments:



- Is Buddycloud intended to become a generic term, like PubSub/MUC/Jingle?

I'm curious because it is giving me the same cautious pause as if this
had been submitted by Facebook and named Facebook Channels, using
the name of a corporation or other trademarked term in the protocol
name.


The disco identity registered here is for pubsub/channels. Would
simply Channels be a better term? (XEP-0060 doesn't use the term
channel, so no conflict there)



- Section 2:

It says that a server can have one Buddycloud channel server. Is this
an artifact of the current Buddycloud implementation, or a restriction
imposed by the protocol?



- Section 6.1.1:

XEP-0060 doesn't currently allow for using multiple items /
elements like that. It might be better to have those as children of a
recent-items / element.



- Section 6.3:

While the Buddycloud service is using Atom for entries, does that need
to be specified as part of this XEP? Some of the tables indicate that
non-Atom content is used already.



- Section 9.1 Inbox is missing?

Although Section 9 seems superfluous right now (that's more a
description of the Buddycloud project/service as a whole, not of this
protocol).





On the whole, I'm liking this so far. Most of my concerns stem from
balancing documenting Buddycloud as it currently works vs making
things a bit more general to be useable in non-Buddycloud projects.


— Lance



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery

[Lance Stout]

 Example: Consider 100'000 devices connecting to an XMPP server they've found 
 somehow, and then need to find a Thing Registry to register themselves. One 
 might be preconfigured, but I want to include the case when one is not. 
 100'000 devices cannot start looping through all possible JIDs and ask 
 service discovery to find out who can what. So it needs, as a last attempt, 
 to try to find it somehow. How do you suggest this done, if you do not accept 
 the methods proposed (as the last resource)?

The approach we would suggest is that the Thing Registry be implemented as a 
server component (and thanks to XEP-0114 can be used with any XMPP server that 
supports XEP-0114, which is to say all of them). A Thing would then iterate 
over the items in a disco#items result for the XMPP server, looking for one 
that provides the registry feature. The disco#items result for a server is on 
the order of tens, not hundreds of thousands. For example, that process is how 
a user discovers SOCKS5 proxies for file transfers.

Implementing a service like the IoT Thing Registry using a client connection 
is, from our collective experience as XMPP devs, ill advised even though it is 
technically possible. Note that several sections of the proposed XEP exist 
solely to work around issues from using a client connection (presence 
subscriptions and limitations with roster sizes) that a server component does 
not need to deal with.

 XEP-0055 has several shortcomings when it comes to the search function we've 
 proposed. This is why we did not used it.

Agreed that XEP-0055 does not meet the needs for this case.


However, in terms of re-using existing protocol building blocks, you should 
look into XEP-0077 some more. People seem to overlook that XEP-0077 is not just 
IBR for new XMPP account provisioning, but also a protocol letting an existing 
JID register with an arbitrary service, and then later update or remove that 
registration. Even the cases where you need additional information (such as 
when Concentrators are used) can be handled using XEP-0077 if that extra data 
can be expressed via data forms.

Implementing some new service as a component, and letting users (which in this 
case would be Things) opt-in for that service using XEP-0077 is a common 
historical pattern.


— Lance


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] Push notification XEP

[Lance Stout]

 Did you have any chance to discuss it in person at FOSDEM? How's going
 there by the way?

Yes, we had quite a bit of good discussion on this topic at the summit, and now 
that I have all of the notes I will have an updated Push XEP proposal out in a 
few days.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] Push notification XEP

[Lance Stout]

I tried writing up an explanation, but it ended up rather long-winded and 
confusing to follow. So I made some diagrams instead :)

https://cloudup.com/c223kt48cGZ

The flows presented there modify what I have in that write-up to make some 
things simpler. Let me know if there are areas that need
more fleshing out for explanation, or if your questions weren't fully addressed.


— Lance


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] Push notification XEP

[Lance Stout]

 We discussed precisely this at the last summit. Nobody has actually written a
 XEP yet, it would be great if you're able to write one :)

I wrote this up to summarize our discussions at the summit and after:
http://legastero.github.io/customxeps/extensions/push.html

I've only given a quick look, but it seems similar to the approach that kicked
off this thread, and to the ideas behind the BuddyCloud push component.


This is the model we arrived at in October:

Definitions:
1) Client app: The thing the user is actually using and interacting with on a 
device.
2) Client Backend Service (CBS): A server run by the maintainers of the client
   app. The CBS is able to integrate any open/Proprietary Push Notifications to
   deliver updates to its associated client apps.
3) Proprietary Push Notifications: Apple's Push Notifications, Google Cloud 
Messaging, etc 
4) XMPP Push Service: An XMPP server component/plugin which delivers messages to
   a CBS on behalf of a user.

Goal: Allow a user to have push notification experience using an arbitrary
third-party Client App with their personal server. Making this possible implies
that use cases where the Client App and XMPP server are part of the same overall
system are also possible (eg, a special purpose app that just happens to be
using XMPP as an implementation detail, not a generic chat application).

Note: It is the CBS that talks with any Proprietary Push service, not the XMPP
server itself. This is done because the CBS has private key material that it
won't share with an arbitrary XMPP server. In many Proprietary Push Services, 
the
notification will appear to come from the Client App and Client App developers 
aren't
going to give you their private keys so you can enable push for their client on
your personal server and risk allowing anyone to spoof their notifications.

So what we end up with is this flow:

1) User establishes stream using Client App.
2) Client App discovers that the server has an XMPP Push Service
3) Client App registers the stream with the push service, indicating an endpoint
   for its CBS that will receive the pushed data.
4) When certain conditions are met (user has no connections, no connection for a
   given Client App, a stream in XEP-0198 zombie mode, etc) the XMPP Push 
Service
   sends a to-be-decided update to the CBS.
5) The CBS can then convert the received update into an open/Proprietary Push
   Notification.
6) The user's device receives a push notification from their Client App.
*) At any time, the user can view the set of endpoints that are registered to
   receive notifications, and remove them.


There are still things that need to be worked out, namely what does an update
contain and when exactly do we trigger them.

The goal is that we provide sufficient use case coverage to heavily discourage
Client App from deciding to proxy the entire session through its CBS. We have
seen Client Apps that do this and store user credentials in the CBS to create
connections at any time, and that behaviour makes me nervous. However, that
approach is 'simplest' and gives Client App developers the greatest degree of
control, so this will need a lot of input from existing Client App developers to
be successful.


— Lance


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] Push notification XEP

[Lance Stout]

 1. I assume the endpoint is the equivalent of a device token for
 APNS and registration ID for GCM

By endpoint I meant JID. 

The Client Backend Service will need some XMPP aware component to receive
notification payloads from their users' XMPP servers and convert those
into their Proprietary Push Notification service format of choice.

 2. I didn't see a way to make the server advertise its provider ID
 which is necessary at least for APNS and GCM. Maybe in the discovery
 reply stanza?

Your XMPP server only advertises that it can relay notifications to
the user's Client Backend Service. It's the CBS that has a provider ID,
etc.



An example:

1) An iOS client app, named Otalk.
2) The Otalk developers runs a private XMPP server (push.otalk.im) solely for 
receiving
   push notification payloads from external servers.
3) I run my own XMPP server on lance.im, which supports this XMPP Push 
extension.


So I install Otalk on my phone, and establish a connection to my own server, 
lance.im.
The Otalk client detects that lance.im supports the push extension via 
disco/caps.
The Otalk client then registers the 'push.otalk.im' endpoint (which the Otalk 
client
knows about because it's hardcoded) as a recipient for push notifications for
la...@lance.im on lance.im. Included in that registration MAY be some ID value
that the Otalk client provides, which is completely opaque and only intended for
use by 'push.otalk.im' as the registered endpoint. (Eg, the Otalk client app 
could
request an ID value from its backend server that associates 'la...@lance.im' 
with a
device id/token before starting the registration process at lance.im.)

I then go offline or do something which causes my server, lance.im, to trigger a
push notification. It then sends the notification payload (whatever we end up
defining for that) to the relevant push endpoints that have been registered for
la...@lance.im. In this case, push.otalk.im.

The notification is then received by push.otalk.im, and the push.otalk.im server
then converts that information into an iOS Push Notification, which requires the
use of private key material issued to the Otalk developers to sign the iOS push
request.

My phone then receives the iOS push notification, which displays a message that
'Otalk' has done something, and maybe updates the Otalk app badge.
 
Fin.


My server, lance.im, never needs to know anything about iOS or GCM or anything
specific to my phone. It has no 'provider ID'; my server never talks to Apple,
Google, etc.

What it does have is essentially a special PubSub/PEP node that has user 
approved 
subscribers and is only published to by the server under certain conditions and 
possibly
only to certain subscribers at a time. It's up to the installed app to 
communicate with its 
own backend services to share device IDs and tokens, and it's up to the app's 
backend 
service to forward that notification over its preferred proprietary push 
service to
the installed app on some device.


— Lance


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] Push notification XEP

[Lance Stout]

 My doubt is: what kind of information may the payload carry given that
 it's generated by the user's server? Any use case for that? Thanks.

Right, this is why it has so far been desirable to just proxy the connection, so
the app service has complete control over what it can know.


These are the use cases I'd want to have covered at minimum:

1) Notification of offline messages, with the message bodies.

2) Notification that messages have been received while offline, possibly with a 
   count of the unread messages. No message bodies or senders.

   This case is one that we've had to explore for dealing with services that
   must conform to governmental privacy regulations (e.g. medical) to prevent 
leaking
   protected data to external push services or across borders (e.g. a UK 
provider using
   push services based in the US).

3) Presence subscription requests, with requester.

4) Number of pending presence subscription requests (same situation as #2).



One more that I'm not quite sure how we'd cover yet, but will become important 
soon:

5) Jingle call request/answered notification.



As far as I can tell, those should be sufficient for general chat applications. 
More
special purpose apps may require things like pub sub notifications, etc.

— Lance


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] BOSH patches

[Lance Stout]

 In the 1.11 version I don't really understand the diagram under point 4. Too 
 many empty bodies.
 - What is the left side and the right side?
 - From X to * is one HTTP request? Then why is there a long time no 
 request (but many pipes |)?

We may need to include some more labeling information in the diagram itself 
then :) The pipes on each side only indicate the passage of time when the 
connection is not being used.



So, here’s the story that accompanies that diagram (from top down):

You have an active BOSH session going, with a single active connection. You 
have been POSTing BOSH requests over that connection, but there hasn’t been any 
new traffic to deliver, so the requests time out with empty responses. A new 
POST is made using that same connection after each timeout to continue 
listening for traffic.

Then, you have a message to send out. You open a second connection and POST 
your message. The pending POST you had on the other connection is then 
responded to (before its usual timeout) with an empty payload because there’s 
nothing to deliver.

Meanwhile, the POST that you used to send your message sticks around, waiting 
for any new traffic to be delivered, but it eventually times out, and returns 
with an empty result, and a new POST is made using that connection (since 
that’s the current ‘active’ connection).

Now, you want to send another message, so you flip the original connection back 
to ‘active’ and use it to send the POST for your message. The old pending POST 
on the other connection then returns. You then receive a message, which is 
delivered to your request on the ‘active’ connection (left side). You then send 
out a new POST to continue listening for traffic.

Once again, you want to send a message out, so you flip the ‘active’ connection 
over again (now on the right side). This time, you happened to have an incoming 
message at the same time, so it is delivered immediately as the response to 
your old pending POST (left side).

And then we time out again, and send a new request on the still ‘active’ right 
hand side connection.



The moral of the story is that you really only ever need two connections, and 
you flip between the two whenever you need to send a stanza and the old 
connection is sent whatever traffic has been buffered.


Hope that helps with implementing your Java BOSH client :)

— Lance


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] eventlogging xeps

[Lance Stout]

Hi Peter,

This is looking really good!

Minor things I noticed:

- The timestamp attribute. We’ve been using ‘stamp’ as the name for that type 
of attribute.
- The type and level attribute values are currently title cased, but I 
personally prefer lowercase values since that is what is commonly used.

It looks like those were made to match directly with syslog?



There are several places where strict element ordering is mandated. Any 
particular reason why? 


-Lance


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] presence TTL

[Lance Stout]

I'm assuming that you're doing direct client to client connections for this 
(eg, link local, etc)? Otherwise the server should ensure that the presence is 
kept up to date.


There is also the new XEP-0334 for processing hints that could be expanded, and 
it might be a good fit for this:

presence from=alice to=bob
  ttl xmlns=urn:xmpp:hints seconds=600 /
/presence

or

presence from=alice to=bob
  expires xmlns=urn:xmpp:hints stamp=1969-07-21T02:56:15Z /
/presence


-- Lance


smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)

[Lance Stout]

So, I've implemented and have been working with this in stanza.io (a new JS 
websocket XMPP client lib) for WebRTC signaling. (Don't worry, I'm also working 
with Fippo to get proper Jingle to work too).


The primary benefit to this is that I don't have to parse SDP in the browser to 
create Jingle stanzas, and then translate Jingle back to SDP. However, what is 
documented here doesn't go far enough to provide that benefit -- it still 
requires some SDP parsing on the receiving end to extract the relevant bits 
needed for WebRTC.

So, what I've been using has the form:

message
  sox xmlns=http://stanza.io/protocol/sox;
   sid=...
   type=offer|answer|candidate 
   [label=... id=...]
...SDP blob...
  /sox
/message

Where sid is the user generated session ID, and label and id are for ICE 
candidate updates. The browser APIs helpfully provide the label and id values. 
Since they are included as attributes, there is no need for parsing the SDP 
blob by the receiver.


-- Lance



On Jun 12, 2013, at 1:55 PM, XMPP Extensions Editor edi...@xmpp.org wrote:

 The XMPP Extensions Editor has received a proposal for a new XEP.
 
 Title: SIP/SDP Over XMPP (SoX)
 
 Abstract: This specification defines an XMPP protocol extension for 
 communicating Session Description Protocol (SDP) data, along with relevant 
 Session Initiation Protocol (SIP) headers. The SoX protocol is designed for 
 use by XMPP-only endpoints that need to communicate raw SDP information 
 (e.g., in WebRTC scenarios), not as a general-purpose replacement for the 
 XMPP Jingle extensions.
 
 URL: http://xmpp.org/extensions/inbox/sox.html
 
 The XMPP Council will decide in the next two weeks whether to accept this 
 proposal as an official XEP.
 

Re: [Standards] Enabling/Disabling Carbons and Chat Markers

[Lance Stout]

On May 28, 2013, at 10:54 PM, Philipp Hancke fi...@goodadvice.pages.de wrote:

 And Carbons/Chat Markers are the type of features that would typically 
 always be enabled, not flipped on and off constantly.
 
 stream:features/ then?
 

Sure, although that's effectively what we have right now. Using 
stream:features / would mean we wouldn't need to query the server for support 
(unless the server does caps via stream:features /), but it's still an extra 
step for the client to enable when the server would already know to enable the 
feature based on caps.

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Enabling/Disabling Carbons and Chat Markers

[Lance Stout]

On May 28, 2013, at 11:18 PM, Kevin Smith ke...@kismith.co.uk wrote:

 My opinion at the moment is that the current toggle is the sort of
 protocol wart that it's possible to get caught up in, but really makes
 no practical difference to anyone beyond aesthetics

I heartily concede that this is very probably the case, especially for Carbons; 
moving on.

 Carbons/Markers are local.

Well, Carbons is local, sure. Markers I'm not sure about yet because

switches to Chat Markers discussion

the current proposal is still a bit hand wavy when dealing with multiple 
servers. So consider ro...@montague.lit/orchard and jul...@capulet.lit/balcony, 
and both have expressed interest in using chat markers.


Romeo sends Juliet a message, and Juliet updates her read information on 
capulet.lit (which is allowed and useful even if Juliet is the only one that 
supports the markers). 


But capulet.lit needs to know if ro...@montague.lit/orchard supports chat 
markers to send it an updated read marker from Juliet. It would need caps for 
that. Or, does it even care about resources? Does capulet.lit instead send a 
request to the bare ro...@montague.lit to update the marker, and let 
montague.lit archive and forward it to the interested resources? My initial 
feeling is that it should care about resources, because of MUC.

smime.p7s
Description: S/MIME cryptographic signature

[Standards] Enabling/Disabling Carbons and Chat Markers

[Lance Stout]

After reading the new proposed Chat Markers XEP, the thought occurred of why 
are we using explicit enable/disable queries for Chat Markers and Carbons?


What if we instead make it so that if you want to use them, advertise support 
for the features in caps and then the server automatically enables them. If you 
don't want to use a feature for a given session, don't advertise support for it.

Benefits:
- Simplified protocol, works similar to PEP
- Fewer requests/responses needed to fully establish a session (ie, faster = 
better, esp for web clients).

Cons:
- Enabling/disabling a feature requires presence update, with associated 
presence storm issues.
- ?

As for presence storms, I'd say we'd have the exact same issue that we already 
have for enabling/disabling interest for PEP nodes, so it shouldn't be that big 
of an issue. And Carbons/Chat Markers are the type of features that would 
typically always be enabled, not flipped on and off constantly.


-- Lance

Re: [Standards] Forward Stanza Inconsistency between XEP-0280 and XEP-0313

[Lance Stout]

On May 22, 2013, at 12:27 PM, Spencer MacDonald 
spencer.macdonald.ot...@gmail.com wrote:

 Hi,
 
 Maybe there is a good reason for it, but in XEP-0280 Message Carbons the 
 forwarded stanza is nested in either a received or sent element with the 
 carbons xmlns.
 
 In XEP-0313 Message Archive Management the result element with the mam xmlns 
 is a sibling of the forwarded stanza.
 
 Should there be a standard for this in terms of wether the xmlns element 
 should be the parent or sibling of the forwarded stanza?

This is just because MAM hasn't been updated to match yet. See 
http://matthewwild.co.uk/uploads/xep-0313.html


-- Lance

Re: [Standards] LAST CALL: XEP-0297 (Stanza Forwarding)

[Lance Stout]

So, for the Last Call that was supposed to expire in December but we all 
forgot...


 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, it has been included in SleekXMPP for a while now, as well as Carbons and 
MAM which require it.

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

None beyond what is already called out in the XEP.

 5. Is the specification accurate and clearly written?

Yes.

Given the other recent mail on the standards list about Carbons nesting its 
content inside the forwarded / element, and the currently published version 
of MAM using the old sibling method, it might be useful to go ahead and mandate 
that nesting the using protocol's content is a MUST instead of a SHOULD. We'll 
just need to bother MattJ into submitting his updated version of the MAM spec 
to the editor.


-- Lance

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] XEP 202

[Lance Stout]

 Am I completely misunderstanding XEP 202? In the ejabberd implmentation, it 
 completely ignores the From and To and gives the user back the UTC and TZO of 
 the server. Am I correct in understanding that this XEP should allow Romeo to 
 find out Juliets timezone?

No, your understanding is correct. It's just ejabberd that has an interesting 
interpretation of the XEP. 


-- Lance

Re: [Standards] Using .well-known/ to supplement XEP-0156

[Lance Stout]

On May 19, 2013, at 7:09 PM, Yusuke DOI yusuke@toshiba.co.jp wrote:
 
 (2013-05-19 03:13), Peter Waher wrote:
 What about the UPnP method? Using SSDP? Creating some well defined
 UPnP Device interface for XMPP Servers  XMPP Clients, perhaps
 exposing the features of each device at the same time? Saves time as
 you don't have to do service discovery on each device.
 
 UPnP is not for browsers and I think this is not what Lance needs.


Right, a .well-known/ document would be the easier/faster win since that uses 
technology readily available in browsers without the need for any plugins, and 
it follows the recent standards trends (POSH, Webfinger, BrowserID/Persona, 
etc). So I want to push to get that sorted out and standardized first.

That said, I do like the idea of using UPnP, so Peter if you have ideas on what 
that would look like, please share. I'm not familiar enough with how it works 
yet. Is it only intended for local network discovery?


-- Lance

[Standards] Using .well-known/ to supplement XEP-0156

[Lance Stout]

So XEP-0156 details how to use DNS records to advertise alternative ways to 
connect to an XMPP server, namely BOSH and soon WebSocket. That's great, except 
that in the browser you can't make arbitrary DNS requests, which severely 
limits the usefulness of this method.

Any interest in standardizing some .well-known/ document to expose alternative 
connection endpoints? There's probably something like this that already exists 
that we can profile or register with, right?

-- Lance

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: JID Prep

[Lance Stout]

 Text that mandates this is currently in the 6122bis draft
 https://tools.ietf.org/html/draft-ietf-xmpp-6122bis#section-3.
 I think it would be better to reference that and make sure the text
 there is sensible.

+1. 

The only reason I added that sentence in this draft is because 6122bis is 
itself still just a draft and not technically in effect. If we're ok with 
temporarily referencing a bis draft (which it says is inappropriate), then I'll 
add it in.

-- Lance

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Proposed XMPP Extension: JID Prep

[Lance Stout]

 2) A restricted user may not have the ability to type the correct jid.
 
 This doesn't seem to be addressed, but could be with minor modifications. For 
 example, if I have the ascii-fied jid of remko.troncon@swift.example, I could 
 have my client request the correct spelling, in effect, and get back 
 remko.tronçon@swift.example. Presumably in this case, it would need to 
 request this from swift.example, and not the client's local server - though 
 it's possible that the local server might forward along the request.
 
 This becomes rather more useful for asian jids, where the user may well have 
 both a ascii (and possibly even European) variant of their name as well as 
 the correct script.


This gets really fun when you consider internationalized domain names. So at 
that point you don't really know who to send the request to.

But, disregarding that, having a query to ask a server for an even more proper 
representation of a JID does seem doable. What would the logic be for that 
though?

1) A server that supports this kind of aliasing MUST set a user's JID to the 
non-aliased version during binding. So an alias JID wouldn't ever be sent out 
by that server.
2) Before interacting with a new JID, a client SHOULD send an alias query to 
the given JID's server and discard and remap the given JID in favor of the 
result. This is independent of being able to prep a JID, so this would apply to 
*all* clients which allow a user to type in a JID.
3) The main question: if the server for the user with an alias receives a 
request to the alias JID, does it forward it to the proper JID, or return an 
error saying to try again with the real JID?
4) Just for fun: If I had both an internationalized domain name, and an ASCII 
version, could I alias JIDs between them. Ie, could an alias map to a JID on 
another domain? Security considerations abound.


I'm in favor of specifying this behavior in its own XEP, since it is generally 
applicable to all clients, not just those in constrained environments without 
access to stringprep/precis/etc (e.g. browsers).

-- Lance

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] LAST CALL: XEP-0152 (Reachability Addresses)

[Lance Stout]

 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, there are use cases for this spec, which my company has used this XEP for 
already for associating phone and SMS numbers with a JID.

Additionally, I think this XEP is very helpful for the case of migrating to a 
new JID.

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

Yes, the given problem is solved by the XEP.

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

Yes, we have already used this in internal systems. If this isn't in SleekXMPP 
already, it will be.

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

None beyond what is already specified. This type of information would tend to 
be available already in other formats.

 5. Is the specification accurate and clearly written?

Yes


 Your feedback is appreciated!


+1 on moving forward



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] XEP-0196 modification

[Lance Stout]

 I think a server_port/ subelement would be useful, because it would be
 clearer and more semantically correct than having a hostname:port string in
 the server_address/ element (not to mention ipv6 addresses).

Yeah, it would mean that a client doesn't have to parse out the port from the
rest of the host part. But that's really not that difficult, and is happening
inside an XMPP client that is required to already know how to do that (of
course, that may mean an underlying library ought to expose a helper method for
it.. :) ).

As for IPv6 addresses, you're supposed to enclose the IP address portion inside
brackets [ ] to separate it from the port.

 I would suggest you put that into uri/ instead.

Except that uri / looks to mean a URI for identifying/learning more about the
game in question. Not where to connect to join the game.


Mathieui: since it looks like you're the first to go this route in a while, let 
us
know what you find experience-wise in practice. It could be worth revisiting
196 in-depth to mirror whatever information Steam provides for the
equivalent feature in its client (especially if that data can be easily 
extracted).


-- Lance

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Resurrection of XEP-0292

[Lance Stout]

 Does anyone know why XEP-0292 (vCard4 Over XMPP) is deferred?

It was automatically deferred a few days ago because there have been no updates 
or calls to advance its status for a year.


-- Lance

smime.p7s
Description: S/MIME cryptographic signature

[Standards] [BOSH] More patches

[Lance Stout]

Here are my patches related to following the requirements of RFC 2616, and 
noting that key comparisons should be case insensitive.

-- Lance




bosh.patch
Description: Binary data


smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] XEP-0012: Last Activity's future

[Lance Stout]

 In addition that it is currently used for two different purposes:

Actually, it looks like three purposes: time since last online, idle time 
(clients), and current uptime (servers/components). 

 2. Discover when a connected user was last active at the server. (The XEP 
 calls it idle time, which would be some kind of server access idle time if i 
 read it right)

For clients XEP-0012 says that idle time is based on human interaction with the 
client. From section 4:

 If the user's server delivers the IQ-get to one of the user's available 
 resources, the user's client MAY respond with the idle time of the user 
 (i.e., the last time that a human user interacted with the client 
 application).


As for the proposals:

 Purpose 1) can be done using presence + delayed delivery, like described at 
 http://tools.ietf.org/html/rfc6121#page-54. This would automatically use 
 absolute time.

+1. If it's handled appropriately in the core RFCs, no need to duplicate it in 
a XEP. 

 Don't think 2) is the semantic we ever wanted. Under idle time I understand 
 the time someone has been away from his machine/device. The most common way 
 to detect this is missing input (keyboard/mouse/touch). In my opinion neither 
 XEP-0012 nor XEP-0256 describe such behavior.

That looks to be what XEP-0012 and XEP-0256 already prescribe, but given the 
overloaded meaning of terms in XEP-0012, +1 on simplifying.

 That's why I propose to use a new protocol, like this 
 https://dl.dropbox.com/u/14672346/xmpp/extensions/xep-0256-replace.html .

My only suggestion for the proposed replacement is to just go ahead and name 
the element idle / instead of last-interaction /. It's shorter (good for 
presence data) and the intent (user has been idle since) reads nicely. 

This leaves the third use case for server/component uptime reporting uncovered, 
but that seems like something that should be done via adhoc commands like other 
statistics reporting, and probably already is.


-- Lance

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Disco Search

[Lance Stout]

I too have been working with several extensions lately that need search 
capabilities, so this has been in my mind the last few days.

I don't have fully formed ideas on how how it would look, etc, but I would be 
interested in experimenting with expanding (or drafting a replacement) XEP-0055 
to include a node parameter to scope what is being searched and use that 
instead.

Eg, with expanding the existing search XEP:
query xmlns=jabber:iq:search node=urn:xmpp:somethingappropriate
   x xmlns=jabber:x:data type=submit
field var=FORM_TYPEvalueurn:xmpp:pubsub:search/value/field
field var=ownervalued...@jabber.org/value/field
  /x
/query

Or with some new XEP similar to RSM to augment a normal query:
query xmlns=http://jabber.org/protocol/disco#items;
  search xmlns=urn:xmpp:search:0
x xmlns=jabber:x:data
  field var=FORM_TYPEvalueurn:xmpp:search:pubsub/value/field
  field var=ownervalued...@jabber.org/value/field
/x
  /search
/query

As for disco node names with query parameters, it works and I know XEP-0303 
uses it, but it opens up a can of worms of implementation details and 
variations that I'd prefer to avoid if possible.


Lance



On Jan 25, 2013, at 2:31 PM, Dave Cridland d...@cridland.net wrote:

 Hi folks,
 
 I have a use case for finding all pubsub nodes on a service for which the 
 caller has an owner affiliation.
 
 I'm implementing this as a private extension comprising a well-known disco 
 node, which when given a disco#items query would list such nodes.
 
 Is there any interest in standardizing:
 
 a) Such a node.
 
 b) A generalized mechanism for constructing node names programmatically to 
 find such information? Say urn:xmpp:disco:search?owner=d...@jabber.org for 
 example.
 
 Dave.
 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] NEW: XEP-0317 (Hats)

[Lance Stout]

Playing around typing out example hat payloads, I noticed that they feel a lot 
like disco identities.

So for what the hat payload format should be, I'm inclined to use a variation 
of formats 1 and 2, with 
s/name/type/ and s/display/name/:

  hats xmlns=urn:xmpp:hats:0
hat type=http://example.com/hats#Foo; name=Displayable name 
xml:lang=en /
  /hats

or even:

  hats xmlns=urn:xmpp:hats:0
identity type=http://example.com/hats#Foo; name=Displayable name 
xml:lang=en /
  /hats

I would prefer using name instead of display or displayName since that's the 
pattern we've used
more often in the past for human presentable labels.

Given that hats are sent via presence, I'm not sure how valuable being able to 
discover them via 
disco would be, but the formats like the above map very nicely to disco 
identities.

query xmlns=http://jabber.org/protocol/disco#info; 
node=urn:xmpp:hats:something
  identity category=hat type=http://example.com/hats#Foo; name=Displayable 
name xml:lang=en /
/query


Other notes:

1. Security considerations should include that hats must always be stamped on 
by the MUC, not by the end user.
2. Noting that multiple versions of the same hat may be included with different 
displayable names so 
   long as the xml:lang value differs. This is a very established pattern, but 
none of the examples showcase it,
   so never hurts to be explicit about it.


-- Lance

On Jan 3, 2013, at 2:53 PM, XMPP Extensions Editor edi...@xmpp.org wrote:

 Version 0.1 of XEP-0317 (Hats) has been released.
 
 Abstract: This specification defines a more extensible model for roles and 
 affiliations in Multi-User Chat rooms.
 
 Changelog: Initial published version approved for publication by the XMPP 
 Council; clarified ad-hoc commands logic and syntax. (psa)
 
 Diff: N/A
 
 URL: http://xmpp.org/extensions/xep-0317.html
 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] XMPP OAuth2 login at Google

[Lance Stout]

It's a bit annoying that they add an extra attribute to the auth / element, 
because it adds a special case to check in what would ideally be a fully 
generic implementation. Fortunately, it doesn't seem to be required for now.

-- Lance


On Sep 11, 2012, at 3:15 PM, Arc Riley arcri...@gmail.com wrote:

 FYI, Google recently documented their X-OAUTH2 SASL method;
 
 https://developers.google.com/talk/jep_extensions/oauth

Re: [Standards] XEP-0301 0.5 comments [Sections 1 through 5]

[Lance Stout]

  The rtt/ element is transmitted at regular intervals by the sender client 
 while a message is being composed

If we're going to be picky about what the first example demonstrates, it should 
probably also be noted in this sentence that the regular intervals are intended 
to be temporal, and not simply every N characters. Thus, if any change is to 
be made, we should make sure that each RTT in the example does not have the 
same number of characters, for the same reasons as have been discussed.

-- Lance

Re: [Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT

[Lance Stout]

Yeah, my first thought was why not just allow adding a replace / in each RTT 
update? but that can add a lot of overhead, even though it makes the intent 
very explicit.

I think the inclusion of the id attribute with event=reset has strong enough 
semantics to make this work. You're resetting a previous message for amendment 
via RTT, and the final replace / gives the result of editing. 


A few things that will need to be considered:

I can see already that the description of the reset event will need to be 
updated to cover the new semantics. For example, the current XEP-0301 text does 
not sound like this method would be acceptable if one attempted to replace a 
message sent before RTT was enabled. 

Does this handle the case where a user begins a replacement, but then decides 
to not commit to the replacement? Or is that simply not a case that makes sense 
in a RTT session?


+1 on the direction of this.

-- Lance

Re: [Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT

[Lance Stout]

 Imagine situations where the original message took 2 seconds to create (Enter 
 was accidentally hit), but last message editing take minutes.How do you 
 replace 2 or 3 rtt/ elements in a proper manner, with over 100 to 1000 
 rtt/ elements, while preserving all behaviour of XEP-0301?  You could 
 transmit 1000 action elements in a single rtt/, but that becomes quite 
 unwieldly, especially, if you continue, and then go back to edit some more.  
 So for this reason, I feel that rtt/ doesn't belong in replace/

Ah, I think we had different scenarios playing in our heads then. I was 
imagining just tagging all of the RTT updates with the replace / element 
referring to the original, complete message that was being changed. Like so:

message to=al...@wonderland.lit from=b...@wonderland.lit type=chat 
id=102
   bodyFirst Lixne/body
/message

...

message to=al...@wonderland.lit from=b...@wonderland.lit type=chat 
id=106
  rtt xmlns=urn:xmpp:rtt:0 seq=4 event=resettFirst Lixne/t/rtt
  replace id=102 xmlns='urn:xmpp:message-correct:0'/
/message  !-- begins replacement editing RTT by including replace / -- 

message to=al...@wonderland.lit from=b...@wonderland.lit type=chat 
id=107
  rtt xmlns=urn:xmpp:rtt:0 seq=5d p=8//rtt
  replace id=102 xmlns='urn:xmpp:message-correct:0'/
/message !-- replacement editing continues -- 

message to=al...@wonderland.lit from=b...@wonderland.lit type=chat 
id=108
   bodyFirst Line/body
   replace id=102 xmlns='urn:xmpp:message-correct:0'/
/message !-- final replacement body for message 102  -- 


No changes in XEP-0301 behaviour or protocol; in fact, it plays out identically 
to your proposal, just with more overhead. The advantage is the increased 
explicitness that those RTT events are happening within the context of last 
message correction. It just would probably need an update in XEP-0308 to allow 
this to be compliant. (I would consider RTT events to be messaging content 
which satisfies the requirement for inclusion of replace /, but it's 
borderline enough that it would need clarification in XEP-0308).

Anyway, the above adds a lot of extra bytes in those cases where there are 1000 
RTT updates during editing, so your proposed method would be preferable in that 
regard.

 I can see already that the description of the reset event will need to be 
 updated to cover the new semantics. For example, the current XEP-0301 text 
 does not sound like this method would be acceptable if one attempted to 
 replace a message sent before RTT was enabled.
 
 That wouldn't be a problem.
 This is because rtt event='reset'/ is treated exactly like rtt 
 event='new'/ if there was no existing message.   My version 0.3 update made 
 that clearer.   Can you clarify?

I meant that XEP-0301 makes references to the use of those events in terms of 
real-time messages, which a message sent before RTT is enabled I would not 
think qualified under those terms. And, if RTT is enabled and immediately used 
to edit a message sent before RTT, then the current text mandates that an 
event=new be sent instead of event=reset (since it is the first rtt / 
element containing action elements). A very minor issue and I'm probably just 
confused by the particular scenario used in your example, but I just want to be 
sure there isn't an edge case complicating things.


-- Lance

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

[Lance Stout]

Given that entity caps are expected to be transmitted in both the sent and 
received presence (or failing that you now know a full JID which can be queried 
for disco), what more do we really need other than saying that you can include 
multiple values in the reason attribute?

  decloak reason=audio video text /

 Answers should include details about the presence, such as supported codecs, 
 and parameters, and encryption capabilities.

Any supported protocols, codecs, etc would be found via disco/entity caps.

The reason value is really just a hint or suggestion, since the requester may 
well attempt to subsequently establish a different type of session than 
originally requested, or none at all (this should be mentioned in security 
considerations, I think). Attempting to layer much more meaning than that seems 
more complex than necessary.

-- Lance

Re: [Standards] Comments Needed: Upgrading XEP-0301 to Draft. (In-Band Real Time Text)

[Lance Stout]

 In one of our chat clients we have developed it is possible for a user to 
 have what amounts to multiple conversations occurring at the same time with a 
 single other user (I.e. In our case a user can have multiple chat tabs open 
 to another user).
 
 Reading the 301 spec, there doesn't seem to be any way to relate the rtt 
 messages to the final message other than the sequence they are received.


For other XEPs that introduce some sort of session, there has typically been a 
session ID attribute to distinguish sessions between the same full JIDs.

In the case that multiple chat window sessions are active between the same 
*full* JIDs, then the use of thread / elements in both the normal and RTT 
messages would easily resolve the issue, especially since that is the only 
standard way I'm aware of that would even allow for that situation to occur 
reliably.

 It's also how you would treat MUC (groupchat) -- correspond RTT with each 
 full JID.

However, regarding a user joining a MUC multiple times, I think that your 
expectations fail when multiple sessions are allowed under the same room nick. 
I.e, a user with two active connections u...@example.com/foo and 
u...@example.com/bar joins a MUC with both JIDs as 
m...@rooms.example.com/user, which is allowed by XEP-0045 section 7.2.9. MUC 
participants who are not allowed to see the actual JIDs of other participants 
will have issues recognizing the situation. There would be two interleaved RTT 
streams, both from the full JID m...@rooms.example.com/user and so the RTT 
buffers in the receivers would become garbled until a reset, and then only a 
single RTT session would win. Again, the use of a thread / element or an 
optional sid attribute would remedy the issue.

-- Lance

Re: [Standards] Comments Needed: Upgrading XEP-0301 to Draft. (In-Band Real Time Text)

[Lance Stout]

 The question is: What to mention in XEP-0301?   
 Most of these are not spec-related issues...

Yes that is the topic at hand, isn't it? I would say that, if anything, adding 
an implementation note that it is acceptable to include a thread / in a RTT 
update, and that it may be used to differentiate sessions in conjunction with 
full JIDs would be sufficient.

I also see now that XEP-0301 6.4.3 touches on the MUC issue, using the error 
recovery you described. The simultaneous login scenario in 6.4.3.2 sounds like 
differentiating between full JIDs, and not the multiple nick session scenario. 
If this situation warrants mention in the spec, then a sentence indicating that 
the multiple nick session scenario is also covered by 6.4.3 would be 
appropriate.

-- Lance

Re: [Standards] XEP-0301: review comments

[Lance Stout]

It may be useful to include some note on how this would interact with XEP-0071 
for XHTML-IM, if at all.

If the two can be used together, then I would imagine that any HTML formatting 
would be ignored when sending RTT, and only sent in a normal, full message 
stanza. And for the receiver, I would expect it to replace the received RTT 
with the XHTML-IM content when it arrives.

-- Lance

On Jun 27, 2012, at 11:57 AM, Mark Rejhon wrote:

 On Wed, Jun 27, 2012 at 8:55 AM, Kurt Zeilenga kurt.zeile...@isode.com 
 wrote:
  Maybe one day we'll have virtually unlimited bandwidth everywhere...  
   but that's simply not the case today and likely won't be the universally 
  case for many decades (if ever). 
  Even fast typing over real-time text, is still rate-limited to 1 stanza 
  every interval (such as 700ms or 1 second)
 
 It's not how slow or fast the user types, it's how many RTTs stanzas are set 
 in addition to the IM stanzas as seen on the XMPP network in total.  If we 
 assume every user has this extension enabled (which is the worse case, I 
 believe) 
 
 We need to distinguish extension enabled from extension active.
 A chat client can advertise that it has audio/video support, but keep it 
 inactive until initiated by the user.
 
 When RTT is added to a mass-market client (note: AOL's AIM has real-time text 
 already) it would be something that can be initiated by the user, such as via 
 a button, i.e. containing the International RTT symbol -- www.fasttext.org 
 
 It would be a very gradual process, very few RTT users at first (first in 
 slowly-increasing open source programs before it reaches a popular brand of 
 instant message program), so the XMPP network has many years to scale/adjust 
 to the needs.  It's already scaled to meet the needs of in-band file and 
 avatar-image transfers, for example.   RTT penetration into mainstream 
 clients is envisioned as a 10-year process.  During this time, most of these 
 software will do stream-level encryption instead of stanza-level encryption, 
 so combined with the gradual scaling, it shouldn't be a big enough concern to 
 mention in the spec about recommending turning off RTT during stanza level 
 encryption.
 
  
 The number of RTTs per IM likely depends on many factors, but I'm roughly 
 guessing there's somewhere between 1 and 10 RTTs per IM stanza.  Even at 1, 
 we're basically doubling of the bandwidth demand.
 
 Given average instant message lengths of 40 characters, that sounds accurate.
 Even with many layers of bubble-wrapping, it's still far less bandwidth than 
 video.
 You can also 'fold' the real-time text in other stanzas you normally send, 
 such as Chat States, so subtract about 1 or 2 the total increase.
 
  
  In borderline situations, you could adjust transmission intervals to 
  violate the recommended range 0.3s-1.0s (I only made that range a 'SHOULD') 
  -- such as transmitting real-time text at 2 second intervals instead.
 
 You?  as in the user?   User's don't know what's wrong, or how to fix it.  
 Hell, they are likely to decrease the interval in hopes of getting an unfair 
 amount of the available bandwidth.
 
 No, no -- it's a software decision.
 When I said you, I meant the developer. Apologies for not being clear.
 
 Software be designed to automatically adjust the transmission interval to 
 automatically adapt to situations such as bandwidth, congestion, decide to do 
 flow control (acknowledgements), etc.  You can do fancy flow control on 
 real-time text to run reduced-rate real-time text on an overloaded server.  
 So it's no longer the end of the world.
 I even already mention this in section 10.2 Congestion Considerations:
 http://xmpp.org/extensions/xep-0301.html#congestion_considerations
 This should cover the situation when part of the chain of the real-time text 
 is 'expensive' (i.e. stanza level encryption slowing down real time text)
  
 
 True congestion control should not be user driven, it should be code driven, 
 based on feedback from the network.  It should be designed to promote 'fair' 
 allocation of bandwidth and congestion pain.
 
 That's what I said. :-)
 
 Sincerely,
 Mark Rejhon

[Standards] XEP-0300 Namespaces

[Lance Stout]

Reading over XEP-0300 yesterday, I noticed that in the examples the namespace
pattern urn:xmpp:hash-function-textual-names:* is used whereas in the main 
text
the pattern urn:xmpp:hash-function-text-names:* is used.

I'm assuming that the prose version is supposed to be normative and the examples
should be updated to match?

-- Lance


* I searched through the archives, but I've not seen this issue mentioned and 
it's
still in the latest draft, so forgive me if this has already been brought up.

Re: [Standards] UPDATED: XEP-0267 (Server Buddies)

[Lance Stout]

 I suppose there is nothing stopping you from subscribing directly to a 
 components presence.

Right, components can do everything a client can do, including sending presence 
and handling presence subscriptions (after all, that's part of what makes 
gateways work). The distinction, aside from the extra control over JIDs, is 
that the server will not maintain the roster for you, so if you want or need 
one you have to implement and maintain it yourself in the component. The roster 
in the end is just a table of subscription mappings. 

  I haven't tried this as I have been relying on OpenFire.  The OpenFire gui 
 doesn't provide the means to setup a roster for a component.  I will need to 
 try to subscribe to it directly and see how that works


Again, that is because you would need to implement that inside your component. 
Technically you could even hook into the server's roster storage if it lends 
itself easily to the task, but it still requires that the component manages the 
integration.

Another difference is that you will probably also want to do presence probing 
to receive initial presence updates, which is another thing that the server 
does on behalf of clients that it does not do for components.

For all of these reasons, in SleekXMPP we ended up adding a complete multi-JID 
roster backend so components could easily have their own rosters.

The only gotcha I've encountered with component presence and current server 
implementations is that if the component crashes or goes offline, the server 
will not broadcast unavailable presence like with clients. That can leave 
contacts' views of the component's presence in odd states. The solution for 
that, of course, is to have clustering, etc so that it doesn't matter.


Lance



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Call for Experience: Advancement of XEP-0047 (In-Band Bytestreams) to Final

[Lance Stout]

For SleekXMPP, I applied the limit to the pre-base64 data because I apparently 
didn't read the XEP closely enough.

I'll fix that shortly though using the 3*floor(X/4) formula.

- Lance

On May 23, 2012, at 11:34 AM, Matthew Wild wrote:

 On 23 May 2012 02:52, Peter Saint-Andre stpe...@stpeter.im wrote:
 On 5/22/12 4:13 PM, Matthew Wild wrote:
 Old draft alert! I really thought I had sent this... sorry.
 
 On 31 January 2012 09:07, Sergey Dobrov bin...@jrudevels.org wrote:
 On 01/31/2012 05:54 AM, Peter Saint-Andre wrote:
 At its meeting on December 20, 2011, the XMPP Council agreed to issue
 a Call for Experience regarding XEP-0047 (In-Band Bytestreams), in
 preparation for perhaps advancing this specification from Draft to
 Final in the XSF's standards process. To help the Council decide
 whether this XEP is ready to advance to a status of Final, the Council
 would like to gather the following information:
 
 1. What software has implemented XEP-0047? Please note that the
 protocol must be implemented in at least two separate codebases (and
 preferably more).
 
 I have tested XEP-47 implementations in tkabber and Vacuum-IM. Also, I
 have my own implementation in my experimental library named twilix
 which is an high level wrapper on top of twisted library. This
 implementation is used now to pass attachments to my experimental
 microblogging platform implementation (named LiJ) which based on
 XEP-277. The source code of the implementation is placed here:
 https://github.com/xamvz/twilix/blob/master/twilix/bytestreams/ibb/base.py
 
 
 2. Have developers experienced any problems with the protocol as defined
 in XEP-0047? If so, please describe the problems and, if possible,
 suggested solutions.
 
 The only problem I remember with the XEP is in this paragraph:
 
 The base64-encoded data to be sent, prior to any wrapping in the data/ 
 element and IQ or message stanza, MUST NOT be larger than the 
 'block-size' determined in the bytestream negotiation.
 
 It's not clear for me when I have to check the length of the block: for
 raw data or for base64 encoded? In the last case it's hard to do such
 encoding. I implemented the last case for the first time but then I
 noticed that Vacuum-IM checks it for raw data and so my implementation
 said that Vacuum-IM sends inappropriate packets, so for now I am
 checking a raw data. Maybe it will be good to specify this thing more
 clearly.
 
 
 It seems overall pretty clear to me that the XEP says the block-size
 limit applies to the data after base64-encoding. This does make it a
 bit more awkward than it should be in my opinion, and I'm not
 surprised clients interpret it differently.
 
 The maximum amount of data you can fit into X bytes of base64 is
 3*floor(X/4)... so for 4096 bytes of base64, 3072 bytes of data can be
 sent. Not hard to figure out, but perhaps too hard, and for the sake
 of simplicity should be relaxed. If we do relax it (and make the limit
 apply to pre-base64 length) then we should decrease the recommended
 block size accordingly.
 
 It seems that at least an implementation note about that little
 calculation would be helpful. I don't particularly see a reason to
 change the spec on this point, but it's not a hill for me to die on.
 
 My preference (and I would imagine the preference of all developers)
 would be for the limit to apply to the input data. If people have
 already implemented with the current text though then I agree it makes
 sense to leave it.
 
 On the other hand from the (little) evidence we have that it's not
 entirely clear what interpretation existing implementations have
 adopted. It wouldn't surprise me at all if the majority are applying
 the limit to the pre-base64 data, and in that case I think the XEP
 should be amended accordingly.
 
 But we need that data before making such a move. People with IBB
 implementations, speak up!
 
 Regards,
 Matthew



smime.p7s
Description: S/MIME cryptographic signature