Subject: [Sip] Reminder: SIP Events WGLC Ending Soon!

From: "Schulz, Eric" <[email-masked]>
Date: Fri, 15 Feb 2002 17:52:42 -0800

Not exactly the thorough review you requested but I did notice the following...

-	In the 7th paragraph of section 4.3.4, "Expiration" should be "Expires"
-	In the 4th paragraph of section 4.3.6, "Expire" should be "Expires"

-Eric

	From:	Adam Roach <[email-masked]>

	The Working Group Last Call for the SIP Events draft is
	ending on Tuesday. So far, only two people have commented
	on it (thanks, Bob and Bert).

	I urge anyone with a stake in this mechanism to give the
	document a thorough review over the weekend, and post
	comments on Monday. I'll be kicking out a new version on
	Tuesday, which will immediately enter IETF Last Call.

	The latest version of the document is available at:
	<http://www.ietf.org/internet-drafts/draft-ietf-sip-events-02.txt>
	and in a PDF-version (with changebars) at:
	<http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-02.pdf>

	/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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sun, 17 Feb 2002 15:11:14 -0800

Hi Adam,

Comments on SIP-Events-02 draft:

The Subscription-State header is a great improvement! 

Okay here are a few comments regarding error-reasons. This continues on from
a discussion of error reasons from last year. Unfortunately I went away for
a over a month in late December-January before Jonathan posted his response
to my last email and the discussion was never concluded.

I have included the last post on the thread "Alignment of sip-events and
watcherinfo" on the 19th December 2001 at the bottom. 

Basically I disagree with Jonathan that all of error-reasons should be
clumped into the "rejected". Currently "rejected" covers:
- initial authorization failed
- authorization failed at a later time due to change authorization policy 
- Event resource does not exists
- Event resource no longer exists

Now of course it is just an error-reason and so nothing is technically
incorrect however I feel "rejected" is overloaded and that some subscribers
would benefit from knowing the difference between these categories.

My suggestion is that the following error-reason is needed:

--
"noresource": The subscription has been terminated because the resource
identified by the request-uri and/or the SUBSCRIBE request's message body is
unknown or is indefinitely unavailable. Clients SHOULD NOT attempt to
re-subscribe unless a "retry-after" parameter is also present.
--

This reason is _quite_ different to the "rejected" description - it has
nothing to do with authorization. A notifier is not required to send a
terminate a subscription because a resource does not exist _NOW_ but in many
cases it does make sense to do this and it needs a proper error-reason. I
don't see that what Jonathan was saying is contrary to this however I
disagree that the notifier should report the termination as a failure due to
an authorization policy change in my mind - it has nothing to do with
authorization - it is a function of the resource.

I think this distinct IS important and should be included in the draft.

Other comments: This is only a small nit but I think the "rejected" reason
comment in 4.2.4 should be changed to state that the termination is due to a
initial authorization failure OR a change in the authorization policy. It
currently only says that the error-reason covers the later reason.

Cheers,

Robert.

----

Reproduced email ....

From: Jonathan Rosenberg [[email-masked]]
Sent: 19 December 2001 19:56
To: Brian Stucker
Cc: 'Fairlie-Cuninghame, Robert'; [email-masked];
[email-masked]
Subject: Re: [Sip] FW: [Simple] Alignment of sip-events and watcherinfo

Brian Stucker wrote:

 >
 >> -----Original Message-----  From: Fairlie-Cuninghame, Robert [
 >> mailto:[email-masked]]  Sent: Monday, December 10, 2001 6:48
 >> PM  To: 'Jonathan Rosenberg'; [email-masked]'  Cc:
 >> [email-masked]'  Subject: RE: [Sip] FW: [Simple]
 >>  Alignment of sip-events and  watcherinfo
 >>

 >> Thus both the terminated & pending reason causes should be 
Subscription-Expire
 >>  reasons and not solely contained in the  Event package  bodies
 >> themselves.
 >>
 >
 > A subscription can be pending to an active resource, or pending to a
 >  pending resource. The two are distinct. They are separate finite
 > state machines, and thus should be processed separately. The state
 > that the subscription is in has nothing at all to do with the state
 >  of the resource on a basic level. The resource may cause the
 > subscription to be handled differently, for sure, but at a generic
 > sip-events level, there is no coupling in my mind.

