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

From: [email-masked]
Date: Mon, 3 Nov 2003 11:26:22 +0200

Hi Ben,

 > -----Original Message-----
 > From: ext Ben Campbell [mailto:[email-masked]]
 > Sent: 28 October, 2003 00:38
 > To: Niemi Aki (NMP/Helsinki)
 > Cc: [email-masked]
 > Subject: Comments on publish-01
 > 
 > 
 > Hi,
 > 
 > I have some comments on publish-01. These are not 
 > necessarily specific 
 > to 01 changes--I apologize if I bring up old concerns again, 
 > or mention 
 > something now that I should have mentioned previously.
 > 
 > 
 > Thanks!
 > 
 > Ben.
 > 
 > --------------------------------------------------------------
 > 
 > 4.3: Why do we require all publish packages to support partial 
 > publication? This seems more a presence requirement than a generic 
 > publish requirement.

This is true. 
 
 > 4.4: Why do we need to specify default expiration times? Why 
 > is this not 
 > just local policy of the ESC?

This is also quite a good question. I think it would be enough to just specify a default expiration time for the PUBLISH method, and leave everything else up to the ESC.
 
 > 5 (last paragraph): I _think_ the intent is to say you 
 > should not send a 
 > new request to a particular ESC when a previous one is 
 > pending for the 
 > _same_ ESC, correct? This seems to be the spirit of the 
 > text, but there 
 > is room for someone to interpret this to say that I cannot 
 > send a new 
 > publish to any ESC if I have not gotten a response from a 
 > particular ESC.

I'll try to clarify the language.
 
 > 5.2 Paragraph 1: Still says To header indicates the AoR. I am pretty 
 > sure we had consensus in SIMPLE that this should be the 
 > r-URI. (Although 
 > I recognize we have had a new controversy on the SIP list 
 > about this.)

Yes, this was simply overlooked while editing.

 > Paragraph 2: Can it _ever_ be carried anywhere else? If not, 
 > we should 
 > drop the word "typically"

I think it might, for example using content indirection, or perhaps the event state could be in the Request-URI. In any case, there doesn't seem to be that much harm if we leave the options open with "typically". 
 
 > 5.3: This seems to conflict with the meaning of 4.4. Nothing is 
 > mentioned in 5.3 about a default expiration.

Will clarify this. It should mention the default expiration.
 
 > 5.4 para 5, 1st sentence:
 > 
 > "The If-Match header field containing an entity-tag 
 > preconditions the 
 > PUBLISH request to refresh a specific instance of event state in the 
 > ESC." Sentence is confusing to me. Are we using the word 
 > "preconditions" 
 > as a verb?

I will reword.
 
 > Same paragraph: Nit: I suspect that "i.e." (which translates 
 > as "that 
 > is", really should mean "for example", as there are other situations 
 > other than expired state that could cause this result. (For 
 > example, the 
 > state never existed at all.)

Correct, will change this to "e.g.".
 
 > Last paragraph: I think this should be MUST NOT. Doesn't the 
 > presence of 
 > a body explicily make this into a modify request, instead of 
 > a refresh?

Yes, will use MUST NOT. 
 
 > 5.7 First paragraph: Should use r-uri, not To header.

Correct.

 > 6 step 8 last para: Do we want to limit this to explictly 
 > 500? In the 
 > example you give, it may be that 504 makes more sense.

Hoe about something like:

       The processing of the PUBLISH request MUST be atomic. If internal
       errors (such as the inability to access a back-end database)
       occur before processing is complete, the publication MUST NOT
       succeed, and the ESC MUST fail with an appropriate error response,
       such as 504 (Server Time-out).
 
 > Table 1: Accept explicitly disallowed in requests? What if a future 
 > publish package uses bodies in responses? Would it not make sense to 
 > allow Accept in the request for such a package?

That makes sense for Accept and maybe even all Accept-*. I will add an "o" to all of them.

 > Security Considerations: Do we need to comment on the interaction 
 > between PUBLISH and the possibility of e2e signatures on presence 
 > documents? I don't know if that belongs here or not.

There is already some text in Section 9.4 - do we need more than that?

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 03 Nov 2003 09:28:38 -0600

[email-masked] wrote:

[...]

>        such as 504 (Server Time-out).

I think that works.

[...]

> There is already some text in Section 9.4 - do we need more than that?

I think that is fine--I just missed it the first time.

Thanks!

Ben.