Re: [Standards] stream restarts
On Thu, 2008-05-08 at 11:40 -0400, Stephen Pendleton wrote: > I think the reasons are: > > - There is no reason have have stream restarts because the reasons > they were introduced ended up not to be correct. > - The protocol "looks" better. Fewer stanzas are needed during the > login/authentication process I believe. > - Some implementations will not need to throw away/reset their parsers > anymore. Currently this is necessary for all implementations that I > know of and those using the style of architecture I show below will no > longer need to do this because the XML parser will be presented with a > complete XML stream, instead of multiple ones. I don't think we should > be changing the core protocol based on implementations though, so this > is less important to me. These are not compelling reasons to introduce a change to a protocol already in wide use. You cannot "clean up" an existing protocol, only make it messier by introducing transition issues.
Re: [Standards] ACTIVE: XEP-0239 (Binary XMPP)
On Tue, 2008-04-01 at 22:08 -0600, Peter Saint-Andre wrote: > Remko Tronçon wrote: > >> Abstract: This specification defines Binary XMPP, an obviously > >> superior representation of the Extensible Messaging and Presence > >> Protocol (XMPP). > > > > Shouldn't we be namespacing these elements? > > Aw, namespaces introduce unnecessary complexity. :) We can make up that complexity by using two different namespaces (one for "zero" and another for "one") and renaming the elements to "x". Since developers have already written plenty of code to handle the element name "x", they can reuse it to parse binary XML elements.
Re: [Standards] Jingle "implementability"
On Wed, 2008-01-30 at 17:53 -0800, Robert Quattlebaum wrote: > What if these plug-ins are actually separate processes? Imagine if you > were using some sort of XMPP client daemon, for example. In such a > setup, you would have separate processes for file transfer, > audio/video chat, roster, etc. With how Jingle is currently specified, > only one process would be allowed to do Jingle stuff at a time. So you > could video chat, but not while being able to do file transfers. You > could use file transfer, but not be able to do video chat. The Jingle process could itself have plugins (subprocesses again) to handle a/v or file transfer or whatever. Presumably this subprocess plugin architecture does not use blocking RPC. If it does, you have bigger problems; for instance, you can't do two file transfers at once.
Re: [Standards] Jingle "implementability"
On Wed, 2008-01-30 at 19:16 +, Alexander Jones wrote: > > I have a few implementation observations with respect to Jingle. The > > current implementation really requires all Jingle stuff to be managed > > centrally in an app. For example, you need a "Jingle engine" that things > > like file transfer and audio chat need to register with. This is > > problematic if you are implementing a Jabber client where all of the > > features are plug-ins. > Why not have a Jingle plugin, and AV Chat and File Transfer could > require its services? Agreed. Reimplementing Jingle in each of the functional plugins seems like the wrong answer; having some kind of nested plugin structure would be better.
Re: [Standards] Messages to unsubscribed contacts and resources
I also feel like bare jid sending would have better behavior in the presence of multiple client connections. I don't see why you wouldn't want your existing conversations to follow you when you switch from one device to another. It's not what clients do currently, though. I'm not sure whether it's wise to encourage such a fundamental change at this point. On Tue, 2007-12-11 at 21:22 +0100, Tomasz Sterna wrote: > On Wt, 2007-12-11 at 13:10 -0700, Peter Saint-Andre wrote: > > Because that's what it means to be in a chat session with someone -- > > you have a FullJID-to-FullJID connection, as it were. > > This is kind of "it is like this, because it is like this" answer. > > And as Robin pointed "a chat session" is a very fuzzy "definition". > > I still se no advantage in this approach. > And Robin and I pointed a few advantages of bare JID messaging. > > > > And remember that these messages are not necessarily human-readable > > text. What if you're sending a file via In-Band Bytestreams? Does half > > the file go to one resource and half to another? Ick. > > Is a IBB a "chat session"? Really? > This makes "chat session" definition even more fuzzy... > > > And I have a feeling of deja-vu. > We had this talk before and IIRC concluded that bare JID messaging is > better and is what we should recommend it and discourage the existing > full JID binding. > > Instead, we documented the full JID binding in RFC3921bis and encourage > it even more... :-/ > >
Re: [Standards] IETF SASL WG meeting
On Mon, 2007-12-10 at 10:20 -0800, Justin Karneges wrote: > I don't understand this talk about the SASL negotiation being attacked by a > MITM when it is taking place over TLS. There is brief mention of Bob > possibly not having a certificate or Alice not trusting Bob's CA. Does this > mean the channel binding problem only affects anonymous/unauthenticated TLS? It strengthens your security properties in cases where you trust your SASL authentication mechanism more than you trust the TLS authentication mechanism. If you trust TLS to authenticate the server to the client, then I believe you can do client-to-server authentication without any form of channel binding and you're fine.
Re: [Standards] Binary data over XMPP
On Mon, 2007-11-05 at 15:35 +0100, Tomasz Sterna wrote: > You cannot use out-of-the-box XML parser anyway. SAX-model XML parsers still qualify as "out of the box." > So, once is extracted from the stream and reported, > you stop feeding the data read from socket to parser, and fetch it > directly for routing. By the time you have received an event reporting the blob element, you have potentially already fed it a chunk containing the and some of your binary data. (Unless you're handing it characters one by one, or being careful to never feed chunks which contain a > character except at the end. Either is inefficient and hackish.)
Re: [Standards] rfc3920bis: stream restarts
On Wed, 2007-10-03 at 10:30 -0600, Peter Saint-Andre wrote: > That approach certainly seems cleaner from an XML standpoint (the > original stream is over, start a new one). I wouldn't worry too much about this. The primary way we abuse XML is requiring endpoints to be able to process partial XML documents--you cannot use a full-document XML parser on an XMPP stream because you can't wait until the end of the document in order to respond. Given that, the ability to leave the stream unfinished and throw it away isn't much of a stretch.
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
On Tue, 2007-09-11 at 19:51 +0100, Dave Cridland wrote: > If I ruled the world, I'd mandate TLS+SCRAM, and have a SHOULD for > TLS+YAP (the latter being plaintext-equiv on the server, but only a > single round-trip, so great for mobiles). You may be missing the most popular reason for sending plain-text passwords to the server (over TLS, one hopes): it's the only way for the server to check the password against an external verifier such as an LDAP server, AD controller, or Kerberos KDC. (GSSAPI krb5 auth is much better if you have an AD controller or Kerberos KDC, of course, but I don't hold out much hope for that being universally implemented in clients.)
Re: [Standards] message type='headline'
On Aug 28, 2007, at 12:15 PM, Joe Hildebrand wrote: As an aside to the discussion on priority ties, I think it would be cool for us to have a defined mechanism for sending messages to all online (non-negative priority) resources. Interesting. Conversely, I think it would be useful to be able to receive messages sent to all resources on your jid somehow. The obvious application would be a client-side logging agent. (Of course, if you've joined a MUC from two normal clients, your logging agent would get doubled messages.)
Re: [Standards] Comment to rfc3921 pt 11.1 : handling of messages to ressources with identical priorities
On Tue, 2007-08-21 at 09:34 -0600, Peter Saint-Andre wrote:
[Quoting Joe Hildebrand:]
> > I still believe that coming home to find a message ("hey!") which I have
> > already replied to while I was at work would be confusing at best, and
> > harmful at worst. Imagine: "sell 50 shares!".
At MIT we have a legacy chat system which always delivers to all
connected clients (has no concept of priority). In 15 years of usage,
I've never heard of a single case of anyone getting confused this way.
> I'm curious: how frequent are priority ties anyway?
I'm a little puzzled by how this part of this thread went. When I last
poked around, it looked like almost all XMPP clients were always setting
priority to 0 unless the user took specific action, so priority ties
were almost exactly as frequent as multiple resources.
Re: [Standards] whiteboarding and shared editing
On Mon, 2007-08-13 at 22:30 -0600, Peter Saint-Andre wrote: > I see nothing artificial about trying to build a generalized approach > that we can re-use for shared editing and real-time synchronization of a > wide variety of XML formats, not just SVG. I don't know if it's "artificial" or not, but "you should go back and solve a much more general and more vaguely defined problem" is generally a good way to kill a project. A generic XML editor isn't going to know much about the semantics of the document it is editing. It's not necessarily going to be a good framework for a whiteboarding application, any more than emacs is a good foundation for Photoshop. They both edit files, but...
Re: [Standards] JID Escaping
On Mon, 2007-07-30 at 10:49 -0600, Peter Saint-Andre wrote: > Or do what this person is going to do -- prevent people who have ' in > their email address from using Jabber! (Sorry, no address mapping for you!) I don't have any issue with JID escaping for characters like '. In fact, I don't know why ' isn't allowed in JID nodes in the first place, but what's done is done. I am concerned, though, that I could create stpeter [EMAIL PROTECTED] and clients would present that as [EMAIL PROTECTED]@example.com. Although the clued-in user could recognize that as an example.com JID, many would probably see it as "Peter with some weird extra routing gunk." Perhaps the answer is to say that clients MAY pick and choose which characters to unescape in order to avoid creating confusion for users. @ would probably be first on the chopping block, with space and / not too far behind.
Re: [Standards] JID Escaping
On Wed, 2007-07-25 at 21:18 +0530, Mridul Muralidharan wrote: > > That's not true of email; why does it need to be true of XMPP? If a JID > > node can contain a "@" character in its display representation, there's > > no nice way to display that JID safely to the user. > > [EMAIL PROTECTED]@montague.org is perhaps unambiguous but is certainly > > confusing. > This is invalid as a JID as per xmpp rfc. Of course it is. But [EMAIL PROTECTED] is to be displayed that way by clients according to XEP 106. It's right there as example #8 in section 5.1.
Re: [Standards] JID Escaping
On Wed, 2007-07-25 at 10:02 +0530, Mridul Muralidharan wrote: > As long as we have prohibited characters - and '@' is always going to be > there in node part, we will need escaping :-) There's an underlying assumption here that JID nodes must be able to contain, in their display representations, the verbatim identifiers from any other system. That's not true of email; why does it need to be true of XMPP? If a JID node can contain a "@" character in its display representation, there's no nice way to display that JID safely to the user. [EMAIL PROTECTED]@montague.org is perhaps unambiguous but is certainly confusing.
