Minutes - SIMPLE 73 - Tuesday 18 Nov 2008 - Minneapolis, MN, USA Summary: * The intradomain-federation draft is nearing completion and is ready for a detailed review. * view-sharing will go into WGLC shortly after IETF. * The meeting participants hummed in favor of taking on the work in msrp-acm as a working group item. * The simple-chat draft is down to a single open issue. There was discussion about whether there was still a need to complete the draft. Participants reported that there are implementations of the stable parts of the draft. Discussion on how to finalize this effort will continue on list. * There was interest expressed in draft-thomson-simple-cont-presence-val-req. Conversation will continue on list. * There was interest in exploring some form of alert mechanism. Interested parties should work with the authors of the poke draft and continue the discussion on list. Raw notes from Dean Willis and Matt Lepinski follow: --------------------------------------------- Notes on SIMPLE meeting at IETF 73 reported by Dean Willis 11/18/08 Topic: Intra-Domain Federation led by Jonathan Rosenberg Slides presented Poll on readership: a fair number of people have read it. Issue: Intra-Domain Federation vs Bridging Several speakers stated preferences for each, with no consensus on naming reached initially. Discussion contiued. Noted that many people hear "interdomain" whenever the word "federation" is used. There seems to be reasonable consensus on the three-way partitioning of the model as proposed in the draft. Issue: Next Steps No issues noted. Topic: View Sharing led by Jonathan Rosenberg Slides presented Changes in this (-02) draft reviewed. Possible future related documents discussed. Issue: List discussion on alternative policy transmission mechanism. Noted that Common Policy would provide a whole lot of ways to get things wrong. There appears to be a rough consensus on using the non-alternative (i.e., as documented) mechanism. Noted that Richard Barnes provided a formal review. Chairs are to execute WGLC on this draft. Topic: Alternative Conection Model for MSRP led by Christer Holmberg Slides presented Noted that Dublin meeting agreed to merge-in draft-denis-simple-comedia. Changes from previous version reviewed. Proposed to adopt as WGLC Ben Campbell noted that while he was the main objector previously, he can now live with the draft and will send some editorial changes Noted by chairs that this apparoach does not preclude MSRP relays. Poll: Who read? Result: Only about 1/3 of the room. Poll: Of the folks who read it, who thinks we should take this on as a WG item, finish and publish? Moderate support noted, none opposed. Issue: Actual MSRP URI vs anonymization thereof Should this be incorporated into this draft or done separately? Chairs direct that this should be brought in as separate work and offered to the WG. Discussion on whether this mechanism is or is not compatible with using a relay. Agreed that once this mechanism is used on a call, relays aren't going to work. If one party using this draft wishes to talk to a party using a relay, the first party falls back to conventional behavior. Discussion on whether this fallback work given the faux URI in the setup. Question; Comedia can be used for NAT traversal, but some sites used MSRP relays for other reasons. How does this interact? Ans: If you have another reason to use a relay, use the relay. Discussion contiued on the use of MSRP relays for media filtering. This may interact with SBC munging of ACM vs m-line issues. Suggested that we add a set of agreed scenarios or use cases to the draft. Question: What was the MSRP relay report from the last SIPIt? Robert recalls MSRP relays and five MSRP clients. Most of the clients were using MSRP for file transfer, not IM. Poll: Has anybody implemented the stuff in this draft? Hadriel reports that he has seen SBC implementations. Topic: Nicknames and simple-chat led by Mary Barnes Slide presented Poll: How many people have read the revised SIMPLE Chat document (this version): A few... Poll: Who wants the simple chat draft to finish: 5 to 10 hands raised. Noted that OMA is still referencing this document. Miguel Garcia reports that he is unaware of any current OMA reauirement. OMA Liaison Dean Willis is asked to find out (Request sent by email to OMA's Ileana Leuca during meeting). Poll: If you are passively ignoring this work, please raise hand: Majority of room. Noted that the constituency for this work was a "rush need" from OMA, and that if OMA doesn't need it, we should discard and concentrate on XCON's solution. Noted that OMA may already have a spec based on this draft in circulation, probably an old POC spec. Noted by Jason Fischl and Avshalon Houri that there are implementations of the simple-chat draft, so we should finish it anyhow. However, people don't appear to be getting hung up on the nickname aspect. Topic: draft-thomson-simple-cont-presence-val-req led by Martin Thomson Slides presented This relates to OMA's "LOCSIP" effort. Discussion ensued. Comment: This draft is very much focused on the watcher to presence-agent problem and its requirements. However, the privacy of the presentity is paramount, and the presence server often obfuscates or granularizes the location data. It is importat to cover this aspect in the document. Comment: What are the applications intended here? Do these drive requirements for different mechanims in sampling continuous-value data? Perhaps bringing these applications in as use-cases would be helpful. Question: Is there just one watcher, or numerous watchers that are asking for different views from the source? If more than one, how many? Answer: The intent is not to limit this any more than presence is limited. Comment: The distinction between continuous and discrete data is interesting. Many of our presence states are sampled from continous data and quantized. However, we haven't put much documentation into this sort of quantization, and it could get complicated. We need to understand more about the applications. Comment: An approach wherein continuos values are quantized to meet the needs of specific applications, then we've reduced the expressivity of the protocol and may have crippled our ability to innovate with future applications. Comment: The interesting thing here may not be the continuity of the data, but the value-space tradeoff on precision and refresh notification. Comment: The glue between measurement and states should not be fixed. But where does it live? Is it at many layers, or can it be compacted into a single more managable layer? Comment: It would be nice to examine the pros and cons of both sorts of models. Conclusion: There appears to be interest in further discussion on this document and topic. This may have application beyond location. Topic: Attention Request for Instant Messaging (Poke!) led by José Luis Martin Slides presented Issue: Simple or "Rich" Poke Comment: In the interest of feature parity, something along these lines would have some value. This argues for a "simple" poke model. Poll: How many would implement? (Some) Poll: How many would turn this OFF in a client? Noted that we don't appear to be the constituency for this feature. Suggested that if we do simple, people will want rich, so we might as well give it. Noted that Adium, Pidgin, and others support a similar feature. Comment: The receiver should have control over the richer poke features. Comment: This sounds something like an MSRP Alert Info header. Comment: We should look at the istyping RFC for guidance. Conclusion: Authors will revise and continue. Meeting terminated at 16:51 --------------------------------------------- Notes on SIMPLE meeting at IETF73 recorded by Matt Lepinski ******** SIMPLE ******** Intra-domain Federation - Jonathan (aka Intra-Domain Bridging) "The document formerly known as Inter-Domain Federation" -- Are the three models listed in the slides, the right three models to document? -- Audet: (name-change issue) There's no problem talking to technical people, but business people worry that it will create significant confusion among customers. It's the business people who don't attend IETF meetings. When you try to find information about "Federation" it's always Inter-Domain (e.g. between enterprises). -- Audet: We need another read of the document to determine if all three models are realistic? Need more active participation. -- Jonathan: I've had customers ask for all three -- Dan York: Customers can freeze up on a word choice and believe that they might be exposing their internal information outside the company. -- Comment: What about the word "confederation" "Or Intra-Domain Soviets" -- This document doesn't provide additional protocol machinery, it just explains the models. There is a need for future work (e.g. Minimal mandatory to implement routing mechanism for Partition-model with a flat name-space) -- Chairs are seeking reviewers. If you're interested, email the chairs. Otherwise the chairs will pick on people. View Sharing - Jonathan -- No one speaks in favor of going down the alternate path: "B passes policy document to A, along with raw presence ... A applies policy". -- Ready for a working group last call (probably this calendar year) Alternative Connection Model for MSRP - Christer -- Ben: I can live with this now -- Hum taken. Working group consensus to adopt this draft. -- Hadriel: Other Dublin issue - MSRP URI in body, is there interest in anonymization techniques? -- Chair: Make an individual draft that suggests -- Hadriel: This isn't really compatible with using a relay is it? (At time of offer if you want to use a relay, you don't use this). -- Christer (and Ben): If you're talking to someone who requires a relay, it's possible to fall-back to traditional MSRP usage with a Relay. -- Hadriel: I don't see how that fall-back would work -- Christer: We can discuss this on the list. -- Hadriel: Note, this isn't a problem, because I don't really believe relays exist. Maybe we need an option tag to make this work. -- Chair: I've talked to service providers who plan to use MSRP relays for content filtering -- Hadriel: They just use that word. I talk to service providers who say "relay" but mean "B2BUA application server". -- Ben: Raises an example that I didn't fully catch ... Hadriel agrees that this is the example he was thinking of that causes the system to fail slowly (due to TCP time-outs) -- Comment: This draft would definitely benefit from concrete examples -- At SIPit there were 5 MSRP clients that interoperated, but only one implemented instant messages (all others implemented file transfer) -- No client code is out there. Someone needs to agree to try this before we move to RFC. (Hadriel: Many implementors are waiting for a stable specification before they go and code). SIMPLE Chat - Nicknames - Mary -- Chair: Who Cares? 5-10 hands -- Jonathan: Who plans to ship a product that uses this? 2-3 hands (Including Cullen - Cisco ) -- Requirement came from OMA (Standard rant - If these people care, why are they here [or on the list] to help us finish it) -- Miguel says that OMA may no longer have a requirement for this work -- XCON chat is on the Agenda for Thursday's XCON session -- Chair: Assuming we get this to last call in the next 6 weeks, who will participate in last call? [small number of hands] -- Adam: This was intended as a short-cut to ensure we got something out the door for OMA before XCON finished its work. If OMA no longer cares, then I'm torn about what to do with this work. -- Markus: OMA has a similar spec [IETF took too long to come up with this shortcut]. We'd love to implement this in our client if anyone were going to implement a server. -- Mary: XCON gives you this functionality for free. -- Comment: We should finish this work. Then it is likely that OMA will update to point to this RFC. -- People who are implementing this aren't getting hung up on the nickname thing, the way we are. SIMPLE Presence with Continuous Values - Martin Thomson -- Motivated by OMA LOCSIP effort -- We're too late to prevent OMA from publishing LOCSIP, but hopefully we can ensure that what they do interoperates with IETF standards -- Location isn't special, it's just like any continuous value. [Although Location is somewhat special in that people actually care about it]. -- OMA considering both Presence or an alternative event mechanism. We believe Presence is the right answer and hopefully if we build the right mechanisms into presence then OMA will use it. -- Key Conclusion: Feedback loop between the Presence Agent and the Watcher needs to be improved -- Jonathan: The draft is very focused on the Watcher requirements (and not presentity privacy, which is paramount in many applications). I think there's a higher-level set of requirements that is driving these mechanisms (these high-level application requirements seem to be different than classic presence use-cases). These should be better documented. -- Steve Norris: What happens with numerous watchers asking for different things from the source? This could quickly become difficult to deal with. -- Martin: I don't think this is limited in any way, other than limitations that exist in traditional presence. -- Jon AD: Many things that we typically include in presence are discrete values sampled from some continuous value. This draft is a good first stab at specifying the distinction between the sampling process and the discrete values they produce. I think the distinction is valuable. We should better understand the requirements (kinds of applications you're trying to enable), even if we end up finding out that there's other ways (that introduce less complexity) to meet these requirements. ... This could turn out to be quite complicated (e.g. require an entirely new end-to-end negotiation problem). -- Adam: Well-written document. I'd like to see it as a basis for something that meets these requirements. Comment: We lose some ability to innovate, once you're gone and reduced data to application-specific discrete values. Pushing these values to the edge is a good idea in the SIP framework. -- This might be difficult, we should make sure that it's worth while. -- Richard: Doesn't this come up with discrete values where there's a probability of error. (e.g. whenever there's a quality/cost trade-off). -- Jon AD: I certainly agree that we don't want to give up any of our power as application developers. -- Rosen: I like this document a lot, I think it should go forward. The general problem is real. It has application beyond location, but location is a good example. I have text comments but those can wait. -- Chair: Take scope discussions to the list. Chip in and help us make progress with this. POKE - -- Goal: Request Attention of User (e.g. buzz, vibrate) -- Sender can specify preference for how user is alerted (e.g. vibrate preferred) -- Is there working group interest? -- Adam: I understand the value of something along these lines (for feature parity with existing IM systems). Support simple poke, without fine-grain control -- Jonathan: I agree. Is anyone planning to implement this feature? -- Comment: I would first implement the functionality to block this -- Question: Who would turn this feature off if their client supported it. -- Adam: I don't think we're the target audience for this feature -- Comment: We've standardized this in XMPP and there exist clients that implement it. I'd never use it, but we standardize all sort of features because some kids want it. -- Adam: Saying "I won't use this get off my lawn" doesn't help "I like being poked on facebook, it's a lot of fun" - Cullen -- Cullen: We should do the simple version of this. But we need this feature to have a competitive IM client in the marketplace. -- Ben: Receiver needs control of how this is rendered. -- Andrew: Agree with Ben. Also, do we need XML for this. Could we just put something in the Alert-Info header? -- Chair: We're not ready for WG adoption yet. People who find this interesting and will actually implement or work on it, should get with the author and build consensus on something that can become a WG item. -- Look towards RFC 3994