Re: [plasma] Plasma transport and encoding

"Jim Schaad" <jimsch@nwlink.com> Thu, 28 June 2012 04:14 UTC

Return-Path: <jimsch@nwlink.com>
X-Original-To: plasma@ietfa.amsl.com
Delivered-To: plasma@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE71111E8136 for <plasma@ietfa.amsl.com>; Wed, 27 Jun 2012 21:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo14mYq6M6h4 for <plasma@ietfa.amsl.com>; Wed, 27 Jun 2012 21:14:27 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id B4AE811E808D for <plasma@ietf.org>; Wed, 27 Jun 2012 19:43:27 -0700 (PDT)
Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id E668538F29; Wed, 27 Jun 2012 19:43:25 -0700 (PDT)
From: Jim Schaad <jimsch@nwlink.com>
To: 'Dan Griffin' <dan@jwsecure.com>, plasma@ietf.org
References: <B66E1F139A0F29418103E63A6124AC1C09FDFB2E@BY2PRD0511MB427.namprd05.prod.outlook.com>
In-Reply-To: <B66E1F139A0F29418103E63A6124AC1C09FDFB2E@BY2PRD0511MB427.namprd05.prod.outlook.com>
Date: Wed, 27 Jun 2012 19:42:05 -0700
Message-ID: <018001cd54d7$9ceaae60$d6c00b20$@nwlink.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0181_01CD549C.F091F0E0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGoOGa8EG3q6ie+V3p589Gxm2B+jpdZPkAQ
Content-Language: en-us
Subject: Re: [plasma] Plasma transport and encoding
X-BeenThere: plasma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." <plasma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plasma>, <mailto:plasma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/plasma>
List-Post: <mailto:plasma@ietf.org>
List-Help: <mailto:plasma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plasma>, <mailto:plasma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2012 04:14:28 -0000

A new section has been added to the document to address this question.
Please ensure that all points are dealt with.

 

    <section title="Message Transmission">

      <t>Plasma messages are sent over a TCP connection using port TBD1 on
the server.  The client first setups up TLS on the connection, then sends
the UTF8 encoded XML message over the TLS connection as an atomic message.
No Byte Order Mark (BOM) is sent as the encoding is 8-bit ASCII.  The
response comes back on the same connection.  The client is responsible for
closing the TLS session and the TCP connection when either no more messages
are to be sent to the server or a final indeterminate state has been
reached.</t>

      <t>If a Plasma server receives an XML request which is not well formed
XML, the server if free to close the connection without first sending an
error reply.</t>

      <t>The Plasma server SHOULD support TLS resumption <xref
target="RFC5077"/>. </t>

      <t>Plasma clients and server MUST support TLS 1.1 <xref
target="RFC4346"/> and above.  Implementations SHOULD NOT allow for the use
of TLS 1.0 or SSL.</t>

    </section>

 

 

Jim

 

 

From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of
Dan Griffin
Sent: Wednesday, June 27, 2012 1:13 PM
To: plasma@ietf.org
Subject: [plasma] Plasma transport and encoding

 

Hi all - we're implementing a proof of concept Plasma server using WCF in
Microsoft .NET and we want to maximize the likelihood that our solution is
interoperable. We see in section 4 of EPS TRUST that TLS 1.1 is a
requirement, but questions such as transport and message encoding seem to
have been left open. Are text-encoded SOAP 1.x messages over HTTP what's
intended?

 

Thanks,

Dan