Subject: Re: [Sip] Entity-tags in PUBLISH

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 05 Dec 2003 15:59:57 -0500

Once the syntax and semantics are not the same, you should not use the 
same header name. Even if we added back in the features we don't need 
pper se, there is still the issue of SHOULD vs. MUST for etag 
inclusion in the response. I think we definitely want a must. Thus, 
this is a change in behavior from HTTP.

I would propose we use "SIP-Etag" and "SIP-If-Match" to convey that 
these are similar in scope to their http bretheren, but not the same.

-Jonathan R.

[email-masked] wrote:

> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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

---

From: [email-masked]
Date: Tue, 9 Dec 2003 10:32:29 +0200

> -----Original Message-----
 > From: ext Jonathan Rosenberg [mailto:[email-masked]]
 > Sent: 05 December, 2003 23:00
 > To: Niemi Aki (NMP/Helsinki)
 > Cc: [email-masked]
 > Subject: Re: [Sip] Entity-tags in PUBLISH
 > 
 > 

Sounds like a plan.

Cheers,
Aki

 > > 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:
 > > 
 > > 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
 > > 
 > >