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

From: "John R Levine" <[email-masked]>
Date: 11 Jul 2021 17:34:08 -0400

Here's a somewhat tardy summary of the postal element discussion.

It's still not clear to me what people think the purpose of the 
optional postal address is.

R's,
John

I said:
  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.

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

(True but it's switched from just enumerating the items to using patterns from
the datatbase, with extra fields.)

Brian said:
> (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.)

Julian responded: In which case the email address should help, no?
Brian: Yes, but not over a 20 or 30 year timespan with people moving from job to job.

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

  Larry Masinter  said:
>I think it's important to keep and encourage authors to supply as part of identity metadata.

I said: Many RFCs have no postal info. If we're going to demand postal info from everyone, that is quite a large change to existing practice.

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

John: 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 that has everything but the 
town wrong and I'd get the mail anyway.

If we want identity metadata, we could ask for ORCID. I doubt we want to go there.

_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 11 Jul 2021 23:50:37 +0200

> If we want identity metadata, we could ask for ORCID. I doubt we want to go there.

We may not ask every author for one, but it would make a lot of sense for an author to be able to provide one.

Grüße, Carsten

---

From: "John R Levine" <[email-masked]>
Date: 11 Jul 2021 22:23:45 -0400

> (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, [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: 11 Jul 2021 22:33:07 -0400

On Sun, 11 Jul 2021, Larry Masinter wrote:
> Why do people want to do standards in the IETF rather just editing a spec in
> Google Docs or GitHub? One primary value that IETF adds is some kind of
> legal action due to copyright or patent claimed infringement, or anti-trust.
> It's the reason why there is a NOTE WELL.

FWIW, I have been a trustee of the IETF Trust for the past four years and 
the identities of IETF contributors have never been an issue.  That's not 
a very compelling argument.

In the RFC publication process, the only identity we verify is your e-mail 
adddress, since you can't approve an RFC if you don't respond to e-mail.

Regards,

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 11 Jul 2021 22:49:07 -0400

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jul 2021 15:18:39 +1200

> a very compelling argument.

IANAL, but surely what counts in prior art claims is certification that
a document *was* published , not which particular Jane Doe  wrote it.

Also, do we actually have an issue here? Supplying a full address is
already optional, judging by a number of recent RFCs.

    Brian

---

From: "John Levine" <[email-masked]>
Date: 11 Jul 2021 23:48:38 -0400

>a document *was* published , not which particular Jane Doe  wrote it.

It has never been a problem so far, but we trustees do worry about a
scenario in which an I-D or an RFC contains text that was borrowed
from someone else and the someone else objects. We have a process that
shows good faith but if we coudn't find the person who did the
borrowing, it could be messy.

>already optional, judging by a number of recent RFCs.

The issue that precipitated this is that if you do provide an address,
the complex format we're currently using turns out to depend on an
abandonware formatting library.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jul 2021 17:30:51 +1200

> borrowing, it could be messy.

Yes, I can see that, but it would be messy (for example) to look for
someone whose affiliation and street address belong to a no-longer
existing company; so messy cases probably come with the territory. 
 
> abandonware formatting library.

Understood. I agree that the obvious short-term measure is to advise
use of <postalLine>. Worry about changing the formal definition later.

   Brian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Jul 2021 08:53:04 +0200

Am 11.07.2021 um 23:34 schrieb John R Levine:
> It's still not clear to me what people think the purpose of the optional
> postal address is.
>
> R's,
> John
>
> I said:
> ...

Not true. What I said is about the definition of the vocabulary. You are
talking about an implementation choice that the author of the *tool* made.

Best regards, Julian

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2021 11:59:10 -0400

> existing company; so messy cases probably come with the territory.

If it wasn't clear, I don't think that postal addresses would 
make any difference.  The most likely version of this scenario is that 
someone uses material he wrote while working for company X, and the 
company says it belongs to them, not to him.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 13 Jul 2021 16:49:18 -0400

> We may not ask every author for one, but it would make a lot of sense for an author to be able to provide one.

I'm not opposed to it, but it's something to save for 3.1 or v4.

Regards,

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Jul 2021 23:02:05 +0200

> I'm not opposed to it, but it's something to save for 3.1 or v4.

Definitely.

Where is the to-do list/product backlog/freezer?

Grüße, Carsten

---

From: "John R Levine" <[email-masked]>
Date: 13 Jul 2021 21:40:49 -0400

On Wed, 14 Jul 2021, Toerless Eckert wrote:
> And of course i just ran into the problem of identifying authors by
> email address. Seemingly this was also reaffirmed as a new rule in 2019,
> that since then, you can not submit to Datatracker any co-author who wants to
> keep privacy of his email address, especially for the case that this is
> a -bis document and that original author is retired and not actively
> engaged in the -bis fixups.

I find it very diifficult to have sympathy for a person who wants to be 
listed as the author of a document but not get e-mail about it.

If you want to change someone's e-mail address, or remove him as an 
author, we have simple ways to do both.

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Jul 2021 11:45:38 +1000

It's not clear what John's proposed resolution is (if any).

Like Brian, I'm fine if the proposal is to deprecate (= disallow in future RFCs) the <city> etc. elements, but still accommodate <postalLine>.

Cheers,

> On 12 Jul 2021, at 3:30 pm, Brian E Carpenter <[email-masked]> wrote:
> 

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

---

From: "John R Levine" <[email-masked]>
Date: 13 Jul 2021 21:57:18 -0400

> It's not clear what John's proposed resolution is (if any).

Here's what we came up with on Monday.  The current schema for <postal> is:

( ( city | cityarea | code | country | extaddr | pobox | region | sortingcode | street )*
   | postalLine+ )

We propose a small tweak:

( ( city | cityarea | code | country | extaddr | pobox | region | sortingcode | street )*
   | postalLine+  country? )

That is, we still allow the current syntax, in which we render just the 
country, getting rid of the problem of what order to render the rest.

Or you can give a sequence of postallines with an optional country, in 
which we render the whole list in order.

The point of adding the country after the postallines is so that scripts 
that are doing country statistics don't have to guess whether the last 
postalline is the country.

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Jul 2021 12:32:34 +1000

WFM. Will you add some prose that the first from isn't preferred? 

Cheers,

> On 14 Jul 2021, at 11:57 am, John R Levine <[email-masked]> wrote:
> 
> That is, we still allow the current syntax, in which we render just the country, getting rid of the problem of what order to render the rest.
> 
> Or you can give a sequence of postallines with an optional country, in which we render the whole list in order.
> 
> The point of adding the country after the postallines is so that scripts that are doing country statistics don't have to guess whether the last postalline is the country.
> 
> Regards,

---

From: "John R Levine" <[email-masked]>
Date: 13 Jul 2021 22:36:37 -0400

> WFM. Will you add some prose that the first from isn't preferred?

It's not just unpreferred, it's deprecated.

Regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jul 2021 14:38:44 +1200

John, 

That would work, but in any case I am perfectly happy to use

  <author initials="B." surname="Carpenter" fullname="Brian Carpenter">
      <organization abbrev="Univ. of Auckland"/>
      <address>
        <postal>
          <postalLine>School of Computer Science</postalLine>
          <postalLine>University of Auckland</postalLine>
          <postalLine>PB 92019</postalLine>
          <postalLine>Auckland 1142</postalLine>
          <postalLine>New Zealand</postalLine>
        </postal>
        <email>[email-masked]</email>
      </address>
    </author>

Regards
   Brian

---

From: "John R Levine" <[email-masked]>
Date: 13 Jul 2021 22:42:43 -0400

>        <email>[email-masked]</email>

We hope you do this, for, you know, statistics:

           <country>New Zealand</country>

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Jul 2021 05:01:40 +0200

> postalline is the country.

Looks good to me.

Best regards, Julian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jul 2021 16:48:19 +1200

I'll be glad to do that when it works. As of very recently, it didn't work (on the web tool).

Regards
   Brian Carpenter

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Jul 2021 09:29:12 +0200

> Or you can give a sequence of postallines with an optional country, in which we render the whole list in order.

Works for me.

(I’m sure nobody will mind if my postal people tell me that starting the address with the lines

GND: 987654321
ORCID: 0123-4711-0815

will get my mail faster to me.)

Grüße, Carsten

---

From: "John R Levine" <[email-masked]>
Date: 19 Jul 2021 13:29:50 -0400

> Rule for no-email is of course that you do not partake in the
> creation of the RFCxxxxbis, but you did partake in RFCxxxx and
> significant enough (for copyright reasions) portions of RFCxxxx
> are inherited without explicit citation into RFCxxxxbis
>
> Does that make sense to you ?

No.  The RPC has a firm rule that everyone who is listed as an author has 
to approve the AUTH48 final draft.  If the author isn't willing to 
respond to mail, they can't publish the RFC.

There is an IESG workaround for the rare case that an author has died or 
has truly disappeared, but "I don't feeel like getting mail" does not 
consitute an emergency.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 19 Jul 2021 13:40:54 -0400

> I think by default we should assume that auhors of some RFCxxxx
> will still have to be listed as authors for RFCxxxxbis, unless
> the RFCxxxxbis is not inheriting text of the RFCxxxx. Purely
> for copyright reasons.

No.  Unless the previous RFC was published before 2005, every author has 
already granted the IETF the right to reuse the material, with or without 
credit.

It's up to the people working on a draft to decide who to list as authors. 
I continue to have no sympathy for someone who says he wants to be listed 
as an author of an RFC but there's no way to contact him about it.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 19 Jul 2021 13:57:48 -0400

> If a bis inherits the mayority of its text from an original RFC
> where the author has died. What do you suggest to do wrt to authorship,
> and are you willing to claim that your suggestion is compliant with
> copyright law ?

We definitely have the rights to use all RFCs published since 2005, and 
probably all the ones since 1998 since they were published with an ISOC 
copyright and ISOC assigned its rights to the IETF Trust.  If it's older 
than that, we may or may not depending on whether the author assigned the 
rights to the trust.  Some have, some haven't.  In the US where RFCs are 
published, for copyright purposes it makes no difference whether a 
publication names its author(s).

R's,
John

PS: Just FYI, I've been a technical expert in a lot of copyright cases 
starting with Field vs. Google, the case that established that search 
engine caches are legal, where the judge referred to me by name in the 
decision. Just for fun I took the Harvard online CopyrightX course earlier 
this year.  Where'd you learn about it?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Jul 2021 09:21:05 +1200

> publication names its author(s).

RFC5378 was also something of a milestone. It's worth noting that
<rfc ipr="pre5378Trust200902"> produces the appropriate disclaimer,
useful for bis documents with lost authors from before Nov 2008:

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

       Brian