Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-02.txt

From: Paul Kyzivat <[email-masked]>
Date: Sun, 21 Sep 2014 11:54:32 -0400

I got permission from Adrian to post this private reply to the list for 
discussion.

-------- Original Message --------
Subject: 	Re: [siprec] New Version Notification for
draft-yan-siprec-msrp-recording-02.txt
Date: 	Sat, 13 Sep 2014 22:30:40 -0300
From: 	Adrian Georgescu <[email-masked]>
To: 	Paul Kyzivat <[email-masked]>

Hi Paul,

I had a look at it. I am an engineer and look at practical maters. I use
MSRP chat and file transfers almost every day with Blink and Blink uses
OTR by default. That means that media is end-to end encrypted and this
happens by default rather than users having to enable it. If someone
tampers with the encryption, user is alerted and will he/she is likely
to bail out of the conversation if is intercepted. Therefore scenario
3.2 where an MSRP relay is used for intercept purpose does not hold
because of possible usage of end-to-end encryption in the clients.
Unless you control at least one of the end-points, you cannot intercept.
Mandating that MSRP relays support a feature it cannot enforce is kind
of flaw. I would leave it out or explaining why it does not work.

The scenario where recording makes most sense is multi-party chat
conversations. There you explicitly give up on privacy for the sake of
sharing capabilities and recording is a useful feature. If an MSRP
switch is used, than the relay is not mandatory so again scenario 3.2 is
not realistic.  I would but scenario 3.3 in pole position in the document.

Last, I would like to see a provision in the draft to make possible for
an end-user to indicate that it does not want its message to be stored
by the other side (the reverse feature of a party initiating
interception and telling the other side about it).  We use this feature
in Blink today and I find it useful as sometimes I want to write
something that I know that the other party would not save in its history
database like a password or other data that need to be consumed and not
reused latter.

Adrian

On 02 Sep 2014, at 11:20, Paul Kyzivat <[email-masked]
<mailto:[email-masked]>> wrote:

