Subject: RE: [Simple] Comments on draft-ietf-simple-publish

From: [email-masked]
Date: Tue, 2 Sep 2003 19:33:36 +0300

Hi Jonathan,

Seems like I never responded to this email, so here goes - inline.

Jonathan Rosenberg wrote:
 > Some comments:
 > 
 > * Section 4 sounds like it is trying to impose guidelines 
 > for some kind of registration procedure that event packages 
 > need to follow. But, it doesn't explicitly state that. If 
 > the intent is to do that (and I think it is), you should 
 > follow the basic structure of rfc3265 in terms of how its done.

It certainly tries to do just that. The next version will try to be more closely aligned with the way RFC 3265 puts it.
 
 > * Section 4 introduces requirements that an event package 
 > has to satisfy in order to make use of publish. In some 
 > places, it does that by referencing the publish requirements 
 > doc. That doc is informational, but you effectively 
 > promoting those requirements to normative in your usage. 
 > That will be a problem. I recommend that you instead include 
 > the specific requirements from the publish requirements doc 
 > into publish that define things an event package has to declare.

Good point. The normative nature of the requirements doc is removed.

 > 
 > * section 5 - subscribing to the AOR will not likely give 
 > you the same information that was published.

Will add a note to that effect. The problem is that this is as close we can get with the current PUBLISH to fulfilling requirement 14 of the publish requirements. Of course, adding such a mechanism should be possible later on if needed.

 > 
 > * section 5 says:
 > 
 > > Expires: PUBLISH requests SHOULD contain a single Expires header
 > >      field. This value indicates the lifetime of the event 
 > state being
 > >      published by this request. A special value of "0" 
 > indicates the
 > >      removal of any prior soft state established by a prior PUBLISH
 > >      request from this EPA.
 > 
 > I don't think its "any prior soft state" - its the specific 
 > soft-state identified by an etag, no?

True, fixed that.
 
 > Section 5.5 doesnt say anything about this either. For 
 > deletion, when there is not body (and thus no tuple id), 
 > there needs to be a way to identify the tuple being deleted.

All of chapters 5.3, 5.4 and 5.5 will have some text to clarify the etags usage in the next rev.
 
 > * The numbered steps in section 6 repeat the UA processing 
 > in rfc3261. They shouldn't be there. You should just 
 > reference rfc3261, and augment the steps there with 
 > publish-specific operations.

Fixed in the next rev.
 
 > * Bullet 9 of section 6:
 > 
 > >the source of the publication (From
 > >           URI), and the version of the publication.
 > 
 > why is the From needed?

Not needed, so removed.

 > * also in step 9:
 > 
 > 
 > >For new publications, i.e., publications without a version
 > >           precondition, the ESC MUST generate a locally unique
 > >           entity-tag, and store it, replacing any existing 
 > entity-tags
 > >           stored for that particular event state. The new 
 > entity-tag
 > 
 > 
 > I don't like this usage of "new". To me, new means that 
 > there is no published data for this tuple. But, you are 
 > using new to mean that the publication doesnt' have a 
 > precondition. That doesnt seem to fit the meaning of "new".

This will also be reworded.

 > * Table 3 - need to indiate its applicability to other methods.

Will add that. 
 
 > * security considerations section: you should discuss 
 > specific threats that PUBLISH introduces, and then from 
 > these make recommendations (such as SHOULD authenticate). 
 > YOu probably want to talk about sensitivity of published 
 > data, and say something about sips.

I will try to add text to this effect, but this section may need to be revisited by someone more security-savvy later on.

 > 
 > On this open issue:
 > 
 > >o  Atomicity of publication. Should the segments of event state
 > >      (presence tuples) be sent in separate PUBLISH 
 > requests or is it
 > >      enough to treat these as implicitly separate 
 > publication requests?
 > 
 > 
 > I vaguely recall at the interim meeting that the idea was 
 > floated that for presence, there were two separate things 
 > one could publish. One was a full presence document, in 
 > which case there is no "partial publication". The other was 
 > just a tuple, representing the partial publication case. In 
 > the case where just a tuple is published, I think that each 
 > PUBLISH should contain just one tuple. If you want to 
 > publish an entire document (in which case you are saying 
 > "this is the whole presence state for user X"), you can do that too.

