Subject: [Simple] msrp-acm and msrp-relay client interworking

From: Hisham Khartabil <[email-masked]>
Date: Mon, 2 Mar 2009 15:24:11 +1100

Hi All,

There seems to be an online debate on how strong a requirement is that
an msrp-acm client must be able to communicate with an msrp-relay
client using an MSRP session set up using SIP/SDP as signalling
protocols. This is a poll requesting input to see if this is indeed a
requirement. Please reply directly tot he mailing list.

Thanks,
Hisham

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 2 Mar 2009 07:04:21 +0100

Hi,

It can be done with an interworking B2BUA.

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hisham Khartabil
> Sent: 2. maaliskuuta 2009 6:24
> To: Simple WG
> Subject: [Simple] msrp-acm and msrp-relay client interworking
> 
> Hi All,
> 
> There seems to be an online debate on how strong a 
> requirement is that an msrp-acm client must be able to 
> communicate with an msrp-relay client using an MSRP session 
> set up using SIP/SDP as signalling protocols. This is a poll 
> requesting input to see if this is indeed a requirement. 
> Please reply directly tot he mailing list.
> 
> Thanks,
> Hisham
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 2 Mar 2009 01:05:40 -0500

Well if you're going to ask for a vote on that, I suppose it's only fair that I actually argue *why* I don't think it's a requirement.  First, I vote "no" it's not a requirement.

And here's my rationale:
1) The MSRP Relay idea was actually a bad idea.  Think about it.  You're creating a protocol to not only send instant-messages now and then in an IM session, but to in fact transfer files - possibly really BIG files.  There are a bunch of folks that want to do that with MSRP.  Some of them are even delay-sensitive, like white-boarding and remote GUI control.  Would you perform bulk file transfer through application-layer relays?  Note this isn't a socket relay - but actual signaling relays that terminate TLS/TCP, parse text messages, and route each chunk/message using what effectively amounts to a SIP Via/Route list inside the message.  You might as well have just sent hundreds of SIP MESSAGE requests with binary MIME attached payloads of the chunks.  It's a really bad protocol idea.

2) The main driver for MSRP Relays, as far as I can tell, is to cross NATs.  Even if you don't like how SBC's do that, it doesn't take a super-genius to figure out TURN at least is a better protocol for this than MSRP Relays.  If you're using TURN, you don't need MSRP Relays.

3) One of the reasons (in fact the only reason, IMHO) to support MSRP Relays is because of the installed base.  I appreciate that, a lot.  Interworking with an installed base is something I like, because it means more people using it, which means wider and faster adoption, which is more money for me in the end (I hope).  But there isn't an installed base.  I don't know how to say this without sounding like a jerk, but if the msrprelay.org site only has 50,000 users, then it's basically a field trial in east-Latvia for some of us.  Compare it to the 50 *Million* Jabber/XMPP users.  And as far as I've heard that MSRP-Relay project is the big one.  If their goal is to help NAT traversal of MSRP, a TURN server project would do it - and would be usable for things other than MSRP.

4) What msrp-acm is proposing is NOT to deprecate RFC 4976.  If people want to use Relays, that's cool.  Clients can continue to support it as well.  All msrp-acm is doing is offering a different relay model, for those who wish to use it.  And the market can decide if one is more useful, or both can be used.  That is *actually* the IETF way.  RFC 4976 is a Proposed Standard, nothing more.  It's not gospel.  We don't have to have one and only one way to use MSRP, and we're not constrained from making changes to it.  And luckily we actually have a capability advertisement protocol (SDP) at our disposal to negotiate which mode.  It would be one thing if we were talking about HTTP or SIP - something with a very large installed base, and a long history of use.  But with MSRP Relays we're not.  Not by a long shot.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hisham Khartabil
>

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 2 Mar 2009 10:37:44 +0200

> requirement. Please reply directly tot he mailing list.

As Hadriel said, and as I mentioned on this mailing list and on BEHAVE on 
several occasions, multiplexing independent bulk transfers over hop-by-hop TCP 
is a *BAD* idea.

