Subject: [Sip] Comments on sip-publish-01

From: [email-masked]
Date: Thu, 6 Nov 2003 15:53:58 +0200

Apologies if some of these comments below have already been made on the list. There are no major comments.

- General:
   - I think a section should be dedicated to etags. This section would explain how they work. At the moment, it is all over the place.

- Abstract:
   - The 1st sentence in the second paragraph repeats what is said in the first paragraph.

- Section 1: 
   - The 1st sentence in the 3rd paragraph repeats what is said in the first paragraph.

- Section 3:
   - Second paragraph repeats definitions section. Maybe this paragraph can go away and references added to definitions section.

- Section 4.3:
   - Why is it a MUST for the content-type to provide partial publication? I think MAY is enough

- Section 5:
   - The note: Why would a PUBLISH fork? If would only fork if the user has explicitly registered 2 different addresses or the proxy is configured with 2 ESCs. In any case, I don't get why the PUBLISH may not be appropriately presented. I think this note can go away.
   - PUBLISH does not create a dialog. Can we have some text here why this is so. I just to remind us in 2 years time when we start asking the question again.
   - Why is it explicitly forbidden for a PUBLISH to contain a contact. It could be as simple as saying that the ESC ignores the contact header.

- Section 5.2:
   - Request-URI should be used instead of To-header
   - It should be clarified that an etag associates an EPA with the ESC for that boot cycle or until the EPA removes a publication (or something like that) and does not change for that duration. (I was momentarily confused and thought that the etag changes with every PUBLISH from the same EPA).
   - I think I understand the etag mechanism, but is there a chance that a state already exists for a EPA before that initial PUBLISH (a crash and reboot or something). How does the ESC behave in this case? Does the ESC know it is the same ESC publishing and therefore should remove the state that was created before this new PUBLISH?

- Section 5.4 and 5.5:
   - "the 200 (OK) response to a PUBLISH request from the ESC contains ..." appears a few times. This confused me into thinking that you are talking about the 200 of the refresh/modification PUBLISH. I think you mean the "previous" PUBLISH.

- Section 5.5:
   - The note should be normative text.

- Section 5.6
   - "EPAs which support the PUBLISH method SHOULD support this mechanism for explicitly removing event state." Should the SHOULD be a MUST?

Regards,
Hisham

_______________________________________________
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: Aki Niemi <[email-masked]>
Date: Mon, 10 Nov 2003 18:38:16 +0200

Hi Hisham,

Sorry for the delay in answering. Inline-

ext [email-masked] wrote:
> - General: - I think a section should be dedicated to etags. This
> section would explain how they work. At the moment, it is all over
> the place.

This is probably a good idea. I will try to address this in the next rev.

> - Abstract: - The 1st sentence in the second paragraph repeats what
> is said in the first paragraph.

Hmm... I don't quite see how, but perhaps you can suggest a better wording?

> - Section 1: - The 1st sentence in the 3rd paragraph repeats what is
> said in the first paragraph.

I think it is sort of elaborating on the text in the 1st paragraph, but 
I will change it if you can suggest some better wording.

> - Section 3: - Second paragraph repeats definitions section. Maybe
> this paragraph can go away and references added to definitions
> section.

True. How about this: I remove references to presence from the 
definitions and that way chapter 3 adds value in describing how these 
components relate to presence.

> - Section 4.3: - Why is it a MUST for the content-type to provide
> partial publication? I think MAY is enough

Ben commented this before, and this is mainly a presence related thing 
anyway. Some event packages may have no use for such a thing. I'll try 
to reword this so that what is meant here is more in terms of allowing 
more than one EPA at a time.

Then, if that is the case, the content-type may also need to support 
this explicitly.

> - Section 5: - The note: Why would a PUBLISH fork? If would only fork
> if the user has explicitly registered 2 different addresses or the
> proxy is configured with 2 ESCs. In any case, I don't get why the
> PUBLISH may not be appropriately presented. I think this note can go
> away. - PUBLISH does not create a dialog. Can we have some text here
> why this is so. I just to remind us in 2 years time when we start
> asking the question again. - Why is it explicitly forbidden for a
> PUBLISH to contain a contact. It could be as simple as saying that
> the ESC ignores the contact header.

This note is about an OPTIONS forking, in which case the 200 OK may not 
be from an ESC, and thus lack support for the PUBLISH method.

> - Section 5.2: - Request-URI should be used instead of To-header 

Correct, I missed this while editing.

> - It
> should be clarified that an etag associates an EPA with the ESC for
> that boot cycle or until the EPA removes a publication (or something
> like that) and does not change for that duration. (I was momentarily
> confused and thought that the etag changes with every PUBLISH from
> the same EPA). - I think I understand the etag mechanism, but is
> there a chance that a state already exists for a EPA before that
> initial PUBLISH (a crash and reboot or something). How does the ESC
> behave in this case? Does the ESC know it is the same ESC publishing
> and therefore should remove the state that was created before this
> new PUBLISH?

The ESC would not know, and would instead assign a new etag and treat 
this as an initial publication. The original publication would simply 
expire and be garbage-collected.

The etags are just receipts for the EPA on a given publication. 
Modifying, refreshing or removing that state is only possible upon 
presenting this receipt to the ESC.

I gather this sort of text needs to be in that chapter explaining the 
etags usage a bit closer.

> - Section 5.4 and 5.5: - "the 200 (OK) response to a PUBLISH request
> from the ESC contains ..." appears a few times. This confused me into
> thinking that you are talking about the 200 of the
> refresh/modification PUBLISH. I think you mean the "previous"
> PUBLISH.

Right. I need to clarify those passages a bit.

> - Section 5.5: - The note should be normative text.

It ought to be - in Chapter 6 which describes the ESC behavior.

> - Section 5.6 - "EPAs which support the PUBLISH method SHOULD support
> this mechanism for explicitly removing event state." Should the
> SHOULD be a MUST?

You're right. This is a MUST.

Thanks for the comments!

Cheers,
Aki

> Regards, Hisham

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