Subject: [xml2rfc] <country> in v3

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Jan 2020 08:58:40 +1300

For some reason, it appears that <country>P.R. China</country> causes problems in v3, but <country>China</country> is OK.

The problem I see is that <country> is simply ignored, and <code> is also ignored,
when the "P.R" was included. 

I think there is a similar issue with commas included in <street>.

For both, RFC7991 says "Content model: only text content." I don't see that this
should exclude punctuation marks.

Regards
   Brian Carpenter

---

From: Julian Reschke <[email-masked]>
Date: Fri, 3 Jan 2020 08:36:40 +0100

> should exclude punctuation marks.

xml2rfc wants an "ISO short name" here (see
<https://www.iso.org/obp/ui#search> for a lookup UI).

Another issue here is that it has unintended consequences with respect
to Taiwanese users, as they would have to use "Taiwan (Province of China)".

IMHO the changes with respect to postal formatting (see
<https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-10#section-3.1.13>)
are overly complex and should be backed out. And yes, I'm saying this
after having it reverse engineered and partly implemented in my XSLT code.

Best regards, Julian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 Jan 2020 08:43:06 +1300

> <https://www.iso.org/obp/ui#search> for a lookup UI).

I really hope it doesn't "want" an ISO code, since RFC7991 says nothing about
that. It's very convenient that they are available, though.

It takes some cheating to produce:

Dilbert Engineer
Pointy Haired Products LLC
42 Deepinit Street
Mudgrad 7991
Elbonia
Email: [email-masked]

> to Taiwanese users, as they would have to use "Taiwan (Province of China)".

That's a serious problem. But they can simply omit <country>.

> after having it reverse engineered and partly implemented in my XSLT code.

Fortunately <street> isn't picky, so one can do anything:

    <author fullname="Dilbert Engineer" initials="D." surname="Engineer">
      <organization abbrev="Pointy LLC"/>
      <address>
        <postal>
          <street>Pointy Haired Products LLC</street>
          <street>42 Deepinit Street</street>
          <street>Mudgrad 7991</street>
          <street>Elbonia</street>
          <country/>
        </postal>
        <email>[email-masked]</email>
      </address>
    </author>

Regards
   Brian

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 3 Jan 2020 21:24:11 +0100

Hi Brian,

> that. It's very convenient that they are available, though.

xml2rfc recognizes the ISO 3166 2-letter, 3-letter, official, and common names
of countries.  In cases where a name or abbreviation in common use isn't
recognized, I'm happy to add extra entries.  I've already done so for 'UK',
and will do so for "P.R. China" in the next release.

> That's a serious problem. But they can simply omit <country>.

I'll see what I can do to address this, too, in the next release.

Best regards,

	Henrik

> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 3 Jan 2020 21:36:12 +0100

Follow-up:

> and will do so for "P.R. China" in the next release.

Added in my code.

>> That's a serious problem. But they can simply omit <country>.

I cannot reproduce the problem above.  Using <country>Taiwan</country>
works fine when I test it with xml2rfc 2.37.0.

Regards,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Sat, 4 Jan 2020 08:23:48 +0100

On 03.01.2020 21:24, Henrik Levkowetz wrote:
> ...

If this is the case, it should be properly documented (otherwise we
don't have a spec but just a single implementation that has some
heuristics that affect the generated RFC text). In particular, extra
entries would need to be documented.

Looking at the Taiwan case:

>       <author surname="Taiwan" initials="T." fullname="Tai Taiwan">
>          <address>
>             <postal>
>                <extaddr>EXTADDR-1</extaddr>
>                <extaddr>EXTADDR-2</extaddr>
>                <extaddr>EXTADDR-3</extaddr>
>                <street>STREET-1</street>
>                <street>STREET-2</street>
>                <street>STREET-3</street>
>                <pobox>POBOX</pobox>
>                <sortingcode>SORTINGCODE</sortingcode>
>                <code>CODE</code>
>                <cityarea>CITYAREA</cityarea>
>                <city>CITY</city>
>                <region>REGION</region>
>                <country>Taiwan</country>
>             </postal>
>          </address>
>       </author>

produces

>    Tai Taiwan
>    EXTADDR-1
>    EXTADDR-2
>    EXTADDR-3
>    STREET-1
>    STREET-2
>    STREET-3
>    POBOX
>    CITY, REGION CODE
>    Taiwan

So it falls back to US address formatting, but doesn't generate any warning.

Now,

>       <author surname="Taiwan" initials="T." fullname="Tai Taiwan2">
>          <address>
>             <postal>
>                <extaddr>EXTADDR-1</extaddr>
>                <extaddr>EXTADDR-2</extaddr>
>                <extaddr>EXTADDR-3</extaddr>
>                <street>STREET-1</street>
>                <street>STREET-2</street>
>                <street>STREET-3</street>
>                <pobox>POBOX</pobox>
>                <sortingcode>SORTINGCODE</sortingcode>
>                <code>CODE</code>
>                <cityarea>CITYAREA</cityarea>
>                <city>CITY</city>
>                <region>REGION</region>
>                <country>Taiwan (Province of China)</country>
>             </postal>
>          </address>
>       </author>

yields:

>    Tai Taiwan
>    EXTADDR-1
>    EXTADDR-2
>    EXTADDR-3
>    STREET-1
>    STREET-2
>    STREET-3
>    POBOX
>    CITY

So the country name is simply dropped, again without warning.

(I would open a ticket, but it seems that tickets opened by me are
ignored anyway)

Using TW or TWN as country names gets me:

>    Tai Taiwan
>    EXTADDR-1
>    EXTADDR-2
>    EXTADDR-3
>    STREET-1
>    STREET-2
>    STREET-3
>    POBOX
>    CITY, REGION CODE
>    Taiwan, Province of China

which indicates that the expected short name is "Taiwan, Province of
China", not "Taiwan (Province of China)" (which is what I get from
<https://www.iso.org/obp/ui#search> which agrees with
<https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes>").

I continue to believe that we are wasting time and energy here. There's
a reason why RFC 7991 has "postalLine"; it allows authors to format
their postal address exactly the way they want it; and that should be
sufficient. We should just get rid of any requirements made by the HTML
spec with respect to HCARD annotations and be done with it.

Best regards, Julian