Minutes, SIMPLE WG, IETF 55

11/18/2002 1530-1730
Atlanta, Georgia US

Reported by Dean Willis
Edited by Robert Sparks

Blue sheets: circulated with some discussion of algorithm, one from the 
back right and one from the left front.

Agenda discussion: No issues raised.

Status discussion: Chairs
------------------------- 

MESSAGE has an RFC number. Presence event package has passed WGLC and is in 
IESG. Charter requires date adjustment. 

Open question: Do we need a new charter item for PUBLISH?  Suggestion from 
audience that this be handled most expeditiously. The chair reported a 
consensus to adopt the PUBLISH requirements into the chartered work of the 
group.


Publish Work: Sean Olson 
-------------------------

Changes in the -01 model, now 3 pieces of information: class, instance or 
stream header, facet which indicates target group or set of logic that 
applies.  Publication class defines a type. 

Open issue, should this be mandatory?. Publication facet defines 
intended watcher group. 

Open issue: Is the syntax sufficiently flexible? Should this be 
standardized? Publication Instance provides source 
identification. 

Open issues: Should there be an explicit dialog? Is the proposed syntax 
adequate? Several general open issues raised in slides.
Proposal: We should move to an explicit dialog model. We don't do this in 
REGISTER for historical reasons, and this has caused a mess. It is nice to 
have an identifier that is persistent across transactions. There are also 
requirements for name persistence that extend well beyond a dialog, and 
this is a seperable problem that the authors propose to move to a 
seperate draft. 

Question: Why are things like the publication class seperate headers 
instead of body elements?  Short answer is that this requires 
MIME/MULTIPART automatically. 

Question: If we solve the greater naming problem, do we still need a 
dialog?
Consensus: yes.  

Comment that stuff in headers is metadata, understandable by a 
compositor even when the body isn't. 


Publish work:  Aki Niemi
------------------------

Proposes a general framework based on the Olson work. Provides new 
"Allow" header functionality for publication operations. Open 
questions on payload format. 

Open questions: abandon, integrate with Olson, complete in seperate 
track? 
 Discussion: Publication is really an inherent part of the 3265 events 
package, it's just getting done later.  There seem to be no real 
conflicts between header use in this work and in 3265. PUBLISH will want to 
say that future event packages should include details of 
publication.
 Further discussion: There may be more semantic analysis of what we mean by 
"allow/supported" headers here. 

Poll: Should requirements document for PUBLISH be a working group 
effort? Proposal that we do requirements here and draft up a solution for 
handoff to SIP.

3GPP Messaging Requirements Draft: Aki Niemi

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

Includes data manipulation and privacy requirements that go beyond 
current SIMPLE work. Data manipulation has much in common with 
conference work in SIPPING and author proposes moving this work there. 
There are open issues on addressing and message class based 
diversion, and on charging and security.  Author assumes that charging and 
security fall into the regular work. 

Question: What do you mean by message class?
 Answer: We're not sure. It means something like "advertisement" or 
"personal" or something like that.  

Question: Is this in e-mail. 


3GPP Presence Requirements: Kristian Kizs

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

Require standardized publication mechanism, publishing from multiple PUAs, 
feedback on publishing and composition, and efficient publishing of large 
multimedia content including partial publication. Several issues with 
filtering and efficiency described in slides. 

Question: Process: Can this be an informational seperate draft, or should 
this be in the main requirments body deferred to later discussion. 

Comment on efficiency issue: In some off-list discussions in came up that 
much of the large-media stuff can be addressed with content 
indirection. 

Further requirements on presence document, authorization, and 
presencelist given in slides. 

Comment on work process: There really aren't any other requirements 
documents to integrate this work into. Do we need one? Can we take the 
requirements out of here and merge them into other work that is going to 
include them? Chairs deferred this discussion to the list, along with a 
request for people to lead on various task points.

SIMPLE PIDF Extensions: Paul Kyzivat
------------------------------------

Purpose is to represent SIP-specific features in presence documents. Work 
spans both the kyzivat (rqmts) and lonnfors (response to rqmts) 
prescaps documents.  Work is based on callerprefs. Proposes a set of 
requirments discussed in slides. 

Open question on work process: Enhance these drafts, or seperate into 
other extensions.  
 Discussion: The discussion of capability registration is similar to other 
work in ENUM and elsewhere. The whole idea about pushing capability 
awareness to an endpoint is to allow the endpoint to make an informed 
decision about whether to attempt communications. 

