Re: [Xml-sg-cmt] Proposed message to rfc-interest about <postal>

[Peter Saint-Andre <[e-mail]>]

After discussion on Monday I think that's no longer the direction we'd
prefer. :-)

John, your message looks good to me.

Peter

On 6/7/21 9:49 AM, Henrik Levkowetz wrote:
> Hi John,
> 
> I believe we also said we'd permit <country/> as a sibling to <postal/> in
> the schema, so that we later could deprecate and remove <postal/> entirely,
> but still keep <country/>.
> 
> 	Henrik
> 
> On 2021-06-06 23:56, John R Levine wrote:
>> Here's what I plan to send out, with bits borrowed from Peter:
>>
>> 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 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 work for minimal benefit.
>>
>> If there are issues we've missed, please let us know.
>>
>> R's,
>> John
>>
> 
>