To me, MSRP relays are broken -beyond repair- by design. I would not mind if 
MSRP-ACM does not interwork with those. A fortiori, I would really not care if 
those two can be made interwork albeit with some non-IETF architecture 
components.

I anyway believe MSRP relays don't exist except as spec and prototypes.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Mar 2009 14:46:23 -0600

Registering my vote, before responding to other entries on the thread:

I vote yes. I don't want to  encourage people to deploy islands of non- 
interoperable endpoints.  If they want that for policy reasons, fine,  
but it should not happen due to technological reasons. If we go down  
the path of the current ACM draft, we will almost certainly get the  
scenario where my provider forces me to use a relay, and your provider  
forces you to use an SBC, and we therefore can't talk.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Mar 2009 14:59:01 -0600

> It can be done with an interworking B2BUA.

I think it can also be done with a minor modification to the way MSRP  
endpoint map incoming messages to sessions. I'm not sure this works,  
but it's worth exploring. I've mentioned this in other threads, but to  
recap:

The endpoint currently maps a message to sessions by matching the URI  
in the To-Path of an inbound message to the URI that endpoint  
published in SDP. This prevents an ALG/SBC from modifying the  
addressing info in the SDP. I think we could modify this so that the  
endpoint ignores the "address" part of the URI and just matches the  
"session-ID" part and have little to no affect on the security  
properties of the URI.

This has the advantage than an intermediary could rewrite the URI in  
the same way the ACM draft encourages rewriting of the C-line, but  
also working with a peer that uses an msrp relay.

As far as I can tell, it has two disadvantages. The first is, existing  
SBC code doesn't do this now, so implementers would have to touch  
code. I think it is worth this if it allows MSRP relay compatibility  
without requiring a b2bua. (I'll leave the argument about the  
difficulty of guarantying backwards-compatibility with non- 
standardized devices to the imagination of the reader.)

The second issue is that this sort of rewrite can interfere with TLS  
certificate matching. However, I think this will also be true if we  
follow the ACM draft, and an SBC rewrites the C-line. This part needs  
further study.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Mar 2009 15:18:56 -0600

On Mar 2, 2009, at 12:05 AM, Hadriel Kaplan wrote:

>
> Well if you're going to ask for a vote on that, I suppose it's only  
> fair that I actually argue *why* I don't think it's a requirement.   
> First, I vote "no" it's not a requirement.
>
> And here's my rationale:
> 1) The MSRP Relay idea was actually a bad idea.  Think about it.   
> You're creating a protocol to not only send instant-messages now and  
> then in an IM session, but to in fact transfer files - possibly  
> really BIG files.  There are a bunch of folks that want to do that  
> with MSRP.  Some of them are even delay-sensitive, like white- 
> boarding and remote GUI control.  Would you perform bulk file  
> transfer through application-layer relays?  Note this isn't a socket  
> relay - but actual signaling relays that terminate TLS/TCP, parse  
> text messages, and route each chunk/message using what effectively  
> amounts to a SIP Via/Route list inside the message.  You might as  
> well have just sent hundreds of SIP MESSAGE requests with binary  
> MIME attached payloads of the chunks.  It's a really bad protocol  
> idea.

Lots of this comes from the requirement for connection sharing. There  
was work group consensus that this was a requirement. That consensus  
was tested over and over.  We also had consensus that MSRP relays  
needed to be able to act as policy enforcement points and/or message  
loggers. This was for things like trading-floor applications that are  
heavily regulated.

I'm not saying everyone needs those things. But if we don't require  
interoperability, then anyone who really needs relays is effectively  
prevented from deploying them. (I assume communicating with other MSRP  
users is a pretty big requirement for MSRP deployments.)

>
>
> 2) The main driver for MSRP Relays, as far as I can tell, is to  
> cross NATs.  Even if you don't like how SBC's do that, it doesn't  
> take a super-genius to figure out TURN at least is a better protocol  
> for this than MSRP Relays.  If you're using TURN, you don't need  
> MSRP Relays.

