Subject: [Simple] WG call for comment: Auth48 changes to winfo-package

From: Robert Sparks <[email-masked]>
Date: Wed, 28 Jul 2004 19:41:05 -0500

Folks -

Celebration is in order!

The core set of drafts are finally working their way out
of the process. 

We've had many months since IESG approval to acquire feedback on these
drafts. Time has told us that we did a very good job - most
of them require very little tweaking.

-winfo-package got some feedback that suggests adding several
words. The meaning doesn't change, but there have been good
points brought forth for clarification. We need, as a group,
to look through the new words and verify that this is what we've
agreed to say.

Jonathan will post the proposed edits that add significant
text shortly (there are the usual editorial fixes, but we
do not need to review those here). Please send a note to the
list confirming your agreement with them before Aug 7.

Thanks,

RjS

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Jul 2004 07:07:02 -0400

Folks,

Here are the changes I think need to be made to the document. Mostly 
they are clarifications. Two of the changes are based on some brief 
email exchanges that occurred while the docs were sitting with 
rfc-editor. Those changes deal with two issues that were raised:

1. When someone does a fetch, the subscription FSM is created, goes into 
the active state and then is immmediately terminated and destoryed. You 
don't want to get notifications for each of these transitions, and this 
was raised on the list. So, text has been added saying that you SHOULD 
NOT send notifications in transient states.

2. The current document has a transition from waiting back to pending in 
the case where the subscription comes back. But, it never will; it would 
show up as a new subscription that goes into pending. As such, the 
transition from waiting back to pending was removed. Instead, when 
another subscription arrives, you can remove the one in the waiting 
state, and that is described.

Below are the set of proposed diffs to reflect these two issues plus 
general clarifications:

Section 1, first paragraph:

OLD:

The SIP event framework is described in RFC 3265 [1].  It defines a

NEW:

The Session Initiation Protocol (SIP) event framework is described in
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RFC 3265 [1].  It defines a

Section 2, second paragraph:

OLD:

the "inner" subscribers, subscriptions, and notifications - those

NEW:

the "inner" subscriptions, subscribers and notifications - those
             ^^^^^^^^^^^^^^^^^^^^^^^^^^

Section 3.1, first paragraph:

OLD:

The motivating application for this package is presence

NEW:

The motivating application for this template-package is presence
                                     ^^^^^^^^^

Section 4.4, second paragraph:

OLD:

  how long a user maintains its subscription.  Typically, watcherinfo
    subscriptions will be timed to span the lifetime of the subscriptions
    being watcher, and therefore range from minutes to days.

NEW:

  how long a user maintains its subscription.  Typically, watcherinfo
    subscriptions will be timed to span the lifetime of the subscriptions
    being watched, and therefore range from minutes to days.
                ^

Section 4.5, second paragraph:

OLD:

The body of the watcherinfo notification contains a watcher
    information document.  This document describes some or all of the
    watchers for a given package, and the state of their subscriptions.

NEW:

The body of the watcherinfo notification contains a watcher
    information document.  This document describes some or all of the
    watchers for a resource within a given package, and the state of
             ^^^^^^^^^^^^^^^^^^^^^
their subscriptions.

Section 4.7, second paragraph:

OLD:

Watcherinfo notifications MAY be generated for watcher information on
    package foo, when the subscription state for a user on package foo
    changes. The watcher information package therefore needs a model of
    subscription state.

NEW (add text and split into two paragraphs):

Each watcherinfo subscription is associated with a set of "inner" 
subscriptions being watched. This set is defined by the URI in the 
Request URI of the watcherinfo SUBSCRIBE request, along with the parent 
event package of the watcherinfo subscription. The parent event package 
is obtained by removing the trailing ".winfo" from the value of the 
Event header field from the watcherinfo SUBSCRIBE request. If the Event 
header field in the watcherinfo subscription has a value of 
"presence.winfo", the parent event package is "presence". If the Event 
header field has a value of "presence.winfo.winfo", the parent event 
package is "presence.winfo". Normally, the URI in the Request URI of the 
watcherinfo SUBSCRIBE identifies an address-of-record within the domain. 
In that case, the set of subscriptions to be watched are all of the 
subscriptions for the parent event package that have been made to the 
resource in the Request URI of the watcherinfo SUBSCRIBE. However, the 
Request URI can contin a URI that defines a larger collection of 
resources. For example, sip:[email-masked] might be defined 
within example.com to refer to all resources. In that case, a 
watcherinfo subscription for "presence.winfo" to 
sip:[email-masked] is requesting notifications any time the 
state of any presence subscription for any resource within example.com 
changes. A watcherinfo notifier MAY generate a notification any time the 
state of any of the watched subscriptions changes.

Because a watcherinfo subscription is made to a collection of 
subscriptions, the watcher information package needs a model of 
subscription state.

Section 4.7.1, second paragraph:

OLD:

Initially, there is no state allocated for a subscription (the init
    state).  When a SUBSCRIBE request arrives, the subscription FSM is
    created.

NEW:

When a SUBSCRIBE request arrives, the subscription FSM is created in the 
init state. This state is transient.

Section 4.7.1, last paragraph on page 9:

OLD:

The waiting state is similar to pending, in that no notifications are
    generated.  However, if the subscription is approved or denied, the
    FSM is destroyed.

NEW:

The waiting state is similar to pending, in that no notifications are
    generated.  However, if the subscription is approved or denied, the
    FSM enters the terminated state, and is destroyed. Furthermore, if 
another subscription is received to the same resource, from the same 
watcher, for the same event package, event package parameters and filter 
in the body of the SUBSCRIBE request (if one was present initially), the 
FSM enters the terminated state with a "giveup" event, and is destroyed. 
This transition occurs because, on arrival of a new subscription with 
identical parameters, it will enter the pending state, making the 
waiting state for the prior subscription redundant.

Section 4.7.1, figure 1:

replace figure with this (transition from waiting to pending has been 
removed):

        subscribe,
        policy=       +----------+
        reject        |          |<------------------------+
        +------------>|terminated|<---------+              |
        |             |          |          |              |
        |             |          |          |noresource    |
        |             +----------+          |rejected      |
        |                  ^noresource      |deactivated   |
        |                  |rejected        |probation     |
        |                  |deactivated     |timeout       |noresource
        |                  |probation       |              |rejected
        |                  |giveup          |              |giveup
        |                  |                |              |approved
     +-------+         +-------+        +-------+          |
     |       |subscribe|       |approved|       |          |
     | init  |-------->|pending|------->|active |          |
     |       |no policy|       |        |       |          |
     |       |         |       |        |       |          |
     +-------+         +-------+        +-------+          |
        |                  |                ^              |
        | subscribe,       |                |              |
        +-----------------------------------+              |
          policy = accept  |            +-------+          |
                           |            |       |          |
                           |            |waiting|----------+
                           +----------->|       |
                            timeout     |       |
                                        +-------+

Section 4.7.1, bottom of page 10:

OLD:

Of course, policy may never be specified for the subscription.  As a
    result, the server can generate a giveup event to move the waiting
    subscription to the terminated state.  The amount of time to wait
    before issuing a giveup event is system dependent.  If, while in the
    waiting state, the subscription is refreshed through another
    SUBSCRIBE, it moves back into the pending state.

NEW (delete last sentence):

Of course, policy may never be specified for the subscription.  As a
    result, the server can generate a giveup event to move the waiting
    subscription to the terminated state.  The amount of time to wait
    before issuing a giveup event is system dependent.

Section 4.7.1, last paragraph page 10:

OLD:

The giveup event is generated in either the waiting or pending states
    to destroy resources associated with unauthorized subscriptions.

NEW:

The giveup event is generated in either the waiting or pending states
    to destroy resources associated with unauthorized subscriptions. 
This event is generated when a giveup timer fires. This timer is set to 
a timeout value when entering either the pending or waiting states.

Section 4.7.1, first paragraph page 11:

OLD:

that servers, which retain state for unauthorized subscriptions, add
    policies which prohibit a particular subscriber from having more than
    some number of pending or waiting subscriptions.

NEW:

that servers that retain state for unauthorized subscriptions add
             ^^^^^                                            ^
    policies which prohibit a particular subscriber from having more than
    some number of pending or waiting subscriptions.

Section 4.7.2:

Add this as the last paragraph in the section:

Frequently, states in the subscription state machine will be transient. 
For example, if an authorized watcher performs a fetch operation, this 
will cause the state machine to be created, transition from init to 
active, and then from active to terminated, followed by a destruction of 
the FSM. In such cases, watcherinfo notifications SHOULD NOT be sent for 
any transient states. In the prior example, the server wouldn't send any 
notifications, since all of the states are transient.

Section 5, last message on page 14:

OLD:

    NOTIFY sip:[email-masked] SIP/2.0
    Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
    From: sip:[email-masked];tag=xyzygg
    To: sip:[email-masked];tag=123aa9
    Call-ID: [email-masked]
    CSeq: 1288 NOTIFY
    Contact: sip:server19.example.com
    Event: presence.winfo
    Max-Forwards: 70
    Content-Type: application/watcherinfo+xml
    Content-Length: ...

NEW:

    NOTIFY sip:[email-masked] SIP/2.0
    Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
    From: sip:[email-masked];tag=xyzygg
    To: sip:[email-masked];tag=123aa9
    Call-ID: [email-masked]
    CSeq: 1288 NOTIFY
    Contact: sip:server19.example.com
    Event: presence.winfo
    Subscription-State: active
    Max-Forwards: 70
    Content-Type: application/watcherinfo+xml
    Content-Length: ...

Section 5, last message on page 15:

OLD:

    NOTIFY sip:[email-masked] SIP/2.0
    Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
    From: sip:[email-masked];tag=xyzygg
    To: sip:[email-masked];tag=123aa9
    Call-ID: [email-masked]
    CSeq: 1289 NOTIFY
    Contact: sip:server19.example.com
    Event: presence.winfo
    Max-Forwards: 70
    Content-Type: application/watcherinfo+xml
    Content-Length: ...

NEW (add Subsription-State header):

    NOTIFY sip:[email-masked] SIP/2.0
    Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
    From: sip:[email-masked];tag=xyzygg
    To: sip:[email-masked];tag=123aa9
    Call-ID: [email-masked]
    CSeq: 1289 NOTIFY
    Contact: sip:server19.example.com
    Event: presence.winfo
    Subscription-State: active
    Max-Forwards: 70
    Content-Type: application/watcherinfo+xml
    Content-Length: ...

Section 6.2, second paragraph:

OLD:

information.  To prevent that, watchers MAY use the SIPS scheme when
    subscribing to a watcherinfo resource.  Notifiers for watcherinfo
    MUST support TLS and SIPS as if they were a proxy (see Section 26.3.1
    of RFC 3261).

NEW:

information.  To prevent that, watchers MAY use the sips URI scheme when
                                                     ^^^^^^^^
    subscribing to a watcherinfo resource.  Notifiers for watcherinfo
    MUST support TLS and sips as if they were a proxy (see Section 26.3.1
                         ^^^^
    of RFC 3261).

Section 11, authors address:

OLD:

Jonathan Rosenberg
    dynamicsoft
    72 Eagle Rock Avenue
    First Floor
    East Hanover, NJ 07936

NEW:

Jonathan Rosenberg
    dynamicsoft
    600 Lanidex Plaza
    Parsippany, NJ 07054

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 30 Jul 2004 09:38:33 -0500

I agree with all the changes, with one question below:

On Jul 29, 2004, at 6:07 AM, Jonathan Rosenberg wrote:

[...]
> Request URI of the watcherinfo SUBSCRIBE request, along with the 
> parent event package of the watcherinfo subscription. The parent event 
> package is obtained by removing the trailing ".winfo" from the value 
> of the Event header field from the watcherinfo SUBSCRIBE request. If 
> the Event header field in the watcherinfo subscription has a value of 
> package is "presence.winfo". Normally, the URI in the Request URI of 
> the watcherinfo SUBSCRIBE identifies an address-of-record within the 
> domain. In that case, the set of subscriptions to be watched are all 
> of the subscriptions for the parent event package that have been made 
> to the resource in the Request URI of the watcherinfo SUBSCRIBE. 
> However, the Request URI can contin a URI that defines a larger 
> collection of resources. For example, sip:[email-masked] 
> might be defined within example.com to refer to all resources. In that 
> case, a watcherinfo subscription for "presence.winfo" to 
> changes. A watcherinfo notifier MAY generate a notification any time 
> the state of any of the watched subscriptions changes.
>

Do you mean to only allow winfo subscriptions to _larger_ scopes that 
"all subscribers to a resource?" Is it possible to have something like 
"sip:[email-masked]" that only tells me about watchers 
in the AoL domain, but not watchers from some other domain?

(I am not expressing a strong feeling that this is needed; I am only 
trying to understand the intent.)

> subscriptions, the watcher information package needs a model of 

[...]