Subject: [Sipping] I-D ACTION:draft-ietf-sipping-uri-list-subscribe-02.txt

From: [email-masked]
Date: Tue, 11 Jan 2005 15:38:09 -0500

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

	Title		: Subscriptions to Request-Contained Resource Lists in 
			  the Session Initiation Protocol (SIP)
	Author(s)	: G. Camarillo, et al.
	Filename	: draft-ietf-sipping-uri-list-subscribe-02.txt
	Pages		: 9
	Date		: 2005-1-11
	
This document specifies a way to create subscription to a list of
   resources in SIP.  This is achieved by including the list of
   resources in the body of a SUBSCRIBE.  Instead of having a subscriber
   send a SUBSCRIBE for each resource individually, the subscriber
   defines the resource list, subscribes to it, and gets notifications
   about changes in the resources' state using a single SUBSCRIBE
   dialog.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-list-subscribe-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-sipping-uri-list-subscribe-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-sipping-uri-list-subscribe-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.
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Jan 2005 09:52:05 -0500

Section 6 says:

    A resource list server receiving a subsequent SUBSCRIBE request with
    a resource-list body, following standard SIP procedures, rejects it
    with a 415 (Unsupported Media Type) response.

This seems to be stretching the meaning of 415. With a 415 you are 
supposed to list the media types that you support. I don't think the 
server can honestly report that it doesn't support the media type - it 
does, but just not in this context.

The text tries to explain its way out of this with the following:

       Note that a difference between an initial SUBSCRIBE request and
       subsequent ones is that while the initial request is sent to the
       public URI of the resource list, subsequent ones are sent to the
       URI provided by the server when the dialog was established.
       Therefore, from the client's point of view, the resource
       identified by the former URI supports recipient-list bodies while
       the resource identified by the latter does not support them.

But this doesn't really hold water. There is no guarantee that the 
initial subscribe request is sent to a different address than the 
resubscribe. (It is entirely possible that the watcher had the contact 
address at the time of the initial subscription. And in any case the 
entity the subscription is with is determined by the response to the 
initial subscribe.

With the proposed new Accept-Disposition header, I suppose it could 
report that it doesn't support "recipient-list" disposition. But that 
suffers from the same problem - the lack of support is contextual.

As it stands, it would be reasonable for the watcher to conclude that 
this peer no longer supports this feature.

I think we need a new way to reflect that something isn't accepted for 
contextual reasons. Perhaps this could be handled with a Reason code in 
addition to the 415.

Or - the scope of Accept-* headers has never been specified. We could 
clarify some relationship between this and dialogs, though that would 
cause problems with its use outside dialogs, such as in OPTIONS.

	Paul