Re: [xml2rfc] [Rfc-markdown] New xml2rfc release: v2.12.1

[Henrik Levkowetz <[e-mail]>]

On 2018-10-30 05:57, Julian Reschke wrote:
> On 2018-10-29 22:57, Henrik Levkowetz wrote:
>> ...
>> Country-specific address formatting.  Without it, you'll be stuck with the
>> fallback, which is very americentric for the text output, somewhat less so
>> for the html output (but not very refined).  I'd hate to see it go.
>> ...
> 
> Example? Smells a bit like overkill, given that v3 has simplified 
> address formatting (postalLine).

Example: In Norwegian and Swedish address format, the postal code goes
before the city, not after the region code.  This is correct:

  Midtskogveien 18
  2020 Skedsmokorset
  Norway 

The current html specification would instead have produced, depending on
how you work around its problems, one of

  Midtskogveien 18
  Skedsmokorset
  2020
  Norway

or 

  Midtskogveien 18
  Skedsmokorset, 2020
  Norway

which is a slighter degree of mangling than for places like various areas
of Japan, that needs city-region.  Here is a Japanese example.  This is
correct (except that it's also a translation, not just a romanization):

  Japan
  112-0001
  Tokyo-to
  Bunkyo-ku
  4-3-2 Hakusan
  3rd Floor Room B

and the RFC7992 specification would have rendered it as either this,
preserving the semantic labelling of the parts, but loosing the city-region
part:

  3rd Floor Room B
  4-3-2 Hakusan
  Tokyo-to, 112-0001
  Japan

or would loose all semantic labelling through forced use of postalLine for
all entries.

This problem has however been solved to a large degree by modern libraries.
If you can do this *right*, why continue to do it wrong?

postalLine would have been a bit of an improvement, if it hadn't been 
handicapped by throwing out interesting and valid information through
the choice of not permitting any of the existing elements that made sense
for the location's address.  A better choice would have been to add
city-region and postal-box as new address elements, and specify the use
of country-specific formatting.  The latter is something I could do.
I haven't done the former, even if it would have been tempting, given
that it would have given a pretty complete set of labelled address entities
to work with.

Take the statistics that are available here:
  https://datatracker.ietf.org/stats/document/yearly/country/

Forcing the removal of country (and region, and city) labelling if your
address needs a non-US address format makes producing that kind of info
harder; and it also removes the vCard/hCard annotation made possible by
having properly identified address parts.  The current code provides the
correct hCard property labels also for non-US addresses.

I'm *tired* of having software only work right for one country out of
many, and it's not necessary any longer.  Look at all the variations
across the globe, and come and tell me that it is preferred not to do
things as right as you can for most of them:

  https://en.wikipedia.org/wiki/Postal_address

Finally, given an old conversation you had about address formatting, the
rendering of the bottom address here may please you:

https://durif.tools.ietf.org/src/xml2rfc/html/show/elements.html#name-authors-addresses


Regards,

	Henrik