[Devel] ETag in Presence module

[Anca-Maria Vamanu]

Hello,

I have read closely the RFC and strange as it may seem, because I can't 
find what benefits it may bring, a ETag must be generated for each new 
Publish.
Therefore I modified the trunk version and commited the changes.

regards,

Anca

Cesc wrote:

> 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
>>
>