Re: [Rfc-markdown] Carsten: Re: [rfc-i] summary of Removing postal information from RFCs

CCing RFC-markdown...

> On 19. Jul 2021, at 19:18, Toerless Eckert <tte@cs.fau.de> wrote:
> 
> So, what is the relationship kramdown-rfc2629 to this ?
> 
> - Can the kramdown create xmlv3 output ?

Yes, via the --v2v3 process in xml2rfc.

Without the --v3 (kdrfc -3) flag, kramdown-rfc2629 produces just that, RFC 2629 (or its evolution that we call v2, as per RFC 7749).
This can be used by the historic v2 code in xml2rfc, or it can be converted to v3 using xml2rfc —v2v3.
After the successful transition from v2 to some v3, I don’t think that is a very function any more, but I’ll wait before killing it.

With the --v3 (-3) flag, kramdown-rfc2629 produces XML that xml2rfc can process, and that --v2v3 can turn into the current version of v3.
This XML is no longer v2 compliant, as it uses the new features of v3.
Not all v3 features are directly accessible from markdown syntax, but practically all of them can be activated via inline attribute lists (IALs) or by including XML syntax in the markdown.
(The only one really missing from the direct markdown translation is the new table format with colspan/rowspan, and that is hard to get right in markdown — I’m working on it.
Until then just enter the tables that need this in v3 XML format inside the markdown.)

> - Does it support postalline ?

Since 1.5.2, yes.
(The memo: update early, update often.)

> - Is there a better way to figure out answers other han
>   - check readme on github (didn't find it)

I’d memoize this: http://rfc.space
(Yeah, I’ll get to httpsing this, one of these days.)

>   - ask carsten (here)

Here = rfc-markdown@ietf.org (which can also be searched).

>   - trial and error (tried to avoid this so far ..)

Yes: read the commit history and/or the source.
Important progress is announced on rfc-markdown@ietf.org, but since postalLine support is probably a minority program right now, I didn’t announce 1.5.2 there yet (too little time before today).

Re postalLine, the 1.5.2 commit says:

+  # The below anticipates the "postalLine" changes.
+  # If a postalLine is used (abbreviated "postal" in YAML),
+  # non-postalLine elements are appended as further postalLines.
+  # This prepares for how "country" is expected to be handled
+  # specially with the next schema update.
+  # So an address is now best keyboarded as:
+  #   postal:
+  #     - Foo Street
+  #     - 28359 Bar
+  #   country: Germany

So what happens here is to put the value of `country:` in as another postalLine until `<country>` becomes allowed together with `<postalLine>`s in one of the next v3 versions.
Then there will be another change in the tool (here my strategy to isolate kramdown-rfc from v3 changes via --v2v3 obviously doesn’t work).
If you follow the above recommendation, there will be no need to do another change to the YAML then.

Grüße, Carsten

> 
> Cheers
>    Toerless
> 
> On Wed, Jul 14, 2021 at 09:29:12AM +0200, Carsten Bormann wrote:
>> On 14. Jul 2021, at 03:57, John R Levine <johnl@taugh.com> wrote:
>>> 
>>> 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
>> 
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest@rfc-editor.org
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 
> -- 
> ---
> tte@cs.fau.de