I think TURN-TCP is a fine choice if you don't need any of the other  
features of MSRP relays. Furthermore, it should be able to interop  
with 4975 relays. Furthermore, I don't think it requires the ACM draft  
to work (although the comedia parts would make it cleaner.) I suspect  
this is true of other relay protocols such as SOCKS.

>
>
> 3) One of the reasons (in fact the only reason, IMHO) to support  
> MSRP Relays is because of the installed base.  I appreciate that, a  
> lot.  Interworking with an installed base is something I like,  
> because it means more people using it, which means wider and faster  
> adoption, which is more money for me in the end (I hope).  But there  
> isn't an installed base.  I don't know how to say this without  
> sounding like a jerk, but if the msrprelay.org site only has 50,000  
> users, then it's basically a field trial in east-Latvia for some of  
> us.  Compare it to the 50 *Million* Jabber/XMPP users.  And as far  
> as I've heard that MSRP-Relay project is the big one.  If their goal  
> is to help NAT traversal of MSRP, a TURN server project would do it  
> - and would be usable for things other than MSRP.

As MSRP goes right now, 50K is a big number. It's a fairly new protocol.

The number of jabber users is really a non-sequitur here, unless we  
want to argue about whether one should use MSRP _at_all_.   A more  
fair comparison would be the number of MSRP capable UAs that sit  
behind SBCs. Or even users behind SBCs that would actually use MSRP in  
the near future if it worked over the SBC.

>
>
> 4) What msrp-acm is proposing is NOT to deprecate RFC 4976.  If  
> people want to use Relays, that's cool.  Clients can continue to  
> support it as well.  All msrp-acm is doing is offering a different  
> relay model, for those who wish to use it.  And the market can  
> decide if one is more useful, or both can be used.  That is  
> *actually* the IETF way.  RFC 4976 is a Proposed Standard, nothing  
> more.  It's not gospel.  We don't have to have one and only one way  
> to use MSRP, and we're not constrained from making changes to it.   
> And luckily we actually have a capability advertisement protocol  
> (SDP) at our disposal to negotiate which mode.  It would be one  
> thing if we were talking about HTTP or SIP - something with a very  
> large installed base, and a long history of use.  But with MSRP  
> Relays we're not.  Not by a long shot.

We keep saying that no one is advocating we deprecate RFC 4976. Is it  
better to consign it to a technology ghetto? The effect is pretty much  
the same--an implicit deprecation is still a deprecation, even if we  
pretend it's not.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 3 Mar 2009 22:08:11 -0500

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, March 03, 2009 4:19 PM
>
> was tested over and over.

I'm not sure I understand what you mean by that.  Who needs connection sharing?  The MSRP UA?  It's only sharing the TCP socket, but each MSRP session is still unique within it, no?  People were worried about the number of TCP connections for IM on a UA??  Compared with what AJAX and normal web browsing uses at any given time??

Maybe you mean for the MSRP Relay's benefit?  But that's a circular argument.

> We also had consensus that MSRP relays

You don't need a Relay for that, either.  And in fact I seriously doubt an MSRP Relay is even sufficient for their needs.  The trading floor folks I've talked to refuse to allow trading partners learn the IP Addresses of the trading consoles or PCs of other traders.  You can probably imagine why that would be.  So they won't be letting the URL's identify the UA's, as is done in the RFC.  More importantly, they also need to monitor the SIP signaling associated with the session, and bind the two together in the logs, so at the end of the day what they really need is an MSRP B2BUA, controlled by the SIP signaling.  Now maybe its just paranoid folks I talk to, but my point is if you're in a type of situation that requires that level of control, you're probably not going to just use a simple Relay model anyway.  (that's in fact why draft-macdonald-simple-msrp-opaque-path-00 was written, to let the UA get privacy by anonymizing the MSRP URL's)

> the near future if it worked over the SBC.

