Subject: [Sip] Entity-tags in PUBLISH

From: [email-masked]
Date: Wed, 26 Nov 2003 13:36:31 +0200

Hi,

As we discussed in Minneapolis, the PUBLISH draft needs additional text covering the use of etags, and the relationship to HTTP in this respect. One related thing that came up was that although the etags in PUBLISH have been copied from RFC 2616, there are some minor differences, mainly due to the fact that with PUBLISH, we don't have use for features used with for example the GET and HEAD methods:

   - We have dropped the weak etag concept, because PUBLISH etags are basically 
     always strong. As a side effect, the syntax is also different, i.e., an etag 
     is a token, instead of quoted-string with an optional "weakness" tag prefix. 
     This seemed reasonable, since this is the common way to representing	
     similar things in SIP, and after removing the weak tag, the quotes were 
     superfluous.

   - We have dropped multiple etags in If-Match header, because in PUBLISH, the 
     EPA will always only modify/remove/refresh its own publications. This 
     corresponds to a conditional PUT in HTTP/1.1, where only a single entity-tag 
     is present in If-Match.

   - We have dropped the "*" valued If-Match. An "If-Match: *" corresponds to a 
     PUBLISH without the If-Match header, so there is no need for this special 
     value.

   - In HTTP/1.1, the origin server SHOULD create an etag, whereas in PUBLISH, 
     the ESC MUST always create an etag.

The main functionality of etags is the same in my opinion, even with the above "focused" use of them. But I would still like some input on whether the working group feels these differences are considerable enough that we should *not* inherit the syntax for these headers from HTTP/1.1, but create similar but distinct header field names, and response code.

Cheers,
Aki

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip