[Devel] ETag in Presence module

[Cesc]

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 <klaus.mailinglists at pernau.at> 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
> >> Devel at openser.org
> >> http://openser.org/cgi-bin/mailman/listinfo/devel
> >>
> >
>
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>