issues with extensions to <postal>

[reschke]

The motivation for this incredible complex feature (see related tickets on xml2rfc trac), as explained in https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-10#section-3.1.13, is IMHO very weak.

It would be far easier to remove the inconsistency with the HTML format spec by fixing that spec instead. The use case of making statistics about the countries authors come from (if really needed) could be addressed by a for more simpler extension.

If the extensions are to stay we need to:

• define all elements properly (see <postal>: new definition incomplete, also out of sync with implementation #101)
• define processing more clearly (not based on a concrete implementation)
• make sure that any kind of processing (insertion of defaults such as country codes, re-ordering, skipping) is somehow reflected in the preptool output

[jrlevine]

I agree, if the problem is that the order of address lines is different in English and other languages, there are much simpler ways to solve it.

[reschke]

We actually solved that by introducing https://greenbytes.de/tech/webdav/rfc7991.html#element.postalLine

[reschke]

(see also https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/520)

[stpeter]

Based on rfc-interest discussion, if we move to postalLine plus optional country then that would simplify processing. We'd still need to document that in 7991bis, of course.

[reschke]

I can prepare a PR if you want me to.

[jrlevine]

@reschke please do
This requires a grammar change, the first one in quite a while. Maybe we should wait and see if there are others we can batch with it.

[reschke]

Here you go: #204

[jrlevine]

merged manually