Subject: [plasma] why not web portal mail?

From: Trevor Freeman <[email-masked]>
Date: Wed, 6 Apr 2011 19:33:19 +0000

Stephen Farrell asked why not use Web portal mail? Why do we need to develop plasma?

I don't think we concisely answered that question in the BoF and it is an important data point.

The web portal mail products are used where there is no way to securely deliver sensitive mail to a recipient outside the sender's organization. The message is held within the sender's organization and a notification email is sent to the recipient.  The notification email contains a HTTPS URI to the original message with the sensitive content.

This model work Ok if it is bilateral communication e.g. doctor-patient where you want to reply to the sender. This has been deployed with my healthcare provider and we can exchange messages.   However the notification email are very generic by design so it hard to find specific messages in your inbox other than by date and time sent. It also means useful features like inbox search don't work as you only have the notification message in your inbox.

This model fails totally if it's multilateral communication where you want to reply all or forward to messages. The message never leaves the originators organization so you cannot originate new message as if it were from a recipient's organization. This means for business to business scenario it would hinder the use of email for collaboration.

With these limitations I think it's clear that that plasma offers some significant benefits over web portal email.

Dr Trevor Freeman  Senior Security Strategist
End to End Trust Team<http://www.microsoft.com/mscorp/twc/endtoendtrust/default.mspx>
Microsoft Trustworthy Computing <http://www.microsoft.com/mscorp/twc/default.mspx>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 08 Apr 2011 19:33:54 +0100

Hi Trevor,

On 06/04/11 20:33, Trevor Freeman wrote:
> I don’t think we concisely answered that question in the BoF and it is
> an important data point.

Thanks for trying now.

> The web portal mail products are used where there is no way to securely
> deliver sensitive mail to a recipient outside the sender’s organization.
> The message is held within the sender’s organization and a notification
> email is sent to the recipient.  The notification email contains a HTTPS
> URI to the original message with the sensitive content.  

Right.

> This model work Ok if it is bilateral communication e.g. doctor-patient
> where you want to reply to the sender. This has been deployed with my
> healthcare provider and we can exchange messages.   

Well, its also works fine for announcements, i.e. 1:N messages.

> However the
> notification email are very generic by design so it hard to find
> specific messages in your inbox other than by date and time sent. It
> also means useful features like inbox search don’t work as you only have
> the notification message in your inbox.

True. However, does that mean that you'd expect the UA search
function to be plasma-aware? If not, then won't the sensitive
information be vulnerable in whatever search DB the UA uses?
Maybe that's a question of defining the trust boundaries for
this, but given that the search may be on an IMAP server its
possibly complicated doing that in a secure way.

> This model fails totally if it’s multilateral communication where you
> want to reply all or forward to messages. 