Point: This doesn't replace registration. This is on the "other side" of the 
AOR -- what capabilities does the AOR, not the Contact, support?  
Generally this is some sort of union of the contact capabilities. Ample 
discussion followed. 

Proposal from chair: We go ahead an adopt this is a starting point for the 
charter item of PIDF extension, emphasizing status appropriate for 
instant messaging.
 question: Which of the two referenced drafts are you talking about? 
Chair response: both: you authors coordinate and go forward. Further 
discussion deferred to list.

Event List Template Open Issues: Adam Roach

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

Issue: mixed vs parallel multiparts? 

Issue: Metadata, using MIME preamble vs body-part headers. Would a 
seperate body part be more useful? Do we aggregate meta-data? 

Discussion: Option 2 (slides) preferred for nesting models by several 
speakers.

Issue: Uniform depth. As defined, subscriptions may require uniform 
depths in their heirarchy. Does this justify further work? 

Discussion: This requirements seems to be a headache. If we ever need to 
include a list from another domain it causes some challenges. This may not 
happen due to the implicit requirement of understanding an event to 
subscribe to it? Comment: Experience from LDAP and WebDAV indicates that we 
will have to deal with recursion eventually, so we might as well solve it 
now.


Data Manipulation Requirements Issues: Jonathan Rosenberg

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

Open issues: 1) Security requirements, 2) scope, 3) tuple naming

Question: To what degree does this relate to filtering:
Answer: Anything that can go in a filter should be subject to policy.

Question: We could possibly define a scripting language for this but 
anything else seems to be insuffient to express policy. Proposal is to 
remove the scripting discussion as it is implementation, not 
requirements. Hopefully we can narrow the requirements sufficiently to have 
choices for the implementation.


SIMPLE List Manipulation Semantics: Markus Isomaki

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

Premise: We see lots of unordered URI lists in SIMPLE 
applications. A common manipulation mechanism would be very useful. 
Rather than defining an implementation, the current work defines the 
semantics requirements of an implemementation.

Open issues: scope (presence only, generic list and auth policy, or 
general purpose data manipulation), plan, synch model, deciding how to 
choose actual protocols. Discussion of scope and unification followed. One of 
the main discussion themes was semantic nature of data and discussion of 
access control policy language being done in other SDOs.  Further 
discussion deferred to list.


Message Sessions: Ben Campbell
------------------------------

Three drafts in the discussion -- SDP descriptions, CPIM/TCP, and
Jabber sessions. Discussion will focus on first two drafts.

Open Issue: Supporting Intermediaries. How much do we want to say?
 Discussion: We should show cases one zero, one, and more than one 
intermediary.
 Discussion: There are basically two approaches: back-to-back media 
relays, and something on a globally unique name end to end using 
something like preloaded routes.
 Discussion: This is a big change from what we have been doing with 
messaging sessions. Should we vote on it or something?
  Comment: There seems to be general agreement on using SDP style 
negotiation. 

Discussion: Much of what is in cpim is constant over a session, so we 
should be able to negotiate these up front, perhaps 
parameterizing them, and then reuse them. This probably requires a CPIM 
extension registry. 

Issue: Do we want RFC 1893 and 1894 type confirmations?  Suggestion that the 
delivery reports stuff be pulled out and moved to a seperate documemt. No 
objections raised to suggestion.

Issue: Session keys vs S/MIME.
Discussion: S/MIME can use a session key using a shared secret in the SDP. 
Rohan will work with S/MIME group on this and report back. Note that this 
applies for encrypted but not signed data. Is Mikey appropriate? General 
consensus seems to be "not at this time".  However, there is a lot of 
convergence in security going on now, so we can probably defer safely. 

Issue: M-line format. Three alternatives.
Discussion: CPIM/TCP is not a valid token in SDP, no slashes allowed. 
Further work on SDP format is required. 

Issue: Comedia usage. COMEDIA makes connection sharing difficult by 
making it difficult to demux shared connections.  Current plan is to get 
COMEDIA fixed in MMUSIC and then import. If it doesn't get fixed, then 
we'll have to come up with something else.

Question: How do people feel about the work of the design team?
Poll: adopt draft-campbell-simple-im-sessions as WG effort, approved by 
hum, no dissent. Poll adopt cpim-sessions draft as WG effort, approved by 
hum with several dissenters. 

Discussion on Jabber-sessions draft: Question: Do we deal with new 
transports my extending SDP name space, or is there a way to do it using the 
MIME registry? Suggestion that this should be followed up in the SDP 
draft.