Re: [xmpp] AD review of draft-ietf-xmpp-websocket

Lance Stout <lance@andyet.net> Fri, 20 June 2014 21:35 UTC

Return-Path: <lance@andyet.net>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE251B2909 for <xmpp@ietfa.amsl.com>; Fri, 20 Jun 2014 14:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 069NJJZd2k-w for <xmpp@ietfa.amsl.com>; Fri, 20 Jun 2014 14:35:20 -0700 (PDT)
Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9991A0283 for <xmpp@ietf.org>; Fri, 20 Jun 2014 14:35:20 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id w10so3396702pde.17 for <xmpp@ietf.org>; Fri, 20 Jun 2014 14:35:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=zee07dQ0Iuv/VgtgPBEOHJR3otroYOlRXljmIFSAphg=; b=OEhabRB+509IXhVHczfIT9zHVx9jGBs4PMeGrdcj2WcA9z5W4thdAg5k8evblVRuxe PHvTjGUM455LKJeQDDDB7ll1bQWYs9ZhmFJeuRbkPsiQmysdTBgAdvYoVcHWgxDiuGoG p/yrPFZwg2LGMK7fhy2UBTLguAPP4PcM588OVORJLeIcM680o5crFdrFOiFTZIqXP080 a5JxowuC3zi/R7jXTjmzUos3tWkoPGMJxjmOx3oCGQG2aC+H4Tvcf/eg0Su7K5fOCoCv zja+SNkqZs4OxnUNBPpzCQQ6Z8ndn7DfZHT7GnrzuK3Mf5/CEyi6l6fXCLqi2FlaEFf5 G5yA==
X-Gm-Message-State: ALoCoQkmrPqF1/+oLJF4D7SeOuVLbDwQSC9Grcg2qSDmUPOGlt1nSCTXuzkpa031WLaKlQ7YgdJQ
X-Received: by 10.66.156.71 with SMTP id wc7mr8210555pab.64.1403300119990; Fri, 20 Jun 2014 14:35:19 -0700 (PDT)
Received: from [192.168.1.23] (66-191-14-77.static.knwc.wa.charter.com. [66.191.14.77]) by mx.google.com with ESMTPSA id zb2sm15007601pbb.45.2014.06.20.14.35.18 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 14:35:18 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_8C554B1D-7471-4E85-B409-273075C09CE9"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Lance Stout <lance@andyet.net>
In-Reply-To: <CAL02cgSGKyKgL44tJXLat8x8_TR2yKmzkFk_BzJC=7TG5txe1g@mail.gmail.com>
Date: Fri, 20 Jun 2014 14:35:17 -0700
Message-Id: <617D9F2E-D236-48C8-902F-9BDFEDD92F91@andyet.net>
References: <CAL02cgSGKyKgL44tJXLat8x8_TR2yKmzkFk_BzJC=7TG5txe1g@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/PeGj-edyt0hvTAzD03jhfAsKEAI
Cc: XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] AD review of draft-ietf-xmpp-websocket
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jun 2014 21:35:22 -0000

> MINOR
> 
> S3.1. "WebSocket messages sent or received will conform"
> Should this be "MUST conform"?

Makes sense to me to make that MUST, since that's the entire point of this document.


> S3.6.1. "a different transport, such as BOSH"
> How is the recipient of one of these messages supposed to tell what transport?  Does the use of an http- or https-schemed URI imply BOSH?

I would assume that's implied, as BOSH is the only defined transport for the http/https scheme, and I don't expect for us to define another given the existing deployment base.

However, I can see where this could get fuzzy. Any suggestions on a solution?


> S3.7. "[Streams implicitly closed]"
> Does this usage map cleanly to the TCP case?  That is, would a </stream> element be sent in this closure case?  I'm just imagining that if you have, say, a relatively naïve gateway that translates <stream> to <open> and </stream> to <close>, this could cause problems.

Yes, this intentionally mirrors the process used in the TCP binding. The Prosody implementation of this spec actually does exactly that 'naïve gateway' approach internally to convert the framed stream to the TCP C2S stream format to reuse its existing code paths.



- Lance