Re: [jose] [Editorial Errata Reported] RFC7515 (4554)

John Bradley <ve7jtb@ve7jtb.com> Tue, 08 December 2015 16:14 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32311B2F9B for <jose@ietfa.amsl.com>; Tue, 8 Dec 2015 08:14:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 1ThXSXzLdclp for <jose@ietfa.amsl.com>; Tue, 8 Dec 2015 08:14:48 -0800 (PST)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 834601B2ECD for <jose@ietf.org>; Tue, 8 Dec 2015 08:14:48 -0800 (PST)
Received: by qgea14 with SMTP id a14so23130949qge.0 for <jose@ietf.org>; Tue, 08 Dec 2015 08:14:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+J4qW4OlS2WeXvP1sgZjt2oHgigjmJOxPnX95NkOJo0=; b=QfBMPuY8mcnqic198jffnAQ0UfYyOZmDcN7hhZBLzOfZjArLFAt1mHxR4VfnaXGoDl HtD2kOIKl05FcxGjV//pigQf5h2TK4aK7AdVutZKu9VvTQ2Iy/+w9AhKTcWYw5/UTP/w KxZ8C9pOgt8br/QjS2TDBuFoWi1T2Uoldmqm57jZuT8Ja3GCXadMXm9jMANxbFvLUcZk PCqswsvEUG9xZ9cJ0dTpojPx4/6ho6nxBuSTRC0v9XHsQZWF+9FNZdZ3IHNHMOsayDGB CbSlB5nvzuOrZH/Rg8PkrxAzU3wVn2f6jidFkYK2+TlnqJ1p8jD0GDhFOnxOblfysMGY DgiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=+J4qW4OlS2WeXvP1sgZjt2oHgigjmJOxPnX95NkOJo0=; b=lxq2RFF3bYhXSkne84sU3IJ/xLd0qdZoREEDgKluMR3oVhnEjIGcP+5v1XS8ysh6SH ae8WbnCcO3z4H7lmkHfTzRT2GQn+/ZaRMpAfH3KHRIbGLI0eXTulGW88xUTP+xDQgqJ7 a5kHCR/ZuUbyERM/b//rRDvAoRvmHqnw2+iD0d/d10jW4166rcNNd84yVyzoB49Wf70v Vdn5b72grFB/AomUi1EQ24DOft7kGpNLFUTD3C1EUihvpnanQ5ngyrxUiGUya5LEwvCK AZbIpZHSh92WniEJN33DqJ3ySAW0Vjxctk1xXPNq7s7AkUAOJAGh4hEl20rWnFA9tnm/ N4QQ==
X-Gm-Message-State: ALoCoQkXVeKh2qVtIPmjKhv+JprQKsulLiRBLEPm5DmLJ+ZghmN1UZdoj3KSOoV4D1eWdhXWNKCyRl3E0QKo6f6YYdv//sVpqw==
X-Received: by 10.140.152.150 with SMTP id 144mr6281046qhy.8.1449591267854; Tue, 08 Dec 2015 08:14:27 -0800 (PST)
Received: from [192.168.1.216] ([191.115.1.95]) by smtp.gmail.com with ESMTPSA id n74sm1792023qgd.25.2015.12.08.08.14.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Dec 2015 08:14:26 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <BY2PR03MB44221CB791F8F7F6BFEBDCEF5080@BY2PR03MB442.namprd03.prod.outlook.com>
Date: Tue, 8 Dec 2015 13:14:19 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C496D6C-2D77-4826-B748-963A6E79B2DB@ve7jtb.com>
References: <20151204151726.F0B12180006@rfc-editor.org> <018b01d1316f$ea11c8e0$be355aa0$@augustcellars.com> <EC8849D9-1802-4406-8F30-E5DAD541593E@ve7jtb.com> <5912D7C1-CC80-48ED-8B87-60E1D88391B8@gmail.com> <2DE3D87D-4F05-4D1F-9AEB-E68A9A43DC0C@ve7jtb.com> <BY2PR03MB44221CB791F8F7F6BFEBDCEF5080@BY2PR03MB442.namprd03.prod.outlook.com>
To: Michael Jones <Michael.Jones@microsoft.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/6A3hJX_6JjQc4DthaW6EbTK7HK4>
Cc: "simon@bastli.ethz.ch" <simon@bastli.ethz.ch>, Karen Odonoghue <odonoghue@isoc.org>, Jim Schaad <ietf@augustcellars.com>, RFC Errata System <rfc-editor@rfc-editor.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "jose@ietf.org" <jose@ietf.org>, Nat Sakimura <n-sakimura@nri.co.jp>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [jose] [Editorial Errata Reported] RFC7515 (4554)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2015 16:14:54 -0000

Rfcmarkup will be dropped for new RFC.   I some historical drafts were submitted with the XML (like this one).   While the RFC editor could start generating the HTML from those directly, I don’t know if that is the plan.

In any case the XML may not be optimal as we have had to compromise that in some cases to get the TXT version to play nice with Rfcmarkup.

Going forward life should be better.

I suspect that only so much can be done with Rfcmarkup, and it probably should be a secondary priority to moving ahead with the other RFC changes.

John B.


> On Dec 8, 2015, at 1:04 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
> 
> Agreed.  I'll note that the HTML produced by xml2rfc directly from the XML source doesn't have this problem.  Unfortunately, the RFCmarkup tool that's used to produce the HTML that's posted based on the .txt version has heuristics that are wrong.  Does anyone know how Simon can instead file a bug against RFCmarkup?  (And to people know whether the plan is to drop using RFCmarkup once the RFC evolution changes roll out?)
> 
> 				-- Mike
> 
> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
> Sent: Tuesday, December 8, 2015 6:13 AM
> To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
> Cc: Jim Schaad <ietf@augustcellars.com>om>; RFC Errata System <rfc-editor@rfc-editor.org>rg>; Mike Jones <Michael.Jones@microsoft.com>om>; Nat Sakimura <n-sakimura@nri.co.jp>jp>; Stephen Farrell <stephen.farrell@cs.tcd.ie>ie>; Karen Odonoghue <odonoghue@isoc.org>rg>; simon@bastli.ethz.ch; jose@ietf.org
> Subject: Re: [Editorial Errata Reported] RFC7515 (4554)
> 
> +1
> 
>> On Dec 8, 2015, at 10:58 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
>> 
>> Thanks for your advice on this.
>> 
>> How about I mark it as 'editorial' and hold for document update, then add a note that says the normative section is correct and this is just an HTML markup from txt issue?
>> 
>> Thanks,
>> Kathleen
>> 
>> Sent from my iPhone
>> 
>>> On Dec 8, 2015, at 8:47 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>> 
>>> I agree, Rfcmarkup strikes again:)
>>> 
>>> The canonical version is txt and that is correct.
>>> 
>>> The link is probably correct in the XML version.  
>>> One day we will publish RFC from the XML and can get rid of these stupid HTML markup from TXT issues.
>>> 
>>> Worth keeping a note of if we do do an errata and can publish in XML.
>>> 
>>> Until that time nothing to do for it.
>>> 
>>> John B.
>>> 
>>>> On Dec 8, 2015, at 1:21 AM, Jim Schaad <ietf@augustcellars.com> wrote:
>>>> 
>>>> 
>>>> My inclination is to say that this is not a valid Errata.  The 
>>>> complaint is really against the tools and not the document as the 
>>>> complaint is dealing with the line, which is not part of the RFC, 
>>>> rather than with either technical or editorial content of the document.
>>>> 
>>>> I believe that the original text is sufficiently clear as to which 
>>>> section is being referred to for a human.  But it would not be clear 
>>>> to a tool.  The suggested change may or may not fix that for the 
>>>> tool and a better approach is probably to start using the xml source 
>>>> for the generation of the html page rather than to fix up the text version.
>>>> 
>>>> Jim
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
>>>>> Sent: Friday, December 04, 2015 7:17 AM
>>>>> To: mbj@microsoft.com; ve7jtb@ve7jtb.com; n-sakimura@nri.co.jp; 
>>>>> stephen.farrell@cs.tcd.ie; Kathleen.Moriarty.ietf@gmail.com; 
>>>>> odonoghue@isoc.org; ietf@augustcellars.com
>>>>> Cc: simon@bastli.ethz.ch; jose@ietf.org; rfc-editor@rfc-editor.org
>>>>> Subject: [Editorial Errata Reported] RFC7515 (4554)
>>>>> 
>>>>> The following errata report has been submitted for RFC7515, "JSON 
>>>>> Web Signature (JWS)".
>>>>> 
>>>>> --------------------------------------
>>>>> You may review the report below and at:
>>>>> http://www.rfc-editor.org/errata_search.php?rfc=7515&eid=4554
>>>>> 
>>>>> --------------------------------------
>>>>> Type: Editorial
>>>>> Reported by: Simon <simon@bastli.ethz.ch>
>>>>> 
>>>>> Section: 2
>>>>> 
>>>>> Original Text
>>>>> -------------
>>>>> Base64url Encoding
>>>>>   Base64 encoding using the URL- and filename-safe character set
>>>>>   defined in Section 5 of RFC 4648 [RFC4648], with all trailing
>>>> \\'=\\'
>>>>>   characters omitted (as permitted by Section 3.2) and without the
>>>>>   inclusion of any line breaks, whitespace, or other additional
>>>>>   characters.  Note that the base64url encoding of the empty octet
>>>>>   sequence is the empty string.  (See Appendix C for notes on
>>>>>   implementing base64url encoding without padding.)
>>>>> 
>>>>> Corrected Text
>>>>> --------------
>>>>> Base64url Encoding
>>>>>   Base64 encoding using the URL- and filename-safe character set
>>>>>   defined in Section 5 of RFC 4648 [RFC4648], with all trailing
>>>> \\'=\\'
>>>>>   characters omitted (as permitted by Section 3.2 of RFC 4648) and
>>>>>   without the inclusion of any line breaks, whitespace, or other
>>>>>   additional characters.  Note that the base64url encoding of the
>>>>>   empty octet sequence is the empty string.  (See Appendix C for
>>>>>   notes on implementing base64url encoding without padding.)
>>>>> 
>>>>> Notes
>>>>> -----
>>>>> in the html version https://tools.ietf.org/html/rfc7515 the link on
>>>> \\"Section
>>>>> 3.2\\" goes to Section 3.2 of RFC7515 but it should go to Section 
>>>>> 3.2 of RFC4648. Not sure how the automatic link generation is made 
>>>>> (or is it
>>>> manual?),
>>>>> so i would propose explicitly saying \\"Section 3.2 of RFC 4648\\".
>>>>> 
>>>>> Instructions:
>>>>> -------------
>>>>> This erratum is currently posted as "Reported". If necessary, 
>>>>> please use
>>>> "Reply
>>>>> All" to discuss whether it should be verified or rejected. When a 
>>>>> decision
>>>> is
>>>>> reached, the verifying party (IESG) can log in to change the status 
>>>>> and
>>>> edit the
>>>>> report, if necessary.
>>>>> 
>>>>> --------------------------------------
>>>>> RFC7515 (draft-ietf-jose-json-web-signature-41)
>>>>> --------------------------------------
>>>>> Title               : JSON Web Signature (JWS)
>>>>> Publication Date    : May 2015
>>>>> Author(s)           : M. Jones, J. Bradley, N. Sakimura
>>>>> Category            : PROPOSED STANDARD
>>>>> Source              : Javascript Object Signing and Encryption
>>>>> Area                : Security
>>>>> Stream              : IETF
>>>>> Verifying Party     : IESG
>>> 
>