Subject: [Simple] MSRP: Contributor ID

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Aug 2004 10:27:58 -0500

Hi,

In last week's SIMPLE meeting, Orit brought up an issue about how we 
planned to identify contributors when MSRP is used with a conference 
focus. Previously, we had discussed using message/cpim wrappers for 
this purpose.

After thinking through the use case, I think Orit may be correct that 
cpim is unwieldy for this purpose.

The use case I think we have in mind is, you have a text conference 
where each participant has an independent MSRP session with the 
conference focus. The focus acts as a reflector, forwarding messages 
that come in on one participant session to each of the other 
participants. It needs a way to tell the receiving parties which 
participant sent the message. _How_ it determines what contributor ID 
to attach to a given message is out of scope for MSRP--that problem 
belongs to XCON.

We had previously assumed the focus would simply wrap the inbound 
message in a message/cpim document, and use the CPIM "from" field for 
this purpose. This, however, is problematic for chunked messages, as 
the focus would need to buffer the message until it had received all 
the chunks, wrap the completed message in the cpim document, and then 
send that message out to the other participants, possibly re-chunking 
in the process. This does seem to me to be burdensome on the focus; it 
would be nicer if the focus could simply forward the individual chunks, 
and let the endpoints deal with re-assembling them.

Another approach would be to have the focus force the endpoints to use 
a cpim envelope. However, there may be times where the identity that 
the focus wants to insert may be different than the identity that the 
endpoint inserts.

Therefore, I propose we add a new optional header called 
Contributor-ID, which can carry a name-addr. Normal endpoints would 
never insert this, but a conference focus could insert this header on a 
per-chunk basis, and avoid the buffering requirement mentioned above.

What do others think? Am I completely off base?

Thanks!

Ben. 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Aug 2004 14:47:41 -0400

comments inline.

	Paul

Ben Campbell wrote:
> focus. Previously, we had discussed using message/cpim wrappers for this 
> purpose.
> 
> participant sent the message. _How_ it determines what contributor ID to 
> attach to a given message is out of scope for MSRP--that problem belongs 
> to XCON.
> 
> this purpose. This, however, is problematic for chunked messages, as the 
> focus would need to buffer the message until it had received all the 
> chunks, wrap the completed message in the cpim document, and then send 
> that message out to the other participants, possibly re-chunking in the 
> process. This does seem to me to be burdensome on the focus; it would be 
> nicer if the focus could simply forward the individual chunks, and let 
> the endpoints deal with re-assembling them.

I haven't thought this thru carefully, but I think it should be possible 
to wrap the message in a CPIM wrapper without reassembling it first. It 
is just a matter of inserting some bytes for the wrapper in the first 
chunk. If that pushes the first chunk over 2k then it might have to be 
sent as two chunks, then so be it. If the actual length of the message 
was provided, then it would need to be changed. And then each other 
chunk of the message would need to have its byte range adjusted. Then, 
when the last chunk is found, it needs to have a suffix appended to it 
to wrap out the CPIM wrapper. (Actually I don't recall the details of 
CPIM to know if that is needed.)

So, it takes a bit of work, but not a huge amount.

> Another approach would be to have the focus force the endpoints to use a 
> cpim envelope. However, there may be times where the identity that the 
> focus wants to insert may be different than the identity that the 
> endpoint inserts.
> 
> Therefore, I propose we add a new optional header called Contributor-ID, 
> which can carry a name-addr. Normal endpoints would never insert this, 
> but a conference focus could insert this header on a per-chunk basis, 
> and avoid the buffering requirement mentioned above.
> 

I think the two approaches aren't different enough in the work required 
that they should be judged based on that.

Its probably more important to get the semantics right. Suppose we were 
to go with this new header. And then suppose we had conference 
participants sending CPIM wrapped messages that contain a From header. 
What identity should the recipient display?

I think it is probably better for the focus to confront this from the 
beginning, resolving any conflict there might be. This could be resolved 
with either approach, but I think it is cleaner if you don't present the 
recipient with any potential conflict. So I would prefer to use CPIM 
wrappers for this purpose.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Aug 2004 13:56:23 -0500

