Subject: [Simple] draft SIMPLE minutes from 51st IETF

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 13 Aug 2001 21:14:04 -0500

Thanks very much to the invaluable Mr. Dean Willis for taking these minutes
in London this past Monday. If any amendations to these minutes are
required, please let us know in the not-too-distant future.

Jon Peterson
NeuStar, Inc.
SIMPLE co-chair

---

SIMPLE Charter Changes:

Proposed
Aug01 -- IM document set to IESG
Sep01 -- Presence extension to IESG

Jonathan Rosenberg (JDR) suggests swapping these dates as presence is
running ahead of messaging.

IM Session Open Issues -- Ben Campbell
--------------------------------------------
Ovelapping MESSAGEs -- overlapping transactions prohibited by 2543bis.

JDR: Three approaches
1) declare non problem
2) allow overlapping transactions by overruling spec using ordering in the
content.
3) Define a message transport

Dave Oran:
4) Telnet approach -- additive transmissions until ACKed.

Question : Can we discard solution 1? This could be a real issue for
machine-driven systems.
Much discussion on whether this is really a problem. The difference is in
waiting for the ACK, and where reordering is done. There may also be a
question of rate-liimiting. The real issue is delay from ping-pong effect.

Poll: Can we live with no overlap? General response: no.

Question: Do we want to fix SIP for this or use something not-SIP for
message transport.

Question: : For session-mode, SIP has a lot of overhead. We could do
something more stream-lined. What?

Question: Would text-rtp work for this? We need to do an analysis and
determine if it meets requirements. There are likely to be real challenges
with NATs. There are also problems with non-reliability as text-RTP is not
acknowledged.  What about delimiters and framing with RTP? Is this an issue
for CPIM conversion? We may need a message delimiter in-body.

Question: Is ability to cross a CPIM boundary a requirement  -- consensus
yes. It is probably acceptable to make the CPIM gateway session stateful.

Question: Why are we limiting the "signaling session" to MESSAGEs? Could
this be generalized? Can a SIP session running messages transport other
messages, like OPTIONS or INVITE?  Arguments in both directions presented.
Proposal: Always use ";method=MESSAGE" when referencing the URL.

Question: Should we move URL out of m= line and into c= line. Will SDP
support this? SDP seems to define c=values as addresses, not URIs. ATM uses
ATM addresses, so it might be possible. PINT did something similar, and the
SDP guys haven't complained loudly. Consensus: yes, may need clarification
from MMUSIC.

Question: How to get MESSAGE request to follow same signal path as enclosing
INVITE? Do we require this ability? Proposal: save this for later.

Question: MESSAGEs hitting forking proxied will fork. Is this a problem?
This says a couple of things: 1) using SIP for message transport is using a
very large hammer for a small nail.  This may be further cause for finding a
different transport for messages in streams. Discussion postponed. Followup:
We'd need alternative proposals -- and must make sure that it gets through
NATs. Suggestion: We should keep in mind that session and page based
messaging are separate, split the deliverables, and go ahead and get message
mode into the IESG. Session mode is to be delegated to design teams to
generate real proposals (goal three weeks). Ben Campbell volunteered  for
non-SIP. Sean Olson  olunteered for SIP transport.

Question: Currently, MESSAGE follows initial path. This may be very strange
if
original INVITE follows non-optimal path. We will insert new text to
recommend this not happen.

Question: Current proposal uses two one-way streams where persistent
connections are used. Okay? It appears that commedia (in MMUSIC) will
resolve this in
general.

Presence Open Issues -- Jonathan Rosenberg
-----------------------------------------------

Privacy of Auth Policy:

Basic question: If a party subscribes, is there an issue with revealing
whether they have been accepted or declined. Is this a problem? Should we
solve it? Arguments on both sides. This adds complexity, and may not be
doable in many implementation domains. Perhaps a set of guidelines for
"authorization policy hiding" can be provided to allow specific domains to
implement local policy. There are two problems here: leakage of policy (the
"hurt feelings" problem) and leakage of presence (rapid vs. slow denials
might indicate whether they are there).

Proposal : Don't solve, and add cautionary/implementation guidance text to
the document.

Remote-Party-ID:

Predicts that much authentication will be based on transitive trust. SIP.
Remote-Party-ID may be useful for this. Question: Should we reference it?
Consenus: yes.

Presence Doc Format:

