Hello Rajaram, Thanks for your response.
As per my understanding, once the PUBLISH has been succesfully terminated, any subsequent PUBLISH will be treated as a fresh PUBLICATION, making the subsequent PUBLISH an initial PUBLISH. And Sip-If-Match header is optional in that case.. So am still thinking... what will be the signifance of E-tag in a 2xx for Stop-PUBLISH. Correct me if i'm wrong. Cheers, Pankaj On 4/3/07, Rajaram Tripathy <[EMAIL PROTECTED]> wrote: > > Pankaj, > RFC 3903 says SIP-Etag is mandatory in 2xx response for > PUBLISH. Just check section 11.3, table 6 of RFC 3903 > > Thanks, > Rajaram > > > 11.3. New Header Fields > > Table 4, Table 5, and Table 6 expand on Table 3 in SIP [4], as > amended by the changes in Section 11.1. > > +--------------+-------+-------+-----+-----+-----+-----+-----+ > | Header Field | where | proxy | ACK | BYE | CAN | INF | INV | > +--------------+-------+-------+-----+-----+-----+-----+-----+ > | SIP-ETag | 2xx | | - | - | - | - | - | > | SIP-If-Match | R | | - | - | - | - | - | > +--------------+-------+-------+-----+-----+-----+-----+-----+ > > Table 4: Summary of header fields, P--Z > > +--------------+-------+-------+-----+-----+-----+-----+-----+ > | Header Field | where | proxy | NOT | OPT | PRA | REG | SUB | > +--------------+-------+-------+-----+-----+-----+-----+-----+ > | SIP-ETag | 2xx | | - | - | - | - | - | > | SIP-If-Match | R | | - | - | - | - | - | > +--------------+-------+-------+-----+-----+-----+-----+-----+ > > Table 5: Summary of header fields, P--Z > > +--------------+-------+-------+-----+-----+-----+---------+ > | Header Field | where | proxy | UPD | MSG | REF | PUBLISH | > +--------------+-------+-------+-----+-----+-----+---------+ > | SIP-ETag | 2xx | | - | - | - | m | > | SIP-If-Match | R | | - | - | - | o | > +--------------+-------+-------+-----+-----+-----+---------+ > > Table 6: Summary of header fields, P--Z > > > > Pankaj Munjal wrote: > > Hello, > > > > I had a query regarding Entity tag. > > Suppose a Client has sent a stop-publish request to stop it's publication, > > using Expires Header with value '0'. > > Presence server replies back with a 200 OK indicating that the publication > > has been successfully terminated. > > Should this 200 OK contain an Entity tag? > > > > There is no section in PUBLISH RFC (3903) that explcitely mandates E-tag > in > > such 200 OK. > > > > *Section 4.3: Refreshing Event State* > > *Like the 2xx response to an initial PUBLISH request, the 2xx response to > a > > refresh PUBLISH request will contain a SIP-ETag header field > > with an entity-tag.* > > ** > > *Section 4.5: Removing Event State* > > *Note that removing event state is effectively a publication refresh > > suggesting an infinitesimal expiration interval.Consequently, the > refreshed > > event state expires immediately after > > being refreshed.* > > > > Can we conclude from this that the remove(stop) response will also be > > constructed on the same lines as a refresh response (i.e, having an E-Tag) > > ?? > > > > But if we see other sections in the same RFC.. > > > > *Section 8.2: Client Usage* > > *"Each successful publication will get assigned an entity-tag which is > then > > delivered to the EPA in the response to the PUBLISH request."* > > ** > > *Section 8.3: Server Usage* > > *"An entity-tag is generated and stored for each successful event state > > publication, and returned to the EPA in a 200 (OK) response."* > > > > It says that E-tags are generated for each successful publication, however > > when we send a stop publish request, we are actually deleting this > > Publication context, > > so ideally we don't need a new E-tag now at the Client side. > > > > Can anyone throw some light on this... > > > > Thanks, > > Pankaj > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments. WARNING: Computer viruses can be transmitted > via email. The recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any damage caused > by any virus transmitted by this email. www.wipro.com > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
