IETF Logo Mail Archive

Re: [Trans] Some comments on the Web Service part

Phillip Hallam-Baker <hallam@gmail.com> Thu, 06 March 2014 13:12 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD881A017A for <trans@ietfa.amsl.com>; Thu, 6 Mar 2014 05:12:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 3AlBf4072tqL for <trans@ietfa.amsl.com>; Thu, 6 Mar 2014 05:12:46 -0800 (PST)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4F08D1A02CD for <trans@ietf.org>; Thu, 6 Mar 2014 05:12:46 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id hr17so1714686lab.5 for <trans@ietf.org>; Thu, 06 Mar 2014 05:12:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z5EU266hEE6bRG+lBVVg22QtwO3Z/irPfojy+LFSg/w=; b=GU8oMQlLSryubDaC3hFqqAApYuHQQLhCQb/pOYOQxUT5dULEwyAAuboMAcJW+iUwgM QRGFLI8KTwtOJN7zPjBg1TbpleXVEbQOPKVt+ocLq70kVrowOgkxZuuDnxOqxgdA8zjn 7TbASiBcbFyuH6WP+r+tQxZLy5sSLtWhCkkpuZyYKfx8OVJzB+Kwr90p3jjkLqDLkMz7 +ndJbN2ECOSObucV6FIhUQrqNQ3RPzuSIO3XULIwvdCaqwW057M4aqCPTZgdQZumIBYA ZacQS6yayUTmiMp39YP8E2d9320fbcUuR1vQmCL0OZl/aqINVHkM/jtOSpr9FoVvv/o2 8XsQ==
MIME-Version: 1.0
X-Received: by 10.152.190.135 with SMTP id gq7mr8084111lac.28.1394111561746; Thu, 06 Mar 2014 05:12:41 -0800 (PST)
Received: by 10.112.37.168 with HTTP; Thu, 6 Mar 2014 05:12:41 -0800 (PST)
In-Reply-To: <CALzYgEctzKxXJzG43qJJbqsZmT36Z+TkP_woZAYZ3ha2vhSKyg@mail.gmail.com>
References: <CAMm+LwipgTevGFqs0PphNTpn=1ZZgSjVVvMe2Srco4JN8F_fQg@mail.gmail.com> <CALzYgEctzKxXJzG43qJJbqsZmT36Z+TkP_woZAYZ3ha2vhSKyg@mail.gmail.com>
Date: Thu, 06 Mar 2014 13:12:41 +0000
Message-ID: <CAMm+LwjQawRJ6+UbU+Fr56U0AZZSN0YPBRUH8cc2kihNWjXMcg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Eran Messeri <eranm@google.com>
Content-Type: multipart/alternative; boundary="001a11381b506a4e4604f3efe42f"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/tjfsFMzob5U7H4Wax9XbXvzRX6k
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Some comments on the Web Service part
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 13:12:49 -0000

On Thu, Mar 6, 2014 at 11:29 AM, Eran Messeri <eranm@google.com> wrote:

>
>
>
> On Wed, Mar 5, 2014 at 6:41 PM, Phillip Hallam-Baker <hallam@gmail.com>wrote:
>
>> 1) This is a specified service, shouldn't it be registered as a
>> .well-known service?
>>
>> http://example.com/.well-known/ct/1
>>
>> This means that the CT log can play nice with other services on the same
>> server.
>>
>> (obviously have to replace ct with what we register)
>>
> Could you please point to the standard specifying how these well-known
> services are defined?
>

https://tools.ietf.org/html/rfc5785


>  Regardless, it seems to be independent of the commands specification
> that a CT log must conform to.
>

It is a standards nit.


> The Google-managed logs have an address that conforms with the rest of the
> HTTP APIs Google offers. We technically could offer
> https://ct.googleapis.com/.well-known/..., if it provides strong benefit.
>

The benefit here is that we try to get consistency across IETF standards.
And since this is layering over HTTP it is important to make it layer the
same way that other specs layer.


> Since we expect few, well-known logs, I can't see the benefit in
> registering it as well-known service since very few domains are expected to
> offer it (i.e. there is no benefit it making it easily discoverable)
>

Expectations of low use is not a good reason not to conform to an
established practice.



>
>> 2) The command should be present in the JSON request.
>>
>> Do you mean this as an addition or instead of specifying the command in
> the request line?
> Is there a specific web traffic management system that you know/expect to
> cause problem?
>

In addition to the HTTP request line.

Some people are going to want to be able to separate out command handlers
by command. The ADD commands cause a state change to the database, the
request commands don't. So it is worthwhile making it easy to route the
command to the right processor.

This is a very similar argument to the reason why SMTP FROM (RFC821) is not
the same as RFC822 From:


-- 
Website: http://hallambaker.com/

v2.14.0 | Report a Bug | By Email