On Aug 9, 2004, at 1:47 PM, Paul Kyzivat wrote:

>> in the process. This does seem to me to be burdensome on the focus; 
>> it would be nicer if the focus could simply forward the individual 
>> chunks, and let the endpoints deal with re-assembling them.
>
> I haven't thought this thru carefully, but I think it should be 
> possible to wrap the message in a CPIM wrapper without reassembling it 
> first. It is just a matter of inserting some bytes for the wrapper in 
> the first chunk. If that pushes the first chunk over 2k then it might 
> have to be sent as two chunks, then so be it. If the actual length of 
> the message was provided, then it would need to be changed. And then 
> each other chunk of the message would need to have its byte range 
> adjusted. Then, when the last chunk is found, it needs to have a 
> suffix appended to it to wrap out the CPIM wrapper. (Actually I don't 
> recall the details of CPIM to know if that is needed.)
>

I agree this is true, assuming the use of cpim is always that simple. 
Do we run into any problem if the chunk contained signed or encrypted 
data? Will the focus ever need to sign or encrypt the data itself?

>> Another approach would be to have the focus force the endpoints to 
>> use a cpim envelope. However, there may be times where the identity 
>> that the focus wants to insert may be different than the identity 
>> that the endpoint inserts.
>> never insert this, but a conference focus could insert this header on 
>> a per-chunk basis, and avoid the buffering requirement mentioned 
>> above.
> I think the two approaches aren't different enough in the work 
> required that they should be judged based on that.
>
> Its probably more important to get the semantics right. Suppose we 
> were to go with this new header. And then suppose we had conference 

It seems to me that this is a matter for the conference policy to 
solve, and is not significantly different than if you have a voice 
conference, and a caller has a different identity in the credentials 
for a SIP dialog than in the conference policy.

> beginning, resolving any conflict there might be. This could be 
> resolved with either approach, but I think it is cleaner if you don't 
> present the recipient with any potential conflict. So I would prefer 
> to use CPIM wrappers for this purpose.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Aug 2004 15:34:58 -0400

Ben Campbell wrote:
> I agree this is true, assuming the use of cpim is always that simple. Do 
> we run into any problem if the chunk contained signed or encrypted data? 
> Will the focus ever need to sign or encrypt the data itself?

Well, what are the cases?
- the message arriving at the mixer could be signed, encrypted, both,
   neither - by the sender.
- the outgoing message from the mixer could any signing/encryping of
   the incoming message alone, or could remove one or the other.
- the outgoing message from the mixer could be signed, encrypted, both
   or neither - by the mixer.

I'm not sure how many of those combinations are meaningful - not very 
many I think.

If the message is encrypted, and the mixer needs to remove that 
encryption, then it cannot escape buffering the whole message.

If the message is not encrypted, but it is signed with multipart/signed, 
then it should be possible to remove the signature on the fly.

If the message is to be signed and/or encrypted by the mixer, then given 
a suitable algorith, I think it is possible to do it on the fly, with 
the restriction that any out-of-order chunks will need to be buffered 
until their turn arrives. All the stuff that wraps the actual encrypted 
text can still be inserted at the beginning or end.

I'm not sure of this - would need to study the encoding more carefully 
to be sure, but I think this should work.

Note that all of this is independent of whether a CPIM wrapper is being 
added or not.

> It seems to me that this is a matter for the conference policy to solve, 
> and is not significantly different than if you have a voice conference, 
> and a caller has a different identity in the credentials for a SIP 
> dialog than in the conference policy.

Certainly it *can*. But as long as the endpoint can receive identity 
information in two ways there will always be more confusion that if 
there is only one way.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Aug 2004 14:54:21 -0500

On Aug 9, 2004, at 2:34 PM, Paul Kyzivat wrote:

>>>> In last week's SIMPLE meeting, Orit brought up an issue about how 
>>>> we planned to identify contributors when MSRP is used with a 
>>>> conference focus. Previously, we had discussed using message/cpim 
>>>> After thinking through the use case, I think Orit may be correct 
>>>> that cpim is unwieldy for this purpose.
>>>> conference focus. The focus acts as a reflector, forwarding 
>>>> messages that come in on one participant session to each of the 
>>>> other participants. It needs a way to tell the receiving parties 
>>>> which participant sent the message. _How_ it determines what 
>>>> contributor ID to attach to a given message is out of scope for 
>>>> MSRP--that problem belongs to XCON.
>>>> message in a message/cpim document, and use the CPIM "from" field 
>>>> for this purpose. This, however, is problematic for chunked 
>>>> messages, as the focus would need to buffer the message until it 
>>>> had received all the chunks, wrap the completed message in the cpim 
>>>> document, and then send that message out to the other participants, 
>>>> possibly re-chunking in the process. This does seem to me to be 
>>>> burdensome on the focus; it would be nicer if the focus could 
>>>> simply forward the individual chunks, and let the endpoints deal 
>>>> with re-assembling them.
>>>
>>>
>>> possible to wrap the message in a CPIM wrapper without reassembling 
>>> it first. It is just a matter of inserting some bytes for the 
>>> wrapper in the first chunk. If that pushes the first chunk over 2k 
>>> then it might have to be sent as two chunks, then so be it. If the 
>>> actual length of the message was provided, then it would need to be 
>>> changed. And then each other chunk of the message would need to have 
>>> its byte range adjusted. Then, when the last chunk is found, it 
>>> needs to have a suffix appended to it to wrap out the CPIM wrapper. 
>>> (Actually I don't recall the details of CPIM to know if that is 
>>> needed.)
>>>
> If the message is not encrypted, but it is signed with 
> multipart/signed, then it should be possible to remove the signature 
> on the fly.
>
> If the message is to be signed and/or encrypted by the mixer, then 
> given a suitable algorith, I think it is possible to do it on the fly, 
> with the restriction that any out-of-order chunks will need to be 
> buffered until their turn arrives. All the stuff that wraps the actual 
> encrypted text can still be inserted at the beginning or end.
>
> Note that all of this is independent of whether a CPIM wrapper is 
> being added or not.
>
>>> participants sending CPIM wrapped messages that contain a From 
>>> header. What identity should the recipient display?

It seems like the same problem can exist, regardless of whether we use 
cpim or a header for this. Even if we just use cpim, you could still 
have an endpoint use a cpim envelope, just to have the focus blindly 
stick that inside _another_ cpim envelope.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Aug 2004 17:13:47 -0400

> stick that inside _another_ cpim envelope.

Well, maybe that is the case. I wouldn't expect the mixer to put another 
CPIM wrapper around a message that already had one. I would expect it to 
either adjust the existing wrapper, possibly changing the From header;

OR, (equivalently) remove the incoming CPIM wrapper and replace it with 
a new one constructed by the mixer, possibly using some of the header 
values from the incoming one.

If this new header is added, then either the mixer should remove the 
 From header from any CPIM wrapper, or else should force the two to be 
the same.

I think I am still inclined to prefer using CPIM, but I don't have any 
compelling arguments for it.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Wed, 11 Aug 2004 09:12:34 -0500

So, since the crypto usage does not seem to break anything, it looks 
like cpim can work. In fact, since we had a prior consensus to use cpim 
for this, anything but clear consensus to change things should mean we 
leave things as they are.

But, Rohan said he things cpim is kind of ugly for this purpose, and I 
tend to agree now that we have chunking in the core protocol. If we use 
cpim, it seems like the focus has to do the following:

Check if this is the first chunk. If so, change the content-type to 
message/cpim, add the cpim headers to the head of the body. Adjust the 
byte-range header to match the new range. Optionally re-chunk if this 
pushes the chunk above 2k (actually, this part is probably not worth 
doing, as we are increasing the size by only a little.)  If this is any 
chunk other than the first, just change the content-type and the 
byte-range headers. (Note that fixing up the byte-range header will 
require keeping a small amount of state until all chunks of the message 
have been processed.)

