Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02

John Bradley <ve7jtb@ve7jtb.com> Sat, 23 June 2012 15:35 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9599A21F846B for <oauth@ietfa.amsl.com>; Sat, 23 Jun 2012 08:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.739
X-Spam-Level:
X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VoNFmLJvY+8 for <oauth@ietfa.amsl.com>; Sat, 23 Jun 2012 08:35:48 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B487021F846A for <oauth@ietf.org>; Sat, 23 Jun 2012 08:35:47 -0700 (PDT)
Received: by yenq13 with SMTP id q13so2373548yen.31 for <oauth@ietf.org>; Sat, 23 Jun 2012 08:35:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=xXyFimCUk4SZ2RBTBakuVxI3uVnTbaHvzEJY8wAnwaA=; b=Pt26iPrQRD2ugqI3mSm5x0M3uDFYj+b6Fkaxjd2ewwIoJa+fagcMMBxu2J00r29D4a XFk1B0TQayFg4Z0gep+J32KvFnMtQOYD+GUNUliY9GFV9Pwdh7o2Ykg/y0PTrqe3+hiJ DOHIoAztIccNNIatusqAw4ot3hmVudA/kp+9tYHpEjQ3WHtsqDCQlraQFMgpFMfzzbVx F0HW76tgLnGd6JFGi/PafCJnYJC31lClUIppNlaJmxOky3bgPzg51yKu2gSv2/6evAS3 fGEwxWLaTnKp49MEC6MKF2/rSEVZM6RUauibxIRDPEj4o+f8BS0RGdGSe0YLL4k2x2cf NSPA==
Received: by 10.236.76.233 with SMTP id b69mr6873523yhe.52.1340465747116; Sat, 23 Jun 2012 08:35:47 -0700 (PDT)
Received: from [192.168.1.41] (190-20-54-57.baf.movistar.cl. [190.20.54.57]) by mx.google.com with ESMTPS id p29sm121581588yhl.19.2012.06.23.08.35.43 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Jun 2012 08:35:46 -0700 (PDT)
References: <4FE1C16D.6010602@cs.tcd.ie> <F606CA9D-9DB6-460E-BE7A-BC989A4AB25F@gmx.net> <CAC4RtVCrQ9yG6V_XwczXo_FvCkyCXJDfmrb-p0UX3KRW7Edx9A@mail.gmail.com> <4CD0B85C-C88D-4B52-81E4-5D53A25E60EF@cs.tcd.ie> <CAC4RtVBEjDeoJzbxGwkTHsk2REv8+6GELywR7Sv-dsRm8LGw2A@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739436656365A@TK5EX14MBXC283.redmond.corp.microsoft.com> <B14B7AFA-C6A7-49EE-BC36-BDA8B0FE8814@gmx.net>
In-Reply-To: <B14B7AFA-C6A7-49EE-BC36-BDA8B0FE8814@gmx.net>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/signed; micalg="sha1"; boundary="Apple-Mail-4F7079D0-D7BA-4867-9080-DB3E08442017"; protocol="application/pkcs7-signature"
Message-Id: <A756E768-991F-4A68-A18B-A1E99096BDC5@ve7jtb.com>
X-Mailer: iPad Mail (9B206)
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Sat, 23 Jun 2012 11:35:40 -0400
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Gm-Message-State: ALoCoQm7kMlOV0sa+vRzg/HWiurEUu4ZUhr8ZMe6ImGIbaumprmqbOqASabnmGB0ZUAWvrzeEj0O
Cc: Barry Leiba <barryleiba@computer.org>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Jun 2012 15:35:48 -0000

I think Specification required is fine.  It allows a OIDF or OASIS spec to be used as the basis for the registration withh appropriate expert review.

John B.

Sent from my iPad

On 2012-06-23, at 8:31 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

> Hi Mike, 
> 
> the point is not that other groups, like OASIS, cannot use them. They can use the extensions. 
> 
> The question is more what process and documentation is needed to allow OASIS (and others) to define their own extensions. 
> 
> So far, OASIS had not been interested for any extension (at least from what I know). The OpenID community, to which you also belong, had defined extensions (and brought some of them to the IETF) but had been quite careful themselves to ensure proper review and documentation. 
> 
> So, if you look at the most important decision points then you have: 
> 
> 1) do you want a requirement for a specification, i.e., when someone defines an extension do you want it to be documented somewhere? 
> 
> 2) do you envision a review from experts (e.g., checking whether the stuff makes any sense or conflicts with some other already available extensions)? 
> 
> http://tools.ietf.org/html/rfc5226 provides a good discussion about this topic. 
> 
> If the answer to the above-listed questions is YES then you probably at least want 'Specification Required' as a policy. 
> 
> Ciao
> Hannes
> 
> 
> On Jun 21, 2012, at 10:49 PM, Mike Jones wrote:
> 
>> I'd argue that the registration regime chosen should be flexible enough to permit OASIS or OpenID specs to use it. Otherwise, as someone else pointed, people will work around the limitation by using unregistered values - which helps no one.
>> 
>> -- Mike
>> 
>> From: Barry Leiba
>> Sent: 6/21/2012 12:31 PM
>> To: Stephen Farrell
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02
>> 
>>>> Stephen:
>>>> Yeah, I'm not sure Standards Track is needed.
>>> 
>>> On this bit: I personally don't care, except that we don't have to do it twice
>>> because someone later on thinks the opposite and wins that argument, which
>>> I'd rather not have at all  (My one-track mind:-) Doing the 4 week last call means
>>> once is enough. But I'm ok with whatever the WG want.
>> 
>> Well, it's not a 4-week LC, but a 2-week one.  Anyway, yes, I see your
>> point, and I've done that with other documents.  Better to make it
>> Standards Track for now, note in the shepherd writeup that
>> Informational is probably OK, and let the IESG decide.
>> 
>> b
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth