El Viernes 05 Marzo 2010, Laurent Etiemble escribió: > Hello, > > The <entry-ref/> and <external/> elements serves different purposes:
> - <entry-ref/> is used to reference an <entry/> element. Yes right, I missed that point and thought that it could also point to a <list> (within the same xcap-root). Thanks. > 3.1). This way, the same <entry/> element can appear at different places by > reference and be defined in one place. The reference is relative as the > document and the reference share the same XCAP root. > - <external/> is used to reference a whole <list/> element.The list can be > defined in another document but it can also be placed on another server > (RFC 4826 Para. 3.1). This way, composite list can be constructed (as > defined in OMA and RCS). The anchor is absolute as the anchor can be an > another server. Thanks a lot for the clarification. Anyhow, after implementing a complete XDMS server and all the XCAP protocol and applications I can sure something: XCAP resource-lists application is the worst design in the world. Just a big pain. I really cannot understand how such specification can be token by OMA/RCS. The whole XCAP protocol and applications should be deleted from the IETF documents, as they just are valid to show very complex and unfeasible flow diagrams: http://oversip.net/public/SIP_SIMPLE_OMA.jpeg Also, there is no a real specification about how should the presence server *subscribe* to *all* the XCAP document modifications under the users tree. For sure, vendors will use a proprietary mechanism between their presence servers and XCAP servers. Great. > Moreover: > - In OMA and RCS, it is common to use <external/> to build aggregate groups > ("oma_grantedcontacts" contains "oma_buddylist", which contains > "oma_pocbuddylist", etc). And those resource-lists documents look really ugly, containing absolute links referencing to other absolute links referencing to a list in the document. Finally RCS resource-lists document format/guidelines is a big hack, but a dirty hack is the only solution when using such painful specification (RFC 4826). A document format must be *easy* to implement and parse, and must allow easy interoperability. resource-lists format doesn't fit such requirements at all. OMA guidelines for resource-lists are still a pain, something fully unusable (if not, take a look to OMA pres/xdm guidelines documents and let me know if you understand something there and can code two interoperable implementations). So RCS has done a hack-over-hack design to get something "usable", but a hack anyway, containing absolute <external> references pointing to other absolute <external> references within the same document, and so on. Also, moving a contact from the buddy list to the blocked list involves two XCAP partial operations (entry DELETE and entry PUT). So the XCAP server must notify these changes to the presence server which must get the XCAP document (twice) and recompute *all* the pres-rules (and other permission documents using shared list) twice again. The most inefficient and unclear mechanism I've ever seen. And also, the meaning of a <list> is completely unclear/broken/confused in RFC 4826. Should such list mean something as "my golf friend"? or shall it mean something as "blocked contacts"? What about if I want a contact in two groups ("friends" and "work")? or what about if I want to block a user but keep him within the "friends" group? This is *easily* implementable in XMPP and any other good IM/presence protocol, as <group> is a property of each buddy/contact, instead of having groups/lists containing contacts. So it's easy a buddy to have various <group> elements. Also, being blocked or not is also a property within each buddy/contact, rather than having buddies distributed in "allowed"/"blocked" lists (in fact they are <lists> referenced by other list referenced by other lists.... a chaos). There is a lot to learn from XMPP in terms of IM/presence, I cannot understand with IETF has chosen a completely different design (and *much* worse) for SIP/SIMPLE. Nobody wants it! > - It is common that anchors in <external/> elements reference the XDM > aggregation server XCAP root, which hides on which server the anchored > <list/> is stored. This adds a level of indirection that help hide real XDM > topology. Again, this is a pain. Why should the xcap server domain (or aggregation proxy domain) be present into the documents? what about if the domain must be changed? or what about if the provider changes from http to https? then all the documents would get invalid as they contain absolute URI's. Why should the client be aware of the exact server (or domain) in which the document is stored? This is a really bad design. And the main question: did the author of XCAP protocol and its RFC applications take a look to XMPP specification? For sure: no. He preferred to build a painful/abstract/undefined protocol from scratch (based on Xpath 1.0 but not compatible with Xpath1.0 due to the painful "auid default namespace" which makes any Xpath1.0 existing library not valid to work with XCAP). Nobody chooses SIMPLE for IM/presence in the 2.0 world, nobody (Facebook, Google... all choose XMPP, of course). I'd really would like to know if IETF- SIMPLE work-group cares it. Perhaps they are already happy having telcos/operators trying to make such abominable specifications to run into their private IP networks, so far from Internet. Is this the main target of the SIMPLE group and protocols? ok, goodbye then. As I said, after coding a complete XCAP/XDM server (and client) implementing the full XCAP protocol and OMA/XDM applications (so I *do* know what I'm speaking about), I leave this world of pain forever. I would like to send also this mail to IETF-SIMPLE maillist, but there the only important subject is creating a new version of the hyperpainful xcap-diff draft. No real activity, no real interest in SIP presence/IM at all. In the other hand I don't want just to complain without providing an alternative, so I'll write my own specifications for *easy* and *effective* presence in SIP, so far from XCAP protocol and painful flows. It will be based on a single subscription dialog for event "buddies", so creating a new buddy means a PUBLISH with body like: <buddies> <!-- Adding a new buddy --> <buddy uri="sip:al...@domain.org"> <!-- allow the buddy to contact us by call/IM and see our status --> <permissions> <allow-pres/> <allow-call/> <allow-im/> </permissions> <!-- instruct the presence server that we can see the buddy status --> <pres-watched/> <!-- which groups this buddy belongs to --> <groups> <group>My Friends</group> <group>Co-workers</group> </groups> <!-- data for this user provided by us --> <static-data> <display-name>Alice</display-name> <address>lalalala 1234</address> ... </static-data> </buddy> </buddies> The presence server will store this buddy into a database after extracting some useful data as <permissions> and <pres-watched>, so these fields can be a real column into the table row, allowing *fast* and efficient searching. Then the client sends a SUBSCRIBE for "Event: buddies", this means that the presence server will compute all the user buddies for which <pres-watched/> is present, so no need to subscribe to each watcher, and really simpler than the complex and dangerous rls-service subscription. Then to publish the user presence status, the client would send a new PUBLISH "Event: buddies" with body like this: <buddies> <!-- publish my entire presence status for resource "home" --> <!-- there could me more resource publishing presence status --> <me type=full resource="home"> <display-name>Iñaki</display-name> <status><online/><status> <avatar> <format>png</format> <height>100</height> <wegiht>100</weight> <icon>abca65c6a6565b65ca65c6a56b56a5c6a5....</icon> </avatar> </me> </buddies> If alice allows me to see her presence status then the presence server would send me a NOTIFY with: <buddies> <buddy uri="sip:al...@domain.org" type="partial"> <status> <display-name>Alice</display-name> <status><bussy/><status> <avatar> <format>gif</format> <height>120</height> <wegiht>110</weight> <icon>abca65c6a6565b65ca65c6a56b56a5c6a5....</icon> </avatar> </buddy> </buddies> In this way it's easy to create buddies in an elegant way, without custom and complex documents. Permissions belong to each buddy/contact. And yes, the avatar image goes into the SIP message (PUBLISH/NOTIFY), avoiding exotic external access from a XCAP/XDM server and all the painful flow it involves when coming to permissions rules. What about UDP client? modernize or die, doesn't RFC 3261 states that a SIP device must also speak TCP? I will write such specification and publish it when a first draft is finished. I think it could be useful for SIP environments in pure internet rather than vendor closed networks (as IMS and so...). Also, after 7 months playing with XCAP protocol and SIMPLE presence (building a 100% compliant server and so) I recommend everybody to avoid SIMPLE and XCAP current specifications, fully, they are the worst design I've ever seen, and it's clear that nobody in the Internet world wants to implement them (neither can understand them without ending writing his own "vision" and specification to make them work in some ***custom*** way, so non interoperable with other "visions"). Note that current RCS specifications requires layers over layers to get something "usable" (and really less powerful than XMPP): RCS layer over OMA layer over XCAP related RFC's Pain! All this stuff should dissapear as it has failed. Move on IETF! There is no need to reuse such kind of unuseful specifications, not at all. Best regards. -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
