[Simple] draft minutes for SIMPLE at IETF73

[Robert Sparks <[e-mail]>]

Please review. Send comments/corrections to the list or directly to  
the chairs ASAP.

RjS
-------

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

<see slides for changes in new version>

--  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

<see slides for changes in new version>

-- 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 <grin>)

-- 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.

<I think I missed a comment>

-- 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 - <I believe it was Garcia who presented>

-- 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

_______________________________________________
Simple mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/simple