[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