Subject: [xml2rfc] xml2rfc.tools.ietf.org server error

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Aug 2017 09:35:33 -0400

I am getting a Error 500 from submitting the attached xml.

I have cut out just about all of my content that MAY be a problem (but 
don't believe so) and still get the error.

I have compared it to other xmls I have created and these successfully 
complete.

So there is something here that I am just missing and would appreciate 
someone helping me find what the cgi does not like.

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Aug 2017 10:07:54 -0400

And when I try the old converter at: http://xml2rfc.tools.ietf.org/old.html

I get the error:

Unable to Validate File

xml2rfc: error: input file "INPUT.xml" does not begin with an XML 
declaration

Don't understand this error.  I copied the header section from a draft 
that builds with no problems.

Bob

On 08/24/2017 09:35 AM, Robert Moskowitz wrote:
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Thu, 24 Aug 2017 14:10:43 +0000

A 500 error is odd. When I uploaded your xml file, I did not get any server errors. However, I did get the following error on your file:

ERROR: Unable to validate the XML document: INPUT
 <string>: Line 123: Element section content does not follow the DTD, expecting ((t | figure | texttable | iref)* , section*), got (CDATA)
 <string>: Line 132: Element references content does not follow the DTD, expecting (reference)+, got (CDATA)

	Tony

On 8/24/17, 9:36 AM, "xml2rfc on behalf of Robert Moskowitz" <[email-masked] on behalf of [email-masked]> wrote:

    

    Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Aug 2017 11:23:02 -0400

> A 500 error is odd. When I uploaded your xml file, I did not get any server errors. However, I did get the following error on your file:

And I do get error 500...

>   <string>: Line 132: Element references content does not follow the DTD, expecting (reference)+, got (CDATA)

The version I attached did have a problem there with the TBD line not in 
a text block.  I fixed that and still the problem.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Aug 2017 11:52:28 -0400

On 08/24/2017 11:18 AM, Carsten Bormann wrote:
>> On Aug 24, 2017, at 17:13, Robert Moskowitz <[email-masked]> wrote:
>>
>>
>>
>> On 08/24/2017 10:10 AM, Carsten Bormann wrote:
>>> And this one has a BOM at the start, which shouldn’t be there own UTF-8.
>> I do not understand what you are referring to.
> Sorry, too much jargon.
>
> BOM is not about the text itself, but about a weird character coding artifact.
>
> https://en.wikipedia.org/wiki/Byte_order_mark
>
> Byte order mark
>  From Wikipedia, the free encyclopedia
> The byte order mark (BOM) is a Unicode character, U+FEFF  byte order mark (BOM), whose appearance as a magic number at the start of a text stream can signal several things to a program consuming the text:[1]
> 	• What byte order, or endianness, the text stream is stored in;
> 	• The fact that the text stream is Unicode, to a high level of confidence;
> 	• Which of several Unicode encodings that text stream is encoded as.
>
> Microsoft at some point decided that UTF-8 text files are so foreign they need to be adorned by BOMs.
> Apparently, you are using some software that follows this approach.
> Most tools (including kramdown-rfc) are now immune against BOM contamination, but not all are.

I am using Geany 1.31 in Fedora 24.  Been using it for a couple years.

I am narrowing this down.  I started over from an old xml that I tested 
that works.  I pared it down, made a few changes and it works.  I 
changed ONE keyword from SSLS to PKI and it fails.  See attached with 
the SSLS in.  I tried making the change in Geany and in Leafpad.  Can't 
see any special characters, but I get the failure with a keyword of PKI????

Maybe something even more.  I change the intro and it fails....

>
> Grüße, Carsten
>
>> The first 11 lines? I have had those in for years.  I have xml drafts with exactly the same content that builds just fine.  Of course if I am behind the current best practice (nothing new there), please tell me what those lines should be.
>>
>> Bob
>>
>>
>>> Grüße, Carsten
>>>
>>>> On Aug 24, 2017, at 16:07, Robert Moskowitz <[email-masked]> wrote:
>>>>
>>>> xml2rfc: error: input file "INPUT.xml" does not begin with an XML declaration
>>>>
>>>> Don't understand this error.  I copied the header section from a draft that builds with no problems.
>>>>
>>>> Bob
>>>>
>>>>> I have cut out just about all of my content that MAY be a problem (but don't believe so) and still get the error.
>>>>>
>>>>> I have compared it to other xmls I have created and these successfully complete.
>>>>>
>>>>> So there is something here that I am just missing and would appreciate someone helping me find what the cgi does not like.
>>>>>
>>>>> Bob
>>>>>
>>>>>
>>>>>
>>>> <draft-moskowitz-ecdsa-pki-00.xml>_______________________________________________
>>>> xml2rfc mailing list
>>>> [email-masked]

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Aug 2017 12:03:39 -0400

Weird.  As I said, I started afresh, and have SOMETHING working, but I 
make a change and it fails.  For example I replace the text SSLS with 
PKI in a keyword block and it fails.  I replace the text block in the 
intro and it fails.

So it is either something wrong with my editors, or with my Firefox.  Is 
there some unix tool that will display special characters in a terminal 
window?  And my Firefox is a tad old at v54. (Fedora 24).

Doing some more digging....

Bob

On 08/24/2017 11:52 AM, HANSEN, TONY L wrote:
> I’ve tried invoking xml2rfc.tools.ietf.org in a number of ways, with multiple browsers on my Mac, and cannot reproduce a 500 error.
>
>
> Still an error in your file:
>
>   <string>: Line 135: Element references content does not follow the DTD, expecting (reference)+, got (t)
>
> 	Tony
>
> On 8/24/17, 11:23 AM, "Robert Moskowitz" <[email-masked]> wrote:
>
>      
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Aug 2017 18:04:49 +0200

Weird.

I can xml2rfc the file you attached.
It still has a BOM (Geany has an option “Document/Write Unicode BOM” that you can switch off), but that should not be a problem here.
(I tried submitting the draft both with and without a BOM, and it does take the first hurdle.
Oops, I forgot to cancel the submission…. Will try to do that now.)

Are you maybe in a less-than-pristine TLS environment?

Grüße, Carsten

> On Aug 24, 2017, at 17:52, Robert Moskowitz <[email-masked]> wrote:
> 
> 
> 
> I am narrowing this down.  I started over from an old xml that I tested that works.  I pared it down, made a few changes and it works.  I changed ONE keyword from SSLS to PKI and it fails. See attached with the SSLS in.  I tried making the change in Geany and in Leafpad.  Can't see any special characters, but I get the failure with a keyword of PKI????
> 
> <draft-moskowitz-ecdsa-pki-0-00.xml>

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Thu, 24 Aug 2017 16:09:21 +0000

I use od, hexdump, and iconv as tools to help look at strange characters.

For example, to verify that the characters at the beginning of that file were what I suspected they were, I did this:

$ iconv -f UTF-8 -t UTF-32BE /tmp/draft-moskowitz-ecdsa-pki-00.xml | hexdump | sed 3q
0000000 00 00 fe ff 00 00 00 3c 00 00 00 3f 00 00 00 78
0000010 00 00 00 6d 00 00 00 6c 00 00 00 20 00 00 00 76
0000020 00 00 00 65 00 00 00 72 00 00 00 73 00 00 00 69

	Tony

On 8/24/17, 12:04 PM, "Robert Moskowitz" <[email-masked]> wrote:

    
    
    Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Aug 2017 12:27:48 -0400

I am using the v2 parser.  How do I get this out of the file?  I tried 
vi, but it does not show these bytes

I guess I want to convert the file to no BOM.  I found a check box in 
Geany for "Write Unicode BOM"

On 08/24/2017 12:06 PM, HANSEN, TONY L wrote:
> Yeah, the file’s first few bytes are EF BB, which is a UTF-8 encoded FE FF Byte Order Mark.
>
> The OLD xml2rfc parser does not grok UTF-8 at all. The v2 parser is much more forgiving in that respect.
>
> 	Tony
>
> On 8/24/17, 11:52 AM, "xml2rfc on behalf of Robert Moskowitz" <[email-masked] on behalf of [email-masked]> wrote:
>
>      
>      
>      > https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Byte-5Forder-5Fmark&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=ZbKcre0N9Go6c_WtHXn2109jTFcmbBqWReZF6EPJxpQ&s=nhqYSknoWYfFRVb1bvKliujraUh-y7Zmd4BYW1pvy1Q&e=
>      >
>      > Byte order mark
>      >>>> And when I try the old converter at: xml2rfc.tools.ietf.org/old.html
>      >>>>
>      >>>> I get the error:
>      >>>>
>      >>>> Unable to Validate File
>      >>>>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Aug 2017 12:37:45 -0400

I turned off BOM in Geany and wrote out a version that works without 
BOM.  The dump shows:

$ iconv -f UTF-8 -t UTF-32BE draft-moskowitz-ecdsa-pki-1-00.xml | 
hexdump | sed 3q
0000000 0000 3c00 0000 3f00 0000 7800 0000 6d00
0000010 0000 6c00 0000 2000 0000 7600 0000 6500
0000020 0000 7200 0000 7300 0000 6900 0000 6f00

And this fails with the server error using http://xml2rfc.tools.ietf.org/

BTW, I have not used this tool since just before Prague.  It was not 
giving me any problems then.

Bob

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Thu, 24 Aug 2017 15:52:36 +0000

Tony

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 24 Aug 2017 21:04:57 +0200

Hi Bob,

> that builds with no problems.

So with the old converter, the problem was the byte order mark (BOM).

With the new converter, the problem was that the xml file you attached
had text directly in a <section/> element:

  <section title="Acknowledgments">
        TBD
  </section>

If I change that to:

  <section title="Acknowledgments">
    <t>
        TBD
    </t>
  </section>

the file is processed to .txt by 2.7.0, which is the latest version.

It is possible that 2.7.0 is stricter than 2.5.2 in its validation, and
that's the reason why you succeed with 2.5.2 but fail with the latest.

Best regards,

	Henrik

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Thu, 24 Aug 2017 16:06:38 +0000

Tony

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Aug 2017 15:48:01 -0400

> that's the reason why you succeed with 2.5.2 but fail with the latest.

I fat fingered that edit, taking out what I had in the Ack to figure out 
why the server error.  Previously I had:

<t>
     This work was jump started by the excellent RSA pki guide by Jamie
     Nguyen.  The openssl-user mailing list, with its many supportive
     experts, was of immense help and the openssl man pages website.
     Finally, "Professor Google" was always ready to point to answers to
     questions like: "openssl subjectAltName on the command line". And
     the Professor never seems to tire answering even trivial questions.
</t>

I just cut out too much to put in the TBD.  This text works...