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

Peter Saint-Andre - &yet <> Wed, 12 August 2015 00:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 385491A8A89 for <>; Tue, 11 Aug 2015 17:58:02 -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 YQ5fL1PIxK2B for <>; Tue, 11 Aug 2015 17:58:01 -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 9325A1ACD4F for <>; Tue, 11 Aug 2015 17:57:57 -0700 (PDT)
Received: by igui7 with SMTP id i7so52122674igu.1 for <>; Tue, 11 Aug 2015 17:57:57 -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=Lq9JTLxh+FkLZZHoLKRwGCWyGckY34RQyhxMz1rC6k8=; b=E7v6PbA8gLIGp1+hLqPrkO9Hineo3ct6jso3c77Gmyxiz8nLnKpw8zsr1AJ2683skn cxrmD10KMyDTAgOGlVm7iNVcedRWhwtKV9vPGSd59L+m2wLq4EscaTUU0oVtY7Nehs76 ukDkjGT+Ix/Fz0xBdUCDGt74Y5LRlOzayjcc6LeQko0Z6ccpjgFh1U4AnTlSnPBbaX+K wFVdV3xMBJTj4tcyc6gsfZmUAVtaAsJGEAt/MofKArvCma8mLgmzDgauen/9TO41MWBX 0cmDZUNH8t2nkMflISsic9Td9wp5HSNK27DzNKKHwbDfE5/3ROlhg3QwCfXeJzwApCXS k4gg==
X-Gm-Message-State: ALoCoQlALkfAUzcYAuXnaThyGdu4WFc150fgbgm1gli0juyBwUJPyi7TrvOrMQFzsTNS5xmwB0qf
X-Received: by with SMTP id fn2mr22044582igb.55.1439341076760; Tue, 11 Aug 2015 17:57:56 -0700 (PDT)
Received: from aither.local ([2601:282:4201:ef5b:b4bc:6cdf:f03:aabe]) by with ESMTPSA id z6sm9365238ign.12.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 17:57:55 -0700 (PDT)
To: Barry Leiba <>
References: <> <> <> <> <>
From: Peter Saint-Andre - &yet <>
Message-ID: <>
Date: Tue, 11 Aug 2015 18:57:52 -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: Wed, 12 Aug 2015 00:58:02 -0000

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.


Peter Saint-Andre