Well I can't speak for how many are MSRP-capable today, because I don't make endpoints.  I do know of one softclient vendor that is deployed behind SBC's that has MSRP in a recent software release, but I don't know how many of that release they've shipped, or how many of them are behind SBCs.  I also know of at least one mobile handset vendor that wants to add MSRP, and they're behind SBCs.  And I know of at least two operators that want to use MSRP, but can't do so without ACM.  Each one of them represents far more than 50k users (orders of magnitude more users, but I don't know how many will do MSRP).  But as for total SIP UA endpoints behind SBC's, it's orders of magnitudes greater than 50k today.  Even just softclients it's at least one order of magnitude greater, maybe more.  On the Service Provider side, access-side SBC's typically range anywhere from 10k-200k SIP UA's per system (and some a lot more than that now).  I only work for one of many SBC vendors, but even we've sold several thousands of SBC's, and the rate is increasing.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 3 Mar 2009 22:41:26 -0500

> Of Ben Campbell
> Sent: Tuesday, March 03, 2009 3:59 PM
>

This still requires the MSRP UA *and* the MSRP Relay to change from current behavior, no?  The MSRP Relay will be getting a from-path URL in the MSRP Message of the remote UA that does not match the remote IP/port info for the socket, because the remote IP/port of the socket would be the SBC's.

If changing current Relay behavior is in-scope, then this would be easy I think.  As would privacy-anonymization, for that matter.

> without requiring a b2bua.

That's not a problem for my particular company's SBCs (you can just configure us to do that, with no code changes).  It's not as good as the current ACM because that didn't even need configuration changes for current deployments, but that's life.  But I can't speak for the other vendors.  Many of them don't even seem to monitor the IETF lists. :(

> follow the ACM draft, and an SBC rewrites the C-line. This part needs

I know we're successfully supporting Comedia-TLS in deployments, letting the TLS go end-end being relayed by the SBC.  But those are undoubtedly without SAN verification, since they rarely even have SAN's.  I thought MSRP also ultimately ignored the SAN and used the SDP fingerprint instead, no?

-hadriel

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Mar 2009 21:47:09 -0600

On Mar 3, 2009, at 9:08 PM, Hadriel Kaplan wrote:

> I'm not sure I understand what you mean by that.  Who needs  
> connection sharing?  The MSRP UA?  It's only sharing the TCP socket,  
> but each MSRP session is still unique within it, no?  People were  
> worried about the number of TCP connections for IM on a UA??   
> Compared with what AJAX and normal web browsing uses at any given  
> time??
>

People we worried about the number of connections between a pair of  
relays. If you use TURN-TCP at both ends, for example, you have 3 TCP  
connections per session at each TURN server. Same for a pair of TCP  
aware SBCs, or MSRP B2BUAs, etc.

Is this a problem? It depends on how a given platform scales to  
massive numbers of TCP connections. Also, at least at the time, a  
large number of parallel TCP connections was considered to have poorer  
congestion properties than a smaller number. (Alas, my TCP-fu is not  
advanced enough for me to have an opinion on the congestion issue--I  
am merely restating the arguments we had then.)

