Re: [auth48] AUTH48: RFC-to-be 9380 <draft-irtf-cfrg-hash-to-curve-16> for your review

[Sandy Ginoza <[e-mail]>]

Hi Chris,

Is there a tool you recommend for this?  The text wraps as expected in the text output, so a diff of the text isn’t helpful.  I'm assuming you want a diff of the outputs; we don’t have a good tool for this.  I searched for some html diff tools, but I didn’t find anything particularly helpful.  Robert Sparks mentioned one he finds less bad and will try to help us get it set up this week.  I’m looking at diff tools for PDFs, which might work.  I’m doing some testing.  I will also check in with the tools team to see when a fix might be available. 

In case I’m mistaken and you want to see diffs of the code, they are available here:

https://www.rfc-editor.org/authors/rfc9380_artwork_diff.html
https://www.rfc-editor.org/authors/rfc9380_artwork_zwsp_diff.html

These diffs compare the original html with the sample files mentioned below: rfc9380_artwork.html and rfc9380_artwork_zwsp.html

Both of the files use <artwork> and zwsp, but rfc9380_artwork uses zwsp sparingly and rfc9380_artwork_zwsp uses it more liberally.  

I’m attaching a few screenshots to give you an idea in the meantime. 

Thanks,
Sandy 


Example from rfc9380.pdf (the original output) that shows the text running off the page:






From rfc9380_artwork.pdf - uses zwsp p: and <artwork> for A' and B’ 







From rfc9380_artwork_zwsp.pdf - uses zwsp more liberally; uses <artwork> in the appendixes.





> On Jul 22, 2023, at 5:59 AM, Christopher Wood <[e-mail]> wrote:
> 
> Friendly bump!
> 
> Sent from my iPhone
> 
>> On Jul 18, 2023, at 2:51 PM, Christopher Wood <[e-mail]> wrote:
>> 
>> Hi Sandy,
>> 
>> Can you please show us a diff between all versions? It’s hard to assess otherwise.
>> 
>> Thanks,
>> Chris 
>> 
>> Sent from my iPhone
>> 
>>> On Jul 18, 2023, at 2:53 PM, Stanislav V. Smyshlyaev <[e-mail]> wrote:
>>> 
>>> 
>>> Hi Sandy,
>>> 
>>> Please feel free to use [e-mail] to contact Nick. 
>>> 
>>> Kind regards,
>>> Stanislav 
>>> 
>>> On Tue, 18 Jul 2023 at 21:47, Sandy Ginoza <[e-mail]> wrote:
>>> Hi again,
>>> 
>>> We are getting a “message wasn’t delivered” notice for Nick Sullivan <[e-mail]>.  Please let us know if you have an alternative address we can use to contact Nick.
>>> 
>>> Thanks,
>>> Sandy 
>>> 
>>> 
>>> > On Jul 18, 2023, at 11:34 AM, Sandy Ginoza <[e-mail]> wrote:
>>> > 
>>> > Greetings all,
>>> > 
>>> > IETF is approaching quickly - there is still a chance to publish before it starts.  Do you have a preference or input regarding the options below?  Another option would be to ask the tools team to prioritize a fix, but that likely will not happen in the next few days.  
>>> > 
>>> > Please let us know if you have any questions. 
>>> > 
>>> > Thanks,
>>> > Sandy 
>>> > 
>>> > 
>>> > 
>>> >> On Jul 14, 2023, at 12:33 PM, Sandy Ginoza <[e-mail]> wrote:
>>> >> 
>>> >> Hi Christopher, Authors,
>>> >> 
>>> >> I’ve decided to part ways with GitHub for now, as we’ll need to focus on the outputs to review these issues.  xml2rfc is not wrapping lines in the HTML and PDF properly (lines wrap okay in text).  Many of the lines run off the page, and information is lost.  See Sections 8.3 - 8.5, 8.7, and 8.8, and all of Appendix E.1 in the PDF (more prominent in the PDF).  We have added some notes to the existing GitHub issue 687.  
>>> >> 
>>> >> The files are available here:
>>> >>   https://www.rfc-editor.org/authors/rfc9380.xml
>>> >>   https://www.rfc-editor.org/authors/rfc9380.txt
>>> >>   https://www.rfc-editor.org/authors/rfc9380.html
>>> >>   https://www.rfc-editor.org/authors/rfc9380.pdf
>>> >> 
>>> >> 
>>> >> A workaround is to use <artwork>.  I have made test files so you can see what the output looks like using <artwork>.  I used <artwork> consistently for the same level of bullets/information (i.e., I used <artwork> for the same level of bullets even if there was no issue with the line lengths).  In an attempt to have the bullets have a similar look across sections, I also used &#8203; (zwsp) in Sections 8.8.1 (for bullet p:) and 8.8.2 (for bullet h_eff:).  
>>> >> 
>>> >> The test files are available here:
>>> >>  https://www.rfc-editor.org/authors/rfc9380_artwork.xml
>>> >>   https://www.rfc-editor.org/authors/rfc9380_artwork.txt
>>> >>   https://www.rfc-editor.org/authors/rfc9380_artwork.html
>>> >>   https://www.rfc-editor.org/authors/rfc9380_artwork.pdf
>>> >> 
>>> >> 
>>> >> A third version, which uses zwsp to get line breaks throughout section 8 and uses <arwtork> in Appendix E is also available.  I’m having trouble getting the second break in the "B =“ bullet in Section 8.4 - I’m still working on this.  The other breaks seem to be working as expected.  
>>> >> 
>>> >> The files associated with the third version are available here:
>>> >>  https://www.rfc-editor.org/authors/rfc9380_artwork_zwsp.xml
>>> >>   https://www.rfc-editor.org/authors/rfc9380_artwork_zwsp.txt
>>> >>   https://www.rfc-editor.org/authors/rfc9380_artwork_zwsp.html
>>> >>   https://www.rfc-editor.org/authors/rfc9380_artwork_zwsp.pdf
>>> >> 
>>> >> 
>>> >> Note: a problem with using &#8203; (zwsp) is the that copy & paste may pick up the invisible characters.  We could also use <br/>, but that will pick up render as a hard break.  
>>> >> 
>>> >> 
>>> >> Please review the files and let us know what you think of these options.  Also, please let us know if you have an alternative that we should try.  
>>> >> 
>>> >> Thanks,
>>> >> Sandy 
>>> >> 
>>> >> 
>>> >> 
>>> >> 
>>> >> 
>>> >> 
>>> >> 
>>> >> 
>>> >>> On Jul 13, 2023, at 7:03 AM, Christopher Wood <[e-mail]> wrote:
>>> >>> 
>>> >>> I don’t think any of the authors have strong opinions on artwork vs sourcecode. Whatever renders best is the right answer!
>>> >>> 
>>> >>>> On Jul 13, 2023, at 9:52 AM, Sandy Ginoza <[e-mail]> wrote:
>>> >>>> 
>>> >>>> Hi Christopher,
>>> >>>> 
>>> >>>> We’re almost there!  We ran into an issue while reviewing the output files.  I’ll be adding a PR for the XML file today to see if the workaround is acceptable.  I’ve also been reviewing the <artwork> vs <sourcecode> and wonder if the equations should be marked as <artwork> instead - will add a PR for that as well. 
>>> >>>> 
>>> >>>> Thanks!
>>> >>>> Sandy 
>>> >>>> 
>>> >>>>> On Jul 13, 2023, at 4:53 AM, Christopher Wood <[e-mail]> wrote:
>>> >>>>> 
>>> >>>>> Hi Sandy,
>>> >>>>> 
>>> >>>>> Thanks again for all your work on this (enormous) document! I think all issues should now be resolved. Please let us know if you need anything else from the editors at this point.
>>> >>>>> 
>>> >>>>> Best,
>>> >>>>> Chris
>>> >>>>> 
>>> >>>>>>> On Jul 3, 2023, at 4:26 PM, Sandy Ginoza <[e-mail]> wrote:
>>> >>>>>> 
>>> >>>>>> Greetings all,
>>> >>>>>> 
>>> >>>>>> We are seemingly close to finalizing the content of this document.  Please review the remaining open issue #8 and let us know if any updates are needed.  Once this item has been resolved, we will convert the file to XML and post the output for your review. 
>>> >>>>>> 
>>> >>>>>> Thank you,
>>> >>>>>> RFC Editor/sg
>>> >>>>>> 
>>> >>>>>> 
>>> >>>>>> 
>>> >>>>>>> On Jun 26, 2023, at 11:28 PM, Sandy Ginoza <[e-mail]> wrote:
>>> >>>>>>> 
>>> >>>>>>> Hi Chris,
>>> >>>>>>> 
>>> >>>>>>> There are a couple of remaining open items; see issue #8 and the discussion for PR #57.  
>>> >>>>>>> 
>>> >>>>>>> Assuming none of the authors object to any of the updates, we will convert the document to XML once these items have been addressed.  We will then post the output files so each author can review and approve the RFC for publication.  
>>> >>>>>>> 
>>> >>>>>>> Please let us know if you have any questions or concerns.  
>>> >>>>>>> 
>>> >>>>>>> Thanks,
>>> >>>>>>> Sandy 
>>> >>>>>>> 
>>> >>>>>>> 
>>> >>>>>>>> On Jun 26, 2023, at 7:51 AM, Christopher Wood <[e-mail]> wrote:
>>> >>>>>>>> 
>>> >>>>>>>> Hi folks,
>>> >>>>>>>> 
>>> >>>>>>>> I went through and approved all open PRs. Is there anything left to resolve at this point?
>>> >>>>>>>> 
>>> >>>>>>>> Thanks,
>>> >>>>>>>> Chris
>>> >>>>>>>> 
>>> >>>>>>>>> On Jun 20, 2023, at 3:05 PM, Lynne Bartholomew <[e-mail]> wrote:
>>> >>>>>>>>> 
>>> >>>>>>>>> Hi, Armando and Riad.
>>> >>>>>>>>> 
>>> >>>>>>>>> We have updated the text listed below as suggested (https://github.com/rfc-editor/draft-irtf-cfrg-hash-to-curve/pull/64).
>>> >>>>>>>>> 
>>> >>>>>>>>> Thank you!
>>> >>>>>>>>> 
>>> >>>>>>>>> RFC Editor/lb
>>> >>>>>>>>> 
>>> >>>>>>>>>> From: "Riad S. Wahby" <[e-mail]>
>>> >>>>>>>>>> Subject: Re: [rfc-editor/draft-irtf-cfrg-hash-to-curve] Changes-for-issue-46 (PR #63)
>>> >>>>>>>>>> Date: June 19, 2023 at 3:01:49 PM PDT
>>> >>>>>>>>>> To: rfc-editor/draft-irtf-cfrg-hash-to-curve <[e-mail]>
>>> >>>>>>>>>> Cc: lbartholomew-rpc <[e-mail]>, State change <[e-mail]>
>>> >>>>>>>>>> Reply-To: rfc-editor/draft-irtf-cfrg-hash-to-curve <[e-mail]>
>>> >>>>>>>>>> 
>>> >>>>>>>>>> 
>>> >>>>>>>>>> @kwantam commented on this pull request.In draft-irtf-cfrg-hash-to-curve.md:
>>> >>>>>>>>>>> @@ -3034,7 +3034,7 @@ directly from the indifferentiability of H.
>>> >>>>>>>>>> For case (3), i.e., for H a Merkle-Damgaard hash function, indifferentiability
>>> >>>>>>>>>> follows from {{CDMP05}}, Theorem 3.5.
>>> >>>>>>>>>> In particular, expand\_message\_xmd computes b\_0 by prefixing the message
>>> >>>>>>>>>> -with one block of 0-bytes plus auxiliary information (length, counter, and DST).
>>> >>>>>>>>>> +with one block of zero bytes plus auxiliary information (length, counter, and DST).
>>> >>>>>>>>>> 
>>> >>>>>>>>>> Agreed that it would be good to avoid the garden path, "a block of bytes with length zero".
>>> >>>>>>>>> 
>>> >>>>>>>>> 
>>> >>>>>>>>> 
>>> >>>>>>>>>> From: Armando Faz <[e-mail]>
>>> >>>>>>>>>> Subject: Re: [rfc-editor/draft-irtf-cfrg-hash-to-curve] Changes-for-issue-46 (PR #63)
>>> >>>>>>>>>> Date: June 19, 2023 at 2:08:11 PM PDT
>>> >>>>>>>>>> To: rfc-editor/draft-irtf-cfrg-hash-to-curve <[e-mail]>
>>> >>>>>>>>>> Cc: lbartholomew-rpc <[e-mail]>, State change <[e-mail]>
>>> >>>>>>>>>> Reply-To: rfc-editor/draft-irtf-cfrg-hash-to-curve <[e-mail]>
>>> >>>>>>>>>> 
>>> >>>>>>>>>> 
>>> >>>>>>>>>> @armfazh commented on this pull request.In draft-irtf-cfrg-hash-to-curve.md:
>>> >>>>>>>>>>> @@ -3034,7 +3034,7 @@ directly from the indifferentiability of H.
>>> >>>>>>>>>> For case (3), i.e., for H a Merkle-Damgaard hash function, indifferentiability
>>> >>>>>>>>>> follows from {{CDMP05}}, Theorem 3.5.
>>> >>>>>>>>>> In particular, expand\_message\_xmd computes b\_0 by prefixing the message
>>> >>>>>>>>>> -with one block of 0-bytes plus auxiliary information (length, counter, and DST).
>>> >>>>>>>>>> +with one block of zero bytes plus auxiliary information (length, counter, and DST).
>>> >>>>>>>>>> 
>>> >>>>>>>>>> ⬇️ Suggested change-with one block of zero bytes plus auxiliary information (length, counter, and DST).
>>> >>>>>>>>>> +with one block of zeros plus auxiliary information (length, counter, and DST).
>>> >>>>>>>>>> 
>>> >>>>>>>>>> Not sure, if the sentence can be interpreted as: "a block that has a length of zero bytes", instead of a block with all zeros.
>>> >>>>>>>> 
>>> >>>>>>> 
>>> >>>>>> 
>>> >>>>> 
>>> >>>> 
>>> >>> 
>>> >> 
>>> >