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

From: [email-masked]
Date: Thu, 11 Sep 2003 14:50:17 -0400

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-00.txt
	Pages		: 32
	Date		: 2003-9-11
	
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-00.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-00.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-00.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: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Sep 2003 14:32:05 -0400

I'm sorry to be late with comments on this draft - it just slipped down 
the priority queue until I saw the proposal for last call.

Below are a number of comments.

	Paul

Section 3:

Last sentence  says "Both the source and the target of the
publication are naturally represented as an address-of-record.")

I don't think this is right. At least it is no more true than saying
"Both the source and the target of an invitation are naturally
represented as an address-of-record."

This is especially a problem for the source of publication. Certainly
the source isn't *uniquely* represented by an AOR - in typical cases
there may be many sources that all share an AOR. Nor is it necessary for
the source to have any AOR at all.

The statement is closer to true for the target. I think we all expect
the typical usage to be that PUBLISH requests are aimed at an AOR and
then routed to an appropriate contact address by a proxy. But of course
this usage isn't required, any more than it is with invite. And while we
may understand expected typical usage with presence, different patterns
may be appropriate for other event packages.

I'm not convinced that it is necessary to replace this sentence with
anything. If you feel a need to say something, how about:

"Often, publication requests will originate from endpoints associated
with an address-of-record and be directed to that address-of-record."

-----

Section 5:

    Request-URI: The Request-URI initially contains the address-of-record
       whose publication is to be created, removed, or modified. The
       address-of-record MUST be a SIP URI or SIPS URI. Unlike the
       REGISTER request, the Request-URI SHOULD contain both "userinfo"
       and "@" components.

I see no reason for this. The request-uri is all about routing, and 
routing is fully specified in 3261. There is no reason to muck with this 
here. By the time the request arrives, the request-uri won't contain an 
AOR. Whether it had one initially or not is of no consequence. The ESC 
must decide what presence document to operate on based on the content of 
the message received. This decision will presumably be made based on the 
request-uri at that time, together with the presumed association of that 
with a particular AOR/presence document. (Or maybe it will be made based 
on the content of the To field.)

-----

Section 5:

    To: The To header field contains the address-of-record whose
       publication is to be created, removed, or modified. The To header
       field and the Request-URI field are typically the same. This
       address-of-record MUST be a SIP URI or SIPS URI.

I think there is some question whether the To should be used to select 
the presence doc or whether the request uri should be used. It depends 
on what we expect to happen in the case of forwarding.

Suppose sip:[email-masked] forwards everything to sip:[email-masked]. 
Then suppose something sends a PUBLISH to alice. This will get forwarded 
to the ESC registed for bob. Now, does it refuse the request because the 
To references alice, or does it update the presence of bob? I haven't 
decided what I think the right answer is. But I think it ought to be 
consistent with what happens to SUBSCRIBE requests addressed to alice.

-----

Section 6:

    The Event State Compositor (ESC) is a UAS that processes and responds
    to PUBLISH requests, and maintains a list of publications for a given
    address-of-record. The ESC has to know (e.g., through configuration)
    the domain or set of domains for which it maintains event state.

This makes an assumption that a given ESC is responsible for a domain or 
domains. This need not be the case. It may simply be responsible for a 
few specific users. Proxy routing logic can get things to the right ESC. 
I think this could be reworded as:

"The ESC has to know (e.g., through configuration) the set of addresses 
for which it maintains event state."

-----

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.

It may be tricky to get this to work. If the ESC is itself registered as 
one of the contacts of the AOR, then a straightforward OPTIONS will 
fork, and only the first response will get back. That might not be from 
the ESC.

To get around that, it may be necessary to use callerprefs to direct the 
OPTIONS to the ESC, perhaps via something like:

	OPTIONS sip:user@domain
	To: sip:user@domain
	From: sip:somebody@domain
	Accept-Contact: *;methods="SUBSCRIBE";events="presence"

Having said that, I don't know how much of it needs to be in the spec. 
Maybe just a warning.

------

Section 6:

    1.   The ESC inspects the Request-URI to determine whether this
         request is for a domain supported by the ESC. If not, the ESC
         SHOULD proxy the request to the addressed domain.

The ESC is a UA. UAs are typically not required to act as proxies. In 
any case, this bullet is all about standard 3261 behavior. Don't think 
it needs to be said.

-------

Section 6:

    4.   The ESC SHOULD determine if the authenticated user is authorized
         to perform event state publication for the address-of-record of
         the To header field.

This goes to my question above about whether selection of the 
presentity/presence document should be based on the request uri or 
To-uri. Here it clearly specifys this.

The problem with this is that I don't believe it is consistent with 
SUBSCRIBE.

-------

Section 6:

    5.   The ESC extracts the address-of-record from the To header field
         of the request.  If the address-of-record is not valid for the
         domain in the Request-URI, the ESC MUST send a 404 (Not Found)
         response and skip the remaining steps.

Again I think this is over specifying. There need not be any specific 
relationship between the domain in the request uri and the domain in the 
To uri, though there often will be. But it could be completely 
reasonable for some server at sip:presenceRus.com to act as an ESC for 
users in any number of domains.

*If* the To address is to be used for choosing the presence document to 
be affected, it would be better to say:

"The ESC extracts the address-of-record from the To header field of the 
request. If the ESC does not manage event state for this address, it 
MUST send a 404 (Not Found) response and skip the remaining steps."

[THE END]

_______________________________________________
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