Adding to this, if there are two EPAs updating the same event, if one of them does an 'Initial publish' as mentioned by the RFC, it puts the other EPA publisher out of sync, and then he does the same thing, and gets a new Etag - and this puts the first one out of sync - and there it goes - round and round, isn't it ?
regds arjun On 3/2/06, Arjun Roychowdhury <[EMAIL PROTECTED]> wrote: > > Hi all, > > 3903 specifies that SIP-Etag can also be provided in 2xx. Now suppose a > publisher receives a 412, section 5 states: > > If an EPA receives a 412 (Conditional Request Failed) response, it > *MUST NOT* reattempt the PUBLISH request. Instead, to publish event > state, the EPA *SHOULD* perform an initial publication, i.e., a PUBLISH > request without a SIP-If-Match header field, as described in Section > 4.2. The EPA *MUST* also discard the entity-tag that produced this > error response. > > > While this is a mechanism that works, why not allow the 4xx to contain a > SIP-Etag response which is the latest SIP-Etag at the ESC ? (or specify a > mechanism that allows the EPA to query for the latest Etag before deciding > to write over with an initial publish) > > That way, before the EPA destroys all versioning - especially in the case > where A & B are the publishers of the same event to the ESC and A 'lost' > the Etag, happens to have an older version of the published document as > compared to B, and really needs a way to find out the Etag value, it can > just > 'refresh' its state by receving the latest event state in the 413 body > along with the latest Etag. > > I understand this has been derived from HTTP and HTTP ETag is also allowed > only for 2xx and 3xx, however, since this is SIP-Etag can we have an > extended usage as above ? > > > regds > arjun > > > > -- > Arjun Roychowdhury > > -- Arjun Roychowdhury _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