If we use Contributor-ID (or whatever we choose to call it, the focus 
does the following:

Add the header, if it is not already there.

But, I have a concern that Contributor-ID may not be robust enough. 
What happens if my message crosses _two_ focuses? Do I need a way to 
put in multiple identities, one from the perspective of each focus? Do 
I need a way for each focus to sign the identity it put in?

If these are needed, then we need something more complex than 
contributor-ID. Something more like the SIP identity draft would be in 
order. f this is the case, then I really think that the problem 
solution is out of scope for the core protocol.

On Aug 10, 2004, at 6:30 PM, Rohan Mahy wrote:

> Paul,
>
> I am not arguing for using CPIM.  I actually feel its kind of ugly, 
> but in the interest of describing what you need to do to use CPIM, I 
> think you missed a few cases.  I believe there are 2 axes here 
> (signature, and crypto)
>
> 1. Unsigned
> 2. Signed by the participant
> 3. Signed by the focus
> 4. Signed by both the participant and the focus
>
> A. Unencrypted
> B. Encrypted with a group key to whole conference
> C. Encrypted to Focus, Re-encrypted to Target Participant
>
> On the signature axis, the focus just needs to add a new message/cpim 
> envelope, and can do this in all 4 cases.
>
> 1. Unsigned
> BEFORE
> ...
> Content-Type: text/plain
>
> Hi
> -------foo$
>
> AFTER
> ...
> Content-Type: message/cpim
>
> From: <sms:+12223334444>
>
> Content-Type: text/plain
>
> Hi
> -------foo$
>
> 2. Signed by Participant
> BEFORE
> ...
> Content-Type: multipart/signed;boudary=bar
>
> --bar
> Content-Type: text/plain
>
> Hi
> --bar
> Content-Type: application/pkcs7-mime
>
> <signature>
> --bar
> -------foo$
>
> AFTER
> ...
> Content-Type: message/cpim
>
> From: Alice <sip:[email-masked]>
>
> Content-Type: multipart/signed;boudary=bar
>
> --bar
> Content-Type: text/plain
>
> Hi
> --bar
> Content-Type: application/pkcs7-mime
>
> <signature>
> --bar
> -------foo$
>
>
> 3. Signed by Focus
> BEFORE
> ...
> Content-Type: text/plain
>
> Hi
> -------foo$
>
> AFTER
> ...
> Content-Type: multipart/signed;boundary=bar
>
> --bar
> Content-Type: message/cpim
>
> From: Alice <sips:[email-masked]>
>
> Content-Type: text/plain
>
> Hi
> --bar
> Content-Type: application/pkcs7-mime
>
> <signature>
> --bar
> -------foo$
>
> 4. Signed by Both
> BEFORE
> ...
> Content-Type: multipart/signed;boudary=bar
>
> --bar
> Content-Type: text/plain
>
> Hi
> --bar
> Content-Type: application/pkcs7-mime
>
> <signature>
> --bar
> -------foo$
>
>
> AFTER
> ...
> Content-Type: multipart/signed;boundary=focus-bound
>
> --focus-bound
> Content-Type: message/cpim
>
> From: Alice <jid:[email-masked]/atlanta>
>
> Content-Type: multipart/signed;boundary=godzilla
>
> --godzilla
> Content-Type: text/plain
>
> Hi
> --godzilla
> Content-Type: application/pkcs7-mime
>
> <signature of participant>
> --godzilla
> --focus-bound
> Content-Type: application/pkcs7-mime
>
> <signature of focus>
> --focus-bound
> -------foo$
>
> None of the signature combos requires the whole message. You insert 
> some stuff at the top, and and the end.  you need to keep a running 
> hash going in the middle to generate or verify the signature at the 
> end, but you don't need the whole message to start writing.
>
> For the encryption axis, obviously all the signature examples were 
> unencrypted and work fine.  If a message is encrypted for a group, the 
> focus just treats this like any other type of body and slaps a 
> message/cpim envelope around it to assert who it thinks the From is 
> (**).  The only time the focus needs to grab the whole message, is 
> when it is encrypted for the focus and nobody else has the key.  
> Obviously here, you need the whole message anyway, so CPIM is hardly 
> the limiting factor.
>
> (**) example:
>
> B. Encrypted with group key
> BEFORE
> ...
> Content-Type: application/pkcs7mime
>
> ***********ciphertext*********
> -------foo$
>
> AFTER
> ...
> Content-Type: message/cpim
>
> From: Alice <sips:[email-masked]>
>
> Content-Type: application/pkcs7mime
>
> ***********ciphertext*********
> -------foo$
>
> thanks.
> -rohan
>
>
>
>
>
> On Aug 9, 2004, at 12:34 PM, Paul Kyzivat wrote:
>
>>
>>
>> Ben Campbell wrote:
>>>>> The use case I think we have in mind is, you have a text 
>>>>> conference where each participant has an independent MSRP session 
>>>>> with the conference focus. The focus acts as a reflector, 
>>>>> forwarding messages that come in on one participant session to 
>>>>> each of the other participants. It needs a way to tell the 
>>>>> receiving parties which participant sent the message. _How_ it 
>>>>> determines what contributor ID to attach to a given message is out 
>>>>> of scope for MSRP--that problem belongs to XCON.
>>>>> had received all the chunks, wrap the completed message in the 
>>>>> cpim document, and then send that message out to the other 
>>>>> participants, possibly re-chunking in the process. This does seem 
>>>>> to me to be burdensome on the focus; it would be nicer if the 
>>>>> focus could simply forward the individual chunks, and let the 
>>>>> endpoints deal with re-assembling them.
>>>>
>>>>
>>>> changed. And then each other chunk of the message would need to 
>>>> have its byte range adjusted. Then, when the last chunk is found, 
>>>> it needs to have a suffix appended to it to wrap out the CPIM 
>>>> wrapper. (Actually I don't recall the details of CPIM to know if 
>>>> that is needed.)
>>>>
>>> I agree this is true, assuming the use of cpim is always that 
>>> simple. Do we run into any problem if the chunk contained signed or 
>>> encrypted data? Will the focus ever need to sign or encrypt the data 
>>> itself?
>>
>> given a suitable algorith, I think it is possible to do it on the 
>> fly, with the restriction that any out-of-order chunks will need to 
>> be buffered until their turn arrives. All the stuff that wraps the 
>> actual encrypted text can still be inserted at the beginning or end.
>>
>> I'm not sure of this - would need to study the encoding more 
>> carefully to be sure, but I think this should work.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Aug 2004 10:14:57 -0400

Rohan,

Thanks for filling in details. You do help make the fundamental point 
that CPIM is not substantially more complex than an new header for this 
purpose. Most of the issues that Ben brought up are the same for both. 
So I continue to think the decision on which way to go should be based 
on other criteria.

The numerous extra cases you bring up are interesting. An important 
question is how the mixer in fact determines what strategy to take with 
a given message?

If a message is signed and not encrypted then I guess there is never any 
reason for the focus to remove that signature - it can just add another 
one if it wishes.

But if a message is encrypted, and the mixer knows how to decrypt it, it 
needs to decide if it should do so (because some or all the the 
participants may not be able to decrypt it), or leave it alone. And then 
it needs to decide if it should re-encrypt it.

Some of this is simply policy, but there probably need to be some 
standards for how this should be done if there is to be any prayer of 
interoperability.

	Paul

Rohan Mahy wrote:
> Paul,
> 
> I am not arguing for using CPIM.  I actually feel its kind of ugly, but 
> in the interest of describing what you need to do to use CPIM, I think 
> you missed a few cases.  I believe there are 2 axes here (signature, and 
> crypto)
> 
> 1. Unsigned
> None of the signature combos requires the whole message. You insert some 
> stuff at the top, and and the end.  you need to keep a running hash 
> going in the middle to generate or verify the signature at the end, but 
> you don't need the whole message to start writing.
> 
> (**).  The only time the focus needs to grab the whole message, is when 
> it is encrypted for the focus and nobody else has the key.  Obviously 
> here, you need the whole message anyway, so CPIM is hardly the limiting 
> factor.
> 
> (**) example:
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 11 Aug 2004 09:26:55 -0500

On Aug 11, 2004, at 9:14 AM, Paul Kyzivat wrote:

> that CPIM is not substantially more complex than an new header for 
> this purpose. Most of the issues that Ben brought up are the same for 
> both. So I continue to think the decision on which way to go should be 
> based on other criteria.
>
> question is how the mixer in fact determines what strategy to take 
> with a given message?
>
> If a message is signed and not encrypted then I guess there is never 
> any reason for the focus to remove that signature - it can just add 
> another one if it wishes.
>
> But if a message is encrypted, and the mixer knows how to decrypt it, 
> it needs to decide if it should do so (because some or all the the 
> participants may not be able to decrypt it), or leave it alone. And 
> then it needs to decide if it should re-encrypt it.
>

I really think that defining a conferencing application is out of 
scope.  All we are trying to do is build in a hook, so that it is 
possible to build a conferencing application.

>> unencrypted and work fine.  If a message is encrypted for a group, 
>> the focus just treats this like any other type of body and slaps a 
>>>>>> determines what contributor ID to attach to a given message is 
>>>>>> out of scope for MSRP--that problem belongs to XCON.
>>>>> possible to wrap the message in a CPIM wrapper without 
>>>>> reassembling it first. It is just a matter of inserting some bytes 
>>>>> for the wrapper in the first chunk. If that pushes the first chunk 
>>>>> over 2k then it might have to be sent as two chunks, then so be 
>>>>> it. If the actual length of the message was provided, then it 
>>>>> would need to be changed. And then each other chunk of the message 
>>>>> would need to have its byte range adjusted. Then, when the last 
>>>>> chunk is found, it needs to have a suffix appended to it to wrap 
>>>>> out the CPIM wrapper. (Actually I don't recall the details of CPIM 
>>>>> to know if that is needed.)
>>>>>
>>>> encrypted data? Will the focus ever need to sign or encrypt the 
>>>> data itself?
>>>
>>>
>>> I'm not sure how many of those combinations are meaningful - not 
>>> very many I think.
>>>
>>>>> were to go with this new header. And then suppose we had 
>>>>> conference participants sending CPIM wrapped messages that contain 
>>>>> a From header. What identity should the recipient display?
>>>>
>>>> conference, and a caller has a different identity in the 
>>>> credentials for a SIP dialog than in the conference policy.
>>>
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Aug 2004 11:24:10 -0400

> require keeping a small amount of state until all chunks of the message 

Note that it is possible for the mixer to receive the first chunk of a 
message *after* receiving one or more other chunks of the message.

Unless the change in the byte range is entirely deterministic, the mixer 
will have to buffer chunks until it receives the first one, so it will 
know what alterations are required in the others. I have to think about 
it more to decide if the necessary delta to the byte range can be 
computed deterministically from any chunk.

> Add the header, if it is not already there.

This does seem simpler, though the computational and memory load of the 
two are roughly equivalent.

> But, I have a concern that Contributor-ID may not be robust enough. What 
> happens if my message crosses _two_ focuses? Do I need a way to put in 
> multiple identities, one from the perspective of each focus? Do I need a 
> way for each focus to sign the identity it put in?

Hmm. Interesting questions.

I think the simple answer is that e2e identification and encryption 
don't make much sense in conferences. When a conference is built around 
a focus, each partipant is in fact communicating with the focus, and 
must trust that focus. The identities received in messages from the 
focus are simply assertions by the focus, and can't easily be proven to 
be correct. When there are multiple foci, then the one nearest to the 
participant is the only one of direct relevance to it. Information from 
other foci is via transitive trust.

An alternative might be for the focus to simply check messages with CPIM 
bodies, to ensure that the From address is correct, based on its 
knowledge of conference participants. If not, it would simply reject the 
message. If so, it could pass on, possibly signing it again.

> order. f this is the case, then I really think that the problem solution 
> is out of scope for the core protocol.

Agree. That leaves the question of what to do for now.

The simplest thing to do is nothing. That leaves the xcon guys to figure 
out what to do. They are free to use CPIM, or some other special body 
type, however they like.

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Wed, 11 Aug 2004 18:33:48 +0300

Hi,

IMO, there are two things CPIM is needed for in a conferencing scenario:

1 - In your use case below, for a focus-inserted "asserted" identity
identifying the sender of the message

2 - For routing purposes, in order to route messages based on who the
messages were addressed to. This is to enable whispering within a
conference (i.e., sending a certain message not to the entire
conference, but to one or a few of the participants). This has been
discussed before at length.

Clearly, CPIM (ugly as it may be) can be made to handle both of these
needs. Contributor-ID will only cover the first one - unless of course
we also add "Recipient-ID" and "Recipient-of-Carbon-Copy-ID", inserted
by the client, to cover the second need.

Cheers,
Aki

---

From: Ben Campbell <[email-masked]>
Date: Wed, 11 Aug 2004 10:42:53 -0500

On Aug 11, 2004, at 10:24 AM, Paul Kyzivat wrote:

>> like cpim can work. In fact, since we had a prior consensus to use 
>> cpim for this, anything but clear consensus to change things should 
>> mean we leave things as they are.
>> But, Rohan said he things cpim is kind of ugly for this purpose, and 
>> I tend to agree now that we have chunking in the core protocol. If we 
>> use cpim, it seems like the focus has to do the following:
>> message/cpim, add the cpim headers to the head of the body. Adjust 
>> the byte-range header to match the new range.  Optionally re-chunk if 
>> this
>> doing, as we are increasing the size by only a little.)  If this is 
>> any chunk other than the first, just change the content-type and the 
>> require keeping a small amount of state until all chunks of the 
>> message have been processed.)
>
> Unless the change in the byte range is entirely deterministic, the 
> mixer will have to buffer chunks until it receives the first one, so 
> it will know what alterations are required in the others. I have to 
> think about it more to decide if the necessary delta to the byte range 
> can be computed deterministically from any chunk.
>
> This does seem simpler, though the computational and memory load of 
> the two are roughly equivalent.
>
>> put in multiple identities, one from the perspective of each focus? 
>> Do I need a way for each focus to sign the identity it put in?
>
> don't make much sense in conferences. When a conference is built 
> around a focus, each partipant is in fact communicating with the 
> focus, and must trust that focus. The identities received in messages 
> from the focus are simply assertions by the focus, and can't easily be 
> proven to be correct. When there are multiple foci, then the one 
> nearest to the participant is the only one of direct relevance to it. 
> Information from other foci is via transitive trust.
>

I can imagine situations where one of the participants at a focus is in 
fact another focus. I don't know if this is in scope for xcon or not, 
so I don't know if we need to worry about it.

> An alternative might be for the focus to simply check messages with 
> CPIM bodies, to ensure that the From address is correct, based on its 
> knowledge of conference participants. If not, it would simply reject 
> the message. If so, it could pass on, possibly signing it again.
>
>> contributor-ID. Something more like the SIP identity draft would be 
>> in order. f this is the case, then I really think that the problem 
> The simplest thing to do is nothing. That leaves the xcon guys to 
> figure out what to do. They are free to use CPIM, or some other 
> special body type, however they like.

I am starting to come back to that opinion myself.

It seems like we have two choices. One is to say that MSRP focus 
behavior is out of scope for the current specs; we think it can be 
solved with cpim; and cpim is must-implement. That is, do nothing now. 
If we are proven wrong, then xcon has some work to do.

The other is to actually try to specify how we expect MSRP foci to 
work, based either on cpim or something else such as additional 
headers. I suspect this is a non-trivial task on which we do not want 
to block the MSRP work.

>>> On the signature axis, the focus just needs to add a new 
>>> message/cpim envelope, and can do this in all 4 cases.
>>>
>>> 1. Unsigned
>>> BEFORE
>>> ...
>>> Content-Type: text/plain
>>>
>>> Hi
>>> -------foo$
>>>
>>> AFTER
>>> ...
>>>>>>> In last week's SIMPLE meeting, Orit brought up an issue about 
>>>>>>> how we planned to identify contributors when MSRP is used with a 
>>>>>>> conference focus. Previously, we had discussed using 
>>>>>>> message/cpim wrappers for this purpose.
>>>>>>> conference where each participant has an independent MSRP 
>>>>>>> session with the conference focus. The focus acts as a 
>>>>>>> reflector, forwarding messages that come in on one participant 
>>>>>>> session to each of the other participants. It needs a way to 
>>>>>>> tell the receiving parties which participant sent the message. 
>>>>>>> _How_ it determines what contributor ID to attach to a given 
>>>>>>> message is out of scope for MSRP--that problem belongs to XCON.
>>>>>>> We had previously assumed the focus would simply wrap the 
>>>>>>> inbound message in a message/cpim document, and use the CPIM 
>>>>>>> "from" field for this purpose. This, however, is problematic for 
>>>>>>> chunked messages, as the focus would need to buffer the message 
>>>>>>> until it had received all the chunks, wrap the completed message 
>>>>>>> in the cpim document, and then send that message out to the 
>>>>>>> other participants, possibly re-chunking in the process. This 
>>>>>>> does seem to me to be burdensome on the focus; it would be nicer 
>>>>>>> if the focus could simply forward the individual chunks, and let 
>>>>>> reassembling it first. It is just a matter of inserting some 
>>>>>> bytes for the wrapper in the first chunk. If that pushes the 
>>>>>> first chunk over 2k then it might have to be sent as two chunks, 
>>>>>> then so be it. If the actual length of the message was provided, 
>>>>>> then it would need to be changed. And then each other chunk of 
>>>>>> the message would need to have its byte range adjusted. Then, 
>>>>>> when the last chunk is found, it needs to have a suffix appended 
>>>>>> to it to wrap out the CPIM wrapper. (Actually I don't recall the 
>>>>>> details of CPIM to know if that is needed.)
>>>>>>
>>>>> simple. Do we run into any problem if the chunk contained signed 
>>>>> or encrypted data? Will the focus ever need to sign or encrypt the 
>>>>> data itself?
>>>>
>>>>
>>>> multipart/signed, then it should be possible to remove the 
>>>> signature on the fly.
>>>>
>>>>>> Its probably more important to get the semantics right. Suppose 
>>>>>> we were to go with this new header. And then suppose we had 
>>>>>> conference participants sending CPIM wrapped messages that 
>>>>>> contain a From header. What identity should the recipient 
>>>>>> display?
>>>>>
>>>> Certainly it *can*. But as long as the endpoint can receive 
>>>> identity information in two ways there will always be more 
>>>> confusion that if there is only one way.
>>>>
>>>>     Paul
>>>>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Aug 2004 17:55:25 -0700

