[Devel] ETag in Presence module

[Anca-Maria Vamanu]

Reading again I think you may be right :) . If so I  will do the changes.

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