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/
- [xmpp] PROTO review of draft-ietf-xmpp-posh Ben Campbell
- Re: [xmpp] PROTO review of draft-ietf-xmpp-posh Peter Saint-Andre - &yet
- Re: [xmpp] PROTO review of draft-ietf-xmpp-posh Ben Campbell
- Re: [xmpp] PROTO review of draft-ietf-xmpp-posh ⌘ Matt Miller
- Re: [xmpp] PROTO review of draft-ietf-xmpp-posh Peter Saint-Andre - &yet
- Re: [xmpp] PROTO review of draft-ietf-xmpp-posh Peter Saint-Andre - &yet
- Re: [xmpp] PROTO review of draft-ietf-xmpp-posh Ben Campbell