> Adrian,
>
> I've been working on a draft for the siprec wg about the recording of
> msrp.
>
> Ben Campbell suggested that I contact you because you have more
> real-life experience with msrp than most people.
>
> I would appreciate any comments you have on this draft.
>
> For context, if you haven't followed siprec, you may have to look at
> some of the previous siprec drafts to understand what it is about. And
> I'll be happy to answer any questions you might have.
>
> Thanks,
> Paul
>
>
> -------- Original Message --------
> Subject: [siprec] New Version Notification for
> draft-yan-siprec-msrp-recording-02.txt
> Date: Wed, 27 Aug 2014 16:28:41 -0400
> From: Paul Kyzivat <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]> <[email-masked]
> <mailto:[email-masked]>>
>
> I just submitted a revised version of the MSRP recording draft.
>
> The following is a summary of what is different in this version. (It is
> in the draft too.)
>
>   This version addresses comments received on the -01 version, both on
>   the mailing list and at IETF90.  The following is my list of things
>   to address:
>
>   o  Define a new MIME type that is used to wrap the CS MSRP messages
>      that are being recorded.  This allows the original message to be
>      left as-is, so it is always clear what it was.  While CPIM could
>      be used for this, defining a new type will allow capturing other
>      necessary metadata.
>
>   o  Need to further consider the need to track message timing.  Can
>      the timing of messages received by the SRS on the RS MSRP stream
>      be considered a sufficient proxy for the timing of messages in the
>      CS, or should we explicitly pass timestamps of messages as
>      received on the CS?  (The issue was raised but not decided.)
>
>   o  We need to clarify that there is no guarantee that messages
>      received on the CS have been recorded.
>
>   o  It was agreed that there is no need to record the MSRP URIs that
>      are used to establish the CS MSRP session.
>
>   o  It is important that we maintain a 1:1 consistency between MSRP
>      MESSAGE-IDs used in recorded CS sessions and the MESSAGE-IDs used
>      in the RS.  But we should not violate MSRP by using the same
>      MESSAGE-IDs.  We came up with the idea of adding an SRC-specific
>      prefix to the CS message ids to create unique ones for the RS.
>      This should be done in a standard way so that the SRS can recover
>      the original CS message ids, in order to support correlation
>      across redundant SRCs.
>
>   o  Will need to work out the details of what happens when a CS MSRP
>      session is terminated with an incomplete message.  It will be
>      necessary to send the incomplete message to the SRS, but must it
>      appear to be incomplete within the SRS MSRP session?
>
>   o  There are a variety of reasons why the SRC may not want, or be
>      able to, record individual messages in the CS session.  (One
>      example is because the message size is greater than the maximum
>      indicated by the SRS.  Another is because the mime type of the
>      message is a type that the SRS did not indicate support for.)
>      There should be a type of placeholder message that can be sent to
>      the SRS to indicate a message has been dropped, why, and some key
>      attributes about the message.  The new SIPREC wrapper mime type
>      could be designed to serve this purpose.
>
>   o  REPORT messages on the CS can't be sent directly on the RS.  The
>      new SIPREC wrapper mime type could also serve as a way to
>      encapsulate those.
>
>   The primary change is to introduce a new wrapper MIME type
>   ("application/msrp-recording") that is used in RS MSRP sessions for
>   all CS MSRP messages that are to be recorded.  This is used with SEND
>   messages whether they have a CPIM wrapper or not.  It also allows
>   non-SEND messages from the CS to be sent intact in the RS for
>   recording.  And it provides a vehicle for carrying other data as
>   needed.
>
>   Adding another layer of wrapper could substantially increase the
>   total amount of data send on the RS session, relative to what is
>   present on the CS.  I've tried to mitigate that via the details of
>   the design.  For SEND messages, only the body of the SEND message is
>   wrapped.  And From and To headers in this wrapper can be omitted in
>   cases where that information is redundant.  I've assumed that
>   messages other than SEND should in general be infrequent enough that
>   extra overhead when sending them isn't worth a lot of concern.
>
>   This wrapper can carry a DateTime header.  This provides a mechanism
>   to address the timestamp issues.  I've left it as optional to use.
>
>   I clarified the non-guarantee of recording in the architecture
>   section.
>
>   I've provided a special header in the wrapper to carry the MESSAGE-ID
>   from SEND messages in the CS.  And SEND messages will get a separate
>   MESSAGE-ID on the RS MSRP session when sent to the SRS.  This
>   provides the SRS with enough information to solve the correlation
>   problem when a message is incomplete in one CS MSRP session and is
>   resumed on another.  (The problem of reassembly is left to the SRS.)
>
>   The wrapper format includes a mechanism for the SRC to report dropped
>   messages to the SRS.
>
>   The wrapper format also includes a mechanism for encapsulating CS
>   REPORT messages for sending to the SRS.
>
>   I realized that this level of wrapping provides an opportunity to
>   multiplex unrelated CS MSRP sessions on a single RS MSRP session.  To
>   allow this I've provided a way to include the session-id from the
>   metadata, that identifies the particular CS MSRP session, as a value
>   in the wrapper of the message sent on the RS.  But I also made that
>   optional when it is redundant.  This gives a choice: multiplex but
>   make the messages bigger, or create a separate RS MSRP session for
>   each CS MSRP session and keep the messages smaller.  I've included
>   this as a trial balloon for discussion.  I'm undecided about it.
>
>   The formatting of all of this could be better.  But for now I just
>   wanted to get the basic concepts down for review.  Once the approach
>   is reasonably well worked out I'll try to improve the formatting.
>
>   There are many places here where I am uncertain what normative
>   strength to apply to individual requirements.  I've indicated this
>   inline for many of those.  Please comment on this.
>
> I believe this is in line with what was discussed in Toronto.
>
> I especially want to hear whether people find this an acceptable
> direction, as well as thoughts on the details. And anything I might have
> overlooked that still needs to be addressed.
>
> Thanks,
> Paul
>
> -------- Original Message --------
> Subject: New Version Notification for
> draft-yan-siprec-msrp-recording-02.txt
> Date: Wed, 27 Aug 2014 13:19:15 -0700
> From: [email-masked] <mailto:[email-masked]>
> To: Michael Yan <[email-masked]
> <mailto:[email-masked]>>,        "Paul H. Kyzivat"
> <[email-masked] <mailto:[email-masked]>>,
>        "Michael Yan" <[email-masked]
> <mailto:[email-masked]>>,
>       "Paul Kyzivat" <[email-masked]
> <mailto:[email-masked]>>
>
>
> A new version of I-D, draft-yan-siprec-msrp-recording-02.txt
> has been successfully submitted by Paul H. Kyzivat and posted to the
> IETF repository.
>
> Name:draft-yan-siprec-msrp-recording
> Revision:02
> Title:Overview for MSRP Recording based on SIPREC
> Document date:2014-08-27
> Group:Individual Submission
> Pages:17
> URL:
> http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
> Htmlized:
> http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-02
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-02
>
> Abstract:
>   SIPREC is capable of recording interactive text media that is
>   transmitted via RTP.  However that format is not commonly used for
>   message or chat scenarios.  There is also a need for recording text
>   media carried via MSRP.  One case of note is exchange of text between
>   hearing-impaired users and emergence service bureaus.  Also,
>   recording support is needed for MSRP used in chat conferences and
>   multimedia conferences.
>
>   This document describes how to achieve MSRP channel recording within
>   the mechanism of SIP Recording (SIPREC).
>
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>
>
>

--
Adrian

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 21 Sep 2014 12:17:21 -0400

Adrian,

Thanks for commenting. Responses inline.

> of flaw. I would leave it out or explaining why it does not work.

I'm not familiar with OTR other than what wikipedia tells me, and it 
doesn't say how it works with MSRP.

I'm guessing that it is just encrypting the body of messages? (So that 
MSRP relays can still be used - but can't understand the content of the 
body.)

If so, then I don't think this changes much. A relay could still record 
what it gets, even if the recorded content is unintelligible to most.

Suppose that were the case. Would the recorded content be decodable by 
full knowledge of the keys of sender and receiver?

Also, we don't mandate which elements do recording. We only try to 
describe possibilities. So perhaps in the your case useful recordings 
could only be done by the endpoints. (That might be the desired effect 
for those using OTR.)

If so, perhaps that deserves some consideration. As currently described, 
the recording is applied to the MSRP messages, as seen by *somebody* in 
the path those messages traverse. If those messages are encrypted, then 
perhaps that is the wrong strategy. Perhaps in that case it is the 
*unencrypted* messages that need to be recorded. (Possibly encrypted 
again for the recorder.) That would require some changes to the proposal.

> interception and telling the other side about it).

Are you familiar with the base siprec drafts? (Particularly 
draft-ietf-siprec-protocol-14.) There is a mechanism (a=recordpref) to 
indicate a preference for recording, or for *not* recording. It applies 
to audio and video, and with the msrp-recording draft it will apply also 
to that.

	Thanks,
	Paul

> We use this feature

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 21 Sep 2014 12:21:07 -0400

[resending, including Adrian since I don't think he is on the siprec 
list. Please reply to this one so he is included.]

Adrian,

	Thanks,
	Paul

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 25 Sep 2014 20:24:42 -0300

On 21 Sep 2014, at 13:21, Paul Kyzivat <[email-masked]> wrote:

> [resending, including Adrian since I don't think he is on the siprec list. Please reply to this one so he is included.]
> 
> Adrian,
> 
> I'm not familiar with OTR other than what wikipedia tells me, and it doesn't say how it works with MSRP.
> 
> I'm guessing that it is just encrypting the body of messages? (So that MSRP relays can still be used - but can't understand the content of the body.)

Correct. Same as RTP relays can store RTP with zRTP encrypted data where the encryption key is not known by the SIP server as the key is not exchanged in clear text inside signalling.

> 
> If so, then I don't think this changes much. A relay could still record what it gets, even if the recorded content is unintelligible to most.

Yes, technically they could stored the encrypted data.

> 
> Suppose that were the case. Would the recorded content be decodable by full knowledge of the keys of sender and receiver?
> 

Not always or not likely depending on implementation. Not when using a forward secrecy mechanism for example. One cannot decode future communication with an old key:

https://en.wikipedia.org/wiki/Perfect_forward_secrecy

> Also, we don't mandate which elements do recording. We only try to describe possibilities.

This is why possibilities likely to fail deterministically should be dismissed.

> So perhaps in the your case useful recordings could only be done by the endpoints. (That might be the desired effect for those using OTR.)
> 
> If so, perhaps that deserves some consideration. As currently described, the recording is applied to the MSRP messages, as seen by *somebody* in the path those messages traverse. If those messages are encrypted, then perhaps that is the wrong strategy. Perhaps in that case it is the *unencrypted* messages that need to be recorded. (Possibly encrypted again for the recorder.) That would require some changes to the proposal.

One relay can guess if OTR is negotiated as the data is cleartext inside the MSRP data but beyond this, if the relay tries to interfere with the initial OTR negotiation, both end-points will know.

> Are you familiar with the base siprec drafts? (Particularly draft-ietf-siprec-protocol-14.) There is a mechanism (a=recordpref) to indicate a preference for recording, or for *not* recording. It applies to audio and video, and with the msrp-recording draft it will apply also to that.

This requires a re-INVITE, which may fail later in the middle of the session, or be out of sync with media plane, while the media continues to flow. It is a bad strategy as signalling and data are disconnected. So mandating to use SIP packet that may get lost to control MSRP chat messages in progress, is not gonna work properly. I want to know deterministically that my next MSRP message is not going to be stored (or fail to send at all), regardless of the SIP signalling or other middle box protocols that helped setup the MSRP media in the first place.

--
Adrian

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Sep 2014 12:54:11 -0400

Adrian,

Thanks for your input. Please find more comments inline.

On 9/25/14 7:24 PM, Adrian Georgescu wrote:
[snip]
>> MSRP relays can still be used - but can't understand the content of
>> the body.)
>
> Correct. Same as RTP relays can store RTP with zRTP encrypted data where
> the encryption key is not known by the SIP server as the key is not
> exchanged in clear text inside signalling.

How is OTR integrated into MSRP?
How is it negotiated?
Does it use a new wrapper MIME type?
Is the key exchange done in SDP or in MSRP messages?

>> If so, then I don't think this changes much. A relay could still
>> record what it gets, even if the recorded content is unintelligible to
>> most.
>
> Not always or not likely depending on implementation. Not when using a
> forward secrecy mechanism for example. One cannot decode future
> communication with an old key:
>
>> describe possibilities.

Well, that judgement may be right in cases where OTR is in use. But I 
don't think we can assume that it always is. The actual choice of if, 
where and how to install SRCs in middleboxes will be made by 
administrators who have some knowledge of how the system is being used.

But based on this discussion I think we should probably add some text 
noting that this case will not be useful if e2e encryption of messages 
is being used.

>> So perhaps in the your case useful recordings could only be done by
>> the endpoints. (That might be the desired effect for those using OTR.)
>>
>> If so, perhaps that deserves some consideration. As currently
>> described, the recording is applied to the MSRP messages, as seen by
>> *somebody* in the path those messages traverse. If those messages are
>> encrypted, then perhaps that is the wrong strategy. Perhaps in that
>> case it is the *unencrypted* messages that need to be recorded.
>> (Possibly encrypted again for the recorder.) That would require some
>> changes to the proposal.
>
> One relay can guess if OTR is negotiated as the data is cleartext inside
> the MSRP data but beyond this, if the relay tries to interfere with the
> initial OTR negotiation, both end-points will know.

I must not have been clear enough. I was assuming that when OTR is in 
use that recording could only be done by the endpoints (who have access 
to the unencrypted form of the messages). The existing text talks about 
recording of the body of the SEND messages. In the case of encrypted 
messages, it would have to be the unencrypted form of the body.

Also, the base siprec specs say that the protection of the RS must 
always be at least as strong as that of the CS. When using OTR on the 
CS, will that mean also using OTR on the RS?

>> indicate a preference for recording, or for *not* recording. It
>> applies to audio and video, and with the msrp-recording draft it will
>> apply also to that.
>
> This requires a re-INVITE, which may fail later in the middle of the
> session, or be out of sync with media plane, while the media continues
> to flow. It is a bad strategy as signalling and data are disconnected.

Well, this is what was mandated for audio and video. For those, AFAIK 
there is no way to carry the signaling for this in the media.

> So mandating to use SIP packet that may get lost to control MSRP chat
> messages in progress, is not gonna work properly. I want to know
> deterministically that my next MSRP message is not going to be stored
> (or fail to send at all), regardless of the SIP signalling or other
> middle box protocols that helped setup the MSRP media in the first place.

With the current siprec mechanism, the do-not-record indication on the 
CS is a *request* from a UA to the SRC. The SRC doesn't have to honor 
it. However it is required to signal its actual recording/not-recording 
state. So the requesting UA can decide not to transmit sensitive 
information (or terminate the session) if it doesn't get an indication 
that recording has stopped. And similarly if the re-INVITE fails.

We *could* define a different mechanism for use with with MSRP 
recording. That would require defining an extension to MSRP for the 
purpose. That is a possibility, though it raises the bar a bit.

