2010/3/21 Saúl Ibarra <[email protected]>: >> 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.
Well, I wouldn't call it "changes" as for me there is *nothing* right now (nothing but some incomplete, complex, limited and unfeasible specifications involving SIP and HTTP) => nothing. > Also, > letting implementors to have dual implementations could be good to > help the adoption of your new model. "Dual implementations"? this must be a joke :) Do you know any real implementation of the painful XCAP specifications for buddies and permissiones management? (I mean a specification which doesn't end making its own vision of such incomplete specifications). >> 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 Note that PUBLISH method is already "server oriented". PUBLISH is not an end-to-end method and it's just used to "send" information to a server (an not to a SIP user). >> 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? Two problems: - A buddy is permanente data, nobody should re-publish it as it doesn't make sense. - The 200 for a PUBLISH must contain "Expires" header with a valid (and finite) value :( > 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. As the information already exists in the server it doesn't make sense the server to refresh it.. (IMHO) > This is just my two cents, but would let implementations to have old > SIMPLE and new stuff working together. What do you think? No, never, if I could I would delete all the RFC's related to SIMPLE and XCAP, and would also force the IETF-SIMPLE group to remain publishing new versions of xcap-diff draft until they arrive to version 3000 and realize of the unusable monster they have created. Thanks a lot. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
