[rfc-i] Changes to the v3 <postal> element

Julian Reschke julian.reschke at gmx.de
Fri Jun 11 04:32:37 PDT 2021

Am 11.06.2021 um 11:42 schrieb Carsten Bormann:
> I have a lot of sympathy with what John is proposing here, discussions about the proper process (important!) notwithstanding.
>> On 2021-06-11, at 01:54, John R Levine <johnl at taugh.com> wrote:
>> The one part we care most about from <postal/> is <country/>.  This enables
>> people to do things like gather statistics about where RFCs originate, such as
>> https://www.arkko.com/tools/rfcstats/d-countrydistr.html
> The problem with doing this is that it removes the postalLine alternative.
> Or, the other way around, if we want to preserve postalLine, we make country inaccessible to those that use postalLine.
>     postal =
>       element postal {
>         attribute xml:base { text }?,
>         attribute xml:lang { text }?,
>         (( city | cityarea | code | country | extaddr | pobox | region
>            | sortingcode | street)*
>          | postalLine+)
>       }
> So if we want to have a country, let’s please extract that from postal, deprecate postal in total (or everything except postalLine), and put the country beside the postal address.
> (There are also some countries that need cities to understand which territory you are really in, but that is a whole different discussion.)

Here's the alternative:

1) Remove all child elements from <postal> that have been added after
RFC 7991.

2) Deprecate all other child elements of <postal> *except* <postalLine>
and <country>. (Deprecating means we could remove them in the next
iteration of the spec).

3) Remove country-specific formatting code from xml2rfc (going back to
v2 behaviour)

4) Change content model for postal like this:

      postal =
        element postal {
          attribute xml:base { text }?,
          attribute xml:lang { text }?,
          (( city | code | country | region | street)*
           | (postalLine+, country?))

So <country> can be combined with <postalLine>. (and will always appear

5) Define that preptool will convert the v2 content model to postalLine
+ country

6) Optionally add an attribute to country so that people can specify an
ISO code.

What this achieves:

- undo controversial changes done after 7991; removes dependency on a
library/database we do not control

- allows people to format their postal address in a way that feels right
to them

- no hidden metadata (except for the country code should we add it)

- tools can process <country> if they want to extract origin information

Best regards, Julian

More information about the rfc-interest mailing list