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

Richard Barnes <rlb@ipv.sx> Fri, 20 June 2014 23:42 UTC

Return-Path: <rlb@ipv.sx>
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 257351A04AC for <xmpp@ietfa.amsl.com>; Fri, 20 Jun 2014 16:42:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 s5hgxuFG0Oca for <xmpp@ietfa.amsl.com>; Fri, 20 Jun 2014 16:42:39 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339FF1A04B8 for <xmpp@ietf.org>; Fri, 20 Jun 2014 16:42:39 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id uy5so1834603obc.3 for <xmpp@ietf.org>; Fri, 20 Jun 2014 16:42:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EAy2VYbmpXIy1GITNF/tL8wlKgEtAmopBMKlIDW1C7Y=; b=JiDxSNb947+oBnMYDOGBGOQkNph5/16T+TGspCpEWa0Pgiex0RdTx89xRSjwOjWRL6 P6J6qYxUf/13o3/hxc1/Yk5RyfbyZVpnx8fwOVdEgb5ZtSovnwsMx/xyRke8wtzOruce 5FgeniBpc1jTGhd3IEUW6TIJLJwQw/gPrDEO64Ts49FCy7tSj3wPsv5taXUVrailprZl l1Tv5s0eZ53CqfXqMHWaePkL26LjfmLPt8ZebUvviFwCrZQ0LVhazjqG2KZR+6+Vfz3+ SPhb8vFH4Cwdqf7zqiL/XB3i7RdfcqEy5BIw7uyyCrlqiuhXKLnAln2isQ5r4KhRSd/C NdDA==
X-Gm-Message-State: ALoCoQmJodTThwFdLrncy/iApm1+yzcoxch2K9ozJAUenOyIxgztboLmE0K4j6xRofy6evT04Kyb
MIME-Version: 1.0
X-Received: by 10.182.24.38 with SMTP id r6mr6849394obf.10.1403307758619; Fri, 20 Jun 2014 16:42:38 -0700 (PDT)
Received: by 10.60.143.131 with HTTP; Fri, 20 Jun 2014 16:42:38 -0700 (PDT)
In-Reply-To: <617D9F2E-D236-48C8-902F-9BDFEDD92F91@andyet.net>
References: <CAL02cgSGKyKgL44tJXLat8x8_TR2yKmzkFk_BzJC=7TG5txe1g@mail.gmail.com> <617D9F2E-D236-48C8-902F-9BDFEDD92F91@andyet.net>
Date: Fri, 20 Jun 2014 19:42:38 -0400
Message-ID: <CAL02cgTm9uUvFyNLK1s0JQWvuPwM24TFeQgwDh477=GV0UXiMA@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Lance Stout <lance@andyet.net>
Content-Type: multipart/alternative; boundary=001a11c29c8276a29e04fc4d0cae
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/fBT6kYgOkgie56RoLtc5uy1Go2M
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 23:42:41 -0000

On Fri, Jun 20, 2014 at 5:35 PM, Lance Stout <lance@andyet.net> wrote:

>
> > 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?


If it wouldn't be too disruptive to change the syntax, you could just do
the same thing as XEP-0156 and specify the protocol explicitly.  Otherwise,
perhaps some text of the form:

"Since BOSH is the only HTTP-based transport for XMPP, an HTTP URI in the
"see-other-uri" attribute indicates that the client should connect using
BOSH.  Likewise, a WebSocket URI indicates that the client should use the
transport defined in this document."

There's some risk that a persnickety AD will ask for a registry (scheme to
protocol mapping), but I think we can push back on that.


> > 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
>
>
>