Hi Iñaki, On Sun, Mar 21, 2010 at 1:59 PM, Iñaki Baz Castillo <[email protected]> wrote: > Hi, I'm starting a new specifications for SIP presence, totally from > scratch. I won't reuse any of the current painful specifications > (presence model, XCAP, resource-lists, pres-rules, resource-lists...), > neither HTTP protocol (just SIP for all). > > For example, a buddy (a SIP contact) is a XML document <buddy> > containing the <groups> it belongs to and also the <permissions> I let > him (i.e. <pres-allowed />). > > One of the main problems I've found is the lack of a way to publish > permanente information via SIP. When creating a buddy it must be > permanently stored in the presence server. For such prupose, a PUBLISH > could be used, so I send a PUBLISH ("Event: buddies") containing the > <buddy> XML. > > Unfortunatelly PUBLISH requires a "Expires" header and its value > cannot be infinite (can it be??). Of course I don't want temporal > storage of the buddies, but permanent. Is there any way to publish > permanent information with PUBLISH? >
Trying to change the world is cool, and I think it's really positive to see an attempt to make SIMPLE much more simple. Now, trying to make too many changes could lead people not to adopt new models. Also, letting implementors to have dual implementations could be good to help the adoption of your new model. > If not, which would be the best approach?: > > a) Creating a new SIP method as STORAGE (or whatever) which allows > creating or deleting permanent information in the server (in this case > in the presence server). > Maybe this is to specific for server oriented presence? I can't say exactly why, but this doesn't feel 100% right to me :-S > b) Allowing "Expires: infinite" in PUBLISH. This is hard as involves a > SIP basic grammar modification. > This is too big change IMHO so I consider it a no go... instead, what about letting the presence server do the job of re-publishing the information? You could use the old-school PUBLISH with some new header where you specify what you want to do just as you said in the STORAGE method proposal. Stupid example: Storage: permanent Expires: 3600 Now, the presence server would be the responsible for publishing the information again when 3600 seconds elapse. This is just my two cents, but would let implementations to have old SIMPLE and new stuff working together. What do you think? Cheers, -- /Saúl http://saghul.net | http://sipdoc.net _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
