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

From: "John R Levine" <[email-masked]>
Date: 10 Jun 2021 19:54:49 -0400

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
authors.

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

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.

R's,
John
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: "John R Levine" <[email-masked]>
Date: 10 Jun 2021 21:33:58 -0400

> I don't think the elements should be deprecated. Instead there should
> be a new optional <pre> element that has the complete pre-rendered address.
> This would solve your rendering issue.

As Henrik can explain in more detail, no it wouldn't.  The same address is 
rendered differently in different contexts, e.g. using American rules or 
Swedish rules.  So I don't see any advantage in even trying.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: "John R Levine" <[email-masked]>
Date: 10 Jun 2021 21:43:31 -0400

On Fri, 11 Jun 2021, Toerless Eckert wrote:
> I am talking about some form of pre that would render verbatim
> without interpretation / application of rules such as done for ascii
> art as well. Only difference i would suggest is to not use a different font.

Yes, I understand.  No, that would not solve the problem.  Henrik can 
explain in more detail if anyone cares.

Regards,

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 11 Jun 2021 11:46:28 +1000

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.)

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Jun 2021 11:58:01 +1000

Please clarify - do you intend to deprecate postalLine as well?

Cheers,

> On 11 Jun 2021, at 9:54 am, John R Levine <[email-masked]> 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.
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: "John Levine" <[email-masked]>
Date: 10 Jun 2021 22:21:10 -0400

>Please clarify - do you intend to deprecate postalLine as well?

Yes, we're deprecating all of the <postal> subelements except <country>.

R's,
John

>> 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.
>>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Jun 2021 12:27:51 +1000

> On 11 Jun 2021, at 12:21 pm, John Levine <[email-masked]> wrote:
> 

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,

---

From: "John R Levine" <[email-masked]>
Date: 10 Jun 2021 22:47:09 -0400

> 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 fro…

It's true that a fair number of RFCs have postal addresses.  The question 
is whether including those addresses is worth the hassle of collecting 
them.  We didn't see much evidence that it is.

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Jun 2021 12:47:53 +1000

> On 11 Jun 2021, at 12:47 pm, John R Levine <[email-masked]> wrote:
> 
> It's true that a fair number of RFCs have postal addresses.  The question is whether including those addresses is worth the hassle of collecting them.  We didn't see much evidence that it is.

What's the hassle?

Have you tried to gather evidence?

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Jun 2021 04:51:54 +0200

> Question: How many RFCs (text and XML) to date have postal information included? From what I've seen, it's a substantial portion.

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

---

From: "John R Levine" <[email-masked]>
Date: 10 Jun 2021 22:53:46 -0400

> What's the hassle?

If you'll refer back to my original message, the code that tries to turn 
the subfields of <postal> into a formatted address depend on an 
abandonware database.

I suppose we could go back and reissue all of the existing XML RFCs that 
have postal addresses with <postalline> rather than what's there now, but 
I don't think we are anywhere near consensus on revising published XML.

> Have you tried to gather evidence?

About what?  If there is evidence that the postal addresses are useful, 
I'd be happy to hear about it.  All we've seen is along the lines of well, 
someone might use it for X, but in practice they don't.

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Jun 2021 04:57:07 +0200

Am 11.06.2021 um 04:47 schrieb Mark Nottingham:
> ...
> ...

The problem that got us here is that RFC 2629 defined a sub grammar for
postal information, but always rendered it like a US address. It's clear
why this upsets some of authors not living in the US.

RFC 7991 addressed this by allowing authors to control the textual
information precisely, giving up marking up the elements individually. I
still think this is the right approach.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Jun 2021 12:57:42 +1000

> On 11 Jun 2021, at 12:53 pm, John R Levine <[email-masked]> wrote:
> 
>> What's the hassle?
> 
> If you'll refer back to my original message, the code that tries to turn the subfields of <postal> into a formatted address depend on an abandonware database.

As I pointed out previously, this argument does not apply to <postalLine>.

> I suppose we could go back and reissue all of the existing XML RFCs that have postal addresses with <postalline> rather than what's there now, but I don't think we are anywhere near consensus on revising published XML.

