[rfc-i] Changes to the v3 <postal> element
mt at lowentropy.net
Thu Jun 10 18:46:28 PDT 2021
This is a good plan. Country is useful and mostly easy to get right. I'd be happy not to see addresses rendered at all, even if they were provided in XML.
RFC 7991 also includes phone and facsimilie elements. Aside from the laughably antiquated nature of fax, maybe we can deprecate those for similar reasons. (For the record, I have run the experiment and putting your mobile number in drafts resulted in a phone call. Once.)
On Fri, Jun 11, 2021, at 09:54, John R Levine wrote:
> One of the changes to the xml v3 grammar since RFC 7991 is a new <postal>
> element with a set of subfields such as <street>, <region>, and <code>. To
> render addresses we use a python library that depends on an open source
> address database originally from Google. While tracking down a rendering
> bug, we found that the rendering database is not actively maintained and
> has a long list of unresolved pull requests. We don't know of any other
> reliable source of rendering patterns.
> But we don't see a strong reason for readers to need the full postal address
> for RFC authors. Anecdotally, on rare occasions readers have used the postal
> address but (a) the email address is primary since <postal/> is optional and
> (b) readers likely have better ways to find contact information for RFC
> 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
> Our proposal is to deprecate all of the <postal> elements other than the
> <country/> element. Authors can include them if they want, but they won't be
> rendered and the RPC won't ask for them. We think this leaves the useful bit
> of info while avoiding a lot of extra work for minimal benefit.
> If there are issues we've missed, please let us know.
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest