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

[Paul Kyzivat <[e-mail]>]

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 <[e-mail]>
To: 	Paul Kyzivat <[e-mail]>



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 <[e-mail]
<mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>>
> To: [e-mail] <mailto:[e-mail]> <[e-mail]
> <mailto:[e-mail]>>
>
> 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: [e-mail] <mailto:[e-mail]>
> To: Michael Yan <[e-mail]
> <mailto:[e-mail]>>,        "Paul H. Kyzivat"
> <[e-mail] <mailto:[e-mail]>>,
>        "Michael Yan" <[e-mail]
> <mailto:[e-mail]>>,
>       "Paul Kyzivat" <[e-mail]
> <mailto:[e-mail]>>
>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec
>
>
>

--
Adrian