From nobody Wed Jul 29 02:04:44 2015 Return-Path: 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 1CA811A0064; Wed, 29 Jul 2015 02:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Rqv9gLgnASl3; Wed, 29 Jul 2015 02:04:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8031A0041; Wed, 29 Jul 2015 02:04:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.2.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> Date: Wed, 29 Jul 2015 02:04:41 -0700 Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org Subject: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 09:04:43 -0000 Barry Leiba has entered the following ballot position for draft-ietf-xmpp-posh-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection, in that I'm not going to block on these points, but I do ask for some discussion, please; see below. General: You're inconsistent in your use of "URI" and "URL", using the former in Sections 3 and 8, the latter in Sections 1, 3.2, and 10 -- and, of course, calling the member "url", rather than "uri". I'd prefer that you use "URI", but you should, in any case, be consistent. -- Section 3 -- When POSH is used, the first two aspects remain the same: the POSH server proves it identity by presenting a PKIX certificate [RFC5280] Typo: It proves "its" identity, not "it". * If it does not have any PKIX certificate information or a reference to such information for the requested path, it responds with an HTTP client error status code (e.g., 404). Do you really want to leave the status code unspecified ("e.g."), rather than just saying that the code to use is 404? -- Section 3.1 -- o A "fingerprints" field whose value is a JSON array of fingerprint descriptors. Here and elsewhere: the JSON term is "member", not "field" (for members of an object; arrays have "elements"). Please check the content-length in the example; I don't think it's correct (I get 176, assuming CRLF-termination, and 135 even if I get rid of all the pretty-print). Similarly for the example in Section 3.2. If you're using the pretty-print, the content-length should reflect it. If no "expires" field is included or its value is equal to 0, a POSH client SHOULD consider these verification materials invalid. But above you say that having "expires" is a "MUST". Why is this "SHOULD" and not "MUST", and why is 0 not just outright invalid (previous sentence, change "non-negative" to "positive")? (And similarly for Section 3.2.) -- Section 3.2 -- The example shows using the same sort of .well-known URI, but I presume there's no requirement that this referral be to one of those (if there is, the doc should say so). It might be worth making it clear, with something like this (or adjust it if my previous presumption is wrong): OLD o A "url" field whose value is a JSON string specifying the HTTPS URL where POSH clients can obtain the actual certificate information. NEW o A "url" field whose value is a JSON string specifying the HTTPS URL where POSH clients can obtain the actual certificate information. The URL can be a similar .well-known POSH URL, but it need not be. END -- 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: https://hosting.example.net/.well-known/posh/spice/json or this (I prefer the former, but don't really care): https://hosting.example.net/.well-known/posh/spice.json ...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. Hable conmigo... From nobody Wed Jul 29 02:46:21 2015 Return-Path: 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 B7CF21A014B; Wed, 29 Jul 2015 02:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 5pJRMV2OWh8r; Wed, 29 Jul 2015 02:46:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EBC1A0130; Wed, 29 Jul 2015 02:46:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.2.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150729094616.18053.7103.idtracker@ietfa.amsl.com> Date: Wed, 29 Jul 2015 02:46:16 -0700 Archived-At: Cc: draft-ietf-xmpp-dna.ad@ietf.org, draft-ietf-xmpp-dna@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-dna.shepherd@ietf.org Subject: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 09:46:18 -0000 Barry Leiba has entered the following ballot position for draft-ietf-xmpp-dna-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Apart from the ".well-known" issue brought up in my comments to xmpp-posh, I have only one, tiny comment here: -- Section 1 -- If such delegation is not done in a secure manner, then the domain name association cannot be verified. Really small point: many people find these sorts of negative-negative constructions to be confusing, so I suggest this: NEW The domain name association can only be verified when the delegation is done in a secure manner. END From nobody Thu Jul 30 16:57:56 2015 Return-Path: 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 71DE21B2C27 for ; Thu, 30 Jul 2015 16:57:55 -0700 (PDT) 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=unavailable 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 bNmk_ZEDpeg9 for ; Thu, 30 Jul 2015 16:57:54 -0700 (PDT) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) (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 1474A1B2B11 for ; Thu, 30 Jul 2015 16:57:12 -0700 (PDT) Received: by iodd187 with SMTP id d187so69700494iod.2 for ; Thu, 30 Jul 2015 16:57:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=IhCAk9sfcx8QOG4z3Qx+GRl+2BcRVbJ0ZxjQVLS1Bbk=; b=BgfjwvBXADyYb1bnLRVpK7A+s78zsw/HrH9S8LZJTwcY+llrFegFC10GA/qi4Fr9H3 S4YgTfKBPc3BC6XcD6Oprpp4bv41sjpkQG1bq9AK3Kus3lC4wD0C1WWkuPFbNEjtp4l2 3cgt0xlJ2jn4HBzmsB1xUrwlK+wH6qevvBQ+uDhVsJrSpnY1WYYcTy00R1cLJfi5WcPV Ce1zVEnoK/4SM7pV6MCNQdsz0kqN4/ocyMcLu8BXUIMO8v+2qQAyR8lNsMg3L9MgBYvp V5DGuyTCHaQd7J+6LWNvMSBeFaGGjuWc8Dj+ecWIbV+vb3f2Jxnvn/YhYMOa/CRxk4VN v1qw== X-Gm-Message-State: ALoCoQlkngwSfU3ifV1AQe34QAPo3ZL2exYBKCB6aIo/fx0M+9i7PidPOnzcBZ6XOioSBR+tqZc8 X-Received: by 10.107.19.206 with SMTP id 75mr14170592iot.191.1438300632427; Thu, 30 Jul 2015 16:57:12 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:911:7b2:8aa2:8931]) by smtp.googlemail.com with ESMTPSA id y6sm859329igl.17.2015.07.30.16.57.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2015 16:57:10 -0700 (PDT) To: Barry Leiba , The IESG References: <20150729094616.18053.7103.idtracker@ietfa.amsl.com> From: Peter Saint-Andre - &yet Message-ID: <55BAB9D3.2050600@andyet.net> Date: Thu, 30 Jul 2015 17:57:07 -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: <20150729094616.18053.7103.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-xmpp-dna.ad@ietf.org, draft-ietf-xmpp-dna@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-dna.shepherd@ietf.org Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT) X-BeenThere: xmpp@ietf.org 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: Thu, 30 Jul 2015 23:57:55 -0000 On 7/29/15 3:46 AM, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-xmpp-dna-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Apart from the ".well-known" issue brought up in my comments to > xmpp-posh, I have only one, tiny comment here: > > -- Section 1 -- > > If such delegation is not done in > a secure manner, then the domain name association cannot be verified. > > Really small point: many people find these sorts of negative-negative > constructions to be confusing, so I suggest this: > > NEW > The domain name association can only be verified when the delegation > is done in a secure manner. > END Good point. I agree that such double negatives are the sort of construction up with which we shall not put. :-) Peter From nobody Thu Jul 30 18:13:49 2015 Return-Path: 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 A6DC11B2F9D for ; Thu, 30 Jul 2015 18:13:45 -0700 (PDT) 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=unavailable 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 X4xl1OlgTW8a for ; Thu, 30 Jul 2015 18:13:44 -0700 (PDT) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (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 3DEA41B2F9C for ; Thu, 30 Jul 2015 18:13:41 -0700 (PDT) Received: by igr7 with SMTP id 7so7308045igr.0 for ; Thu, 30 Jul 2015 18:13:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=1c4Ses86HMiVo8+UAXFnzuunZuAKsYH2j+cGVFx43Ig=; b=S6pMI+vEs0ZvQpAVMEM2Jx/4fEmJkXLDd+ToeKIEMEpi5G9dRiATIjj5rYBEYQ/R0a xrC9tLpnYOVC1Ggcn0CN2CsQH/ip0AaOOu9Z8g3KkKaQuOru+bZZL35baqIrhGd6Vpcq 1s63pPV5szZdRpV8pp9+XlBxBe9ddTyd38/N00CzralyHlltiFfNcwiczlp+ZhRir4V1 H1NW7arGb7fSCqPqTP/GP4BDBaw4DgFIDaYb54SbNc8oJb32MvFZz4nV4ukzqs2e2HTu K8K7D9UC+w4F6i0UNlPX13QswPtHxg/j/8ybsPXIw+6Ry4D9f2pxuVVcxhJ0XuvyB0Ed 6y5g== X-Gm-Message-State: ALoCoQmAdiq+DoAC/Kw9QHxWCLFJ5WvArwa5H4oBY4IpvJrj1HI0QrIYrXNkqdy2yOoBXzrARWmR X-Received: by 10.50.40.39 with SMTP id u7mr687971igk.71.1438305220654; Thu, 30 Jul 2015 18:13:40 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:644b:2b7f:76c5:30be]) by smtp.googlemail.com with ESMTPSA id x4sm2007245iod.26.2015.07.30.18.13.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2015 18:13:39 -0700 (PDT) To: Barry Leiba , The IESG References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> From: Peter Saint-Andre - &yet Message-ID: <55BACBBF.3060301@andyet.net> Date: Thu, 30 Jul 2015 19:13:35 -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: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org 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 01:13:45 -0000 Hi Barry, thanks for the review. Replies inline. On 7/29/15 3:04 AM, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-xmpp-posh-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > No objection, in that I'm not going to block on these points, but I do > ask for some discussion, please; see below. > > General: You're inconsistent in your use of "URI" and "URL", using the > former in Sections 3 and 8, the latter in Sections 1, 3.2, and 10 -- and, > of course, calling the member "url", rather than "uri". I'd prefer that > you use "URI", but you should, in any case, be consistent. Given that we have implementations, I'd prefer not to change the member name (although I can't remember why we would have named it "url" instead of "uri"). We will, however, make it consistent. > -- Section 3 -- > > When POSH is used, the first two aspects remain the same: the POSH > server proves it identity by presenting a PKIX certificate [RFC5280] > > Typo: It proves "its" identity, not "it". Noted. > * If it does not have any PKIX certificate information or a > reference to such information for the requested path, it > responds with an HTTP client error status code (e.g., 404). > > Do you really want to leave the status code unspecified ("e.g."), rather > than just saying that the code to use is 404? Good point. Specifying 404 would be better. > -- Section 3.1 -- > > o A "fingerprints" field whose value is a JSON array of fingerprint > descriptors. > > Here and elsewhere: the JSON term is "member", not "field" (for members > of an object; arrays have "elements"). Yes, sloppy terminology on our part. We'll clean that up. > Please check the content-length in the example; I don't think it's > correct (I get 176, assuming CRLF-termination, and 135 even if I get rid > of all the pretty-print). Similarly for the example in Section 3.2. If > you're using the pretty-print, the content-length should reflect it. We'll double-check those. > If no "expires" field > is included or its value is equal to 0, a POSH client SHOULD consider > these verification materials invalid. > > But above you say that having "expires" is a "MUST". Good catch. Earlier in the life of this draft, the "expires" member was not required; that changed at one point but we neglected to update this text. > Why is this > "SHOULD" and not "MUST", and why is 0 not just outright invalid (previous > sentence, change "non-negative" to "positive")? On reflection, I see no reason to say SHOULD (i.e., I see no circumstance under which it would make sense for the client to consider the verification materials as valid if the "expires" value is zero). So changing SHOULD to MUST seems like the right thing to do. > (And similarly for > Section 3.2.) Yep. > -- Section 3.2 -- > The example shows using the same sort of .well-known URI, but I presume > there's no requirement that this referral be to one of those (if there > is, the doc should say so). The use of .well-known is not required, it's simply a useful convention. > It might be worth making it clear, with > something like this (or adjust it if my previous presumption is wrong): > > OLD > o A "url" field whose value is a JSON string specifying the HTTPS > URL where POSH clients can obtain the actual certificate > information. > NEW > o A "url" field whose value is a JSON string specifying the HTTPS > URL where POSH clients can obtain the actual certificate > information. The URL can be a similar .well-known POSH URL, but > it need not be. > END +1 > -- 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: > https://hosting.example.net/.well-known/posh/spice/json > or this (I prefer the former, but don't really care): > https://hosting.example.net/.well-known/posh/spice.json > ...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? Peter P.S. My co-author is on vacation right now so I might not be able to coordinate with him quickly. From nobody Thu Jul 30 22:56:04 2015 Return-Path: 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 94BBC1B319C; Thu, 30 Jul 2015 22:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 hO9Wkqs0Irxe; Thu, 30 Jul 2015 22:55:57 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 55D121B3191; Thu, 30 Jul 2015 22:55:57 -0700 (PDT) Received: by vkci6 with SMTP id i6so18008116vkc.3; Thu, 30 Jul 2015 22:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bJgS8ui/6j27h1hVERePtJsfJM0UyHkNCNZ/v0eXUfs=; b=Qskg7UcrrxQFNjYDyIZod4Ty7aG8jcr0AhFOG+vTxPqpsiCyFcmuZnZd5N5oc+Ukki zFUc8neP+SOX7ddxv89GOJ2vMoHCHDC69/JUME+tPgnRKewGLzuVCe8s9YotlIekz/D/ rUa4Qpf9ax1IfHrWLdHecDzG1K4FP/oeNmU4Yg/tZm/bZgIrw6lR9AE2H01Q8cSyva3s DuPQyyUgPKRr8/8DhVm7puFV8uAAgMzNiaS3pahvtiLPkS0QLCQ/xv2xMVmdjVOAMFva GKBkHM46hupAoglR04YRUf2BUZFOCmL4eLE8kd2oiJU38ilwQ755rhpPMvtVgUk16n+l fz1w== MIME-Version: 1.0 X-Received: by 10.52.100.167 with SMTP id ez7mr1702733vdb.80.1438322156523; Thu, 30 Jul 2015 22:55:56 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Thu, 30 Jul 2015 22:55:56 -0700 (PDT) In-Reply-To: <55BACBBF.3060301@andyet.net> References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> Date: Fri, 31 Jul 2015 07:55:56 +0200 X-Google-Sender-Auth: APJVskRFauT6nppsZhcJYWYGqbU Message-ID: From: Barry Leiba To: "Peter Saint-Andre - &yet" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, xmpp@ietf.org, The IESG , draft-ietf-xmpp-posh@ietf.org Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org 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 05:55:59 -0000 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: >> https://hosting.example.net/.well-known/posh/spice/json >> or this (I prefer the former, but don't really care): >> https://hosting.example.net/.well-known/posh/spice.json >> ...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//", define one 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". Barry From nobody Fri Jul 31 07:32:37 2015 Return-Path: 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 A679B1A8937; Fri, 31 Jul 2015 07:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hUqTU-GFVZ4; Fri, 31 Jul 2015 07:32:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 620301A892A; Fri, 31 Jul 2015 07:32:30 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (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 ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Barry Leiba" Date: Fri, 31 Jul 2015 09:32:09 -0500 Message-ID: <0688B575-4D67-4390-AFE0-FBD7068749CA@nostrum.com> In-Reply-To: References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org 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: >>> https://hosting.example.net/.well-known/posh/spice/json >>> or this (I prefer the former, but don't really care): >>> https://hosting.example.net/.well-known/posh/spice.json >>> ...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//", > define one 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 ugly) > > Barry From nobody Fri Jul 31 09:39:36 2015 Return-Path: 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 093D31B2E4D for ; Fri, 31 Jul 2015 09:39:35 -0700 (PDT) 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 rxLbfi9RtzxL for ; Fri, 31 Jul 2015 09:39:33 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (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 4570E1B2E46 for ; Fri, 31 Jul 2015 09:39:33 -0700 (PDT) Received: by igr7 with SMTP id 7so19933739igr.0 for ; Fri, 31 Jul 2015 09:39:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=N2VrRqOQ1MSKzHKWXLDUKk6DXwgSJ6W//tTJWLvpIiU=; b=BIBwf2kJJ9Ux7r77SHgfeuEraYOFSmUFqM5s2Py5ALTBeOQKWlor8o5+oyxIzolkJY R+sSaanrkkCfiODxQRe2ur32AFiFSJRoPTpF9tUzV9JHzMNfSFjy4e1VPriJU1BOzGP7 HK03nsMo593rEa5+vQIrqluuJxVQ2eOa6vnUZkCpsgGL/ns1HK3JKtTuCDTIc3H0b61O NfDYep3dJBNIm0iJrHSZVKHFS5DPpcm4XvpDMFNQLMq2py9en1ONBTednP0id4OaaVtS vfiXZ1ABOA8/zvbV8XkR2x7Vm3BAozSG5kL8Cm2bjTJPTmbCkLneflEV/gMQ55estxtv Ytsw== X-Gm-Message-State: ALoCoQktYy4YSdugnx/5gkiTsmolIr6ui4eNHhdzeAVE2R4C0SbmTQmPF8WR/VMVKjwc8Q9MtlEs X-Received: by 10.50.40.42 with SMTP id u10mr7290991igk.71.1438360772688; Fri, 31 Jul 2015 09:39:32 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id h32sm3599641iod.29.2015.07.31.09.39.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 09:39:31 -0700 (PDT) To: Barry Leiba References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> From: Peter Saint-Andre - &yet Message-ID: <55BBA4C1.6040404@andyet.net> Date: Fri, 31 Jul 2015 10:39:29 -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: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, xmpp@ietf.org, The IESG , draft-ietf-xmpp-posh@ietf.org Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org 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 16:39:35 -0000 On 7/30/15 11:55 PM, 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: >>> https://hosting.example.net/.well-known/posh/spice/json >>> or this (I prefer the former, but don't really care): >>> https://hosting.example.net/.well-known/posh/spice.json >>> ...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. Yes, we talked with Mark Nottingham (expert reviewer for the well-known URIs registry, co-author of RFC 5785) about that option, too. His preference was for the approach that's currently documented in the spec. > If you like, it could even do POSH service names and POSH format > names, and specify ".well-known/posh//", Currently it's the field that we're most interested in. > define one as "json" and say that a registry could be > created in future if necessary. That strikes me as excessively flexible, since it would imply the use of data formats other than JSON (say, XML?). Given that POSH is, we strenuously hope, a temporary workaround while DNSSEC and DANE become more widely deployed, I don't foresee the need for extensibility here. Naturally, DNSSEC/DANE might never take off, but thankfully that doesn't seem to be the current trajectory. > 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". Perhaps it makes sense to talk about it again with Mark? Peter -- Peter Saint-Andre https://andyet.com/ From nobody Fri Jul 31 18:50:36 2015 Return-Path: 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 859401A86FE; Fri, 31 Jul 2015 18:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 kYVwwOhopgjL; Fri, 31 Jul 2015 18:50:29 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 9BDD01A86F7; Fri, 31 Jul 2015 18:50:29 -0700 (PDT) Received: by vkgc186 with SMTP id c186so26833715vkg.0; Fri, 31 Jul 2015 18:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cAx3/pPoZLpV/0zq9fW28FAtEkEvy5jjqaW4Lweymr8=; b=PmkoRgTU0G8BgcJag7IZVF090H8PY7EDsmi1MDCDqgs2RkoiRQgaC8gKXEwXKc0B7t g8SidQWghqVsDBt4reZUnvmJDJWGbGLG3gOASUSlSVUbZ9UB8kmswsTOco2hp+wnS6Rv gAyGweCs6hRpDHUsrylC0xeb6FsFssTVYo+glu61qjQEI8ueMoH2GWS3jsGvMwtb/qNC iIMOhG2RHRlaeWdhsrS7iJh2EN1wf29u0j78KYH2Z5QzfOZ7kmnqDl615wsjyIblvWPI TB0knXzVWrwkUeBmt4Gwr1P5Iyq+DH36aTXLmQ+teNjwQYTFLrLmVqYf25SwOznFiRfI kBIQ== MIME-Version: 1.0 X-Received: by 10.52.38.197 with SMTP id i5mr9230166vdk.52.1438393828869; Fri, 31 Jul 2015 18:50:28 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Fri, 31 Jul 2015 18:50:28 -0700 (PDT) In-Reply-To: <55BBA4C1.6040404@andyet.net> References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> Date: Sat, 1 Aug 2015 03:50:28 +0200 X-Google-Sender-Auth: u72BbfbVCcMhwrZxb-XpXqd5GAQ Message-ID: From: Barry Leiba To: "Peter Saint-Andre - &yet" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, The IESG , draft-ietf-xmpp-posh@ietf.org Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org 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: Sat, 01 Aug 2015 01:50:30 -0000 >> If you like, it could even do POSH service names and POSH format >> names, and specify ".well-known/posh//", > > Currently it's the 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. b