[Devel] ETag in Presence module

[Klaus Darilion]

Hi Anca!

I think it would be useful to have old behaviour too - configurable with 
a module parameter.

comments?

regards
klaus

Anca-Maria Vamanu wrote:
> 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
>>>
>>
>