Subject: [Simple] Refreshing event State - New PUBLISH draft 01

From: "George Foti (LMC)" <[email-masked]>
Date: Fri, 4 Jul 2003 15:23:48 -0400

Hi,

Step 10 in setcion 6 (processing PUBLISH Requests), implies that for all PUBLISH requests, including those related to refreshing existing event states, the ESC shall include an entity tag.
 
Is that the case ?

If that is the case, I am unclear as to why that is needed for the refresh case? 
Cant the UAC assume that the absence of an entity tag in the refresh cases simply imply resuing the same entity tag for future refreshes?
Also, if the ESC has to return an enity tag in the response, can the ESC reuse the same entity tag in such a case, or does it have to be a new one?
Finally, it would be desirable to expand section 5.3, where the issue is discussed, with these details.

Thanks
George Foti
Ericsson Canada 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: [email-masked]
Date: Tue, 8 Jul 2003 11:57:25 +0300

Hi George,

Inline.

 > -----Original Message-----
 > From: ext George Foti (LMC) [mailto:[email-masked]]
 > Sent: 04 July, 2003 22:24
 > To: Niemi Aki (NMP/Helsinki); [email-masked]
 > Subject: [Simple] Refreshing event State - New PUBLISH draft 01
 > 
 > 
 > Hi,
 > 
 > Step 10 in setcion 6 (processing PUBLISH Requests), implies 
 > that for all PUBLISH requests, including those related to 
 > refreshing existing event states, the ESC shall include an 
 > entity tag.
 >  
 > Is that the case ?

Correct. ETag is also listed as a mandatory header in 2xx responses to PUBLISH in Table 3.
 
 > If that is the case, I am unclear as to why that is needed 

It isn't strictly needed. There wasn't any particular reason to list it mandatory, except that at least intuitively, it would be good to have all success responses to PUBLISH look and behave the same. However, I'm quite OK either way. Should we remove it?

 > Cant the UAC assume that the absence of an entity tag in the 
 > refresh cases simply imply resuing the same entity tag for 
 > future refreshes?

I think this would work equally well.

 > Also, if the ESC has to return an enity tag in the response, 
 > can the ESC reuse the same entity tag in such a case, or 
 > does it have to be a new one?

This was the intention. A refresh simply extends the validity lifetime of a particular version of event state, so in that sense the entity-tag shouldn't change.

I agree this is not stated very clearly, and I will add text to that extent.

 > Finally, it would be desirable to expand section 5.3, where 
 > the issue is discussed, with these details.

I will try to strengthen both section 6 and section 5.3. about this.

Thanks for the comments.

Cheers,
Aki

---

From: [email-masked]
Date: Tue, 8 Jul 2003 11:57:25 +0300

Hi George,

Inline.

 

Thanks for the comments.

Cheers,
Aki

---

From: "George Foti (LMC)" <[email-masked]>
Date: Tue, 8 Jul 2003 07:43:55 -0400

Aki, you wrote:

>However, I'm quite OK either way. Should we remove it?

Lets keep it for consistency.
Rgds/gf

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, July 08, 2003 4:57 AM
> To: George Foti (QC/LMC); [email-masked]
> Subject: RE: [Simple] Refreshing event State - New PUBLISH draft 01
> 
> 
> Hi George,
> 
> Inline.
> 
> It isn't strictly needed. There wasn't any particular reason 
> to list it mandatory, except that at least intuitively, it 
> would be good to have all success responses to PUBLISH look 
> and behave the same. However, I'm quite OK either way. Should 
> we remove it?
> 
> This was the intention. A refresh simply extends the validity 
> lifetime of a particular version of event state, so in that 
> sense the entity-tag shouldn't change.
>

---

From: "George Foti (LMC)" <[email-masked]>
Date: Tue, 8 Jul 2003 07:43:55 -0400