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

Peter Saint-Andre - &yet <> Mon, 03 August 2015 23:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F11891B31F8 for <>; Mon, 3 Aug 2015 16:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
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=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 02CLmsu2yZ_x for <>; Mon, 3 Aug 2015 16:31:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 319681B29BD for <>; Mon, 3 Aug 2015 16:31:19 -0700 (PDT)
Received: by iodd187 with SMTP id d187so809472iod.2 for <>; Mon, 03 Aug 2015 16:31:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=WTVRVQ9/DchYM09j+zlL3+hJ6HrXhg55toa+Hrt9Abg=; b=QBMiVzZPKOqDBiUf3wGfmKUva3NOYxMTzPGG8ViL3d+sBKfijC2qpZdnqeSGmK6hCr 8S1INKV4dNi0J7Hqthxi6XRCHv9DNz5yJwDIY8a+E6iGvcNh+KuBVlByGTxCpl9Tdcmi VHgt3oHIO1R8+UeoVClb4kw0gYSV4i/16nLjfNEG47WKuZIu+XMudygsxl69ADtKAhdl 1/UtGesWL0PEGTpbccL3gDNkBaIvWC49HzhE/TxcAWAgLi3Nd+aLXUAzym/HsjbHAXQt uWWaihc1e/NhNvvor+F74irKx9eOqLT4ekOBb/XCLaSbm0bS1s/IIrMxYXWq1Y1ZYfBm I81Q==
X-Gm-Message-State: ALoCoQkTcrelxyWoBuujv1gW5GFeuYfGl9c4cw8fG5kow98FtPSdZMigsXT3C1nm8r0QqH1n/7M8
X-Received: by with SMTP id g19mr528786iod.3.1438644678608; Mon, 03 Aug 2015 16:31:18 -0700 (PDT)
Received: from aither.local ([2601:282:4201:ef5b:5181:be11:62dd:5bb8]) by with ESMTPSA id fv2sm6829684igb.22.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2015 16:31:17 -0700 (PDT)
To: Barry Leiba <>, Mark Nottingham <>
References: <> <> <> <> <>
From: Peter Saint-Andre - &yet <>
Message-ID: <>
Date: Mon, 3 Aug 2015 17:31:15 -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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 03 Aug 2015 23:31:23 -0000

Adding Mark to this thread, with pointers to get him up to speed...

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).
>> Perhaps it makes sense to talk about it again with Mark?
> Sounds like a plan.

Hi Mark,

During IESG review of draft-ietf-xmpp-posh, Barry raised a question 
about the .well-known registration, which you and Matt Miller and I 
talked about ages ago. Here are some relevant readings:

Barry's proposed approach is more elegant. However, my feeling is that 
POSH is essentially a one-off workaround for use in XMPP until DNSSEC 
and DANE are more widely deployed. Although we've tried to design it in 
such a way that it *could* be used by other application protocols, I 
doubt that folks in those communities will use POSH unless Matt and I 
start actively promoting it (and even that is only a necessary 
condition, not a sufficent one). Because I don't think that we'll see 
additional .well-known registrations related to POSH, setting up a 
separate POSH registry to supplement a "posh" entry in the well-known 
URIs registry feels like overkill to me given the burden on IANA (I'm 
not a fan of one-entry registries).

That said, people have been wrong before about the popularity of 
technologies defined in RFCs and it's possible that POSH could become 
more popular, in which case I'd lean more strongly toward the approach 
that Barry has outlined.

As the designated expert for the well-known URIs registry, do you have 
any suggestions or preferences on how to proceed?