Re: [Standards] XEP-0071 v. 1.4pre1
None forbids their implementation, but do you think every client should implement them? Pavel On Wed, 6 Aug 2008 18:18:19 -0600 Joe Hildebrand [EMAIL PROTECTED] wrote: Implementation experience has shown that table and friends is strongly demanded by users, mostly because of copy/paste from Excel. I think we should consider their inclusion in the future, if we're going to open XEP-71 back up. On Aug 6, 2008, at 10:24 AM, Peter Saint-Andre wrote: In accordance with recent list discussion, I have provisionally modified XEP-0071 (XHTML-IM). Rendered text: http://www.xmpp.org/extensions/tmp/xep-0071-1.4.html Changelog: Encouraged support for several more structural elements from the text module (blockquote, cite, em, and strong); further clarified security considerations regarding fetching and presentation of images; modified several examples; clarified several points throughout the text. SVN diff: http://is.gd/1h2G /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] UPDATED: XEP-0231 (Bits of Binary)
Version 0.7 of XEP-0231 (Bits of Binary) has been released. Abstract: This specification defines an XMPP protocol extension for including or referring to small bits of binary data in an XML stanza. Changelog: Simplified the protocol; removed fetch element because the cid: URI uniquely identifies the data; changed the name of the protocol to something more catchy. (psa/ps) Diff: http://is.gd/1hwb URL: http://www.xmpp.org/extensions/xep-0231.html Nice. I was actually about to suggest exactly these changes based on the implementation I've made in libpurple. Now, the only change I need to make is not make it not include data by default. This also means I don't need to keep track of which data objects have been sent in a conversation. It will only need to cache binary data received in a conversation. This is using the messaging use-case for emoticons. Currently we don't implement an emoticon cache. This might get implemented later on. So currently received emoticons are only cached in memory during a conversation. Since my current implementation already supports fetching data, so this should simplify things. //Marcus
Re: [Standards] UPDATED: XEP-0231 (Bits of Binary)
XMPP Extensions Editor wrote: Version 0.7 of XEP-0231 (Bits of Binary) has been released. urn:xmpp:bob? :) I'm waiting for you to invent urn:xmpp:peter :) -- Maciek xmpp:[EMAIL PROTECTED]
[Standards] About the messaging use-case of XEP-0231
Hi. I saw that the use-cases of XEP-0231 has been removed along with the service discovery features. Is the intention that this particular use-case will become a part of XEP-0071? I found the service discovery feature for using in-band images to be useful. This way we can send an emoticon as its shortcut in the case when the receiver can't handle BoB, instead of including an img/ with a cid: URI. I also just realized that the alt attribute has been removed from the data/ tag. This makes perfect sense to me :) I just need to make some changes in my code... //Marcus
Re: [Standards] UPDATED: XEP-0231 (Bits of Binary)
Marcus Lundblad wrote: Version 0.7 of XEP-0231 (Bits of Binary) has been released. Abstract: This specification defines an XMPP protocol extension for including or referring to small bits of binary data in an XML stanza. Changelog: Simplified the protocol; removed fetch element because the cid: URI uniquely identifies the data; changed the name of the protocol to something more catchy. (psa/ps) Diff: http://is.gd/1hwb URL: http://www.xmpp.org/extensions/xep-0231.html Nice. I was actually about to suggest exactly these changes based on the implementation I've made in libpurple. Now, the only change I need to make is not make it not include data by default. This also means I don't need to keep track of which data objects have been sent in a conversation. It will only need to cache binary data received in a conversation. This is using the messaging use-case for emoticons. Currently we don't implement an emoticon cache. This might get implemented later on. So currently received emoticons are only cached in memory during a conversation. Since my current implementation already supports fetching data, so this should simplify things. Great, thanks for the feedback. Simpler is better. :) Pavel and I worked out these changes yesterday in the jdev room -- I'm sure you can find the logs at http://logs.jabber.org/ if you're really interested in our thought process... /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0071 v. 1.4pre1
Pavel Simerda wrote: On Wed, 6 Aug 2008 18:18:19 -0600 Joe Hildebrand [EMAIL PROTECTED] wrote: Implementation experience has shown that table and friends is strongly demanded by users, mostly because of copy/paste from Excel. I think we should consider their inclusion in the future, if we're going to open XEP-71 back up. None forbids their implementation, but do you think every client should implement them? In fact tables are currently forbidden, because the Table Module from XHTML Modularization is not part of the definition for XHTML-IM. Elements like em and strong are currently allowed (they're part of the Text Module) but not encouraged. IMHO adding a new module is a much bigger change than no longer discouraging particular elements or attributes from a module that's currently supported. I think we'd need a strong consensus to add a new module. Question: how do we expect an existing XHTML-IM implementation to behave if it receives content that include a table? Does it follow the ignore rule from XHTML? If so, I think the presentation would be sub-optimal. Or does it return an error? (In fact, error handling is not very well defined for XHTML-IM right now, hmm) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] UPDATED: XEP-0231 (Bits of Binary)
Maciek Niedzielski wrote: XMPP Extensions Editor wrote: Version 0.7 of XEP-0231 (Bits of Binary) has been released. urn:xmpp:bob? :) I'm waiting for you to invent urn:xmpp:peter :) Oh that would be too egotistical. But we could have urn:xmpp:psa for public service announcements. :) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] About the messaging use-case of XEP-0231
On Thu, 7 Aug 2008 14:29:32 +0200 (CEST) Marcus Lundblad [EMAIL PROTECTED] wrote: Hi. I saw that the use-cases of XEP-0231 has been removed along with the service discovery features. I believe we just lost the service discovery on the way. But it will be the same case as with XHTML-IM where the discovery is not mandatory. (E.g. you can't discover if you don't have a presence, it maybe stored offine and you don't know the client features yet.) I'm for putting the feature back if Peter agrees and for making the discovery optional. Is the intention that this particular use-case will become a part of XEP-0071? I found the service discovery feature for using in-band images to be useful. This way we can send an emoticon as its shortcut in the case when the receiver can't handle BoB, instead of including an img/ with a cid: URI. I also just realized that the alt attribute has been removed from the data/ tag. This makes perfect sense to me :) I just need to make some changes in my code... +1 //Marcus -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] About the messaging use-case of XEP-0231
Pavel Simerda wrote: On Thu, 7 Aug 2008 14:29:32 +0200 (CEST) Marcus Lundblad [EMAIL PROTECTED] wrote: Hi. I saw that the use-cases of XEP-0231 has been removed along with the service discovery features. I believe we just lost the service discovery on the way. But it will be the same case as with XHTML-IM where the discovery is not mandatory. (E.g. you can't discover if you don't have a presence, it maybe stored offine and you don't know the client features yet.) I'm for putting the feature back if Peter agrees and for making the discovery optional. I think the service discovery features are best defined in the specs that use BoB, such as XHTML-IM and file transfer, which is why I removed them from XEP-0231. Is the intention that this particular use-case will become a part of XEP-0071? I found the service discovery feature for using in-band images to be useful. This way we can send an emoticon as its shortcut in the case when the receiver can't handle BoB, instead of including an img/ with a cid: URI. I also just realized that the alt attribute has been removed from the data/ tag. This makes perfect sense to me :) I just need to make some changes in my code... +1 Yes, we figured out that we don't need 'alt' for data/ because the description will be handled by img/ (in XHTML-IM) or whatever other protocol uses BoB. /psa smime.p7s Description: S/MIME Cryptographic Signature
[Standards] UPDATED: XEP-0235 (OAuth Over XMPP)
Version 0.4 of XEP-0235 (OAuth Over XMPP) has been released. Abstract: This specification defines an XMPP extension for delegating access to protected resources over XMPP, using the OAuth protocol. In the language of OAuth, a User can authorize a Consumer to access a Protected Resource that is hosted by a Service Provider; this authorization is encapsulated in a token that the User requests from the Service Provider, that the User shares with the Consumer, and that the Consumer then presents to the Service Provider. This specification assumes that OAuth tokens will be acquired via HTTP as defined in the core OAuth specification, then presented over XMPP to a Service Provider. The Protected Resources accessible over XMPP might include groupchat rooms, data feeds hosted at publish-subscribe nodes, media relays, communication gateways, and other items of interest. Changelog: Incorporated consensus reached at XMPP Summit #5: specified that HTTP is used except for presentation of an Access Token, corrected signature generation algorithm, specified security considerations, and removed invitation and account registration use cases. (psa) Diff: http://is.gd/1ixT URL: http://www.xmpp.org/extensions/xep-0235.html
Re: [Standards] About the messaging use-case of XEP-0231
On Thu, 07 Aug 2008 10:15:16 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Thu, 7 Aug 2008 14:29:32 +0200 (CEST) Marcus Lundblad [EMAIL PROTECTED] wrote: Hi. I saw that the use-cases of XEP-0231 has been removed along with the service discovery features. I believe we just lost the service discovery on the way. But it will be the same case as with XHTML-IM where the discovery is not mandatory. (E.g. you can't discover if you don't have a presence, it maybe stored offine and you don't know the client features yet.) I'm for putting the feature back if Peter agrees and for making the discovery optional. I think the service discovery features are best defined in the specs that use BoB, such as XHTML-IM and file transfer, which is why I removed them from XEP-0231. Ok, I didn't notice this change was intentional. What about a short informational section when there's time for it? Is the intention that this particular use-case will become a part of XEP-0071? I found the service discovery feature for using in-band images to be useful. This way we can send an emoticon as its shortcut in the case when the receiver can't handle BoB, instead of including an img/ with a cid: URI. I also just realized that the alt attribute has been removed from the data/ tag. This makes perfect sense to me :) I just need to make some changes in my code... +1 Yes, we figured out that we don't need 'alt' for data/ because the description will be handled by img/ (in XHTML-IM) or whatever other protocol uses BoB. /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
[Standards] UPDATED: XEP-0235 (OAuth Over XMPP)
Version 0.5 of XEP-0235 (OAuth Over XMPP) has been released. Abstract: This specification defines an XMPP extension for delegating access to protected resources over XMPP, using the OAuth protocol. In the language of OAuth, a User can authorize a Consumer to access a Protected Resource that is hosted by a Service Provider; this authorization is encapsulated in a token that the User requests from the Service Provider, that the User shares with the Consumer, and that the Consumer then presents to the Service Provider in an access request. This specification assumes that OAuth tokens will be acquired via HTTP as defined in the core OAuth specification, then presented over XMPP to a Service Provider. The Protected Resources accessible over XMPP might include groupchat rooms, data feeds hosted at publish-subscribe nodes, media relays, communication gateways, and other items of interest. Changelog: More clearly specified access request format; corrected examples to incorporate nonce, timestamp, and version; modified request URL syntax to follow XML canonicalization order; changed HMAC-SHA1 from MUST to SHOULD. (psa) Diff: http://is.gd/1iLl URL: http://www.xmpp.org/extensions/xep-0235.html
Re: [Standards] About the messaging use-case of XEP-0231
Pavel Simerda wrote: On Thu, 07 Aug 2008 10:15:16 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Thu, 7 Aug 2008 14:29:32 +0200 (CEST) Marcus Lundblad [EMAIL PROTECTED] wrote: Hi. I saw that the use-cases of XEP-0231 has been removed along with the service discovery features. I believe we just lost the service discovery on the way. But it will be the same case as with XHTML-IM where the discovery is not mandatory. (E.g. you can't discover if you don't have a presence, it maybe stored offine and you don't know the client features yet.) I'm for putting the feature back if Peter agrees and for making the discovery optional. I think the service discovery features are best defined in the specs that use BoB, such as XHTML-IM and file transfer, which is why I removed them from XEP-0231. Ok, I didn't notice this change was intentional. What about a short informational section when there's time for it? Hmm. Do we really need those special service-discovery features? Perhaps all we need now is some text that says don't include [only] cid: URIs unless the recipient supports BoB. The reason we had the disco features is that we didn't want to spam people with in-band binary unless they said that was OK, but now we're pretty much forcing you to send the cid: URI and then the recipient can decide if they want to retrieve the binary. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] About the messaging use-case of XEP-0231
On Thu, 07 Aug 2008 14:52:23 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Thu, 07 Aug 2008 10:15:16 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Thu, 7 Aug 2008 14:29:32 +0200 (CEST) Marcus Lundblad [EMAIL PROTECTED] wrote: Hi. I saw that the use-cases of XEP-0231 has been removed along with the service discovery features. I believe we just lost the service discovery on the way. But it will be the same case as with XHTML-IM where the discovery is not mandatory. (E.g. you can't discover if you don't have a presence, it maybe stored offine and you don't know the client features yet.) I'm for putting the feature back if Peter agrees and for making the discovery optional. I think the service discovery features are best defined in the specs that use BoB, such as XHTML-IM and file transfer, which is why I removed them from XEP-0231. Ok, I didn't notice this change was intentional. What about a short informational section when there's time for it? Hmm. Do we really need those special service-discovery features? Perhaps all we need now is some text that says don't include [only] cid: URIs unless the recipient supports BoB. The reason we had the disco features is that we didn't want to spam people with in-band binary unless they said that was OK, but now we're pretty much forcing you to send the cid: URI and then the recipient can decide if they want to retrieve the binary. /psa That's what your original Service-Discovery section was about, no? As this is easier, I'm for allowing clients to handle URIs uniformly. And for announcing support for BoB in one Discovery Feature. This means you would just add back the Disco section :). Other suggestions from anyone? Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] About the messaging use-case of XEP-0231
Pavel Simerda [EMAIL PROTECTED] wrote: And for announcing support for BoB in one Discovery Feature. This means you would just add back the Disco section :). Other suggestions from anyone? I agree that this is easier as the client doesn't need to keep track of if the data has been requested from the remote client (or did I get it wrong? I understood it that way that a client should include a cid and shouldn't do that anymore if that cid isn't requested by the other client). So having it in disco / caps would make it easier. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] About the messaging use-case of XEP-0231
Pavel Simerda wrote: On Thu, 07 Aug 2008 14:52:23 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Thu, 07 Aug 2008 10:15:16 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Thu, 7 Aug 2008 14:29:32 +0200 (CEST) Marcus Lundblad [EMAIL PROTECTED] wrote: Hi. I saw that the use-cases of XEP-0231 has been removed along with the service discovery features. I believe we just lost the service discovery on the way. But it will be the same case as with XHTML-IM where the discovery is not mandatory. (E.g. you can't discover if you don't have a presence, it maybe stored offine and you don't know the client features yet.) I'm for putting the feature back if Peter agrees and for making the discovery optional. I think the service discovery features are best defined in the specs that use BoB, such as XHTML-IM and file transfer, which is why I removed them from XEP-0231. Ok, I didn't notice this change was intentional. What about a short informational section when there's time for it? Hmm. Do we really need those special service-discovery features? Perhaps all we need now is some text that says don't include [only] cid: URIs unless the recipient supports BoB. The reason we had the disco features is that we didn't want to spam people with in-band binary unless they said that was OK, but now we're pretty much forcing you to send the cid: URI and then the recipient can decide if they want to retrieve the binary. /psa That's what your original Service-Discovery section was about, no? As this is easier, I'm for allowing clients to handle URIs uniformly. And for announcing support for BoB in one Discovery Feature. This means you would just add back the Disco section :). Oh, duh, I didn't realize that I had removed the entire section. :) Fixed, will published the updated version in a few minutes. /psa smime.p7s Description: S/MIME Cryptographic Signature
[Standards] UPDATED: XEP-0231 (Bits of Binary)
Version 0.8 of XEP-0231 (Bits of Binary) has been released. Abstract: This specification defines an XMPP protocol extension for including or referring to small bits of binary data in an XML stanza. Changelog: Added section on determining support. (psa/ps) Diff: http://is.gd/1j1T URL: http://www.xmpp.org/extensions/xep-0231.html
[Standards] UPDATED: XEP-0235 (OAuth Over XMPP)
Version 0.6 of XEP-0235 (OAuth Over XMPP) has been released. Abstract: This specification defines an XMPP extension for delegating access to protected resources over XMPP, using the OAuth protocol. In the language of OAuth, a User can authorize a Consumer to access a Protected Resource that is hosted by a Service Provider; this authorization is encapsulated in a token that the User requests from the Service Provider, that the User shares with the Consumer, and that the Consumer then presents to the Service Provider in an access request. This specification assumes that OAuth tokens will be acquired via HTTP as defined in the core OAuth specification, then presented over XMPP to a Service Provider. The Protected Resources accessible over XMPP might include groupchat rooms, data feeds hosted at publish-subscribe nodes, media relays, communication gateways, and other items of interest. Changelog: Clarified error handling and service discovery. (psa) Diff: http://is.gd/1j8v URL: http://www.xmpp.org/extensions/xep-0235.html
