[Devel] ETag in Presence module

Klaus Darilion klaus.mailinglists at pernau.at
Wed Apr 25 11:55:16 CEST 2007


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



More information about the Devel mailing list