Right, I agree with Brian.

Another point to show the decoupling. Robert, you used the case of a 
concert which has a finite start and end time, and argued that when the 
concert ended, so should the subscription. However, I can think of a few 
cases where there are useful cases for subscriptions to events that have 
ended like this:

1. for periodic or recurring events, I may want my subscription to be 
maintained until the next occurrence. I see no reason to differentiate 
subscription processing for objects that exist just once than for 
objects that exist periodically.

2. Even after the object has expired, I might like to know that, and so 
one could imagine useful cases for fetching the state after the object 
has expired, to learn just that - that is has expired. Fetching is 
nothing more than subscribing for an infintesimally small duration, so 
we are talking about subscriptions to an object that "does not exist 
anymore", but it still sensible to have a subscription to it.

Robert suggested some more reason values:

> 
> I made a couple in my last email (some of which you have already covered):
> 
> 	- Terminated/rejected because authorization failed

Thats covered by "rejected"

> 	- Terminated because subscribed object terminated

See above; I would argue that if the server wants to terminate the 
subscription because the object has entered a state that will no longer 
generate events, thats really just a change in authorization policy and 
would be covered by "rejected" as well.

> 	- Terminated because subscriber requested termination.

Since termination of a subscription is done through expires=0, this is 
the same as "timeout".

> 	- Expired. Subscriber did not refresh subscription.

"timeout"

> 	- Terminated at request of notifier.
> 

Changes in authorization policy -> "rejected".

-Jonathan R.

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

---

From: "James Undery" <[email-masked]>
Date: Mon, 18 Feb 2002 16:00:04 -0000

Hi,

Here's a hodge podge of comments sorry it's so late. (I've tried to
avoid duplicates of previous posters but they may crop up)

3. State Agent; s/Agent/agent/ in description only for consistency.

4.1.1. 3rd para. Requirement of a Expires header in a 200-class response
not reflected in 7.4. 

4.1.1. 5th para. Using Expires of zero is also a fetch operation because
of 4.1.4.1. (same comment for 4.1.4.3.) closely related to 4.3.6 might
be worth bringing these sections together.

4.2.2 1st para. s/is/are/ to match rules

4.3.4. 7th para. Inconsistent placement of punctuation wrt quotes (and
won't get into the quotes as it's a style thing).

4.3.5. 1st para. Inconsistent quoting s/"NOTIFY"/NOTIFY/

5.2. 4th para. Inconsistent placement of punctuation wrt quotes
(Although this is a confusing case to use the American version)

5.3.2. 4th para. State Deltas if a subscriber has missed sequence
numbers surely the subscription will have been silently cancelled ala
4.2.2. (Not sure this is a nit or me thinking aloud)

5.4. 2nd para s/changed/weakened/ 

5.4.7. 1st para. It may be worth noting explicitly that "fake" or
"neutral" state information isn't required

5.4.7. 2nd para. Missing ".." ;-)

5.4.9. 2nd para. Inconsistent quoting, the header values haven't been
quoted

5.4.11. 1st para. s/"State Agent"/state agent/

6.1. s/user/resource/ (also section 3 might do with a consistent name
for the entity the state describes)

6.3. 3rd para. s/of notifiers/accepting subscriptions/

7. Ensure first bracketed sentence goes

7. last para. Inconsistent placement of punctuation wrt quotes 

7.4. s/"NOTIFY"/NOTIFY/ s/"SUBSCRIBE"/SUBSCRIBE/

7.4. Should Allow-Events be mandatory in 2xx responses to an OPTIONS

7.4. Why isn't Accept "m*" for SUBSCRIBE

4.6.1. Reference [4] rfc2616 might be a better choice

James

---

From: Adam Roach <[email-masked]>
Date: Mon, 18 Feb 2002 14:02:51 -0500

> - Event resource no longer exists

I believe a "reason" code could only conceivably cover the second
and fourth cases. In the first and third cases, you would never
get as far as a NOTIFY; the SUBSCRIBE would be answered with a
suitable error code, and no NOTIFY would ever be sent.

> My suggestion is that the following error-reason is needed:

I'll wait for Jonathan to reply before taking action. While I
agree that the distinction you make is useful, I think it's far, far
more important to have sip-events synced with watcherinfo than it is
to have another reason code for this case.

> currently only says that the error-reason covers the later reason.

