Subject: RE: [Simple] SIMPLE BoF agenda

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Feb 2001 18:43:56 -0500

> -----Original Message-----
> From: James Undery [mailto:[email-masked]]
> Sent: Thursday, February 22, 2001 10:55 AM
> To: Adam B. Roach
> Cc: [email-masked]
> Subject: Re: [Simple] SIMPLE BoF agenda
> 
> 
> 
> Thanks I am quite good at spotting low wit.
> 
> Will they also address the information leakage in section 4 of the
> presence draft, The bizare accept rule in section 5.5.1, 
> reference where a
> 202 Subscription Pending in 5.5.2 comes from. Solve the cut and paste
> mismatch later in that section, Swap the will for a MAY in 
> 5.6 so it is
> consistent with SIP (and 7.2 and examples), loosen the CSeq 
> requirements
> in line with SIP.
> 
> In time to read through it in a meaningful manner as the 
> drafts expired in
> December, and I feel I may be wasting my time and yours pointing out
> mistakes that have been corrected months ago.

Please, lets all be civil. 

I will do an update on the presence and IM specs before the deadline. I'll
incorporate whatever comments I get. I am also going to pare down the draft
a lot, since it was written largely to sell the concept. I will not update
the others, since the work is being picked up by IMPP (the presence data
format), or its not relevant, or significant discussion is needed. That is
the case for the QAUTH spec.

Frankly, QAUTH makes me queasy. Its nothing more than an authorization
mechanism. The difference between it and others of that sort are that this
one is between a network server and an end system. However, it has not a lot
to do with SIP per se. There is a lot more that one might want from an
authorization protocol of this sort (for how long are they authorized, for
what kind of presence data, etc.), and none of this is in SIP now. There are
no sessions here, nor does the protocol run between domains (two things that
might make using SIP more appealing). One of the open issues, then, is
whether this is the right approach to use. 

The questions to ask are:

1. do we need a presence server to client authorization protocol at all,
2. if so, what do we want it to do (requirements),
2. should it be based on SIP

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 23 Feb 2001 04:05:23 -0800

> 2. should it be based on SIP

Given the wide variety of things one might want to express, I suspect
that a form of program, such as an extended version of CPL, is much more
appropriate for the cases where the subscription arrives while no user
agent is available. If a user agent is available, normal SUBSCRIBE
processing would seem to work.

---

From: James Undery <[email-masked]>
Date: Fri, 23 Feb 2001 10:01:09 +0000

> Please, lets all be civil.

Sorry, I was obliquely referencing Oscar Wilde ("Sarcasm is the lowest form of
wit") and any attribution of wit is a compliment if you check the dictionary.

The unhelpful nature of the response to my first posting of known issues made
the second of ones that I don't know if anyone is aware of terse, if you'd like
more info on any of them I'd be glad to detail them.

> 1. do we need a presence server to client authorization protocol at all,

I think this has to be yes.

> 2. if so, what do we want it to do (requirements),

My preference would be to have an additional 'simple' mechanism for describing
accept and ban lists with what to do with unknowns. I'd also suggest that
headers were taken on trust (Oh dear) or a single presence server had to be able
to authenticate all the parties involved, with the user able to specify which
policy to use.

This would simplify the implementation greatly by avoiding many of the harder
authentication problems that could be solved by a more complete mechanism. It
also prevents people using Subscribe and watching when 202s become a 600
response to guess when people are online.

> 2. should it be based on SIP

I wouldn't be competent to say, although if it is used I'd look at
draft-nystrom-http-sasl-00.txt as a potential basis of an extension to SIP to
help with the inter domain problem. My gut feeling is something else would be

James Undery