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

"Ben Campbell" <> Fri, 31 July 2015 14:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A679B1A8937; Fri, 31 Jul 2015 07:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4hUqTU-GFVZ4; Fri, 31 Jul 2015 07:32:30 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 620301A892A; Fri, 31 Jul 2015 07:32:30 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.14.9) with ESMTPSA id t6VEW9b7088155 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 31 Jul 2015 09:32:19 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
To: Barry Leiba <>
Date: Fri, 31 Jul 2015 09:32:09 -0500
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.2r5107)
Archived-At: <>
Cc:,,,,, The IESG <>
Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Jul 2015 14:32:32 -0000

On 31 Jul 2015, at 0:55, 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:
>>> or this (I prefer the former, but don't really care):
>>> ...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.
> If you like, it could even do POSH service names and POSH format
> names, and specify ".well-known/posh/<servicename>/<formatname>",
> define one <formatname> as "json" and say that a registry could be
> created in future if necessary.
> 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".

I'm a bit confused, is it seems like the effective end result would 
still be hierarchical well-known URLs. So I guess I have to wonder why 
they are prohibited from the well-known registry in the first place. Was 
there some problem the original authors were trying to avoid?

(And for the record, I agree that the current "template" approach is 

> Barry