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 <[EMAIL PROTECTED]> 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@openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>
>
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