This issue has basically gone away now that segmentation and collision detection among the segments has been removed.

Cheers,
Aki
 
 > 
 > -Jonathan R.
 > 
 > 
 > 
 > 
 > --
 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
 > Chief Technology Officer Parsippany, NJ 07054-2711
 > dynamicsoft
 > [email-masked] FAX: (973) 952-5050
 > http://www.jdrosen.net PHONE: (973) 952-5000
 > http://www.dynamicsoft.com
 > 
 > 
 > 
 > 
 > _______________________________________________
 > Simple mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/simple
 > 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 Sep 2003 09:32:45 -0400

Aki,

Thanks for your resposne. Everything looks good. I am looking forward 
to seeing a rev of this doc. Hopefully we have finally settled on the 
mechanism here!

Thanks,
Jonathan R.

[email-masked] wrote:

>> * Section 4 sounds like it is trying to impose guidelines for
>> some kind of registration procedure that event packages need to
>> follow. But, it doesn't explicitly state that. If the intent is
>> to do that (and I think it is), you should follow the basic
>> structure of rfc3265 in terms of how its done.
> 
> It certainly tries to do just that. The next version will try to be
> more closely aligned with the way RFC 3265 puts it.
> 
>> * Section 4 introduces requirements that an event package has to
>> satisfy in order to make use of publish. In some places, it does
>> that by referencing the publish requirements doc. That doc is
>> informational, but you effectively promoting those requirements
>> to normative in your usage. That will be a problem. I recommend
>> that you instead include the specific requirements from the
>> publish requirements doc into publish that define things an event
>> package has to declare.
> 
>> * section 5 - subscribing to the AOR will not likely give you the
>> same information that was published.
> 
> Will add a note to that effect. The problem is that this is as
> close we can get with the current PUBLISH to fulfilling requirement
> 14 of the publish requirements. Of course, adding such a mechanism
> should be possible later on if needed.
> 
>> 
>> * section 5 says:
>> 
>>> Expires: PUBLISH requests SHOULD contain a single Expires
>>> header field. This value indicates the lifetime of the event
>> state being
>> Section 5.5 doesnt say anything about this either. For deletion,
>> when there is not body (and thus no tuple id), there needs to be
>> a way to identify the tuple being deleted.
> 
>> * The numbered steps in section 6 repeat the UA processing in
>> rfc3261. They shouldn't be there. You should just reference
>> rfc3261, and augment the steps there with publish-specific
>> operations.
> 
> Fixed in the next rev.
> 
>> * Bullet 9 of section 6:
>> 
>>> the source of the publication (From URI), and the version of
>>> the publication.
>> 
>> why is the From needed?
> 
> Not needed, so removed.
> 
>> * also in step 9:
>> 
>> 
>> I don't like this usage of "new". To me, new means that there is
>> no published data for this tuple. But, you are using new to mean
>> that the publication doesnt' have a precondition. That doesnt
>> seem to fit the meaning of "new".
> 
>> * security considerations section: you should discuss specific
>> threats that PUBLISH introduces, and then from these make
>> recommendations (such as SHOULD authenticate). YOu probably want
>> to talk about sensitivity of published data, and say something
>> about sips.
> 
> I will try to add text to this effect, but this section may need to
> be revisited by someone more security-savvy later on.
> 
>> 
>> On this open issue:
>> 
>> I vaguely recall at the interim meeting that the idea was floated
>> that for presence, there were two separate things one could
>> publish. One was a full presence document, in which case there is
>> no "partial publication". The other was just a tuple,
>> representing the partial publication case. In the case where just
>> a tuple is published, I think that each PUBLISH should contain
>> just one tuple. If you want to publish an entire document (in
>> which case you are saying "this is the whole presence state for
>> user X"), you can do that too.
> 
> This issue has basically gone away now that segmentation and
> collision detection among the segments has been removed.
> 
> Cheers, Aki
> 
>> 
>> -Jonathan R.
>> 
>> 
>> 
>> 
>> -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief
>> Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 
>> _______________________________________________ Simple mailing
>> list [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 Sep 2003 09:32:45 -0400

Aki,

Thanks,
Jonathan R.