Re: [jose] Barry Leiba's No Objection on draft-ietf-jose-json-web-algorithms-32: (with COMMENT)

Mike Jones <> Tue, 30 September 2014 18:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E30F41A8729; Tue, 30 Sep 2014 11:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sy5R7piEbU-N; Tue, 30 Sep 2014 11:50:25 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::764]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CFD21A1A23; Tue, 30 Sep 2014 11:50:24 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 18:50:01 +0000
Received: from (2a01:111:f400:7c0c::168) by (2a01:111:e400:401e::17) with Microsoft SMTP Server (TLS) id 15.0.1039.15 via Frontend Transport; Tue, 30 Sep 2014 18:50:00 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 30 Sep 2014 18:49:59 +0000
Received: from ([]) by ([]) with mapi id 14.03.0195.002; Tue, 30 Sep 2014 18:49:21 +0000
From: Mike Jones <>
To: Barry Leiba <>
Thread-Topic: Barry Leiba's No Objection on draft-ietf-jose-json-web-algorithms-32: (with COMMENT)
Thread-Index: AQHP2M2p40kNJRGfoE2XYlz5+tEBApwYsvmQgAE1o4CAACPigA==
Date: Tue, 30 Sep 2014 18:49:20 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BAA5B74TK5EX14MBXC288r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(43784003)(377454003)(51704005)(199003)(13464003)(189002)(107046002)(81156004)(10300001)(80022003)(106466001)(54356999)(76176999)(50986999)(106116001)(31966008)(95666004)(46102003)(120916001)(85306004)(97736003)(19580405001)(68736004)(20776003)(2656002)(21056001)(99396003)(77096002)(230783001)(55846006)(87936001)(33656002)(44976005)(15202345003)(15975445006)(6806004)(76482002)(4396001)(19300405004)(16236675004)(66066001)(86362001)(71186001)(92566001)(85852003)(92726001)(64706001)(19580395003)(26826002)(104016003)(19625215002)(69596002)(84676001)(86612001)(512954002)(84326002)(110136001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB395;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB395;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0350D7A55D
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: "" <>, "" <>, The IESG <>, "" <>
Subject: Re: [jose] Barry Leiba's No Objection on draft-ietf-jose-json-web-algorithms-32: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Sep 2014 18:50:29 -0000

-----Original Message-----
From: [] On Behalf Of Barry Leiba
Sent: Tuesday, September 30, 2014 9:40 AM
To: Mike Jones
Cc: The IESG;;;
Subject: Re: Barry Leiba's No Objection on draft-ietf-jose-json-web-algorithms-32: (with COMMENT)

>> 2 (the real point). I don't understand how the two sentences relate

>> to each other.  The first sentence seems to say that the DE(s) can

>> change implementation requirements on their own.  The second says it

>> has to be done using Specification Required (which doesn't really

>> need to be said, as that's the policy for the registry anyway).


>> Which is it?  If it's Specification Required, then anyone can propose

>> a change, using a specification, and the DE(s) will review that as

>> they do any other registration request.


> The intent is for both to be required - that a specification be

> written proposing the change and the designated experts approve the

> change.  I can look into a wording change to make this clearer when

> the document is next revised.

OK, but that's just normal Specification Required.  It's fine if you want to point out that updates can also be made using the Specification Required policy... but please avoid making it look like you're setting up something special, as that might wind up being confusing.

Understood.  I'll plan on revising the description accordingly.


                                                            Thanks again,

                                                            -- Mike