Sounds like a reasonable idea to me. I think we would want to add that if
the user had requested Privacy either via the privacy header or setting From
to Anonymous then the contributor id should not be revealed here. Even if
the user authenticated via pins or something, the identity should not be
revealed here if the original call was private.

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 10 Aug 2004 16:30:09 -0700

Paul,

I am not arguing for using CPIM.  I actually feel its kind of ugly, but 
in the interest of describing what you need to do to use CPIM, I think 
you missed a few cases.  I believe there are 2 axes here (signature, 
and crypto)

1. Unsigned

A. Unencrypted

1. Unsigned
BEFORE
...
Content-Type: text/plain

Hi
-------foo$

AFTER
...

From: <sms:+12223334444>

Content-Type: text/plain

Hi
-------foo$

2. Signed by Participant
BEFORE
...

--bar
Content-Type: text/plain

Hi
--bar

<signature>
--bar
-------foo$

AFTER
...

--bar
Content-Type: text/plain

Hi
--bar

<signature>
--bar
-------foo$

3. Signed by Focus
BEFORE
...
Content-Type: text/plain

Hi
-------foo$

AFTER
...

--bar

Content-Type: text/plain

Hi
--bar

<signature>
--bar
-------foo$

4. Signed by Both
BEFORE
...

--bar
Content-Type: text/plain

Hi
--bar

<signature>
--bar
-------foo$

AFTER
...

--focus-bound

--godzilla
Content-Type: text/plain

Hi
--godzilla

<signature of focus>
--focus-bound
-------foo$

(**) example:

AFTER
...

thanks.
-rohan