Re: [Standards] Chat States as Headlines
On Mar 16, 2011, at 11:54 , Mark Rejhon wrote: > On a related note, are there situations where messsages is type="chat" > but does NOT contain a ? I couldn't find a guideline relating > to this, as this is also relevant to my work-in-progress. > CSN (XEP-0082) is the most common case where we have a with no . Another is likely to be whatever encryption paradigm we standardize. RFC 3921bis briefly talks about what a "chat session" is, but does not mandate (or suggest, or preclude) every include a . - m&m smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Proposed XMPP Extension: Service Delegation
On Wednesday 16 March 2011 02:33:07 you wrote: > On 16 March 2011 02:48, Justin Karneges > > If we're not querying for lists, then disco#items is out. But, we can > > still inherit disco category and type. > > > > How about this: > > > > > id="d1"> > type="service" purpose="microblog"/> > > > > > > > id="d1"> > > > > > > > > +1 for all the feedback Dave gave. > > If we would use the above example you gave, how would the "delete" case > work? Even in the the current examples in the XEP (deleting entries with > the type attribute), I would not want to delete all my chess or microblog > delegations with one shot. Indeed. Basically, whether create, query, or delete, you'd need to specify all three of these parameters, and only 1 item would ever be created, returned, or deleted as a result. Now I am concerned about the disco identity fields being too specific. For example, couldn't a microblog be hosted on a "pep" service instead of a "service" service? Maybe we only want category and purpose for delegation, and drop type? It may not really matter though, as we could say that for microblogs you always delegate to "service" regardless of the actual disco#info of the JID being delegated to. Of course, a related question is whether the disco identities should match (i.e. any JID being delegated for a specific category+type combination also having that category+type in its disco#info). Justin
Re: [Standards] Chat States as Headlines
On a related note, are there situations where messsages is type="chat" but does NOT contain a ? I couldn't find a guideline relating to this, as this is also relevant to my work-in-progress. On 3/16/11, Kevin Smith wrote: > On Wed, Mar 16, 2011 at 5:09 PM, Kevin Smith wrote: >> At least, without giving it up thought, it seems to be. > > *much* thought > > /K > -- Sent from my mobile device
Re: [Standards] Chat States as Headlines
On Wed, Mar 16, 2011 at 5:09 PM, Kevin Smith wrote: > At least, without giving it up thought, it seems to be. *much* thought /K
Re: [Standards] FWD: XEP-0277 message
Hi, On 16 March 2011 17:24, Kim Alvefur wrote: > On Wed, 2011-03-16 at 15:39 +, Kevin Smith wrote: >> We had a strong need during its integration: the multiple/single >> file(s) attachment, like Identi.ca does in its protocol. We built a >> simple way (maybe not the best?!) to do this, with XML >> elements. > > Atom has this, which is also what StatusNet does: > > type='image/png' length='1057' > href='http://example.org/file.png'/> > > See http://tools.ietf.org/html/rfc4287#section-4.2.7 Yes, +1 Valérian? Is there a reason why not to use the standard atom link? Cheers, -- Tuomas
Re: [Standards] Chat States as Headlines
On Wed, Mar 16, 2011 at 4:51 PM, Matthew Wild wrote: > On 16 March 2011 14:23, Mark Rejhon wrote: >> I second it as well. The "don't store if there is no body" standard >> is recommended too, for my submitted/upcoming resubmit of Real Time >> Text too. It also involves message transmissions without a body >> element, sent before the completed message which contains a body >> element. >> > > I know it's easy to come up with many cases where no means no > storage. Unfortunately there are many applications where you really > *do* want to store a message without a . Many of these would be > from pubsub. It's fairly hard to come up with cases where no means no storage *and* it isn't a negotiated (usually) via caps protocol that can only very rarely end up in store anyway. At least, without giving it up thought, it seems to be. /K
[Standards] UPDATED: XEP-0237 (Roster Versioning)
Version 1.2 of XEP-0237 (Roster Versioning) has been released. Abstract: This specification defines a proposed modification to the XMPP roster protocol that enables versioning of rosters such that the server will not send the roster to the client if the roster has not been modified, thus saving bandwidth during session establishment. Changelog: Corrected stream features definition to note that it is always voluntary-to-negotiate. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0237/diff/1.1/vs/1.2 URL: http://xmpp.org/extensions/xep-0237.html
Re: [Standards] Chat States as Headlines
On 16 March 2011 14:23, Mark Rejhon wrote: > I second it as well. The "don't store if there is no body" standard > is recommended too, for my submitted/upcoming resubmit of Real Time > Text too. It also involves message transmissions without a body > element, sent before the completed message which contains a body > element. > I know it's easy to come up with many cases where no means no storage. Unfortunately there are many applications where you really *do* want to store a message without a . Many of these would be from pubsub. Maybe it's kind of a hack, but perhaps type="chat" should always have a if it ought to be stored. On the other hand type="normal" may be without a and ought to be stored always. It doesn't make sense for a pubsub service or non-interactive notification app to use type="chat" as far as I can see. Thoughts? Matthew
Re: [Standards] FWD: XEP-0277 message
On Wed, 2011-03-16 at 15:39 +, Kevin Smith wrote: > We had a strong need during its integration: the multiple/single > file(s) attachment, like Identi.ca does in its protocol. We built a > simple way (maybe not the best?!) to do this, with XML > elements. Atom has this, which is also what StatusNet does: See http://tools.ietf.org/html/rfc4287#section-4.2.7 -- Kim Alvefur signature.asc Description: This is a digitally signed message part
[Standards] FWD: XEP-0277 message
Forwarding this because his mail doesn't seem to be happy: --- BEGIN -- Hi, I am the Jappix project founder (https://www.jappix.com/ - https://project.jappix.com/ - https://mini.jappix.com), and we added full microblogging XEP (XEP-0277) support to our webclient (desktop edition). We had a strong need during its integration: the multiple/single file(s) attachment, like Identi.ca does in its protocol. We built a simple way (maybe not the best?!) to do this, with XML elements. Would it be possible to add this to the XEP draft, or to enhence this structure if bad? It looks like this: http://www.w3.org/2005/Atom";> Microblog (Vanaryon) 2011-03-13T15:52:45Z Vanaryon Espérons que le salon du jeu vidéo Breton sera meilleur l'année prochaine :( Espérons que le salon du jeu vidéo Breton sera meilleur l'année prochaine :( 2011-03-13T15:52:45Z 2011-03-13T15:52:45Z https://www.jappix.com/store/share/vanar...@jappix.com/76cc121cab14443c1d6ffe046443dfd1d856940b.jpg"; source="web" ext="jpg" type="image" thumb="https://www.jappix.com/store/share/vanar...@jappix.com/76cc121cab14443c1d6ffe046443dfd1d856940b_thumb.jpg"; /> https://www.jappix.com/store/share/vanar...@jappix.com/bdc11f42e0c1d810b33733689f6cfd7a9197c9e0.jpg"; source="web" ext="jpg" type="image" thumb="https://www.jappix.com/store/share/vanar...@jappix.com/bdc11f42e0c1d810b33733689f6cfd7a9197c9e0_thumb.jpg"; /> Here are the attributes in use: * name: the real file name * url: the file url (HTTP if source=web; ...) * source: the source of the file (web, ...) * ext: the file extension (I think it might be removed because of "type" attr) * type: the file type category (I think it might be changed to the MIME type to remove "ext" attr) * thumb: the link to a thumbnail of the image file, using the same MIME type as the "big" file (we may add video files thumbs support too, maybe using a sub-element with all the MIME type needed in a "type" attr) I am waiting for your replies and thoughts about it. I am aware that my first integration of this new feature in Jappix is not really "clean" and might be enhenced. Thanks, Valérian Saliou, Jappix founder.
Re: [Standards] Chat States as Headlines
I second it as well. The "don't store if there is no body" standard is recommended too, for my submitted/upcoming resubmit of Real Time Text too. It also involves message transmissions without a body element, sent before the completed message which contains a body element. On 3/16/11, Jonathan Schleifer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > Am 15.03.2011 um 21:53 schrieb Matthew A. Miller: > >> I know a couple of clients where switching the chatstates s to >> type='headline' will break their support; I'm sure there are others since >> XEP-0082 specifies the states SHOULD NOT be sent in types other than >> "chat" and "groupchat". And the problem will arise with other protocols, >> like RTT for example. > > Well, if most clients work, I think it would be ok to change the XEP. > >> From my experiences with customers, only s that contain a >> required storage; everything else either had other (better) >> mechanisms for retrieving the data (e.g. pubsub item retrieval), or >> storing the was worthless. YMMV. > > There is no standard saying "Don't store if there is no body" AFAIK and I'm > sure there might be legitimate reasons to store a message without a body. > > - -- > Jonathan > > -BEGIN PGP SIGNATURE- > > iQIcBAEBAwAGBQJNgJ1lAAoJEMtRg9d5cXHkWLsP/3v9G/S9ek3FTuBYmxe7Y4KF > +86RN8XzLGjZ3kR3WWmId631G31iejfxb/Wj9qbltYkR20I5RRnrSpk4XcD5AG8t > nHdod9p8wAOX8L8IXmNF3JfYtpoHxlHtE/t2InNv4oyl3z3kenn86N7oZpKrvkQ4 > bDKn0ivqD4Sxqi2LuRE7M1RQWk67dRi/6a0MdWkoC2zoSsmH9gJjI37g5dZjtwp7 > 27qa9HNZlM54Ra7Ur7FGdXF6oLBLGtUSDPa2vp0UaOqJW4XlPHf5MYQqHduHjGIY > YpxqAoAfW8fJeMzYObEfBZaeII+hTGqOFtAiZZmbwNQhw1WiMNCjorImp8ZSgv5V > rqdGYi+CzpQC0h/jx52j8npPSJhVK54MwQDYoZj1R63j/wYCdsruweNUd04VTzDs > KOAiMZFWEBDwcjxVFYWGRWehPxdHnLUrdkxY9cueLtLt1U2VPOt+or2s1Ia/sEuj > 2cf1UTEiabECk7Mw2+5f0vSWqBxCCm20ZPAsOsv1UIGSmYCi0WiWBA/EJzHouwB3 > J3R1jq0im+G21ll+yJYxNh89XoIU31HusllQeVB3ND2EsfdDY4qRZhq3tMKvPP4J > Ta/w+O8P/HoXyKwSQtfHBocHS9D9CfZWVKOz2CmQEd+Qiedt7QZSN55MQvqlJYqZ > 2vDmQWllPiOmqC2mJBMS > =Qo9b > -END PGP SIGNATURE- > -- Sent from my mobile device
Re: [Standards] Chat States as Headlines
On Tue, Mar 15, 2011 at 12:36 PM, Jonathan Schleifer wrote: > Just having looked at my offline storage, I saw that chat states are stored > by the server. But of course they are, as the type is chat and thus the > server has to store them. > > Thinking about it, wouldn't it make sense to set the type to headline? > Are there any reasons why we couldn't just test how many clients still work > correctly if you just change the type to headline and if most of the clients > still accept it change the XEP? I note that having many offline messages suggests a client bug somewhere - clients should only be sending CSN when they know the other full-JID side supports it, so CSN in offline store should only happen if the CSN and the presence-unavailable cross each other on the wire. In any case, I don't think this is an appropriate change to a Final XEP. > And while we're at it, wouldn't the same make sense for PEP? I believe PEP already suggests this. /K
Re: [Standards] Chat States as Headlines
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Am 15.03.2011 um 21:53 schrieb Matthew A. Miller: > I know a couple of clients where switching the chatstates s to > type='headline' will break their support; I'm sure there are others since > XEP-0082 specifies the states SHOULD NOT be sent in types other than "chat" > and "groupchat". And the problem will arise with other protocols, like RTT > for example. Well, if most clients work, I think it would be ok to change the XEP. > From my experiences with customers, only s that contain a > required storage; everything else either had other (better) mechanisms for > retrieving the data (e.g. pubsub item retrieval), or storing the > was worthless. YMMV. There is no standard saying "Don't store if there is no body" AFAIK and I'm sure there might be legitimate reasons to store a message without a body. - -- Jonathan -BEGIN PGP SIGNATURE- iQIcBAEBAwAGBQJNgJ1lAAoJEMtRg9d5cXHkWLsP/3v9G/S9ek3FTuBYmxe7Y4KF +86RN8XzLGjZ3kR3WWmId631G31iejfxb/Wj9qbltYkR20I5RRnrSpk4XcD5AG8t nHdod9p8wAOX8L8IXmNF3JfYtpoHxlHtE/t2InNv4oyl3z3kenn86N7oZpKrvkQ4 bDKn0ivqD4Sxqi2LuRE7M1RQWk67dRi/6a0MdWkoC2zoSsmH9gJjI37g5dZjtwp7 27qa9HNZlM54Ra7Ur7FGdXF6oLBLGtUSDPa2vp0UaOqJW4XlPHf5MYQqHduHjGIY YpxqAoAfW8fJeMzYObEfBZaeII+hTGqOFtAiZZmbwNQhw1WiMNCjorImp8ZSgv5V rqdGYi+CzpQC0h/jx52j8npPSJhVK54MwQDYoZj1R63j/wYCdsruweNUd04VTzDs KOAiMZFWEBDwcjxVFYWGRWehPxdHnLUrdkxY9cueLtLt1U2VPOt+or2s1Ia/sEuj 2cf1UTEiabECk7Mw2+5f0vSWqBxCCm20ZPAsOsv1UIGSmYCi0WiWBA/EJzHouwB3 J3R1jq0im+G21ll+yJYxNh89XoIU31HusllQeVB3ND2EsfdDY4qRZhq3tMKvPP4J Ta/w+O8P/HoXyKwSQtfHBocHS9D9CfZWVKOz2CmQEd+Qiedt7QZSN55MQvqlJYqZ 2vDmQWllPiOmqC2mJBMS =Qo9b -END PGP SIGNATURE-
Re: [Standards] Proposed XMPP Extension: Service Delegation
Hi Justin, first of all, great work. I find it a very good idea. On 16 March 2011 02:48, Justin Karneges wrote: > On Monday 10 January 2011 04:08:23 Dave Cridland wrote: >> 1) A minor niggle - I hate using "query" as the element. Feels >> very old-fashioned. :-) > > And what would you pick? :) > >> 2) Delegations may need to include a node. > > Good idea. > >> 3) The "type" attribute used feels highly underspecified. I suspect >> something with a couple of levels of heirarchy, similar to (and >> possibly the same as) the disco category and type. >> Equally, it needs a registry defined, and a human-readable string >> wouldn't hurt, so maybe the best option would be to simply use the >> same element and have done with it. >> >> 4) Conceptually, this feels similar to disco#items anyway. We can't >> use disco#items directly, though, because we can't include the >> purpose in the items listing, which is unfortunate - I do wonder if >> we could include a child element of there to include that >> information, though. It could prove useful in other cases: >> >> >> > xmlns:x='urn:xmpp:tmp:delegation'> >> >> >> >> >> >> >> >> Or even: >> >> >> > xmlns:x='urn:xmpp:tmp:delegation'> >> >> > purpose='continue'/> >> >> >> >> >> >> Note I'm not using in this suggestion because - of course >> - it won't fit. I assume the existence of a purpose registry, to >> indicate some kind of purpose of the entity from the perspective of >> the queried entity. > > Yes, I think having a purpose or context is important, as I wrote in my other > mail. > > I am partial to David Ammouial's suggestion of using redirects as opposed to > querying for a list. We'd need a way to include purpose in the request > though, so we can't literally send a normal stanza to trigger this. Rather, > we'd perform a special query for the type+purpose and get a response jid+node > (and probably we should use a success response to deliver that, rather than > use ). > > If we're not querying for lists, then disco#items is out. But, we can still > inherit disco category and type. > > How about this: > > > purpose="microblog"/> > > > > > > > +1 for all the feedback Dave gave. If we would use the above example you gave, how would the "delete" case work? Even in the the current examples in the XEP (deleting entries with the type attribute), I would not want to delete all my chess or microblog delegations with one shot. Cheers, -- tuomas
