Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt

Martin Thomson <> Mon, 08 July 2013 21:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF09021F9E3B for <>; Mon, 8 Jul 2013 14:57:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.416
X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mC1kvw5Jnl-B for <>; Mon, 8 Jul 2013 14:57:14 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::229]) by (Postfix) with ESMTP id E11F921F9DED for <>; Mon, 8 Jul 2013 14:57:10 -0700 (PDT)
Received: by with SMTP id n57so4167884wev.14 for <>; Mon, 08 Jul 2013 14:57:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J/qqY0CP4m+YO4eL9CCmnP9VqdFi2lWbfEpDspbb1OI=; b=TqxpJCb3NsvulN0O2fyus92zRZSuQ15/rDBtN7kDsgHoXoVbMayd/yHyn14F+eqzCZ /cj/6dWxneT2RVd9I10vkyF8ZSZmXfcS2EI1pbsfpKdkBr4kYmZAjAUSHoV0lQwYOjfb p+3XB+946oNcy4ZuBnE8S4v2qEBIKwPuQeeJMFhKEUnk2UXmt0FU9g8efN27ACjhSZ0l AqfPxEcXOyp3ECqdkNJE/UNIFCLfmidgscwi79BGM69im6r+DBM8TbBWUHRn7wHnv4wL TSv9shCFY3gq6yzWR0yYXZtvWxgEPqrjKAY9yRekC/BHeRJgKyPWtdD94b7b6EIt55sl BjaA==
MIME-Version: 1.0
X-Received: by with SMTP id r3mr13423494wjw.5.1373320629980; Mon, 08 Jul 2013 14:57:09 -0700 (PDT)
Received: by with HTTP; Mon, 8 Jul 2013 14:57:09 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 8 Jul 2013 14:57:09 -0700
Message-ID: <>
From: Martin Thomson <>
To: Adam Roach <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Jul 2013 21:57:15 -0000

On 8 July 2013 14:50, Adam Roach <> wrote:
> I only find one issue in my initial read through the document: why are we
> proposing the use of HTTP POST for stateless, idempotent information
> retrieval? The key benefit of this approach is that it doesn't actually
> create state in the network. That's a much better fit for GET.

That's an interesting question.  From one perspective, this is not
idempotent, nor is it safe.  It creates a new resource: a new
username/password pair with a defined validity.  You could even
identify this "resource" with a URI.  Imagine what a DELETE on that
resource would do...

But it's equally valid to try to pretend otherwise and use GET.  After
all, most servers won't actually be allocating any state for these
things.  And I can't think of an actual, practical use for DELETE, so
that's just a silly feature.


p.s., I was going to let this slide, but this design is not RESTful,
no sense in pretending like it is.