MINUTES - SIMPLE IETF71 - Tuesday Mar 11 Chairs: Robert Sparks, Hisham Khartabil Summary: The room felt the chat draft should not address sending to multiple recipients with one SEND request. The room believes the view sharing draft is close to ready for last call. Ben Campbell and Brian Rosen will try to find new people to do a detailed early review. There are open issues remaining in the Intradomain Federation working group item. More people need to read the draft and engage in closing those issues. Discussion of the text-transmission for MSRP draft uncovered several concerns but was not conclusive. Interested parties will continue the discussion on list. We ran out of time before talking about indirect presence publication. The group is encouraged to read Miguel's slides and bring questions to the list. Raw notes follow: ------------------------------------------------ SIMPLE IETF 71 notes by Dean Willis Chairs Note Well presented. Agenda accepted as presented. Topic: Status Chairs Slides presented Issue: partial-* patchops Jon P reports that IESG may split into parts and advance separately. Topic: Multi-Party Sessions in MSRP Geir Sandbakken Slides presented Issue: Brian Rosen reported that he meant to sent list message saying that the language used for SIP AOR and SIP URI uniqueness is not as consistent as it could be. Issue: Correlating roster and anonymous participants. Miguel believes users need to know their own anoymous URIs so they can correlate. Another possibility would be a P-Asserted-URI like header in the INVITE or response thereto. However, in the current text participants do not know their replacement URIs. Brian R. holds that conversations need to provide a consistent representation for anonymous users so that such users can know when they are being talked to. Miguel suggests that default nickname is the anonymous URI (replacement URI). This of course means that users need to know their replacement URIS. Brian proposes "If you are going to be anonymous, then you must request a nickname." Miguel points out a race condition between joining the conference and getting a nickname -- during this window, users don't know their own references. Issue: Miguel wants to send private message to multiple recipients. Previous versions allowed this -- current does not seem to. Geir reports that requirements and text for this has been removed in current draft. Brian R thinks this will intersect badly with XCON sidebar. Miguel thinks that if these are two different things, then software should be able to keep them straight -- if the users know their replacement URIs. (Mutiple to: entries) Adam thinks that complexity for a narrow use case is inappropriate -- we should send multiple messages from the UA for now until XCON sidebar is ready. Deliver receipts are a major problem. Geir notes an advantage using a 428 response to single messages. Mary also objects to extending differently from XCON. Hisham thinks the draft doesn't prohibit a cc: header, but just doesn't define it. However, WhoWasThatGuy thinks that if we do not have this feature, we should explicitly forbid. Miguel maintains that this can be done simply. Robert thinks that this would not be as easy as we might think. Poll: Who would like to leave the draft as it is, not attacking multiple recipient problem vs. who wants multiple recipients? Only Miguel declares in favor of multiples. Issue: what role the switch need to take when it receives error reports from downstram? Does it discard or pass on? The current text does not say, and we need to say something. Agreed that we need to be precise about this. Topic: View Sharing Jonathan Rosenberg Slides presented Open Issue: raised by Brian Rosen. Wish to assure people that the only thing this does is change traffic between large presence servers. Unclear what the impact on the total network traffic here. According to JDR and Adam Roach, it does not change the total number of notifications seen by watchers. What it changes is the number of messages between the servers. Issue: Brian Rosen asks about relationship between choosing of modes and winfo, This needs to be better documented in teh draft. Ben Campbell notes that many people see "winfo" as "who is watching me now" and really want it. Brian Rosen also reports that presence optimization techniques may use winfo. Poll: Do we think the next draft might be ready for WGLC? People think it is possible. Brian will ask some people for detailed review. Ben will too. Topic: Intra-Domain Presence Federation Jonathan Rosenberg Slides presented Changes since last version discussed. Question from brian R: Can you explain why there is a difference between partitioned and exclusive models? Partitioned implies an administrative move. Exclusive implies a dynamic binding, making for more complicated routing. Open issue: Recommend a single routing mechanism as a baseline? Ben thinks this feels like a place where implementors are really going to innovate. Specifying a baseline is premature. JDR notes that flooding across servers (forking) is a possible baseline. Jeff Hodges observes that domain is used here as an unadorned phrase which may be ambiguous. Perhaps administrative domain is correct? Noted from floor that we mean "right hand side" when we say "domain". If we partition into multiple subdomains, then we're back into the interdomain techniques. Open Issues: Data sharing in divided models is a Big Problem. Poll: Have you read this draft? Not many. Chair reminds us this IS a working group item. SIMPLE Text Transmission Erik Zetterstrom for Gunnar Hellstrom Question from Henry Sinnreich: Don't understand usage of erasing text -- I like to be able to re-read. Also there are cases where the log of the text is required for legal transactions. Dean noted that "erasing" is for user-correction. But the logging, if required, has to include the erasing operations. Ben Campbell notes that there are lots of other protocols that already do this. And he doesn't WANT real time text. Jeff Hodges notes that we're really recreating the old Unix "talk" (or "ntalk") protocols here. But the mode of operation could certainly be selected on a per-user or per system basis. Stu Goldman sees this not as an alternative to instant messaging but as an adaptive technology for people with impairments. It is a replacement for voice. It therefore seems reasonable to provide this service. Robert notes that having the service or not having the service is not a question -- ToIP already exists. Does it make sense to deliver this on MSRP, and on general purpose IM services. Miguel reminds us that ToIP already exists. RFC 4103. Dean notes that 4103 is not congestion-controlled or reliable and uses redundant encoding for reliability. It therefore makes him nervous. Jeff Hodges suggests "TCP over UDP" as an alternative (humor). Hisham suggests that 1-byte chunking is a bad idea. Ben raises the question of whether MSRP (with its overhead) is a good idea. This is a lot of overhead. We could do steady-streaming, but relays might break this. Rohan suggests that msrp servers can rechunk, and this will interfere with the experience. Dean suggests that this could be a good usage of TURN. Further discussion deferred to list.