Subject: [xml2rfc] #280 (Version 2 cli): xml2rfc reorders <city> and <code>, in violation of RFC2629

From: "xml2rfc issue tracker" <[email-masked]>
Date: Wed, 03 Dec 2014 16:31:17 -0000

#280: xml2rfc reorders <city> and <code>, in violation of RFC2629

 According to RFC2629 section 2.2.2, the following applies to the in the
 <postal> element (emphasis mine)

 {{{
    This flexibility is provided to allow for different national formats
    for postal addresses. Note however, that although the order of the
    "city", "region", "code", and "country" elements isn't specified, at
    most one of each may be present. Regardless, these elements must not
    be re-ordered during processing by an XML application (e.g., display
    applications **must preserve the ordering of the information contained
    in these elements).**
 }}}

 Given the following XML as input:

 {{{
 <author fullname="Tore Anderson" initials="T" surname="Anderson">
 <organization>Redpill Linpro</organization>
 <address>
 <postal>
 <street>Vitaminveien 1A</street>
 <code>0485</code>
 <city>Oslo</city>
 <country>NO</country>
 </postal>
 <phone>+47 959 31 212</phone>
 <email>[email-masked]</email>
 </address>
 </author>
 }}}

 xml2rfc will produce the following text output:

 {{{
    Tore Anderson
    Redpill Linpro
    Vitaminveien 1A
    Oslo  0485
    NORWAY
 }}}

 Note how the order of <city> and <code> was reversed, even though RFC2629
 says such reordering must not be done.

 For what it's worth, in Norway, the postal code precedes the city name.
 This bug means I cannot express a syntactically correct Norwegian street
 address.

-- 
-------------------------------------+----------------------------------
 Reporter:  [email-masked]  |      Owner:  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  medium                   |  Milestone:
Component:  Version 2 cli            |    Version:  2.4.x
 Keywords:                           |
-------------------------------------+----------------------------------

Ticket URL: <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/280>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Wed, 03 Dec 2014 16:51:52 -0000

Comment (by [email-masked]):

 This was never implemented in any RFC2629 processor. Implementing it now
 could cause confusion in documents where people relied on the processor
 doing the reordering.

 The new "v3" vocabulary will add a new way to get exactly the ordering you
 want.

 I propose to close this as WONTFIX.

-- 
--------------------------------------+----------------------------------
Resolution:                           |   Keywords:
--------------------------------------+----------------------------------

Ticket URL: <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/280#comment:1>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Dec 2014 08:04:09 +1300

I would add the comment that many of us have used tricks such as

 <code>Oslo</code>
 <city>0485</city>

to work around discrepancies between the tools and real requirements.
It would indeed be nice if we never have to do that in v3.

  Brian

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Wed, 03 Dec 2014 20:16:11 -0000

Comment (by [email-masked]):

 I actually lied a little bit also, due to copy/pasting the wrong output:

 {{{
 <country>NO</country>
 }}}

 ...doesn't get turned into "NORWAY" in the generated output, it gets
 rendered as "NO". Same with lowercase "no". That's not terribly useful as
 postal address. Or, well, I'm sure the fine postal workers would get any
 letter safely delivered to me anyway, but given that RFC2629 says «the
 value of the "country" element should be a two-letter code from ISO 3166»
 I think that the xml2rfc tool should have rendered "NO" as the more postal
 worker-friendly "Norway".

 Anyway, I'm fine with closing this issue as WONTFIX, just wanted to let
 you know about this issue (for all I knew Norway was the only country in
 the world to put the postal code first, and so I thought the developers
 might not realise this was a problem for anyone). If it gets fixed in
 version 3, that's sounds completely fine to me.

Ticket URL: <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/280#comment:2>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>