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

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 12 Jul 2003 21:37:33 -0400

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.

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

* 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?

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.

* Bullet 9 of section 6:

> the source of the publication (From
>            URI), and the version of the publication.

why is the From needed?

* 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".

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

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

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.

-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