Subject: [Simple] Draft minutes from IETF53 meeting

From: Robert Sparks <[email-masked]>
Date: 03 Apr 2002 09:43:48 -0600

Thanks to James Undery for taking the notes.

Please provide comments/corrections by Apr-8.

RjS
---------------------------------------------
SIMPLE 53rd IETF Salon C Mar-20-2002 15:30

Summary:

* The presence and watcher-info drafts are ready for nits review.
  Nits review will occur by Apr 5 and will proceed to WGLC.

* CPIM mapping effort is on track for June milestone

* Message session
  - Jonathan will provide a proposal for message sessions using
    normal SIP instead of IMTP, using loose routing to solve
    our earlier transport issues
  - Analysis of this proposal and IMXP for satisfying transport
    constraints and CPIM conformity will be provided within 4 weeks 
    (by Apr-22-2002).

* There is general agreement to work on providing solutions for the
  gaps identified in the simple-components draft. Some of the work
  would be done in SIMPLE, some in SIP/SIPPING, and some in a few
  other fora. The work to be done in SIMPLE will be identified and
  a proposed charter reflecting it will be submitted shortly.
    
Detailed Minutes (provided by James Undery)

Agenda Bash
+ No issues

Current deliverables
Apr 02 Presence to be submitted
Apr 02 watcher info to IESG
May 02 CPIM mapping to IESG
Jun 02 IM sessions to draft

SIMPLE issues - Jonathon Rosenberg
==================================

Jonathon presented the latest changes and upcoming work for a number of the 
drafts he is authoring.

Presence
- Alignment with new SIP and sip-events upcoming RFCs
- Removal of 3/4 of examples, removal of example PIDF content from remaining 
  examples
- Additional security, usage of SMIME and sips
- Recommended PUA implement this package, so network can subscribe
- Handle generally applicable issues such as IANA considerations and split 
  references into normative and non-normative categories.

winfo-format
- First-Subscribed will now indicate when the current state machine was first 
  created rather than the first subscription ever
- Removed notify address
- Added expiration params
- Removed most recent subscribed
- id and version attributes will be added after the blackout
Open issue: duration meaningless in fetch operation; Jonathon said to ignore it,
speakers from the floor agreed.

winfo-package
- Forking issue need to get subscriptions on all machines handling 
  subscriptions. Two methods were discussed forking or use existing dialog. 
  Which method to use depends on whether you are the presentity or not. i.e. A 
  pure watcher should use an existing dialog.
- IANA considerations
- State agent text will be rewritten

The proposed schedule for progressing these items was
Arrange nits reviews
Updated drafts by Apr 5 for WGLC
Submit to IESG

CPIM mapping draft open issues - Ben Campbell
=============================================

Ben commented there has been no discussion of this draft on lists. Ben then ran
through his list of open issues.

- How the URI is handled at the CPIM gateway. Two methods have been suggested
  - Direct scheme substitution
  - Leave as a gateway local mapping
  - Ben proposed taking the local policy approach. There was no objection.

- Update the draft to take account of changes in the latest SIP spec. e.g. 
  transaction IDs and dialog.

Christian Huitema observed that CPIM was designed to allow SMIME to cover the 
body, we should check we don't need to change the body at the gateway.

Ben agreed it was reasonable to meet charter deadline of May 02 provided the
work didn't have to account for message sessions (due June 02).

Message sessions
================

IMSX - Marshall Rose
--------------------

Marshall ran through a brief presentation of how IMSX and beep would work.
The steps involved were establish a TCP connection, tune BEEP session and then
exchange messages. Examples of the SDP involved were given showing privacy 
being tuned. 

At this point Christian noted the problems opening the TCP connection from a 
SDP negotiation; Rohan Mahy noted this is being worked on by mmusic in the 
comedia draft.

Marshall explained the tuning process negotiates authentication integrity 
privacy of the connection and how the initial message can be piggybacked with 
opening a IMSX channel. The simplicity of the scheme was then covered, i.e. 
it deals with no addressing, routing,middlebox, message formats or rendering. 
All these issues are handled by other protocols.

Cullen Jennings questioned if lack of middlebox issues was true. The answer 
from various people was this was a SIP/SDP/Midcom issue with the session setup.

Ben asked how large is a beep implementation? Marshall estimated that 20 
screens would cover the simplest implementation and more feature equated to 
more code. 

Jonathon noted SIP offers a lot of the negotiation feature making large 
portions of the BEEP/IMSX setup redundant. To which Marshall replied Beep
stays out of signaling and noted media protocols might want security
negotiation indirectly too.

Christian said attributes should be negotiated in the SDP to remove a level of 
indirection and that TLS handles negotiation of encryption integrity.

