Re: [xmpp] PROTO review of draft-ietf-xmpp-posh

Peter Saint-Andre - &yet <peter@andyet.net> Mon, 23 February 2015 22:53 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 731AB1A0262 for <xmpp@ietfa.amsl.com>; Mon, 23 Feb 2015 14:53:13 -0800 (PST)
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 ufWckCI6dS2Q for <xmpp@ietfa.amsl.com>; Mon, 23 Feb 2015 14:53:11 -0800 (PST)
Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (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 0773E1A0235 for <xmpp@ietf.org>; Mon, 23 Feb 2015 14:53:11 -0800 (PST)
Received: by iecvy18 with SMTP id vy18so27409733iec.13 for <xmpp@ietf.org>; Mon, 23 Feb 2015 14:53:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6eg01lW2gmNlgThoiLF0h+7FJyaBDBSZ9v5PjTtSqWs=; b=ZOMliNX/WgM6p9z+Pnq7AadjZ8G1K5ekhtpbBvgdfVw/7d0WP5aTPXKTcby5/lwA33 r2I7mBlXF/Uuj9gaIEnFxx1bIInqNR8jGp613hNif3zWh10osZcsfu29YRK4EJv7781T pQFqDQt/RDUPLEKqHyRbQ1pvky0rPq7m5bDOv4ni2lIye1gty7LiOYnz91LZ3g9JVV// pNkhQMcMDHx5RlkSgNEcrTntOkV8UZ7/9KDKctHPtyjbM1qLQ2E0E/8oYJEaXpqU1TgM jnbFwdycuMkGzhtWJXvonYMjyzCyp3OTxnxqj8Y73vbX9TQm2PhSL5ptMcDLve06twYO nRAg==
X-Gm-Message-State: ALoCoQmt5e/1r3BJHxCgQS1WD+jUHjvzm5sy0qx1IVgthaPOoYEq2xM0lIZDQjdlcA69icxPAPzN
X-Received: by 10.107.136.26 with SMTP id k26mr15760819iod.26.1424731990469; Mon, 23 Feb 2015 14:53:10 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id k2sm4112925iod.13.2015.02.23.14.53.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 14:53:09 -0800 (PST)
Message-ID: <54EBAF53.9020904@andyet.net>
Date: Mon, 23 Feb 2015 15:53:07 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
References: <9A67CFDB-5504-43E0-A63C-82E996A70620@nostrum.com> <54EBA26D.4080000@andyet.net> <5CD6E0B8-CB86-472B-9A3B-9F89274DB2FF@nostrum.com> <54EBAA5C.508@andyet.net>
In-Reply-To: <54EBAA5C.508@andyet.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/5-ZoCpOSHwiJW872fPb6-xOfwRY>
Cc: draft-ietf-xmpp-posh.all@tools.ietf.org, XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] PROTO review of draft-ietf-xmpp-posh
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: <http://www.ietf.org/mail-archive/web/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: Mon, 23 Feb 2015 22:53:13 -0000

On 2/23/15 3:31 PM, Peter Saint-Andre - &yet wrote:
> On 2/23/15 3:10 PM, Ben Campbell wrote:
>> Hi Peter, further comments below. I removed sections that do not seem to
>> need further discussion.
>>
>> On 23 Feb 2015, at 15:58, Peter Saint-Andre - &yet wrote:
>>
>> [...]
>>
>>>>
>>>> — Material Comment: IANA Considerations
>>>>
>>>> These seems a bit unusual, since we are registering a “fragment” that
>>>> other protocols will use to register actual URIs.  This does not
>>>> seem to
>>>> have been contemplated by RFC5785. This also the side effect of
>>>> establishing rules for certain entries in the well-known URI registry
>>>> over and above those from RFC5785.
>>>>
>>>> Does it make sense to actually register the prefix itself, since it’s
>>>> not really a URI? It would seem reasonable to leave the actual
>>>> registration to protocols that need to register posh URIs.
>>>
>>> You make a very good point. I think you're right that it makes more
>>> sense for the POSH spec to provide instructions to protocols that need
>>> to register POSH URIs - as, for instance, draft-ietf-xmpp-dna does -
>>> but not to register a URI prefix (instead, just say "please use the
>>> prefix").
>>
>> So if I understand the implications of this path, it would mean we give
>> guidance that any protocol that uses posh should register a “posh.*”
>> URL.
>
> Yes but that's really just for a friendly consistency.
>
> Matt and I chatted about it over IM and we both recalled that we were
> trying to prevent crazy registrations in .well-known (this was around
> the time that Mark Nottingham was starting to work on the evocatively
> named draft-nottingham-uri-get-off-my-lawn, now RFC 7320).
>
>> (I note that the well-known URI registry uses the specification
>> required policy. Is that adequate for POSH use?).
>
> I think so. Over time we've tried to become more liberal about IANA
> registrations policies.
>
>> But this doc would not
>> register anything.
>
> Correct.
>
>> Would that guidance still go in the IANA
>> considerations section? I suspect the answer is probably not.
>
> It would go in another section since we wouldn't be registering
> anything, nor would we be providing actionable guidance to IANA.
>
>> Also, does anything implode if some protocol chooses not to use the POSH
>> prefix?
>
> No imminent implosions to worry about.
>
>> Do we actually care?
>
> Not much, although as I said it provides a friendly consistency.
>
>> I assume we don’t expect developers to try
>> to guess well-known URIs.
>
> That's true.
>
>>>> I see Mark Nottingham is the expert for the well-known URI registry. By
>>>> any chance has anyone run this by him?
>>>
>>> I have a vague recollection of having talked with him about it once,
>>> but I can find no evidence of that in my email folders. If we agree
>>> that what you suggest is the best approach, then I think it makes
>>> sense to update the document before reaching out to him (and in fact
>>> that might not be necessary since this document wouldn't be doing
>>> anything unusual).
>>
>> I agree that if we don’t register anything, and don’t try to change the
>> well-known URI registration policy for posh purposes, it might not be
>> necessary to involve Mark. (But for the record, if he were okay with the
>> way things are currently documented, I would back off on this point.)
>
> Well, I think the way things are currently documented is misguided, so
> we might as well correct it.

Here is proposed text:

###

8.  Guidelines for Protocols that Use POSH

    Protocols that use POSH will need to register well-known URIs wth the
    IANA in accordance with [RFC5785] (the IANA registration policy
    [RFC5226] for well-known URIs is Specification Required).

    For the sake of consistency, it would be best if the URIs registered
    by such protocols match the URI template [RFC6570] path "/.well-known
    /posh.{servicedesc}.json"; that is, begin with "posh." and end with
    ".json" (indicating a media type of application/json [RFC7159]).

    For POSH-using protocols that rely on DNS SRV records [RFC2782], it
    would be best if the "{servicedesc}" part of the well-known URI is
    "{service}.{proto}", where the "{service}" is the DNS SRV "Service"
    prepended by the underscore character "_" and the "{proto}" is the
    DNS SRV "Proto" also prepended by the underscore character "_".  As
    an example, the well-known URI for XMPP server-to-server connections
    would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers
    a service name of "xmpp-server" and uses TCP as the underlying
    transport protocol.

    For other POSH-using protocols, the "{servicedesc}" part of the well-
    known URI can be any unique string or identifier for the protocol,
    which might be a service name registered with the IANA in accordance
    with [RFC6335] or which might be an unregistered name.  As an
    example, the well-known URI for a hypothetical "SPICE" application
    could be "posh.spice.json".

###

Peter

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