[rfc-i] Removing postal information from RFCs [was: Changes to the v3 <postal> element]

Julian Reschke julian.reschke at gmx.de
Thu Jun 10 19:51:54 PDT 2021


Am 11.06.2021 um 04:27 schrieb Mark Nottingham:
>
>> On 11 Jun 2021, at 12:21 pm, John Levine <johnl at taugh.com> wrote:
>>
>> It appears that Mark Nottingham  <mnot at mnot.net> said:
>>> Please clarify - do you intend to deprecate postalLine as well?
>>
>> Yes, we're deprecating all of the <postal> subelements except <country>.
>
> I don't see how deprecating <postalLine> follows from the problems you describe; if anything, they validate that it was the correct approach, and that the more detailed elements that were defined as an alternative were a mistake.
>
> My understanding is that the rfc7991bis effort was focused on minimal changes; this doesn't seem aligned with that. What you're really doing here is proposing that postal information be removed from RFCs altogether, which is a pretty substantial change. I've adjusted the Subject line to better reflect this.
>
> Question: How many RFCs (text and XML) to date have postal information included? From what I've seen, it's a substantial portion.
>
> Cheers,

I agree with Mark here.

For the purpose of fixing/finishing v3, reverting the changes past RFC
7991 plus maybe deprecating the old <postal> child elements is the right
thing. <postalLine> was added specifically to allow authors to have some
kind of address information with full control over formatting (and not
having to rely on out-of-band information).

(Also: keeping the elements while not displaying them is sort of
dangerous, it introduces invisible metadata; at a minimum it would need
to be stripped from the canoical XML)

Removing postal address info altogether is an interesting idea, but
needs to be done in the context of revising the style guide.

Best regards, Julian


More information about the rfc-interest mailing list