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
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
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 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 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 > >> with a cid: URI. > > > >> I also just realized that the "alt" attribute has been removed from > >> the 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 because the > description will be handled by (in XHTML-IM) or whatever other > protocol uses BoB. > > /psa > -- 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 with a cid: URI. I also just realized that the "alt" attribute has been removed from the 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 because the description will be handled by (in XHTML-IM) or whatever other protocol uses BoB. /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 > with a cid: URI. > I also just realized that the "alt" attribute has been removed from > the 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
[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 with a cid: URI. I also just realized that the "alt" attribute has been removed from the tag. This makes perfect sense to me :) I just need to make some changes in my code... //Marcus