Open issues with presence document composition and upload. REGISTER may not
be the right thing. Do we want to solve these? Consensus: yes.

Dicsusion: It is important to be able to feed in presence document
components from multiple sources using a common interface method. This is
required to be able to composite presence information.

Question: How do we want to upload presence? New method? Is there a general
purpose uploading method that would work for CPL, etc.? How to prevent
madness?

Proposal:  Property-value management mechanism based on
content-disposition. This might actually be able to replace the whole
registration payload work, which is currently on-charter for SIPPING.
Consenus to explore this line of work.

Triggered Authorizations:

Background: Use of user-supplied authorization policy, and notification of
the lack of authorization policy.

Proposal: watcherinfo package with data set for each subscription. Poll for
dissenters: none. Discussion: Do we wish to include type or class of
authorization in the data set? Consensus no due to complexity. Audience
requested to folloow up with more consideration of mechanism and proposed
FSM.

Settting Authorization Policy:

Proposals:
1) Say nothing -- app specific
2) Include approve/reject URLs in wathcerinfo to allow GUI processing at
client
3) Define policy doc and upload mehod

Much discussion. If policy is semantically self-contained, this would allow
a great deal of interoperability.  The URL suggestion requires web servers
and HTML renderers. Proposals:
1) Leave the solution to the implementaion, potentially using other-defined
"upload" procedure, and leave open the option of defining a policy document
in the future.
2) Punt to IMPP for a policy document format. Probably no result.
Consensus seems to favor proposal 1.

---

From: "Sriram Parameswar" <[email-masked]>
Date: Mon, 20 Aug 2001 09:54:28 -0500

Problems with the list...my email did not get through 

-----Original Message----- 
From: Parameswar, Sriram [NGB:B658:EXCH] 
Sent: Friday, August 17, 2001 11:04 AM 
To: 'Peterson, Jon'; [email-masked]' 
Subject: RE: [Simple] draft SIMPLE minutes from 51st IETF 

Hi All, 

With regards to the following question and answer (see below) - and my not
being there at the IETF 51, I would be extremely grateful if somebody could
explain the term 'Property-value management mechanism based on
content-disposition.' 

I also want to know how this applies to the question of publishing presence
via methods other than REGISTER. 

Thanks in advance, 

Sriram 

--------------------------------------------- 

__________________________________________ 
Sriram Parameswar              Phone: 972-685-8540 
Wireless IP MultiMedia (WIPMM)   Fax: 972-685-3563 
Nortel Networks, Richardson USA  Email: [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Aug 2001 14:00:07 -0400

-----Original Message-----
>From: Sriram Parameswar [mailto:[email-masked]]
>Sent: Monday, August 20, 2001 10:54 AM
>To: [email-masked]'

>explain the term 'Property-value management mechanism based on content-
>disposition.' 

What this means is that users in a system have configuration parameters that
define the service delivered to them. Some of these parameters are values
settable by the end user themselves. Examples of such "properties" are the
user's CPL script, the presence doc they desire for distribution, their
authorization policy, etc. So, it was proposed (and I think there was
consensus on) to have a general purpose mechanism in SIP that allows a
client to set a particular property. The current CPL upload draft uses
Content-Disposition header to indicate the purpose of the upload - setting a
CPL script, for example. This could be generalized to support other things,
like presence doc uploads. 

>via methods other than REGISTER. 

Yes, this mechanism would presumably be used for that purpose as well (or,
at least, it is my recollection that this was the proposal).

-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: "Robert Brown" <[email-masked]>
Date: Mon, 20 Aug 2001 11:18:35 -0700

Would this also be used to authorise watchers?

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, August 20, 2001 11:00 AM
> To: 'Sriram Parameswar'; [email-masked]'
> >With regards to the following question and answer (see below) - and
my
> not
content-
> >disposition.'
> 
> What this means is that users in a system have configuration
parameters
> that
> Content-Disposition header to indicate the purpose of the upload -
setting
> a
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Aug 2001 23:07:14 -0400

> From: Robert Brown [mailto:[email-masked]]
> Sent: Monday, August 20, 2001 2:19 PM
> To: Jonathan Rosenberg; Sriram Parameswar;

It would be used to upload authorization documents, yes.

-Jonathan R.

> > Yes, this mechanism would presumably be used for that 
> purpose as well
> (or,

---