I think that's an orthogonal decision.

> About what?  If there is evidence that the postal addresses are useful, I'd be happy to hear about it.  All we've seen is along the lines of well, someone might use it for X, but in practice they don't.

You claimed that lack of evidence was justification for this change. I was asking if that was informed lack of evidence, or just lack of asking.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Jun 2021 04:58:36 +0200

> 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 experime…

<facsimile> was deprecated on 7991.

Best regards, Julian

---

From: "John R Levine" <[email-masked]>
Date: 10 Jun 2021 22:59:00 -0400

> You claimed that lack of evidence was justification for this change. I was asking if that was informed lack of evidence, or just lack of asking.

I'm asking.  If anyone thinks that the physical postal address is 
important and worth the editors spending time on, let us know.

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Jun 2021 12:59:58 +1000

> On 11 Jun 2021, at 12:59 pm, John R Levine <[email-masked]> wrote:
> 
> I'm asking.  If anyone thinks that the physical postal address is important

I do.

> and worth the editors spending time on, let us know.

Given that we're already spending time on it, I think we've crossed that bridge.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Jun 2021 05:13:29 +0200

Am 11.06.2021 um 01:54 schrieb John R Levine:
> 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

That is misleading. Most of these elements date back to RFC 2629. RFC
7991 has added <postalLine> which allows authors to format their
information the way to want it, instead of having to live with the baked
in address formatter.

> 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.

+1, that's indeed a problem.

> address but (a) the email address is primary since <postal/> is optional

Strictly speaking, <email> is optional as well. We may want to require it.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Jun 2021 13:16:11 +1000

> On 11 Jun 2021, at 1:13 pm, Julian Reschke <[email-masked]> wrote:
> 

Some authors don't wish to make their e-mail address available in the specification. Whether or not that's reasonable is debatable -- but again, this seems like it's out of scope for an effort to merely clean up 7991. Substantive changes should wait until we have a community-driven process in place.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 Jun 2021 20:27:39 -0700

On Thu, Jun 10, 2021 at 8:16 PM Mark Nottingham <[email-masked]> wrote:

> Some authors don't wish to make their e-mail address available in the
> specification. Whether or not that's reasonable is debatable -- but again,
> this seems like it's out of scope for an effort to merely clean up 7991.
> Substantive changes should wait until we have a community-driven process in
> place.
>

+1

Unless there's some technical reason why we should need to require email,
this should be out of scope....

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Jun 2021 17:10:38 +1200

Upping the level one more notch:
> Given that we're already spending time on it, I think we've crossed that bridge.

I detect an obvious lack of consensus here, so a community process is needed, and we don't have one yet. So IMHO this can has to be kicked down the road until the RSE discussions have been resolved.

(FWIW I have never received paper mail in my life about any RFC that I've co-authored, but of course it is essential to give an attribution and enough of an address to distinguish one person from another. We've had at least one case of two people with the same name and the same employer, and at least one of them is an RFC author.)

    Brian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Jun 2021 11:26:35 +0200

> I detect an obvious lack of consensus here, so a community process is needed, and we don't have one yet. So IMHO this can has to be kicked down the road until the RSE discussions have been resolved.

I'll make a proposal later that should be able to reach consensus.

> (FWIW I have never received paper mail in my life about any RFC that I've co-authored, but of course it is essential to give an attribution and enough of an address to distinguish one person from a…

In which case the email address should help, no?

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Jun 2021 11:42:14 +0200

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 <[email-masked]> wrote:
> 

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.)

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Jun 2021 13:32:37 +0200

> (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
last)

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

---

From: "John R Levine" <[email-masked]>
Date: 11 Jun 2021 11:38:16 -0400

> Or, the other way around, if we want to preserve postalLine, we make country inaccessible to those that use postalLine.

Well, OK, but that's not enough.  We have found that the current set of 
fields won't let us render addresses consistently in the future.  My 
suggestion is to say the addresses aren't important, so don't render them 
at all.  If they are important and we want to keep postalline, we
need to go back and change the published RFCs to use postalline instead so 
they can be rendered later without the abandonware format library.