Hmm. So that'd imply that forwarding etc. is an important
part of the proposed work? It strikes me that that's one of the
weakest aspects of generic s/mime (just from personal experience,
its not something I've gone out of my way to test). There'd also
be some pretty complex policy calculations to make to figure
out what can be forwarded to whom, I assume, so this seems like
a fairly complex area.

> The message never leaves the
> originators organization so you cannot originate new message as if it
> were from a recipient’s organization. This means for business to
> business scenario it would hinder the use of email for collaboration.

I don't get that at all. But never mind.

> With these limitations I think it’s clear that that plasma offers some
> significant benefits over web portal email.

Not that clear to me I'm afraid.

While you're arguing for plasma on this basis, to judge those arguments
people would need some kind of evidence that's a good bit better than
just an assertion. But I'm sure you guys are working on that.

S.

> 
>  
> 
> *Dr Trevor Freeman*  Senior Security Strategist
> 
> *End to End Trust Team*
> <http://www.microsoft.com/mscorp/twc/endtoendtrust/default.mspx>**
> 
> *Microsoft Trustworthy
> Computing*<http://www.microsoft.com/mscorp/twc/default.mspx> 
> 
>  
> 
> 
> 
> _______________________________________________
> plasma mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/plasma

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 12 Apr 2011 00:02:14 +0000

Hi Steve,

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Friday, April 08, 2011 11:34 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: [plasma] why not web portal mail?

Hi Trevor,

On 06/04/11 20:33, Trevor Freeman wrote:

> Stephen Farrell asked why not use Web portal mail? Why do we need to

> develop plasma?

> I don't think we concisely answered that question in the BoF and it is

Thanks for trying now.

> The web portal mail products are used where there is no way to

> securely deliver sensitive mail to a recipient outside the sender's organization.

> The message is held within the sender's organization and a

> notification email is sent to the recipient.  The notification email

> contains a HTTPS URI to the original message with the sensitive content.

Right.

> This model work Ok if it is bilateral communication e.g.

> doctor-patient where you want to reply to the sender. This has been deployed with my

[TF] Agreed.

> also means useful features like inbox search don't work as you only

> have the notification message in your inbox.

True. However, does that mean that you'd expect the UA search function to be plasma-aware? If not, then won't the sensitive information be vulnerable in whatever search DB the UA uses?

Maybe that's a question of defining the trust boundaries for this, but given that the search may be on an IMAP server its possibly complicated doing that in a secure way.

[TF] Yes I expect search engines to become Plasma aware just as search engines have become aware of other encrypted content types. The search engine does not necessary need unrestricted access to content and the content indexed is by definition potentially sensitive so have to be controlled. However that process is a local UA process so is not in scope for Plasma. However the fact that all the user content is in their inbox makes it a tractable problem.

> This model fails totally if it's multilateral communication where you

> want to reply all or forward to messages.

Hmm. So that'd imply that forwarding etc. is an important part of the proposed work? It strikes me that that's one of the weakest aspects of generic s/mime (just from personal experience, its not something I've gone out of my way to test). There'd also be some pretty complex policy calculations to make to figure out what can be forwarded to whom, I assume, so this seems like a fairly complex area.

[TF] Not just forwarding - reply all is just as important as we have demonstrated with this thread. One of the value propositions for email is the flexible, multiparty nature of the asynchronous communication whereby groups of individuals can be part of a conversation and any recipient can participate in the thread or can spawn new threads just as we are doing here. The objective that Plasma brings is the desire to maintain a degree of policy enforcement to the process when the content of the message is either sensitive or regulated. What if, as part of my reply, I wanted to inject some information which was Microsoft confidential and was being shared under respective non-disclosure agreements? The aim of Plasma would be to allow me to add a policy check before the decryption key to my reply was disclosed to recipients to ensure every recipient was in an organization which had a current legal agreement in place. This message is using a distribution list managed outside my organization so I cannot determine the exact list of recipients at send time. If the mail list was an S/MIME MLA I could protect the confidentiality of the information so only plasma mail list subscribers can read the content but this does not satisfy the policy requirements of determining if there is a legal agreement in place.

> were from a recipient's organization. This means for business to

[TF] I think it's a critical reason for why Plasma.  Consider the scenario where this thread becomes sensitive as I suggested above and I was to use a web portal for this reply. That portal would be hosted on a Microsoft corporate server since I invoked the sensitivity clause and you would have received a notification email instead of the actual email. If you were to further reply all or forward that messages the origination point for that message would be from a Microsoft corporate server. The Microsoft server would in turn send out an email notification with a FROM address of [email-masked]<mailto:[email-masked]> with a url of https:\\mail.microsoft.com\???

This seems a highly dubious pattern which matches the pattern used by phishers and spammers. How could you expect Microsoft to be authoritative for sending mail as someone from Trinity College Dublin to all the recipients on the distribution list?

What is the scenario was reversed and we used a web portal in your domain and I still wanted to add some Microsoft sensitive information to the thread. How would your portal know what my corporate rulers were if I were to reply all?

> With these limitations I think it's clear that that plasma offers some

While you're arguing for plasma on this basis, to judge those arguments people would need some kind of evidence that's a good bit better than just an assertion. But I'm sure you guys are working on that.

[TF] Yes that is what dialog is about:)

S.

> [email-masked]<mailto:[email-masked]>

---

From: "Whitlock, Stephen" <[email-masked]>
Date: Tue, 12 Apr 2011 06:30:34 -0700

So, would Plasma allow me to create/modify a set of allowed recipients to a conversation conducted over a public network by just changing policies on the messages? And would this work across different vendor's e-mail systems?

Steve W

From: [email-masked] [mailto:[email-masked]] On Behalf Of Trevor Freeman
Sent: Monday, April 11, 2011 5:02 PM
To: Stephen Farrell
Cc: [email-masked]
Subject: Re: [plasma] why not web portal mail?

Hi Steve,

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Friday, April 08, 2011 11:34 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: [plasma] why not web portal mail?

Hi Trevor,

Thanks for trying now.

Right.

[TF] Agreed.

S.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 12 Apr 2011 16:21:25 +0200

> Stephen Farrell asked why not use Web portal mail? Why do we need to develop plasma?

Maybe that question is easier to answer if we consider plasma for XMPP
and not just for email. There are important differences between XMPP
and email that make it much more challenging to build web-only versions
of the XMPP.

	Cheers Leif

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Apr 2011 11:13:24 -0400

I don't think it actually helps to artificially narrow the scope of the use
cases.

The real use cases here are of the form 'Alice wants to protect her
information against unintended disclosure'.

It may make sense to restrict the initial detailed specification to a single
protocol, but the architecture has to be designed with the general case in
mind from the start. Otherwise we end up with a hack that enables policy to
be used with SMTP based email but nothing else.

My experience is that special case protocols start off more complex and
become even more so over time than proposals that start from the general
case. FTP is actually a far more involved protocol than HTTP with far more
features and complexity. But HTTP is actually the more flexible protocol
because of that (try layering your Web Service over FTP and let me know how
it works for you). Insisting on generality forces people to give up their
special case hacks and results in a cleaner result.

The starting point as I see it should be an identifier for security
policies. Make it easy for the end user to specify that document X is under
control of policy Y. Since we want the policy identifiers to be easy to
remember and want an infinite registry space of them, this results in the
user presentation looking something like:

policyname#example.com

And it is convenient to also have a URI form.

policy:example.com/policyname

We thus have separate forms of the identifier for human readability and
machine readability.

It is pretty easy to see that anyone who wants to define policies can do so
by registering a domain name. Also we have a fairly clear mapping from the
DNS to the some sort of policy service.

The policy service is of course going to be some sort of Web Service that we
discover by means of the DNS. We may well have a separate mechanism (e.g. CA
certs) for establishing trust. But that is something to defer to much later.

Given a web service to support the security policy management protocol we
can now interrogate it to ask queries of the form 'how do I apply policy X
to object Y in the context of operation Z'.

So we have an architecture that is completely general and can in theory be
used to support any protocol whatsoever without special casing.

The next question is going to be whether the policy enforcement is going to
be discretionary or mandatory (yeah, I know the terms are polluted, but I
can't think of better words).

The traditional approach to CRM has been to try to design systems where the
data is protected with cryptography and there is no way for the end user to
evade the controls. That is desirable in some cases but not if it limits the
scope of the policy language to features that can be enforced
cryptographically.

I think that the enforcement mechanism for a policy should itself be a
policy issue. So just like an auth scheme that allows username password for
low security sites and requires 2 factor for banking sites, we might have a
policy mechanism that might allow data controlled by a low restriction
security policy to be passed with an 'advisory' note while top secret
documents would be exchanged encrypted.

Now as far as deployment incentives go, I think the big one for me would be
to have a mechanism that would make S/MIME actually work as an email
mechanism which at the moment it does not. None of the clients implement an
effective cert discovery mechanism by default and so most mail is sent
without S/MIME.

So I would look at ways to combine the policy mechanism with the cert
discovery mechanism.

If PLASMA ends up being another option on a protocol with unusable
implementations, there is not much point.

On Tue, Apr 12, 2011 at 10:21 AM, Leif Johansson <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk2kX+UACgkQ8Jx8FtbMZndeOwCcC1BQafbUXYLHJZKxsuAcV8eS
> 6ukAnA0JGhMsLdmh+WG+GqEUoVMWj7+e
> =5lPF
> -----END PGP SIGNATURE-----

-- 
Website: http://hallambaker.com/

---

From: Leif Johansson <[email-masked]>
Date: Tue, 12 Apr 2011 17:33:35 +0200

> I don't think it actually helps to artificially narrow the scope of the use

so basically you agree with me ;-)

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 12 Apr 2011 18:36:44 +0000

The degree to which the send wants to retain control over the policies on subsequent messages is a policy for the sender. So far I have seen three types of binding for subsequent messages.

1.       None. This is the case where the need to bind policy ended on delivery to the recipient. This is the case with scenarios like business to consumer where it's the consumer's data e.g. a statement or health record.

2.       Append allowed. This is where the original policies are preserved and subsequent messages could have a policy appended (a logical policy AND). This is the case with scenarios like replay all for business to business where the subsequent message has the original content plus some new content. The user replaying to the original message needs to add their policy because they added some sensitive or regulated content.

3.       Alternate allowed. This is where the original policies are preserved and subsequent messages could have an alternate policy applied (a logical policy OR). This is the case with forwarded business to business where the originator is delegating to the recipients the ability to provide an equivalent policy for its community of interest.
The first is easy to deliver since it has no expectations on the client. The latter two are a higher bar and put some level of trust in the client. In these case over time you will likely want some claim about the state of health of the client before you release the decryption key.

From: Whitlock, Stephen [mailto:[email-masked]]
Sent: Tuesday, April 12, 2011 6:31 AM
To: Trevor Freeman; Stephen Farrell
Cc: [email-masked]
Subject: RE: [plasma] why not web portal mail?

Steve W

Hi Steve,

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Friday, April 08, 2011 11:34 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: [plasma] why not web portal mail?

Hi Trevor,

Thanks for trying now.

Right.

[TF] Agreed.

S.

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 12 Apr 2011 18:41:46 +0000

If you consider XMPP case it is easier because there is no expectation of data persistence. It's a synchronous protocol where all parties are online together exchanging information and that information is not persisted one the session is ended.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: Tuesday, April 12, 2011 7:21 AM
To: [email-masked]
Subject: Re: [plasma] why not web portal mail?

> Stephen Farrell asked why not use Web portal mail? Why do we need to develop plasma?

Maybe that question is easier to answer if we consider plasma for XMPP and not just for email. There are important differences between XMPP and email that make it much more challenging to build web-only versions of the XMPP.

	Cheers Leif

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Apr 2011 15:31:29 -0400

If we consider the Word, Excel and Diplomatic cables examples, the data is
static and to be controlled under a policy regardless of what channels it
might be transferred or transmitted through.

The protocol requirement here in my view is to enable applications to
determine how to apply the security policy identified as X to the data
object Y.

On Tue, Apr 12, 2011 at 2:41 PM, Trevor Freeman <
[email-masked]> wrote:

> If you consider XMPP case it is easier because there is no expectation of
> data persistence. It's a synchronous protocol where all parties are online
> together exchanging information and that information is not persisted one
> the session is ended.
>
> Maybe that question is easier to answer if we consider plasma for XMPP and
> not just for email. There are important differences between XMPP and email
> that make it much more challenging to build web-only versions of the XMPP.
>
>        Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Tue, 12 Apr 2011 22:55:12 +0200

> If you consider XMPP case it is easier because there is no expectation of data persistence. It's a synchronous protocol where all parties are online together exchanging information and that informa…

Ah no most XMPP deployments does store-and-forward (offline messages I
think its called).

	Cheers Leif

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 12 Apr 2011 14:56:50 -0600

> Ah no most XMPP deployments does store-and-forward (offline messages I

Correct:

http://xmpp.org/extensions/xep-0160.html

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 12 Apr 2011 22:52:24 +0000

Policy does not distinguish in what form the data is held. So information persisted in email is subject to the same policy as the same information persisted in a word document.

Yes we have to bind data to some set of policies. The semantics for email and documents are the same.

Overall the Alice case you cited is too simple. A more realist example is

Alice has some data and wants to apply policy X and Y to her data
Bob has some data and wants to apply policy Z to his data

Policies X, Y and Z each defines a set of authorized recipients.

Alice and Bob's data had become comingled so now policies X Y and Z have to be enforced.

In an ideal world we would want to identify Alice's and Bob's data and bind it to its respective polices.

In a less than perfect world we may enforce access at the container level which is an incremental improvement on what we have today.

From: Phillip Hallam-Baker [mailto:[email-masked]]
Sent: Tuesday, April 12, 2011 12:31 PM
To: Trevor Freeman
Cc: Leif Johansson; [email-masked]
Subject: Re: [plasma] why not web portal mail?

If we consider the Word, Excel and Diplomatic cables examples, the data is static and to be controlled under a policy regardless of what channels it might be transferred or transmitted through.

The protocol requirement here in my view is to enable applications to determine how to apply the security policy identified as X to the data object Y.

On Tue, Apr 12, 2011 at 2:41 PM, Trevor Freeman <[email-masked]<mailto:[email-masked]>> wrote:
If you consider XMPP case it is easier because there is no expectation of data persistence. It's a synchronous protocol where all parties are online together exchanging information and that information is not persisted one the session is ended.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Leif Johansson
Sent: Tuesday, April 12, 2011 7:21 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [plasma] why not web portal mail?

       Cheers Leif

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 12 Apr 2011 23:11:08 +0000

I realize at the physical level with IM it uses a sequence of messages which hare relayed server to server. Just as with VoIP, an audio stream is packaged as a sequence of IP packets. However there is no concept of long term persistence of information outside of the IM session (I am ignoring auditing). I don’t have an IM inbox.

The closest I can get is if I persist my IM history I would invoke the policy but it's not intuitive I would spawn more im sessions based on that as I would forward or reply all with email. 

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: Tuesday, April 12, 2011 1:57 PM
To: Leif Johansson
Cc: Trevor Freeman; [email-masked]
Subject: Re: [plasma] why not web portal mail?

Correct:

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Apr 2011 20:49:58 -0400

Agreed, but not actually an issue.

If we have a collection of data in a database that is controlled under the
secret#example.com policy we might have an infinite series of permutations
and subsets that could be drawn from the database.

We don't need to standardize the expression of the secret#example.com policy
or how it relates to the dataset. There might be constraints in there of the
form 'fans of Lady Gaga can only download a maximum of 1000 items', there
might be propositions that are nondeterministic, even undecidable.

All an application ever needs to deal with is the consequences of that
policy and those can be reduced to a small number of fixed actions plus
'call back for further instructions'.

There will have to be a policy language of course. But the policy language
itself does not need to be part of the standard. Its like the .NET
specification, the byte code and the APIs are standard, but that
infrastructure can support a vast array of languages.

What we need in the PLASMA standard is the range of moves used to implement
the policy.

That is good in two ways, first it is more general and a better
architecture, second it avoids the worst thickets of patent trolldom which
obsess about the idea of moving the policy itself round with the data being
controlled. That is a necessary approach for copyright enforcement which had
to support offline devices and physical media once upon a time but not for
content management in general.

On Tue, Apr 12, 2011 at 6:52 PM, Trevor Freeman <
[email-masked]> wrote:

>  *Policy does not distinguish in what form the data is held. So
> information persisted in email is subject to the same policy as the same
> information persisted in a word document. *
>
> * *
>
> *Yes we have to bind data to some set of policies. The semantics for email
> and documents are the same. *
>
> * *
>
> *Overall the Alice case you cited is too simple. A more realist example is
> *
>
> * *
>
> *Alice has some data and wants to apply policy X and Y to her data *
>
> *Bob has some data and wants to apply policy Z to his data*
>
> * *
>
> *Policies X, Y and Z each defines a set of authorized recipients.*
>
> * *
>
> *Alice and Bob’s data had become comingled so now policies X Y and Z have
> to be enforced.*
>
> * *
>
> *In an ideal world we would want to identify Alice’s and Bob’s data and
> bind it to its respective polices. *
>
> * *
>
> *In a less than perfect world we may enforce access at the container level
> which is an incremental improvement on what we have today. *
>
> * *
>
> * *
>
> *From:* Phillip Hallam-Baker [mailto:[email-masked]]
> *Sent:* Tuesday, April 12, 2011 12:31 PM
> *To:* Trevor Freeman
> *Cc:* Leif Johansson; [email-masked]
>
> *Subject:* Re: [plasma] why not web portal mail?
>
>
>

---

From: Leif Johansson <[email-masked]>
Date: Wed, 13 Apr 2011 10:22:24 +0200

> The closest I can get is if I persist my IM history I would invoke the policy but it's not intuitive I would spawn more im sessions based on that as I would forward or reply all with email. 

Yes you do! XEP-0060 is exactly your XMPP inbox.

---

From: Trevor Freeman <[email-masked]>
Date: Wed, 13 Apr 2011 17:08:32 +0000

Ok then I don’t get the use case. 

Can you describe when a user would do such a thing and what are they trying to accomplish?

---

From: Trevor Freeman <[email-masked]>
Date: Wed, 13 Apr 2011 17:58:56 +0000

From: Phillip Hallam-Baker [mailto:[email-masked]]
Sent: Tuesday, April 12, 2011 5:50 PM
To: Trevor Freeman
Cc: Leif Johansson; [email-masked]
Subject: Re: [plasma] why not web portal mail?

If we have a collection of data in a database that is controlled under the secret#example.com<http://example.com> policy we might have an infinite series of permutations and subsets that could be drawn from the database.
[TF] I do think we need to store the logic tree of how the policies are expected to be combined. I have come across scenarios where the policies are a logical AND as well as scenarios where the policies are a logical OR. That needs to be persisted with the data.

We don't need to standardize the expression of the secret#example.com<http://example.com> policy or how it relates to the dataset. There might be constraints in there of the form 'fans of Lady Gaga can only download a maximum of 1000 items', there might be propositions that are nondeterministic, even undecidable.
[TF] Agreed. The point of Plasma is that process is opaque to the client. All the client should get is a series of references from the server of polices the user can assert which amounts to a list of stings. We need a machine readable sting and a sting for the user.

All an application ever needs to deal with is the consequences of that policy and those can be reduced to a small number of fixed actions plus 'call back for further instructions'.
[TF] Yes I think we only need define a few standard actions such as sign the thing. We also need to define obligations on policy binding for derivative data. In some cases you can change it or remove it, other you can append to it, etc.

There will have to be a policy language of course. But the policy language itself does not need to be part of the standard. Its like the .NET specification, the byte code and the APIs are standard, but that infrastructure can support a vast array of languages.
[TF] Defiantly don't need to standardize the policy language in Plasma. We only need to standardize the reference to the policy itself. We may want to standardize discovery of keys. The round trip to the plasma server is time consuming which is not a problem for the client but is for a server. If I want to preauthorize access to the email e.g. an AV scanning service for the domain, then we need to find their keys before we send the email.

What we need in the PLASMA standard is the range of moves used to implement the policy.
[TF] If by that you mean how to I interact with the policy server and what does it expect me to do, yes.

That is good in two ways, first it is more general and a better architecture, second it avoids the worst thickets of patent trolldom which obsess about the idea of moving the policy itself round with the data being controlled. That is a necessary approach for copyright enforcement which had to support offline devices and physical media once upon a time but not for content management in general.
[TF] Embedding the policy with the data is a bad idea became it presents an unsolvable maintenance problem. Data has a habit of getting copied and moved to all sorts of locations. If the policy changed then you cannot track down every copy.

On Tue, Apr 12, 2011 at 6:52 PM, Trevor Freeman <[email-masked]<mailto:[email-masked]>> wrote:
Policy does not distinguish in what form the data is held. So information persisted in email is subject to the same policy as the same information persisted in a word document.

From: Phillip Hallam-Baker [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, April 12, 2011 12:31 PM
To: Trevor Freeman
Cc: Leif Johansson; [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Leif Johansson
Sent: Tuesday, April 12, 2011 7:21 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [plasma] why not web portal mail?

       Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Wed, 13 Apr 2011 23:14:29 +0200

> Can you describe when a user would do such a thing and what are they trying to accomplish? 

OK I'll try to spell it out...

The point I was trying to make is and was that the same requirements
and UCs that apply to email apply equally well to XMPP. The fact that
XMPP _has_ store-and-forward capabilities doesn't mean it is _exactly_
the same thing as email.

I believe the difficulty of building web-only XMPP clients and the
fact that plasma-like capabilities are probably equally useful for
XMPP as for email is a response to Stephens question "Why not build
a web-applications?".

	Cheers Leif

---

From: Trevor Freeman <[email-masked]>
Date: Fri, 15 Apr 2011 16:59:51 +0000

Leif,

I am sure Plasma is applicable to XMPP.

The question I am trying to answer in my mind is what is happing to the data. While there are a lot of similarities, they are not identical so we can to look at the expected behavior of the client wrt the data. While IM exchanges data I don’t see in current clients the commingling and reuse of data you get with email. That should be goodness for XMPP because the complications for email lie in this comingling and reuse. 

If you can write up a use case for non-store and forward as well as store and forward I can incorporate them into the requirements doc. 

Thanks 

Trevor

-----Original Message-----
From: Leif Johansson [mailto:[email-masked]] 
Sent: Wednesday, April 13, 2011 2:14 PM
To: Trevor Freeman
Cc: Peter Saint-Andre; [email-masked]
Subject: Re: [plasma] why not web portal mail?

The point I was trying to make is and was that the same requirements and UCs that apply to email apply equally well to XMPP. The fact that XMPP _has_ store-and-forward capabilities doesn't mean it is _exactly_ the same thing as email.

I believe the difficulty of building web-only XMPP clients and the fact that plasma-like capabilities are probably equally useful for XMPP as for email is a response to Stephens question "Why not build a web-applications?".

	Cheers Leif