IETF Logo Mail Archive

Re: [tcpm] SYN/ACK Payloads, draft 01

"Adam Langley" <agl@imperialviolet.org> Thu, 14 August 2008 20:25 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339403A68C2; Thu, 14 Aug 2008 13:25:36 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7D33A6851 for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 13:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.538
X-Spam-Level:
X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEJOVHYN7ccP for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 13:25:34 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id E871B3A67F8 for <tcpm@ietf.org>; Thu, 14 Aug 2008 13:25:33 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so515682rvf.49 for <tcpm@ietf.org>; Thu, 14 Aug 2008 13:25:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=lJnMjRBsORiXwVaRf5sG7Kte31A4TVEoOXtqW+hN+vo=; b=Orw7LCdFKS0XTnHDpUUx1jFz2/hR6L0lLtjnYtqWUt+V+COqpkEy9GVIbEb6VMHN5p /sDEA+ETZW1xasKK+dLhY+jxpmOCE4dnN46D2Km0dVAkUfFgHrT+kAeMti9wXUIDzp72 HkmwQDa2zaqCVFfxzHdyOq1Mp7jBlyyETDHTo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=bTV3gf+YSYHUbi8wTPnWTA9lkx2nHJV+56P9tUivEFezB5dWAq9dULmpdq93zL61bp WQO2vyr2t5KYBAipF47saFvlfuGrZa5sClbOnt0nIhif1RxY9GG71XBRcSEzQZFio1rp WxdK0y+iHfTvnNqhL+AHsflM4pmAodQ9Xyov4=
Received: by 10.141.195.5 with SMTP id x5mr1002142rvp.263.1218745508350; Thu, 14 Aug 2008 13:25:08 -0700 (PDT)
Received: by 10.141.37.3 with HTTP; Thu, 14 Aug 2008 13:25:08 -0700 (PDT)
Message-ID: <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com>
Date: Thu, 14 Aug 2008 13:25:08 -0700
From: Adam Langley <agl@imperialviolet.org>
To: Joe Touch <touch@isi.edu>
In-Reply-To: <48A491B9.3000209@isi.edu>
MIME-Version: 1.0
Content-Disposition: inline
References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A383F0.9030601@isi.edu> <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> <48A491B9.3000209@isi.edu>
X-Google-Sender-Auth: 4869652acc1cd3fb
Cc: tcpm@ietf.org
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Thu, Aug 14, 2008 at 1:12 PM, Joe Touch <touch@isi.edu> wrote:
> Client-speaks-first puts data in the SYN, not the SYN-ACK. Or have you
> got the roles reversed, as with FTP data connections?

Sorry, I was speaking of the application layer protocol. Commonly,
client-speaks-first application protocols are putting data in the
final ACK of the 3-way handshake.

> If the option is ignored, and you don't intend to change TCP semantics,
> then the data - i.e., the hash or whatever - needs to be sent in the
> next data packet.

Ok, I'm fine with that. But there will always be servers which ignore
the option because they don't understand it. In that case, obviously,
they can't send it in the next packet.


AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

v2.23.0 | Report a Bug | By Email