We could do that, but it seems way more effort than it's worth.

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Jun 2021 17:46:12 +0200

Am 11.06.2021 um 17:38 schrieb John R Levine:
>> I have a lot of sympathy with what John is proposing here, discussions
>> about the proper process (important!) notwithstanding.
>>
>> Or, the other way around, if we want to preserve postalLine, we make
>> country inaccessible to those that use postalLine.
>
> suggestion is to say the addresses aren't important, so don't render
> them at all.  If they are important and we want to keep postalline, we
> need to go back and change the published RFCs to use postalline instead
> so they can be rendered later without the abandonware format library.
> ...

I understand that you want to avoid that, but I'm pretty sure that at
some point, we'll have to do that anyway.

(Another issue that might require that is the cleanup of the seriesInfo
mess).

Best regards, Julian

---

From: Larry Masinter <[email-masked]>
Date: Fri, 11 Jun 2021 00:53:40 -0700

I think it’s important to keep and encourage authors to supply as part of identity metadata. 

((Sent from phone))

--
LarryMasinter.net

> On Jun 10, 2021, at 8:13 PM, Julian Reschke <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 11 Jun 2021 12:52:41 -0400

>I think it’s important to keep and encourage authors to supply as part of identity metadata. 

Of the 378 RFCs published so far in XML, 77 have no postal info at all.

If we're going to demand postal info from everyone, that is quite a large change to existing practice.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Jun 2021 09:03:02 +1200

> In which case the email address should help, no?

Yes, but not over a 20 or 30 year timespan with people moving from job to job.

There's no perfect solution, but first we need to know the *purposes* of the author's address section. All I wanted to say is that they don't include the ability to send physical mail.

   Brian

---

From: Larry Masinter <[email-masked]>
Date: Fri, 11 Jun 2021 18:35:59 -0700

Identity metadata is data the author supplied to establish their identity.  Whether you could send postal mail to the person isn’t the point.
--
LarryMasinter.net

> On Jun 11, 2021, at 2:03 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 11 Jun 2021 23:36:06 -0400

>Identity metadata is data the author supplied to establish their identity.  Whether you could send postal mail to the person isn’t the point.

I don't get it.  Given that the IETF has never verified anything about RFC authors other than their e-mail addresses,
what difference does it make if they provide a street address?  What if I just made one up?  Or in my case, since I live
in a small town, I could provide an address what has everything but the town wrong and I'd get any mail sent to me anyway.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Jun 2021 16:37:44 +1200

On 12-Jun-21 15:36, John Levine wrote:
> what difference does it make if they provide a street address?  What if 
I just made one up?  Or in my case, since I live
> in a small town, I could provide an address what has everything but the 
town wrong and I'd get any mail sent to me anyway.

It's even better. Once when I lived in Switzerland I got a very late Christmas card that had been redirected from Swaziland.

The postal address *in itself* cannot really matter. When it comes to identity for IPR reasons, look at what patents say: you see things like "<name> Durham, NC (US)" or "<name> Kilchberg (CH)". I assume the USPTO thought this through at some time, and not recently. One of my uncles got a US 
patent in 1951 and he's identified as "<name> Harrow, England".

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Jun 2021 10:39:12 -0400

John Levine <[email-masked]> wrote:
    >> Identity metadata is data the author supplied to establish their
    >> identity.  Whether you could send postal mail to the person isn’t the
    >> point. 

    > I don't get it.  Given that the IETF has never verified anything about
    > RFC authors other than their e-mail addresses, what difference does it
    > make if they provide a street address?  What if I just made one up?

I think that when we started in the 1980s, the email address was relatively
official.   brian.carpenter@IBM was pretty clear (IBM!brian ?), to the point
where I think that any lawyers that had IPR questions would be able to find
him.

I actually wonder if you shouldn't ask the question too loudly: the lawyers
might say WTF and make us do better.
    
    > Or
    > in my case, since I live in a small town, I could provide an address
    > what has everything but the town wrong and I'd get any mail sent to me
    > anyway. 

"John Levine, USA"      :-)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [