RE: I-D ACTION:draft-ietf-sip-publish-02.txt

Hi Jonathan,

Thanks a lot for the excellent comments. Most of them I will directly fold into -03. Few clarifications below.

Cheers,
Aki

Jonathan Rosenberg wrote:

<snip />

 > * section 3, paragraph 3:
 > 
 > > That is, the steady-state of
 > >    this event package in the absence of, or in addition 
 > to, soft state
 > >    provided through the PUBLISH mechanism
 > 
 > this makes it sound like steady state is a function of the event 
 > packae only. the hard state is a function of the resource uRI and 
 > event package. Indeed, one may think of an event package as merely 
 > sub-resource within the full resource. I wonder if it wouldn't be 
 > useful to come up with a term for this - for example, "scoped 
 > resource" is a combination of a URI and event package, and 
 > identifies 
 > a particular piece of event state.

I don't quite follow,  but I agree the quoted text is rather vague. To me the hard state, or "preconfigured"
state is just another source of event state to the composer. The mechanism to set that state might be other
than PUBLISH. 

<snip />

 > * section 5.1:
 > 
 > > As with any other SIP message, the PUBLISH mechanism MAY use the
 > >    content indirection mechanism defined in [10].
 > 
 > this statement makes [10] a normative reference, I believe. It is 
 > listed as informative in the references section.

I'm not sure I agree. I've understood the RFC editor's policy so that an informative reference is not
required for implementing the RFC. It's an interesting question as to how this relates to RFC 2119
terminology. But I think a MAY makes the feature optional so that it fits the informative reference definition.

<snip />

 > * section 5.3 is out of place. Section 5 is about generating 
 > requests. 
 > the subsections for the most part deal with the specific 4 sub-cases 
 > you identified in 5.1. However, 5.3 talks about setting expirations, 
 > which is something that is actually done for the cases in 5.2, 5.4, 
 > 5.5 and 5.6. I would suggest that eaech of those four 
 > sections rather 
 > describe how the Expires header field is constructed for each case. 
 > That is consistent with having a column in table 1 on 
 > expires. Indeed, 
 > each section should also talk about bodies and etag. Along those 
 > lines, section 5.2 does not actually say that a body has to be 
 > present; it shouold be stated given the importance of this fact from 
 > table 1.

I think the reason for this is that I envisioned a PUBLISH carrying state in some other place than the body.
However, I don't know if such a case would ever exist, and other people have also commented on this. I think
it is safe to assume that the state is always carried in the body, as opposed to "typically".

I'll change the text in 5.2 accordingly.

<snip />

 > * section 5.7 is out of place, since it has nothing to do with 
 > constructing publish at all. indeed, since the note basically says 
 > that this doesnt work, i would suggest removing the section entirely.

I think I agree with you. The separate email thread about querying the state of a particular publication
ought to resolve this issue. 

 > It occurs to me that its a huge shame that etags are not 
 > URIs. If they 
 > weree, we would have a rerally neat way to find out the 
 > specific state 
 > of a particular publication - you woould subscribe to that etag. The 
 > next best thing might be to define a header field in the PUBLISH 
 > response that identifies this particular published instance. Hmm, 
 > Contact might even be a sensible choice there... worth discussing. 
 > I'll send a separate email on the topic.

I responded to this separately. 

<snip />

 > * section 6:
 > 
 > >  PUBLISH requests MUST be processed in the order that they are
 > >    received. 
 > 
 > isnt this only true for requuests with the same r-uri?

Correct. I will add some text to this effect.

<snip />

 > * the steps in section 6 omit handling for the case where 
 > there was no 
 > SIP-If-Match header field. step 6 says to check for it, and all the 
 > following steps assume it was there. I would suggest adding a bullet 
 > to step 6 which says, if there was no SIP-If-Match header field, the 
 > ESC creates a new etag, and associates it with as-yet empty event 
 > state. Processing continues in the steps below. This way, you always 
 > exit step 6 with an etag.

The attempt was to make etag generation part of step 9. This way, an entity-tag is generated for each
successful publication and returned in 2xx, irrespective of whether the publication was an initial
publication, a refresh, or a modification. Indeed, a 2xx to a removal could be treated the same, although
such an entity-tag is useless at that point.

So I think it is ok to exit step 6 without an entity tag, as long as step 9 is clear that entity-tags are
generated for all successful publications.

 > 
 > * step 8 of section 6:
 > 
 > >  The ESC processes the published event state, typically contained
 > >        in the body of the PUBLISH request. If the request 
 > contains no
 > >        body (when it should contain one), 
 > 
 > i think we need to list the conditions for when it should 
 > contain one. 
 > Indeed, since you are always allowed to publish without a body in 
 > order to refresh or delete, under what conditions is it illegal for 
 > the body to not be there?

I don't think there are any. I will reword and remove that part.

<snip />

 > * step 9:
 > 
 > > The response MUST also contain a SIP-ETag header field for
 > >        which the ESC MUST generate and store a locally 
 > unique entity-tag
 > >        for identifying the publication.
 > 
 > You should clarify that it generates a new one in each response, and 
 > does so for both initial and refreshes. Also, clarify that this etag 
 > replaces the previous, such that the previous etag is no 
 > longer valid 
 > for identifying the publication.

Good point.

<snip />

 > * sectiton 11.1:
 > 
 > > Authentication issues are discussed in SIP [2]. The exact 
 > methods for
 > >    creation and manipulation of the ESC authorization policies are
 > >    outside the scope of this document.
 > 
 > you will get dinged on this by Bellovin, guaranteed. He wants to see 
 > statements about baseline mandtory to implement mechahnisms. 
 > Its fine 
 > to say that this mechanism is digest, as mandated by rfc3261.
 > 
 > >  To prevent replay attacks, implementations SHOULD require
 > >    authentication with anti-replay protection. 
 > Authentication issues are
 > >    discussed in SIP [2].
 > 
 > as above.... does this mean digest with next-nonce or are 
 > you talking 
 > sips?
 > 
 > and section 11.4:
 > 
 > > To prevent such attacks, implementations SHOULD, at a minimum,
 > >    provide integrity protection across the To, From, Event,
 > >    SIP-If-Match, Route, and Expires headers and the bodies 
 > of PUBLISH
 > >    requests.
 > 
 > as above, he will ask for a mechanism. This requiurement makes the 
 > choice sips.
 > 
 > Same in 11.5.

I see what you are saying. But is it really so that each new method that gets added to SIP needs to explicitly
mandate certain security mechanisms? At least going beyond the security considerations in RFC 3261
seems unnecessary, since the properties of PUBLISH are very similar to, say, REGISTER. 

I was hoping we could get by with discussing PUBLISH specific threats, and merely referencing relevant
parts of RFC3261 when it comes to mitigating those threats.

Cheers,
Aki

<snip />

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip