Re: [Standards] digest algorithm in XTLS
On Jan 8, 2014, at 12:56 AM, Fedor Brunner wrote: > Signed PGP part > Hi, > is there a XMPP client/library implementing [draft-miller] ? > I know there are implementations out there, but I don't recall who exactly has done it. I've done some personal prototypes, but I'm not obliged to share them. > When comparing [draft-miller] with XTLS, I think XTLS is simpler and > could be implemented using existing TLS libraries. TLS doesn't support > encryption of offline messages, but for offline messages OpenPGP > XEP-0027 could be used. > To be fair, nothing developed after XEP-0027 really supports offline messaging. That said, having two completely separate protocols (and presumably completely separate branches of code) seems like a recipe for non-interoperability. - m&m Matthew A. Miller < http://goo.gl/LK55L > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] BOSH patches
On Dec 11, 2013, at 9:41 AM, Christian Schudt wrote: >> In theory, more connections means less latency. In practice, anything more >> than 1 held connection (so a maximum of 2 requests) starts to violate the >> in-order delivery rules from RFC 6120. > > So, another argument, to completely remove "hold" and "requests", as they are > always 1 and 2 in practice? (See my other mail for the other arguments). If XEP-0124 were Experimental and not Draft, I would agree with you. But Draft raises a significant bar on breaking backwards compatibility. Removing these, while correct from an architectural purity perspective, would make existing implementations (of which there are many) non-conformant and therefore non-interoperable, with (at least in my opinion) little real benefit. In other words, I think the boat for that level of change has already sailed into the West beyond the realm of Men. - m&m Matthew A. Miller < http://goo.gl/LK55L > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] BOSH patches
On Dec 11, 2013, at 12:21 AM, Christian Schudt wrote:
> Hi,
>
> yes, "to" should be "from" in 7.2.
>
> Concerning the xs:positiveInteger:
> http://www.w3schools.com/schema/schema_dtypes_numeric.asp
> I am not really sure if a positiveInteger is unbound and an unsignedInt is
> limited to 32bit. I don't really understand the difference anyway.
> Still, unsignedLong feels more appropriate, no?
>
The official definition is at <
http://www.w3.org/TR/xmlschema-2/#positiveInteger >. It states that
positiveInteger is the infinite set {1, 2, 3, ...}.
To be pedantically correct, we'd have to define our own simpleType, derived
from positiveInteger, and upper bounded to (2^53)-1. Otherwise, since the
value can't be less than 1, positiveInteger is the most appropriate.
> Concerning the diagram:
> Thanks, it became more clear, but definitively should have more
> labels/legends. I thought the left side is the client and the right side is
> the connection manager.
>
I'll endeavor to construct that legend, but would not mind any assistance (-:
> Why can there be more than two concurrent connections ("requests") anyway?
> Or, what's the benefit, if you use, say 5. You said "you only ever need two
> connections".
> This is something I wondered, too, while implementing it.
>
In theory, more connections means less latency. In practice, anything more
than 1 held connection (so a maximum of 2 requests) starts to violate the
in-order delivery rules from RFC 6120.
- m&m
Matthew A. Miller
< http://goo.gl/LK55L >
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [Standards] BOSH patches
On Dec 10, 2013, at 3:06 PM, Christian Schudt wrote: > Hi, > > I am new to this mailing list. > > I have been trying to implement BOSH in Java (client side) on basis of draft > 1.10. > > I think the document is quite understandable. > > However, I ran into the following issues: > - I did not understand the HTTP pipelining stuff, which is now removed :) Pipelining isn't something that can be applied to BOSH, so we all opted to remove any discussion on it. > - The 'rid' and 'ack' attribute are marked as "positiveInteger" in the XSD. > However, in Java, you need type "long" to represent the largest number > (2^53-1). I think this should be changed to "unsignedLong". (integer is only > 32-bit in XSD). In XSD, positiveInteger is unbounded at the maximum (bounded to 1 at the minimum). You're thinking of unsignedInt. > - "The client MUST generate a large, random, positive integer for the initial > 'rid'": What is large? Is there a minimum? And should be "positive long". Exactly what constitutes a large random value is left for clients to figure out. I don't know that we could reach consensus on what a suitable minimum is. > - The from attribute. I think it should be: "it MUST forward the identity to > the client by including a 'from' attribute in a response" (instead of MAY), > because the core spec says: > "For response stream headers in both client-to-server and server-to-server > communication, the receiving entity MUST include the 'from' attribute" > (http://xmpp.org/rfcs/rfc6120.html#streams-attr-from) > … just to be conform. That seems like a reasonable request to me, but we might need more feedback from implementers before changing that MAY to a MUST (or even just a SHOULD). For a real BOSH connection manager, it ought to be known immediately; for a BOSH-as-proxy, though ... maybe the horribly implemented ones need the MAY. > - The sentence "The client SHOULD NOT open more than two HTTP connections to > the connection manager at the same time" confused me, because the document > also said the number is defined by the "requests" attribute. But this > sentence is now gone in 1.11. (I think this revised section is my fault) That section did not feel like a normative section to me (more like an extended intro), and so I tried make it more of a play-by-play of what a BOSH session conceptually looks like. That meant (to me) removing RFC 2119-style normative language. > > > 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 |)? > This is addition is my fault (again), I'll try to clarify (-: The two sides are separate sockets between the client and server, for a single BOSH session. This was an attempt to illustrate how BOSH utilizes "one sometimes two" sockets for all BOSH traffic. "X" indicates when an HTTP request is transmitted from the client to the server. "*" indicates when the corresponding HTTP response is transmitted from the server to the client. "| |" indicate the time a server leaves a request pending (at most "wait" seconds). "|" indicates an idle (but still open) socket connection between the client and server. I can see about converting the above into a legend suitable to patch into the document, but I don't know when I can do that yet. Hope this helps. - m&m Matthew A. Miller < http://goo.gl/LK55L > > > Kind regards, > Christian > > > > Am 10.12.2013 um 22:12 schrieb Peter Saint-Andre: > >> On 11/27/13 8:23 AM, Winfried Tilanus wrote: >>> On 08-11-13 23:40, Peter Saint-Andre wrote: >>> >>> Hi, >>> Sitting here at IETF 88 with Lance Stout, I'm reminded to finally apply the collected patch he sent me to incorporate all the hard work that various folks on this list did earlier this year on XEP-0124 and XEP-0206. The rendered files and diffs are as follows. http://xmpp.org/extensions/tmp/xep-0124-1.11.html http://xmpp.org/extensions/diff/api/xep/0124/diff/1.10/vs/1.11rc1 http://xmpp.org/extensions/tmp/xep-0206-1.4.html http://xmpp.org/extensions/diff/api/xep/0206/diff/1.3/vs/1.4rc1 >> >> Lance has sent me an updated patch, which I have applied. The diff >> between 124rc1 and 124rc2 is here: >> >> http://xmpp.org/extensions/diff/api/xep/0124/diff/1.11rc1/vs/1.11rc2 >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] XEP-280 and MUC private chats
On Sep 25, 2013, at 2:24 PM, Waqas Hussain wrote: > On Wed, Sep 25, 2013 at 4:00 PM, Kim Alvefur wrote: >> Hello, >> >> On 2013-06-09 20:40, Mathieu Pasquet wrote: >>> I was starting to implement carbons in poezio when I came across some >>> kind of design issue that I haven’t been able to work out. >>> >>> However, in the case of private MUC messages (XEP-0045, 7.5), the >>> messages are also of type 'chat', causing them to be forwarded as normal >>> chat messages. But the other resources are not necessarily present on >>> that MUC, so they will receive the messages just fine, as with any >>> direct conversation with a fulljid, but they won’t be able to reply, >>> because I believe most MUC implementations will check the fulljid and >>> reply with an error. >> >> I would like to propose that the MUC server shall stamp something like >> on private messages >> passing through, similar to what is already done to . >> >> This would allow a Carbons implementation to treat those differently, eg >> by not copying them to Carbons-interested resources, or a client >> receiving a carbon copied message can indicate to the user that replying >> won't be possible. >> >> Aside: I also think this would be useful for message archives, to help >> not record duplicated PMs if the user has joined a room from multiple >> clients. >> > > Ignoring the protocol for a bit, what do users want? There's a lot of > user interest in having the same chats available across devices. I > would assume users would want the same for chatrooms and MUC PMs… > > We also have mutli-party chats where a one-to-one chat is upgraded to > a MUC [1]. Would that mean users are happily chatting across multiple > devices, they add a person to the chat and are suddenly stuck to one > device? > > I think MUC is just incompatible with carbons with no clean way to > combine them, however a carbons-like XEP for MUC would be highly > desirable. Coincidentally, this was a problem I was attempting to > solve today for a service I'm working on: Multiple clients (BOSH > clients on multiple tabs, devices, native application) which needed to > have the same chatrooms open (It's like [1], but starting out with MUC > from the start). I'm starting out with broadcasts on join/leave from > the MUC service to users' resources, which may or may not be the ideal > design. > > [1] http://xmpp.org/extensions/xep-0045.html#continue I think one could do achieve carbons-like behavior in MUC today if the service supported multiple joins (say, different resourceparts under the same bare JID) to the same nickname. It looks like most (if not all) of the protocol bits are already in XEP-0045 to allow for that. Such behavior is underspecified, and that could be addressed by an informational XEP. - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
[Standards] Fwd: Minutes for 2013-09-11
FYI Begin forwarded message: > -BEGIN MINUTES- > > 0) Meeting logs > < http://logs.xmpp.org/council/130911/ > > > > 1) Roll Call > > Tobias Markmann, Matt Miller, and Matthew Wild present. Ralph Meijer and > Kevin Smith sent apologies. > > > 2) Proto-XEP Jingle SDP Content -- Accept as Experimental? > < http://xmpp.org/extensions/inbox/jingle-sdp.html > > > The council has decided not to accept this XEP as experimental, on the advice > of the Jingle SIG. Matthew Wild to inform the standards@ mailing list. > > > 3) Date of Next Meeting > > 2013-09-18 at 15:10 UTC > > > 4) Any Other Business > > A reminder to all that Council and Board elections are soon, and candidates > are still needed. Anyone planning to run should update the Wiki at < > http://wiki.xmpp.org/web/Board_and_Council_Elections_2013 >. > > A reminder to all that XMPP Summit 14 is Oct 21 and 22 in Portland, OR, US. > Anyone planning to attend should update the Wiki at < > http://wiki.xmpp.org/web/Summit_14 > or send a notice to < sum...@xmpp.org >. > > > -END MINUTES- - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
[Standards] Fwd: [Council] Minutes for 2013-09-04T15:10:00Z
FYI - m&m Matthew A. Miller < http://goo.gl/LK55L > Begin forwarded message: > From: Matt Miller > Subject: Minutes for 2013-09-04T15:10:00Z > Date: September 4, 2013 7:23:41 PM MDT > To: XMPP Council > > 0) Logs > > < http://logs.xmpp.org/council/130904/ > > > 1) Roll Call > > Kevin Smith, Matt Miller, Matthew Wild, Tobias Markmann present; Ralph Meijer > absent. > > 2) Date of Next Meeting > > 2013-09-11 at 15:10 UTC > Kevin sends apologies in advance. > > 3) Any Other Business > > 3.1) Voting Deadline > > Matt Miller asked for the deadline for votes on outstanding XEPs to be > extended. All present agreed to extend the deadline to 2013-09-18. > > 3.2) Next Council Elections > > Kevin Smith and Matt Miller uncertain of running for another term; Matthew > Wild and Tobias Markmass planning to run, and are encouraging others to also. > > 3.3) IETF Happenings > > It is noted that draft-moffitt-xmpp-over-websocket has been accepted as a > XMPP WG item. Reviews from XSF council members would be greatly appreciated. > > It is noted that draft-ietf-precis-framework and draft-ietf-precis-mappings > are in PRECIS WG LC (dependencies on 6122bis). Reviews from XSF council > members would be greatly appreciated. > smime.p7s Description: S/MIME cryptographic signature
[Standards] Concerns with "Data Forms - Dynamic Forms"
[ My apologies for the lateness in this response ] Regarding < http://xmpp.org/extensions/inbox/dynamic-forms.html >, it has not yet been accepted by Council because there appear to be strong similarities between this and XEP-0050: Ad-Hoc Commands, at least as currently documented. It is requested that the document first be updated to discuss differences between it and XEP-0050 before being considered for Experimental. - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] BOSH updates from last summit
On Jul 18, 2013, at 10:33 AM, Peter Saint-Andre wrote: > On Thu, Jul 18, 2013 at 04:48:08PM +0100, Ashley Ward wrote: >> I was just thinking about the updates we discussed about the BOSH spec. I >> think all the patches were posted to the mailing list, but did anyone >> actually make the updates to the spec itself in the end? I'm happy to trawl >> back through the mailing list and make the updates. >> >> This was the wiki page with the list of changes: >> >> http://wiki.xmpp.org/web/BoshIssues > > Hey Ash, I was thinking about the other night while trying to clear out > my inbox. It definitely would be good to get all the fixes incorporated. > I think Matt Miller, Winfried Tilanus, and Stefan Strigler would have > the best idea of where we stand here. > > /psa > I think we all got a little busy, and lost track of it. If I recall correctly, all of the things we signed up to fix are done, but no one's rolled that into a single patch yet. I'd be happy to do that, though...unless Winfried already did it and forgot to push it upstream (-: - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] XEP-280 and MUC private chats
On Jul 14, 2013, at 1:13 PM, Mathieu Pasquet wrote: > On Sun, Jul 14, 2013 at 05:36:51PM +0100, Kevin Smith wrote: >> On Sun, Jun 9, 2013 at 7:40 PM, Mathieu Pasquet >> wrote: >>> I was starting to implement carbons in poezio when I came across some >>> kind of design issue that I haven’t been able to work out. >>> >>> As I understand it (and in the use case explained in the introduction), >>> Carbons provide a way to minimize the nuisance of changing devices, by >>> providing all the messages with 'chat' type to all the carbon-enabled >>> clients. >>> >>> The requirements also state that “All clients that turn on the new >>> protocol MUST be able to see all inbound chat-type messages”. >>> >>> However, in the case of private MUC messages (XEP-0045, 7.5), the >>> messages are also of type 'chat', causing them to be forwarded as normal >>> chat messages. But the other resources are not necessarily present on >>> that MUC, so they will receive the messages just fine, as with any >>> direct conversation with a fulljid, but they won’t be able to reply, >>> because I believe most MUC implementations will check the fulljid and >>> reply with an error. >>> >>> I can’t think of a straightforward solution to this issue, as the server >>> doesn’t know about MUC, neither does the other resource. >>> >>> On the sender part, it might be solved by including a with >>> each message sent through such chats, but on the receiving part, AFAIK >>> there is no way to distinguish those. >>> >>> I think the XEP should cover that case, because it is rather common to >>> have private conversations with people in a groupchat, and letting >>> clients guess how they should handle the message is very error-prone. >> >> Could you disco any unknown JIDs to see if they're users or MUCs? >> >> /K > > Yeah, that’s what I went with (I had forgotten about it at the moment of > writing that email). > > I think the XEP should indicate such a behavior, as a client developer > might forget about this case. > > Or even better, maybe the server could perform that disco, although I > get that making changes to already-deployed implementations might be > painful. > > -- > Mathieu Pasquet (mathieui) > This makes sense; I'll try to get this added in the coming weeks, post-IETF (-: - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
[Standards] Fwd: [Council] Minutes 2013-06-19
FYI Begin forwarded message: > From: Matt Miller > Subject: Minutes 2013-06-19 > Date: June 19, 2013 11:19:54 AM MDT > To: XMPP Council > > Logs: < http://logs.xmpp.org/council/130619/ > > > 1) Roll Call > Matt Miller, Tobias Markmann, Matthew Wild present; Ralph Meijer arrived > late; Keven Smith absent with apologies > > 2) Proposed XEP: SOX < http://xmpp.org/extensions/inbox/sox.html > > Accept as Experimental? > > No objections from all present; Kevin Smith has a fortnight to object. > > 3) Proposed XEP: Chat Markers < > http://xmpp.org/extensions/inbox/chat-markers.html > > Accept (revision) as Experimental? > > No objections from all present; Kevin Smith has a fortnight to object. > > 4) Date of Next Meeting > No noted absences for next meeting. > > 5) Any other Business > > 5.1) Outstanding Proposed XEPS > > Peter Waher has submitted new revisions to HTTP over XMPP and Color Data Form > Validation, but have not yet made it to the inbox. Will be considered once > the inbox is updated. > > 5.2) XEP Editor Status > > Discussion on the status of the current XEP editor. It has been suggested > that a job description be drafted and the board or council solicit for > volunteers. It has also been asked what can be done to distribute the work > to multiple individuals. Peter Saint-Andre to report to the Board and > Council how the XEP Editor role might be distributed. > > No actions for the council at this time. > > > 5.3) Jingle vs. SIP/SDP > > Philipp Hancke brought up a question on XMPP direction for SIP/SDP versus > Jingle. The consensus of the Council members present is to form a Special > Interest Group (SIG) to explore technical direction and report to the > council. The SIG leaders are Dave Cridland (chair), Philipp Hancke, Lance > Stout, and Ralph Meijer; discussion will be on the jin...@xmpp.org mailing > list. > > Kevin Smith has a fortnight to comment. > > > - m&m > > Matthew A. Miller > < http://goo.gl/LK55L > > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] resurrecting Hop Check (XEP-0219)
On Jun 12, 2013, at 8:41 PM, Peter Saint-Andre wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 6/6/13 6:40 AM, Matthew Wild wrote: >> On 6 June 2013 10:21, Simon Tennant wrote: >>> End to end encryption is a worth goal. This is very cool for >>> getting information on the s2s connection. >> >> Perhaps on first sight. However this kind of usage is exactly why >> the XEP died last time around. It isn't suitable for anything >> except purely informational/debugging purposes. This is because the >> link can change - it might be encrypted when you check it, and then >> reconnect unencrypted without you knowing. Also, malicious entities >> can always lie. > > What I'd like is to know whether the connection from my personal IM > server (stpeter.im) or my company's IM server (say, cisco.com) to a > random server like prosody.im or jabber.ietf.org is encrypted. Sure, > malicious entities can lie, but I try not to create accounts or > authenticate with malicious servers. :-) Look, I need to have *some* > level of trust in the server I authenticate with. I just want to know > if the path from there to the next server is encrypted, too. If I'm a > server admin presumably I have some kind of server-side tool I can > use, but that's not the case if I'm not an admin. I don't disagree that the user is trusting their server by logging in. And if this check were to stop at "my.domain --> other.domain", then I can see some confidence in the results because of the trust. Changes in the state *could* be dealt with by making this information available in a pubsub-like manner (I sensed the collective shudder from some of our server developers and operators before I even typed that sentence (-: ). However, that trust doesn't carry over to the answer for "other.domain --> contact@other.domain" which users will want so very, very desperately. I don't necessarily have a problem with this as a protocol-level diagnostic tool; it can help users (or rather, the developers of the client the user interacts with) and admins to troubleshoot. But the potential of abuse and over-interpretation is extremely high. - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Minutes 2013-05-29
On Jun 3, 2013, at 2:22 PM, Peter Waher wrote: > Hello > > 1) Regarding: > >> 3) ProtoXEP: Data Forms - Color Field Type < >> http://xmpp.org/extensions/inbox/color-parameter.html > >> Accept as Experimental? >> >> RM, TM, MW have no objections. MM has objections (prefixing of XEP-0122 >> elements). Author(s) to submit a revision correcting XEP-0122 use. >> KS have one fortnight to note objections. > > I'm unsure what you mean by this. Could you provide an example or reference > into the XEP-0122 that clarifies this point? > > In XEP-0122 I read: "The use of namespace prefixes is RECOMMENDED for large > forms, to reduce the data size." > > Why do you feel this is not done in this XEP? > I apologize for my misreadings, and lift my objections. > 2) Regarding the HTTP over XMPP XEP posted earlier. I have still a couple of > questions posted to the council and the standards list, that have not been > answered. Could you please take a look at my latest comments again so that I > know how to proceed? While I still have some concerns about the non-IBB chunked model, that is not holding it up. The biggest outstanding issues are the unclear copyright ownership around the SOAP examples. The appear to be from W3Schools, but it is unclear if you have rights to place them into a XEP, which then requires you to assign those rights to the XSF. We cannot accept this proto-XEP until the copyright issues are resolved. - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
[Standards] Fwd: Minutes 2013-05-29
FYI Begin forwarded message: > From: Matt Miller > Subject: Minutes 2013-05-29 > Date: May 29, 2013 10:03:43 AM MDT > To: XMPP Council > > 0) Roll Call > > Matt Miller (MM), Matthew Wild (MW), Ralph Meijer (RM), Tobias Markmann (TM), > present; Kevin Smith (KS) arrived late. > > 1) XEP-0297: Stanza Forwarding < http://xmpp.org/extensions/xep-0297.html > > Advance to Draft? > > RM, TM, MW +1 at first. MM -1 until §3.2, #5 is changed from SHOULD embed to > MUST embed > KS notes a preference for embedding, but to vote on list within one fortnight. > > 2) ProtoXEP: Chat Markers < > http://xmpp.org/extensions/inbox/chat-markers.html > > Accept as Experimental? > > (KS arrives) > > RM has no objections. MM, MW have objections (lack of s2s considerations). > MW to send discussion to standards@xmpp.org > TM, KS have one fortnight to note objections. > > 3) ProtoXEP: Data Forms - Color Field Type < > http://xmpp.org/extensions/inbox/color-parameter.html > > Accept as Experimental? > > RM, TM, MW have no objections. MM has objections (prefixing of XEP-0122 > elements). Author(s) to submit a revision correcting XEP-0122 use. > KS have one fortnight to note objections. > > 4) Date of Next Meeting > > 2013-06-05T15:00:00Z > > 5) Any other Business > > 5.1) Color coding XEPs by Status > > RM asked about any effort to better indicate what state XEPs are in by color > coding. No work has been done toward this the Council is aware of, but proof > of concepts are welcome. > > 5.2) XEP-0280: Message Carbons < http://xmpp.org/extensions/xep-0280.html > > Issue Last Call? > > +1 from MW, TM, RM, MM. KS as one fortnight to vote on list. > > > - m&m > > Matthew A. Miller > < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Comments on "HTTP over XMPP"
On May 22, 2013, at 8:50 PM, Peter Waher wrote: > Hello Matt (again) and Council members. > > Seems I sent the last mail (below) too quickly, and started to think a > little, with regards to IBB. I have a set of questions/reflections: > > The IBB requires an open iq-stanza (with response and possible handshake) and > a closing iq-stanza (with response) for each transfer. For streamBase64 I see > no problem in converting to IBB for transport. I agree that IBB is better > suited for this, as it is already defined. > > But for normal chunked transfer, this seems very impractical. This may result > in hundreds of additional messages that needs to be sent for a simple > API-transaction, invoking a set of calls, etc. Or a normal web page > (containing links to much embedded content). > > Note that chunked transfer is often used when content size (Content-Length) > is not known, and the server decides to start transmitting anyway to maintain > buffers small. This is often the case as I mentioned for dynamic content, not > necessarily large, for instance in results to API calls. To add such a large > extent of messages for each response will decrease performance radically > without much gain. > > I therefore wanted to ask if it is possible to leave the chunkedBase64 > encoding as it is, and only convert streamBase64 to IBB? I believe the > overhead of messages merits a separate handling in this case. > > The chunk message contains a last attribute also that is a convenient way to > avoid the last close iq stanza in IBB. This saves a lot during small > transfers. Consider a relatively small HTTP GET with a response of 3 chunks. > Using IBB it would require at least 2+2+3+2=9 messages (http get+reponse+ibb > open+ibb open response+3 chunks+close+close response), while as it is now, > only 5 messages are required. > > The streamBase64 part is different however, as it is probable that very few > (probably at most one) stream is active from a client at a given time. Having > the additional open and close commands here gives no visible additional cost > in terms of messages. > > What is the opinion of the council: > > Is the use of IBB so important in this case that a performance degradation is > preferred in the chunked case? > > Or is it sufficient to use IBB only in the streamBase64 case, and leave the > chunkedBase64 case as is? > One of the things IBB worked through is data loss. The current definition just assumes the HTTP/XMPP "client" is there and ready to receive the stanzas containing the data chunk. While it should be, networks and software is not 100% reliable and that "client" could have lost their connection just after sending the . The HTTP/XMPP "server" is not going to have any clue things aren't going where it expects unless it's receiving presence for the HTTP/XMPP "client". You could build this into HTTP/XMPP, but at some point you will get to the point where it duplicates much of IBB (which is awfully small to begin with) ... so why not use IBB in the first place? - m&m Matthew A. Miller < http://goo.gl/LK55L > [AMP] XEP-0079: Advanced Message Processing < http://xmpp.org/extensions/xep-0079.html > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Forward Stanza Inconsistency between XEP-0280 and XEP-0313
On May 22, 2013, at 1:57 PM, Spencer MacDonald wrote: > Thanks Lance, > > OK so the xmlns element should be a parent not a sibling. > > Yes, the extension using stanza forward is supposed to contain it. This is a SHOULD in XEP-0297 (hrm, I wonder if this ought to be a MUST?)...now (-: - m&m Matthew A. Miller < http://goo.gl/LK55L > > On Wednesday, 22 May 2013 at 20:37, Lance Stout wrote: > >> On May 22, 2013, at 12:27 PM, Spencer MacDonald >> 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 > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] LAST CALL: XEP-0297 (Stanza Forwarding)
< http://joeyandchristy.com/images/artextras/logos/awebreadylogos/resurrect.jpg
>
On Nov 28, 2012, at 9:34 AM, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on XEP-0297
> (Stanza Forwarding).
>
> Abstract: This document defines a protocol to forward a stanza from one
> entity to another.
>
> URL: http://xmpp.org/extensions/xep-0297.html
>
> This Last Call begins today and shall end at the close of business on
> 2012-12-14.
>
> Please consider the following questions during this Last Call and send your
> feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to
> clarify an existing protocol?
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, at least as needed for [CARBONS] and [XMPP-E2E].
> 4. Do you have any security concerns related to this specification?
No further security concerns that are not already covered in the document.
> 5. Is the specification accurate and clearly written?
Yes, typos not withstanding ("There are many situations is which an entity
needs" --> "There are many situations in which an entity needs", is the first I
noticed).
- m&m
Matthew A. Miller
< http://goo.gl/LK55L >
[CARBONS] XEP-0280: Message Carbons < http://xmpp.org/extensions/xep-0280.html >
[XMPP-E2E] End-to-End Object Encryption and Signatures for the Extensible
Messaging and Presence Protocol (XMPP) <
http://tools.ietf.org/html/draft-miller-xmpp-e2e.html >
smime.p7s
Description: S/MIME cryptographic signature
[Standards] Comments on "Pubsub Subscription"
I really only have one comment, and that is around the need (and algorithm) for itemID generation. * I think it would help greatly to add a statement or paragraph explaining why it's necessary. I personally don't really see the need, given a pubsub service MUST generate unique item IDs. * I think the algorithm is susceptible to collisions. If item ID generation is really necessary, I would suggest coming up with a stronger algorithm. - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
[Standards] Comments on "HTTP over XMPP"
I have some comments regarding the Proto-XEP "HTTP over XMPP": * I don't think the use of is appropriate here, as per the guidelines in RFC6120 § 8.2.3. At a minimum, the unsafe methods (e.g., DELETE, POST, PUT, et al) ought to be , although a strong argument can be made that all ought to be . * This protocols seems like an appropriate place to use [SHIM]. * I note that "Response formats" seem to be useable in requests. I would consider changing the term to something a little more generic. * Are there any concerns about what data transfer mechanisms/resposne formats an entity is expected to accept? This document seems to imply all entities MUST understand all of them, and I'm not sure that's a reasonable implication. * It would seem to me that the actual data transmission of chuckedBase64 and streamBase64 are better implemented as [IBB], or use Jingle with [XEP-261] IBB candidates. - m&m Matthew A. Miller < http://goo.gl/LK55L > [SHIM] XEP-0131: Stanza Headers and Internet Metadata < http://xmpp.org/extensions/xep-0131.html > [IBB] XEP-0049: In-Band Bytestreams < http://xmpp.org/extensions/xep-0047.html > [XEP-261] XEP-0261: Jingle In-Band Bytestreams Transport Method < http://xmpp.org/extensions/xep-0261.html > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] SASL GSSAPI kerberos principal
On May 10, 2013, at 8:29 AM, Alexander Gnauck wrote: > currently I have some issues with the kerberos principal in GSSAPI SASL > authentication. > What is the correct way for building the kerberos principal for > authentication in the client? > > 1) xmpp/xmppdomain@realm > 2) xmpp/hostname@realm > > with hostname I mean the host we are connecting the TCP socket to according > to SRV lookups. > > I have tested only on Cisco XCP and M-Link yet. XCP puts the kerberos > principal in a special attribute which is nice and it looks like Mink wants > the hostname here and not the xmpp domain. > We tried to address this with domain principals (//@REALM) and [XEP-0233], but that as gone deferred. I think there was one implementation each (client, server) but I've lost track of them. I'd be happy to help move that to draft if there is interest. Absent all of that, GSSAPI requires the hostname. It's not exactly inline with our expectations in XMPP, though, which is why some of us started on XEP-0223. - m&m Matthew A. Miller < http://goo.gl/LK55L > [XEP-0233] "XEP-0233: Domain-Based Service Names in XMPP SASL Negotiation" < http://xmpp.org/extensions/xep-0233.html > smime.p7s Description: S/MIME cryptographic signature
[Standards] Fwd: Minutes 2013-04-24T15:00:00Z
FYI Begin forwarded message: > From: Matt Miller > Subject: Minutes 2013-04-24T15:00:00Z > Date: April 24, 2013 9:29:48 AM MDT > To: XMPP Council > > Room Logs: http://logs.xmpp.org/council/130424/ > > 1) Roll call > Tobias Markmann (TM), Matt Miller (MM), Matthew Wild (MW) present. Ralph > Meijer (RM) absent. Kevin Smith (KS) sent apologies in advance. > > > 2) http://xmpp.org/extensions/inbox/rayo.html > Accept as Experimental? > > No objections from TM and MM. MW (and others) have one week remaining to > object on list. > > > 3) http://xmpp.org/extensions/inbox/sensor-network-control.html > Accept as Experimental? > > No objections from TM and MM. MW (and others) have one week remaining to > object on list. > > > 4) http://xmpp.org/extensions/inbox/sensor-network-concentrators.html > Accept as Experimental? > > No objections from TM and MM. MW (and others) have one week remaining to > object on list. > > > 5) Next Meeting > > 2013-05-01 @ 15:00 UTC. > > > 6)Any Other Business > > None. > > - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] [BOSH] More Patches - Better explanation for "1 sometimes 2 sockets" behavior
On Feb 24, 2013, at 6:42 PM, Dave Cridland wrote: > On 20 Feb 2013 21:49, "Matt Miller" wrote: >> >> Attached is a patch to try and better explain what the network > connectivity looks like in the BOSH world. I decided to take the approach > of rewriting the section "The BOSH Technique", and added an ASCII art > diagram to illustrate it. >> >> A more human-friendly version is available at < > http://outer-planes.net/~linuxwolf/xsf/extensions/xep-0124.html#technique >. >> > > There's an implied time-line of the underlying XMPP session; putting that > in might make the two HTTP timelines make more sense. Certainly it'd be > more complete. > I started down that road, and found the output to be more than a page's worth long, and some IRL feedback led me to believe it made the explanation worse instead of better; sometimes too much information can be harmful (-: But I'd be willing to try again. As for Peter's question (merging XEPs -0124 and -0206), there's no objection from me. Some originally thought BOSH would be used for more than just XMPP, but that hasn't really materialized as far as I've seen. - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
[Standards] [BOSH] More Patches - Better explanation for "1 sometimes 2 sockets" behavior
Attached is a patch to try and better explain what the network connectivity looks like in the BOSH world. I decided to take the approach of rewriting the section "The BOSH Technique", and added an ASCII art diagram to illustrate it. A more human-friendly version is available at < http://outer-planes.net/~linuxwolf/xsf/extensions/xep-0124.html#technique >. Critiques welcome! - m&m Matthew A. Miller < http://goo.gl/LK55L > bosh.how-it-works.patch Description: Binary data
[Standards] Proposed Patch: Pipelining
Attached is a proposed patch to de-recommend HTTP pipelining, as discussed at the summit. Critiques welcome! /me moves onto "1 sometimes 2 sockets" - m&m Matthew A. Miller < http://goo.gl/LK55L > pipelining.patch Description: Binary data
Re: [Standards] BOSH and "Multiple Streams"
On Feb 11, 2013, at 6:25 AM, Stefan Strigler wrote: > Hi, > > Am 08.02.2013 um 23:55 schrieb Matt Miller : > >> In working on the patch to address HTTP pipelining, I cascaded into section >> 16: Multiple Streams. >> >> Multiple Streams seems to require support for HTTP pipelining, but feels as >> if it runs afoul of even the basic requirements for HTTP pipelining (not >> including the "SHOULD NOT use pipelining with non-safe or non-indempotent >> methods"). I have a hard time working out my patch without doing something >> substantial about Multiple Streams. > > As to my understanding Multiple Streams do not require HTTP Pipelining. > Actually the XEP says that Mulitple Streams might come in handy in case HTTP > Pipelining is not available. > One does not need Multiple Streams (as vaguely defined in BOSH) to overcome the lack of HTTP pipelining. Perhaps there is intermingling of the term connection reuse (using a single socket connection for multiple HTTP request/response pairs, serially) with HTTP pipelining (sending multiple HTTP requests in parallel over the same socket connection). XEP-0124 does make some mention opening a new socket connection to send a stanza if the previous request is still held pending a response. This is what every BOSH implementation I've worked with does today, without the BOSH definition of Multiple Streams. In fact, I'm working on a patch to XEP-0124 that (attempts to) better explain this concept. >> Does anyone actually implement this, and depend on its support? If so, then >> I think we ought to separate this into its own XEP, and fixing all of the >> vagueness and ambiguities around it. If not, then I would STRONG RECOMMEND >> removing it completely. > > Some years ago I ran into an issue where we wanted to deal with multiple XMPP > session at the same time and due to browser restrictions couldn't create more > simultaneous BOSH sessions. That's why we came up with this proposal at first > hand. But then we never had it implemented. While I can understand the use-case, the fact we're hard-pressed to find implementations tells me this is a candidate for removal. - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
[Standards] BOSH and "Multiple Streams"
In working on the patch to address HTTP pipelining, I cascaded into section 16: Multiple Streams. Multiple Streams seems to require support for HTTP pipelining, but feels as if it runs afoul of even the basic requirements for HTTP pipelining (not including the "SHOULD NOT use pipelining with non-safe or non-indempotent methods"). I have a hard time working out my patch without doing something substantial about Multiple Streams. Does anyone actually implement this, and depend on its support? If so, then I think we ought to separate this into its own XEP, and fixing all of the vagueness and ambiguities around it. If not, then I would STRONG RECOMMEND removing it completely. Thoughts? - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] [Summit] BOSH actions
This is not implemented in CAXL either. Given just about none of the known web-based XMPP libraries implement it, the rationale seems to be moot now. I think its safe to remove altogether. - m&m Matthew A. Miller < http://goo.gl/LK55L > On Feb 5, 2013, at 6:08 AM, Peter Saint-Andre (psaintan) wrote: > As I recall this was added to support really ok browsers. > > Sent from mobile, might be terse > > On Feb 5, 2013, at 4:27 AM, "Steffen Larsen" wrote: > >> True true, >> Ive been looking on some other client implementations as well, and they do >> not implements it as well. So I think it seems sane to remove it. >> >> /Steffen >> >> On Feb 5, 2013, at 12:24 PM, Ashley Ward wrote: >> >>> We don't use it in emite either. >>> >>> Also clients which do implement it should fall back gracefully to utf-8 >>> anyway. >>> >>> -- >>> Ash >>> >>> On 04/02/2013 21:57, "Stefan Strigler" wrote: >>> JSJaC doesn't either. And at least the old implementation of ejabberd's mod_http_bind didn't as well. .Steve Am 04.02.2013 um 22:39 schrieb Steffen Larsen : > Just checked strophe, and it does not use it. I'll check some more > implementations that uses BOSH for transport. Maybe that would give us > an indication. > > /Steffen > > On Feb 4, 2013, at 10:06 PM, "Peter Saint-Andre (psaintan)" > wrote: > >> That sounds sensible. >> >> Sent from mobile, might be terse >> >> On Feb 4, 2013, at 1:26 PM, "Ashley Ward" >> wrote: >> >>> It would be great to keep them consistent, but is it worth potentially >>> breaking implementations? I think the main problem with accept was >>> that >>> the example was inconsistent with the text. >>> >>> In fact, I very much doubt anyone should be using that option as xmpp >>> mandates the use of utf-8, and I doubt anyone's using bosh for >>> anything >>> other than xmpp. Perhaps we should just look at getting rid of that >>> attribute? >>> >>> -- >>> Ash >>> >>> On 04/02/2013 10:30, "Steffen Larsen" wrote: >>> Cross-posted from the summit list (sorry making noise). Here are my small notes to the BOSH action list (embedded). /Steffen Begin forwarded message: > From: "Peter Saint-Andre (psaintan)" > Subject: Re: [Summit] BOSH actions > Date: February 2, 2013 10:18:01 PM GMT+01:00 > To: XMPP Summit > Cc: Bidirectional Streams Over Synchronous HTTP , > XMPP > Summit > Reply-To: XMPP Summit > > Maybe it would be better to take the technical discussion to the > standards@ list? > > Sent from mobile, might be terse > > On Feb 2, 2013, at 4:32 PM, "Steffen Larsen" > wrote: > >> Hey, >> >> Just saw the issue with the accept attribute. How about charset? >> It is >> currently space separated in the example (and it also says) - but >> should we not comma separate that like the accept attribute? >> >> Its on 7.2 in http://xmpp.org/extensions/xep-0124.html: >> charsets='ISO_8859-1 ISO-2022-JP' >> -Just my 50 cent >> >> /Steffen >> >> On Feb 2, 2013, at 4:18 PM, Winfried Tilanus >> wrote: >> >>> Hi all, >>> >>> I updated the BOSH issues page with the results & and who will be >>> writing patches. >>> http://wiki.xmpp.org:12480/web/BoshIssues >>> >>> I only forgot who will be writing the patch for the first issue >>> (remove >>> Pipelining). Plz check if your name pops up at the correct places >>> and >>> ping me if there are any problems! >>> >>> happy patch-writing! >>> >>> Winfried >> smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] XEP-0198 and SASL-Anonymous
On Jan 25, 2013, at 7:08 AM, Winfried Tilanus wrote: > Hi, > > And now we are talking about XEP-0198, I think the security > considerations should take some more situations in account for the > session hijacking protection. When properly and securely authenticated, > the authentication is enough protection against sesion hijacking. But > when using SASL-Anonymous, the session id MUST be unpredictable AND the > session MUST be encrypted, otherwise the session can be hijacked. Think > it would be better to add that to the spec. > Those are good points, although transport encryption is only as trusted as the certificate in use (think of all the times we have clicked "I understand the risks"...). I think it should also be valid for the server to prohibit stream management resumption if using SASL ANONYMOUS. - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] XEP-0012 And Absolute Time
On Jan 24, 2013, at 12:04 PM, Peter Saint-Andre wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 1/24/13 9:20 AM, Tobias Markmann wrote: >> >> On Thu, Jan 24, 2013 at 5:01 PM, Matt Miller >> mailto:linuxw...@outer-planes.net>> >> wrote: >> >> Sure, but there are potential privacy concerns here. Sending UTC >> always does not give away my (extremely broad) geographical >> location, while including the timezone offset does. >> >> I am not suggesting we force this 'stamp' to always be UTC. >> Personally, I think I might like the timezone offset to be >> included (my last is 3 hours ago because it's the middle of the >> night for me compared to you"). What I am suggesting is adding a >> note somewhere about the concern. >> >> >> Wouldn't it make more sense to add this security notice to >> XEP-0082, since it applies to everywhere you use timestamps that >> include a timezone? > > Yes, that sounds like the right place. Works for me. - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] XEP-0012 And Absolute Time
On Jan 23, 2013, at 4:00 PM, Tobias Markmann wrote: > On Wed, Jan 23, 2013 at 11:54 PM, Matt Miller > wrote: > >> To be clear, 'stamp' is the equivalent of 'seconds', in absolute terms. >> The recipient wouldn't deduct 'seconds' from 'stamp' to get the ultimate >> result. >> > > Yes...if both present then on the system initially sending the stanza, > stamp = now() - seconds. No deductions needed if 'stamp' is present. > >> >> Also, would 'stamp' always be in terms of UTC, or are other offsets >> permitted? I can see pros and cons for both sides of that fence. >> > > I think the value of 'stamp' would be according to XEP-0082, which allows > for optional time zone specifier at the end (just 'Z' at the end meaning > UTC). > > Sure, but there are potential privacy concerns here. Sending UTC always does not give away my (extremely broad) geographical location, while including the timezone offset does. I am not suggesting we force this 'stamp' to always be UTC. Personally, I think I might like the timezone offset to be included (my last is 3 hours ago because it's the middle of the night for me compared to you"). What I am suggesting is adding a note somewhere about the concern. - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] XEP-0012 And Absolute Time
On Jan 23, 2013, at 3:42 PM, Tobias Markmann wrote: > Hi, > > kind of as follow up post to my recent lone message here a more general > approach to the problem. > > How about adding an optional attribute to XEP-0012's query stanza (eg. > stamp) for indicating absolute time. Depending on what you use the time for > you might require the entities in XMPP to be synced in time. This would be > backward-compatible, by still requiring seconds attribute and having an > optional stamp attribute. So it would look like: > > > > > With relative time, the only way to do it now, to get absolute time you > either have to ping the remote party for its current time (+ transmission > delay) or use your own time. Either way you get something but probably not > the actual absolute time of the described event. > > Thoughts? Opinions? > > Cheers, > Tobi To be clear, 'stamp' is the equivalent of 'seconds', in absolute terms. The recipient wouldn't deduct 'seconds' from 'stamp' to get the ultimate result. Also, would 'stamp' always be in terms of UTC, or are other offsets permitted? I can see pros and cons for both sides of that fence. I've got no objections to this proposal, and it seems to meet the threshold for a Final XEP. - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