> You don't need a Relay for that, either.  And in fact I seriously  
> doubt an MSRP Relay is even sufficient for their needs.  The trading  
> floor folks I've talked to refuse to allow trading partners learn  
> the IP Addresses of the trading consoles or PCs of other traders.   
> You can probably imagine why that would be.  So they won't be  
> letting the URL's identify the UA's, as is done in the RFC.  More  
> importantly, they also need to monitor the SIP signaling associated  
> with the session, and bind the two together in the logs, so at the  
> end of the day what they really need is an MSRP B2BUA, controlled by  
> the SIP signaling.  Now maybe its just paranoid folks I talk to, but  
> my point is if you're in a type of situation that requires that  
> level of control, you're probably not going to just use a simple  
> Relay model anyway.  (that's in fact why draft-macdonald-simple-msrp- 
> opaque-path-00 was written, to let the UA get privacy by anonymizing  
> the MSRP URL's)

I'm not saying that MSRP relays necessarily support all the features  
that a particular market needs--I expect there to be many extensions  
to both RFCs before the dust settles. My point was that the features  
we considered at the time required it to operate at the application  
layer. That is, it had to know how to parse MSRP rather than merely  
shuffle bytes.

But to restate my earlier point: If all a deployment needs is relay- 
assisted NAT traversal, and TCP connection scaling is not a concern,  
then I think TURN-TCP is an excellent solution. But that's not what  
the ACM draft is about.

> Well I can't speak for how many are MSRP-capable today, because I  
> don't make endpoints.  I do know of one softclient vendor that is  
> deployed behind SBC's that has MSRP in a recent software release,  
> but I don't know how many of that release they've shipped, or how  
> many of them are behind SBCs.  I also know of at least one mobile  
> handset vendor that wants to add MSRP, and they're behind SBCs.  And  
> I know of at least two operators that want to use MSRP, but can't do  
> so without ACM.  Each one of them represents far more than 50k users  
> (orders of magnitude more users, but I don't know how many will do  
> MSRP).  But as for total SIP UA endpoints behind SBC's, it's orders  
> of magnitudes greater than 50k today.  Even just softclients it's at  
> least one order of magnitude greater, maybe more.  On the Service  
> Provider side, access-side SBC's typically range anywhere from  
> 10k-200k SIP UA's per system (and some a lot more than that now).  I  
> only work for one of many SBC vendors, but even we've sold several  
> thousands of SBC's, and the rate is increasing.
>
> -hadriel

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Mar 2009 22:04:13 -0600

On Mar 3, 2009, at 9:41 PM, Hadriel Kaplan wrote:

> This still requires the MSRP UA *and* the MSRP Relay to change from  
> current behavior, no?  The MSRP Relay will be getting a from-path  
> URL in the MSRP Message of the remote UA that does not match the  
> remote IP/port info for the socket, because the remote IP/port of  
> the socket would be the SBC's.
>

On reflection, I guess it would require rewriting relay URIs as well,  
so probably yes.

> If changing current Relay behavior is in-scope, then this would be  
> easy I think.  As would privacy-anonymization, for that matter.
>

Revisions for these two purposes seems reasonable to me on the  
surface, assuming that once we work through the implications, we don't  
discover that they either just don't work, or cause more harm than  
good. I am certainly not the final arbiter of what we are allowed to  
change.

> That's not a problem for my particular company's SBCs (you can just  
> configure us to do that, with no code changes).  It's not as good as  
> the current ACM because that didn't even need configuration changes  
> for current deployments, but that's life.  But I can't speak for the  
> other vendors.  Many of them don't even seem to monitor the IETF  
> lists. :(
>
>
> I know we're successfully supporting Comedia-TLS in deployments,  
> letting the TLS go end-end being relayed by the SBC.  But those are  
> undoubtedly without SAN verification, since they rarely even have  
> SAN's.  I thought MSRP also ultimately ignored the SAN and used the  
> SDP fingerprint instead, no?

I assume SAN == subjectAltName?

4975 allows self-signed UA certs with the fingerprint (from Comedia- 
TLS.) It also allows client certs with user identities in the  
subjectAltName. Either of those should work with either approach.

  It might be harder for TLS between a client and a relay, though. The  
relay is expected to have a cert that has a match for its URI in the  
subjectAltName. I can see that working if the SBC and relay are in the  
same administrative domain, but it falls down otherwise. That may be a  
show stopper, or at least needs more thought.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 4 Mar 2009 07:26:39 +0100

Hi Ben,

>I think it can also be done with a minor modification to the 
>way MSRP endpoint map incoming messages to sessions. I'm not 
>sure this works, but it's worth exploring. I've mentioned 
>this in other threads, but to
>recap:
> 
>The endpoint currently maps a message to sessions by matching 
>the URI in the To-Path of an inbound message to the URI that 
>endpoint published in SDP. This prevents an ALG/SBC from 
>modifying the addressing info in the SDP. I think we could 
>modify this so that the endpoint ignores the "address" part 
>of the URI and just matches the "session-ID" part and have 
>little to no affect on the security properties of the URI.
> 
>This has the advantage than an intermediary could rewrite the 
>URI in the same way the ACM draft encourages rewriting of the 
>C-line, but also working with a peer that uses an msrp relay.
> 
>As far as I can tell, it has two disadvantages. The first is, 
>existing SBC code doesn't do this now, so implementers would 
>have to touch code. I think it is worth this if it allows 
>MSRP relay compatibility without requiring a b2bua. (I'll 
>leave the argument about the difficulty of guarantying 
>backwards-compatibility with non- standardized devices to the 
>imagination of the reader.)
> 
>The second issue is that this sort of rewrite can interfere 
>with TLS certificate matching. However, I think this will 
>also be true if we follow the ACM draft, and an SBC rewrites 
>the C-line. This part needs further study.

So, just for my clarification: this modified way of mapping incoming
messages would be an correction to legacy MSRP endpoints, right?

Also, I assume that would be described in a separate draft, since it's
not ACM specific?

Regards,

Christer

> >> There seems to be an online debate on how strong a requirement is 
> >> that an msrp-acm client must be able to communicate with an 
> >> msrp-relay client using an MSRP session set up using SIP/SDP as 
> >> signalling protocols. This is a poll requesting input to 
> see if this 
> >> is indeed a requirement.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 4 Mar 2009 12:15:24 +0100

Hi,

Also, IF we do the message session mapping change, I assume it would be
documented as an essential change? Ie we document which parts of the RFC
needs to be fixed.

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 4. maaliskuuta 2009 8:27
> To: Ben Campbell
> Cc: Simple WG
> Subject: Re: [Simple] msrp-acm and msrp-relay client interworking
> 
>  
> Hi Ben,
> 
> way MSRP 
> >in the To-Path of an inbound message to the URI that 
> endpoint published 
> >in SDP. This prevents an ALG/SBC from modifying the 
> addressing info in 
> >the SDP. I think we could modify this so that the endpoint 
> ignores the 
> >"address" part of the URI and just matches the "session-ID" part and 
> >have little to no affect on the security properties of the URI.
> > 
> >the same way the ACM draft encourages rewriting of the 
> C-line, but also 
> >working with a peer that uses an msrp relay.
> > 
> >SBC code doesn't do this now, so implementers would have to 
> touch code. 
> >I think it is worth this if it allows MSRP relay 
> compatibility without 
> >requiring a b2bua. (I'll leave the argument about the difficulty of 
> >guarantying backwards-compatibility with non- standardized 
> devices to 
> >the imagination of the reader.)
> > 
> So, just for my clarification: this modified way of mapping 
> incoming messages would be an correction to legacy MSRP 
> endpoints, right?
> 
> Also, I assume that would be described in a separate draft, 
> since it's not ACM specific?
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> requirement is

---

From: Ben Campbell <[email-masked]>
Date: Wed, 4 Mar 2009 09:39:02 -0600

> Also, I assume that would be described in a separate draft, since it's

Assuming it proves to be worth doing, that's how I would expect things  
to go.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 4 Mar 2009 09:40:19 -0600

> documented as an essential change? Ie we document which parts of the  

Again assuming we decide this approach is worth pursuing, that is what  
I had in mind.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 4 Mar 2009 20:14:11 +0100

Ok,

Due to the cutoff date I guess it's too late to submit an essential
correction draft for this meeting, but nothing prevents us from putting
some slides toghether which would show the changes which are needed.

Regards,

Christer

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Wednesday, March 04, 2009 5:40 PM
To: Christer Holmberg
Cc: Simple WG
Subject: Re: [Simple] msrp-acm and msrp-relay client interworking

On Mar 4, 2009, at 5:15 AM, Christer Holmberg wrote:

>
> Hi,
>
> Also, IF we do the message session mapping change, I assume it would 
> be documented as an essential change? Ie we document which parts of 
> the RFC needs to be fixed.

Again assuming we decide this approach is worth pursuing, that is what I
had in mind.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 4 Mar 2009 13:39:53 -0600

> some slides toghether which would show the changes which are needed.

Agreed. I had hopes to get a draft together by the cutoff, but my  
schedule got whacked by a badly timed cold virus over the weekend. It  
might be worth trying to get a f2f meeting of interested parties  
together in SF prior to the SIMPLE meeting to talk this through.