Subject: [Sip] I-D ACTION:draft-ietf-sip-publish-02.txt

From: [email-masked]
Date: Wed, 07 Jan 2004 16:01:50 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Session Initiation Protocol (SIP) Extension for Event 
			  State Publication
	Author(s)	: A. Niemi
	Filename	: draft-ietf-sip-publish-02.txt
	Pages		: 39
	Date		: 2004-1-7
	
This document describes an extension to the Session Initiation
Protocol (SIP) for publishing event state used within the framework
for SIP Event Notification. The first application of this extension
is targeted at the publication of presence information.
The mechanism described in this document can be extended to support
publication of any event state, for which there exists an appropriate
event package. It is not intended to be a general-purpose mechanism
for transport of arbitrary data, as there are better-suited
mechanisms for this purpose (FTP, HTTP, etc.)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-publish-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-publish-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 24 Jan 2004 17:39:01 -0500

enclosed are my comments on -02. Most are minor. There is one major 
question, and I sent a separate note on that.

* the current title is not in line with the guidelines in 
draft-ietf-sip-guiudelines, which says:

  An important decision to be made about the extension is its title.
    The title MUST indicate that the document is an extension to SIP. It
    is RECOMMENDED that the title follow the basic form of "A [summary of
    function] for the Session Initiation Protocol (SIP)", where the
    summary of function is a one to three word description of the

as such, I suggest changing to "An Event State Publication Extension 
to the Session Initiation Protocol (SIP)"

* wording nit in the abstract:

This document describes an extension to the Session Initiation
    Protocol (SIP) for publishing event state used within the framework
    for SIP Event Notification.

is clearer as:

This document describes an extension to the Session Initiation
    Protocol (SIP) for publishing event state used within the SIP 
event framework.

* also in the abstract:

It is not intended to be a general-purpose mechanism
    for transport of arbitrary data, as there are better-suited
    mechanisms for this purpose (FTP, HTTP, etc.)

i suggest dropping the examples (FTP, HTTP) since it may raise some 
alarms that we are asserting that http should be used for all kinds of 
data transport functions.

* In the intro:

> The focus of this specification is to provide a framework for the
>    publication of event state from a user agent to an entity that is

focus implies that it does other things also, but it doesnt. I would 
rather say "this specification provides a framework for the ...."

* also in the intro:

> The first application of this mechanism is the publication of
>    presence state by a presence user agent to a presence compositor,
>    which has a tightly coupled relationship with the presence agent.

the beginning of this sentence doesnt make it clear that this spec 
indeed defines that application. how abouot:

"In addition to defining an event publication framework, this 
specification defines a usage of that framework for the publication of 
presence state [REF draft-ietf-simple-presence]..."

You shouuld add a reference to rfc2778 after "presence user agent", 
and to draft-ietf-simple-presence for the definition of presence 
agent. presence compositor is used here but not defined. Indeed, 
'presence compositor' does not appear in the definitions which follow. 
  As I believe the requiremenets and model will be folded into this 
spec, the definition shouould appear here.

* from the intro:

>    event package as defined in [1].

the comma in the midddle is not needed

* from the intro:

> It is not intended to be a
>    general-purpose mechanism for transport of arbitrary data, as there
>    are better-suited mechanisms for this purpose (FTP [6], HTTP [7],
>    etc.)

as above re: ftp, http

* in the definitions section, you offer definitions of soft and hard 
state. These are not the definitions for those terms as they are 
commonly known. I suggest you instead usue the terms "event hard 
state" and "event soft state" to match the scope of the definitions.

* section 3:

>  have multiple UAs or endpoints that publish event state. Each
>    endpoint may publish its own unique state, out of which the event
>    agent generates the composite event state of the resource.

s/event agent/event state compositor

* section 3:

> Through a
>    subscription to that event package,

"that" is a dangling reference, since you have not yet mentioned that 
publications address a resouurce and a specific event package. I 
suggest you make mention of that in the text abvoe

* section 3, para 2;

> In the generic sense, a UAC that publishes event state is labeled an
>    Event Publication Agent (EPA)

"in the generic sense" implies that there is a more specific case 
under which the definition can be understood, which is not the case. I 
suggest removing 'in the generic sense'

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

* section 3, para 3:

> Setting this hard state or
>    configuring the composer policy is out of the scope of this
>    specification.

you use the term composer here; it should be "event state compositor 
policy". I know it sounds like a real nit, but having rigorously 
consistent terminology is really important for new people to pick up 
the spec and understand it. We were religious about this in RFC 3261.

* i suggest moving section 4 to later in the spec. the reason is that 
section 4 basically gives instructions for packages to use publish, 
yet it has not said how publish works. that context will be usefull to 
interpret section 4.

* section 4.2:

> There is no such meaning for the body of a response to a presence
>    publication when the document format used is CPIM PIDF.

this implies that, in general, the meaning of the body in the response 
depends on the body in the request. the previous paragraph says that 
this is rather defined on a package by package basis. I suggest 
rermoving "when the document format used is CPIM PIDF"

* section 4.3:

> 4.3 Multple Sources for Event State

s/Multple/Multiple

* re: table 1, I suggest adding a column which is "Expires value". 
Without this, there is no way to know whether or not a publish with no 
body and a sip-if-match is refreshing or deleting.

* section 5.1:

> Identification of published event state is provided by four pieces of
>    information: Request-URI, event type, and (optionally) an entity-tag
>    and the message body.

I think its just the first three. the message body itself does not 
IDENTIFY the event state - it IS the event state. The first three 
identify it.

* section 5.2

> For determining the type of the published event state, the EPA MUST
>    include a single Event header field in the PUBLISH requests. The

s/in the PUBLISH requests/in PUBLISH requests

> The
>    value of this header field indicates the event package, for which
>    this request is publishing event state.

comma in the middle is not needed

* section 5.2:

> For each successful PUBLISH request, the ESC will generate and assign
>    an entity-tag and return it in the SIP-ETag header field of the 200
>    (OK) response.

only 200 OK? Or 2xx? I thihnk its 2xx.

* section 5.1:

> The presence of a body and the SIP-If-Match header field determine
>    the specific operation that the request is performing, as described
>    in Table 1. These operations are described in more detail in the
>    following sections.

it would probably be helpful though to say one sentence here on what 
each of these mean.

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

* section 5.2

> The EPA MAY send subsequent PUBLISH requests to refresh, modify, or
>    remove the event state established by a prior publication and
>    identified by the associated entity-tag. These operations will be
>    described in the following sections.

this paragraph is redundant. you have already said in 5.1 to see the 
sections below on how to do reefresh, modify or removal.

* section 5.3:

> PUBLISH requests SHOULD contain a single Expires header field.

i think MAY is sufficient; its a perfectly common case where the EPA 
jusut doesnt care and wants the server to tell it when to refresh.

* section 5.3:

> The actual validity period of the soft state is defined
>    by local policy at the ESC, although typically the event state is
>    cleared immediately after the publication expires.

this sentence might lead one to believe that an ESC can still keep 
around, and thus use, event state after its actual expiration. That is 
not a good thing; an ESC MUST expire event state after its expiration. 
of course this doesnt mean that the data must physically be removed 
from any dB or memory in the eSC, but rather that the ESC behaves as 
if the data has been removed.

we went through this with registrations. There are serious privacy 
implications for having the eSC in any way extend the lifetime as 
suggested by the client.

Indeed, section 5.3 shouuld say that the ESC won't ever extend the 
lifetime of the publication.

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

* section 5.4:

> Note that like any other 200 (OK) response to a PUBLISH, also this
>       response will contain a SIP-ETag header field with an entity-tag.

This is a little awkward. Suggest, "Like the 2xx rersponse to an 
initial PUBLISH request, the response to a refresh PUBLISH request 
will contain a SIP-ETag header field with an entity-tag."

* section 5.5:

> If the entity-tag matches previously
>    published event state at the ESC, that event state is replaced by the
>    event state carried in the PUBLISH request, and the EPA receives a
>    200 (OK) response.

