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

Peter Saint-Andre - &yet <peter@andyet.net> Fri, 31 July 2015 16:39 UTC

Return-Path: <peter@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 093D31B2E4D for <xmpp@ietfa.amsl.com>; Fri, 31 Jul 2015 09:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 rxLbfi9RtzxL for <xmpp@ietfa.amsl.com>; Fri, 31 Jul 2015 09:39:33 -0700 (PDT)
Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (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 4570E1B2E46 for <xmpp@ietf.org>; Fri, 31 Jul 2015 09:39:33 -0700 (PDT)
Received: by igr7 with SMTP id 7so19933739igr.0 for <xmpp@ietf.org>; Fri, 31 Jul 2015 09:39:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=N2VrRqOQ1MSKzHKWXLDUKk6DXwgSJ6W//tTJWLvpIiU=; b=BIBwf2kJJ9Ux7r77SHgfeuEraYOFSmUFqM5s2Py5ALTBeOQKWlor8o5+oyxIzolkJY R+sSaanrkkCfiODxQRe2ur32AFiFSJRoPTpF9tUzV9JHzMNfSFjy4e1VPriJU1BOzGP7 HK03nsMo593rEa5+vQIrqluuJxVQ2eOa6vnUZkCpsgGL/ns1HK3JKtTuCDTIc3H0b61O NfDYep3dJBNIm0iJrHSZVKHFS5DPpcm4XvpDMFNQLMq2py9en1ONBTednP0id4OaaVtS vfiXZ1ABOA8/zvbV8XkR2x7Vm3BAozSG5kL8Cm2bjTJPTmbCkLneflEV/gMQ55estxtv Ytsw==
X-Gm-Message-State: ALoCoQktYy4YSdugnx/5gkiTsmolIr6ui4eNHhdzeAVE2R4C0SbmTQmPF8WR/VMVKjwc8Q9MtlEs
X-Received: by 10.50.40.42 with SMTP id u10mr7290991igk.71.1438360772688; Fri, 31 Jul 2015 09:39:32 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id h32sm3599641iod.29.2015.07.31.09.39.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 09:39:31 -0700 (PDT)
To: Barry Leiba <barryleiba@computer.org>
References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <CALaySJ+k6Pt6b6UvhKNYgsk+=nMRfiSocd_T8aatRvLq4Vg+-w@mail.gmail.com>
From: Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <55BBA4C1.6040404@andyet.net>
Date: Fri, 31 Jul 2015 10:39:29 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CALaySJ+k6Pt6b6UvhKNYgsk+=nMRfiSocd_T8aatRvLq4Vg+-w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/5bRV3Ob2ugDkL2E7XFrCL-eKLFE>
Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, xmpp@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-xmpp-posh@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: Fri, 31 Jul 2015 16:39:35 -0000

On 7/30/15 11:55 PM, Barry Leiba wrote:
> Hi, Peter, and thanks for the quick response.  Only the last issue
> remains to chat further about:
>
>>> -- Section 8 --
>>> I'm not terribly happy with the mechanism of having a faux hierarchy in
>>> the .well-known name (posh.servicename.json), not registering any
>>> .well-known name here, and asking the .well-known registry (via the
>>> designated expert) to register and evaluate each POSH service -- the
>>> .well-known DE is not an expert for POSH.  Also if, using your example,
>>> Victoria Beckham should want to have a .well-known URI to access her
>>> tweets from anywhere, returning them in JSON wrappers, she might want to
>>> register "posh.spice.json", which would then get in the way of that name
>>> for POSH, entirely unintentionally.
>>>
>>> I'd be much happier with using a real URI hierarchy and registering
>>> "posh" as a .well-known name here, so a POSH URI might be this:
>>>      https://hosting.example.net/.well-known/posh/spice/json
>>> or this (I prefer the former, but don't really care):
>>>      https://hosting.example.net/.well-known/posh/spice.json
>>> ...and you might establish an FCFS registry of POSH service names under
>>> which "spice" (or "spice.json") would be registered.  Now you're putting
>>> it all under one .well-known name, and only asking the .well-known expert
>>> to review this one, rather than one for every POSH service.
>>
>> We're not terribly happy with the faux hierarchy, either, and we considered
>> the approach you suggest (and consulted on the matter with Mark Nottingham).
>> Unfortunately, the specification for well-known URIs (RFC 5785) states:
>>
>>     Registered names MUST conform to the segment-nz production in
>>     [RFC3986].
>>
>> Because the segment-nz production does not allow "/", a real hierarchy won't
>> work.
>>
>> In practice, we are not expecting a large number of POSH registrations so I
>> doubt that this would put a significant burden on the DE for the well-known
>> URI registry. However, do you think it would be helpful to provide some
>> additional guidance to the DE in this document?
>
> The hierarchy would work fine: the point is that the registered
> .well-known name would just be "posh", and would be registered once
> here -- and that confirms fine to the .well-known requirements.  This
> document would then specify the use of hierarchy under
> .well-known/posh, and would create a (FCFS) registry for POSH service
> names.

Yes, we talked with Mark Nottingham (expert reviewer for the well-known 
URIs registry, co-author of RFC 5785) about that option, too. His 
preference was for the approach that's currently documented in the spec.

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

> define one <formatname> as "json" and say that a registry could be
> created in future if necessary.

That strikes me as excessively flexible, since it would imply the use of 
data formats other than JSON (say, XML?). Given that POSH is, we 
strenuously hope, a temporary workaround while DNSSEC and DANE become 
more widely deployed, I don't foresee the need for extensibility here. 
Naturally, DNSSEC/DANE might never take off, but thankfully that doesn't 
seem to be the current trajectory.

> I know that changing this would affect current implementations and
> make them change, but I think it's worth it.  On the other hand, if
> you don't agree, I won't push it further.  I just think it'd be much
> better to have just "posh" as the registered .well-known "segment-nz".

Perhaps it makes sense to talk about it again with Mark?

Peter

-- 
Peter Saint-Andre
https://andyet.com/