Henning Schulzrinne  commented multiple negotiations allows multiple new 
failures.
   
Question from the floor is binary data in beep transported as binary or base 
64 encoded, the reply was BEEP sends as binary.

A discussion of UDP and TCP transversing middleboxes followed, the consensus 
was this is a non-issue as it's the same for both proposals.

IMTP - Jonathon Rosenberg
-------------------------

Jonathon ran through the changes to the SIP spec that have greatly aided and
simplified this work. The main change to benefit IMTP was loose routing that
removed the need to make IMTP a subset of SIP ( by removing UDP, forking and 
redirection). The requirement now being loose routing can only use TCP hops.
Other changes relating to when a proxy can change the Request URI (i.e. only 
when it owns the domain in the Request URI) means using a FQDN or IP of host 
ensures no forking or redirection.

Henning asked if this would interference with normal signaling traffic. 
Jonathon replied that the element handling IMTP wouldn't necessarily be a 
signaling entity.

Henning also inquired if it is possible to open multiple TCP connections to 
handle messages. Jonathon replied yes, however because it's SHOULD to reuse
connection this would requires special code for this instance.

A speaker noted that IMTP was routed at application level yet should act like 
media. Jonathon drew attention to the problems of creating a bespoke protocol 
and how it'd probably be similar to IMTP anyway.

Christian noted we could stream CPIM over TCP as a minimum, however, we might 
need a proxy for logging etc. So IMTP is probably minimal for what we want.

Bob Penfield observed using Record-Routes seems overkill. Jonathon responded 
by saying it was likely that the loose route would be obtained separately 
routes in the signaling.

The chairs commented we have two concrete proposals neither absolutely flawed, 
we have the options pick one, pick both or chuck the problem. After a lengthy 
discussion on the two alternatives it was decided that both options would verify 
they conform to CPIM sanity checks and report this back within 4 weeks. Once 
this information was in the WG would be in a better position to pick one or 
proceed with both.

Andrew Zmolek added that picking one option now doesn't shut the door on the 
other, SIP can still use it later.

Alison Mankin noted that the proposals should also tidy loose ends as they 
checked for CPIM conformity.

Page vs Session modes and groups - Jonathon Rosenberg
=====================================================

Jonathon ran through talk showing groups existed in both modes, and 
characterised with mode was appropriate. Counter examples were discussed, and
Jonathon agreed group messaging covered a spectrum of modes and potentially 
mode transition would be useful.

Open issues were then covered including threading and ordering of group 
messages, group addressing and maximum message size for page mode (Bis 
will automatically use TCP for big messages)

Christian noted for security and page mode we want to use SMIME which could be
large due to the certificates. Jonathon replied session mode could use a 
session key rather than certs. Christian also noted this could be a bigger SIP
issue.

Jonathon finished with the biggest open issue, how much effort should we put 
in to adding group mode that is how to use the existing modes one, both or 
neither. Jonathon recommended for groups mode use session. Henning replied we 
don't need to make the decision, there are cases for both, we should give 
advice not make a choice. Dave Oran questioned this asking why would you 
need group in both, one reason for page mode is latency for the initial 
message, otherwise use session.

SIMPLE components - Jonathon Rosenberg
======================================

Jonathon gave a presentation of the network components that would be required
for a functional "buddy list" application, and suggested we ensure the tools 
were available to build this.

Jonathon identified a list of what's missing which included; data manipulation,
status notification (i.e. is typing notification), message storing, group 
conferencing, content sharing, threading, publication and glue for above. His
proposal was SIMPLE adopt "buddy list" application, adopt a "is typing" 
solution, adopt development of IM statuses for PIDF, finish message sessions 
(including threading), adopt data manipulation (i.e. list allow or deny), 
a presence publication document and an architecture document to put it all
together.

Henning commented that we have started group mode and threading. Jonathon
noted this is just for SIMPLE, the homeless items are message store (VPIM ?),
content vault manipulation (Webdav ?), conferencing floor control 
(needs a BOF ?) and profiles, user and group discovery (whois++). Lots of 
people agree this is needed, someone noted this homeless stuff needs to go 
somewhere. Sean Olsen asked if we can expand the charter to encompass this 
or pass it out to other WGs. Henning noted another conferencing adhoc had
occurred and were going to produce requirements within 3 weeks.

It was agreed to hold an adhoc meeting to continue this discussion

Markus commented this stuff is needed by 3GPP who will be looking at it 
after release 5. Someone else observed AOL has trademarked buddylist,
Jonathon agreed to change the name he used.

A hum on adopting the work and discussing what it means was held with 
strong consensus for continuing this work.

Keith Drage requested we don't set priorities until input from external groups 
has had a chance to come in.

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple