Re: [xml2rfc] <country> in v3

[Julian Reschke <[e-mail]>]

On 03.01.2020 21:24, Henrik Levkowetz wrote:
> Hi Brian,
>
> On 2020-01-03 20:43, Brian E Carpenter wrote:
>> On 03-Jan-20 20:36, Julian Reschke wrote:
>>> On 02.01.2020 20:58, Brian E Carpenter wrote:
>>>> 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
>>>
>>> xml2rfc wants an "ISO short name" here (see
>>> <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.
>
> 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.
> ...

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