Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt

From: [email-masked]
Date: Fri, 4 Oct 2002 09:34:33 +0100

All,

I was expecting comments similar to Adam's, and fully understand them.

However, I would support a more general version of this draft.  For
instance, the real gain I can see (as Adam says, this is only an
optimisation, which SIPPING won't allow) is that one REGISTER request does
the same thing as a REGISTER + X * SUBSCRIBE requests.  But- In the above
draft, the SIP nodes are all in the core network anyway, so this saving is
surely less valuable?

Now, in the 3GPP situation where we send SIP messages across the radio
interface, there is a strong requirement to save radio bandwidth.
Additionally, we also use the SUBSCRIBE/NOTIFY procedures for events other
than presence, so any kind of implicit subscription is attractive...

But isn't the problem with implicit subscription the fact that there is no
call-id for the NOTIFY request to use?  Is there no way around this?

Duncan

-----Original Message-----
From: Adam Roach [mailto:[email-masked]]
Sent: 03 October 2002 18:04
To: [email-masked]
Cc: [email-masked]'; [email-masked]';
[email-masked]'
Subject: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt

I have a several comments on the draft "SIP Combined Registration
and Subscription".

General Priciple:
-----------------

1) As a working group, we long ago reached the conclusion that
   combining multiple operations into a single request is a
   really bad idea, and have worked hard to avoid it. This is
   why, for example, uploading of CPL scripts in REGISTER messages
   has been depricated. Among other problems, it becomes
   impossible to describe what failed in partial-failure scenarios.

2) Another principle we have embraced is that we will design the
   tools for creating powerful services in such a way that they
   work as independantly of each other as possible. This is often
   stated as selecting generality over efficiency. This is, for
   example, why we have selected to standardize the general
   capability described by the "REFER" draft instead of the
   onetime competing proposal for a "TRANSFER" verb.

Process:
--------

Currently, the way of getting work items onto the SIP working
group agenda is to formulate a group of requirement in the
SIPPING working group, and then develop the acutal mechanism
in the SIP working group.

Specific Mechanism:
-------------------

1) It is not clear how the proposed mechanism solves the problem
   described in the introduction. However,
   the described mechanism doesn't solve this problem any better
   than a standard REGISTER and SUBSCRIBE message sent
   separately. Has there been some sort of major cut-and-paste
   error, or did I miss the linkage?

2) The draft proposes:

      This memo also proposes that a NOTIFY SHOULD not be sent      
      immediately on receiving the REGISTER, since the proxy UA would      
      have all the required information on presence, or would get it in
      the 200 OK response. So a NOTIFY SHOULD only be sent when the      
      presence information changes like when the old contact is removed,

      or a new contact address is added,  the old contact SHOULD to be      
      informed of this change.

   Unfortunately, this isn't a workable solution. The immediate NOTIFY
   was placed in RFC3265 quite purposefully to solve a wide variety
   of problems. Forking of requests is the most obvious, but it serves
   other important purposes, such as communicating the state of the
   subscription itself (in addition to the resource), and providing
   a final negotiated expiration time.

3) In many, if not most, cases, the subscriber will want information
   about more than one resource (that is, he will want to subscribe
   to more than one resouce, and often, more than one type of event
   package). It is not clear how the proposed mechanism could
   handle this case.

4) One of the more important bits of information when subscribing
   for presence is the identity contained in the Request-URI.
   However, for REGISTER messages, this Request-URI is required
   to contain the identity of the registrar. It is highly
   doubtful that the intention is to subscribe to the presence
   of the registrar. So, from the current description, it
   is not clear at all to which resource the subscription would be.

/a
_______________________________________________
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
_______________________________________________
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

---

From: "Stephen James" <[email-masked]>
Date: Fri, 4 Oct 2002 07:43:45 -0500

What is the general opinion or policy on using the Content of the REGISTER
for this? Supposedly, the Regstrar in this case is expected to have extended
functionality to support combined REGISTER/SUBSCRIBE, could the a new
content type be developed for Subscriptions that could be contained in the
REGISTER message. By placing such elements as Subscription Call-ID and
request URL into this new content type, some of the problems described below
could be circumvented.

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, October 04, 2002 3:34 AM
Subject: RE: [Sip] Comments on draft-idnani-sip-comb-reg-subscr-00.txt

---

From: Ben Campbell <[email-masked]>
Date: Fri, 04 Oct 2002 14:21:07 -0500

> draft, the SIP nodes are all in the core network anyway, so this saving is

Having a single request perform multiple, otherwise orthagonal, 
operations is a recipe for trouble. You get into situations where one 
operation succeeds, and another fails. There is no way to communicate 
compound results like that back to the requestor.

If you are concerned about the X * subscribe issue for situations where 
you are subscribing to a large number of resources (common for presence 
applications, I suggest you look at the collections draft and related 
discussion instead. If instead, you are concerned about the idea of 
sending a few SUBSCRIBEs for different purposes (i.e. different event 
packages) then I think the added complexity and brittleness introduced 
by combining the operations greatly outweighs the gain of saving a small 
number of transactions.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Oct 2002 22:50:14 -0400

> request URL into this new content type, some of the problems described below

This is effectively tunneling SIP in SIP. I don't see the benefit of 
that. It has none of the "overhead" reduction benefits that the draft is 
aiming for, but breaks interoperability by effectively defining a new 
protocol.

To address the original proposal, I do not think it is a good idea to 
combine REGISTER and SUBSCRIBE. Adam makes many good points on the 
problems associated with this idea. Some additional ones to consider:

* The accept header indicates body types that the UA can accept. In 
SUBSCRIBE, it refers to allowed body types in NOTIFY, in REGISTER, to 
allowed body types in the response. When present in a "combined" 
SUBSCRIBE/REGISTER, there would be no way to know which one it refers 
to. It is very possible that certain types would be supported for one 
case and not the other.

* Same as above for accept-encoding.

* the client has no way to know whether the resource that the UA wants 
to subscribe to is available from the registrar. This will lead to 
frequent "guess-and-check" attempts that are wasteful.

* a user might be authorized to register, but not authorized to 
subscribe to a resource. There is no way to differentiate which is the 
case based on the response code (this is one example of the failure 
problem that Adam points out).

There are other problems; these are just a few I came up with.

I'll also note this tidbit in the draft:
> Notice Regarding Intellectual Property Rights
> 
>    The IETF has been notified of intellectual property rights claimed 
>    in regard to some or all of the specification contained in this 
>    document.  For more information consult the online list of claimed 
>    rights

I am reluctant to pursue patented technologies generally; I am less 
interested in doing so to define optimizations that introduce many new 
problems.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 7 Oct 2002 15:15:24 -0500

Duncan wrote:
> However, I would support a more general version of this 
> draft.  For instance, the real gain I can see (as Adam says, 
> this is only an optimisation, which SIPPING won't allow) is 
> that one REGISTER request does the same thing as a REGISTER + 
> X * SUBSCRIBE requests.  But- In the above draft, the SIP 
> nodes are all in the core network anyway, so this saving is 
> surely less valuable?
> 
> Now, in the 3GPP situation where we send SIP messages across 
> the radio interface, there is a strong requirement to save 
> radio bandwidth. Additionally, we also use the 
> SUBSCRIBE/NOTIFY procedures for events other than presence, 
> so any kind of implicit subscription is attractive...

Perhaps I'm confused about something, but as I recall, the things in IMS
being subscibed to via SUBSCRIBE are not served from the registrar that
services the REGISTER request. In other words, the SUBSCRIBEs don't go
to the same destinations as do the REGISTERs, so combining them doesn't
seem to make a lot of sense in any case. We should have called REGISTER
something like "SETCONTACT" -- it would have avoided a lot of this
discussion.

It would seem far more effective to use a server process that aggregates
notifications and subscriptions, as is done in the "presencelist" work.
In this model one subscribes to a list served by a server, then that
server subscribes to each element of the list, aggregates state, and
filters and returns appropriate notifications to the subscriber thereby
reducing over-the-air traffic tremendously. This effectively replaces
many SUBSCRIBEs with one SUBSCRIBs, and may replace many NOTIFYs with
fewer NOTIFYs, depending on how thoseare handled.
 
> But isn't the problem with implicit subscription the fact 
> that there is no call-id for the NOTIFY request to use?  Is 
> there no way around this?

That's one problem. There are also issues with knowing how to filter
notifications and how to negotiate whether implicit subscription is
supported and lots of other things. We had not finished enumerating the
issues before deciding implicit subscriptions were just dangerous.

--
Dean