Hi guys, This is a "reading interpretation" of RFC 3903 (SIP event state publication) out of the openser list (start from bottom up ... sorry)
Any feedback? Cesc ---------- Forwarded message ---------- From: Cesc <[EMAIL PROTECTED]> Date: Apr 25, 2007 12:10 PM Subject: Re: [Devel] ETag in Presence module Hi Klaus/Anca, Maybe we shall move the discussion (or include) to the sip-implementors ... My first reading of the RFC was in the line of Anca, but a careful reading does indeed suggest that on the 2xx a NEW e-tag needs to be generated, which is taken by the EPA and used in the following PUB. Maybe it is an RFC "bug", in which they mean that "a new e-tag will be generated after a successful INITIAL publication and sent in the 2xx response. For successful refresh/modify/remove publications, the 2xx will contain the EXISTING e-tag". What would be the benefit of changing the e-tag with every publication, as it seems the RFC sets us to do? Cesc S. On 4/25/07, Klaus Darilion <[EMAIL PROTECTED]> wrote: > I read the RFC different: > > ...The ESC MUST generate a new entity-tag for each successful > publication, replacing any previous entity-tag associated with > that event state. > > IMO this means: > > 1. > PUBLISH > ...... > > 200 OK > SIP-ETag: abc > > 2. publish from same client > PUBLISH > SIP-If-Match: abc > > 200 OK > SIP-ETag: def > > 3. > PUBLISH > SIP-If-Match: def > > 200 OK > SIP-ETag: ghi > > > and so on ... > > regards > klaus > > > Anca-Maria Vamanu wrote: > > Hello, > > > > RFC3903 : > > > > 8.3. Server Usage > > > > Entity-tags are generated and maintained by the ESC. They are part > > of the state maintained by the ESC that also includes the actual > > event state and its remaining expiration interval. An entity-tag is > > generated and stored for each successful event state publication, and > > returned to the EPA in a 200 (OK) response. Each event state > > publication from the EPA that updates a previous publication will > > include an entity-tag that the ESC can use as a search key in the set > > of active publications. > > > > This is exacly what presence module does. When a new Publish is > > received, it generates a Etag and includes in the 200ok reply. If a > > publish with a SIP-If-Match header is received, that is an updating > > Publish, it searches if > > it has a matching etag stored in database. > > It does not reuse it for other publications and it respects the unicity > > propriety described in: > > > > 6. The ESC returns a 200 (OK) response. The response MUST contain an > > > > Expires header field indicating the expiration interval chosen by > > the ESC. The response MUST also contain a SIP-ETag header field > > that contains a single entity-tag identifying the publication. > > The ESC MUST generate a new entity-tag for each successful > > publication, replacing any previous entity-tag associated with > > that event state. The generated entity-tag MUST be unique from any > > other entity-tags currently assigned to event state associated > > with that Request-URI, and MUST be different from any entity-tag > > assigned previously to event state for that Request-URI. See > > Section 8.3 for more information on the ESC handling of entity- > > tags. > > > > > > Klaus Darilion wrote: > > > >> Hi! > >> > >> Is the ETag constant for a certain client "session"? > >> > >> RFC3903 mandates that the Etag should be changed with every PUBLISH: > >> > >> 6.6: ...The ESC MUST generate a new entity-tag for each successful > >> publication, replacing any previous entity-tag associated with > >> that event state. > >> > >> I think currently openser reuses the Etag from the received PUBLISH in > >> the 200 Ok. Nevertheless, if "changing" Etag will be introduced IMO a > >> constant Etag should be chooseable with module parameters. > >> > >> regards > >> klaus > >> > >> _______________________________________________ > >> Devel mailing list > >> [EMAIL PROTECTED] > >> http://openser.org/cgi-bin/mailman/listinfo/devel > >> > > > > _______________________________________________ > Devel mailing list > [EMAIL PROTECTED] > http://openser.org/cgi-bin/mailman/listinfo/devel > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
