Re: [Standards] MSN does XMPP
15/09/2011, Thijs: > It is explained pretty clearly in LiveConnectPrelim.chm, which you > can find from http://dev.live.com (you probably need to sign up to > access the "technical preview"). Can anyone with access to that documentation please convert it to a readable format and make it public? Thanks! -- David signature.asc Description: PGP signature
Re: [Standards] MSN does XMPP
14/09/2011, Justin:
> - login requires using a special SASL mechanism
> "X-MESSENGER-OAUTH2".
> - JIDs are {identifier}@messenger.live.com, where {identifier}
> comes from the OAuth access token.
Could it be linked to this old, deferred specification?
http://xmpp.org/extensions/xep-0235.html
Whatever it is, I hope they'll document it at some point.
I'm confident that they will – if they want to allow connection via
traditional clients, it would be counter-productive to force
developpers to reverse-engineer the authentication protocol.
--
David
signature.asc
Description: PGP signature
[Standards] Indexing messages (Was: Re: Correcting last message)
On Fri, 25 Mar 2011 12:21:10 -0400, Mark Rejhon wrote: > -- Wild idea out of the blue: what about the idea of a different > standard (third standard) called a message indexing standard, a method > of referencing a specific historical line, that both your standard and > possible future versions of my standard, can take advantage of? Using the 'id' attribute on message stanzas would be a clean way of indexing messages... if only that attribute were guaranteed to always exist on such stanzas. Unfortunately, the 'id' attribute is only mandatory on iq stanzas. I can see two approaches for solving this: 1. Only messages with an 'id' attribute can be later referenced/edited. Smart clients would always insert that attribute on messages. I like this approach because it requires no change to any spec, and doesn't introduce compatibility issues. Only messages without an id couldn't be edited later. We need to decide whether this is a problem, and whose. For this feature (correcting one's own message), I would say that this is the emitting client's, so I don't consider it an interop issue. 2. Modify one of the specs somewhere in the chain to require id attributes on messages. What spec, and how? Does anybody see another approach? FWIW, let's not forget that there have been, and will be, other situations where an id attribute on messages would be of great help. For example (but there might be others), being able to quote/reference/point a previous message in a conversation. In some use cases, not including this attribute could be someone else's problem. For instance, a flag-this-message-as-spam feature would definitely not be happy with optional id attributes. Who would include an id on their spam so that it can be easily flagged? ;) Cheers. -- David
Re: [Standards] NEW: XEP-0291 (Service Delegation)
Hello, (First of all, sorry if I'm not answering in the proper place. The 'Discussion venue' section of the XEP makes me think I am, though.) 27/01/11, XMPP Extensions Editor: > Version 0.1 of XEP-0291 (Service Delegation) has been released. > > Abstract: This specification defines an approach for users to > delegate certain services (e.g. pubsub) to alternative JIDs. > > Changelog: Initial published version. (psa) > > URL: http://xmpp.org/extensions/xep-0291.html I see the use case that this XEP addresses as an equivalent of HTTP 301 and 302 return codes. As such, I'm not sure that asking and receiving the whole list of delegations of a given entity is the right way to go, or at least the most sensible one. If you want to, say, play chess with someone, you don't really care about their pubsub service, or the other 50 services they're announcing delegation for. And caching is not an answer, because it puts the complexity on the client's side. This approach also only works well if the list of delegated services doesn't grow too much, which means it's not scalable. Also, it's a bad thing for mobile or generally low-bandwith devices. We don't want to have to "fix" this XEP in 3 years with a "delegation list versioning" one. Do you ask an HTTP server about all redirected URLs, cache that answer, and the check that list against any URL you want to fetch? Instead, I would say that the "regular" use case is that you try to play chess with someone, and receive an answer that says "please talk to JID xxx for that". I might have overlooked something obvious though. What do you think? -- David signature.asc Description: PGP signature
Re: [Standards] Name of IQ query nodes
18/12/10, Matthew: > There are no implicit restrictions, if no text states that the child > element must be then it need not be. In the early days a lot > of specs used by convention, but there is no need for it and > it was abandoned in later extensions as you can see. Thanks for the clarification about the tag name. > " >An IQ stanza of type "get" or "set" MUST contain one and only > one child element that specifies the semantics of the particular >request or response. > " -- http://tools.ietf.org/html/rfc3920#section-9.2.3 > > Just making sure - have you read 3920? I have, although I don't know it by heart. When I looked again for the number of expected children, I couldn't find it. Sorry for the noise about that part. -- David signature.asc Description: PGP signature
[Standards] Name of IQ query nodes
[Note to the list moderators: I sent the same email a moment ago, before subscribing to the list. Please discard it.] Hello, It is not clear from the specification what the name of the query node of an IQ may (or should) be. In RFC 3921, it is implied that it is "query". However, there's no mention of whether this is a mandatory tag name or not. Because of that, and because there's no example of any other tag name in the whole RFC, I would tend to believe that it is indeed the only expected tag name. However, several XEPs use another one, for example 'vCard'. I think the expected name is actually described in the definition of the corresponding namespace, which would mean that as far as the RFC is concerned, any name is in fact allowed, provided it honors the namespace's definition. Am I right? In any case, we should maybe clarify this detail in the specification. I think several generic IQ-handling implementations rely on the tag being called "query", which breaks their behaviour in case the query tag has a different name. One example is xmpppy[1], but there might be existing or future others if the situation stays unclear. As a related note, it doesn't seem clear either how many direct children an IQ stanza is supposed to have. All examples in the litterature show only one, but I can't see that defined anywhere. [1] See source code of IQ class: http://xmpppy.sourceforge.net/apidocs/xmpp.protocol.Iq-class.html Regards. -- David signature.asc Description: PGP signature
