Subject: [Sip] Comments on publish-01

From: Ben Campbell <[email-masked]>
Date: Mon, 27 Oct 2003 16:38:05 -0600

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.

4.4: Why do we need to specify default expiration times? Why is this not 
just local policy of 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.

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

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

5.3: This seems to conflict with the meaning of 4.4. Nothing is 
mentioned in 5.3 about a 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?

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

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?

5.7 First paragraph: Should use r-uri, not To header.

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.

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?

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.

_______________________________________________
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