Subject: [xml2rfc] Help with a special character in formulas

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Dec 2020 10:34:16 -0500

I am copying some formulas from the cryptographic function, Xoodyak.

https://eprint.iacr.org/2018/767.pdf

Specifically I am having problems with (page 22):

x3 ◦ x2 ◦ x1

xml2rfc renders this as:

x3 &#9702; x2 &#9702; x1

How can I get the proper special character into my draft?  Or, if anyone 
has experience with this sort of a formula, what else might I use that 
works in xml2rfc?

thanks

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Dec 2020 17:32:48 +0100

> has experience with this sort of a formula, what else might I use that

Does the HTML output work? Where do you have the formula? In a regular
paragraph? AFAIU, xml2rfc will not allow this, but putting this into
<artwork> might get you around that restriction.

Best regards, Julian

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Dec 2020 13:14:22 -0500

> <artwork> might get you around that restriction.

same formatting problem in HTML output from xml2rfc.tools.ietf.org

It is in a regular paragraph.

<t>
     Xoodyak can also naturally implement a Dec function and process a
     sequence of strings.  Here the output depends on the sequence as
     such and not just on the concatenation of the different strings. To
     compute a n-byte digest over the sequence x3 ◦ x2 ◦ x1
     {XHASH(n, x3,x2,x1)}, one does:
</t>

When I stuff it into an artwork with CDATA for testing:

<artwork name="" type="" align="left" alt="">
<![CDATA[
x3 ◦ x2 ◦ x1
      Cyclist(ε,ε,ε)
      Absorb(x1)
      Absorb(x2)
      Absorb(x3)
      Squeeze(n)
]]>
</artwork>

It works right.

Grumble.  Now I have to figure out a reasonable format maybe stuff CDATA 
into a paragraph?

<t>
     Xoodyak can also naturally implement a Dec function and process a
     sequence of strings.  Here the output depends on the sequence as
     such and not just on the concatenation of the different strings. To
     compute a n-byte digest over the sequence
     <![CDATA[x3 ◦ x2 ◦ x1 ]]> {XHASH(n, x3,x2,x1)}, one does:
</t>

Produces the same gobbled text as without CDATA.

<t>
     Xoodyak can also naturally implement a Dec function and process a
     sequence of strings.  Here the output depends on the sequence as
     such and not just on the concatenation of the different strings. To
     compute a n-byte digest over the sequence
     <artwork><![CDATA[x3 ◦ x2 ◦ x1 ]]></artwork> {XHASH(n, x3,x2,x1)}, 
one does:
</t>

And artwork cannot go into a paragraph.

Now what to do???

thanks

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Dec 2020 21:08:46 +0100

> Now what to do???

As always: Cheat.

In kramdown-rfc, it would be

  To compute an n-byte digest over the sequence {{{x3 ◦ x2 ◦ x1}{}}}, one does:

Currently, kramdown-rfc turns this into this little exploit:

  <t>To compute an n-byte digest over the sequence <contact fullname="x3 ◦ x2 ◦ x1" asciiFullname=""/>, one does:</t>

I’m sure the way this is expressed in XML will change, but I’ll try to keep the kramdown-rfc input stable.

(Alternative keyboarding:

To compute an n-byte digest over the sequence $$x3 ◦ x2 ◦ x1$$, one does:
➔
   To compute an n-byte digest over the sequence x3 ◦ x2 ◦ x1, one does:

Or maybe you actually mean:

To compute an n-byte digest over the sequence $$x3 \circ x2 \circ x1$$, one does:
➔
   To compute an n-byte digest over the sequence x3 ∘ x2 ∘ x1, one does:
)

Grüße, Carsten

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Dec 2020 17:10:51 -0500

Carsten,

>    <t>To compute an n-byte digest over the sequence <contact fullname="x3 ◦ x2 ◦ x1" asciiFullname=""/>, one does:</t>

this works!

>     To compute an n-byte digest over the sequence x3 ∘ x2 ∘ x1, one does:

these don't  :(

I also looked in the html special characters &...;  and did not see the 
circle.  Degree was closest.

But thank you.  I have it fixed for now until/if they change the XML as 
you mention.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Dec 2020 00:27:39 +0100

Am 24.12.2020 um 23:10 schrieb Robert Moskowitz:
>>    <t>To compute an n-byte digest over the sequence <contact
>> fullname="x3 ◦ x2 ◦ x1" asciiFullname=""/>, one does:</t>
>
> this works!

Please don't.

This is a defect in xml2rfc (IMHO), and should be fixed. Raise tickets.

Best regards, Julian

---

From: "John Levine" <[email-masked]>
Date: 24 Dec 2020 18:54:54 -0500

>This is a defect in xml2rfc (IMHO), and should be fixed. Raise tickets.

Agreed. We already have tickets about the appropriate use of
<contact>, and I agree that the rules for where you can use non-ASCII
characters in text need to be updated.

R's,
John

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Dec 2020 19:15:03 -0500

Please point me to how/where to submit a ticket for this?

On 12/24/20 6:54 PM, John Levine wrote:
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Dec 2020 19:53:04 -0500

> On 2020-12-24, at 19:14, Robert Moskowitz <[email-masked]> wrote:

Why not simply turn your equation into a one-line artwork, with the text 
split into paragraphs before and after? That is fully supported now, and 
for the use here it seems entirely reasonable even if it isn't exactly 
the same.

	Thanks,
	Paul

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Dec 2020 21:32:41 -0500

On 12/24/20 7:53 PM, Paul Kyzivat wrote:
> Why not simply turn your equation into a one-line artwork, with the 
> text split into paragraphs before and after? That is fully supported 
> now, and for the use here it seems entirely reasonable even if it 
> isn't exactly the same.

Working on that...

Still should submit a ticket.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Dec 2020 14:14:34 +0100

Am 25.12.2020 um 01:15 schrieb Robert Moskowitz:
> ...

For the format specs (both issues and enhancement requests), there's
<https://github.com/rfc-format>.

For the actual implementation, there's
<https://trac.tools.ietf.org/tools/xml2rfc/trac/report/1>.

Best regards, Julian

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Dec 2020 10:08:18 -0500

> now, and for the use here it seems entirely reasonable even if it 

Not sooo simple.  Looks a little dorky:

    Xoodyak can also naturally implement a Dec function and process a
    sequence of strings.  Here the output depends on the sequence as such
    and not just on the concatenation of the different strings.  To
    compute a n-byte digest over the sequence

         x3 ◦ x2 ◦ x1

         Cyclist(ε,ε,ε)
         Absorb(x1)
         Absorb(x2)
         Absorb(x3)
         Squeeze(n)

further thought needed.  Or a proper support of special characters in 
paragraphs.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 26 Dec 2020 06:29:50 +0100

> Grumble.  Now I have to figure out a reasonable format maybe stuff CDATA

CDATA is an escaping mechanism. Use of it doesn't affect what can go where.

Best regards, Julian