[rfc-i] summary of Removing postal information from RFCs

Henning Schulzrinne hgs at cs.columbia.edu
Sun Jul 11 19:49:07 PDT 2021


To be clear, I listed four options for completeness, since the XML format
and the mandatory/voluntary/verified issues seem largely orthogonal. I was
certainly not advocating validation and don't see much advantage in having
a formal data structure (option 3). I'm sorry for contributing a strawman
to the discussion :-)

Henning

On Sun, Jul 11, 2021 at 10:23 PM John R Levine <johnl at taugh.com> wrote:

> > (2) Allow in some free-text format, used for human disambiguation, not
> > sending postal mail or other purposes.
>
> If we keep it, that's my inclination, if people want to provide a postal
> address, we use <postalline> to publish what they provided.
>
> > (3) Enforce specific elements (and the IETF has an RFC for that, used for
> > emergency calling)
>
> That's how we got into this mess.  It turns out that the general problem
> of parsing and formatting postal addresses is very hard.  There's an
> entire part of the UPU in Berne that will sell you very expensive address
> normalization services.  Since we are not the UPU, I don't think we care
> that much.
>
>
> https://www.upu.int/UPU/media/upu/documents/PostCode/UniversalPostcodesDatabaseProductSheetEnglish.pdf
>
> > (4) Validate the truthfulness of the data.
>
> I hope that was just for completeness, since we've gotten along for 50
> years without doing that.
>
> Regards,
> John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20210711/26bdc683/attachment.html>


More information about the rfc-interest mailing list