Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Wed, 12 August 2015 01:48 UTC

Return-Path: <ben@nostrum.com>
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 A0CFD1A1BB0; Tue, 11 Aug 2015 18:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
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 Dmmh810NGRXD; Tue, 11 Aug 2015 18:48:43 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3B41A1A29; Tue, 11 Aug 2015 18:48:43 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7C1mOKD035677 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2015 20:48:35 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: Ben Campbell <ben@nostrum.com>
To: Peter Saint-Andre - &yet <peter@andyet.net>
Date: Tue, 11 Aug 2015 20:48:24 -0500
Message-ID: <C4930219-3403-4782-869B-2348A7BFBEEB@nostrum.com>
In-Reply-To: <55CA9A10.2080603@andyet.net>
References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <CALaySJ+k6Pt6b6UvhKNYgsk+=nMRfiSocd_T8aatRvLq4Vg+-w@mail.gmail.com> <55BBA4C1.6040404@andyet.net> <CALaySJLWDfRuCdziHSKqPFJ136d3O45Z7JDnYzDfQEZsKUsfdA@mail.gmail.com> <55CA9A10.2080603@andyet.net>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.2r5107)
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/OZ2RKQwCQDLtPu6qlK_X7d1IX0w>
Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, Barry Leiba <barryleiba@computer.org>, draft-ietf-xmpp-posh@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT)
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 12 Aug 2015 01:48:44 -0000

On 11 Aug 2015, at 19:57, Peter Saint-Andre - &yet wrote:

> On 7/31/15 7:50 PM, Barry Leiba wrote:
>>>> If you like, it could even do POSH service names and POSH format
>>>> names, and specify ".well-known/posh/<servicename>/<formatname>",
>>>
>>> Currently it's the <servicename> field that we're most interested 
>>> in.
>>
>> Right... and that's what I'm suggesting an FCFS registry for.  You
>> register "posh" in .well-known, and you create your own FCFS registry
>> for service names, and if you don't care about the format as a
>> separate thing, you just register "spice.json" (and so on) in your
>> FCFS registry.  That way, Mark doesn't get involved in approving
>> "posh.x" and "posh.y" and "posh.z", when Mark has no idea of what to
>> say about posh service names (or seedy ones, for that matter).
>
> I'm warming to this suggestion. Part of my hesitation was caused by 
> the fact that I had misunderstood RFC 5785. I somehow had the 
> impression that it discouraged path components beyond the registered 
> name, but that impression was false:
>
> Typically, a registration will reference a specification that defines
> the format and associated media type to be obtained by dereferencing
> the well-known URI.
>
> It MAY also contain additional information, such as the syntax of
> additional path components, query strings and/or fragment identifiers
> to be appended to the well-known URI, or protocol-specific details
> (e.g., HTTP [RFC2616] method handling).
>
> However, I haven't yet had an opportunity to discuss this in depth 
> with my co-author. We'll be back in touch once we've talked about it 
> and perhaps discussed it with implementers.

For the record, I do not object to this change. I can even see the 
advantage. But let's keep in mind that there was working group consensus 
(such as it was) to do things as currently written. We can change that 
if there is good reason--but I want to make sure people think the reason 
is really good enough (with all due respect to Barry and Stephen).

If we do change it, we should probably consider an abbreviated WGLC on 
just this point. (Or perhaps the discussion with implementors would 
serve the same purpose.)

Thanks!

Ben.