As I point out above, "reason" could never apply due to an
initial authorization failure; if a user is not authorized at
the time of subscription (and the notifier is going to let
the subscriber know of such a failure), the SUBSCRIBE is answered
with a "403 Forbidden." If the SUBSCRIBE isn't answered with a 403,
then any authorization-related event that causes the subscription
to be rejected later is, by definition, a change in authorization
policy.

Thanks for reading over the draft!

/a

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 18 Feb 2002 11:19:27 -0800

Hi Adam,

> suitable error code, and no NOTIFY would ever be sent.

This assumes that authorization and resource location occurs instantaneously
- which cannot be assumed. If either of these operations take non-negligible
time then the Notifier MUST send an immediate NOTIFY (which
"Subscription-State: pending"). You therefore needs an appropriate terminate
reason-code - the SUBSCRIBE response codes cannot be used for this.

Regards,

Robert.

---

From: Adam Roach <[email-masked]>
Date: Mon, 18 Feb 2002 18:03:44 -0500

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]

Going from "pending" (which means that authorization state
is undefined -- user is neither authorized nor forbiddden) to
"terminated" with reason of "rejected" (which means that
authorization is forbidden) *is* a change in authorization
state: from undefined to forbidden.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 18 Feb 2002 17:59:36 -0500

Thanks for the detailed comments. I've incorporated them, except
as noted below. A few responses:

> From: James Undery [mailto:[email-masked]]

Removal of a subscription on timeout is a SHOULD, not a MUST...
so, the simple answer is "no."

> "neutral" state information isn't required

Actually, I think it is. The need to provide this sort of
authentication hiding comes down more to a policy decision
that will be made on a per-deployment basis than a package-
related attribute that a package author can decide to neglect.

> for the entity the state describes)

Actually, we really mean user. Human. The person who owns the
resource, not the resource itself. It's an important distinction.

> 6.3. 3rd para. s/of notifiers/accepting subscriptions/

Notifiers is a defined term; we describe accepting
SUBSCRIBE messages in the definition of a notifier.
I think your suggested change would actually cause more
confusion than it avoids.

> 7. Ensure first bracketed sentence goes

The actual e-mail address and policy for IANA registration
will be decided by IANA review. Presumably, the disclaimer
will be removed at that point in the process. Thanks for the
reminder, though.

> 7.4. Should Allow-Events be mandatory in 2xx responses to an OPTIONS

Only sort of. When interacting with UAs not supporting SIP-Events,
you won't see "Allow-Events" in OPTIONS responses. Putting an "m"
in the table would imply a global change.

> 7.4. Why isn't Accept "m*" for SUBSCRIBE

Because not all event packages will define bodies for
conveying state.

> 4.6.1. Reference [4] rfc2616 might be a better choice

Whoa! Good catch! I don't know how I got the obsoleted spec #
in there...

/a

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 18 Feb 2002 15:36:16 -0800

> state: from undefined to forbidden.

Adam,

Two cases:

* using "rejected" due to the failure of authorization: sure it is a change
in authorization _state_ but the description for "rejected" says that the
error-reason is used when there is a change in authorization _policy_. I'm
sure you can justify this by your definition of authorization policy but I
think it is confusing and should be reworded to more clearly state that
"rejected" also covers the initial authorization failure case.

* using "rejected" to cover unavailable/non-existing resource: I think this
is just plain wrong. It has nothing to do with authorization policy;
resubscribing with new credentials will not improve the situation - the
resource is unavailable. Hence, my proposal to introduce the "noresource"
error-reason. Subscriber response codes are not sufficient as resource
location is not necessarily a synchronous operation.

Cheers,

Robert.

---

From: Adam Roach <[email-masked]>
Date: Mon, 18 Feb 2002 19:03:46 -0500

> * using "rejected" due to the failure of authorization: sure 
> it is a change in authorization _state_ but the description for
> "rejected" says that the error-reason is used when there is a
> change in authorization _policy_. I'm sure you can justify this
> by your definition of authorization policy but I think it is
> confusing and should be reworded to more clearly state that

I don't want to put that language in there because it will cause
more confusion than it avoids. People will be unclear about whether
an unauthorized subscription should be refused with a 403 or
created with a 2xx and then killed with a NOTIFY/terminated/refused.

> location is not necessarily a synchronous operation.

You need to take up this argument with Jonathan, not me. My #1
priority on the reason codes is to sync with watcherinfo. If you
can get Jonathan to add it to watcherinfo, I'll add it to events.

/a

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 18 Feb 2002 16:27:31 -0800

Adam,

Let em add the following observation that (and I quote from the watcherinfo
Abstract)

"Watcher information refers to the set of users subcribed to a particular
resource within a particular event package."

So when watcherinfo is used, you have already performed the resource
location process. Of course, it does not make sense for watcherinfo to
include an error-reason to say that a subscriber couldn't locate the
resource that the watcher is already watching. 

However we are talking about the SIP Events draft here where this DOES make
a sense (and IS of definite use) to have a "noresource" error-reason.

Jonathan, what's your opinion on this?

Robert.

---

From: "James Undery" <[email-masked]>
Date: Tue, 19 Feb 2002 09:24:31 -0000

I am not hung up on any of this as it's non-normative and can be ignored
;-)

> From: Adam Roach [mailto:[email-masked]]

> related attribute that a package author can decide to neglect.

In general if you mean no state in the NOTIFY is neutral okay, otherwise
I've a problem. Fake state is for polite refusal a rather rare problem
(i.e. presence); the existance of a neutral state or identity for deltas
is something my limited set theory would suggest may not apply.

> resource, not the resource itself. It's an important distinction.

In that case may I suggest s/user/local policy/ as it is REALLY
important a human need not be involved.

> confusion than it avoids.

Where as I'd hate to introduce the braindead arguments people have over
location servers, registrars and proxies. The entity that accepts the
subscription and the entity that's the notifier are logically distinct.

> in the table would imply a global change.

Surely only for people implementing Sub/Not, it's like Max-Forwards
mandatory, yet only bis aware UAs will be guaranteed to do it.

James

---

From: "James Undery" <[email-masked]>
Date: Tue, 19 Feb 2002 09:33:46 -0000

Ooops hit send too soon another v. minor nit; the BNF uses '|' instead
of the rfc2234 '/' the bis has now adopted.

James

---

From: Adam Roach <[email-masked]>
Date: Tue, 19 Feb 2002 11:33:38 -0500

Thanks. This has now been corrected. (We also use a hex notation
now for the method names, like bis-07).

/a

> Sent: Tuesday, February 19, 2002 3:34 AM
> To: James Undery; Adam Roach; [email-masked]
> Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon!
> 
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 19 Feb 2002 12:20:36 -0500

> important a human need not be involved.

Perhaps in some sort of a post-apocalyptic world portrayed in
the movie "Terminator" and its sequels, this would be correct.

For the time being -- and until machines acheive a frightening
level of sentience -- I'd expect humans to be in charge of
determining what does and does not constitute an acceptable
subscription. I don't mean real-time, and I don't mean for
every single subscription on a one-by-one basis. Installing a
local policy would place the ability to accept subscriptions 
under the direct control of the user, which is all this section
suggests.

> subscription and the entity that's the notifier are logically 

Do you see the term "UA" as useful? It has component parts that
are individually a UAS and a UAC, but we use the term "UA" all
over the place. Notifiers are a special kind of UA -- ones which
accept SUBSCRIBE messages and generate NOTIFY messages. I don't
really want to invent new terms to describe the two halves of
this special UA; it would be inventing terms for the sake of
inventing terms instead of for clarity.

/a

---

From: "James Undery" <[email-masked]>
Date: Tue, 19 Feb 2002 17:42:58 -0000

> Sent: 19 February 2002 17:21

user implies user interaction to my mind otherwise, I could describe
your draft to the a user generates SUBSCRIBE messages a user responds,
the user generates a NOTIFY a user generates a response. Very few
packages are likely to require human interaction at an operator sits at
his terminal fingers poised of the 'y' and 'n' keys level, which is why
I object to this. It strikes me as very presence biased, but as I said
non-normative text so I don't care.

> inventing terms instead of for clarity.

The distinction is critical the entity accepting the SUBSCRIBE is a UAS,
the entity generating a NOTIFY is a UAC. In the proxy world acting as a
UAS is familiar registrar teritorry, UAC is new and frightening unless
you're a b2bua weirdo. Without getting into architectual discussions I
believe these are separate network components, but again non-normative
text so I don't really care.