I think we need to be really careful with the words here. What you 
have writteen actually disallows partial publication as an extension, 
wherein a UAC could send a publish that modifies a piece of the 
published state (i.e., change the note in tuple with id "3" to "out to 
lunch"). Thats because the text says the state is *replaced* by whats 
in the body. I would prefer to say that the state is updated, and that 
update depends on the content of the body. If the body contains a 
format whose semantics are 'this is the state of the resource' then 
the event state is replaced.

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

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 suggest changing section 5.8 to a top level section, section 6, 
and have this be 'processing PUBLISH responses'. it doesnt belong as a 
subsection of 5, since 5 is about generating requests. Also, sectiono 
5.8 should point to 8.1.3 of RfC 3261 and say that those steps apply.

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

* section 6:

> A client may probe the ESC for the support of PUBLISH using the
>    OPTIONS request defined in SIP [2]. In the response to such an
>    OPTIONS request, the ESC SHOULD include "PUBLISH" to the list of
>    allowed methods in the Allow header field. Also, it SHOULD list the
>    supported event packages in an Allow-Events header field.
> 
>       The "methods" Contact header field parameter may also be used to
>       specifically announce support for PUBLISH messages when
>       registering. (See SIP Capabilities [11] for details on the
>       "methods" parameter).

This bit is out of place here, since the section is about publish 
processing. youo might want to make this section 7, else have section 
6 be "ESC behavior" and then have subsections for PUBLISH and OPTIONS 
processing.

Also, the indented note is not correct. Callee caps says that the 
Allow header should be used.

* sectiono 6:

The ESC inspects the Request-URI to determine whether this
        request is targeted to a resource for which the ESC is
        responsible for maintaining event state. If not, the ESC MUST
        return a 404 (Not Found) response and skip the remaining steps.

this sounds like the publish cant be proxied, which it can. I suppose 
in such a case, its not an ESC at all, and that ESC is particularly 
something that processes the request. This should be clarified I think.

* sectiono 6, steps 2,3,4 duplicate the behavipr specified in RFC 
3261, section 8.2. I suggest referring to that section instead in the 
beginning of section 6.

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

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

* step 8:

>  *  If present, the ESC stores the event state delivered in the
>           PUBLISH request and identified by the associated entity-tag,
>           replacing any existing event state for that entity-tag.

as above - we need careful wording to allow partial publication

* step 9:

> The ESC returns a 200 (OK) response. The response MUST contain an
>        Expires header 

s/header/header field

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

* step 9:

> After returning the 200 (OK)
>        response, the state agent associated with this ESC may then issue
>        appropriate NOTIFY requests to any watchers of this event state.

terminology confusioon here. Somoetimes, event state is usued to refer 
to the inputs of composition. Other times, the unique output 
associated with the aor. Here, it explicitly refers to the output 
associated with the aor, which may not even actually change 
dependening on comoposition policy.

* good work on section 7; very concise and clear on the differences 
with http.

* section 8:

> As already explained in Section 5.3, choosing the expiration
>       interval for a publication is ultimately the ESC's responsibility,
>       and choosing longer expiration values reduces the rate at which
>       publications are refreshed.

Careful - the ESC can't extend the expiration suggested by the client. 
It can reject one that it thinks is too short, but thats not the same, 
since the client could give up at that point. So, its not under eSC 
control completely.

* section 9 isnt syntax since it defines the headers as well as the 
syntax. I would instead suggest following the pattern in rfc3261, and 
have a section that defines any additional semantics for the headers, 
methods and response codes, but has no syntax. Then, have a separate 
section just for bnf.

* on evil table 2:

              | Allow               |   2xx   |    o    |
               | Allow               |    r    |    o    |

these can be folded together

* the trend in tables 4/5 is to include columns for each method that 
has reached rfc.

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

* In the examples, I suggest not using net10. You shouold instead use 
something in 192.0.2.0/24.

* i think references 8 and 9 aree normative, since you are mandating a 
particular publication format (pidf) for usage with the presence event 
package.

Thanks,
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

_______________________________________________
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