Re: [Standards] shared editing requirements
On 8/17/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Here is my first attempt at summarizing the requirements for shared XML > editing applications such as whiteboarding. The use of must and should > is approximate. Not all of these requirements need to be addressed by a > single specification. The requirements are not necessarily grouped by > category. Further refinement will be necessary. This is a first pass. > > OK, here goes... > > 1. The underlying protocol is designed for synchronization of XML > instances between entities that communicate via XMPP. > > 2. By "synchronization" is mean that all parties to a shared XML editing > session must have the same representation of the XML object after all > synchronization messages have been processed. > > 3. Ideally, it should be possible to use the protocol for multiple > application types, e.g. SVG whiteboarding, XHTML document editing, > collaborative data objects (XEP-0204). > > 4. There is no requirement to synchronize non-XML data. > > 5. It must be possible to synchronize XML object instances either > between two entities or among more than two entities. > > 6. The protocol should not (unduly) limit the number of parties to a > shared XML editing session. > > 7. It must be possible to use the protocol "directly" between two > entities without assistance from intermediaries, either via an XMPP > server (RFC 3920) or in serverless mode (XEP-0174). > > 8. It must be possible to use the protocol through a multi-user chat > (XEP-0045) room. > > 9. It should be possible to use the protocol with a specialized > synchronization component attached to an XMPP server. > > 10. Where possible, all edits should be commutative in order to minimize > the need for locking of the XML object. > > 11. The protocol should be as lightweight as possible in order to > minimize bandwidth consumption. > > 12. It must be possible to add new "nodes" (elements and attributes) to > the XML object. > > 13. It must be possible to edit existing nodes. > > 14. It must be possible to remove existing nodes. > > 15. It should be possible to move a node from one location to another > within the XML object. > > 16. It should be possible to re-use the XML object outside of a shared > editing session (e.g., for offline editing in a different application, > or for archiving). > > 17. It should be possible to specify the version of the protocol. > > 18. It should be possible to refer to outside resources (e.g., images > hosted at websites) from within the protocol. > > 19. It should be possible to retrieve the current state of the XML > object from a party to the shared editing session. > > 20. It should be possible to retrieve the history of edits to the XML > object from a party to the shared editing session. > > 21. It must be possible to discover whether another entity can engage in > a shared XML editing session. > > 22. It must be possible to discover which application types another > entity can handle. > > 23. It must be possible to initiate, update, join, and terminate a > shared XML editing session. > > 24. It must be possible to specify the roles of parties to a shared XML > editing session. > > 25. It must be possible to uniquely identify each node in an XML object, > both within the scope of a standalone shared XML editing session and if > the edited object is shared with other appliclations or embedded in > other objects. > > 26. It should be possible to validate synchronization messages against a > defined schema for the application type in real time. > > 27. It must be possible to reject out-of-order synchronization messages. > > 28. It must be possible to specify the parent of any given node. > > 29. It should be possible to query an entity for the shared XML editing > sessions to which it is a party. > > 30. It should be possible to query an entity for the XML objects it owns > or knows about (which may be the result of a past editing session). > > 31. It should be possible to send the complete content of a node or only > the difference between the last version of the node and the current version. > > 32. It should be possible to declare shared editing of the XML object to > be complete (e.g., in preparation for archiving of the XML object or > editing by another application). > > 33. It should be possible to declare shared editing of part of the XML > object to be complete. > > 34. It should be possible to associate an XML object with other XML objects. > > 35. It should be possible to specify that all parties shall move their > viewing context to a particular location in the XML data object. > > 36. It must be possible to represent human-readable text in a language > and character set appropriate for a human user. > > 37. Certain applications may need to handle particular features of the > XML syntax for that application type (e.g., layers in SVG or pages in > XHTML); the protocol must not forbid such specialized semantics. > > 38. It should be possible to associate re
[Standards] shared editing requirements
Here is my first attempt at summarizing the requirements for shared XML editing applications such as whiteboarding. The use of must and should is approximate. Not all of these requirements need to be addressed by a single specification. The requirements are not necessarily grouped by category. Further refinement will be necessary. This is a first pass. OK, here goes... 1. The underlying protocol is designed for synchronization of XML instances between entities that communicate via XMPP. 2. By "synchronization" is mean that all parties to a shared XML editing session must have the same representation of the XML object after all synchronization messages have been processed. 3. Ideally, it should be possible to use the protocol for multiple application types, e.g. SVG whiteboarding, XHTML document editing, collaborative data objects (XEP-0204). 4. There is no requirement to synchronize non-XML data. 5. It must be possible to synchronize XML object instances either between two entities or among more than two entities. 6. The protocol should not (unduly) limit the number of parties to a shared XML editing session. 7. It must be possible to use the protocol "directly" between two entities without assistance from intermediaries, either via an XMPP server (RFC 3920) or in serverless mode (XEP-0174). 8. It must be possible to use the protocol through a multi-user chat (XEP-0045) room. 9. It should be possible to use the protocol with a specialized synchronization component attached to an XMPP server. 10. Where possible, all edits should be commutative in order to minimize the need for locking of the XML object. 11. The protocol should be as lightweight as possible in order to minimize bandwidth consumption. 12. It must be possible to add new "nodes" (elements and attributes) to the XML object. 13. It must be possible to edit existing nodes. 14. It must be possible to remove existing nodes. 15. It should be possible to move a node from one location to another within the XML object. 16. It should be possible to re-use the XML object outside of a shared editing session (e.g., for offline editing in a different application, or for archiving). 17. It should be possible to specify the version of the protocol. 18. It should be possible to refer to outside resources (e.g., images hosted at websites) from within the protocol. 19. It should be possible to retrieve the current state of the XML object from a party to the shared editing session. 20. It should be possible to retrieve the history of edits to the XML object from a party to the shared editing session. 21. It must be possible to discover whether another entity can engage in a shared XML editing session. 22. It must be possible to discover which application types another entity can handle. 23. It must be possible to initiate, update, join, and terminate a shared XML editing session. 24. It must be possible to specify the roles of parties to a shared XML editing session. 25. It must be possible to uniquely identify each node in an XML object, both within the scope of a standalone shared XML editing session and if the edited object is shared with other appliclations or embedded in other objects. 26. It should be possible to validate synchronization messages against a defined schema for the application type in real time. 27. It must be possible to reject out-of-order synchronization messages. 28. It must be possible to specify the parent of any given node. 29. It should be possible to query an entity for the shared XML editing sessions to which it is a party. 30. It should be possible to query an entity for the XML objects it owns or knows about (which may be the result of a past editing session). 31. It should be possible to send the complete content of a node or only the difference between the last version of the node and the current version. 32. It should be possible to declare shared editing of the XML object to be complete (e.g., in preparation for archiving of the XML object or editing by another application). 33. It should be possible to declare shared editing of part of the XML object to be complete. 34. It should be possible to associate an XML object with other XML objects. 35. It should be possible to specify that all parties shall move their viewing context to a particular location in the XML data object. 36. It must be possible to represent human-readable text in a language and character set appropriate for a human user. 37. Certain applications may need to handle particular features of the XML syntax for that application type (e.g., layers in SVG or pages in XHTML); the protocol must not forbid such specialized semantics. 38. It should be possible to associate relevant metadata with each node in the XML object, which might include time of creation, identity of the creator, time of last modification, and identity of last modifier. 39. It should be possible to log all synchronization messages and associated metadata fo
Re: [Standards] whiteboarding and shared editing
Bishop, Michael W. CONTR J9C880 wrote: >> Requirements, requirements, requirements. Again, it would help for >> someone to write a clear and comprehensive requirements doc. OK I have re-read the three whiteboarding-related proposals: http://www.xmpp.org/extensions/inbox/sxde.html http://www.xmpp.org/extensions/inbox/whiteboard.html http://www.xmpp.org/extensions/inbox/whiteboard2.html As well as Mats's sync memo: http://coccinella.im/memo/sync And the collaborative data objects spec contributed by MITRE: http://www.xmpp.org/extensions/xep-0204.html I have also re-read some email messages sent both on-list and off-list (e.g., some discussion that Ian Paterson, Joonas Govenius, and I had in January about synchronization requirements). So I hope that I can add helpfully to the requirements discussion. :) I will send out another message in a new thread with a summary of the requirements as I see them based on my reading. >> It would also help for you to summarize the ways in which > whiteboarding >> is more than modifying an XML document. That would help us find common >> ground and achieve consensus. > > While I don't have a requirements doc, I can share the problems we tried > to solve with our whiteboarding approach we recently submitted: > > - The editing of shared XML documents. As others have mentioned, this seems to be the basic synchronization problem. > - Logical ordering of said shared documents. I'm not sure what exactly you mean by that. Do you mean that documents need to be edited or presented in a specific order? Examples might be to enable a workflow of collaborative data objects (XEP-0204) or a series of XHTML documents in a presentation (think S5). To me this seems like something that we'd build on top of the shared editing protocol in order to bundle documents together. > - Presentation. (Page changes and a future revision to support cursor > position.) I can see that communication of cursor position might be helpful in certain contexts, but I think that this would be optional. It's kind of like Chat State Notifications (XEP-0085) for shared editing, in a way, since it provides information about the state of the participants, not state about the data being exchanged in the stanza session itself (where I use the term "stanza session" as an abstraction from chat session in XMPP messaging, whiteboard, shared document, etc.). > - Roles. (Who can edit? Who can only observe?) I agree that this may be needed in larger groups, but it is probably not needed in 1-to-1 mode or in small/informal MUC rooms. > - Current state. A user can join and get the current state. Yes, this is common across several of the approaches. > - History. A user who got disconnected can rejoin and ask for the last > X actions to occur. This may be a subset of getting the current state. >> If someone takes time and look into http://coccinella.im/memo/sync > they will see that it is completely >> generic and general. There is nothing specific to whiteboarding and it > could be used in any context where >> the basic assumptions are valid. > > While reading some of the discussions on this topic in the list, I > realized that our protocol shares some of the same characteristics. > While it was designed specifically for whiteboarding using SVG as a > medium, the protocol itself does not deal with SVG. The manipulation of > the SVG document can be applied to any XML in any namespace. While it's > been written as a whiteboard protocol, nothing forces it to be one. It > would work as-is as a shared XML document protocol with permissions, > history, current state, and presentation. Very interesting. We seem then to be converging on consensus about what should be possible here. That is, it should be possible to develop an approach to shared XML editing that enables us to edit different XML formats, such as SVG, XHTML, and collaborative data objects (XEP-0204). > Peter wrote: >> Greg Hudson wrote: 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... >> I don't think anyone is arguing for a general *application* that would > >> do shared XML editing that would do whiteboarding, spreadsheets, word >> processing, presentations, and everything else under the sun. But it >> seems wasteful for us to define separat
Re: [Standards] whiteboarding and shared editing
Joonas Govenius wrote: > On 8/16/07, Bishop, Michael W. CONTR J9C880 <[EMAIL PROTECTED]> wrote: >>> Right. Probably the biggest difference between the two proposed >> approaches is the reliance on server-side >>> support. >>> http://www.xmpp.org/extensions/inbox/whiteboard2.html requires >> server-side support while sxde tries to >>> allow sessions 1-to-1 and in MUC rooms and includes the possibility of >> specific server-side support merely >>> as an optional enchancement to lessen some of the requirements on the >> clients. >> >> Just to clarify, server-side support is needed for MUC rooms only; not >> for 1-to-1 sessions. > > Oh. Do you have any documentation or description of how the documents > are kept identical in 1-to-1 sessions without the server as an > arbitrator? Yes, that would be helpful. As far as I can see, we would like the standardized protocol to support 1-to-1 mode without any intermediary. For example, this would be useful when running a whiteboarding session over a link-local connection (XEP-0174), or in situations where a MUC service or dedicated whiteboarding component is not available or not trusted to relay the relevant stanzas. Thanks! Peter smime.p7s Description: S/MIME Cryptographic Signature
[Standards] UPDATED: XEP-0136 (Message Archiving)
Version 0.14 of XEP-0136 (Message Archiving) has been released. Abstract: This document defines mechanisms and preferences for the archiving and retrieval of XMPP messages. Changelog: Clarified text regarding preference syntax; completed copy edit. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0136.xml?r1=316&r2=1164 URL: http://www.xmpp.org/extensions/xep-0136.html
Re: [Standards] whiteboarding and shared editing
On 8/16/07, Bishop, Michael W. CONTR J9C880 <[EMAIL PROTECTED]> wrote: > > Right. Probably the biggest difference between the two proposed > approaches is the reliance on server-side > > support. > > http://www.xmpp.org/extensions/inbox/whiteboard2.html requires > server-side support while sxde tries to > > allow sessions 1-to-1 and in MUC rooms and includes the possibility of > specific server-side support merely > > as an optional enchancement to lessen some of the requirements on the > clients. > > Just to clarify, server-side support is needed for MUC rooms only; not > for 1-to-1 sessions. Oh. Do you have any documentation or description of how the documents are kept identical in 1-to-1 sessions without the server as an arbitrator?
Re: [Standards] whiteboarding and shared editing
> Right. Probably the biggest difference between the two proposed approaches is the reliance on server-side > support. > http://www.xmpp.org/extensions/inbox/whiteboard2.html requires server-side support while sxde tries to > allow sessions 1-to-1 and in MUC rooms and includes the possibility of specific server-side support merely > as an optional enchancement to lessen some of the requirements on the clients. Just to clarify, server-side support is needed for MUC rooms only; not for 1-to-1 sessions. Michael Bishop -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joonas Govenius Sent: Thursday, August 16, 2007 1:45 PM To: XMPP Extension Discussion List Subject: Re: [Standards] whiteboarding and shared editing On 8/16/07, Bishop, Michael W. CONTR J9C880 <[EMAIL PROTECTED]> wrote: > While reading some of the discussions on this topic in the list, I > realized that our protocol shares some of the same characteristics. > While it was designed specifically for whiteboarding using SVG as a > medium, the protocol itself does not deal with SVG. The manipulation > of the SVG document can be applied to any XML in any namespace. While > it's been written as a whiteboard protocol, nothing forces it to be > one. It would work as-is as a shared XML document protocol with > permissions, history, current state, and presentation. Right. Probably the biggest difference between the two proposed approaches is the reliance on server-side support. http://www.xmpp.org/extensions/inbox/whiteboard2.html requires server-side support while sxde tries to allow sessions 1-to-1 and in MUC rooms and includes the possibility of specific server-side support merely as an optional enchancement to lessen some of the requirements on the clients.
Re: [Standards] whiteboarding and shared editing
On 8/16/07, Bishop, Michael W. CONTR J9C880 <[EMAIL PROTECTED]> wrote: > While reading some of the discussions on this topic in the list, I > realized that our protocol shares some of the same characteristics. > While it was designed specifically for whiteboarding using SVG as a > medium, the protocol itself does not deal with SVG. The manipulation of > the SVG document can be applied to any XML in any namespace. While it's > been written as a whiteboard protocol, nothing forces it to be one. It > would work as-is as a shared XML document protocol with permissions, > history, current state, and presentation. Right. Probably the biggest difference between the two proposed approaches is the reliance on server-side support. http://www.xmpp.org/extensions/inbox/whiteboard2.html requires server-side support while sxde tries to allow sessions 1-to-1 and in MUC rooms and includes the possibility of specific server-side support merely as an optional enchancement to lessen some of the requirements on the clients.
Re: [Standards] whiteboarding and shared editing
> Requirements, requirements, requirements. Again, it would help for > someone to write a clear and comprehensive requirements doc. > It would also help for you to summarize the ways in which whiteboarding > is more than modifying an XML document. That would help us find common > ground and achieve consensus. While I don't have a requirements doc, I can share the problems we tried to solve with our whiteboarding approach we recently submitted: - The editing of shared XML documents. - Logical ordering of said shared documents. - Presentation. (Page changes and a future revision to support cursor position.) - Roles. (Who can edit? Who can only observe?) - Current state. A user can join and get the current state. - History. A user who got disconnected can rejoin and ask for the last X actions to occur. > If someone takes time and look into http://coccinella.im/memo/sync they will see that it is completely > generic and general. There is nothing specific to whiteboarding and it could be used in any context where > the basic assumptions are valid. While reading some of the discussions on this topic in the list, I realized that our protocol shares some of the same characteristics. While it was designed specifically for whiteboarding using SVG as a medium, the protocol itself does not deal with SVG. The manipulation of the SVG document can be applied to any XML in any namespace. While it's been written as a whiteboard protocol, nothing forces it to be one. It would work as-is as a shared XML document protocol with permissions, history, current state, and presentation. Michael Bishop -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mats Bengtsson Sent: Thursday, August 16, 2007 2:54 AM To: standards@xmpp.org Subject: Re: [Standards] whiteboarding and shared editing Peter wrote: > Greg Hudson wrote: >> > 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... > > I don't think anyone is arguing for a general *application* that would > do shared XML editing that would do whiteboarding, spreadsheets, word > processing, presentations, and everything else under the sun. But it > seems wasteful for us to define separate XML editing/syncronization > protocols for each application type, unless there really are special > considerations that make it is impossible to use the same underlying > technology for each. Which is what we're talking about taking some > time to explore... > If someone takes time and look into http://coccinella.im/memo/sync they will see that it is completely generic and general. There is nothing specific to whiteboarding and it could be used in any context where the basic assumptions are valid. However, the basic assumptions imply that we haven't dealt with editing parts of CHDATA or parts of attributes, but elements are treated as entities. Mats
Re: [Standards] Removing PEP nodes?
Peter Saint-Andre wrote: > Ralph Meijer wrote: >> On Thu, 2007-08-16 at 13:09 +0200, Magnus Henoch wrote: >>> Peter Saint-Andre <[EMAIL PROTECTED]> writes: >>> Andreas Monitzer wrote: > On Jun 15, 2007, at 20:07, Peter Saint-Andre wrote: > >> Andreas Monitzer wrote: >>> Hi, >>> I'm currently implementing PEP into libpurple, and have some issue >>> I can't quite find explained in the XEPs: How do I remove a >>> personal event? >> I think you would use the syntax defined in XEP-0060: >> >> http://www.xmpp.org/extensions/xep-0060.html#publisher-delete > What should I supply as the item id? I don't have that value. Why not? You should have received it when the PEP service sent it to you (the account owner automatically receives a copy). >>> The only reference to this that I can find is section 12.9 of >>> XEP-0060, Auto-Subscribing Owners and Publishers, which says that the >>> service MAY do so. Did I miss some other place? Is there anything >>> PEP-specific that specifies this behaviour? >> In both the current 1.0 (section 8) as well as the upcoming 1.1 version >> of XEP-0163 [1], there is the mention of notifications to resources of >> the node owner. The latter mentions that this is subject to filtered >> notifications (section 10.2 of the upcoming 1.10 version of XEP-0060 >> [2]). It seems to me that what was meant is that your own account is >> assumed to be in the group of entities that will receive notifications >> when a resource sends the proper entity capabilities with +notify >> suffixes. > > Right. I'll check the working copies of XEP-0060 and XEP-0163 to make > sure that this is clearer. The text should say that the service MUST > send a notification to the account owner (subject to caps-based > filtering etc.). I've clarified that text here: http://www.xmpp.org/extensions/tmp/xep-0060-1.10.html#auto-subscribe http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0060.xml?r1=1152&r2=1162 Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Experimental XEPs
Dave Cridland wrote: > On Wed Aug 15 22:57:23 2007, Peter Saint-Andre wrote: >> Based on my experience in the IETF since 2002, I am not familiar with a >> formal process for doing draft proposals there. You just publish an >> Internet-Draft, others may propose similar or competing I-Ds, and you >> hash it out on mailing lists and at in-person meetings. Hmm, that sounds >> awfully familiar... >> >> > There is a formal process, it's just very lightweight. > > In order to publish an ID, you need to have the formatting correct and > have the IPR boilerplate correct (and current). You also need to name > your draft correctly, and a handful of other minor things. That's essentially the approach we had for the first 2+ years of our existence. > In return, the IETF Secretariat then publish it for you for six months. > In practice, it's longer than that, since the Tools Team publish the lot > in perpetuity. > > This is all very similar to the Inbox we have, although there's a > general expectation that a document still undergoing serious work will > remain an ID - it's only published as an RFC much later in the process, > when it's generally believed to be finished. This is in part a > reflection of the original paper-based publication method - once > something's published, you can't change it if it's been sent out in the > post. (Anyone wondering why they used to be paper needs to figure out > what the IETF developed). > > For our purposes, simply lessening the expectation that anything hitting > the Inbox should immediately be published or killed would be sufficient. Or simply publish-at-will, but lessen the expection that publication as a XEP means much of anything. It's advancement to Draft that has meaning (roughly equivalent to advancement of an I-D to RFC). > I would personally recommend revisiting XEP-1's section 5. In > particular, I'd suggest that the publication of something in the Inbox > and the request to the Council should be distinct actions, and the > latter should be handled by the document author, not the XMPP Extensions > Editor. (Although they're often the same person...) > > I suspect that this would reduce the number of published XEPs, leaving - > hopefully - only those that we want to keep, and only that subset of > them that are reasonably stable and complete. Or give Draft and Final XEPs special prominence, and Experimental XEPs less prominence. We used to do this via http://www.jabber.org/protocol/ (showing only approved specs). > As for developing WG-like entities again, we could certainly look at > that. There are advantages to this kind of behaviour - we limit the > traffic on mailing lists somewhat - but it can also lead to > fragmentation. In the past it has led to fragmentation and fewer eyes reviewing specs. > It might be better to encourage initial design work to > happen on alternate lists, but to move back onto the primary list for > finalization, to gain a wider audience (in particular before it becomes > a XEP). I think it needs thought. (Which could come from a SIG, of course). We've tried that too, but it hasn't worked so well either. Maybe we need to have more groupchat meetings in the design phase (wow, what a concept, use our own technologies!) and then move things more to the list once we've finished that brainstorming/design phase. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Experimental XEPs
Dave Cridland wrote: > On Wed Aug 15 21:01:07 2007, Peter Saint-Andre wrote: >> The XSF is a standards development organization. We're supposed to be >> developing standards. If people want to publish the results of their >> experiments on their own websites as input to the XSF's standards >> development process, they are free to do so. But as far as I can see, >> nothing in the XSF's mission or bylaws dictates that such experiments >> deserve to be published by the XSF. > > Actually I disagree. Not publishing (in some way, it doesn't have to be > as a XEP) experiments and early-stage working documents, and in > particular encouraging these to be privately published, does not > encourage the kind of commonly-owned specification that can be developed > into (or used as input for) a proper standard. > > I suspect - without much justification, I'll admit - that the result of > encouraging specifications to be worked on outside the XSF would lead to > fragmentation and proprietary extensions (by which I mean the term in > the sense of not held under common ownership). Yes, that result is to be avoided. > A good SDO, therefore, not only encourages open participation (as we and > the IETF do), but also encourages open publication of proposals (as the > IETF does with it's I-D documents, which represent a low barrier to > entry, centralized, publication mechanism). We tend toward promoting a > "do or die" approach to publishing XEPs, which leads to the bulk of a > specification being developed outside the XSF, potentially encouraging > multiple non-interoperable approaches to the same goal. Well, it's odd. I used to be very liberal about publishing JEPs (before they were XEPs). This was back when the JEP Editor (me) decided which specs would get published, and the only hurdle was that the spec was properly formatted. Look at lots of the early specs and you'll see that many of them were little experiments that people did. Then folks wanted to control the process more and we instituted the Council as a gating function. If it were still up to me I'd argue for the liberal approach. > This has demonstrably happened with the whiteboarding proposals, and > it's obviously not in our interests - whether that's as a result of the > XSF's processes is most certainly a matter for debate, but I feel the > XSF's processes might be adjusted to try to reduce this. Yes, I prefererd the old way. But then I'm pretty much of an anarchist anyway. ;-) > I believe the best mechanism for encouraging interoperable protocols > through the XSF is to support their publication, even when the proposal > has flaws that the Council require to be rectified. Hence my comments in > another message about adjusting our processes to allow for a long-term > use of the Inbox without forcing publication as a XEP. Or just publish-at-will and take greater care about reviewing specs. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Jingle: UDP relays
Unnikrishnan V wrote: > what about thoughts for using : > http://www.xmpp.org/extensions/xep-0128.html XEP-0030 (augmented by XEP-0128) is for discovery of entities that can communicate over an XMPP network. But many (most?) of the entities you are talking about are not on the XMPP network (e.g., STUN, TURN, and RSIP servers). Basically what you want is that your XMPP server will be a "discovery proxy" to the wider world of services that do not communicate via XMPP. So your XMPP server would do all the hard work of discovering what services are offered in the world (via DNS SRV, DDDS, NAPTR, etc.), and you could query your XMPP server about those non-XMPP services. This could be done by querying a special node at your XMPP server, where you would find a tree of non-XMPP services. Your XMPP server could include XEP-0128 extensions in the data it returns for those services. That seems like a reasonable approach. But as I said I'm still researching SRV/DDDS/NAPTR etc. to see what kind of information might be returned. I'll report more about that soon. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Removing PEP nodes?
Ralph Meijer wrote: > On Thu, 2007-08-16 at 13:09 +0200, Magnus Henoch wrote: >> Peter Saint-Andre <[EMAIL PROTECTED]> writes: >> >>> Andreas Monitzer wrote: On Jun 15, 2007, at 20:07, Peter Saint-Andre wrote: > Andreas Monitzer wrote: >> Hi, >> I'm currently implementing PEP into libpurple, and have some issue >> I can't quite find explained in the XEPs: How do I remove a >> personal event? > I think you would use the syntax defined in XEP-0060: > > http://www.xmpp.org/extensions/xep-0060.html#publisher-delete What should I supply as the item id? I don't have that value. >>> Why not? You should have received it when the PEP service sent it to >>> you (the account owner automatically receives a copy). >> The only reference to this that I can find is section 12.9 of >> XEP-0060, Auto-Subscribing Owners and Publishers, which says that the >> service MAY do so. Did I miss some other place? Is there anything >> PEP-specific that specifies this behaviour? > > In both the current 1.0 (section 8) as well as the upcoming 1.1 version > of XEP-0163 [1], there is the mention of notifications to resources of > the node owner. The latter mentions that this is subject to filtered > notifications (section 10.2 of the upcoming 1.10 version of XEP-0060 > [2]). It seems to me that what was meant is that your own account is > assumed to be in the group of entities that will receive notifications > when a resource sends the proper entity capabilities with +notify > suffixes. Right. I'll check the working copies of XEP-0060 and XEP-0163 to make sure that this is clearer. The text should say that the service MUST send a notification to the account owner (subject to caps-based filtering etc.). > Reading section 10 of XEP-0060 1.10pre5 again, I am wondering if the > implementations working on PEP on the server side actually implemented > it like this. As it is written now, I can have a node with identifier > 'blah' that sends out notifications with geoloc payload. Clients sending > the http://jabber.org/protocol/geoloc+notify feature would also receive > these notifications. I am also wondering how clients would handle that. Reports from the field would be appreciated. :) > On item identifiers, they are optional in the publish request, and if > not provided the server must generate an identifier when the node is > persistent. If a publisher should send along an item identifier depends > on how the node is supposed to be used. Correct. > We used to have an explicit 'current' item identifier for the different > extended presence specs, but these seem to have been removed. I always > assumed extended presence to have a more transient notion than one which > may persist a history of changes (as each publish gets a unique id if > you don't provide one). Peter, could you comment on this? I don't think the "current" ItemID was ever meant to have special meaning, it was just what pgmillard put into the examples. We removed that so that people would no longer get confused. > In general I think you should simply provide an identifier if you want > to be able to retract them at a later point in time. I don't think we > ever discussed how retraction works in the context of PEP. Any use case not discussed in PEP is to be handled as defined in XEP-0060. That applies to item retraction as well. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Error in XEP-0100, Section 4.4.2?
Daniel Henninger wrote: > Hi folk! > > Section 4.4.2, Alternate Flows (of 4.4 Login), example 30, shows the > gateway informing the user of a failed login. Section 9.3 Stanza Errors > of RFC 3920 seems to indicate that there MUST be a type="error" in that > response. Am I misunderstanding or is this just missing from the XEP at > the moment? That's a typo. I fixed this in SVN a few days ago: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0100.xml?r1=1136&r2=1151 Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Removing PEP nodes?
On Thu, 2007-08-16 at 13:09 +0200, Magnus Henoch wrote: > Peter Saint-Andre <[EMAIL PROTECTED]> writes: > > > Andreas Monitzer wrote: > >> On Jun 15, 2007, at 20:07, Peter Saint-Andre wrote: > >> > >>> Andreas Monitzer wrote: > Hi, > I'm currently implementing PEP into libpurple, and have some issue > I can't quite find explained in the XEPs: How do I remove a > personal event? > >>> > >>> I think you would use the syntax defined in XEP-0060: > >>> > >>> http://www.xmpp.org/extensions/xep-0060.html#publisher-delete > >> > >> What should I supply as the item id? I don't have that value. > > > > Why not? You should have received it when the PEP service sent it to > > you (the account owner automatically receives a copy). > > The only reference to this that I can find is section 12.9 of > XEP-0060, Auto-Subscribing Owners and Publishers, which says that the > service MAY do so. Did I miss some other place? Is there anything > PEP-specific that specifies this behaviour? In both the current 1.0 (section 8) as well as the upcoming 1.1 version of XEP-0163 [1], there is the mention of notifications to resources of the node owner. The latter mentions that this is subject to filtered notifications (section 10.2 of the upcoming 1.10 version of XEP-0060 [2]). It seems to me that what was meant is that your own account is assumed to be in the group of entities that will receive notifications when a resource sends the proper entity capabilities with +notify suffixes. Reading section 10 of XEP-0060 1.10pre5 again, I am wondering if the implementations working on PEP on the server side actually implemented it like this. As it is written now, I can have a node with identifier 'blah' that sends out notifications with geoloc payload. Clients sending the http://jabber.org/protocol/geoloc+notify feature would also receive these notifications. I am also wondering how clients would handle that. On item identifiers, they are optional in the publish request, and if not provided the server must generate an identifier when the node is persistent. If a publisher should send along an item identifier depends on how the node is supposed to be used. We used to have an explicit 'current' item identifier for the different extended presence specs, but these seem to have been removed. I always assumed extended presence to have a more transient notion than one which may persist a history of changes (as each publish gets a unique id if you don't provide one). Peter, could you comment on this? In general I think you should simply provide an identifier if you want to be able to retract them at a later point in time. I don't think we ever discussed how retraction works in the context of PEP. [1] http://www.xmpp.org/extensions/tmp/xep-0163-1.1.html [2] http://www.xmpp.org/extensions/tmp/xep-0060-1.10.html -- Groetjes, ralphm
[Standards] Error in XEP-0100, Section 4.4.2?
Hi folk! Section 4.4.2, Alternate Flows (of 4.4 Login), example 30, shows the gateway informing the user of a failed login. Section 9.3 Stanza Errors of RFC 3920 seems to indicate that there MUST be a type="error" in that response. Am I misunderstanding or is this just missing from the XEP at the moment? Daniel
Re: [Standards] Experimental XEPs (was: Re: whiteboarding and shared editing)
On Wed Aug 15 21:01:07 2007, Peter Saint-Andre wrote: The XSF is a standards development organization. We're supposed to be developing standards. If people want to publish the results of their experiments on their own websites as input to the XSF's standards development process, they are free to do so. But as far as I can see, nothing in the XSF's mission or bylaws dictates that such experiments deserve to be published by the XSF. Actually I disagree. Not publishing (in some way, it doesn't have to be as a XEP) experiments and early-stage working documents, and in particular encouraging these to be privately published, does not encourage the kind of commonly-owned specification that can be developed into (or used as input for) a proper standard. I suspect - without much justification, I'll admit - that the result of encouraging specifications to be worked on outside the XSF would lead to fragmentation and proprietary extensions (by which I mean the term in the sense of not held under common ownership). A good SDO, therefore, not only encourages open participation (as we and the IETF do), but also encourages open publication of proposals (as the IETF does with it's I-D documents, which represent a low barrier to entry, centralized, publication mechanism). We tend toward promoting a "do or die" approach to publishing XEPs, which leads to the bulk of a specification being developed outside the XSF, potentially encouraging multiple non-interoperable approaches to the same goal. This has demonstrably happened with the whiteboarding proposals, and it's obviously not in our interests - whether that's as a result of the XSF's processes is most certainly a matter for debate, but I feel the XSF's processes might be adjusted to try to reduce this. I believe the best mechanism for encouraging interoperable protocols through the XSF is to support their publication, even when the proposal has flaws that the Council require to be rectified. Hence my comments in another message about adjusting our processes to allow for a long-term use of the Inbox without forcing publication as a XEP. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Removing PEP nodes?
Peter Saint-Andre <[EMAIL PROTECTED]> writes: > Andreas Monitzer wrote: >> On Jun 15, 2007, at 20:07, Peter Saint-Andre wrote: >> >>> Andreas Monitzer wrote: Hi, I'm currently implementing PEP into libpurple, and have some issue I can't quite find explained in the XEPs: How do I remove a personal event? >>> >>> I think you would use the syntax defined in XEP-0060: >>> >>> http://www.xmpp.org/extensions/xep-0060.html#publisher-delete >> >> What should I supply as the item id? I don't have that value. > > Why not? You should have received it when the PEP service sent it to > you (the account owner automatically receives a copy). The only reference to this that I can find is section 12.9 of XEP-0060, Auto-Subscribing Owners and Publishers, which says that the service MAY do so. Did I miss some other place? Is there anything PEP-specific that specifies this behaviour? -- Magnus JID: [EMAIL PROTECTED]
Re: [Standards] Experimental XEPs
On Wed Aug 15 22:57:23 2007, Peter Saint-Andre wrote: Based on my experience in the IETF since 2002, I am not familiar with a formal process for doing draft proposals there. You just publish an Internet-Draft, others may propose similar or competing I-Ds, and you hash it out on mailing lists and at in-person meetings. Hmm, that sounds awfully familiar... There is a formal process, it's just very lightweight. In order to publish an ID, you need to have the formatting correct and have the IPR boilerplate correct (and current). You also need to name your draft correctly, and a handful of other minor things. In return, the IETF Secretariat then publish it for you for six months. In practice, it's longer than that, since the Tools Team publish the lot in perpetuity. This is all very similar to the Inbox we have, although there's a general expectation that a document still undergoing serious work will remain an ID - it's only published as an RFC much later in the process, when it's generally believed to be finished. This is in part a reflection of the original paper-based publication method - once something's published, you can't change it if it's been sent out in the post. (Anyone wondering why they used to be paper needs to figure out what the IETF developed). For our purposes, simply lessening the expectation that anything hitting the Inbox should immediately be published or killed would be sufficient. I would personally recommend revisiting XEP-1's section 5. In particular, I'd suggest that the publication of something in the Inbox and the request to the Council should be distinct actions, and the latter should be handled by the document author, not the XMPP Extensions Editor. (Although they're often the same person...) I suspect that this would reduce the number of published XEPs, leaving - hopefully - only those that we want to keep, and only that subset of them that are reasonably stable and complete. As for developing WG-like entities again, we could certainly look at that. There are advantages to this kind of behaviour - we limit the traffic on mailing lists somewhat - but it can also lead to fragmentation. It might be better to encourage initial design work to happen on alternate lists, but to move back onto the primary list for finalization, to gain a wider audience (in particular before it becomes a XEP). I think it needs thought. (Which could come from a SIG, of course). Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Group Name with Gateway Registration
Ian Paterson wrote: Currently the name of the group that contacts will be added to tends to be hardcoded on the gateway. This causes problems if there are language issues or, more typically, if the user has two accounts on a legacy service (accessed via two instances of a gateway server) - in which case the contacts will end up being mixed within the same group. To solve this I'd suggest adding a new example (see [1] below) to Section 7 "Contact Lists" that indicates how the client/user might specify during registration a group name (see the "group" below) that the gateway will use whenever it adds contacts to the user's roster. Someone mentioned offlist that some legacy services now support groups, and that some gateways now use these group names (instead of a single hardcoded group). So it may be useful for the client to be able to indicate a prefix/suffix for all group names, instead of a single prefered group name. (A zero length prefix/suffix would be equivalent to no change to the group names at all.) I'd suggest a second additional field like the one in the examples below. - Ian SERVER SENDS: . . . var='groupmodify'> prefix suffix fixed . . . CLIENT SENDS: . . . suffix (Yahoo Work) . . .
Re: [Standards] Group Name with Gateway Registration
Tomasz Sterna wrote: Dnia 15-08-2007, śro o godzinie 18:31 +0100, Ian Paterson napisał(a): Currently the name of the group that contacts will be added to tends to be hardcoded on the gateway. You are talking about gateway XEP-0144 usage? Yes, or the direct roster editing that some server-hosted-plugin gateways seem to perform. - Ian
Re: [Standards] XEP-0170 Recommended Order of Stream Feature Negotiation
You can get sasl to provide the means to establish an encrypted channel after authentication (digest-md5 for example) - which is the reason to establish compression after sasl. Since we already have tls, I dont know what sort of value add it would provide in xmpp case ... but the order of feature negotiation is based on the assumption that this could be leveraged sometimes in the future (like when tls cant be used, etc), and it would be the right order. iirc xep 170 is based on more recent feedback and discussions than 138 ... it is possible that not many servers would have moved to it already, and so the issues you observed. Regards, Mridul Mats Bengtsson wrote: > FYI: > Since there is (was) conflicting recommendations in XEP-0170, > Recommended Order of Stream Feature Negotiation, > (SASL -> compression) > and XEP-0138, Stream Compression, (compression -> SASL), but St Peter > said 0170 is the correct one, I thought about investigating what servers > say: > > OpenFire 3.3.2: It accepts both ways but continue to offer SASL even > after the process SASL -> compress > which it shouldn't > ejabberd 1.1.2: It only accepts compression before SASL (XEP-0138) > > Mats
[Standards] XEP-0170 Recommended Order of Stream Feature Negotiation
FYI: Since there is (was) conflicting recommendations in XEP-0170, Recommended Order of Stream Feature Negotiation, (SASL -> compression) and XEP-0138, Stream Compression, (compression -> SASL), but St Peter said 0170 is the correct one, I thought about investigating what servers say: OpenFire 3.3.2: It accepts both ways but continue to offer SASL even after the process SASL -> compress which it shouldn't ejabberd 1.1.2: It only accepts compression before SASL (XEP-0138) Mats
Re: [Standards] Group Name with Gateway Registration
Dnia 15-08-2007, śro o godzinie 18:31 +0100, Ian Paterson napisał(a): > Currently the name of the group that contacts will be added to tends > to be hardcoded on the gateway. You are talking about gateway XEP-0144 usage? -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