>>> database like a password or other data that need to be consumed and not

So how do you do this? Have you defined an MSRP or CPIM extension? Or 
have you defined a special MIME type for a body that communicates this?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 27 Sep 2014 12:56:48 -0400

Adrian,

Your responses lead me to have a number of other questions.
I'll deal with each in a separate reply, changing the subject to reflect 
the content.

	Thanks,
	Paul

On 9/27/14 7:39 AM, Adrian Georgescu wrote:
>
> On 26 Sep 2014, at 13:54, Paul Kyzivat <[email-masked]
> Inside the message chat stream, is just ascii like any normal message.
> Once the MSRP stream is up any party can start negotiating OTR at any
> point during the lifetime of the session.
>
> No
> Plain MSRP chat stream
>> use that recording could only be done by the endpoints (who have
>> access to the unencrypted form of the messages). The existing text
>> talks about recording of the body of the SEND messages. In the case of
>> encrypted messages, it would have to be the unencrypted form of the body.
>>
> MSRP is different as each message can carry by design any type of media
> described by its content-type inside the CPIM envelope.
>
>>
>> it. However it is required to signal its actual
>> recording/not-recording state. So the requesting UA can decide not to
>> transmit sensitive information (or terminate the session) if it
>> doesn't get an indication that recording has stopped. And similarly if
>> the re-INVITE fails.
>
> For RTP sounds reasonable. For MSRP however is not ideal as it is much
> safer and reliable to send a MSRP message for which there is end-to-end
> integrity, sequencing and delivery reporting capability.
>
>>
> I just send a CPIM message like these:
>
> content_type='application/history-on'
>
> or
>
> content_type='application/history-off'
>
> The support for this feature is negotiated in the SDP of the MSRP media
> block, e.g.:
>
> Offer:
>
> o=- 3620806345 3620806345 IN IP4 192.168.8.3
> s=Blink 4.7.4 (MacOSX)
> m=message 2855 TCP/TLS/MSRP *
> c=IN IP4 192.168.8.3
> a=path:msrps://192.168.8.3:2855/d456be2d8daeff9a39f4;tcp
> a=accept-types:message/cpim text/* application/im-iscomposing+xml
> a=accept-wrapped-types:*
> a=setup:active
> a=features:history-control icon
>
> Answer:
>
> o=- 3620806346 3620806347 IN IP4 10.0.0.139
> s=SylkServer-2.6.0
> c=IN IP4 10.0.0.139
> m=message 51634 TCP/TLS/MSRP *
> a=path:msrps://81.23.228.139:51634/dffc7ea17130f811b6fc;tcp
> a=accept-types:message/cpim
> a=accept-wrapped-types:*
> a=setup:passive
> a=chatroom:nickname private-messages com.ag-projects.screen-sharing
>
>
> PS.
>
> OTR stands for "Off The Record" but I really mean the end-to-end
> encryption and verification part. Keeping records of the conversations
> is in my view a separate feature from the end user point of view which
> does not necessarily require OTR.
>
>>
>> Thanks,
>> Paul
>>
>
> --
> Adrian
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 27 Sep 2014 13:16:19 -0400

>> Is the key exchange done in SDP or in MSRP messages?

I guess I should have asked if you use any new MIME types.

Presumably you need to send messages for key exchange. These need to be 
processed differently from messages that are supposed to be displayed to 
the end user. How are these special messages identified?

> a=chatroom:nickname private-messages com.ag-projects.screen-sharing

The above says that the offerer proposes
- message/cpim is the only accepted wrapper type,
- all subtypes of text are accepted unwrapped
- application/im-iscomposing+xml is accepted unwrapped
- any type is accepted when wrapped with a CPIM wrapper

I must assume that is sufficient for you to negotiate privacy and do key 
exchange. So I guess you don't use any other unwrapped mime types for 
that. But I can't determine if you might use special types that have 
been wrapped with cpim.

And a general question about all of this: is it a proprietary mechanism? 
Or is it public?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 27 Sep 2014 13:25:54 -0400

> a=chatroom:nickname private-messages com.ag-projects.screen-sharing

IIUC, a message with content type of application/history-off would not 
be valid within the MSRP session negotiated above. (Unless it was sent 
within a CPIM wrapper.)

Ignoring that, what are the semantics? Are you sending an *empty* 
message with this content type, to set a mode? Or is this the type of a 
message containing a body that is to be displayed but not added to the 
history?

If the latter, then how do you know the actual type of the content?

How normative is this? Is it advisory to the recipient? Or binding? Doe 
it need to be acknowledged?

	Thanks,
	Paul

---

From: Adrian Georgescu <[email-masked]>
Date: Sat, 27 Sep 2014 08:39:53 -0300

> How is OTR integrated into MSRP?

Inside the message chat stream, is just ascii like any normal message. Once the MSRP stream is up any party can start negotiating OTR at any point during the lifetime of the session. 

No

Plain MSRP chat stream

> Well, that judgement may be right in cases where OTR is in use. But I don't think we can assume that it always is. The actual choice of if, where and how to install SRCs in middleboxes will be made by administrators who have some knowledge of how the system is being used.
> 
> But based on this discussion I think we should probably add some text noting that this case will not be useful if e2e encryption of messages is being used.
> 
> I must not have been clear enough. I was assuming that when OTR is in use that recording could only be done by the endpoints (who have access to the unencrypted form of the messages). The existing text talks about recording of the body of the SEND messages. In the case of encrypted messages, it would have to be the unencrypted form of the body.
> 
> Also, the base siprec specs say that the protection of the RS must always be at least as strong as that of the CS. When using OTR on the CS, will that mean also using OTR on the RS?
> 
> Well, this is what was mandated for audio and video. For those, AFAIK there is no way to carry the signaling for this in the media.

MSRP is different as each message can carry by design any type of media described by its content-type inside the CPIM envelope.

> With the current siprec mechanism, the do-not-record indication on the CS is a *request* from a UA to the SRC. The SRC doesn't have to honor it. However it is required to signal its actual recording/not-recording state. So the requesting UA can decide not to transmit sensitive information (or terminate the session) if it doesn't get an indication that recording has stopped. And similarly if the re-INVITE fails.

For RTP sounds reasonable. For MSRP however is not ideal as it is much safer and reliable to send a MSRP message for which there is end-to-end integrity, sequencing and delivery reporting capability. 

> 
> We *could* define a different mechanism for use with with MSRP recording. That would require defining an extension to MSRP for the purpose. That is a possibility, though it raises the bar a bit.
> 
>>>> We use this feature
> So how do you do this? Have you defined an MSRP or CPIM extension? Or have you defined a special MIME type for a body that communicates this?

or

The support for this feature is negotiated in the SDP of the MSRP media block, e.g.:

Offer:

Answer:

PS.

OTR stands for "Off The Record" but I really mean the end-to-end encryption and verification part. Keeping records of the conversations is in my view a separate feature from the end user point of view which does not necessarily require OTR. 

--
Adrian

---

From: Adrian Georgescu <[email-masked]>
Date: Sat, 27 Sep 2014 14:47:57 -0300

No

> Presumably you need to send messages for key exchange. These need to be processed differently from messages that are supposed to be displayed to the end user. How are these special messages identified?

OTR protocol defined special sequence of chars like ?OTRv2?

> I must assume that is sufficient for you to negotiate privacy and do key exchange. So I guess you don't use any other unwrapped mime types for that. But I can't determine if you might use special types that have been wrapped with cpim.
> 
> And a general question about all of this: is it a proprietary mechanism? Or is it public?

Above have nothing to do with any any key exchange. Is only signalling the support for toggle history feature.

>> a=features:history-control

It is proprietary but probably it should be defined in these siprec drafts.

--
Adrian

---

From: Adrian Georgescu <[email-masked]>
Date: Sat, 27 Sep 2014 14:53:32 -0300

On 27 Sep 2014, at 14:25, Paul Kyzivat <[email-masked]> wrote:

> IIUC, a message with content type of application/history-off would not be valid within the MSRP session negotiated above. (Unless it was sent within a CPIM wrapper.)

It is within the CPIM.

> Ignoring that, what are the semantics? Are you sending an *empty* message with this content type, to set a mode? Or is this the type of a message containing a body that is to be displayed but not added to the history?

It asks the remote party to toggle its save to history on or off. Is a switch that can be toggled remotely (if the recipient want to honour it).

> How normative is this? Is it advisory to the recipient? Or binding? Doe it need to be acknowledged?

It is advisory as there is no way for force the other recipient to comply with such directive. You cannot control what a remote party will really save in its history database, is a gentlemen's agreement.

--
Adrian