From nobody Thu Apr 2 06:54:05 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1E33A12DA for ; Thu, 2 Apr 2020 06:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w--k12apXf5N for ; Thu, 2 Apr 2020 06:53:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1D83A12CD for ; Thu, 2 Apr 2020 06:53:54 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:56578 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jK0Hg-0005vw-KB; Thu, 02 Apr 2020 06:53:54 -0700 To: "David R. Oran" , xml2rfc@ietf.org References: From: Henrik Levkowetz Message-ID: Date: Thu, 2 Apr 2020 15:53:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="F93n4LcAVcxIN7EHC4ewBMLlI8vNgiRL2" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, daveoran@orandom.net X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Some problems with idnits checks on V3 document X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 13:54:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F93n4LcAVcxIN7EHC4ewBMLlI8vNgiRL2 Content-Type: multipart/mixed; boundary="tMJ1tS51RewtOq9GIc6WbGS7oxdB1Xhdn"; protected-headers="v1" From: Henrik Levkowetz To: "David R. Oran" , xml2rfc@ietf.org Message-ID: Subject: Re: [xml2rfc] Some problems with idnits checks on V3 document References: In-Reply-To: --tMJ1tS51RewtOq9GIc6WbGS7oxdB1Xhdn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dave, On 2020-03-31 15:58, David R. Oran wrote: > One of these seem to be xml2rfc rendering problem; others may be idnit = > glitches that only show up on V3 docs: >=20 > - The too long line 1551 is in fact not too long - the length=20 > computation seems to be screwed up by the non-ascii characters (probabl= y=20 > idnit problem?) Yes, that's right. Will see what can be done. > - somehow xml2rfc elided part of an author name into the updates head=20 > field and author address into the Intended Status header field. This=20 > only happens in the .txt output, not the HTML or PDF. xml2rfc bug? Will investigate, and if possible provide a fix in the next release, due tomorrow. > - idnits says this has a downref, but I believe that an I.D. marked=20 > experimental saying it updates an experimental RFC isn=E2=80=99t a down= ref,=20 > right? Huh. I'll check the code. > I include the idnits output below and the xml file as an attachment=20 > (note that this is still a bit private - we haven=E2=80=99t submitted y= es) Understood. > Let me know of any followup I should do - would like to get this=20 > submitted in the next couple of days. Ack. Will follow up when I have more information. Best regards, Henrik > Thanks! DaveO. >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94 >=20 > idnits 2.16.03 >=20 >=20 > tmp/draft-oran-icnrg-reflexive-forwarding.txt: > tmp/draft-oran-icnrg-reflexive-forwarding.txt(1491): Found non-ascii=20 > character (=EF=BF=BD) in position 18. > tmp/draft-oran-icnrg-reflexive-forwarding.txt(1500): Found non-ascii=20 > character (=EF=BF=BD) in position 16. > tmp/draft-oran-icnrg-reflexive-forwarding.txt(1551): Line is too long: = > the offending characters are 'ch,' > tmp/draft-oran-icnrg-reflexive-forwarding.txt(1551): Found non-ascii=20 > character (=EF=BF=BD) in position 16. > tmp/draft-oran-icnrg-reflexive-forwarding.txt(1597): Found non-ascii=20 > character (=EF=BF=BD) in position 67. >=20 >=20 > Checking boilerplate required by RFC 5378 and the IETF Trust (see > https://trustee.ietf.org/license-info): > --------------------------------------------------------------------= -------- >=20 > No issues found here. >=20 > Checking nits according to=20 > https://www.ietf.org/id-info/1id-guidelines.txt: > --------------------------------------------------------------------= -------- >=20 > =3D=3D There are 4 instances of lines with non-ascii characters in = the=20 > document. >=20 >=20 > Checking nits according to https://www.ietf.org/id-info/checklist : > --------------------------------------------------------------------= -------- >=20 > ** There is 1 instance of too long lines in the document, the longes= t=20 > one > being 3 characters in excess of 72. >=20 >=20 > Miscellaneous warnings: > --------------------------------------------------------------------= -------- >=20 > =3D=3D Unrecognized Status in 'Intended status: Experimental Univer= sity=20 > of > Applied Sciences Emden/Leer', assuming Proposed Standard >=20 > (Expected one of 'Standards Track', 'Full Standard', 'Draft=20 > Standard', > 'Proposed Standard', 'Best Current Practice', 'Informational', > 'Experimental', 'Informational', 'Historic'.) >=20 > =3D=3D Couldn't figure out when the document was first submitted -- = there=20 > may > comments or warnings related to the use of a disclaimer for=20 > pre-RFC5378 > work that could not be issued because of this. Please check the = > Legal > Provisions document at https://trustee.ietf.org/license-info to=20 > determine > if you need the pre-RFC5378 disclaimer. >=20 >=20 > Checking references for intended status: Proposed Standard > --------------------------------------------------------------------= -------- >=20 > (See RFCs 3967 and 4897 for information about using normative=20 > references > to lower-maturity documents in RFCs) >=20 > ** Downref: Normative reference to an Experimental RFC: RFC 8569 >=20 > ** Downref: Normative reference to an Experimental RFC: RFC 8609 >=20 >=20 > Summary: 3 errors (**), 0 flaws (~~), 4 warnings (=3D=3D), 0 comm= ents=20 > (--). >=20 > -----------------------------------------------------------------------= --------- >=20 >=20 > 2 ICNRG D.=20 > Oran > 3 Internet-Draft Network Systems Research and=20 > Design > 4 Updates: 8569, 8609 (if approved) D.=20 > Kutscher > 5 Intended status: Experimental University of Applied Sciences=20 > Emden/Leer > 6 Expires: 2 October 2020 31 March=20 > 2020 >=20 > 8 Reflexive Forwarding for CCNx and NDN Protocols > 9 draft-oran-icnrg-reflexive-forwarding-00 >=20 > 11 Abstract >=20 > 13 Current Information-Centric Networking protocols such as CCNx and= =20 > NDN > 14 have a wide range of useful applications in content retrieval and= > 15 other scenarios that depend only on a robust two-way exchange in = > the > 16 form of a request and response (represented by an _Interest-Data > 17 exchange_ in the case of the two protocols noted above). A numbe= r=20 > of > 18 important applications however, require placing large amounts of = > data > 19 in the Interest message, and/or more than one two-way handshake. > 20 While these can be accomplished using independent Interest-Data > 21 exchanges by reversing the roles of consumer and producer, such > 22 approaches can be both clumsy for applications and problematic=20 > from a > 23 state management, congestion control, or security standpoint. =20 > This > 24 specification proposes a _Reflexive Forwarding_ extension to the = > CCNx > 25 and NDN protocol architectures that eliminates the problems=20 > inherent > 26 in using independent Interest-Data exchanges for such=20 > applications. > 27 It updates RFC8569 and RFC8609. >=20 > 29 Status of This Memo >=20 > 31 This Internet-Draft is submitted in full conformance with the > 32 provisions of BCP 78 and BCP 79. >=20 > 34 Internet-Drafts are working documents of the Internet Engineering= > 35 Task Force (IETF). Note that other groups may also distribute > 36 working documents as Internet-Drafts. The list of current=20 > Internet- > 37 Drafts is at https://datatracker.ietf.org/drafts/current/. >=20 > 39 Internet-Drafts are draft documents valid for a maximum of six=20 > months > 40 and may be updated, replaced, or obsoleted by other documents at = > any > 41 time. It is inappropriate to use Internet-Drafts as reference > 42 material or to cite them other than as "work in progress." >=20 > 44 This Internet-Draft will expire on 2 October 2020. >=20 > 46 Copyright Notice >=20 > 48 Copyright (c) 2020 IETF Trust and the persons identified as the > 49 document authors. All rights reserved. >=20 > 51 This document is subject to BCP 78 and the IETF Trust's Legal > 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ > 53 license-info) in effect on the date of publication of this=20 > document. > 54 Please review these documents carefully, as they describe your=20 > rights > 55 and restrictions with respect to this document. >=20 > 57 Table of Contents >=20 > 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .= =20 > 3 > 60 1.1. Problems with pushing data . . . . . . . . . . . . . . .= =20 > 4 > 61 1.2. Problems with utilizing independent exchanges . . . . . .= =20 > 5 > 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . .= =20 > 6 > 63 3. Overview of the Reflexive Forwarding design . . . . . . . . .= =20 > 6 > 64 4. Naming of Reflexive Interests . . . . . . . . . . . . . . . .= =20 > 10 > 65 5. Forwarder operation for Reflexive Interests . . . . . . . . .= =20 > 11 > 66 6. State coupling between producer and consumer . . . . . . . .= =20 > 12 > 67 7. Use cases for Reflexive Interests . . . . . . . . . . . . . .= =20 > 12 > 68 7.1. Achieving Remote Method Invocation with Reflexive > 69 Interests . . . . . . . . . . . . . . . . . . . . . . . .= =20 > 12 > 70 7.2. RESTful Web Interactions . . . . . . . . . . . . . . . .= =20 > 15 > 71 7.3. Achieving simple data pull from consumers with reflexive > 72 Interests . . . . . . . . . . . . . . . . . . . . . . . .= =20 > 15 > 73 8. Implementation Considerations . . . . . . . . . . . . . . . .= =20 > 19 > 74 8.1. Forwarder implementation considerations . . . . . . . . .= =20 > 19 > 75 8.1.1. Forwarding Information Base (FIB) . . . . . . . . . .= =20 > 19 > 76 8.1.2. Interactions with Interest Lifetime . . . . . . . . .= =20 > 20 > 77 8.1.3. Interactions with Interest aggregation . . . . . . .= =20 > 21 > 78 8.2. Consumer Implementation Considerations . . . . . . . . .= =20 > 21 > 79 8.2.1. Data objects returned by the consumer to reflexive=20 > name > 80 Interests arriving from a producer . . . . . . . . .= =20 > 21 > 81 8.2.2. Terminating unwanted reflexive Interest exchanges . .= =20 > 22 > 82 8.2.3. Interactions with caching . . . . . . . . . . . . . .= =20 > 22 > 83 8.3. Producer Implementation Considerations . . . . . . . . .= =20 > 22 > 84 9. Operational Considerations . . . . . . . . . . . . . . . . .= =20 > 23 > 85 10. Mapping to CCNx and NDN packet encodings . . . . . . . . . .= =20 > 24 > 86 10.1. Packet encoding for CCNx . . . . . . . . . . . . . . . .= =20 > 24 > 87 10.2. Packet encoding for NDN . . . . . . . . . . . . . . . .= =20 > 24 > 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .= =20 > 24 > 89 12. Security Considerations . . . . . . . . . . . . . . . . . . .= =20 > 25 > 90 12.1. Collisions of reflexive Interest names . . . . . . . . .= =20 > 25 > 91 12.2. Additional resource pressure on PIT and FIB . . . . . .= =20 > 26 > 92 12.3. Privacy Considerations . . . . . . . . . . . . . . . . .= =20 > 26 > 93 13. Normative References . . . . . . . . . . . . . . . . . . . .= =20 > 27 > 94 14. Informative References . . . . . . . . . . . . . . . . . . .= =20 > 27 > 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .= =20 > 30 >=20 > 97 1. Introduction >=20 > 99 Current ICN protocols such as CCNx [RFC8569] and [NDN] have a wid= e > 100 range of useful applications in content retrieval and other=20 > scenarios > 101 that depend only on a robust two-way exchange in the form of a > 102 request and response. These ICN architectures use the terms > 103 "consumer" and "producer" for the respective roles of the=20 > requester > 104 and the responder, and the protocols directly capture the=20 > mechanics > 105 of the two-way exchange through the "Interest message" carrying = > the > 106 request, and the "Data message" carrying the response. Through = > these > 107 constructs, the protocols are heavily biased toward a pure _pull= - > 108 based_ interaction model where requests are small (carrying=20 > little or > 109 no user-supplied data other than the name of the requested data > 110 object), and responses are relatively large - up to an=20 > architecture- > 111 defined maximum transmission unit (MTU) on the order of kilobyte= s=20 > or > 112 tens of kilobytes. >=20 > 114 A number of important applications however require interaction=20 > models > 115 more complex than individual request/response interactions in th= e > 116 same direction (i.e. between the same consumer and one or more > 117 producers). Among these we identify three important classes=20 > which > 118 are the target of the proposed enhancements defined in this > 119 specification. These are described in the following paragraphs.= >=20 > 121 *Remote Method Invocation (RMI, aka RPC):* When invoking a=20 > remote > 122 method, it is common for the method to require arguments=20 > supplied > 123 by the caller. In conventional TCP/IP style protocols like=20 > CORBA > 124 or HTTP "Post", these are pushed to the server as part of the= > 125 message or messages that comprise the request. In ICN-style > 126 protocols there is an unattractive choice between inflating=20 > the > 127 request initiation with pushed arguments, or arranging to hav= e=20 > one > 128 or more independent request/responses in the opposite=20 > direction > 129 for the server to fetch the arguments. Both of these=20 > approaches > 130 have substantial disadvantages. Recently, a viable=20 > alternative > 131 emerged through the work on RICE [Krol2018] which pioneered=20 > the > 132 main design elements proposed in this specification. >=20 > 134 *Phone-Home scenario:* Applications in sensing,=20 > Internet-of-things > 135 (IoT) and other types where data is produced unpredictably an= d > 136 needs to be _pushed_ somewhere create a conundrum for the pur= e > 137 pull-based architectures considered here. If instead one=20 > eschews > 138 relaxing the size asymmetry between requests and responses,=20 > some > 139 additional protocol machinery is needed. Earlier efforts in = > the > 140 ICN community have recognized this issue and designed methods= =20 > to > 141 provoke a cooperating element to issue a request to return th= e > 142 data the originator desires to push, essentially "phoning=20 > home" to > 143 get the responder to fetch the data. One that has been=20 > explored > 144 to some extent is the _Interest-Interest-Data_ exchange > 145 [Carzaniga2011], where an Interest is sent containing the=20 > desired > 146 request as encapsulated data. CCNx-1.0 Bidirectional Streams= > 147 [Mosko2017] are also based on a scheme where an Interest is=20 > used > 148 to signal a name prefix that a consumer has registered for > 149 receiving Interests from a peer in a bidirectional streaming > 150 session. >=20 > 152 *Peer state synchronization:* A large class of applications, > 153 typified by those built on top of on reliable order-preservin= g > 154 transport protocols, require initial state synchronization=20 > between > 155 the peers. This is accomplished with a three-way (or longer)= > 156 handshake, since employing a two-way handshake as provided in= =20 > the > 157 existing NDN and CCNx protocols exposes a number of well-know= > 158 hazards, such as _half-open connections_. When attempted for > 159 security-related operations such as key exchange, additional > 160 hazards such as _man-in-the-middle_ attacks become trivial to= > 161 mount. Existing alternatives, similar to those used in the=20 > two > 162 examples above, instead utilize either overlapping=20 > Interest-Data > 163 exchanges in opposite directions (resulting in a four-way > 164 handshake) or by adding initialization data to the initial=20 > request > 165 and employing an Interest-Interest-Data protocol extension as= > 166 noted in the Phone-home scenarios above. >=20 > 168 All of the above application interaction models present=20 > interesting > 169 challenges, as neither relaxing the architecture to support=20 > pushing > 170 large amounts of data, nor introducing substantial complexities > 171 through multiple independent Interest-Data exchanges is an=20 > attractive > 172 approach. The following subsections provide further background = > and > 173 justification for why push and/or independent exchanges are > 174 problematical. >=20 > 176 1.1. Problems with pushing data >=20 > 178 There are two substantial problems with the simple approach of=20 > just > 179 allowing arbitrary amounts of data to be included with requests.= > 180 These are: >=20 > 182 1. In ICN protocols, Interest messages are intended to be small= ,=20 > on > 183 the order the size of a TCP ACK, as opposed to the size of a= =20 > TCP > 184 data segment. This is because the hop-by-hop congestion=20 > control > 185 and forwarder state management requires Interest messages to= =20 > be > 186 buffered in expectation of returning data, and possibly > 187 retransmitted hop-by-hop as opposed to end-to-end. In=20 > addition, > 188 the need to create and manage state on a per-Interest basis = > is > 189 substantially complicated if requests in Interest messages=20 > are > 190 larger than a Path MTU (PMTU) and need to be fragmented=20 > hop-by- > 191 hop. >=20 > 193 2. If the payload data of a request is used for invoking a > 194 computation (as in the RMI case described above) then=20 > substantial > 195 bandwidth can be wasted if the computation is either refused= =20 > or > 196 abandoned for any number of reasons, including the requestor= > 197 failing an authorization check, or the responder not having > 198 sufficient resources to execute the associated computation. >=20 > 200 These problems also exist in pure datagram transport protocols=20 > such > 201 as those used for legacy RMI applications like NFS [RFC7530]. =20 > More > 202 usual are application protocols like HTTP(s) which rely on the=20 > TCP or > 203 QUIC 3-way handshake to establish a session and then have=20 > congestion > 204 control and segmentation provided as part of the transport=20 > protocol, > 205 further allowing sessions to be rejected before large amounts of= =20 > data > 206 are transmitted or significant computational resources expended.= >=20 > 208 1.2. Problems with utilizing independent exchanges >=20 > 210 In order to either complete a three-way handshake, or fetch data= =20 > via > 211 a pull from the original requestor, the role of consumer and=20 > producer > 212 need to be reversed and an Interest/Data exchange initiated in=20 > the > 213 direction opposite of the initiating exchange. When done with a= n > 214 independent Interest/Data request and response, a number of > 215 complications ensue. Among them are: >=20 > 217 1. The originating consumer needs to have a routable name prefi= x > 218 that can be used for the exchange. This means the consumer = > must > 219 arrange to have its name prefix propagated in the ICN routin= g > 220 system with sufficient reach that the producer issuing the > 221 interest can be assured it is routed appropriately. While=20 > some > 222 consumers are generally online and act as application=20 > servers, > 223 justifying the maintenance of this routing information, many= =20 > do > 224 not. Further, in mobile environments, a pure consumer that = > does > 225 not need to have a routable name prefix can benefit from the= > 226 inherent consumer mobility support in the CCNx and NDN=20 > protocols. > 227 By requiring a routable name prefix, extra mobile routing > 228 machinery is needed, such as that proposed in KITE=20 > [Zhang2018] or > 229 MAPME [Auge2018]. >=20 > 231 2. The consumer name prefix in item (1) above must be=20 > communicated > 232 to the producer as a payload, name suffix, or other field of= =20 > the > 233 initiating Interest message. Since this name in its entiret= y=20 > is > 234 chosen by the consumer, it is highly problematic from a=20 > security > 235 standpoint, as it can recruit the producer to mount a=20 > reflection > 236 attack against the consumer's chosen victim. >=20 > 238 3. The correlation between the exchanges in opposite directions= =20 > must > 239 be maintained by both the consumer and the producer as > 240 independent state, as opposed to being architecturally tied > 241 together as would be the case with a conventional 3-way=20 > handshake > 242 finite state machine. While this can of course be=20 > accomplished > 243 with care by both parties, experience has shown that it is=20 > error > 244 prone (for example see the checkered history of interactions= > 245 between the SIP [RFC3261] and SDP Offer-Answer [RFC6337]) > 246 protocols. When employed as the wrapper for a key managemen= t > 247 protocol such as with TLS [RFC8446] state management errors = > can > 248 be catastrophic for security. >=20 > 250 2. Requirements Language >=20 > 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL=20 > NOT", > 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",= =20 > and > 254 "OPTIONAL" in this document are to be interpreted as described i= n > 255 [RFC2119]. >=20 > 257 3. Overview of the Reflexive Forwarding design >=20 > 259 This specification defines a _Reflexive Forwarding_ extension to= =20 > CCNx > 260 and NDN that avoids the problems enumerated in Sections 1.1 and = > 1.2. > 261 It straightforwardly exploits the hop-by-hop state and symmetric= > 262 routing properties of the current protocols. >=20 > 264 Figure 1 below illustrates a canonical NDN/CCNx forwarder with=20 > its > 265 conceptual data structures of the Content Store (CS), Pending > 266 Interest Table (PIT) and Forwarding Information Base (FIB). The= =20 > key > 267 observation involves the relation between the PIT and the FIB. = > Upon > 268 arrival of an Interest, a PIT entry is created which contains=20 > state > 269 recording the incoming interface on which the Interest. If the > 270 Interest is not immediately satisfied by cached data in the CS, = > the > 271 forwarder looks up the name in the FIB to ascertain the=20 > _next-hop_ to > 272 propagate the Interest onward upstream toward the named producer= =2E > 273 Therefore, a chain of forwarding state is established during=20 > Interest > 274 forwarding that couples the PIT entries of the chain of=20 > forwarders > 275 together conceptually as _breadcrumbs_. These are used to forwar= d=20 > the > 276 returning Data Message over the inverse path through the chain o= f > 277 forwarders until the Data message arrives at the originating > 278 consumer. The state in the PITs is _unwound_ by destroying it a= s > 279 each PIT entry is _satisfied_. This behavior is *critical* to th= e > 280 feasibility of the reflexive forwarding design we propose. >=20 > 282 =20 > +-----------------------------------------------------------------+ > 283 | ICN Node= =20 > | > 284 | Send data to all =3D=3D=3D= =3D=3D=3D=3D=3D =20 > | > 285 | interfaces that = =20 > | > 286 | requested it = =20 > | > 287 | YES +------------------+ = =20 > | > 288 <------------------------| Pending Interest | =20 > <--------------------- > 289 | | | Table (PIT) | Data = =20 > | > 290 | | +------------------+ 1) Find =20 > (Signed) | > 291 | | 2) Save | Name = =20 > | > 292 | V Data | NO in = =20 > | > 293 | +---------------+ | PIT? = =20 > | > 294 | | Content Store | | = =20 > | > 295 | | (CS) | | = =20 > | > 296 | +---------------+ | = =20 > | > 297 | | = =20 > | > 298 | V = =20 > | > 299 | Drop Data = =20 > | > 300 | = =20 > | > 301 =20 > +-----------------------------------------------------------------+ > 302 =20 > +-----------------------------------------------------------------+ > 303 | ICN Node= =20 > | > 304 | =3D=3D=3D= =3D=3D=3D=3D=3D =20 > | > 305 | = =20 > | > 306 | =20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+| > 307 | |Forwarding Strateg= y=20 > || > 308 | =20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+| > 309 | = =20 > | > 310 | 1) Find name 2) Matching 3) Find matching = =20 > | > 311 | in CS? name in PIT? entry in FIB? = =20 > | > 312 | NO NO = > YES| > 313 | +---------------+ +----------------+ =20 > +-------------------+ | > 314 | | Content Store | | Pending | | Forwarding = =20 > | | > 315 --->| (CS) |-->| Interest |-->| Information Base= =20 > |--> > 316 | | | | Table (PIT) | | ( FIB) = =20 > | | > 317 | +---------------+ +----------------+ =20 > +-------------------+ | > 318 | Return | YES YES | NO NO | = =20 > | > 319 | Data | Add | Add | Drop = =20 > | > 320 | | Incoming | new | or = =20 > | > 321 | <------| Itf. | Interest | NACK = =20 > | > 322 | V V = =20 > | > 323 | = =20 > | > 324 =20 > +-----------------------------------------------------------------+ >=20 > 326 Figure 1: ICN forwarder structure >=20 > 328 Given the above forwarding properties for Interests, it should b= e > 329 clear that while an Interest is outstanding and ultimately=20 > arrives at > 330 a producer who can respond to it, there is sufficient state in=20 > the > 331 chain of forwarders to route not just a returning Data message, = > but > 332 potentially another Interest directed through the inverse path t= o=20 > the > 333 unique consumer who issued the original Interest. (Section 8.1.= 3 > 334 describes how Interest aggregation interacts with this scheme.) = =20 > The > 335 key question therefore is how to access this state in a way that= =20 > it > 336 can be used to forward Interests. >=20 > 338 In order to achieve this _Reflexive Interest_ forwarding on the > 339 inverse path recorded in the PIT of each forwarder, we need a fe= w > 340 critical design elements. These are as follows: >=20 > 342 1. The Reflexive Interest needs to have a Name. This name is=20 > what > 343 the originating consumer will use to match against the Data > 344 object (or objects - more on this later) it wishes the=20 > producer > 345 to fetch by issuing the Reflexive Interest. This cannot be = > just > 346 any name, but needs to essentially name the state already > 347 recorded in the PIT and not allow the consumer to manufactur= e=20 > an > 348 arbitrary name and mount a reflection attack as pointed out = > in > 349 Section 1.2, Paragraph 2, Item 2. >=20 > 351 2. There has to be a FIB entry at each forwarder for this name > 352 prefix so that when the reflexive interest arrives, the=20 > forwarder > 353 can forward it downstream toward the originating consumer. = > This > 354 FIB entry points directly to the incoming interface on which= =20 > the > 355 corresponding original Interest arrived. The FIB entry need= s=20 > to > 356 be created as part of the forwarding of the original Interes= t=20 > so > 357 that it is available in time to catch any reflexive Interest= > 358 issued by the producer. It usually makes sense to destroy=20 > this > 359 FIB entry when the Data message satisfying the original=20 > Interest > 360 arrives since this avoids any dangling stale state. Given=20 > the > 361 deign details documented later in this specification, stale = > FIB > 362 state does not represent a correctness hazard and hence can = > be > 363 done lazily if desired in an implementation. See Section 5 = > for > 364 more details on FIB operation considerations. >=20 > 366 3. There has to be coupling of the state between the originatin= g > 367 Interest-Data exchange and the enclosed Reflexive=20 > Interest-Data > 368 exchange at both the consumer and the producer. In our=20 > design, > 369 this accomplished by the way reflexive interest names are=20 > chosen. >=20 > 371 The following sections provide the normative details on each of = > these > 372 design elements. The overall interaction flow for reflexive > 373 forwarding is illustrated below in Figure 2. >=20 > 375 +-----------+ +-----------+ +-----------+ > 376 | Consumer | | Forwarder | | Producer | > 377 +-----------+ +-----------+ +-----------+ > 378 | | | > 379 | I1 | | > 380 |--------------->| | > 381 |--------------\ | | > 382 || Install RNP |-| | > 383 || in FIB | | | > 384 ||-------------| | | > 385 | | | > 386 | | I1 | > 387 | |----------------------------->| > 388 | | |=20 > -----------\ > 389 | | |-| Create= =20 > | > 390 | | | | RI=20 > state | > 391 | | |=20 > |----------| > 392 | | | > 393 | | RI | > 394 | |<-----------------------------| > 395 | | --------------------\ | > 396 | |-| lookup RNP in FIB | | > 397 | | |-------------------| | > 398 | | | > 399 | RI | | > 400 |<---------------| | > 401 | | | > 402 | D2 | | > 403 |--------------->| | > 404 | | | > 405 | | D2 | > 406 | |----------------------------->| > 407 | | |=20 > ------------\ > 408 | | |-| answer= =20 > I1 | > 409 | | |=20 > |-----------| > 410 | | | > 411 | | D1 | > 412 | |<-----------------------------| > 413 | | -----------------------\ | > 414 | |-| remove RNP FIB entry | | > 415 | | |----------------------| | > 416 | | | > 417 | D1 | | > 418 |<---------------| | > 419 | | | >=20 > 421 Legend: > 422 I1: Interest #1 containing the Reflexive Name Prefix TLV > 423 RI: Reflexive Interest with Reflexive Name Prefix Component > 424 RNP: Reflexive Name Prefix > 425 D1: Data message, answering initiating I1 Interest > 426 D2: Data message, answering RI >=20 > 428 Figure 2: Message Flow Overview >=20 > 430 4. Naming of Reflexive Interests >=20 > 432 A consumer may have one or more objects for the producer to=20 > fetch, > 433 and therefore needs to communicate enough information in their > 434 initial Interest to allow the producer to construct properly=20 > formed > 435 reflexive Interest names. For some applications the set of _ful= l > 436 names_ (see [I-D.irtf-icnrg-terminology]) is known a priori, for= > 437 example through compile time bindings of arguments in interface > 438 definitions or by the architectural definition of a simple senso= r > 439 reading. In other cases the full names of the individual object= s > 440 must be communicated in the original Interest message. In all=20 > cases > 441 enough state must be provided by the consumer for the forwarders= =20 > to > 442 construct a FIB entry (as noted in Section 3, Paragraph 6, Item = > 2). > 443 This is accomplished through the following naming construct. >=20 > 445 We define a new typed name component, identified by a registered= =20 > name > 446 component type in the IANA registry for [RFC8569]. We call this= =20 > the > 447 _Reflexive Interest Name Component type_. It MUST be the first=20 > (i.e. > 448 high order) name component of any Reflexive Interest issued by a= > 449 producer. Its value is a random 64 bit number, assigned by the > 450 consumer, which provides the entropy required to uniquely=20 > identify > 451 the issuing consumer for the duration of any outstanding=20 > Interest- > 452 Data exchange. The consumer SHOULD choose a different random=20 > value > 453 for each Interest message it constructs, for two reasons: >=20 > 455 1. If stale FIB sate is present, the randomness prevents=20 > potential > 456 mis-routing of reflexive interests (see Section 8.1.1 below = > for > 457 more details), and >=20 > 459 2. Re-use of the same reflexive interest name over multiple > 460 interactions might reveal linkability information that could= =20 > be > 461 used by surveillance adversaries for tracking purposes. >=20 > 463 This initial name component is either communicated by itself=20 > through > 464 a _Reflexive Name Prefix TLV_ in the originating Interest, or > 465 prepended to any object names the consumer wishes the producer t= o > 466 fetch explicitly where there is more than one object needed by=20 > the > 467 producer for the current Interest-Data interaction. There are=20 > four > 468 cases to consider: >=20 > 470 1. The reflexive _fullname_ of a single object to fetch. >=20 > 472 2. A single reflexive name prefix out of which the producer can= =20 > (by > 473 application-specific means) construct a number of _fullnames= _=20 > of > 474 the objects it may want to fetch, >=20 > 476 3. The reflexive _fullname_ of a FLIC Manifest=20 > [I-D.irtf-icnrg-flic] > 477 enumerating the suffixes that may be used by the producer to= > 478 construct the necessary names, >=20 > 480 4. Multiple reflexive name TLVs MAY be included in the Interest= > 481 message if none of the above 3 options covers the desired us= e > 482 case. >=20 > 484 The last of the four options above, while not explicitly=20 > outlawed, > 485 SHOULD NOT be used. This is because it results in a longer=20 > Interest > 486 message and requires extra FIB resources. Hence, it is more=20 > likely a > 487 forwarder will reject the Interest for lack of resources. A > 488 forwarder MAY optimize for the case of a single Reflexive Name=20 > TLV at > 489 the expense of those with more than one. >=20 > 491 A producer, upon receiving an Interest with one or more Reflexiv= e > 492 Name TLVs, may decide it needs the pull the associated data > 493 object(s). It therefore can issue one or more Reflexive=20 > Interests by > 494 appending the necessary name components needed to form valid ful= l > 495 names of the associated objects present at the originating=20 > consumer. > 496 These in fact comprise conventional Interest-Data exchanges, wit= h=20 > no > 497 alteration of the usual semantics with regard to signatures,=20 > caching, > 498 expiration, etc. When the producer has retrieved the required > 499 objects to complete the original Interest-Data exchange, it can = > issue > 500 its Data response, which unwinds all the established state at th= e > 501 producer, the consumer, and the intermediate forwarders. >=20 > 503 5. Forwarder operation for Reflexive Interests >=20 > 505 The forwarder operation for CCNx and/or NDN is changed in three > 506 respects when supporting Reflexive Interests. >=20 > 508 1. The forwarder MUST create short-lifetime FIB entries for any= > 509 Reflexive Interest Name prefixes communicated in an Interest= > 510 message. If the forwarder does not have sufficient resource= s=20 > to > 511 do so, it MUST reject the Interest with the=20 > T_RETURN_NO_RESOURCES > 512 error - the same error used if the forwarder were lacking > 513 sufficient PIT resources to process the Interest message. >=20 > 515 2. Those FIB entries MUST be queried whenever an Interest=20 > message > 516 arrives whose first name component is of the type _Reflexive= > 517 Interest Name Component_ >=20 > 519 3. The FIB entry MUST be removed eventually, after the=20 > corresponding > 520 Data message has been forwarded. One option would be to=20 > remove > 521 the FIB directly after the Data message has been forwarded. > 522 However, the forwarder MAY do lazy cleanup. >=20 > 524 The PIT entry for the Reflexive Interest is consumed per regular= > 525 Interest/Data message forwarding requirements. The PIT entry fo= r=20 > the > 526 originating Interest (that communicated the Reflexive Interest=20 > Name) > 527 is also consumed by a final Data message from the producer to th= e > 528 original consumer. >=20 > 530 6. State coupling between producer and consumer >=20 > 532 A consumer that wishes to use this scheme MUST utilize one of th= e > 533 reflexive naming options defined in Section 4 and include it in = > the > 534 corresponding Interest message. The Reflexive Name TLV _and_ th= e > 535 full name of the requested data object (that identifies the=20 > producer) > 536 identify the common state shared by the consumer and the=20 > producer. > 537 When the producer responds by sending Interests with the=20 > Reflexive > 538 Name Prefix, the original consumer therefore has sufficient > 539 information to map these Interests to the ongoing Interest-Data > 540 exchange. >=20 > 542 The exchange is finished when the producer who received the=20 > original > 543 Interest message responds with a Data message (or an Interest=20 > Return > 544 message in the case of error) answering the original Interest. = > After > 545 sending this Data message, the producer SHOULD destroy the > 546 corresponding shared state. It MAY decide to use a timer that=20 > will > 547 trigger a later state destruction. After receiving this Data > 548 message, the originating consumer MUST destroy the corresponding= > 549 Interest-Data exchange state. >=20 > 551 7. Use cases for Reflexive Interests >=20 > 553 7.1. Achieving Remote Method Invocation with Reflexive Interests >=20 > 555 RICE (Remote Method Invocation in ICN) [Krol2018] uses the=20 > Reflexive > 556 Interest Forwarding scheme that inspired the design specified in= =20 > this > 557 document. >=20 > 559 In RICE, the original Interest denotes the remote method (plus > 560 potential parameters) to be invoked at a producer (server). =20 > Before > 561 committing any computating resources, the server can then reques= t > 562 authentication credentials and (optional) parameters using=20 > reflexive > 563 Interest-Data exchanges. >=20 > 565 When the server has obtained the necessary credentials and input= > 566 parameters, it can decide to commit computing resources, starts = > the > 567 compute process, and returns a handle ("Thunk") in the final Dat= a > 568 message to the original consumer (client). >=20 > 570 The client would later request the computation results using a > 571 regular Interest-Data exchange (outside the Reflexive-Interest > 572 transaction) -- using the Thunk as a name for the computation=20 > result. >=20 > 574 Figure 3 depicts an abstract message diagram for RICE. In=20 > addition > 575 to the 4-way Reflexive Forwarding Handshake (see Figure 2 for th= e > 576 details of the interaction), RICE adds another (standard) ICN > 577 Interest/Data exchange for transmitting the RMI result. The=20 > Thunk > 578 name is provided to the consumer in the D1 DATA message=20 > (answering > 579 the initial I1 Interest). >=20 > 581 +-----------+ +-----------+ > 582 | Consumer | | Producer | > 583 +-----------+ +-----------+ > 584 | | > 585 | I1 | > 586 |------------------------->| > 587 | | ---------------------\ > 588 | |-| Requesting request | > 589 | | | parameters | > 590 | | | and credentials | > 591 | | |--------------------| > 592 | | > 593 | RI | > 594 |<-------------------------| > 595 | | > 596 | D2 | > 597 |------------------------->| > 598 | | --------------------\ > 599 | |-| Commit compute | > 600 | | | resources, | > 601 | | | return Thunk name | > 602 | | |-------------------| > 603 | | > 604 | D1 | > 605 |<-------------------------| > 606 | | ----------------\ > 607 | |-| Invoke Remote | > 608 | | | Method | > 609 | | |---------------| > 610 | -------------------\ | > 611 |-| After some time, | | > 612 | | request result | | > 613 | |------------------| | > 614 | | > 615 | I3 | > 616 |------------------------->| > 617 | | > 618 | D3 | > 619 |<-------------------------| > 620 | | > 621 Legend: > 622 I1: Interest #1 containing the Reflexive Name Prefix TLV > 623 D1: Data message, answering initiating I1 Interest, > 624 returning Thunk name > 625 D2: Data message, answering RI (parameters, credentials) > 626 I3: Regular Interest for Thunk (compute result) > 627 D3: Data message, answering I3 > 628 Figure 3: RICE Message Flow >=20 > 630 7.2. RESTful Web Interactions >=20 > 632 In todays HTTP-based web, RESTful (Representational State=20 > Transfer) > 633 web interactions are realized by sending requests in a=20 > client/server > 634 interaction, where the requests provides the application context= =20 > (or > 635 a reference to it). It has been noted in [Moiseenko2014] that > 636 corresponding requests often exceed the response messages in=20 > size, > 637 and that this raises the problems noted in Section 1.1 when > 638 attempting to map such exchanges directly to CCNx/NDN. >=20 > 640 Another reason not to include all request parameters in a=20 > (possibly > 641 encrypted) Interest message is the fact that a server (that is > 642 serving thousands of clients) would be obliged to receive,=20 > possibly > 643 decrypt and parse the complete requests before being able to > 644 determine whether the requestor is authorized, whether the=20 > request > 645 can be served etc. Many non-trivial requests could thus lead to= > 646 computational overload attacks. >=20 > 648 Using Reflexive Interest Forwarding for RESTful Web Interactions= > 649 would encode the REST request in the Original request, together = > with > 650 a Reflexive Interest Prefix that the server could then use to ge= t > 651 back to the client for authentication credentials and request > 652 parameters, such as cookies. The request result (response=20 > message) > 653 could either be transmitted in the Data message answering the > 654 original request, or -- in case of dynamic, longer-running > 655 computations -- in a seperate Interest/Data exchange, potentiall= y > 656 leveraging the Thunk scheme described in section Section 7.1. >=20 > 658 Unlike approaches where clients have to signal a globally=20 > routable > 659 prefix to the network, this approach would not require the clien= t > 660 (original consumer) to expose its identity to the network (the > 661 network only sees the temporary Reflexive Name Prefix), but it=20 > would > 662 still be possible to authenticate the client at the server. >=20 > 664 7.3. Achieving simple data pull from consumers with reflexive=20 > Interests >=20 > 666 An oft-cited use case for ICN network architectures is _Internet= =20 > of > 667 Things_ (IoT), where the sources of data are limited-resource=20 > sensor/ > 668 actuators. Many approaches have been tried (e.g. =20 > [Baccelli2014], > 669 [Lindgren2016], [Gundogan2018]) with varying degrees of success = > in > 670 addressing the issues outlined in Section 1.1. The reflexive > 671 forwarding extension may substantially ameliorate the documented= > 672 difficulties by allowing a different model for the basic=20 > interaction > 673 of sensors with the ICN network. >=20 > 675 Instead of acting as a producer (either directly to the Internet= =20 > or > 676 indirectly through the use of some form of application-layer > 677 gateway), the IoT device need only act as a consumer. When it=20 > has > 678 data to provide, it issues a "phone-home" Interest message to a = > pre- > 679 configured rendezvous name (e.g. an application-layer gateway or= =20 > ICN > 680 Repo [Chen2015]) and provides a reflexive name prefix TLV for th= e > 681 data it wishes to publish. The target producer may then issue=20 > the > 682 necessary reflexive Interest message(s) to fetch the data. Once= > 683 fetched, validated, and stored, the producer then responds to th= e > 684 original Interest message with a success indication, possibly > 685 containing a Data object if needed to allow the originating=20 > device to > 686 modify its internal state. Alternatively, the producer might=20 > choose > 687 to not respond and allow the original Interest to time out,=20 > although > 688 this is NOT RECOMMENDED except in cases where the extra message > 689 transmission bandwith is at a premium compared to the persistenc= e=20 > of > 690 stale state in the forwarders. We note that this interaction > 691 approach mirrors the earlier efforts using Interest-Interest-Dat= a > 692 designs. >=20 > 694 Figure 4 depicts this interaction with the OPTIONAL D1 message. = =20 > See > 695 Figure 2 for the details of the general Reflexive Forwarding > 696 interaction. >=20 > 698 +-----------+ +-----------+ > 699 | Consumer | | Producer | > 700 +-----------+ +-----------+ > 701 ------------\ | | > 702 | new IoT |-| | > 703 | data item | | | > 704 | produced | | | > 705 |-----------| | | > 706 ---------------\ | | > 707 | "phone home" |-| | > 708 | by notifying | | | > 709 | producer | | | > 710 |--------------| | | > 711 | | > 712 | I1 | > 713 |------------>| > 714 | | --------------------\ > 715 | |-| generate Interest | > 716 | | | for IoT data | > 717 | | |-------------------| > 718 | | > 719 | RI | > 720 |<------------| > 721 -----------------\ | | > 722 | send requested |-| | > 723 | data object | | | > 724 |----------------| | | > 725 | | > 726 | D2 | > 727 |------------>| > 728 | | -----------------------\ > 729 | |-| finalize interaction | > 730 | | | with optional | > 731 | | | Data message | > 732 | | |----------------------| > 733 | | > 734 | D1 | > 735 |<------------| > 736 | | > 737 Legend: > 738 I1: Interest #1 containing the Reflexive Name Prefix TLV > 739 D1: Data message (OPTIONAL), finalizing interaction > 740 D1: Data message, answering RI, returning IoT data object >=20 > 742 Figure 4: "Phone Home" Message Flow >=20 > 744 There are two approaches that the IoT device can use for its=20 > response > 745 to a reflexive Interest. It can simply construct a Data Message= > 746 bound through the usual ICN hash name to the reflexive Interest = > name. > 747 Since the scope of any data object bound in this way is only the= > 748 duration of the enclosing Interest-Data exchange (see Section=20 > 8.2) > 749 the producer would need to itself construct any persistent Data > 750 object, name it, and sign it. This is sometimes the right=20 > approach, > 751 as for some applications the identity of the originating IoT=20 > device > 752 is not important from an operational or security point of view; = > in > 753 contrast the identity of the gateway or Repo is what matters. >=20 > 755 If alternatively, the persistent Data object should be bound fro= m=20 > a > 756 naming and security point of view to the originating IoT device,= =20 > this > 757 can be easily accomplished. Instead of directly placing the=20 > content > 758 in a Data object responding to the reflexive Interest as above, = > the > 759 consumer encapsulates a complete CCNx/NDN Data message (which > 760 includes the desired name of the data) as in the response to the= > 761 reflexive Interest message. >=20 > 763 The interaction model described above brings a number potential > 764 advantages, some obvious, some less so. We enumerate a few of=20 > them > 765 as follows: >=20 > 767 * By not requiring the IoT device to be actively listening for > 768 Interests, it can sleep and only wake up if it has something = > to > 769 communicate. Conversely, parties interested in obtaining dat= a > 770 from the device do not need to be constantly polling in order= =20 > to > 771 ascertain if there is new data available. >=20 > 773 * No forwarder resources are tied up with state apart from the > 774 actual reflexive forwarding interactions. All that is needed= =20 > is > 775 enough routing state in the FIB to be able to forward the=20 > "phone > 776 home" Interest to an appropriate target producer. While this= > 777 model does not provide all the richness of a full Pub/Sub=20 > system > 778 (like that described in [Gundogan2018]) we argue it is=20 > adequate > 779 for a large subclass of such applications. >=20 > 781 * The reflexive interest, through either a name suffix or=20 > Interest > 782 payload, can give the IoT device useful context from which to= > 783 craft its Data object in response. One highly useful=20 > parameter > 784 would be a robust clock value for the device to use as a=20 > timestamp > 785 of the data, possibly as part of its name to correctly place = > it in > 786 a time seres of sensor readings. This substantially=20 > alleviates > 787 the need for low-end devices to have a robust time base, as=20 > long > 788 as they trust the producer they contact to provide it. >=20 > 790 8. Implementation Considerations >=20 > 792 There are a number of important aspects to the reflexive=20 > forwarding > 793 design which affect correctness and performance of existing > 794 forwarder, consumer, and producer implementations desiring to=20 > support > 795 it. This section discusses the effect on each of these elements= =20 > of > 796 the CCNx/NDN protocol architecture. >=20 > 798 8.1. Forwarder implementation considerations >=20 > 800 8.1.1. Forwarding Information Base (FIB) >=20 > 802 The FIB is a performance-critical data structure in any=20 > forwarder, as > 803 it needs to support relatively expensive longest name prefix=20 > match > 804 (LNPM) lookup algorithms. A number of well-known FIB data=20 > structures > 805 are heavily optimized for read access, since for normal Interest= > 806 message processing the FIB changes slowly - only after=20 > topological > 807 changes or routing protocol updates. Support for reflexive name= s > 808 changes this, as FIB entries are created and destroyed rapidly a= s > 809 Interest messages containing reflexive name TLVs are processed=20 > and > 810 the corresponding Data messages come back. >=20 > 812 While it may be feasible, especially in low-end forwarders=20 > handling a > 813 low packet forwarding rate to ignore this problem, for high-spee= d > 814 forwarders there are a number of hazards, including: >=20 > 816 1. If the entire FIB needs to be locked in order to insert or=20 > remove > 817 entries, this could cause inflated forwarding delays or in > 818 extreme cases, forwarding performance collapse. >=20 > 820 2. A number of high-speed forwarder implementations employ a=20 > sharded > 821 PIT scheme to better parallelize forwarding across processin= g > 822 cores. The FIB, however, is still a shared data structure=20 > which > 823 is either read without read locks across cores, or explicitl= y > 824 copied such that there is a separate copy of the FIB for eac= h=20 > PIT > 825 shard. Clearly, a high update rate without read locks and/o= r > 826 updating many copies of the FIB are unattractive=20 > implementation > 827 options. (Note: with this reflexive name scheme it is not > 828 feasible to force reflexive interests to be hashed or be > 829 otherwise directed to the PIT shard holding the original=20 > Interest > 830 state). >=20 > 832 There are any number of alternative FIB implementations that can= =20 > work > 833 well however. The most straightforward is to simply implement a= > 834 "special" FIB for just reflexive name lookups. This is feasible= > 835 because reflexive names deterministically contain the=20 > distinguished > 836 high-order name component type of T_REFLEXIVE_NAME, whose conten= t=20 > is > 837 a 64-bit value that can be easily hashed to a FIB entry directly= , > 838 avoiding the more expensive LNPM lookup. Inserts and deletes=20 > then > 839 devolve to the well-understood problem of hash table maintenance= =2E >=20 > 841 8.1.2. Interactions with Interest Lifetime >=20 > 843 If and when a producer decides to fetch data from the consumer=20 > using > 844 one or more reflexive Interest-Data exchanges, the total latency= =20 > for > 845 the original Interest-Data exchange is inflated, potentially by > 846 multiple RTTs. It is difficult for a consumer to predict the > 847 inflation factor when issuing the original Interest, and hence=20 > there > 848 can be a substantial hazard of that Interest lifetime expiring=20 > before > 849 completion of the full multi-way exchange. This can result in > 850 persistent failures, which is obviously highly undesirable. >=20 > 852 There is a fairly straightforward technique that can be employed= =20 > by > 853 forwarders to avoid these "false" Interest lifetime expirations.= =20 > In > 854 the absence of a superior alternative technique, it is=20 > RECOMMENDED > 855 that all forwarders implement the following algorithm. >=20 > 857 When processing an Interest containing the reflexive name TLV an= d > 858 creating the necessary FIB entry (see Section 8.1.1 above), the > 859 forwarder also creates a _back pointer_ from that FIB entry to=20 > the > 860 PIT entry for the Interest message that created it. This PIT=20 > entry > 861 contains the current value of the remaining Interest lifetime or= > 862 alternatively a value from which the remaining Interest lifetime= =20 > can > 863 be easily computed. Call this value _IL_(t)_. >=20 > 865 If and when a reflexive Interest arrives from upstream matching = > the > 866 reflexive FIB entry, the forwarder examines the Interest lifetim= e=20 > of > 867 the arriving reflexive Interest. Call this value _IL_(r)_. The > 868 forwarder computes MAX(_IL_(t), (IL_(r) * 1.5)_), and replaces > 869 _IL_(t)_ with this value. This in effect ensures that the=20 > remaining > 870 Interest lifetime of the original Interest accounts for the > 871 additional 1.5 RTTs that may occur as a result of the reflexive > 872 Interest-Data exchange. >=20 > 874 If the above algorithm is implemented naively as described above= ,=20 > it > 875 may run afoul of a sharded PIT forwarder implementation, since=20 > the > 876 PIT entry for the reflexive Interest and the PIT entry for the > 877 original Interest may be in different shards. Therefore, if the= > 878 update is done cross-shard on each reflexive Interest arrival, > 879 performance may suffer, perhaps dramatically. Instead, the=20 > following > 880 approach to updating the Interest lifetime after computing the=20 > new > 881 value is RECOMMMENDED for sharded-PIT forwarders. >=20 > 883 When creating the reflexive FIB entry as above in Section 8.1.1,= =20 > copy > 884 the remaining Interest lifetime from the PIT entry. Do the PIT > 885 update if and only if this value is about to expire, thus paying= =20 > the > 886 cross-shard update cost only if the original Interest is about t= o > 887 expire. A further optimization at the cost of modest extra > 888 complexity is to instead _queue_ the update to the core holding = > the > 889 shard of the original PIT entry rather than doing the update > 890 directly. If the PIT entry expires or is satisfied, instead of > 891 removing it the associated core checks the update queue and does= =20 > the > 892 necessary update. >=20 > 894 While the above approach of inflating the interest lifetime of=20 > the > 895 original Interest to accommodate the additional RTTs of reflexiv= e > 896 Interest-Data exchanges, this does introduce a new vulnerability= =20 > that > 897 must be dealt with. A Producer, either through a bug or=20 > malicious > 898 intent, could keep an originating Interest-Data exchange alive b= y > 899 continuing to send reflexive Interests back to the consumer,=20 > while > 900 the consumer had no way to terminate the enclosing interaction=20 > (there > 901 is no "cancel Interest" function in either NDN nor CCNx). To > 902 eliminate this hazard, if the consumer rejects a reflexive=20 > interest > 903 with a T_RETURN_PROHIBITED error, the forwarder(s), in addition = > to > 904 satisfying the coresponding PIT entry, MUST also delete the > 905 associated reflexive FIB entry, thereby preventing any further > 906 reflexive Interests from reaching the consumer. This allows the= > 907 enclosing Interest-Datsa exchange to either time out or be=20 > correctly > 908 ended with a Data message or Interest Return from the Producer. >=20 > 910 8.1.3. Interactions with Interest aggregation >=20 > 912 As with numerous other situations where multiple Interests for=20 > the > 913 same named object arrive containing different parameters (e.g. > 914 Interest Lifetime, QoS, payload hash) the same phenomenon occurs= =20 > for > 915 the reflexive Name TLV. If such Interests collide, the forwarde= r > 916 MUST NOT aggregate these Interest messages and instead MUST=20 > create a > 917 separate PIT entry for each. >=20 > 919 8.2. Consumer Implementation Considerations >=20 > 921 8.2.1. Data objects returned by the consumer to reflexive name > 922 Interests arriving from a producer >=20 > 924 The Data objects returned to the producer in response to a=20 > reflexive > 925 Interest are normal CCNx/NDN data objects. It is therefore wort= h > 926 noting that the object is bound to the reflexive Interest full=20 > name > 927 via the hash and hence the scope of the object is under most > 928 circumstances meaningful only for the duration of the enclosing > 929 Interest-Data interaction. This property is ideal for naming an= d > 930 securing data that is "part of" the enclosing interaction -=20 > things > 931 like method arguments, authenticators, and key exchange=20 > parameters, > 932 but not for the creation and naming of objects intended to=20 > survive > 933 outside the current interaction's scope (c.f. Section 7.3, whic= h > 934 describes how to provide globally-named objects using=20 > encapsulation). > 935 In general, the consumer should use the following guidelines in > 936 creating Data messages in response to reflexive Interest message= s > 937 from the producer. >=20 > 939 (a) Set the recommended cache time (T_CACHETIME) either to zero= ,=20 > or > 940 a value no greater than the Interest lifetime (T_INTLIFE) o= f=20 > the > 941 original Interest messsage. >=20 > 943 (b) Set the payload type (T_PAYLDTYPE) according to the type of= > 944 object being returned (e.g. object, link, manifest) >=20 > 946 (c) Set the expiry time (T_EXPIRY) to a value greater than=20 > _now_, > 947 and less than or equal to the _now_ + Interest lifetime > 948 (T_INTLIFE) of the original Interest messsage. >=20 > 950 8.2.2. Terminating unwanted reflexive Interest exchanges >=20 > 952 A consumer may wish to stop receiving reflxive Interests due to > 953 possible erors or malicious behavior on the part of the producer= =2E > 954 Therefore, if the consumer receives an unwanted reflexive=20 > Interest, > 955 it SHOULD reject that interest with a T_RETURN_PROHIBITED error.= > 956 This will provoke the forwarders to prevent further reflexive > 957 Interests from reaching the consumer, as described above in > 958 Section 8.1.2, Paragraph 7. >=20 > 960 8.2.3. Interactions with caching >=20 > 962 The reflexive named objects provide "local", temporary names tha= t=20 > are > 963 only defined for one specific interaction between a consumer and= =20 > a > 964 producer. Corresponding Data objects MUST NOT be shared between= > 965 multiple consumers (violating this would require specail=20 > gyrations by > 966 the producer since the reflexive Name utilizes per-consumer/per-= > 967 interaction random values). A producer MUST NOT issue an=20 > Interest > 968 message for any reflexive name after it has sent the final Data > 969 message answering the original Interest. >=20 > 971 Forwarders SHOULD still cache reflexive Data objects for > 972 retransmissions within a transactions, but they MUST remove them= =20 > from > 973 the content store when they forward the final Data message=20 > answering > 974 the original Interest. >=20 > 976 8.3. Producer Implementation Considerations >=20 > 978 Producers receiving an Interest with a Reflexive Name Component,= =20 > MAY > 979 decide to issue Interests for the corresponding Data objects. =20 > All > 980 Reflexive Interest message that a producer sends MUST be sent=20 > over > 981 the face that the original Interest was received on. >=20 > 983 9. Operational Considerations >=20 > 985 This extension represents a substantial enhancement to the=20 > CCNx/NDN > 986 protocol architecture and hence has important forward and=20 > backward > 987 compatibility effects. The most important of these is that=20 > correct > 988 operation of the scheme requires an unbroken chain of forwarders= > 989 between the consumer and the desired producer that support the > 990 Reflexive Name TLV and the corresponding forwarder capabilities > 991 specified in Section 5. When this invariant is not satisfied,=20 > some > 992 means is necessary to detect and hopefully recover from the=20 > error. > 993 We have identified three possible approaches to handling the lac= k=20 > of > 994 universal deployment of forwarders supporting the reflexive > 995 forwarding scheme. >=20 > 997 The first approach simply lets the producer detect the error by > 998 getting a "no route to destination" error when trying to send an= > 999 Interest to a reflexive name. This will catch the error, but=20 > only > 1000 after forwarding resources are tied up and the producer has don= e=20 > some > 1001 work on the original Interest message. Further, the producer=20 > would > 1002 need a bit of smarts to determine that this is a permanent erro= r=20 > and > 1003 not a transient to be retried. In order for the consumer to=20 > attempt > 1004 recovery, there might be a need for some explicit error returne= d=20 > for > 1005 the original interest to tell the consumer what the likely=20 > problem > 1006 is. This approach does not enable an obvious recovery path for= =20 > the > 1007 consumer either, since while we might envision a way to steer a= > 1008 subsequent Interest onto a working path as proposed in > 1009 [I-D.oran-icnrg-pathsteering], there is no capability to force > 1010 Interest routing away from an otherwise working path not=20 > supporting > 1011 the reflexive name TLV. >=20 > 1013 A second approach is to bump the CCNx/NDN protocol version to > 1014 explicitly indicate the lack of comparability. Such Interests = > would > 1015 be rejected by forwarders not supporting this protocol=20 > extension. A > 1016 consumer wishing to use the reflexive name TLV would use the=20 > higher > 1017 protocol version on those Interest messages (but could of cours= e > 1018 continue to use the current version number on other Interest > 1019 messages). This is a big hammer, but may be called for in this= > 1020 situation because: >=20 > 1022 (a) it detects the problem immediately and deterministically, = > and >=20 > 1024 (b) one could assume an ICN routing protocol that would only=20 > forward > 1025 to a next hop that supports the updated protocol version=20 > number. > 1026 The supported forwarder protocol versions would have been > 1027 communicated in the routing protocol ahead of time. >=20 > 1029 A third option is to, as a precondition utilizing the protocol = > in a > 1030 deployment, create and deploy a neighbor capability exchange=20 > protocol > 1031 which will tell a downstream forwarder if the upstream can=20 > handle the > 1032 new TLV. This might avoid the large hammer of updating the=20 > protocol > 1033 version, but of course this puts a pretty strong dependency on > 1034 somebody actually designing and publishing such a protocol! On= =20 > the > 1035 other hand, a neighbor capability exchange protocol for CCNx/ND= N > 1036 would have a number of other substantial benefits, which makes = > it > 1037 worth seriously considering anyway. >=20 > 1039 10. Mapping to CCNx and NDN packet encodings >=20 > 1041 10.1. Packet encoding for CCNx >=20 > 1043 For CCNx[RFC8569] there is one new Name Component TLV type=20 > defined in > 1044 this specification. >=20 > 1046 =20 > +------------------+----------------+--------------------------+ > 1047 | Abbrev | Name | Description = =20 > | > 1048 =20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > 1049 | T_REFLEXIVE_NAME | Reflexive Name | Name component to use a= s=20 > | > 1050 | | Component | name prefix in Reflexiv= e=20 > | > 1051 | | | Interest Message = =20 > | > 1052 =20 > +------------------+----------------+--------------------------+ >=20 > 1054 Table 1: Reflexive Name TLV >=20 > 1056 10.2. Packet encoding for NDN >=20 > 1058 TBD based on [NDNTLV]. Suggestions from the NDN team greatly > 1059 appreciated. >=20 > 1061 11. IANA Considerations >=20 > 1063 Please add the T_REFLEXIVE_NAME component TLV to the CCNx Name = > types > 1064 TLV types registry of [RFC8609], with Length 9 bytes and type o= f=20 > 64 > 1065 bit random integer. >=20 > 1067 1 2 3 > 1068 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 > 1069 =20 > +---------------+---------------+---------------+---------------+ > 1070 | T_REFLEXIVE_NAME | 8 = =20 > | > 1071 =20 > +---------------+---------------+---------------+---------------+ > 1072 | = =20 > | > 1073 | 64bit Integer randomly assigned by consumer = =20 > | > 1074 =20 > +-------------------------------+-------------------------------+ >=20 > 1076 Figure 5: Reflexive Name component type >=20 > 1078 12. Security Considerations >=20 > 1080 One of the major motivations for the reflexive forwarding=20 > extension > 1081 specified in this document is in fact to enable better security= =20 > and > 1082 privacy characteristics for ICN networks. The main=20 > considerations > 1083 are presented in Section 1, but we briefly recapitulate them=20 > here: >=20 > 1085 * Current approaches to authentication and data transfer often= =20 > use > 1086 payloads in Interest messages, which are clumsy to secure > 1087 (Interest messages must be signed) and as a consequence make= =20 > it > 1088 very difficult to ensure consumer privacy. Reflexive=20 > forwarding > 1089 moves all sensitive data to the Data messages sent in=20 > response to > 1090 reflexive Interests, which are secured in the same manner as= =20 > all > 1091 other Data messages in the CCNx and NDN protocol designs. >=20 > 1093 * In many scenarios, consumers are forced to also act as=20 > producers > 1094 so that data may be fetched by either a particular, or=20 > arbitrary > 1095 other party. The means the consumer must arrange to have a > 1096 routable name prefix and that prefix be disseminated by the > 1097 routing protocol or other means. This represents both a=20 > privacy > 1098 hazard (by revealing possible important information about th= e > 1099 consumer) and a security concern as it opens up the consumer= =20 > to > 1100 the full panoply of flooding and crafted Interest denial of > 1101 service attacks. >=20 > 1103 * In order to achieve multi-way handshakes, in current designs= =20 > a > 1104 consumer wishing a producer to communicate back must inform = > the > 1105 producer of what (globally routable) name to use. This give= s=20 > the > 1106 consumer a convenient means to mount a variety of reflection= > 1107 attacks by enlisting the producer to send Interests to=20 > desired > 1108 victims. >=20 > 1110 As a major protocol extension however, this design brings its=20 > own > 1111 potential security issues, which are discussed in the following= > 1112 subsections. >=20 > 1114 12.1. Collisions of reflexive Interest names >=20 > 1116 Reflexive Interest names are constructed using 64-bit random=20 > numbers. > 1117 This is intended to ensure an off-path attacker cannot easily > 1118 manufacture a matching reflexive Interest and either masquerade= =20 > as > 1119 the producer, or mount a denial of service attack on the=20 > consumer. > 1120 It also limits tracking through the linkability of Interests > 1121 containing a re-used random value. >=20 > 1123 Therefore consumers MUST utilize a robust means of generating=20 > these > 1124 random values, and it is RECOMMENDED that a pseudo-random numbe= r > 1125 generator (PRNG) approved for use with cryptographic protocols = > be > 1126 employed. >=20 > 1128 12.2. Additional resource pressure on PIT and FIB >=20 > 1130 Normal Interest message processing in CCNx and NDN needs to=20 > consider > 1131 effect of various resource depletion attacks on the PIT,=20 > particularly > 1132 in the form of Interest flooding attacks (see [Gasti2012] for a= =20 > good > 1133 overview of DoS and DDoS mitigation on ICN networks). Interest= > 1134 messages utilizing this reflexive forwarding extension can plac= e > 1135 additional resource pressure on the PIT, and additionally cause= > 1136 otherwise stable FIB resources to be subject to highly dynamic = > usage. >=20 > 1138 While this does not represent a new DoS/DDoS attack vector, the= > 1139 ability of a malicious consumer to utilize this extension in an= > 1140 attack does represent an increased risk of resource depletion, > 1141 especially if such Interests are given unfair access to PIT and= =20 > FIB > 1142 resources. Implementers SHOULD therefore protect PIT and FIB > 1143 resources by weighing requests for reflexive forwarding=20 > resources > 1144 appropriately relative to other Interests. >=20 > 1146 12.3. Privacy Considerations >=20 > 1148 ICN architectures like CCNx and NDN provide a rich tapestry of > 1149 interesting privacy issues, which have been extensively explore= d=20 > in > 1150 the research literature. The fundamental tradeoffs for privacy= > 1151 concern the risk of exposing the names of information objects t= o=20 > the > 1152 forwarding elements of the network, which is a necessary=20 > property of > 1153 any name-based routing and forwarding design. Numerous=20 > approaches > 1154 have been explored with varying degrees of success, such as=20 > onion > 1155 routing ([DiBenedettoGTU12]), name encryption ([Ghali2017]), an= d=20 > name > 1156 obfuscation ([Arianfar2011]) among others. >=20 > 1158 Reflexive forwarding does not change the overall landscape of=20 > privacy > 1159 tradeoffs, nor seem to introduce additional hazards. In fact, = > the > 1160 privacy exposures are confined to the inverse path of forwarder= s=20 > from > 1161 the producer to the consumer, through which the original=20 > Interest > 1162 forwarding may have already exposed names on path. Similar nam= e > 1163 privacy techniques to those cited above may be equally applied = > to the > 1164 names in reflexive Interests. >=20 > 1166 While the individual reflexive Interest-Data exchanges have=20 > similar > 1167 properties to those in any NDN or CCNx exchange, the target=20 > usages by > 1168 applications may have interaction patterns that are subject to > 1169 relatively straightforward fingerprinting by adversaries. For > 1170 example, a particular RMI invocation may fingerprint simply=20 > through > 1171 the count of arguments fetched by the producer and their sizes.= =20 > The > 1172 attacker must however be on path, which somewhat ameliorates th= e > 1173 exposure hazards. >=20 > 1175 13. Normative References >=20 > 1177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > 1178 Requirement Levels", BCP 14, RFC 2119, > 1179 DOI 10.17487/RFC2119, March 1997, > 1180 . >=20 > 1182 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric > 1183 Networking (CCNx) Semantics", RFC 8569, > 1184 DOI 10.17487/RFC8569, July 2019, > 1185 . >=20 > 1187 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric > 1188 Networking (CCNx) Messages in TLV Format", RFC 8609,= > 1189 DOI 10.17487/RFC8609, July 2019, > 1190 . >=20 > 1192 14. Informative References >=20 > 1194 [Arianfar2011] > 1195 Arianfar, S., Koponen, T., Raghavan, B., and S.=20 > Shenker, > 1196 "On preserving privacy in content-oriented networks,= =20 > in > 1197 ICN '11: Proceedings of the ACM SIGCOMM workshop on > 1198 Information-centric networking", > 1199 DOI https://doi.org/10.1145/2018584.2018589, August = > 2011, > 1200 . >=20 > 1202 [Auge2018] Aug=C3=A9, J., Carofiglio, G., Grassi, G., Muscariel= lo,=20 > L., > 1203 Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less > 1204 Producer Mobility in Content-Centric Networks, in=20 > IEEE > 1205 Transactions on Network, Volume 15, Issue 2", > 1206 DOI 10.1109/TNSM.2018.2796720, June 2018, > 1207 . >=20 > 1209 [Baccelli2014] > 1210 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and= =20 > M. > 1211 W=C3=A4hlisch, "Information centric networking in th= e=20 > IoT: > 1212 experiments with NDN in the wild, in ACM-ICN '14: > 1213 Proceedings of the 1st ACM Conference on Information= - > 1214 Centric Networking", DOI 10.1145/2660129.2660144, > 1215 September 2014, > 1216 = =2E >=20 > 1218 [Carzaniga2011] > 1219 Carzaniga, A., Papalini, M., and A.L. Wolf,=20 > "Content-Based > 1220 Publish/Subscribe Networking and Information-Centric= > 1221 Networking", DOI 10.1145/2018584.2018599, September = > 2011, > 1222 =20 > 1223 p56.pdf>. >=20 > 1225 [Chen2015] Chen, S., Cao, J., and L. Zhu, "NDSS: A Named Data=20 > Storage > 1226 System, in International Conference on Cloud and=20 > Autonomic > 1227 Computing", DOI 10.1109/ICCAC.2015.12, September=20 > 2014, > 1228 . >=20 > 1230 [DiBenedettoGTU12] > 1231 DiBenedetto, S., Gasti, P., Tsudik, G., and E. Uzun,= > 1232 "ANDaNA: Anonymous Named Data Networking Application= ,=20 > in > 1233 NDSS 2012", DOI https://arxiv.org/abs/1112.2205v2,=20 > 2102, > 1234 =20 > 1235 named-data-networking-application>. >=20 > 1237 [Gasti2012] > 1238 Gasti, P., Tsudik, G., Uzun, Ersin., and L. Zhang,=20 > "DoS > 1239 and DDoS in Named Data Networking, in 22nd=20 > International > 1240 Conference on Computer Communication and Networks > 1241 (ICCCN)", DOI 10.1109/ICCCN.2013.6614127, August=20 > 2013, > 1242 . >=20 > 1244 [Ghali2017] > 1245 Tsudik, G., Ghali, C., and C. Wood, "When encryption= =20 > is > 1246 not enough: privacy attacks in content-centric=20 > networking, > 1247 in ICN '17: Proceedings of the 4th ACM Conference on= > 1248 Information-Centric Networking", > 1249 DOI https://doi.org/10.1145/3125719.3125723,=20 > September > 1250 2017, > 1251 = =2E >=20 > 1253 [Gundogan2018] > 1254 G=C3=BCndo=C4=9Fan, C., Kietzmann, P., Schmidt, T., = and M.=20 > W=C3=A4hlisch, > 1255 "HoPP: publish-subscribe for the constrained IoT, in= =20 > ICN > 1256 '18: Proceedings of the 5th ACM Conference on=20 > Information- > 1257 Centric Networking", DOI 10.1145/3267955.3269020, > 1258 September 2018, > 1259 = =2E >=20 > 1261 [I-D.irtf-icnrg-flic] > 1262 Tschudin, C., Wood, C., Mosko, M., and D. Oran,=20 > "File-Like > 1263 ICN Collections (FLIC)", Work in Progress,=20 > Internet-Draft, > 1264 draft-irtf-icnrg-flic-02, 4 November 2019, > 1265 =20 > . >=20 > 1267 [I-D.irtf-icnrg-terminology] > 1268 Wissingh, B., Wood, C., Afanasyev, A., Zhang, L.,=20 > Oran, > 1269 D., and C. Tschudin, "Information-Centric Networking= > 1270 (ICN): CCNx and NDN Terminology", Work in Progress, > 1271 Internet-Draft, draft-irtf-icnrg-terminology-08, 17 > 1272 January 2020,=20 > 1273 icnrg-terminology-08>. >=20 > 1275 [I-D.oran-icnrg-pathsteering] > 1276 Moiseenko, I. and D. Oran, "Path Steering in CCNx an= d > 1277 NDN", Work in Progress, Internet-Draft,=20 > draft-oran-icnrg- > 1278 pathsteering-00, 21 October 2019, > 1279 1280 pathsteering-00>. >=20 > 1282 [Krol2018] Krol, M., Habak, K., Oran, D., Kutscher, D., and I. > 1283 Psaras, "RICE: Remote Method Invocation in ICN, in > 1284 Proceedings of the 5th ACM Conference on Information= - > 1285 Centric Networking - ICN '18", > 1286 DOI 10.1145/3267955.3267956, September 2018, > 1287 =20 > 1288 icn18-final9.pdf>. >=20 > 1290 [Lindgren2016] > 1291 Lindgren, A., Ben Abdessiem, F., Ahlgren, B.,=20 > Schlel=C3=A9n, > 1292 O., and A.M. Malik, "Design choices for the IoT in > 1293 Information-Centric Networks, in 13th IEEE Annual=20 > Consumer > 1294 Communications and Networking Conference (CCNC)", > 1295 DOI 10.1109/CCNC.2016.7444905, January 2016, > 1296 =20 > . >=20 > 1298 [Moiseenko2014] > 1299 Moiseenko, I., Stapp, M., and D. Oran, "Communicatio= n > 1300 patterns for web interaction in named data=20 > networking", > 1301 DOI 10.1145/2660129.2660152, September 2014, > 1302 . >=20 > 1304 [Mosko2017] > 1305 Mosko, M., "CCNx 1.0 Bidirectional Streams", > 1306 arXiv 1707.04738, July 2017, > 1307 . >=20 > 1309 [NDN] "Named Data Networking", 2020, > 1310 . >=20 > 1312 [NDNTLV] "NDN Packet Format Specification", 2016, > 1313 . >=20 > 1315 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,=20 > Johnston, > 1316 A., Peterson, J., Sparks, R., Handley, M., and E. > 1317 Schooler, "SIP: Session Initiation Protocol", RFC=20 > 3261, > 1318 DOI 10.17487/RFC3261, June 2002, > 1319 . >=20 > 1321 [RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session > 1322 Initiation Protocol (SIP) Usage of the Offer/Answer > 1323 Model", RFC 6337, DOI 10.17487/RFC6337, August 2011,= > 1324 . >=20 > 1326 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File=20 > System > 1327 (NFS) Version 4 Protocol", RFC 7530, DOI=20 > 10.17487/RFC7530, > 1328 March 2015,=20 > . >=20 > 1330 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS)=20 > Protocol > 1331 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August= =20 > 2018, > 1332 . >=20 > 1334 [Zhang2018] > 1335 Zhang, Y., Xia, Z., Mastorakis, S., and L. Zhang,=20 > "KITE: > 1336 Producer Mobility Support in Named Data Networking, = > in > 1337 Proceedings of the 5th ACM Conference on Information= - > 1338 Centric Networking - ICN '18", > 1339 DOI 10.1145/3267955.3267959, September 2018, > 1340 =20 > 1341 icn18-final23.pdf>. >=20 > 1343 Authors' Addresses >=20 > 1345 Dave Oran > 1346 Network Systems Research and Design > 1347 4 Shady Hill Square > 1348 Cambridge, MA 02138 > 1349 United States of America >=20 > 1351 Email: daveoran@orandom.net >=20 > 1353 Dirk Kutscher > 1354 University of Applied Sciences Emden/Leer > 1355 Constantiapl. 4 > 1356 26723 Emden > 1357 Germany >=20 > 1359 Email: ietf@dkutscher.net > 1360 URI: https://dirk-kutscher.info >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > DaveO >=20 >=20 >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc >=20 --tMJ1tS51RewtOq9GIc6WbGS7oxdB1Xhdn-- --F93n4LcAVcxIN7EHC4ewBMLlI8vNgiRL2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl6F7lAACgkQTptXS4+7 FxrGcA//TeQS/fIqfGtKfaU+AFzijHF1jk9fsmMpsnTKYg2L/h+ht2V1jmgCDWW4 qMKQc5WfBAQi0uG0ttUQsHTJBhDTTN2ifVWsGViPaZ/SkSdBn8w67Pb7ATZ0T10e I9g0w9TpVMOURbPxJAGTNAzZHK5YUEOOujQFFTzI4Vi91Y0kwt/soqUlLCF1QTaJ oYG6hb4yUDDQwCClOOrcF7Y2meo/dAcnUnby26MEaQxtcuTOKTep0JPMcOGSejt+ 6p7cGLCy0NjKwTJqezZxHO9fkgGBA/Bcarlj7cAnUZpwoAQudib5cpHNWS4mh511 5KDsYQ+exn3Sz84it6ohOls7fkpZ2SHDjdwpVR28WqbNaIsYkVcPh9hjIodA1cqv 32+qh4Z8pkxO4Do3AvX12INDYLTUcBqKt2sF1d55yj4tUgK2gqz3H9jKn23ZpbCd 0TzgiRmx5P4hftbisbZqnVT4mEmLE4hm+OF3cJ5j4t9A2XVg93HrGzOekSL+trs6 870folpQDY16bxvnR37+il/m7LH2JOEa3uK3DDeyHbAcwU2NapmiljU7atEpgmWO oSreblEd0629SPlOG5VOAIFk6VEopEqzPFFE3fyhxjEOs8e7y42lX5MSRU23I3NG q6t4aQ2zOtN1gJLynFzOyg47ZRbtsbOarmXVs2khfujP2owctxQ= =e68Y -----END PGP SIGNATURE----- --F93n4LcAVcxIN7EHC4ewBMLlI8vNgiRL2-- From nobody Thu Apr 2 07:00:12 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121C03A12EA for ; Thu, 2 Apr 2020 07:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zdPM2gxz5fh for ; Thu, 2 Apr 2020 07:00:03 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8607C3A12F5 for ; Thu, 2 Apr 2020 06:59:58 -0700 (PDT) Received: from [192.168.15.102] ([IPv6:2601:184:407f:80ce:c105:8cce:5bc6:3a67]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 032Dxm7P008125 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Apr 2020 06:59:50 -0700 From: "David R. Oran" To: "Henrik Levkowetz" Cc: xml2rfc@ietf.org Date: Thu, 02 Apr 2020 09:59:42 -0400 X-Mailer: MailMate (1.13.1r5680) Message-ID: <0F30FE8F-15D8-410B-9615-0FE9615148FA@orandom.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_CEA6EA1B-A29A-455E-AFB3-5FC5B40E6AB8_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [xml2rfc] Some problems with idnits checks on V3 document X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 14:00:10 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_CEA6EA1B-A29A-455E-AFB3-5FC5B40E6AB8_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 2 Apr 2020, at 9:53, Henrik Levkowetz wrote: > Hi Dave, > > On 2020-03-31 15:58, David R. Oran wrote: >> One of these seem to be xml2rfc rendering problem; others may be idnit= >> glitches that only show up on V3 docs: >> >> - The too long line 1551 is in fact not too long - the length >> computation seems to be screwed up by the non-ascii characters (probab= ly >> idnit problem?) > > Yes, that's right. Will see what can be done. > >> - somehow xml2rfc elided part of an author name into the updates head >> field and author address into the Intended Status header field. This >> only happens in the .txt output, not the HTML or PDF. xml2rfc bug? > > Will investigate, and if possible provide a fix in the next release, > due tomorrow. > I looked more carefully and this is because the author address is so long= it looks like it=E2=80=99s only one character away from the status, and = hence is parsed as part of that. Probably need to figure out how to split= long right-justified lines that over-run to the left. >> - idnits says this has a downref, but I believe that an I.D. marked >> experimental saying it updates an experimental RFC isn=E2=80=99t a dow= nref, >> right? > > Huh. I'll check the code. > On further investigation, I think this is a boggie due to the intended st= atus getting defaulted to Proposed Standard when incorrectly parse above.= >> I include the idnits output below and the xml file as an attachment >> (note that this is still a bit private - we haven=E2=80=99t submitted = yes) > > Understood. > >> Let me know of any followup I should do - would like to get this >> submitted in the next couple of days. > > Ack. Will follow up when I have more information. > Many thanks! I decided to try to submit anyway and am now being done in by =E2=80=9CFa= iled decoding the uploaded file: "'ascii' codec can't decode byte 0xc3 in= position 69240: ordinal not in range(128)" Time to go count characters in the .txt file. Sigh. > > Best regards, > > Henrik > > > >> Thanks! DaveO. >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94 >> >> idnits 2.16.03 >> >> >> tmp/draft-oran-icnrg-reflexive-forwarding.txt: >> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1491): Found non-ascii >> character (=EF=BF=BD) in position 18. >> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1500): Found non-ascii >> character (=EF=BF=BD) in position 16. >> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1551): Line is too long:= >> the offending characters are 'ch,' >> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1551): Found non-ascii >> character (=EF=BF=BD) in position 16. >> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1597): Found non-ascii >> character (=EF=BF=BD) in position 67. >> >> >> Checking boilerplate required by RFC 5378 and the IETF Trust (see >> https://trustee.ietf.org/license-info): >> -------------------------------------------------------------------= --------- >> >> No issues found here. >> >> Checking nits according to >> https://www.ietf.org/id-info/1id-guidelines.txt: >> -------------------------------------------------------------------= --------- >> >> =3D=3D There are 4 instances of lines with non-ascii characters in= the >> document. >> >> >> Checking nits according to https://www.ietf.org/id-info/checklist := >> -------------------------------------------------------------------= --------- >> >> ** There is 1 instance of too long lines in the document, the longe= st >> one >> being 3 characters in excess of 72. >> >> >> Miscellaneous warnings: >> -------------------------------------------------------------------= --------- >> >> =3D=3D Unrecognized Status in 'Intended status: Experimental Unive= rsity >> of >> Applied Sciences Emden/Leer', assuming Proposed Standard >> >> (Expected one of 'Standards Track', 'Full Standard', 'Draft >> Standard', >> 'Proposed Standard', 'Best Current Practice', 'Informational', >> 'Experimental', 'Informational', 'Historic'.) >> >> =3D=3D Couldn't figure out when the document was first submitted --= there >> may >> comments or warnings related to the use of a disclaimer for >> pre-RFC5378 >> work that could not be issued because of this. Please check the= >> Legal >> Provisions document at https://trustee.ietf.org/license-info to >> determine >> if you need the pre-RFC5378 disclaimer. >> >> >> Checking references for intended status: Proposed Standard >> -------------------------------------------------------------------= --------- >> >> (See RFCs 3967 and 4897 for information about using normative >> references >> to lower-maturity documents in RFCs) >> >> ** Downref: Normative reference to an Experimental RFC: RFC 8569 >> >> ** Downref: Normative reference to an Experimental RFC: RFC 8609 >> >> >> Summary: 3 errors (**), 0 flaws (~~), 4 warnings (=3D=3D), 0 com= ments >> (--). >> >> ----------------------------------------------------------------------= ---------- >> >> >> 2 ICNRG D. >> Oran >> 3 Internet-Draft Network Systems Research and >> Design >> 4 Updates: 8569, 8609 (if approved) D. >> Kutscher >> 5 Intended status: Experimental University of Applied Sciences >> Emden/Leer >> 6 Expires: 2 October 2020 31 March >> 2020 >> >> 8 Reflexive Forwarding for CCNx and NDN Protocols >> 9 draft-oran-icnrg-reflexive-forwarding-00 >> >> 11 Abstract >> >> 13 Current Information-Centric Networking protocols such as CCNx an= d >> NDN >> 14 have a wide range of useful applications in content retrieval an= d >> 15 other scenarios that depend only on a robust two-way exchange in= >> the >> 16 form of a request and response (represented by an _Interest-Data= >> 17 exchange_ in the case of the two protocols noted above). A numb= er >> of >> 18 important applications however, require placing large amounts of= >> data >> 19 in the Interest message, and/or more than one two-way handshake.= >> 20 While these can be accomplished using independent Interest-Data >> 21 exchanges by reversing the roles of consumer and producer, such >> 22 approaches can be both clumsy for applications and problematic >> from a >> 23 state management, congestion control, or security standpoint. >> This >> 24 specification proposes a _Reflexive Forwarding_ extension to the= >> CCNx >> 25 and NDN protocol architectures that eliminates the problems >> inherent >> 26 in using independent Interest-Data exchanges for such >> applications. >> 27 It updates RFC8569 and RFC8609. >> >> 29 Status of This Memo >> >> 31 This Internet-Draft is submitted in full conformance with the >> 32 provisions of BCP 78 and BCP 79. >> >> 34 Internet-Drafts are working documents of the Internet Engineerin= g >> 35 Task Force (IETF). Note that other groups may also distribute >> 36 working documents as Internet-Drafts. The list of current >> Internet- >> 37 Drafts is at https://datatracker.ietf.org/drafts/current/. >> >> 39 Internet-Drafts are draft documents valid for a maximum of six >> months >> 40 and may be updated, replaced, or obsoleted by other documents at= >> any >> 41 time. It is inappropriate to use Internet-Drafts as reference >> 42 material or to cite them other than as "work in progress." >> >> 44 This Internet-Draft will expire on 2 October 2020. >> >> 46 Copyright Notice >> >> 48 Copyright (c) 2020 IETF Trust and the persons identified as the >> 49 document authors. All rights reserved. >> >> 51 This document is subject to BCP 78 and the IETF Trust's Legal >> 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/= >> 53 license-info) in effect on the date of publication of this >> document. >> 54 Please review these documents carefully, as they describe your >> rights >> 55 and restrictions with respect to this document. >> >> 57 Table of Contents >> >> 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . = =2E >> 3 >> 60 1.1. Problems with pushing data . . . . . . . . . . . . . . = =2E >> 4 >> 61 1.2. Problems with utilizing independent exchanges . . . . . = =2E >> 5 >> 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . = =2E >> 6 >> 63 3. Overview of the Reflexive Forwarding design . . . . . . . . = =2E >> 6 >> 64 4. Naming of Reflexive Interests . . . . . . . . . . . . . . . = =2E >> 10 >> 65 5. Forwarder operation for Reflexive Interests . . . . . . . . = =2E >> 11 >> 66 6. State coupling between producer and consumer . . . . . . . = =2E >> 12 >> 67 7. Use cases for Reflexive Interests . . . . . . . . . . . . . = =2E >> 12 >> 68 7.1. Achieving Remote Method Invocation with Reflexive >> 69 Interests . . . . . . . . . . . . . . . . . . . . . . . = =2E >> 12 >> 70 7.2. RESTful Web Interactions . . . . . . . . . . . . . . . = =2E >> 15 >> 71 7.3. Achieving simple data pull from consumers with reflexive= >> 72 Interests . . . . . . . . . . . . . . . . . . . . . . . = =2E >> 15 >> 73 8. Implementation Considerations . . . . . . . . . . . . . . . = =2E >> 19 >> 74 8.1. Forwarder implementation considerations . . . . . . . . = =2E >> 19 >> 75 8.1.1. Forwarding Information Base (FIB) . . . . . . . . . = =2E >> 19 >> 76 8.1.2. Interactions with Interest Lifetime . . . . . . . . = =2E >> 20 >> 77 8.1.3. Interactions with Interest aggregation . . . . . . = =2E >> 21 >> 78 8.2. Consumer Implementation Considerations . . . . . . . . = =2E >> 21 >> 79 8.2.1. Data objects returned by the consumer to reflexive >> name >> 80 Interests arriving from a producer . . . . . . . . = =2E >> 21 >> 81 8.2.2. Terminating unwanted reflexive Interest exchanges . = =2E >> 22 >> 82 8.2.3. Interactions with caching . . . . . . . . . . . . . = =2E >> 22 >> 83 8.3. Producer Implementation Considerations . . . . . . . . = =2E >> 22 >> 84 9. Operational Considerations . . . . . . . . . . . . . . . . = =2E >> 23 >> 85 10. Mapping to CCNx and NDN packet encodings . . . . . . . . . = =2E >> 24 >> 86 10.1. Packet encoding for CCNx . . . . . . . . . . . . . . . = =2E >> 24 >> 87 10.2. Packet encoding for NDN . . . . . . . . . . . . . . . = =2E >> 24 >> 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . = =2E >> 24 >> 89 12. Security Considerations . . . . . . . . . . . . . . . . . . = =2E >> 25 >> 90 12.1. Collisions of reflexive Interest names . . . . . . . . = =2E >> 25 >> 91 12.2. Additional resource pressure on PIT and FIB . . . . . = =2E >> 26 >> 92 12.3. Privacy Considerations . . . . . . . . . . . . . . . . = =2E >> 26 >> 93 13. Normative References . . . . . . . . . . . . . . . . . . . = =2E >> 27 >> 94 14. Informative References . . . . . . . . . . . . . . . . . . = =2E >> 27 >> 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . = =2E >> 30 >> >> 97 1. Introduction >> >> 99 Current ICN protocols such as CCNx [RFC8569] and [NDN] have a wi= de >> 100 range of useful applications in content retrieval and other >> scenarios >> 101 that depend only on a robust two-way exchange in the form of a >> 102 request and response. These ICN architectures use the terms >> 103 "consumer" and "producer" for the respective roles of the >> requester >> 104 and the responder, and the protocols directly capture the >> mechanics >> 105 of the two-way exchange through the "Interest message" carrying= >> the >> 106 request, and the "Data message" carrying the response. Through= >> these >> 107 constructs, the protocols are heavily biased toward a pure _pul= l- >> 108 based_ interaction model where requests are small (carrying >> little or >> 109 no user-supplied data other than the name of the requested data= >> 110 object), and responses are relatively large - up to an >> architecture- >> 111 defined maximum transmission unit (MTU) on the order of kilobyt= es >> or >> 112 tens of kilobytes. >> >> 114 A number of important applications however require interaction >> models >> 115 more complex than individual request/response interactions in t= he >> 116 same direction (i.e. between the same consumer and one or more >> 117 producers). Among these we identify three important classes >> which >> 118 are the target of the proposed enhancements defined in this >> 119 specification. These are described in the following paragraphs= =2E >> >> 121 *Remote Method Invocation (RMI, aka RPC):* When invoking a >> remote >> 122 method, it is common for the method to require arguments >> supplied >> 123 by the caller. In conventional TCP/IP style protocols like >> CORBA >> 124 or HTTP "Post", these are pushed to the server as part of th= e >> 125 message or messages that comprise the request. In ICN-style= >> 126 protocols there is an unattractive choice between inflating >> the >> 127 request initiation with pushed arguments, or arranging to ha= ve >> one >> 128 or more independent request/responses in the opposite >> direction >> 129 for the server to fetch the arguments. Both of these >> approaches >> 130 have substantial disadvantages. Recently, a viable >> alternative >> 131 emerged through the work on RICE [Krol2018] which pioneered >> the >> 132 main design elements proposed in this specification. >> >> 134 *Phone-Home scenario:* Applications in sensing, >> Internet-of-things >> 135 (IoT) and other types where data is produced unpredictably a= nd >> 136 needs to be _pushed_ somewhere create a conundrum for the pu= re >> 137 pull-based architectures considered here. If instead one >> eschews >> 138 relaxing the size asymmetry between requests and responses, >> some >> 139 additional protocol machinery is needed. Earlier efforts in= >> the >> 140 ICN community have recognized this issue and designed method= s >> to >> 141 provoke a cooperating element to issue a request to return t= he >> 142 data the originator desires to push, essentially "phoning >> home" to >> 143 get the responder to fetch the data. One that has been >> explored >> 144 to some extent is the _Interest-Interest-Data_ exchange >> 145 [Carzaniga2011], where an Interest is sent containing the >> desired >> 146 request as encapsulated data. CCNx-1.0 Bidirectional Stream= s >> 147 [Mosko2017] are also based on a scheme where an Interest is >> used >> 148 to signal a name prefix that a consumer has registered for >> 149 receiving Interests from a peer in a bidirectional streaming= >> 150 session. >> >> 152 *Peer state synchronization:* A large class of applications, >> 153 typified by those built on top of on reliable order-preservi= ng >> 154 transport protocols, require initial state synchronization >> between >> 155 the peers. This is accomplished with a three-way (or longer= ) >> 156 handshake, since employing a two-way handshake as provided i= n >> the >> 157 existing NDN and CCNx protocols exposes a number of well-kno= w >> 158 hazards, such as _half-open connections_. When attempted for= >> 159 security-related operations such as key exchange, additional= >> 160 hazards such as _man-in-the-middle_ attacks become trivial t= o >> 161 mount. Existing alternatives, similar to those used in the >> two >> 162 examples above, instead utilize either overlapping >> Interest-Data >> 163 exchanges in opposite directions (resulting in a four-way >> 164 handshake) or by adding initialization data to the initial >> request >> 165 and employing an Interest-Interest-Data protocol extension a= s >> 166 noted in the Phone-home scenarios above. >> >> 168 All of the above application interaction models present >> interesting >> 169 challenges, as neither relaxing the architecture to support >> pushing >> 170 large amounts of data, nor introducing substantial complexities= >> 171 through multiple independent Interest-Data exchanges is an >> attractive >> 172 approach. The following subsections provide further background= >> and >> 173 justification for why push and/or independent exchanges are >> 174 problematical. >> >> 176 1.1. Problems with pushing data >> >> 178 There are two substantial problems with the simple approach of >> just >> 179 allowing arbitrary amounts of data to be included with requests= =2E >> 180 These are: >> >> 182 1. In ICN protocols, Interest messages are intended to be smal= l, >> on >> 183 the order the size of a TCP ACK, as opposed to the size of = a >> TCP >> 184 data segment. This is because the hop-by-hop congestion >> control >> 185 and forwarder state management requires Interest messages t= o >> be >> 186 buffered in expectation of returning data, and possibly >> 187 retransmitted hop-by-hop as opposed to end-to-end. In >> addition, >> 188 the need to create and manage state on a per-Interest basis= >> is >> 189 substantially complicated if requests in Interest messages >> are >> 190 larger than a Path MTU (PMTU) and need to be fragmented >> hop-by- >> 191 hop. >> >> 193 2. If the payload data of a request is used for invoking a >> 194 computation (as in the RMI case described above) then >> substantial >> 195 bandwidth can be wasted if the computation is either refuse= d >> or >> 196 abandoned for any number of reasons, including the requesto= r >> 197 failing an authorization check, or the responder not having= >> 198 sufficient resources to execute the associated computation.= >> >> 200 These problems also exist in pure datagram transport protocols >> such >> 201 as those used for legacy RMI applications like NFS [RFC7530]. >> More >> 202 usual are application protocols like HTTP(s) which rely on the >> TCP or >> 203 QUIC 3-way handshake to establish a session and then have >> congestion >> 204 control and segmentation provided as part of the transport >> protocol, >> 205 further allowing sessions to be rejected before large amounts o= f >> data >> 206 are transmitted or significant computational resources expended= =2E >> >> 208 1.2. Problems with utilizing independent exchanges >> >> 210 In order to either complete a three-way handshake, or fetch dat= a >> via >> 211 a pull from the original requestor, the role of consumer and >> producer >> 212 need to be reversed and an Interest/Data exchange initiated in >> the >> 213 direction opposite of the initiating exchange. When done with = an >> 214 independent Interest/Data request and response, a number of >> 215 complications ensue. Among them are: >> >> 217 1. The originating consumer needs to have a routable name pref= ix >> 218 that can be used for the exchange. This means the consumer= >> must >> 219 arrange to have its name prefix propagated in the ICN routi= ng >> 220 system with sufficient reach that the producer issuing the >> 221 interest can be assured it is routed appropriately. While >> some >> 222 consumers are generally online and act as application >> servers, >> 223 justifying the maintenance of this routing information, man= y >> do >> 224 not. Further, in mobile environments, a pure consumer that= >> does >> 225 not need to have a routable name prefix can benefit from th= e >> 226 inherent consumer mobility support in the CCNx and NDN >> protocols. >> 227 By requiring a routable name prefix, extra mobile routing >> 228 machinery is needed, such as that proposed in KITE >> [Zhang2018] or >> 229 MAPME [Auge2018]. >> >> 231 2. The consumer name prefix in item (1) above must be >> communicated >> 232 to the producer as a payload, name suffix, or other field o= f >> the >> 233 initiating Interest message. Since this name in its entire= ty >> is >> 234 chosen by the consumer, it is highly problematic from a >> security >> 235 standpoint, as it can recruit the producer to mount a >> reflection >> 236 attack against the consumer's chosen victim. >> >> 238 3. The correlation between the exchanges in opposite direction= s >> must >> 239 be maintained by both the consumer and the producer as >> 240 independent state, as opposed to being architecturally tied= >> 241 together as would be the case with a conventional 3-way >> handshake >> 242 finite state machine. While this can of course be >> accomplished >> 243 with care by both parties, experience has shown that it is >> error >> 244 prone (for example see the checkered history of interaction= s >> 245 between the SIP [RFC3261] and SDP Offer-Answer [RFC6337]) >> 246 protocols. When employed as the wrapper for a key manageme= nt >> 247 protocol such as with TLS [RFC8446] state management errors= >> can >> 248 be catastrophic for security. >> >> 250 2. Requirements Language >> >> 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >> NOT", >> 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY"= , >> and >> 254 "OPTIONAL" in this document are to be interpreted as described = in >> 255 [RFC2119]. >> >> 257 3. Overview of the Reflexive Forwarding design >> >> 259 This specification defines a _Reflexive Forwarding_ extension t= o >> CCNx >> 260 and NDN that avoids the problems enumerated in Sections 1.1 and= >> 1.2. >> 261 It straightforwardly exploits the hop-by-hop state and symmetri= c >> 262 routing properties of the current protocols. >> >> 264 Figure 1 below illustrates a canonical NDN/CCNx forwarder with >> its >> 265 conceptual data structures of the Content Store (CS), Pending >> 266 Interest Table (PIT) and Forwarding Information Base (FIB). Th= e >> key >> 267 observation involves the relation between the PIT and the FIB. >> Upon >> 268 arrival of an Interest, a PIT entry is created which contains >> state >> 269 recording the incoming interface on which the Interest. If the= >> 270 Interest is not immediately satisfied by cached data in the CS,= >> the >> 271 forwarder looks up the name in the FIB to ascertain the >> _next-hop_ to >> 272 propagate the Interest onward upstream toward the named produce= r. >> 273 Therefore, a chain of forwarding state is established during >> Interest >> 274 forwarding that couples the PIT entries of the chain of >> forwarders >> 275 together conceptually as _breadcrumbs_. These are used to forwa= rd >> the >> 276 returning Data Message over the inverse path through the chain = of >> 277 forwarders until the Data message arrives at the originating >> 278 consumer. The state in the PITs is _unwound_ by destroying it = as >> 279 each PIT entry is _satisfied_. This behavior is *critical* to t= he >> 280 feasibility of the reflexive forwarding design we propose. >> >> 282 = >> +-----------------------------------------------------------------+ >> 283 | ICN Nod= e >> | >> 284 | Send data to all =3D=3D=3D= =3D=3D=3D=3D=3D >> | >> 285 | interfaces that >> | >> 286 | requested it >> | >> 287 | YES +------------------+ >> | >> 288 <------------------------| Pending Interest | >> <--------------------- >> 289 | | | Table (PIT) | Data= >> | >> 290 | | +------------------+ 1) Find >> (Signed) | >> 291 | | 2) Save | Name >> | >> 292 | V Data | NO in >> | >> 293 | +---------------+ | PIT? >> | >> 294 | | Content Store | | >> | >> 295 | | (CS) | | >> | >> 296 | +---------------+ | >> | >> 297 | | >> | >> 298 | V >> | >> 299 | Drop Data >> | >> 300 | >> | >> 301 = >> +-----------------------------------------------------------------+ >> 302 = >> +-----------------------------------------------------------------+ >> 303 | ICN Nod= e >> | >> 304 | =3D=3D=3D= =3D=3D=3D=3D=3D >> | >> 305 | >> | >> 306 | >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+| >> 307 | |Forwarding Strate= gy >> || >> 308 | >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+| >> 309 | >> | >> 310 | 1) Find name 2) Matching 3) Find matching >> | >> 311 | in CS? name in PIT? entry in FIB? >> | >> 312 | NO NO >> YES| >> 313 | +---------------+ +----------------+ >> +-------------------+ | >> 314 | | Content Store | | Pending | | Forwarding >> | | >> 315 --->| (CS) |-->| Interest |-->| Information Bas= e >> |--> >> 316 | | | | Table (PIT) | | ( FIB) >> | | >> 317 | +---------------+ +----------------+ >> +-------------------+ | >> 318 | Return | YES YES | NO NO | >> | >> 319 | Data | Add | Add | Drop >> | >> 320 | | Incoming | new | or >> | >> 321 | <------| Itf. | Interest | NACK >> | >> 322 | V V >> | >> 323 | >> | >> 324 = >> +-----------------------------------------------------------------+ >> >> 326 Figure 1: ICN forwarder structure >> >> 328 Given the above forwarding properties for Interests, it should = be >> 329 clear that while an Interest is outstanding and ultimately >> arrives at >> 330 a producer who can respond to it, there is sufficient state in >> the >> 331 chain of forwarders to route not just a returning Data message,= >> but >> 332 potentially another Interest directed through the inverse path = to >> the >> 333 unique consumer who issued the original Interest. (Section 8.1= =2E3 >> 334 describes how Interest aggregation interacts with this scheme.)= >> The >> 335 key question therefore is how to access this state in a way tha= t >> it >> 336 can be used to forward Interests. >> >> 338 In order to achieve this _Reflexive Interest_ forwarding on the= >> 339 inverse path recorded in the PIT of each forwarder, we need a f= ew >> 340 critical design elements. These are as follows: >> >> 342 1. The Reflexive Interest needs to have a Name. This name is >> what >> 343 the originating consumer will use to match against the Data= >> 344 object (or objects - more on this later) it wishes the >> producer >> 345 to fetch by issuing the Reflexive Interest. This cannot be= >> just >> 346 any name, but needs to essentially name the state already >> 347 recorded in the PIT and not allow the consumer to manufactu= re >> an >> 348 arbitrary name and mount a reflection attack as pointed out= >> in >> 349 Section 1.2, Paragraph 2, Item 2. >> >> 351 2. There has to be a FIB entry at each forwarder for this name= >> 352 prefix so that when the reflexive interest arrives, the >> forwarder >> 353 can forward it downstream toward the originating consumer. >> This >> 354 FIB entry points directly to the incoming interface on whic= h >> the >> 355 corresponding original Interest arrived. The FIB entry nee= ds >> to >> 356 be created as part of the forwarding of the original Intere= st >> so >> 357 that it is available in time to catch any reflexive Interes= t >> 358 issued by the producer. It usually makes sense to destroy >> this >> 359 FIB entry when the Data message satisfying the original >> Interest >> 360 arrives since this avoids any dangling stale state. Given >> the >> 361 deign details documented later in this specification, stale= >> FIB >> 362 state does not represent a correctness hazard and hence can= >> be >> 363 done lazily if desired in an implementation. See Section 5= >> for >> 364 more details on FIB operation considerations. >> >> 366 3. There has to be coupling of the state between the originati= ng >> 367 Interest-Data exchange and the enclosed Reflexive >> Interest-Data >> 368 exchange at both the consumer and the producer. In our >> design, >> 369 this accomplished by the way reflexive interest names are >> chosen. >> >> 371 The following sections provide the normative details on each of= >> these >> 372 design elements. The overall interaction flow for reflexive >> 373 forwarding is illustrated below in Figure 2. >> >> 375 +-----------+ +-----------+ +-----------+ >> 376 | Consumer | | Forwarder | | Producer | >> 377 +-----------+ +-----------+ +-----------+ >> 378 | | | >> 379 | I1 | | >> 380 |--------------->| | >> 381 |--------------\ | | >> 382 || Install RNP |-| | >> 383 || in FIB | | | >> 384 ||-------------| | | >> 385 | | | >> 386 | | I1 | >> 387 | |----------------------------->| >> 388 | | | >> -----------\ >> 389 | | |-| Creat= e >> | >> 390 | | | | RI >> state | >> 391 | | | >> |----------| >> 392 | | | >> 393 | | RI | >> 394 | |<-----------------------------| >> 395 | | --------------------\ | >> 396 | |-| lookup RNP in FIB | | >> 397 | | |-------------------| | >> 398 | | | >> 399 | RI | | >> 400 |<---------------| | >> 401 | | | >> 402 | D2 | | >> 403 |--------------->| | >> 404 | | | >> 405 | | D2 | >> 406 | |----------------------------->| >> 407 | | | >> ------------\ >> 408 | | |-| answe= r >> I1 | >> 409 | | | >> |-----------| >> 410 | | | >> 411 | | D1 | >> 412 | |<-----------------------------| >> 413 | | -----------------------\ | >> 414 | |-| remove RNP FIB entry | | >> 415 | | |----------------------| | >> 416 | | | >> 417 | D1 | | >> 418 |<---------------| | >> 419 | | | >> >> 421 Legend: >> 422 I1: Interest #1 containing the Reflexive Name Prefix TLV >> 423 RI: Reflexive Interest with Reflexive Name Prefix Component= >> 424 RNP: Reflexive Name Prefix >> 425 D1: Data message, answering initiating I1 Interest >> 426 D2: Data message, answering RI >> >> 428 Figure 2: Message Flow Overview >> >> 430 4. Naming of Reflexive Interests >> >> 432 A consumer may have one or more objects for the producer to >> fetch, >> 433 and therefore needs to communicate enough information in their >> 434 initial Interest to allow the producer to construct properly >> formed >> 435 reflexive Interest names. For some applications the set of _fu= ll >> 436 names_ (see [I-D.irtf-icnrg-terminology]) is known a priori, fo= r >> 437 example through compile time bindings of arguments in interface= >> 438 definitions or by the architectural definition of a simple sens= or >> 439 reading. In other cases the full names of the individual objec= ts >> 440 must be communicated in the original Interest message. In all >> cases >> 441 enough state must be provided by the consumer for the forwarder= s >> to >> 442 construct a FIB entry (as noted in Section 3, Paragraph 6, Item= >> 2). >> 443 This is accomplished through the following naming construct. >> >> 445 We define a new typed name component, identified by a registere= d >> name >> 446 component type in the IANA registry for [RFC8569]. We call thi= s >> the >> 447 _Reflexive Interest Name Component type_. It MUST be the first >> (i.e. >> 448 high order) name component of any Reflexive Interest issued by = a >> 449 producer. Its value is a random 64 bit number, assigned by the= >> 450 consumer, which provides the entropy required to uniquely >> identify >> 451 the issuing consumer for the duration of any outstanding >> Interest- >> 452 Data exchange. The consumer SHOULD choose a different random >> value >> 453 for each Interest message it constructs, for two reasons: >> >> 455 1. If stale FIB sate is present, the randomness prevents >> potential >> 456 mis-routing of reflexive interests (see Section 8.1.1 below= >> for >> 457 more details), and >> >> 459 2. Re-use of the same reflexive interest name over multiple >> 460 interactions might reveal linkability information that coul= d >> be >> 461 used by surveillance adversaries for tracking purposes. >> >> 463 This initial name component is either communicated by itself >> through >> 464 a _Reflexive Name Prefix TLV_ in the originating Interest, or >> 465 prepended to any object names the consumer wishes the producer = to >> 466 fetch explicitly where there is more than one object needed by >> the >> 467 producer for the current Interest-Data interaction. There are >> four >> 468 cases to consider: >> >> 470 1. The reflexive _fullname_ of a single object to fetch. >> >> 472 2. A single reflexive name prefix out of which the producer ca= n >> (by >> 473 application-specific means) construct a number of _fullname= s_ >> of >> 474 the objects it may want to fetch, >> >> 476 3. The reflexive _fullname_ of a FLIC Manifest >> [I-D.irtf-icnrg-flic] >> 477 enumerating the suffixes that may be used by the producer t= o >> 478 construct the necessary names, >> >> 480 4. Multiple reflexive name TLVs MAY be included in the Interes= t >> 481 message if none of the above 3 options covers the desired u= se >> 482 case. >> >> 484 The last of the four options above, while not explicitly >> outlawed, >> 485 SHOULD NOT be used. This is because it results in a longer >> Interest >> 486 message and requires extra FIB resources. Hence, it is more >> likely a >> 487 forwarder will reject the Interest for lack of resources. A >> 488 forwarder MAY optimize for the case of a single Reflexive Name >> TLV at >> 489 the expense of those with more than one. >> >> 491 A producer, upon receiving an Interest with one or more Reflexi= ve >> 492 Name TLVs, may decide it needs the pull the associated data >> 493 object(s). It therefore can issue one or more Reflexive >> Interests by >> 494 appending the necessary name components needed to form valid fu= ll >> 495 names of the associated objects present at the originating >> consumer. >> 496 These in fact comprise conventional Interest-Data exchanges, wi= th >> no >> 497 alteration of the usual semantics with regard to signatures, >> caching, >> 498 expiration, etc. When the producer has retrieved the required >> 499 objects to complete the original Interest-Data exchange, it can= >> issue >> 500 its Data response, which unwinds all the established state at t= he >> 501 producer, the consumer, and the intermediate forwarders. >> >> 503 5. Forwarder operation for Reflexive Interests >> >> 505 The forwarder operation for CCNx and/or NDN is changed in three= >> 506 respects when supporting Reflexive Interests. >> >> 508 1. The forwarder MUST create short-lifetime FIB entries for an= y >> 509 Reflexive Interest Name prefixes communicated in an Interes= t >> 510 message. If the forwarder does not have sufficient resourc= es >> to >> 511 do so, it MUST reject the Interest with the >> T_RETURN_NO_RESOURCES >> 512 error - the same error used if the forwarder were lacking >> 513 sufficient PIT resources to process the Interest message. >> >> 515 2. Those FIB entries MUST be queried whenever an Interest >> message >> 516 arrives whose first name component is of the type _Reflexiv= e >> 517 Interest Name Component_ >> >> 519 3. The FIB entry MUST be removed eventually, after the >> corresponding >> 520 Data message has been forwarded. One option would be to >> remove >> 521 the FIB directly after the Data message has been forwarded.= >> 522 However, the forwarder MAY do lazy cleanup. >> >> 524 The PIT entry for the Reflexive Interest is consumed per regula= r >> 525 Interest/Data message forwarding requirements. The PIT entry f= or >> the >> 526 originating Interest (that communicated the Reflexive Interest >> Name) >> 527 is also consumed by a final Data message from the producer to t= he >> 528 original consumer. >> >> 530 6. State coupling between producer and consumer >> >> 532 A consumer that wishes to use this scheme MUST utilize one of t= he >> 533 reflexive naming options defined in Section 4 and include it in= >> the >> 534 corresponding Interest message. The Reflexive Name TLV _and_ t= he >> 535 full name of the requested data object (that identifies the >> producer) >> 536 identify the common state shared by the consumer and the >> producer. >> 537 When the producer responds by sending Interests with the >> Reflexive >> 538 Name Prefix, the original consumer therefore has sufficient >> 539 information to map these Interests to the ongoing Interest-Data= >> 540 exchange. >> >> 542 The exchange is finished when the producer who received the >> original >> 543 Interest message responds with a Data message (or an Interest >> Return >> 544 message in the case of error) answering the original Interest. >> After >> 545 sending this Data message, the producer SHOULD destroy the >> 546 corresponding shared state. It MAY decide to use a timer that >> will >> 547 trigger a later state destruction. After receiving this Data >> 548 message, the originating consumer MUST destroy the correspondin= g >> 549 Interest-Data exchange state. >> >> 551 7. Use cases for Reflexive Interests >> >> 553 7.1. Achieving Remote Method Invocation with Reflexive Interests >> >> 555 RICE (Remote Method Invocation in ICN) [Krol2018] uses the >> Reflexive >> 556 Interest Forwarding scheme that inspired the design specified i= n >> this >> 557 document. >> >> 559 In RICE, the original Interest denotes the remote method (plus >> 560 potential parameters) to be invoked at a producer (server). >> Before >> 561 committing any computating resources, the server can then reque= st >> 562 authentication credentials and (optional) parameters using >> reflexive >> 563 Interest-Data exchanges. >> >> 565 When the server has obtained the necessary credentials and inpu= t >> 566 parameters, it can decide to commit computing resources, starts= >> the >> 567 compute process, and returns a handle ("Thunk") in the final Da= ta >> 568 message to the original consumer (client). >> >> 570 The client would later request the computation results using a >> 571 regular Interest-Data exchange (outside the Reflexive-Interest >> 572 transaction) -- using the Thunk as a name for the computation >> result. >> >> 574 Figure 3 depicts an abstract message diagram for RICE. In >> addition >> 575 to the 4-way Reflexive Forwarding Handshake (see Figure 2 for t= he >> 576 details of the interaction), RICE adds another (standard) ICN >> 577 Interest/Data exchange for transmitting the RMI result. The >> Thunk >> 578 name is provided to the consumer in the D1 DATA message >> (answering >> 579 the initial I1 Interest). >> >> 581 +-----------+ +-----------+ >> 582 | Consumer | | Producer | >> 583 +-----------+ +-----------+ >> 584 | | >> 585 | I1 | >> 586 |------------------------->| >> 587 | | ---------------------\ >> 588 | |-| Requesting request | >> 589 | | | parameters | >> 590 | | | and credentials | >> 591 | | |--------------------| >> 592 | | >> 593 | RI | >> 594 |<-------------------------| >> 595 | | >> 596 | D2 | >> 597 |------------------------->| >> 598 | | --------------------\ >> 599 | |-| Commit compute | >> 600 | | | resources, | >> 601 | | | return Thunk name | >> 602 | | |-------------------| >> 603 | | >> 604 | D1 | >> 605 |<-------------------------| >> 606 | | ----------------\ >> 607 | |-| Invoke Remote | >> 608 | | | Method | >> 609 | | |---------------| >> 610 | -------------------\ | >> 611 |-| After some time, | | >> 612 | | request result | | >> 613 | |------------------| | >> 614 | | >> 615 | I3 | >> 616 |------------------------->| >> 617 | | >> 618 | D3 | >> 619 |<-------------------------| >> 620 | | >> 621 Legend: >> 622 I1: Interest #1 containing the Reflexive Name Prefix TLV >> 623 D1: Data message, answering initiating I1 Interest, >> 624 returning Thunk name >> 625 D2: Data message, answering RI (parameters, credentials) >> 626 I3: Regular Interest for Thunk (compute result) >> 627 D3: Data message, answering I3 >> 628 Figure 3: RICE Message Flow >> >> 630 7.2. RESTful Web Interactions >> >> 632 In todays HTTP-based web, RESTful (Representational State >> Transfer) >> 633 web interactions are realized by sending requests in a >> client/server >> 634 interaction, where the requests provides the application contex= t >> (or >> 635 a reference to it). It has been noted in [Moiseenko2014] that >> 636 corresponding requests often exceed the response messages in >> size, >> 637 and that this raises the problems noted in Section 1.1 when >> 638 attempting to map such exchanges directly to CCNx/NDN. >> >> 640 Another reason not to include all request parameters in a >> (possibly >> 641 encrypted) Interest message is the fact that a server (that is >> 642 serving thousands of clients) would be obliged to receive, >> possibly >> 643 decrypt and parse the complete requests before being able to >> 644 determine whether the requestor is authorized, whether the >> request >> 645 can be served etc. Many non-trivial requests could thus lead t= o >> 646 computational overload attacks. >> >> 648 Using Reflexive Interest Forwarding for RESTful Web Interaction= s >> 649 would encode the REST request in the Original request, together= >> with >> 650 a Reflexive Interest Prefix that the server could then use to g= et >> 651 back to the client for authentication credentials and request >> 652 parameters, such as cookies. The request result (response >> message) >> 653 could either be transmitted in the Data message answering the >> 654 original request, or -- in case of dynamic, longer-running >> 655 computations -- in a seperate Interest/Data exchange, potential= ly >> 656 leveraging the Thunk scheme described in section Section 7.1. >> >> 658 Unlike approaches where clients have to signal a globally >> routable >> 659 prefix to the network, this approach would not require the clie= nt >> 660 (original consumer) to expose its identity to the network (the >> 661 network only sees the temporary Reflexive Name Prefix), but it >> would >> 662 still be possible to authenticate the client at the server. >> >> 664 7.3. Achieving simple data pull from consumers with reflexive >> Interests >> >> 666 An oft-cited use case for ICN network architectures is _Interne= t >> of >> 667 Things_ (IoT), where the sources of data are limited-resource >> sensor/ >> 668 actuators. Many approaches have been tried (e.g. >> [Baccelli2014], >> 669 [Lindgren2016], [Gundogan2018]) with varying degrees of success= >> in >> 670 addressing the issues outlined in Section 1.1. The reflexive >> 671 forwarding extension may substantially ameliorate the documente= d >> 672 difficulties by allowing a different model for the basic >> interaction >> 673 of sensors with the ICN network. >> >> 675 Instead of acting as a producer (either directly to the Interne= t >> or >> 676 indirectly through the use of some form of application-layer >> 677 gateway), the IoT device need only act as a consumer. When it >> has >> 678 data to provide, it issues a "phone-home" Interest message to a= >> pre- >> 679 configured rendezvous name (e.g. an application-layer gateway o= r >> ICN >> 680 Repo [Chen2015]) and provides a reflexive name prefix TLV for t= he >> 681 data it wishes to publish. The target producer may then issue >> the >> 682 necessary reflexive Interest message(s) to fetch the data. Onc= e >> 683 fetched, validated, and stored, the producer then responds to t= he >> 684 original Interest message with a success indication, possibly >> 685 containing a Data object if needed to allow the originating >> device to >> 686 modify its internal state. Alternatively, the producer might >> choose >> 687 to not respond and allow the original Interest to time out, >> although >> 688 this is NOT RECOMMENDED except in cases where the extra message= >> 689 transmission bandwith is at a premium compared to the persisten= ce >> of >> 690 stale state in the forwarders. We note that this interaction >> 691 approach mirrors the earlier efforts using Interest-Interest-Da= ta >> 692 designs. >> >> 694 Figure 4 depicts this interaction with the OPTIONAL D1 message.= >> See >> 695 Figure 2 for the details of the general Reflexive Forwarding >> 696 interaction. >> >> 698 +-----------+ +-----------+ >> 699 | Consumer | | Producer | >> 700 +-----------+ +-----------+ >> 701 ------------\ | | >> 702 | new IoT |-| | >> 703 | data item | | | >> 704 | produced | | | >> 705 |-----------| | | >> 706 ---------------\ | | >> 707 | "phone home" |-| | >> 708 | by notifying | | | >> 709 | producer | | | >> 710 |--------------| | | >> 711 | | >> 712 | I1 | >> 713 |------------>| >> 714 | | --------------------\ >> 715 | |-| generate Interest | >> 716 | | | for IoT data | >> 717 | | |-------------------| >> 718 | | >> 719 | RI | >> 720 |<------------| >> 721 -----------------\ | | >> 722 | send requested |-| | >> 723 | data object | | | >> 724 |----------------| | | >> 725 | | >> 726 | D2 | >> 727 |------------>| >> 728 | | -----------------------\ >> 729 | |-| finalize interaction | >> 730 | | | with optional | >> 731 | | | Data message | >> 732 | | |----------------------| >> 733 | | >> 734 | D1 | >> 735 |<------------| >> 736 | | >> 737 Legend: >> 738 I1: Interest #1 containing the Reflexive Name Prefix TLV >> 739 D1: Data message (OPTIONAL), finalizing interaction >> 740 D1: Data message, answering RI, returning IoT data object >> >> 742 Figure 4: "Phone Home" Message Flow >> >> 744 There are two approaches that the IoT device can use for its >> response >> 745 to a reflexive Interest. It can simply construct a Data Messag= e >> 746 bound through the usual ICN hash name to the reflexive Interest= >> name. >> 747 Since the scope of any data object bound in this way is only th= e >> 748 duration of the enclosing Interest-Data exchange (see Section >> 8.2) >> 749 the producer would need to itself construct any persistent Data= >> 750 object, name it, and sign it. This is sometimes the right >> approach, >> 751 as for some applications the identity of the originating IoT >> device >> 752 is not important from an operational or security point of view;= >> in >> 753 contrast the identity of the gateway or Repo is what matters. >> >> 755 If alternatively, the persistent Data object should be bound fr= om >> a >> 756 naming and security point of view to the originating IoT device= , >> this >> 757 can be easily accomplished. Instead of directly placing the >> content >> 758 in a Data object responding to the reflexive Interest as above,= >> the >> 759 consumer encapsulates a complete CCNx/NDN Data message (which >> 760 includes the desired name of the data) as in the response to th= e >> 761 reflexive Interest message. >> >> 763 The interaction model described above brings a number potential= >> 764 advantages, some obvious, some less so. We enumerate a few of >> them >> 765 as follows: >> >> 767 * By not requiring the IoT device to be actively listening for= >> 768 Interests, it can sleep and only wake up if it has something= >> to >> 769 communicate. Conversely, parties interested in obtaining da= ta >> 770 from the device do not need to be constantly polling in orde= r >> to >> 771 ascertain if there is new data available. >> >> 773 * No forwarder resources are tied up with state apart from the= >> 774 actual reflexive forwarding interactions. All that is neede= d >> is >> 775 enough routing state in the FIB to be able to forward the >> "phone >> 776 home" Interest to an appropriate target producer. While thi= s >> 777 model does not provide all the richness of a full Pub/Sub >> system >> 778 (like that described in [Gundogan2018]) we argue it is >> adequate >> 779 for a large subclass of such applications. >> >> 781 * The reflexive interest, through either a name suffix or >> Interest >> 782 payload, can give the IoT device useful context from which t= o >> 783 craft its Data object in response. One highly useful >> parameter >> 784 would be a robust clock value for the device to use as a >> timestamp >> 785 of the data, possibly as part of its name to correctly place= >> it in >> 786 a time seres of sensor readings. This substantially >> alleviates >> 787 the need for low-end devices to have a robust time base, as >> long >> 788 as they trust the producer they contact to provide it. >> >> 790 8. Implementation Considerations >> >> 792 There are a number of important aspects to the reflexive >> forwarding >> 793 design which affect correctness and performance of existing >> 794 forwarder, consumer, and producer implementations desiring to >> support >> 795 it. This section discusses the effect on each of these element= s >> of >> 796 the CCNx/NDN protocol architecture. >> >> 798 8.1. Forwarder implementation considerations >> >> 800 8.1.1. Forwarding Information Base (FIB) >> >> 802 The FIB is a performance-critical data structure in any >> forwarder, as >> 803 it needs to support relatively expensive longest name prefix >> match >> 804 (LNPM) lookup algorithms. A number of well-known FIB data >> structures >> 805 are heavily optimized for read access, since for normal Interes= t >> 806 message processing the FIB changes slowly - only after >> topological >> 807 changes or routing protocol updates. Support for reflexive nam= es >> 808 changes this, as FIB entries are created and destroyed rapidly = as >> 809 Interest messages containing reflexive name TLVs are processed >> and >> 810 the corresponding Data messages come back. >> >> 812 While it may be feasible, especially in low-end forwarders >> handling a >> 813 low packet forwarding rate to ignore this problem, for high-spe= ed >> 814 forwarders there are a number of hazards, including: >> >> 816 1. If the entire FIB needs to be locked in order to insert or >> remove >> 817 entries, this could cause inflated forwarding delays or in >> 818 extreme cases, forwarding performance collapse. >> >> 820 2. A number of high-speed forwarder implementations employ a >> sharded >> 821 PIT scheme to better parallelize forwarding across processi= ng >> 822 cores. The FIB, however, is still a shared data structure >> which >> 823 is either read without read locks across cores, or explicit= ly >> 824 copied such that there is a separate copy of the FIB for ea= ch >> PIT >> 825 shard. Clearly, a high update rate without read locks and/= or >> 826 updating many copies of the FIB are unattractive >> implementation >> 827 options. (Note: with this reflexive name scheme it is not >> 828 feasible to force reflexive interests to be hashed or be >> 829 otherwise directed to the PIT shard holding the original >> Interest >> 830 state). >> >> 832 There are any number of alternative FIB implementations that ca= n >> work >> 833 well however. The most straightforward is to simply implement = a >> 834 "special" FIB for just reflexive name lookups. This is feasibl= e >> 835 because reflexive names deterministically contain the >> distinguished >> 836 high-order name component type of T_REFLEXIVE_NAME, whose conte= nt >> is >> 837 a 64-bit value that can be easily hashed to a FIB entry directl= y, >> 838 avoiding the more expensive LNPM lookup. Inserts and deletes >> then >> 839 devolve to the well-understood problem of hash table maintenanc= e. >> >> 841 8.1.2. Interactions with Interest Lifetime >> >> 843 If and when a producer decides to fetch data from the consumer >> using >> 844 one or more reflexive Interest-Data exchanges, the total latenc= y >> for >> 845 the original Interest-Data exchange is inflated, potentially by= >> 846 multiple RTTs. It is difficult for a consumer to predict the >> 847 inflation factor when issuing the original Interest, and hence >> there >> 848 can be a substantial hazard of that Interest lifetime expiring >> before >> 849 completion of the full multi-way exchange. This can result in >> 850 persistent failures, which is obviously highly undesirable. >> >> 852 There is a fairly straightforward technique that can be employe= d >> by >> 853 forwarders to avoid these "false" Interest lifetime expirations= =2E >> In >> 854 the absence of a superior alternative technique, it is >> RECOMMENDED >> 855 that all forwarders implement the following algorithm. >> >> 857 When processing an Interest containing the reflexive name TLV a= nd >> 858 creating the necessary FIB entry (see Section 8.1.1 above), the= >> 859 forwarder also creates a _back pointer_ from that FIB entry to >> the >> 860 PIT entry for the Interest message that created it. This PIT >> entry >> 861 contains the current value of the remaining Interest lifetime o= r >> 862 alternatively a value from which the remaining Interest lifetim= e >> can >> 863 be easily computed. Call this value _IL_(t)_. >> >> 865 If and when a reflexive Interest arrives from upstream matching= >> the >> 866 reflexive FIB entry, the forwarder examines the Interest lifeti= me >> of >> 867 the arriving reflexive Interest. Call this value _IL_(r)_. The= >> 868 forwarder computes MAX(_IL_(t), (IL_(r) * 1.5)_), and replaces >> 869 _IL_(t)_ with this value. This in effect ensures that the >> remaining >> 870 Interest lifetime of the original Interest accounts for the >> 871 additional 1.5 RTTs that may occur as a result of the reflexive= >> 872 Interest-Data exchange. >> >> 874 If the above algorithm is implemented naively as described abov= e, >> it >> 875 may run afoul of a sharded PIT forwarder implementation, since >> the >> 876 PIT entry for the reflexive Interest and the PIT entry for the >> 877 original Interest may be in different shards. Therefore, if th= e >> 878 update is done cross-shard on each reflexive Interest arrival, >> 879 performance may suffer, perhaps dramatically. Instead, the >> following >> 880 approach to updating the Interest lifetime after computing the >> new >> 881 value is RECOMMMENDED for sharded-PIT forwarders. >> >> 883 When creating the reflexive FIB entry as above in Section 8.1.1= , >> copy >> 884 the remaining Interest lifetime from the PIT entry. Do the PIT= >> 885 update if and only if this value is about to expire, thus payin= g >> the >> 886 cross-shard update cost only if the original Interest is about = to >> 887 expire. A further optimization at the cost of modest extra >> 888 complexity is to instead _queue_ the update to the core holding= >> the >> 889 shard of the original PIT entry rather than doing the update >> 890 directly. If the PIT entry expires or is satisfied, instead of= >> 891 removing it the associated core checks the update queue and doe= s >> the >> 892 necessary update. >> >> 894 While the above approach of inflating the interest lifetime of >> the >> 895 original Interest to accommodate the additional RTTs of reflexi= ve >> 896 Interest-Data exchanges, this does introduce a new vulnerabilit= y >> that >> 897 must be dealt with. A Producer, either through a bug or >> malicious >> 898 intent, could keep an originating Interest-Data exchange alive = by >> 899 continuing to send reflexive Interests back to the consumer, >> while >> 900 the consumer had no way to terminate the enclosing interaction >> (there >> 901 is no "cancel Interest" function in either NDN nor CCNx). To >> 902 eliminate this hazard, if the consumer rejects a reflexive >> interest >> 903 with a T_RETURN_PROHIBITED error, the forwarder(s), in addition= >> to >> 904 satisfying the coresponding PIT entry, MUST also delete the >> 905 associated reflexive FIB entry, thereby preventing any further >> 906 reflexive Interests from reaching the consumer. This allows th= e >> 907 enclosing Interest-Datsa exchange to either time out or be >> correctly >> 908 ended with a Data message or Interest Return from the Producer.= >> >> 910 8.1.3. Interactions with Interest aggregation >> >> 912 As with numerous other situations where multiple Interests for >> the >> 913 same named object arrive containing different parameters (e.g. >> 914 Interest Lifetime, QoS, payload hash) the same phenomenon occur= s >> for >> 915 the reflexive Name TLV. If such Interests collide, the forward= er >> 916 MUST NOT aggregate these Interest messages and instead MUST >> create a >> 917 separate PIT entry for each. >> >> 919 8.2. Consumer Implementation Considerations >> >> 921 8.2.1. Data objects returned by the consumer to reflexive name >> 922 Interests arriving from a producer >> >> 924 The Data objects returned to the producer in response to a >> reflexive >> 925 Interest are normal CCNx/NDN data objects. It is therefore wor= th >> 926 noting that the object is bound to the reflexive Interest full >> name >> 927 via the hash and hence the scope of the object is under most >> 928 circumstances meaningful only for the duration of the enclosing= >> 929 Interest-Data interaction. This property is ideal for naming a= nd >> 930 securing data that is "part of" the enclosing interaction - >> things >> 931 like method arguments, authenticators, and key exchange >> parameters, >> 932 but not for the creation and naming of objects intended to >> survive >> 933 outside the current interaction's scope (c.f. Section 7.3, whi= ch >> 934 describes how to provide globally-named objects using >> encapsulation). >> 935 In general, the consumer should use the following guidelines in= >> 936 creating Data messages in response to reflexive Interest messag= es >> 937 from the producer. >> >> 939 (a) Set the recommended cache time (T_CACHETIME) either to zer= o, >> or >> 940 a value no greater than the Interest lifetime (T_INTLIFE) = of >> the >> 941 original Interest messsage. >> >> 943 (b) Set the payload type (T_PAYLDTYPE) according to the type o= f >> 944 object being returned (e.g. object, link, manifest) >> >> 946 (c) Set the expiry time (T_EXPIRY) to a value greater than >> _now_, >> 947 and less than or equal to the _now_ + Interest lifetime >> 948 (T_INTLIFE) of the original Interest messsage. >> >> 950 8.2.2. Terminating unwanted reflexive Interest exchanges >> >> 952 A consumer may wish to stop receiving reflxive Interests due to= >> 953 possible erors or malicious behavior on the part of the produce= r. >> 954 Therefore, if the consumer receives an unwanted reflexive >> Interest, >> 955 it SHOULD reject that interest with a T_RETURN_PROHIBITED error= =2E >> 956 This will provoke the forwarders to prevent further reflexive >> 957 Interests from reaching the consumer, as described above in >> 958 Section 8.1.2, Paragraph 7. >> >> 960 8.2.3. Interactions with caching >> >> 962 The reflexive named objects provide "local", temporary names th= at >> are >> 963 only defined for one specific interaction between a consumer an= d >> a >> 964 producer. Corresponding Data objects MUST NOT be shared betwee= n >> 965 multiple consumers (violating this would require specail >> gyrations by >> 966 the producer since the reflexive Name utilizes per-consumer/per= - >> 967 interaction random values). A producer MUST NOT issue an >> Interest >> 968 message for any reflexive name after it has sent the final Data= >> 969 message answering the original Interest. >> >> 971 Forwarders SHOULD still cache reflexive Data objects for >> 972 retransmissions within a transactions, but they MUST remove the= m >> from >> 973 the content store when they forward the final Data message >> answering >> 974 the original Interest. >> >> 976 8.3. Producer Implementation Considerations >> >> 978 Producers receiving an Interest with a Reflexive Name Component= , >> MAY >> 979 decide to issue Interests for the corresponding Data objects. >> All >> 980 Reflexive Interest message that a producer sends MUST be sent >> over >> 981 the face that the original Interest was received on. >> >> 983 9. Operational Considerations >> >> 985 This extension represents a substantial enhancement to the >> CCNx/NDN >> 986 protocol architecture and hence has important forward and >> backward >> 987 compatibility effects. The most important of these is that >> correct >> 988 operation of the scheme requires an unbroken chain of forwarder= s >> 989 between the consumer and the desired producer that support the >> 990 Reflexive Name TLV and the corresponding forwarder capabilities= >> 991 specified in Section 5. When this invariant is not satisfied, >> some >> 992 means is necessary to detect and hopefully recover from the >> error. >> 993 We have identified three possible approaches to handling the la= ck >> of >> 994 universal deployment of forwarders supporting the reflexive >> 995 forwarding scheme. >> >> 997 The first approach simply lets the producer detect the error by= >> 998 getting a "no route to destination" error when trying to send a= n >> 999 Interest to a reflexive name. This will catch the error, but >> only >> 1000 after forwarding resources are tied up and the producer has do= ne >> some >> 1001 work on the original Interest message. Further, the producer >> would >> 1002 need a bit of smarts to determine that this is a permanent err= or >> and >> 1003 not a transient to be retried. In order for the consumer to >> attempt >> 1004 recovery, there might be a need for some explicit error return= ed >> for >> 1005 the original interest to tell the consumer what the likely >> problem >> 1006 is. This approach does not enable an obvious recovery path fo= r >> the >> 1007 consumer either, since while we might envision a way to steer = a >> 1008 subsequent Interest onto a working path as proposed in >> 1009 [I-D.oran-icnrg-pathsteering], there is no capability to force= >> 1010 Interest routing away from an otherwise working path not >> supporting >> 1011 the reflexive name TLV. >> >> 1013 A second approach is to bump the CCNx/NDN protocol version to >> 1014 explicitly indicate the lack of comparability. Such Interests= >> would >> 1015 be rejected by forwarders not supporting this protocol >> extension. A >> 1016 consumer wishing to use the reflexive name TLV would use the >> higher >> 1017 protocol version on those Interest messages (but could of cour= se >> 1018 continue to use the current version number on other Interest >> 1019 messages). This is a big hammer, but may be called for in thi= s >> 1020 situation because: >> >> 1022 (a) it detects the problem immediately and deterministically,= >> and >> >> 1024 (b) one could assume an ICN routing protocol that would only >> forward >> 1025 to a next hop that supports the updated protocol version >> number. >> 1026 The supported forwarder protocol versions would have been= >> 1027 communicated in the routing protocol ahead of time. >> >> 1029 A third option is to, as a precondition utilizing the protocol= >> in a >> 1030 deployment, create and deploy a neighbor capability exchange >> protocol >> 1031 which will tell a downstream forwarder if the upstream can >> handle the >> 1032 new TLV. This might avoid the large hammer of updating the >> protocol >> 1033 version, but of course this puts a pretty strong dependency on= >> 1034 somebody actually designing and publishing such a protocol! O= n >> the >> 1035 other hand, a neighbor capability exchange protocol for CCNx/N= DN >> 1036 would have a number of other substantial benefits, which makes= >> it >> 1037 worth seriously considering anyway. >> >> 1039 10. Mapping to CCNx and NDN packet encodings >> >> 1041 10.1. Packet encoding for CCNx >> >> 1043 For CCNx[RFC8569] there is one new Name Component TLV type >> defined in >> 1044 this specification. >> >> 1046 = >> +------------------+----------------+--------------------------+ >> 1047 | Abbrev | Name | Description >> | >> 1048 = >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >> 1049 | T_REFLEXIVE_NAME | Reflexive Name | Name component to use = as >> | >> 1050 | | Component | name prefix in Reflexi= ve >> | >> 1051 | | | Interest Message >> | >> 1052 = >> +------------------+----------------+--------------------------+ >> >> 1054 Table 1: Reflexive Name TLV >> >> 1056 10.2. Packet encoding for NDN >> >> 1058 TBD based on [NDNTLV]. Suggestions from the NDN team greatly >> 1059 appreciated. >> >> 1061 11. IANA Considerations >> >> 1063 Please add the T_REFLEXIVE_NAME component TLV to the CCNx Name= >> types >> 1064 TLV types registry of [RFC8609], with Length 9 bytes and type = of >> 64 >> 1065 bit random integer. >> >> 1067 1 2 3= >> 1068 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1 >> 1069 = >> +---------------+---------------+---------------+---------------+ >> 1070 | T_REFLEXIVE_NAME | 8 >> | >> 1071 = >> +---------------+---------------+---------------+---------------+ >> 1072 | >> | >> 1073 | 64bit Integer randomly assigned by consumer >> | >> 1074 = >> +-------------------------------+-------------------------------+ >> >> 1076 Figure 5: Reflexive Name component type >> >> 1078 12. Security Considerations >> >> 1080 One of the major motivations for the reflexive forwarding >> extension >> 1081 specified in this document is in fact to enable better securit= y >> and >> 1082 privacy characteristics for ICN networks. The main >> considerations >> 1083 are presented in Section 1, but we briefly recapitulate them >> here: >> >> 1085 * Current approaches to authentication and data transfer ofte= n >> use >> 1086 payloads in Interest messages, which are clumsy to secure >> 1087 (Interest messages must be signed) and as a consequence mak= e >> it >> 1088 very difficult to ensure consumer privacy. Reflexive >> forwarding >> 1089 moves all sensitive data to the Data messages sent in >> response to >> 1090 reflexive Interests, which are secured in the same manner a= s >> all >> 1091 other Data messages in the CCNx and NDN protocol designs. >> >> 1093 * In many scenarios, consumers are forced to also act as >> producers >> 1094 so that data may be fetched by either a particular, or >> arbitrary >> 1095 other party. The means the consumer must arrange to have a= >> 1096 routable name prefix and that prefix be disseminated by the= >> 1097 routing protocol or other means. This represents both a >> privacy >> 1098 hazard (by revealing possible important information about t= he >> 1099 consumer) and a security concern as it opens up the consume= r >> to >> 1100 the full panoply of flooding and crafted Interest denial of= >> 1101 service attacks. >> >> 1103 * In order to achieve multi-way handshakes, in current design= s >> a >> 1104 consumer wishing a producer to communicate back must inform= >> the >> 1105 producer of what (globally routable) name to use. This giv= es >> the >> 1106 consumer a convenient means to mount a variety of reflectio= n >> 1107 attacks by enlisting the producer to send Interests to >> desired >> 1108 victims. >> >> 1110 As a major protocol extension however, this design brings its >> own >> 1111 potential security issues, which are discussed in the followin= g >> 1112 subsections. >> >> 1114 12.1. Collisions of reflexive Interest names >> >> 1116 Reflexive Interest names are constructed using 64-bit random >> numbers. >> 1117 This is intended to ensure an off-path attacker cannot easily >> 1118 manufacture a matching reflexive Interest and either masquerad= e >> as >> 1119 the producer, or mount a denial of service attack on the >> consumer. >> 1120 It also limits tracking through the linkability of Interests >> 1121 containing a re-used random value. >> >> 1123 Therefore consumers MUST utilize a robust means of generating >> these >> 1124 random values, and it is RECOMMENDED that a pseudo-random numb= er >> 1125 generator (PRNG) approved for use with cryptographic protocols= >> be >> 1126 employed. >> >> 1128 12.2. Additional resource pressure on PIT and FIB >> >> 1130 Normal Interest message processing in CCNx and NDN needs to >> consider >> 1131 effect of various resource depletion attacks on the PIT, >> particularly >> 1132 in the form of Interest flooding attacks (see [Gasti2012] for = a >> good >> 1133 overview of DoS and DDoS mitigation on ICN networks). Interes= t >> 1134 messages utilizing this reflexive forwarding extension can pla= ce >> 1135 additional resource pressure on the PIT, and additionally caus= e >> 1136 otherwise stable FIB resources to be subject to highly dynamic= >> usage. >> >> 1138 While this does not represent a new DoS/DDoS attack vector, th= e >> 1139 ability of a malicious consumer to utilize this extension in a= n >> 1140 attack does represent an increased risk of resource depletion,= >> 1141 especially if such Interests are given unfair access to PIT an= d >> FIB >> 1142 resources. Implementers SHOULD therefore protect PIT and FIB >> 1143 resources by weighing requests for reflexive forwarding >> resources >> 1144 appropriately relative to other Interests. >> >> 1146 12.3. Privacy Considerations >> >> 1148 ICN architectures like CCNx and NDN provide a rich tapestry of= >> 1149 interesting privacy issues, which have been extensively explor= ed >> in >> 1150 the research literature. The fundamental tradeoffs for privac= y >> 1151 concern the risk of exposing the names of information objects = to >> the >> 1152 forwarding elements of the network, which is a necessary >> property of >> 1153 any name-based routing and forwarding design. Numerous >> approaches >> 1154 have been explored with varying degrees of success, such as >> onion >> 1155 routing ([DiBenedettoGTU12]), name encryption ([Ghali2017]), a= nd >> name >> 1156 obfuscation ([Arianfar2011]) among others. >> >> 1158 Reflexive forwarding does not change the overall landscape of >> privacy >> 1159 tradeoffs, nor seem to introduce additional hazards. In fact,= >> the >> 1160 privacy exposures are confined to the inverse path of forwarde= rs >> from >> 1161 the producer to the consumer, through which the original >> Interest >> 1162 forwarding may have already exposed names on path. Similar na= me >> 1163 privacy techniques to those cited above may be equally applied= >> to the >> 1164 names in reflexive Interests. >> >> 1166 While the individual reflexive Interest-Data exchanges have >> similar >> 1167 properties to those in any NDN or CCNx exchange, the target >> usages by >> 1168 applications may have interaction patterns that are subject to= >> 1169 relatively straightforward fingerprinting by adversaries. For= >> 1170 example, a particular RMI invocation may fingerprint simply >> through >> 1171 the count of arguments fetched by the producer and their sizes= =2E >> The >> 1172 attacker must however be on path, which somewhat ameliorates t= he >> 1173 exposure hazards. >> >> 1175 13. Normative References >> >> 1177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate= >> 1178 Requirement Levels", BCP 14, RFC 2119, >> 1179 DOI 10.17487/RFC2119, March 1997, >> 1180 . >> >> 1182 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric= >> 1183 Networking (CCNx) Semantics", RFC 8569, >> 1184 DOI 10.17487/RFC8569, July 2019, >> 1185 . >> >> 1187 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric= >> 1188 Networking (CCNx) Messages in TLV Format", RFC 8609= , >> 1189 DOI 10.17487/RFC8609, July 2019, >> 1190 . >> >> 1192 14. Informative References >> >> 1194 [Arianfar2011] >> 1195 Arianfar, S., Koponen, T., Raghavan, B., and S. >> Shenker, >> 1196 "On preserving privacy in content-oriented networks= , >> in >> 1197 ICN '11: Proceedings of the ACM SIGCOMM workshop on= >> 1198 Information-centric networking", >> 1199 DOI https://doi.org/10.1145/2018584.2018589, August= >> 2011, >> 1200 . >> >> 1202 [Auge2018] Aug=C3=A9, J., Carofiglio, G., Grassi, G., Muscarie= llo, >> L., >> 1203 Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less= >> 1204 Producer Mobility in Content-Centric Networks, in >> IEEE >> 1205 Transactions on Network, Volume 15, Issue 2", >> 1206 DOI 10.1109/TNSM.2018.2796720, June 2018, >> 1207 . >> >> 1209 [Baccelli2014] >> 1210 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., an= d >> M. >> 1211 W=C3=A4hlisch, "Information centric networking in t= he >> IoT: >> 1212 experiments with NDN in the wild, in ACM-ICN '14: >> 1213 Proceedings of the 1st ACM Conference on Informatio= n- >> 1214 Centric Networking", DOI 10.1145/2660129.2660144, >> 1215 September 2014, >> 1216 . >> >> 1218 [Carzaniga2011] >> 1219 Carzaniga, A., Papalini, M., and A.L. Wolf, >> "Content-Based >> 1220 Publish/Subscribe Networking and Information-Centri= c >> 1221 Networking", DOI 10.1145/2018584.2018599, September= >> 2011, >> 1222 = >> > 1223 p56.pdf>. >> >> 1225 [Chen2015] Chen, S., Cao, J., and L. Zhu, "NDSS: A Named Data >> Storage >> 1226 System, in International Conference on Cloud and >> Autonomic >> 1227 Computing", DOI 10.1109/ICCAC.2015.12, September >> 2014, >> 1228 . >> >> 1230 [DiBenedettoGTU12] >> 1231 DiBenedetto, S., Gasti, P., Tsudik, G., and E. Uzun= , >> 1232 "ANDaNA: Anonymous Named Data Networking Applicatio= n, >> in >> 1233 NDSS 2012", DOI https://arxiv.org/abs/1112.2205v2, >> 2102, >> 1234 = >> > 1235 named-data-networking-application>. >> >> 1237 [Gasti2012] >> 1238 Gasti, P., Tsudik, G., Uzun, Ersin., and L. Zhang, >> "DoS >> 1239 and DDoS in Named Data Networking, in 22nd >> International >> 1240 Conference on Computer Communication and Networks >> 1241 (ICCCN)", DOI 10.1109/ICCCN.2013.6614127, August >> 2013, >> 1242 . >> >> 1244 [Ghali2017] >> 1245 Tsudik, G., Ghali, C., and C. Wood, "When encryptio= n >> is >> 1246 not enough: privacy attacks in content-centric >> networking, >> 1247 in ICN '17: Proceedings of the 4th ACM Conference o= n >> 1248 Information-Centric Networking", >> 1249 DOI https://doi.org/10.1145/3125719.3125723, >> September >> 1250 2017, >> 1251 . >> >> 1253 [Gundogan2018] >> 1254 G=C3=BCndo=C4=9Fan, C., Kietzmann, P., Schmidt, T.,= and M. >> W=C3=A4hlisch, >> 1255 "HoPP: publish-subscribe for the constrained IoT, i= n >> ICN >> 1256 '18: Proceedings of the 5th ACM Conference on >> Information- >> 1257 Centric Networking", DOI 10.1145/3267955.3269020, >> 1258 September 2018, >> 1259 . >> >> 1261 [I-D.irtf-icnrg-flic] >> 1262 Tschudin, C., Wood, C., Mosko, M., and D. Oran, >> "File-Like >> 1263 ICN Collections (FLIC)", Work in Progress, >> Internet-Draft, >> 1264 draft-irtf-icnrg-flic-02, 4 November 2019, >> 1265 = >> . >> >> 1267 [I-D.irtf-icnrg-terminology] >> 1268 Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., >> Oran, >> 1269 D., and C. Tschudin, "Information-Centric Networkin= g >> 1270 (ICN): CCNx and NDN Terminology", Work in Progress,= >> 1271 Internet-Draft, draft-irtf-icnrg-terminology-08, 17= >> 1272 January 2020, >> > 1273 icnrg-terminology-08>. >> >> 1275 [I-D.oran-icnrg-pathsteering] >> 1276 Moiseenko, I. and D. Oran, "Path Steering in CCNx a= nd >> 1277 NDN", Work in Progress, Internet-Draft, >> draft-oran-icnrg- >> 1278 pathsteering-00, 21 October 2019, >> 1279 > 1280 pathsteering-00>. >> >> 1282 [Krol2018] Krol, M., Habak, K., Oran, D., Kutscher, D., and I.= >> 1283 Psaras, "RICE: Remote Method Invocation in ICN, in >> 1284 Proceedings of the 5th ACM Conference on Informatio= n- >> 1285 Centric Networking - ICN '18", >> 1286 DOI 10.1145/3267955.3267956, September 2018, >> 1287 = >> > 1288 icn18-final9.pdf>. >> >> 1290 [Lindgren2016] >> 1291 Lindgren, A., Ben Abdessiem, F., Ahlgren, B., >> Schlel=C3=A9n, >> 1292 O., and A.M. Malik, "Design choices for the IoT in >> 1293 Information-Centric Networks, in 13th IEEE Annual >> Consumer >> 1294 Communications and Networking Conference (CCNC)", >> 1295 DOI 10.1109/CCNC.2016.7444905, January 2016, >> 1296 = >> . >> >> 1298 [Moiseenko2014] >> 1299 Moiseenko, I., Stapp, M., and D. Oran, "Communicati= on >> 1300 patterns for web interaction in named data >> networking", >> 1301 DOI 10.1145/2660129.2660152, September 2014, >> 1302 . >> >> 1304 [Mosko2017] >> 1305 Mosko, M., "CCNx 1.0 Bidirectional Streams", >> 1306 arXiv 1707.04738, July 2017, >> 1307 . >> >> 1309 [NDN] "Named Data Networking", 2020, >> 1310 . >> >> 1312 [NDNTLV] "NDN Packet Format Specification", 2016, >> 1313 . >> >> 1315 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., >> Johnston, >> 1316 A., Peterson, J., Sparks, R., Handley, M., and E. >> 1317 Schooler, "SIP: Session Initiation Protocol", RFC >> 3261, >> 1318 DOI 10.17487/RFC3261, June 2002, >> 1319 . >> >> 1321 [RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session >> 1322 Initiation Protocol (SIP) Usage of the Offer/Answer= >> 1323 Model", RFC 6337, DOI 10.17487/RFC6337, August 2011= , >> 1324 . >> >> 1326 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File >> System >> 1327 (NFS) Version 4 Protocol", RFC 7530, DOI >> 10.17487/RFC7530, >> 1328 March 2015, >> . >> >> 1330 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) >> Protocol >> 1331 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, Augus= t >> 2018, >> 1332 . >> >> 1334 [Zhang2018] >> 1335 Zhang, Y., Xia, Z., Mastorakis, S., and L. Zhang, >> "KITE: >> 1336 Producer Mobility Support in Named Data Networking,= >> in >> 1337 Proceedings of the 5th ACM Conference on Informatio= n- >> 1338 Centric Networking - ICN '18", >> 1339 DOI 10.1145/3267955.3267959, September 2018, >> 1340 = >> > 1341 icn18-final23.pdf>. >> >> 1343 Authors' Addresses >> >> 1345 Dave Oran >> 1346 Network Systems Research and Design >> 1347 4 Shady Hill Square >> 1348 Cambridge, MA 02138 >> 1349 United States of America >> >> 1351 Email: daveoran@orandom.net >> >> 1353 Dirk Kutscher >> 1354 University of Applied Sciences Emden/Leer >> 1355 Constantiapl. 4 >> 1356 26723 Emden >> 1357 Germany >> >> 1359 Email: ietf@dkutscher.net >> 1360 URI: https://dirk-kutscher.info >> >> >> >> >> >> >> >> >> >> >> DaveO >> >> >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >> DaveO --=_MailMate_CEA6EA1B-A29A-455E-AFB3-5FC5B40E6AB8_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQJJBAEBAgAzFiEEroJBCc9z/EJK1xs/eu0uvThCv/AFAl6F784VHGRhdmVvcmFu QG9yYW5kb20ubmV0AAoJEHrtLr04Qr/wAdgP/2rdGkYfpx/PfE8dxll8sOBAovbC qZrkAB1V8uCr+jvVqTXSGow5nklNX3MDNtS/eJT/S1o2hIJ4u2uD3W40yVbaAYil zkrBsrT51kKdmv6EJ+ib/oF6Rt36AZuFGXUJ/5wviv/ec0lIqR8j+nQcUkVk996r PkhNJkalnSglDUXxgU9L6yy4TYdvOdC74p4uMV+twTgMPzzRP0m5ZFNGHzDrNvHK wzTBKcCjfJwpv8/n6ILa2cp25u366Ys+9hkBI28mpRe/kt3P2c/Hor9BqP9qRK8+ EUDfZ91zVRP3YAuW1LzPcZSwpHk3KYMWDi9Vg9ODpL3M17Upr2ay+vBGArNVD3iw eHx6KAflJWyqOFFssrzf2R+Xrhur6EDax299V+POdpKCPoRWUUQfUSK9RC+NJKwc YwGLYvT3jPLyrHC5VPqKVhyi8q8S5XC9kphuS3JP6VOJ9burAhMOISjDmVQDwjod ovbKCWtcEGo7daLh/KDlUmNJqlsmeI1nOOffGnqm5kOs43ulEii7iY/wI5EtDtWz 9z5l4bCE+C91HHmzeWv5MaaXBmVnrrmMMVZ10LJceWHoSQYRvtHDIvus9ugxvtVm ss9IHFmnXwu7vsZjtrs/8KNumPRbrsm8m1dix7p054SpM8Pn0qcqfKLt94unIe2j BJpZbaBHwEefwNWQ =YF6U -----END PGP SIGNATURE----- --=_MailMate_CEA6EA1B-A29A-455E-AFB3-5FC5B40E6AB8_=-- From nobody Thu Apr 2 07:10:35 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19E53A1405 for ; Thu, 2 Apr 2020 07:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9971nTEdjOZr for ; Thu, 2 Apr 2020 07:10:22 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A453A132A for ; Thu, 2 Apr 2020 07:10:12 -0700 (PDT) Received: from [192.168.15.102] ([IPv6:2601:184:407f:80ce:c105:8cce:5bc6:3a67]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 032EA97f008463 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 2 Apr 2020 07:10:11 -0700 From: "David R. Oran" To: xml2rfc@ietf.org Date: Thu, 02 Apr 2020 10:10:04 -0400 X-Mailer: MailMate (1.13.1r5680) Message-ID: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Archived-At: Subject: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 14:10:32 -0000 I tried to submit a V3 draft today by uploading the .txt, and got: Failed decoding the uploaded file: "'ascii' codec can't decode byte 0xc3 in position 69240: ordinal not in range(128)" this is in an element which in my .xml file is: But the .txt output of xml2rfc generates: [Auge2018] Augé, J., Carofiglio, G., Grassi, G., Muscariello, L., Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less Producer Mobility in Content-Centric Networks, in IEEE Transactions on Network, Volume 15, Issue 2", DOI 10.1109/TNSM.2018.2796720, June 2018, . Am I missing something obvious or is this a bug? DaveO From nobody Thu Apr 2 07:21:11 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A8D3A136C for ; Thu, 2 Apr 2020 07:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjmIVP_Xz5vX for ; Thu, 2 Apr 2020 07:21:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C483A1363 for ; Thu, 2 Apr 2020 07:21:06 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:56753 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jK0i5-0003Hz-Up; Thu, 02 Apr 2020 07:21:06 -0700 To: "David R. Oran" , xml2rfc@ietf.org References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> From: Henrik Levkowetz Message-ID: Date: Thu, 2 Apr 2020 16:20:38 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="in9ikObSnXA77r4IUgRfnQ8V9bKNOgowj" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, daveoran@orandom.net X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 14:21:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --in9ikObSnXA77r4IUgRfnQ8V9bKNOgowj Content-Type: multipart/mixed; boundary="5ubAIq6UVrakpfijw2lMfhkcsu4Cj6Msc"; protected-headers="v1" From: Henrik Levkowetz To: "David R. Oran" , xml2rfc@ietf.org Message-ID: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> In-Reply-To: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> --5ubAIq6UVrakpfijw2lMfhkcsu4Cj6Msc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi David, On 2020-04-02 16:10, David R. Oran wrote: > I tried to submit a V3 draft today by uploading the .txt, and got: >=20 > Failed decoding the uploaded file: "'ascii' codec can't decode byte 0xc= 3=20 > in position 69240: ordinal not in range(128)" >=20 > this is in an element which in my .xml file is: >=20 > asciiSurname=3D"Auge" asciiFullname=3D"Jordan Auge"/> >=20 > But the .txt output of xml2rfc generates: >=20 > [Auge2018] Aug=C3=A9, J., Carofiglio, G., Grassi, G., Muscariello, = L., > Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less > Producer Mobility in Content-Centric Networks, in IEEE > Transactions on Network, Volume 15, Issue 2", > DOI 10.1109/TNSM.2018.2796720, June 2018, > . >=20 >=20 > Am I missing something obvious or is this a bug? This is probably caused by the file being identified as having ascii encoding by the uploading browser. There are currently two workarounds: Upload the XML and let the submission tool do the conversion, or use the --bom switch to generate an initial BOM in the file, which will let the browser identify the file as UTF-8, which should result in the right handling in the submission tool. Best regards, Henrik --5ubAIq6UVrakpfijw2lMfhkcsu4Cj6Msc-- --in9ikObSnXA77r4IUgRfnQ8V9bKNOgowj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl6F9LYACgkQTptXS4+7 FxrXfxAAjuH5K/kn2jHB843EXMF5JA9HB0eoQn1wN7x69Py08MnF6qOk5V9QjHiV E8pmfByFLy0AwSSho4Oe69VvLpVt709MIIrMxIWm2+3MaU8jbkvuB+HbJullvHn6 djEfvxepU54mzjxXdW6m1NMFCoiTtinNNErT16/uagBQ9o/mZAYtw0favbabzCNw EGafnKtghw/IaIDIO1J0Dg5r27t2Wym+G+uLTojm6xuUzxdfDzx7JQaEsgp+Ln+1 /PB1aVkqLiWLRbvqPP0n6ZYCy5zgyfniwcE3++xk8MMFqJGgU9Zhs7GuaiKb3R0l nuYBsbWkm0af/GZMRJSTX9uZzEECwj5GVglWe79MEovqCBUdxQaS3yJqTHG6sFxr cMEgWXrzFIRgs3C6h4YjQ1JNNCK2O3nwaNbP6cBYrGgafMJ1zyKV2vufJBTcKfQW iW8LaxRxFA7pSYyiud7qUlQIr6qHKItbl7WDs3QPzg4IbK+xNRUGrWrvSQ81PfBN U73wnvPj2jk1w76RUH9J+w86Rc6N6lEEM0IXFb4HaALgv281vTW/kX3dJxbWNHaA YsrCVw4/lmKztmBL4kzmLoZKC4LVvUx4LGCwabMmChBKQRhDT5OIGAZOSnkhFhvr clOm31fxwn5MVOkFf0eyn7msT243QmqvC+5ytCaFWB8vsBWFng4= =l1E2 -----END PGP SIGNATURE----- --in9ikObSnXA77r4IUgRfnQ8V9bKNOgowj-- From nobody Thu Apr 2 07:36:11 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CE43A1397 for ; Thu, 2 Apr 2020 07:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rAt3rALM-zo for ; Thu, 2 Apr 2020 07:36:08 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E853A1390 for ; Thu, 2 Apr 2020 07:36:07 -0700 (PDT) Received: from [192.168.15.102] ([IPv6:2601:184:407f:80ce:c105:8cce:5bc6:3a67]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 032Ea47v009183 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Apr 2020 07:36:06 -0700 From: "David R. Oran" To: "Henrik Levkowetz" Cc: xml2rfc@ietf.org Date: Thu, 02 Apr 2020 10:35:58 -0400 X-Mailer: MailMate (1.13.1r5680) Message-ID: <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> In-Reply-To: References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_EDD23B26-FF7F-4C4E-AE4E-9CA50DA7138E_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 14:36:10 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_EDD23B26-FF7F-4C4E-AE4E-9CA50DA7138E_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 2 Apr 2020, at 10:20, Henrik Levkowetz wrote: > Hi David, > > On 2020-04-02 16:10, David R. Oran wrote: >> I tried to submit a V3 draft today by uploading the .txt, and got: >> >> Failed decoding the uploaded file: "'ascii' codec can't decode byte 0x= c3 >> in position 69240: ordinal not in range(128)" >> >> this is in an element which in my .xml file is: >> >> > asciiSurname=3D"Auge" asciiFullname=3D"Jordan Auge"/> >> >> But the .txt output of xml2rfc generates: >> >> [Auge2018] Aug=C3=A9, J., Carofiglio, G., Grassi, G., Muscariello,= L., >> Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less >> Producer Mobility in Content-Centric Networks, in IEEE >> Transactions on Network, Volume 15, Issue 2", >> DOI 10.1109/TNSM.2018.2796720, June 2018, >> . >> >> >> Am I missing something obvious or is this a bug? > > This is probably caused by the file being identified as having ascii > encoding by the uploading browser. There are currently two workarounds= : > Upload the XML and let the submission tool do the conversion, I can=E2=80=99t - it has included files and there seems to be no way to u= pload dependencies. Or am I missing something? > or use the > --bom switch to generate an initial BOM in the file, which will let the= > browser identify the file as UTF-8, which should result in the right > handling in the submission tool. > Ah, that worked. Didn=E2=80=99t know about that option. Good to know for = future reference. > > Best regards, > > Henrik DaveO --=_MailMate_EDD23B26-FF7F-4C4E-AE4E-9CA50DA7138E_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQJJBAEBAgAzFiEEroJBCc9z/EJK1xs/eu0uvThCv/AFAl6F+E8VHGRhdmVvcmFu QG9yYW5kb20ubmV0AAoJEHrtLr04Qr/w1vEP/iACjPZbprFKlXlgQE+B6Uumw605 hJ9vgNxs/l+ZqcX72LhhCF1OoDnYtJb5Ki5He8N+C9zoWWZa5Jb69pkMuXOQn3oC C9ReYVnEfhUKEkSSqShvt/1PMJir4gDL2Q/ctOrPVDc9Gt4kN9/emvdN6ZWOe3Lg kG5Q+BukoF9MiX3NjXriyLh0agQz2mKiM5dRUZkNKTRxOu67mHuU1iFyphlbBCD2 WY5c7Pk+FIXIXTe+T8CY6FJPaYhuNKGIk1UCdwCZBOz8qbOsZ1zUu3HUtzpdCSeb mv9vXYhISOaQ1EwAC6MJ5tM8RUyclU6uVJ7KfwNugatifOUakhpMhsdwJciBpLUD hnNEk6lqRp+TozygczA57ZfJi2cBdf6MjCLxyxHkXkQTBnIr9n3524Z82CJ3VetL ++ltjbw6rcqq4xdFKkoVwP9vvxHYs4YGWAne2LHZZs8pU1eddMZ5HRL57U9e5MBo jOO9bhgbFkk6IMrEKTv9hh7W3vh6zlWfAhl6KDWHdY3+IhUMz1McNmjFGgpawea5 se2v0w3g/JdHva1tGbsR+wv8oxA5ofd1PdynnBbuKaxnNJEHdx8icbBtUCaw9LGn 7Mx7uUM/ukfOSAK8rH0JOILe3AaqsIhjIsqaNod+inIr1NaLVzXL26O2qeXmf0qA 2vrUe6KqR1YpW/LI =bJzL -----END PGP SIGNATURE----- --=_MailMate_EDD23B26-FF7F-4C4E-AE4E-9CA50DA7138E_=-- From nobody Thu Apr 2 07:41:15 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EEC3A13B1 for ; Thu, 2 Apr 2020 07:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KDkULfP9_dG for ; Thu, 2 Apr 2020 07:41:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84CA43A13AA for ; Thu, 2 Apr 2020 07:41:06 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:56854 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jK11L-0008EK-I4; Thu, 02 Apr 2020 07:41:05 -0700 To: "David R. Oran" References: <0F30FE8F-15D8-410B-9615-0FE9615148FA@orandom.net> Cc: xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: Date: Thu, 2 Apr 2020 16:40:32 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0F30FE8F-15D8-410B-9615-0FE9615148FA@orandom.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KjDVPXut9bS243k9aQUXJ2kAAWMH9vk7i" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, daveoran@orandom.net X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Some problems with idnits checks on V3 document X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 14:41:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KjDVPXut9bS243k9aQUXJ2kAAWMH9vk7i Content-Type: multipart/mixed; boundary="sVIEONXDRqgsflUFIXliqd2GVgNmv33aH"; protected-headers="v1" From: Henrik Levkowetz To: "David R. Oran" Cc: xml2rfc@ietf.org Message-ID: Subject: Re: [xml2rfc] Some problems with idnits checks on V3 document References: <0F30FE8F-15D8-410B-9615-0FE9615148FA@orandom.net> In-Reply-To: <0F30FE8F-15D8-410B-9615-0FE9615148FA@orandom.net> --sVIEONXDRqgsflUFIXliqd2GVgNmv33aH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dave, On 2020-04-02 15:59, David R. Oran wrote: > On 2 Apr 2020, at 9:53, Henrik Levkowetz wrote: >=20 >> Hi Dave, >> >> On 2020-03-31 15:58, David R. Oran wrote: >>> One of these seem to be xml2rfc rendering problem; others may be idni= t >>> glitches that only show up on V3 docs: >>> >>> - The too long line 1551 is in fact not too long - the length >>> computation seems to be screwed up by the non-ascii characters (proba= bly >>> idnit problem?) >> >> Yes, that's right. Will see what can be done. >> >>> - somehow xml2rfc elided part of an author name into the updates head= >>> field and author address into the Intended Status header field. This >>> only happens in the .txt output, not the HTML or PDF. xml2rfc bug? >> >> Will investigate, and if possible provide a fix in the next release, >> due tomorrow. >> > I looked more carefully and this is because the author address is so > long it looks like it=E2=80=99s only one character away from the status= , and > hence is parsed as part of that. Probably need to figure out how to > split long right-justified lines that over-run to the left. Ack on that. I've adjusted idnits; will do a new release shortly. >>> - idnits says this has a downref, but I believe that an I.D. marked >>> experimental saying it updates an experimental RFC isn=E2=80=99t a do= wnref, >>> right? >> >> Huh. I'll check the code. >> > On further investigation, I think this is a boggie due to the > intended status getting defaulted to Proposed Standard when > incorrectly parse above. Ah. Right. >>> I include the idnits output below and the xml file as an attachment >>> (note that this is still a bit private - we haven=E2=80=99t submitted= yes) >> >> Understood. >> >>> Let me know of any followup I should do - would like to get this >>> submitted in the next couple of days. >> >> Ack. Will follow up when I have more information. >> > Many thanks! > I decided to try to submit anyway and am now being done in by =E2=80=9C= Failed > decoding the uploaded file: "'ascii' codec can't decode byte 0xc3 in > position 69240: ordinal not in range(128)" >=20 > Time to go count characters in the .txt file. Sigh. Saw your other post on this, good that the workaround worked. Best, Henrik >=20 >=20 >> >> Best regards, >> >> Henrik >> >> >> >>> Thanks! DaveO. >>> >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>> >>> idnits 2.16.03 >>> >>> >>> tmp/draft-oran-icnrg-reflexive-forwarding.txt: >>> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1491): Found non-ascii >>> character (=EF=BF=BD) in position 18. >>> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1500): Found non-ascii >>> character (=EF=BF=BD) in position 16. >>> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1551): Line is too long= : >>> the offending characters are 'ch,' >>> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1551): Found non-ascii >>> character (=EF=BF=BD) in position 16. >>> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1597): Found non-ascii >>> character (=EF=BF=BD) in position 67. >>> >>> >>> Checking boilerplate required by RFC 5378 and the IETF Trust (see >>> https://trustee.ietf.org/license-info): >>> ------------------------------------------------------------------= ---------- >>> >>> No issues found here. >>> >>> Checking nits according to >>> https://www.ietf.org/id-info/1id-guidelines.txt: >>> ------------------------------------------------------------------= ---------- >>> >>> =3D=3D There are 4 instances of lines with non-ascii characters i= n the >>> document. >>> >>> >>> Checking nits according to https://www.ietf.org/id-info/checklist = : >>> ------------------------------------------------------------------= ---------- >>> >>> ** There is 1 instance of too long lines in the document, the long= est >>> one >>> being 3 characters in excess of 72. >>> >>> >>> Miscellaneous warnings: >>> ------------------------------------------------------------------= ---------- >>> >>> =3D=3D Unrecognized Status in 'Intended status: Experimental Univ= ersity >>> of >>> Applied Sciences Emden/Leer', assuming Proposed Standard >>> >>> (Expected one of 'Standards Track', 'Full Standard', 'Draft >>> Standard', >>> 'Proposed Standard', 'Best Current Practice', 'Informational', >>> 'Experimental', 'Informational', 'Historic'.) >>> >>> =3D=3D Couldn't figure out when the document was first submitted -= - there >>> may >>> comments or warnings related to the use of a disclaimer for >>> pre-RFC5378 >>> work that could not be issued because of this. Please check th= e >>> Legal >>> Provisions document at https://trustee.ietf.org/license-info to= >>> determine >>> if you need the pre-RFC5378 disclaimer. >>> >>> >>> Checking references for intended status: Proposed Standard >>> ------------------------------------------------------------------= ---------- >>> >>> (See RFCs 3967 and 4897 for information about using normative >>> references >>> to lower-maturity documents in RFCs) >>> >>> ** Downref: Normative reference to an Experimental RFC: RFC 8569 >>> >>> ** Downref: Normative reference to an Experimental RFC: RFC 8609 >>> >>> >>> Summary: 3 errors (**), 0 flaws (~~), 4 warnings (=3D=3D), 0 co= mments >>> (--). >>> >>> ---------------------------------------------------------------------= ----------- >>> >>> >>> 2 ICNRG D.= >>> Oran >>> 3 Internet-Draft Network Systems Research and >>> Design >>> 4 Updates: 8569, 8609 (if approved) D. >>> Kutscher >>> 5 Intended status: Experimental University of Applied Sciences >>> Emden/Leer >>> 6 Expires: 2 October 2020 31 March= >>> 2020 >>> >>> 8 Reflexive Forwarding for CCNx and NDN Protocols >>> 9 draft-oran-icnrg-reflexive-forwarding-00 >>> >>> 11 Abstract >>> >>> 13 Current Information-Centric Networking protocols such as CCNx a= nd >>> NDN >>> 14 have a wide range of useful applications in content retrieval a= nd >>> 15 other scenarios that depend only on a robust two-way exchange i= n >>> the >>> 16 form of a request and response (represented by an _Interest-Dat= a >>> 17 exchange_ in the case of the two protocols noted above). A num= ber >>> of >>> 18 important applications however, require placing large amounts o= f >>> data >>> 19 in the Interest message, and/or more than one two-way handshake= =2E >>> 20 While these can be accomplished using independent Interest-Data= >>> 21 exchanges by reversing the roles of consumer and producer, such= >>> 22 approaches can be both clumsy for applications and problematic >>> from a >>> 23 state management, congestion control, or security standpoint. >>> This >>> 24 specification proposes a _Reflexive Forwarding_ extension to th= e >>> CCNx >>> 25 and NDN protocol architectures that eliminates the problems >>> inherent >>> 26 in using independent Interest-Data exchanges for such >>> applications. >>> 27 It updates RFC8569 and RFC8609. >>> >>> 29 Status of This Memo >>> >>> 31 This Internet-Draft is submitted in full conformance with the >>> 32 provisions of BCP 78 and BCP 79. >>> >>> 34 Internet-Drafts are working documents of the Internet Engineeri= ng >>> 35 Task Force (IETF). Note that other groups may also distribute >>> 36 working documents as Internet-Drafts. The list of current >>> Internet- >>> 37 Drafts is at https://datatracker.ietf.org/drafts/current/. >>> >>> 39 Internet-Drafts are draft documents valid for a maximum of six >>> months >>> 40 and may be updated, replaced, or obsoleted by other documents a= t >>> any >>> 41 time. It is inappropriate to use Internet-Drafts as reference >>> 42 material or to cite them other than as "work in progress." >>> >>> 44 This Internet-Draft will expire on 2 October 2020. >>> >>> 46 Copyright Notice >>> >>> 48 Copyright (c) 2020 IETF Trust and the persons identified as the= >>> 49 document authors. All rights reserved. >>> >>> 51 This document is subject to BCP 78 and the IETF Trust's Legal >>> 52 Provisions Relating to IETF Documents (https://trustee.ietf.org= / >>> 53 license-info) in effect on the date of publication of this >>> document. >>> 54 Please review these documents carefully, as they describe your >>> rights >>> 55 and restrictions with respect to this document. >>> >>> 57 Table of Contents >>> >>> 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . .= . >>> 3 >>> 60 1.1. Problems with pushing data . . . . . . . . . . . . . .= . >>> 4 >>> 61 1.2. Problems with utilizing independent exchanges . . . . .= . >>> 5 >>> 62 2. Requirements Language . . . . . . . . . . . . . . . . . . .= . >>> 6 >>> 63 3. Overview of the Reflexive Forwarding design . . . . . . . .= . >>> 6 >>> 64 4. Naming of Reflexive Interests . . . . . . . . . . . . . . .= . >>> 10 >>> 65 5. Forwarder operation for Reflexive Interests . . . . . . . .= . >>> 11 >>> 66 6. State coupling between producer and consumer . . . . . . .= . >>> 12 >>> 67 7. Use cases for Reflexive Interests . . . . . . . . . . . . .= . >>> 12 >>> 68 7.1. Achieving Remote Method Invocation with Reflexive >>> 69 Interests . . . . . . . . . . . . . . . . . . . . . . .= . >>> 12 >>> 70 7.2. RESTful Web Interactions . . . . . . . . . . . . . . .= . >>> 15 >>> 71 7.3. Achieving simple data pull from consumers with reflexiv= e >>> 72 Interests . . . . . . . . . . . . . . . . . . . . . . .= . >>> 15 >>> 73 8. Implementation Considerations . . . . . . . . . . . . . . .= . >>> 19 >>> 74 8.1. Forwarder implementation considerations . . . . . . . .= . >>> 19 >>> 75 8.1.1. Forwarding Information Base (FIB) . . . . . . . . .= . >>> 19 >>> 76 8.1.2. Interactions with Interest Lifetime . . . . . . . .= . >>> 20 >>> 77 8.1.3. Interactions with Interest aggregation . . . . . .= . >>> 21 >>> 78 8.2. Consumer Implementation Considerations . . . . . . . .= . >>> 21 >>> 79 8.2.1. Data objects returned by the consumer to reflexive >>> name >>> 80 Interests arriving from a producer . . . . . . . .= . >>> 21 >>> 81 8.2.2. Terminating unwanted reflexive Interest exchanges .= . >>> 22 >>> 82 8.2.3. Interactions with caching . . . . . . . . . . . . .= . >>> 22 >>> 83 8.3. Producer Implementation Considerations . . . . . . . .= . >>> 22 >>> 84 9. Operational Considerations . . . . . . . . . . . . . . . .= . >>> 23 >>> 85 10. Mapping to CCNx and NDN packet encodings . . . . . . . . .= . >>> 24 >>> 86 10.1. Packet encoding for CCNx . . . . . . . . . . . . . . .= . >>> 24 >>> 87 10.2. Packet encoding for NDN . . . . . . . . . . . . . . .= . >>> 24 >>> 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . .= . >>> 24 >>> 89 12. Security Considerations . . . . . . . . . . . . . . . . . .= . >>> 25 >>> 90 12.1. Collisions of reflexive Interest names . . . . . . . .= . >>> 25 >>> 91 12.2. Additional resource pressure on PIT and FIB . . . . .= . >>> 26 >>> 92 12.3. Privacy Considerations . . . . . . . . . . . . . . . .= . >>> 26 >>> 93 13. Normative References . . . . . . . . . . . . . . . . . . .= . >>> 27 >>> 94 14. Informative References . . . . . . . . . . . . . . . . . .= . >>> 27 >>> 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .= . >>> 30 >>> >>> 97 1. Introduction >>> >>> 99 Current ICN protocols such as CCNx [RFC8569] and [NDN] have a w= ide >>> 100 range of useful applications in content retrieval and other >>> scenarios >>> 101 that depend only on a robust two-way exchange in the form of a= >>> 102 request and response. These ICN architectures use the terms >>> 103 "consumer" and "producer" for the respective roles of the >>> requester >>> 104 and the responder, and the protocols directly capture the >>> mechanics >>> 105 of the two-way exchange through the "Interest message" carryin= g >>> the >>> 106 request, and the "Data message" carrying the response. Throug= h >>> these >>> 107 constructs, the protocols are heavily biased toward a pure _pu= ll- >>> 108 based_ interaction model where requests are small (carrying >>> little or >>> 109 no user-supplied data other than the name of the requested dat= a >>> 110 object), and responses are relatively large - up to an >>> architecture- >>> 111 defined maximum transmission unit (MTU) on the order of kiloby= tes >>> or >>> 112 tens of kilobytes. >>> >>> 114 A number of important applications however require interaction= >>> models >>> 115 more complex than individual request/response interactions in = the >>> 116 same direction (i.e. between the same consumer and one or more= >>> 117 producers). Among these we identify three important classes >>> which >>> 118 are the target of the proposed enhancements defined in this >>> 119 specification. These are described in the following paragraph= s. >>> >>> 121 *Remote Method Invocation (RMI, aka RPC):* When invoking a >>> remote >>> 122 method, it is common for the method to require arguments >>> supplied >>> 123 by the caller. In conventional TCP/IP style protocols like= >>> CORBA >>> 124 or HTTP "Post", these are pushed to the server as part of t= he >>> 125 message or messages that comprise the request. In ICN-styl= e >>> 126 protocols there is an unattractive choice between inflating= >>> the >>> 127 request initiation with pushed arguments, or arranging to h= ave >>> one >>> 128 or more independent request/responses in the opposite >>> direction >>> 129 for the server to fetch the arguments. Both of these >>> approaches >>> 130 have substantial disadvantages. Recently, a viable >>> alternative >>> 131 emerged through the work on RICE [Krol2018] which pioneered= >>> the >>> 132 main design elements proposed in this specification. >>> >>> 134 *Phone-Home scenario:* Applications in sensing, >>> Internet-of-things >>> 135 (IoT) and other types where data is produced unpredictably = and >>> 136 needs to be _pushed_ somewhere create a conundrum for the p= ure >>> 137 pull-based architectures considered here. If instead one >>> eschews >>> 138 relaxing the size asymmetry between requests and responses,= >>> some >>> 139 additional protocol machinery is needed. Earlier efforts i= n >>> the >>> 140 ICN community have recognized this issue and designed metho= ds >>> to >>> 141 provoke a cooperating element to issue a request to return = the >>> 142 data the originator desires to push, essentially "phoning >>> home" to >>> 143 get the responder to fetch the data. One that has been >>> explored >>> 144 to some extent is the _Interest-Interest-Data_ exchange >>> 145 [Carzaniga2011], where an Interest is sent containing the >>> desired >>> 146 request as encapsulated data. CCNx-1.0 Bidirectional Strea= ms >>> 147 [Mosko2017] are also based on a scheme where an Interest is= >>> used >>> 148 to signal a name prefix that a consumer has registered for >>> 149 receiving Interests from a peer in a bidirectional streamin= g >>> 150 session. >>> >>> 152 *Peer state synchronization:* A large class of applications, >>> 153 typified by those built on top of on reliable order-preserv= ing >>> 154 transport protocols, require initial state synchronization >>> between >>> 155 the peers. This is accomplished with a three-way (or longe= r) >>> 156 handshake, since employing a two-way handshake as provided = in >>> the >>> 157 existing NDN and CCNx protocols exposes a number of well-kn= ow >>> 158 hazards, such as _half-open connections_. When attempted fo= r >>> 159 security-related operations such as key exchange, additiona= l >>> 160 hazards such as _man-in-the-middle_ attacks become trivial = to >>> 161 mount. Existing alternatives, similar to those used in the= >>> two >>> 162 examples above, instead utilize either overlapping >>> Interest-Data >>> 163 exchanges in opposite directions (resulting in a four-way >>> 164 handshake) or by adding initialization data to the initial >>> request >>> 165 and employing an Interest-Interest-Data protocol extension = as >>> 166 noted in the Phone-home scenarios above. >>> >>> 168 All of the above application interaction models present >>> interesting >>> 169 challenges, as neither relaxing the architecture to support >>> pushing >>> 170 large amounts of data, nor introducing substantial complexitie= s >>> 171 through multiple independent Interest-Data exchanges is an >>> attractive >>> 172 approach. The following subsections provide further backgroun= d >>> and >>> 173 justification for why push and/or independent exchanges are >>> 174 problematical. >>> >>> 176 1.1. Problems with pushing data >>> >>> 178 There are two substantial problems with the simple approach of= >>> just >>> 179 allowing arbitrary amounts of data to be included with request= s. >>> 180 These are: >>> >>> 182 1. In ICN protocols, Interest messages are intended to be sma= ll, >>> on >>> 183 the order the size of a TCP ACK, as opposed to the size of= a >>> TCP >>> 184 data segment. This is because the hop-by-hop congestion >>> control >>> 185 and forwarder state management requires Interest messages = to >>> be >>> 186 buffered in expectation of returning data, and possibly >>> 187 retransmitted hop-by-hop as opposed to end-to-end. In >>> addition, >>> 188 the need to create and manage state on a per-Interest basi= s >>> is >>> 189 substantially complicated if requests in Interest messages= >>> are >>> 190 larger than a Path MTU (PMTU) and need to be fragmented >>> hop-by- >>> 191 hop. >>> >>> 193 2. If the payload data of a request is used for invoking a >>> 194 computation (as in the RMI case described above) then >>> substantial >>> 195 bandwidth can be wasted if the computation is either refus= ed >>> or >>> 196 abandoned for any number of reasons, including the request= or >>> 197 failing an authorization check, or the responder not havin= g >>> 198 sufficient resources to execute the associated computation= =2E >>> >>> 200 These problems also exist in pure datagram transport protocols= >>> such >>> 201 as those used for legacy RMI applications like NFS [RFC7530]. >>> More >>> 202 usual are application protocols like HTTP(s) which rely on the= >>> TCP or >>> 203 QUIC 3-way handshake to establish a session and then have >>> congestion >>> 204 control and segmentation provided as part of the transport >>> protocol, >>> 205 further allowing sessions to be rejected before large amounts = of >>> data >>> 206 are transmitted or significant computational resources expende= d. >>> >>> 208 1.2. Problems with utilizing independent exchanges >>> >>> 210 In order to either complete a three-way handshake, or fetch da= ta >>> via >>> 211 a pull from the original requestor, the role of consumer and >>> producer >>> 212 need to be reversed and an Interest/Data exchange initiated in= >>> the >>> 213 direction opposite of the initiating exchange. When done with= an >>> 214 independent Interest/Data request and response, a number of >>> 215 complications ensue. Among them are: >>> >>> 217 1. The originating consumer needs to have a routable name pre= fix >>> 218 that can be used for the exchange. This means the consume= r >>> must >>> 219 arrange to have its name prefix propagated in the ICN rout= ing >>> 220 system with sufficient reach that the producer issuing the= >>> 221 interest can be assured it is routed appropriately. While= >>> some >>> 222 consumers are generally online and act as application >>> servers, >>> 223 justifying the maintenance of this routing information, ma= ny >>> do >>> 224 not. Further, in mobile environments, a pure consumer tha= t >>> does >>> 225 not need to have a routable name prefix can benefit from t= he >>> 226 inherent consumer mobility support in the CCNx and NDN >>> protocols. >>> 227 By requiring a routable name prefix, extra mobile routing >>> 228 machinery is needed, such as that proposed in KITE >>> [Zhang2018] or >>> 229 MAPME [Auge2018]. >>> >>> 231 2. The consumer name prefix in item (1) above must be >>> communicated >>> 232 to the producer as a payload, name suffix, or other field = of >>> the >>> 233 initiating Interest message. Since this name in its entir= ety >>> is >>> 234 chosen by the consumer, it is highly problematic from a >>> security >>> 235 standpoint, as it can recruit the producer to mount a >>> reflection >>> 236 attack against the consumer's chosen victim. >>> >>> 238 3. The correlation between the exchanges in opposite directio= ns >>> must >>> 239 be maintained by both the consumer and the producer as >>> 240 independent state, as opposed to being architecturally tie= d >>> 241 together as would be the case with a conventional 3-way >>> handshake >>> 242 finite state machine. While this can of course be >>> accomplished >>> 243 with care by both parties, experience has shown that it is= >>> error >>> 244 prone (for example see the checkered history of interactio= ns >>> 245 between the SIP [RFC3261] and SDP Offer-Answer [RFC6337]) >>> 246 protocols. When employed as the wrapper for a key managem= ent >>> 247 protocol such as with TLS [RFC8446] state management error= s >>> can >>> 248 be catastrophic for security. >>> >>> 250 2. Requirements Language >>> >>> 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >>> NOT", >>> 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY= ", >>> and >>> 254 "OPTIONAL" in this document are to be interpreted as described= in >>> 255 [RFC2119]. >>> >>> 257 3. Overview of the Reflexive Forwarding design >>> >>> 259 This specification defines a _Reflexive Forwarding_ extension = to >>> CCNx >>> 260 and NDN that avoids the problems enumerated in Sections 1.1 an= d >>> 1.2. >>> 261 It straightforwardly exploits the hop-by-hop state and symmetr= ic >>> 262 routing properties of the current protocols. >>> >>> 264 Figure 1 below illustrates a canonical NDN/CCNx forwarder with= >>> its >>> 265 conceptual data structures of the Content Store (CS), Pending >>> 266 Interest Table (PIT) and Forwarding Information Base (FIB). T= he >>> key >>> 267 observation involves the relation between the PIT and the FIB.= >>> Upon >>> 268 arrival of an Interest, a PIT entry is created which contains >>> state >>> 269 recording the incoming interface on which the Interest. If th= e >>> 270 Interest is not immediately satisfied by cached data in the CS= , >>> the >>> 271 forwarder looks up the name in the FIB to ascertain the >>> _next-hop_ to >>> 272 propagate the Interest onward upstream toward the named produc= er. >>> 273 Therefore, a chain of forwarding state is established during >>> Interest >>> 274 forwarding that couples the PIT entries of the chain of >>> forwarders >>> 275 together conceptually as _breadcrumbs_. These are used to forw= ard >>> the >>> 276 returning Data Message over the inverse path through the chain= of >>> 277 forwarders until the Data message arrives at the originating >>> 278 consumer. The state in the PITs is _unwound_ by destroying it= as >>> 279 each PIT entry is _satisfied_. This behavior is *critical* to = the >>> 280 feasibility of the reflexive forwarding design we propose. >>> >>> 282=09 >>> +-----------------------------------------------------------------+ >>> 283 | ICN No= de >>> | >>> 284 | Send data to all =3D=3D= =3D=3D=3D=3D=3D=3D >>> | >>> 285 | interfaces that >>> | >>> 286 | requested it >>> | >>> 287 | YES +------------------+ >>> | >>> 288 <------------------------| Pending Interest | >>> <--------------------- >>> 289 | | | Table (PIT) | Dat= a >>> | >>> 290 | | +------------------+ 1) Find >>> (Signed) | >>> 291 | | 2) Save | Name >>> | >>> 292 | V Data | NO in >>> | >>> 293 | +---------------+ | PIT? >>> | >>> 294 | | Content Store | | >>> | >>> 295 | | (CS) | | >>> | >>> 296 | +---------------+ | >>> | >>> 297 | | >>> | >>> 298 | V >>> | >>> 299 | Drop Data >>> | >>> 300 | >>> | >>> 301=09 >>> +-----------------------------------------------------------------+ >>> 302=09 >>> +-----------------------------------------------------------------+ >>> 303 | ICN No= de >>> | >>> 304 | =3D=3D= =3D=3D=3D=3D=3D=3D >>> | >>> 305 | >>> | >>> 306 | >>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+| >>> 307 | |Forwarding Strat= egy >>> || >>> 308 | >>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+| >>> 309 | >>> | >>> 310 | 1) Find name 2) Matching 3) Find matching= >>> | >>> 311 | in CS? name in PIT? entry in FIB?= >>> | >>> 312 | NO NO >>> YES| >>> 313 | +---------------+ +----------------+ >>> +-------------------+ | >>> 314 | | Content Store | | Pending | | Forwarding >>> | | >>> 315 --->| (CS) |-->| Interest |-->| Information Ba= se >>> |--> >>> 316 | | | | Table (PIT) | | ( FIB) >>> | | >>> 317 | +---------------+ +----------------+ >>> +-------------------+ | >>> 318 | Return | YES YES | NO NO | >>> | >>> 319 | Data | Add | Add | Drop >>> | >>> 320 | | Incoming | new | or >>> | >>> 321 | <------| Itf. | Interest | NACK >>> | >>> 322 | V V >>> | >>> 323 | >>> | >>> 324=09 >>> +-----------------------------------------------------------------+ >>> >>> 326 Figure 1: ICN forwarder structure >>> >>> 328 Given the above forwarding properties for Interests, it should= be >>> 329 clear that while an Interest is outstanding and ultimately >>> arrives at >>> 330 a producer who can respond to it, there is sufficient state in= >>> the >>> 331 chain of forwarders to route not just a returning Data message= , >>> but >>> 332 potentially another Interest directed through the inverse path= to >>> the >>> 333 unique consumer who issued the original Interest. (Section 8.= 1.3 >>> 334 describes how Interest aggregation interacts with this scheme.= ) >>> The >>> 335 key question therefore is how to access this state in a way th= at >>> it >>> 336 can be used to forward Interests. >>> >>> 338 In order to achieve this _Reflexive Interest_ forwarding on th= e >>> 339 inverse path recorded in the PIT of each forwarder, we need a = few >>> 340 critical design elements. These are as follows: >>> >>> 342 1. The Reflexive Interest needs to have a Name. This name is= >>> what >>> 343 the originating consumer will use to match against the Dat= a >>> 344 object (or objects - more on this later) it wishes the >>> producer >>> 345 to fetch by issuing the Reflexive Interest. This cannot b= e >>> just >>> 346 any name, but needs to essentially name the state already >>> 347 recorded in the PIT and not allow the consumer to manufact= ure >>> an >>> 348 arbitrary name and mount a reflection attack as pointed ou= t >>> in >>> 349 Section 1.2, Paragraph 2, Item 2. >>> >>> 351 2. There has to be a FIB entry at each forwarder for this nam= e >>> 352 prefix so that when the reflexive interest arrives, the >>> forwarder >>> 353 can forward it downstream toward the originating consumer.= >>> This >>> 354 FIB entry points directly to the incoming interface on whi= ch >>> the >>> 355 corresponding original Interest arrived. The FIB entry ne= eds >>> to >>> 356 be created as part of the forwarding of the original Inter= est >>> so >>> 357 that it is available in time to catch any reflexive Intere= st >>> 358 issued by the producer. It usually makes sense to destroy= >>> this >>> 359 FIB entry when the Data message satisfying the original >>> Interest >>> 360 arrives since this avoids any dangling stale state. Given= >>> the >>> 361 deign details documented later in this specification, stal= e >>> FIB >>> 362 state does not represent a correctness hazard and hence ca= n >>> be >>> 363 done lazily if desired in an implementation. See Section = 5 >>> for >>> 364 more details on FIB operation considerations. >>> >>> 366 3. There has to be coupling of the state between the originat= ing >>> 367 Interest-Data exchange and the enclosed Reflexive >>> Interest-Data >>> 368 exchange at both the consumer and the producer. In our >>> design, >>> 369 this accomplished by the way reflexive interest names are >>> chosen. >>> >>> 371 The following sections provide the normative details on each o= f >>> these >>> 372 design elements. The overall interaction flow for reflexive >>> 373 forwarding is illustrated below in Figure 2. >>> >>> 375 +-----------+ +-----------+ +-----------+ >>> 376 | Consumer | | Forwarder | | Producer | >>> 377 +-----------+ +-----------+ +-----------+ >>> 378 | | | >>> 379 | I1 | | >>> 380 |--------------->| | >>> 381 |--------------\ | | >>> 382 || Install RNP |-| | >>> 383 || in FIB | | | >>> 384 ||-------------| | | >>> 385 | | | >>> 386 | | I1 | >>> 387 | |----------------------------->| >>> 388 | | | >>> -----------\ >>> 389 | | |-| Crea= te >>> | >>> 390 | | | | RI >>> state | >>> 391 | | | >>> |----------| >>> 392 | | | >>> 393 | | RI | >>> 394 | |<-----------------------------| >>> 395 | | --------------------\ | >>> 396 | |-| lookup RNP in FIB | | >>> 397 | | |-------------------| | >>> 398 | | | >>> 399 | RI | | >>> 400 |<---------------| | >>> 401 | | | >>> 402 | D2 | | >>> 403 |--------------->| | >>> 404 | | | >>> 405 | | D2 | >>> 406 | |----------------------------->| >>> 407 | | | >>> ------------\ >>> 408 | | |-| answ= er >>> I1 | >>> 409 | | | >>> |-----------| >>> 410 | | | >>> 411 | | D1 | >>> 412 | |<-----------------------------| >>> 413 | | -----------------------\ | >>> 414 | |-| remove RNP FIB entry | | >>> 415 | | |----------------------| | >>> 416 | | | >>> 417 | D1 | | >>> 418 |<---------------| | >>> 419 | | | >>> >>> 421 Legend: >>> 422 I1: Interest #1 containing the Reflexive Name Prefix TLV >>> 423 RI: Reflexive Interest with Reflexive Name Prefix Componen= t >>> 424 RNP: Reflexive Name Prefix >>> 425 D1: Data message, answering initiating I1 Interest >>> 426 D2: Data message, answering RI >>> >>> 428 Figure 2: Message Flow Overview >>> >>> 430 4. Naming of Reflexive Interests >>> >>> 432 A consumer may have one or more objects for the producer to >>> fetch, >>> 433 and therefore needs to communicate enough information in their= >>> 434 initial Interest to allow the producer to construct properly >>> formed >>> 435 reflexive Interest names. For some applications the set of _f= ull >>> 436 names_ (see [I-D.irtf-icnrg-terminology]) is known a priori, f= or >>> 437 example through compile time bindings of arguments in interfac= e >>> 438 definitions or by the architectural definition of a simple sen= sor >>> 439 reading. In other cases the full names of the individual obje= cts >>> 440 must be communicated in the original Interest message. In all= >>> cases >>> 441 enough state must be provided by the consumer for the forwarde= rs >>> to >>> 442 construct a FIB entry (as noted in Section 3, Paragraph 6, Ite= m >>> 2). >>> 443 This is accomplished through the following naming construct. >>> >>> 445 We define a new typed name component, identified by a register= ed >>> name >>> 446 component type in the IANA registry for [RFC8569]. We call th= is >>> the >>> 447 _Reflexive Interest Name Component type_. It MUST be the first= >>> (i.e. >>> 448 high order) name component of any Reflexive Interest issued by= a >>> 449 producer. Its value is a random 64 bit number, assigned by th= e >>> 450 consumer, which provides the entropy required to uniquely >>> identify >>> 451 the issuing consumer for the duration of any outstanding >>> Interest- >>> 452 Data exchange. The consumer SHOULD choose a different random >>> value >>> 453 for each Interest message it constructs, for two reasons: >>> >>> 455 1. If stale FIB sate is present, the randomness prevents >>> potential >>> 456 mis-routing of reflexive interests (see Section 8.1.1 belo= w >>> for >>> 457 more details), and >>> >>> 459 2. Re-use of the same reflexive interest name over multiple >>> 460 interactions might reveal linkability information that cou= ld >>> be >>> 461 used by surveillance adversaries for tracking purposes. >>> >>> 463 This initial name component is either communicated by itself >>> through >>> 464 a _Reflexive Name Prefix TLV_ in the originating Interest, or >>> 465 prepended to any object names the consumer wishes the producer= to >>> 466 fetch explicitly where there is more than one object needed by= >>> the >>> 467 producer for the current Interest-Data interaction. There are= >>> four >>> 468 cases to consider: >>> >>> 470 1. The reflexive _fullname_ of a single object to fetch. >>> >>> 472 2. A single reflexive name prefix out of which the producer c= an >>> (by >>> 473 application-specific means) construct a number of _fullnam= es_ >>> of >>> 474 the objects it may want to fetch, >>> >>> 476 3. The reflexive _fullname_ of a FLIC Manifest >>> [I-D.irtf-icnrg-flic] >>> 477 enumerating the suffixes that may be used by the producer = to >>> 478 construct the necessary names, >>> >>> 480 4. Multiple reflexive name TLVs MAY be included in the Intere= st >>> 481 message if none of the above 3 options covers the desired = use >>> 482 case. >>> >>> 484 The last of the four options above, while not explicitly >>> outlawed, >>> 485 SHOULD NOT be used. This is because it results in a longer >>> Interest >>> 486 message and requires extra FIB resources. Hence, it is more >>> likely a >>> 487 forwarder will reject the Interest for lack of resources. A >>> 488 forwarder MAY optimize for the case of a single Reflexive Name= >>> TLV at >>> 489 the expense of those with more than one. >>> >>> 491 A producer, upon receiving an Interest with one or more Reflex= ive >>> 492 Name TLVs, may decide it needs the pull the associated data >>> 493 object(s). It therefore can issue one or more Reflexive >>> Interests by >>> 494 appending the necessary name components needed to form valid f= ull >>> 495 names of the associated objects present at the originating >>> consumer. >>> 496 These in fact comprise conventional Interest-Data exchanges, w= ith >>> no >>> 497 alteration of the usual semantics with regard to signatures, >>> caching, >>> 498 expiration, etc. When the producer has retrieved the required= >>> 499 objects to complete the original Interest-Data exchange, it ca= n >>> issue >>> 500 its Data response, which unwinds all the established state at = the >>> 501 producer, the consumer, and the intermediate forwarders. >>> >>> 503 5. Forwarder operation for Reflexive Interests >>> >>> 505 The forwarder operation for CCNx and/or NDN is changed in thre= e >>> 506 respects when supporting Reflexive Interests. >>> >>> 508 1. The forwarder MUST create short-lifetime FIB entries for a= ny >>> 509 Reflexive Interest Name prefixes communicated in an Intere= st >>> 510 message. If the forwarder does not have sufficient resour= ces >>> to >>> 511 do so, it MUST reject the Interest with the >>> T_RETURN_NO_RESOURCES >>> 512 error - the same error used if the forwarder were lacking >>> 513 sufficient PIT resources to process the Interest message. >>> >>> 515 2. Those FIB entries MUST be queried whenever an Interest >>> message >>> 516 arrives whose first name component is of the type _Reflexi= ve >>> 517 Interest Name Component_ >>> >>> 519 3. The FIB entry MUST be removed eventually, after the >>> corresponding >>> 520 Data message has been forwarded. One option would be to >>> remove >>> 521 the FIB directly after the Data message has been forwarded= =2E >>> 522 However, the forwarder MAY do lazy cleanup. >>> >>> 524 The PIT entry for the Reflexive Interest is consumed per regul= ar >>> 525 Interest/Data message forwarding requirements. The PIT entry = for >>> the >>> 526 originating Interest (that communicated the Reflexive Interest= >>> Name) >>> 527 is also consumed by a final Data message from the producer to = the >>> 528 original consumer. >>> >>> 530 6. State coupling between producer and consumer >>> >>> 532 A consumer that wishes to use this scheme MUST utilize one of = the >>> 533 reflexive naming options defined in Section 4 and include it i= n >>> the >>> 534 corresponding Interest message. The Reflexive Name TLV _and_ = the >>> 535 full name of the requested data object (that identifies the >>> producer) >>> 536 identify the common state shared by the consumer and the >>> producer. >>> 537 When the producer responds by sending Interests with the >>> Reflexive >>> 538 Name Prefix, the original consumer therefore has sufficient >>> 539 information to map these Interests to the ongoing Interest-Dat= a >>> 540 exchange. >>> >>> 542 The exchange is finished when the producer who received the >>> original >>> 543 Interest message responds with a Data message (or an Interest >>> Return >>> 544 message in the case of error) answering the original Interest.= >>> After >>> 545 sending this Data message, the producer SHOULD destroy the >>> 546 corresponding shared state. It MAY decide to use a timer that= >>> will >>> 547 trigger a later state destruction. After receiving this Data >>> 548 message, the originating consumer MUST destroy the correspondi= ng >>> 549 Interest-Data exchange state. >>> >>> 551 7. Use cases for Reflexive Interests >>> >>> 553 7.1. Achieving Remote Method Invocation with Reflexive Interests= >>> >>> 555 RICE (Remote Method Invocation in ICN) [Krol2018] uses the >>> Reflexive >>> 556 Interest Forwarding scheme that inspired the design specified = in >>> this >>> 557 document. >>> >>> 559 In RICE, the original Interest denotes the remote method (plus= >>> 560 potential parameters) to be invoked at a producer (server). >>> Before >>> 561 committing any computating resources, the server can then requ= est >>> 562 authentication credentials and (optional) parameters using >>> reflexive >>> 563 Interest-Data exchanges. >>> >>> 565 When the server has obtained the necessary credentials and inp= ut >>> 566 parameters, it can decide to commit computing resources, start= s >>> the >>> 567 compute process, and returns a handle ("Thunk") in the final D= ata >>> 568 message to the original consumer (client). >>> >>> 570 The client would later request the computation results using a= >>> 571 regular Interest-Data exchange (outside the Reflexive-Interest= >>> 572 transaction) -- using the Thunk as a name for the computation >>> result. >>> >>> 574 Figure 3 depicts an abstract message diagram for RICE. In >>> addition >>> 575 to the 4-way Reflexive Forwarding Handshake (see Figure 2 for = the >>> 576 details of the interaction), RICE adds another (standard) ICN >>> 577 Interest/Data exchange for transmitting the RMI result. The >>> Thunk >>> 578 name is provided to the consumer in the D1 DATA message >>> (answering >>> 579 the initial I1 Interest). >>> >>> 581 +-----------+ +-----------+ >>> 582 | Consumer | | Producer | >>> 583 +-----------+ +-----------+ >>> 584 | | >>> 585 | I1 | >>> 586 |------------------------->| >>> 587 | | ---------------------\ >>> 588 | |-| Requesting request | >>> 589 | | | parameters | >>> 590 | | | and credentials | >>> 591 | | |--------------------| >>> 592 | | >>> 593 | RI | >>> 594 |<-------------------------| >>> 595 | | >>> 596 | D2 | >>> 597 |------------------------->| >>> 598 | | --------------------\ >>> 599 | |-| Commit compute | >>> 600 | | | resources, | >>> 601 | | | return Thunk name | >>> 602 | | |-------------------| >>> 603 | | >>> 604 | D1 | >>> 605 |<-------------------------| >>> 606 | | ----------------\ >>> 607 | |-| Invoke Remote | >>> 608 | | | Method | >>> 609 | | |---------------| >>> 610 | -------------------\ | >>> 611 |-| After some time, | | >>> 612 | | request result | | >>> 613 | |------------------| | >>> 614 | | >>> 615 | I3 | >>> 616 |------------------------->| >>> 617 | | >>> 618 | D3 | >>> 619 |<-------------------------| >>> 620 | | >>> 621 Legend: >>> 622 I1: Interest #1 containing the Reflexive Name Prefix TLV >>> 623 D1: Data message, answering initiating I1 Interest, >>> 624 returning Thunk name >>> 625 D2: Data message, answering RI (parameters, credentials) >>> 626 I3: Regular Interest for Thunk (compute result) >>> 627 D3: Data message, answering I3 >>> 628 Figure 3: RICE Message Flow >>> >>> 630 7.2. RESTful Web Interactions >>> >>> 632 In todays HTTP-based web, RESTful (Representational State >>> Transfer) >>> 633 web interactions are realized by sending requests in a >>> client/server >>> 634 interaction, where the requests provides the application conte= xt >>> (or >>> 635 a reference to it). It has been noted in [Moiseenko2014] that= >>> 636 corresponding requests often exceed the response messages in >>> size, >>> 637 and that this raises the problems noted in Section 1.1 when >>> 638 attempting to map such exchanges directly to CCNx/NDN. >>> >>> 640 Another reason not to include all request parameters in a >>> (possibly >>> 641 encrypted) Interest message is the fact that a server (that is= >>> 642 serving thousands of clients) would be obliged to receive, >>> possibly >>> 643 decrypt and parse the complete requests before being able to >>> 644 determine whether the requestor is authorized, whether the >>> request >>> 645 can be served etc. Many non-trivial requests could thus lead = to >>> 646 computational overload attacks. >>> >>> 648 Using Reflexive Interest Forwarding for RESTful Web Interactio= ns >>> 649 would encode the REST request in the Original request, togethe= r >>> with >>> 650 a Reflexive Interest Prefix that the server could then use to = get >>> 651 back to the client for authentication credentials and request >>> 652 parameters, such as cookies. The request result (response >>> message) >>> 653 could either be transmitted in the Data message answering the >>> 654 original request, or -- in case of dynamic, longer-running >>> 655 computations -- in a seperate Interest/Data exchange, potentia= lly >>> 656 leveraging the Thunk scheme described in section Section 7.1. >>> >>> 658 Unlike approaches where clients have to signal a globally >>> routable >>> 659 prefix to the network, this approach would not require the cli= ent >>> 660 (original consumer) to expose its identity to the network (the= >>> 661 network only sees the temporary Reflexive Name Prefix), but it= >>> would >>> 662 still be possible to authenticate the client at the server. >>> >>> 664 7.3. Achieving simple data pull from consumers with reflexive >>> Interests >>> >>> 666 An oft-cited use case for ICN network architectures is _Intern= et >>> of >>> 667 Things_ (IoT), where the sources of data are limited-resource >>> sensor/ >>> 668 actuators. Many approaches have been tried (e.g. >>> [Baccelli2014], >>> 669 [Lindgren2016], [Gundogan2018]) with varying degrees of succes= s >>> in >>> 670 addressing the issues outlined in Section 1.1. The reflexive >>> 671 forwarding extension may substantially ameliorate the document= ed >>> 672 difficulties by allowing a different model for the basic >>> interaction >>> 673 of sensors with the ICN network. >>> >>> 675 Instead of acting as a producer (either directly to the Intern= et >>> or >>> 676 indirectly through the use of some form of application-layer >>> 677 gateway), the IoT device need only act as a consumer. When it= >>> has >>> 678 data to provide, it issues a "phone-home" Interest message to = a >>> pre- >>> 679 configured rendezvous name (e.g. an application-layer gateway = or >>> ICN >>> 680 Repo [Chen2015]) and provides a reflexive name prefix TLV for = the >>> 681 data it wishes to publish. The target producer may then issue= >>> the >>> 682 necessary reflexive Interest message(s) to fetch the data. On= ce >>> 683 fetched, validated, and stored, the producer then responds to = the >>> 684 original Interest message with a success indication, possibly >>> 685 containing a Data object if needed to allow the originating >>> device to >>> 686 modify its internal state. Alternatively, the producer might >>> choose >>> 687 to not respond and allow the original Interest to time out, >>> although >>> 688 this is NOT RECOMMENDED except in cases where the extra messag= e >>> 689 transmission bandwith is at a premium compared to the persiste= nce >>> of >>> 690 stale state in the forwarders. We note that this interaction >>> 691 approach mirrors the earlier efforts using Interest-Interest-D= ata >>> 692 designs. >>> >>> 694 Figure 4 depicts this interaction with the OPTIONAL D1 message= =2E >>> See >>> 695 Figure 2 for the details of the general Reflexive Forwarding >>> 696 interaction. >>> >>> 698 +-----------+ +-----------+ >>> 699 | Consumer | | Producer | >>> 700 +-----------+ +-----------+ >>> 701 ------------\ | | >>> 702 | new IoT |-| | >>> 703 | data item | | | >>> 704 | produced | | | >>> 705 |-----------| | | >>> 706 ---------------\ | | >>> 707 | "phone home" |-| | >>> 708 | by notifying | | | >>> 709 | producer | | | >>> 710 |--------------| | | >>> 711 | | >>> 712 | I1 | >>> 713 |------------>| >>> 714 | | --------------------\ >>> 715 | |-| generate Interest | >>> 716 | | | for IoT data | >>> 717 | | |-------------------| >>> 718 | | >>> 719 | RI | >>> 720 |<------------| >>> 721 -----------------\ | | >>> 722 | send requested |-| | >>> 723 | data object | | | >>> 724 |----------------| | | >>> 725 | | >>> 726 | D2 | >>> 727 |------------>| >>> 728 | | -----------------------\ >>> 729 | |-| finalize interaction | >>> 730 | | | with optional | >>> 731 | | | Data message | >>> 732 | | |----------------------| >>> 733 | | >>> 734 | D1 | >>> 735 |<------------| >>> 736 | | >>> 737 Legend: >>> 738 I1: Interest #1 containing the Reflexive Name Prefix TLV >>> 739 D1: Data message (OPTIONAL), finalizing interaction >>> 740 D1: Data message, answering RI, returning IoT data object >>> >>> 742 Figure 4: "Phone Home" Message Flow >>> >>> 744 There are two approaches that the IoT device can use for its >>> response >>> 745 to a reflexive Interest. It can simply construct a Data Messa= ge >>> 746 bound through the usual ICN hash name to the reflexive Interes= t >>> name. >>> 747 Since the scope of any data object bound in this way is only t= he >>> 748 duration of the enclosing Interest-Data exchange (see Section >>> 8.2) >>> 749 the producer would need to itself construct any persistent Dat= a >>> 750 object, name it, and sign it. This is sometimes the right >>> approach, >>> 751 as for some applications the identity of the originating IoT >>> device >>> 752 is not important from an operational or security point of view= ; >>> in >>> 753 contrast the identity of the gateway or Repo is what matters. >>> >>> 755 If alternatively, the persistent Data object should be bound f= rom >>> a >>> 756 naming and security point of view to the originating IoT devic= e, >>> this >>> 757 can be easily accomplished. Instead of directly placing the >>> content >>> 758 in a Data object responding to the reflexive Interest as above= , >>> the >>> 759 consumer encapsulates a complete CCNx/NDN Data message (which >>> 760 includes the desired name of the data) as in the response to t= he >>> 761 reflexive Interest message. >>> >>> 763 The interaction model described above brings a number potentia= l >>> 764 advantages, some obvious, some less so. We enumerate a few of= >>> them >>> 765 as follows: >>> >>> 767 * By not requiring the IoT device to be actively listening fo= r >>> 768 Interests, it can sleep and only wake up if it has somethin= g >>> to >>> 769 communicate. Conversely, parties interested in obtaining d= ata >>> 770 from the device do not need to be constantly polling in ord= er >>> to >>> 771 ascertain if there is new data available. >>> >>> 773 * No forwarder resources are tied up with state apart from th= e >>> 774 actual reflexive forwarding interactions. All that is need= ed >>> is >>> 775 enough routing state in the FIB to be able to forward the >>> "phone >>> 776 home" Interest to an appropriate target producer. While th= is >>> 777 model does not provide all the richness of a full Pub/Sub >>> system >>> 778 (like that described in [Gundogan2018]) we argue it is >>> adequate >>> 779 for a large subclass of such applications. >>> >>> 781 * The reflexive interest, through either a name suffix or >>> Interest >>> 782 payload, can give the IoT device useful context from which = to >>> 783 craft its Data object in response. One highly useful >>> parameter >>> 784 would be a robust clock value for the device to use as a >>> timestamp >>> 785 of the data, possibly as part of its name to correctly plac= e >>> it in >>> 786 a time seres of sensor readings. This substantially >>> alleviates >>> 787 the need for low-end devices to have a robust time base, as= >>> long >>> 788 as they trust the producer they contact to provide it. >>> >>> 790 8. Implementation Considerations >>> >>> 792 There are a number of important aspects to the reflexive >>> forwarding >>> 793 design which affect correctness and performance of existing >>> 794 forwarder, consumer, and producer implementations desiring to >>> support >>> 795 it. This section discusses the effect on each of these elemen= ts >>> of >>> 796 the CCNx/NDN protocol architecture. >>> >>> 798 8.1. Forwarder implementation considerations >>> >>> 800 8.1.1. Forwarding Information Base (FIB) >>> >>> 802 The FIB is a performance-critical data structure in any >>> forwarder, as >>> 803 it needs to support relatively expensive longest name prefix >>> match >>> 804 (LNPM) lookup algorithms. A number of well-known FIB data >>> structures >>> 805 are heavily optimized for read access, since for normal Intere= st >>> 806 message processing the FIB changes slowly - only after >>> topological >>> 807 changes or routing protocol updates. Support for reflexive na= mes >>> 808 changes this, as FIB entries are created and destroyed rapidly= as >>> 809 Interest messages containing reflexive name TLVs are processed= >>> and >>> 810 the corresponding Data messages come back. >>> >>> 812 While it may be feasible, especially in low-end forwarders >>> handling a >>> 813 low packet forwarding rate to ignore this problem, for high-sp= eed >>> 814 forwarders there are a number of hazards, including: >>> >>> 816 1. If the entire FIB needs to be locked in order to insert or= >>> remove >>> 817 entries, this could cause inflated forwarding delays or in= >>> 818 extreme cases, forwarding performance collapse. >>> >>> 820 2. A number of high-speed forwarder implementations employ a >>> sharded >>> 821 PIT scheme to better parallelize forwarding across process= ing >>> 822 cores. The FIB, however, is still a shared data structure= >>> which >>> 823 is either read without read locks across cores, or explici= tly >>> 824 copied such that there is a separate copy of the FIB for e= ach >>> PIT >>> 825 shard. Clearly, a high update rate without read locks and= /or >>> 826 updating many copies of the FIB are unattractive >>> implementation >>> 827 options. (Note: with this reflexive name scheme it is not= >>> 828 feasible to force reflexive interests to be hashed or be >>> 829 otherwise directed to the PIT shard holding the original >>> Interest >>> 830 state). >>> >>> 832 There are any number of alternative FIB implementations that c= an >>> work >>> 833 well however. The most straightforward is to simply implement= a >>> 834 "special" FIB for just reflexive name lookups. This is feasib= le >>> 835 because reflexive names deterministically contain the >>> distinguished >>> 836 high-order name component type of T_REFLEXIVE_NAME, whose cont= ent >>> is >>> 837 a 64-bit value that can be easily hashed to a FIB entry direct= ly, >>> 838 avoiding the more expensive LNPM lookup. Inserts and deletes >>> then >>> 839 devolve to the well-understood problem of hash table maintenan= ce. >>> >>> 841 8.1.2. Interactions with Interest Lifetime >>> >>> 843 If and when a producer decides to fetch data from the consumer= >>> using >>> 844 one or more reflexive Interest-Data exchanges, the total laten= cy >>> for >>> 845 the original Interest-Data exchange is inflated, potentially b= y >>> 846 multiple RTTs. It is difficult for a consumer to predict the >>> 847 inflation factor when issuing the original Interest, and hence= >>> there >>> 848 can be a substantial hazard of that Interest lifetime expiring= >>> before >>> 849 completion of the full multi-way exchange. This can result in= >>> 850 persistent failures, which is obviously highly undesirable. >>> >>> 852 There is a fairly straightforward technique that can be employ= ed >>> by >>> 853 forwarders to avoid these "false" Interest lifetime expiration= s. >>> In >>> 854 the absence of a superior alternative technique, it is >>> RECOMMENDED >>> 855 that all forwarders implement the following algorithm. >>> >>> 857 When processing an Interest containing the reflexive name TLV = and >>> 858 creating the necessary FIB entry (see Section 8.1.1 above), th= e >>> 859 forwarder also creates a _back pointer_ from that FIB entry to= >>> the >>> 860 PIT entry for the Interest message that created it. This PIT >>> entry >>> 861 contains the current value of the remaining Interest lifetime = or >>> 862 alternatively a value from which the remaining Interest lifeti= me >>> can >>> 863 be easily computed. Call this value _IL_(t)_. >>> >>> 865 If and when a reflexive Interest arrives from upstream matchin= g >>> the >>> 866 reflexive FIB entry, the forwarder examines the Interest lifet= ime >>> of >>> 867 the arriving reflexive Interest. Call this value _IL_(r)_. Th= e >>> 868 forwarder computes MAX(_IL_(t), (IL_(r) * 1.5)_), and replaces= >>> 869 _IL_(t)_ with this value. This in effect ensures that the >>> remaining >>> 870 Interest lifetime of the original Interest accounts for the >>> 871 additional 1.5 RTTs that may occur as a result of the reflexiv= e >>> 872 Interest-Data exchange. >>> >>> 874 If the above algorithm is implemented naively as described abo= ve, >>> it >>> 875 may run afoul of a sharded PIT forwarder implementation, since= >>> the >>> 876 PIT entry for the reflexive Interest and the PIT entry for the= >>> 877 original Interest may be in different shards. Therefore, if t= he >>> 878 update is done cross-shard on each reflexive Interest arrival,= >>> 879 performance may suffer, perhaps dramatically. Instead, the >>> following >>> 880 approach to updating the Interest lifetime after computing the= >>> new >>> 881 value is RECOMMMENDED for sharded-PIT forwarders. >>> >>> 883 When creating the reflexive FIB entry as above in Section 8.1.= 1, >>> copy >>> 884 the remaining Interest lifetime from the PIT entry. Do the PI= T >>> 885 update if and only if this value is about to expire, thus payi= ng >>> the >>> 886 cross-shard update cost only if the original Interest is about= to >>> 887 expire. A further optimization at the cost of modest extra >>> 888 complexity is to instead _queue_ the update to the core holdin= g >>> the >>> 889 shard of the original PIT entry rather than doing the update >>> 890 directly. If the PIT entry expires or is satisfied, instead o= f >>> 891 removing it the associated core checks the update queue and do= es >>> the >>> 892 necessary update. >>> >>> 894 While the above approach of inflating the interest lifetime of= >>> the >>> 895 original Interest to accommodate the additional RTTs of reflex= ive >>> 896 Interest-Data exchanges, this does introduce a new vulnerabili= ty >>> that >>> 897 must be dealt with. A Producer, either through a bug or >>> malicious >>> 898 intent, could keep an originating Interest-Data exchange alive= by >>> 899 continuing to send reflexive Interests back to the consumer, >>> while >>> 900 the consumer had no way to terminate the enclosing interaction= >>> (there >>> 901 is no "cancel Interest" function in either NDN nor CCNx). To >>> 902 eliminate this hazard, if the consumer rejects a reflexive >>> interest >>> 903 with a T_RETURN_PROHIBITED error, the forwarder(s), in additio= n >>> to >>> 904 satisfying the coresponding PIT entry, MUST also delete the >>> 905 associated reflexive FIB entry, thereby preventing any further= >>> 906 reflexive Interests from reaching the consumer. This allows t= he >>> 907 enclosing Interest-Datsa exchange to either time out or be >>> correctly >>> 908 ended with a Data message or Interest Return from the Producer= =2E >>> >>> 910 8.1.3. Interactions with Interest aggregation >>> >>> 912 As with numerous other situations where multiple Interests for= >>> the >>> 913 same named object arrive containing different parameters (e.g.= >>> 914 Interest Lifetime, QoS, payload hash) the same phenomenon occu= rs >>> for >>> 915 the reflexive Name TLV. If such Interests collide, the forwar= der >>> 916 MUST NOT aggregate these Interest messages and instead MUST >>> create a >>> 917 separate PIT entry for each. >>> >>> 919 8.2. Consumer Implementation Considerations >>> >>> 921 8.2.1. Data objects returned by the consumer to reflexive name >>> 922 Interests arriving from a producer >>> >>> 924 The Data objects returned to the producer in response to a >>> reflexive >>> 925 Interest are normal CCNx/NDN data objects. It is therefore wo= rth >>> 926 noting that the object is bound to the reflexive Interest full= >>> name >>> 927 via the hash and hence the scope of the object is under most >>> 928 circumstances meaningful only for the duration of the enclosin= g >>> 929 Interest-Data interaction. This property is ideal for naming = and >>> 930 securing data that is "part of" the enclosing interaction - >>> things >>> 931 like method arguments, authenticators, and key exchange >>> parameters, >>> 932 but not for the creation and naming of objects intended to >>> survive >>> 933 outside the current interaction's scope (c.f. Section 7.3, wh= ich >>> 934 describes how to provide globally-named objects using >>> encapsulation). >>> 935 In general, the consumer should use the following guidelines i= n >>> 936 creating Data messages in response to reflexive Interest messa= ges >>> 937 from the producer. >>> >>> 939 (a) Set the recommended cache time (T_CACHETIME) either to ze= ro, >>> or >>> 940 a value no greater than the Interest lifetime (T_INTLIFE)= of >>> the >>> 941 original Interest messsage. >>> >>> 943 (b) Set the payload type (T_PAYLDTYPE) according to the type = of >>> 944 object being returned (e.g. object, link, manifest) >>> >>> 946 (c) Set the expiry time (T_EXPIRY) to a value greater than >>> _now_, >>> 947 and less than or equal to the _now_ + Interest lifetime >>> 948 (T_INTLIFE) of the original Interest messsage. >>> >>> 950 8.2.2. Terminating unwanted reflexive Interest exchanges >>> >>> 952 A consumer may wish to stop receiving reflxive Interests due t= o >>> 953 possible erors or malicious behavior on the part of the produc= er. >>> 954 Therefore, if the consumer receives an unwanted reflexive >>> Interest, >>> 955 it SHOULD reject that interest with a T_RETURN_PROHIBITED erro= r. >>> 956 This will provoke the forwarders to prevent further reflexive >>> 957 Interests from reaching the consumer, as described above in >>> 958 Section 8.1.2, Paragraph 7. >>> >>> 960 8.2.3. Interactions with caching >>> >>> 962 The reflexive named objects provide "local", temporary names t= hat >>> are >>> 963 only defined for one specific interaction between a consumer a= nd >>> a >>> 964 producer. Corresponding Data objects MUST NOT be shared betwe= en >>> 965 multiple consumers (violating this would require specail >>> gyrations by >>> 966 the producer since the reflexive Name utilizes per-consumer/pe= r- >>> 967 interaction random values). A producer MUST NOT issue an >>> Interest >>> 968 message for any reflexive name after it has sent the final Dat= a >>> 969 message answering the original Interest. >>> >>> 971 Forwarders SHOULD still cache reflexive Data objects for >>> 972 retransmissions within a transactions, but they MUST remove th= em >>> from >>> 973 the content store when they forward the final Data message >>> answering >>> 974 the original Interest. >>> >>> 976 8.3. Producer Implementation Considerations >>> >>> 978 Producers receiving an Interest with a Reflexive Name Componen= t, >>> MAY >>> 979 decide to issue Interests for the corresponding Data objects. >>> All >>> 980 Reflexive Interest message that a producer sends MUST be sent >>> over >>> 981 the face that the original Interest was received on. >>> >>> 983 9. Operational Considerations >>> >>> 985 This extension represents a substantial enhancement to the >>> CCNx/NDN >>> 986 protocol architecture and hence has important forward and >>> backward >>> 987 compatibility effects. The most important of these is that >>> correct >>> 988 operation of the scheme requires an unbroken chain of forwarde= rs >>> 989 between the consumer and the desired producer that support the= >>> 990 Reflexive Name TLV and the corresponding forwarder capabilitie= s >>> 991 specified in Section 5. When this invariant is not satisfied,= >>> some >>> 992 means is necessary to detect and hopefully recover from the >>> error. >>> 993 We have identified three possible approaches to handling the l= ack >>> of >>> 994 universal deployment of forwarders supporting the reflexive >>> 995 forwarding scheme. >>> >>> 997 The first approach simply lets the producer detect the error b= y >>> 998 getting a "no route to destination" error when trying to send = an >>> 999 Interest to a reflexive name. This will catch the error, but >>> only >>> 1000 after forwarding resources are tied up and the producer has d= one >>> some >>> 1001 work on the original Interest message. Further, the producer= >>> would >>> 1002 need a bit of smarts to determine that this is a permanent er= ror >>> and >>> 1003 not a transient to be retried. In order for the consumer to >>> attempt >>> 1004 recovery, there might be a need for some explicit error retur= ned >>> for >>> 1005 the original interest to tell the consumer what the likely >>> problem >>> 1006 is. This approach does not enable an obvious recovery path f= or >>> the >>> 1007 consumer either, since while we might envision a way to steer= a >>> 1008 subsequent Interest onto a working path as proposed in >>> 1009 [I-D.oran-icnrg-pathsteering], there is no capability to forc= e >>> 1010 Interest routing away from an otherwise working path not >>> supporting >>> 1011 the reflexive name TLV. >>> >>> 1013 A second approach is to bump the CCNx/NDN protocol version to= >>> 1014 explicitly indicate the lack of comparability. Such Interest= s >>> would >>> 1015 be rejected by forwarders not supporting this protocol >>> extension. A >>> 1016 consumer wishing to use the reflexive name TLV would use the >>> higher >>> 1017 protocol version on those Interest messages (but could of cou= rse >>> 1018 continue to use the current version number on other Interest >>> 1019 messages). This is a big hammer, but may be called for in th= is >>> 1020 situation because: >>> >>> 1022 (a) it detects the problem immediately and deterministically= , >>> and >>> >>> 1024 (b) one could assume an ICN routing protocol that would only= >>> forward >>> 1025 to a next hop that supports the updated protocol version= >>> number. >>> 1026 The supported forwarder protocol versions would have bee= n >>> 1027 communicated in the routing protocol ahead of time. >>> >>> 1029 A third option is to, as a precondition utilizing the protoco= l >>> in a >>> 1030 deployment, create and deploy a neighbor capability exchange >>> protocol >>> 1031 which will tell a downstream forwarder if the upstream can >>> handle the >>> 1032 new TLV. This might avoid the large hammer of updating the >>> protocol >>> 1033 version, but of course this puts a pretty strong dependency o= n >>> 1034 somebody actually designing and publishing such a protocol! = On >>> the >>> 1035 other hand, a neighbor capability exchange protocol for CCNx/= NDN >>> 1036 would have a number of other substantial benefits, which make= s >>> it >>> 1037 worth seriously considering anyway. >>> >>> 1039 10. Mapping to CCNx and NDN packet encodings >>> >>> 1041 10.1. Packet encoding for CCNx >>> >>> 1043 For CCNx[RFC8569] there is one new Name Component TLV type >>> defined in >>> 1044 this specification. >>> >>> 1046=09 >>> +------------------+----------------+--------------------------+ >>> 1047 | Abbrev | Name | Description >>> | >>> 1048=09 >>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>> 1049 | T_REFLEXIVE_NAME | Reflexive Name | Name component to use= as >>> | >>> 1050 | | Component | name prefix in Reflex= ive >>> | >>> 1051 | | | Interest Message >>> | >>> 1052=09 >>> +------------------+----------------+--------------------------+ >>> >>> 1054 Table 1: Reflexive Name TLV >>> >>> 1056 10.2. Packet encoding for NDN >>> >>> 1058 TBD based on [NDNTLV]. Suggestions from the NDN team greatly= >>> 1059 appreciated. >>> >>> 1061 11. IANA Considerations >>> >>> 1063 Please add the T_REFLEXIVE_NAME component TLV to the CCNx Nam= e >>> types >>> 1064 TLV types registry of [RFC8609], with Length 9 bytes and type= of >>> 64 >>> 1065 bit random integer. >>> >>> 1067 1 2 = 3 >>> 1068 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 = 0 1 >>> 1069=09 >>> +---------------+---------------+---------------+---------------+ >>> 1070 | T_REFLEXIVE_NAME | 8 >>> | >>> 1071=09 >>> +---------------+---------------+---------------+---------------+ >>> 1072 | >>> | >>> 1073 | 64bit Integer randomly assigned by consumer >>> | >>> 1074=09 >>> +-------------------------------+-------------------------------+ >>> >>> 1076 Figure 5: Reflexive Name component type >>> >>> 1078 12. Security Considerations >>> >>> 1080 One of the major motivations for the reflexive forwarding >>> extension >>> 1081 specified in this document is in fact to enable better securi= ty >>> and >>> 1082 privacy characteristics for ICN networks. The main >>> considerations >>> 1083 are presented in Section 1, but we briefly recapitulate them >>> here: >>> >>> 1085 * Current approaches to authentication and data transfer oft= en >>> use >>> 1086 payloads in Interest messages, which are clumsy to secure >>> 1087 (Interest messages must be signed) and as a consequence ma= ke >>> it >>> 1088 very difficult to ensure consumer privacy. Reflexive >>> forwarding >>> 1089 moves all sensitive data to the Data messages sent in >>> response to >>> 1090 reflexive Interests, which are secured in the same manner = as >>> all >>> 1091 other Data messages in the CCNx and NDN protocol designs. >>> >>> 1093 * In many scenarios, consumers are forced to also act as >>> producers >>> 1094 so that data may be fetched by either a particular, or >>> arbitrary >>> 1095 other party. The means the consumer must arrange to have = a >>> 1096 routable name prefix and that prefix be disseminated by th= e >>> 1097 routing protocol or other means. This represents both a >>> privacy >>> 1098 hazard (by revealing possible important information about = the >>> 1099 consumer) and a security concern as it opens up the consum= er >>> to >>> 1100 the full panoply of flooding and crafted Interest denial o= f >>> 1101 service attacks. >>> >>> 1103 * In order to achieve multi-way handshakes, in current desig= ns >>> a >>> 1104 consumer wishing a producer to communicate back must infor= m >>> the >>> 1105 producer of what (globally routable) name to use. This gi= ves >>> the >>> 1106 consumer a convenient means to mount a variety of reflecti= on >>> 1107 attacks by enlisting the producer to send Interests to >>> desired >>> 1108 victims. >>> >>> 1110 As a major protocol extension however, this design brings its= >>> own >>> 1111 potential security issues, which are discussed in the followi= ng >>> 1112 subsections. >>> >>> 1114 12.1. Collisions of reflexive Interest names >>> >>> 1116 Reflexive Interest names are constructed using 64-bit random >>> numbers. >>> 1117 This is intended to ensure an off-path attacker cannot easily= >>> 1118 manufacture a matching reflexive Interest and either masquera= de >>> as >>> 1119 the producer, or mount a denial of service attack on the >>> consumer. >>> 1120 It also limits tracking through the linkability of Interests >>> 1121 containing a re-used random value. >>> >>> 1123 Therefore consumers MUST utilize a robust means of generating= >>> these >>> 1124 random values, and it is RECOMMENDED that a pseudo-random num= ber >>> 1125 generator (PRNG) approved for use with cryptographic protocol= s >>> be >>> 1126 employed. >>> >>> 1128 12.2. Additional resource pressure on PIT and FIB >>> >>> 1130 Normal Interest message processing in CCNx and NDN needs to >>> consider >>> 1131 effect of various resource depletion attacks on the PIT, >>> particularly >>> 1132 in the form of Interest flooding attacks (see [Gasti2012] for= a >>> good >>> 1133 overview of DoS and DDoS mitigation on ICN networks). Intere= st >>> 1134 messages utilizing this reflexive forwarding extension can pl= ace >>> 1135 additional resource pressure on the PIT, and additionally cau= se >>> 1136 otherwise stable FIB resources to be subject to highly dynami= c >>> usage. >>> >>> 1138 While this does not represent a new DoS/DDoS attack vector, t= he >>> 1139 ability of a malicious consumer to utilize this extension in = an >>> 1140 attack does represent an increased risk of resource depletion= , >>> 1141 especially if such Interests are given unfair access to PIT a= nd >>> FIB >>> 1142 resources. Implementers SHOULD therefore protect PIT and FIB= >>> 1143 resources by weighing requests for reflexive forwarding >>> resources >>> 1144 appropriately relative to other Interests. >>> >>> 1146 12.3. Privacy Considerations >>> >>> 1148 ICN architectures like CCNx and NDN provide a rich tapestry o= f >>> 1149 interesting privacy issues, which have been extensively explo= red >>> in >>> 1150 the research literature. The fundamental tradeoffs for priva= cy >>> 1151 concern the risk of exposing the names of information objects= to >>> the >>> 1152 forwarding elements of the network, which is a necessary >>> property of >>> 1153 any name-based routing and forwarding design. Numerous >>> approaches >>> 1154 have been explored with varying degrees of success, such as >>> onion >>> 1155 routing ([DiBenedettoGTU12]), name encryption ([Ghali2017]), = and >>> name >>> 1156 obfuscation ([Arianfar2011]) among others. >>> >>> 1158 Reflexive forwarding does not change the overall landscape of= >>> privacy >>> 1159 tradeoffs, nor seem to introduce additional hazards. In fact= , >>> the >>> 1160 privacy exposures are confined to the inverse path of forward= ers >>> from >>> 1161 the producer to the consumer, through which the original >>> Interest >>> 1162 forwarding may have already exposed names on path. Similar n= ame >>> 1163 privacy techniques to those cited above may be equally applie= d >>> to the >>> 1164 names in reflexive Interests. >>> >>> 1166 While the individual reflexive Interest-Data exchanges have >>> similar >>> 1167 properties to those in any NDN or CCNx exchange, the target >>> usages by >>> 1168 applications may have interaction patterns that are subject t= o >>> 1169 relatively straightforward fingerprinting by adversaries. Fo= r >>> 1170 example, a particular RMI invocation may fingerprint simply >>> through >>> 1171 the count of arguments fetched by the producer and their size= s. >>> The >>> 1172 attacker must however be on path, which somewhat ameliorates = the >>> 1173 exposure hazards. >>> >>> 1175 13. Normative References >>> >>> 1177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicat= e >>> 1178 Requirement Levels", BCP 14, RFC 2119, >>> 1179 DOI 10.17487/RFC2119, March 1997, >>> 1180 . >>> >>> 1182 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centri= c >>> 1183 Networking (CCNx) Semantics", RFC 8569, >>> 1184 DOI 10.17487/RFC8569, July 2019, >>> 1185 . >>> >>> 1187 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centri= c >>> 1188 Networking (CCNx) Messages in TLV Format", RFC 860= 9, >>> 1189 DOI 10.17487/RFC8609, July 2019, >>> 1190 . >>> >>> 1192 14. Informative References >>> >>> 1194 [Arianfar2011] >>> 1195 Arianfar, S., Koponen, T., Raghavan, B., and S. >>> Shenker, >>> 1196 "On preserving privacy in content-oriented network= s, >>> in >>> 1197 ICN '11: Proceedings of the ACM SIGCOMM workshop o= n >>> 1198 Information-centric networking", >>> 1199 DOI https://doi.org/10.1145/2018584.2018589, Augus= t >>> 2011, >>> 1200 . >>> >>> 1202 [Auge2018] Aug=C3=A9, J., Carofiglio, G., Grassi, G., Muscari= ello, >>> L., >>> 1203 Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Les= s >>> 1204 Producer Mobility in Content-Centric Networks, in >>> IEEE >>> 1205 Transactions on Network, Volume 15, Issue 2", >>> 1206 DOI 10.1109/TNSM.2018.2796720, June 2018, >>> 1207 . >>> >>> 1209 [Baccelli2014] >>> 1210 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., a= nd >>> M. >>> 1211 W=C3=A4hlisch, "Information centric networking in = the >>> IoT: >>> 1212 experiments with NDN in the wild, in ACM-ICN '14: >>> 1213 Proceedings of the 1st ACM Conference on Informati= on- >>> 1214 Centric Networking", DOI 10.1145/2660129.2660144, >>> 1215 September 2014, >>> 1216 . >>> >>> 1218 [Carzaniga2011] >>> 1219 Carzaniga, A., Papalini, M., and A.L. Wolf, >>> "Content-Based >>> 1220 Publish/Subscribe Networking and Information-Centr= ic >>> 1221 Networking", DOI 10.1145/2018584.2018599, Septembe= r >>> 2011, >>> 1222=09 >>> >> 1223 p56.pdf>. >>> >>> 1225 [Chen2015] Chen, S., Cao, J., and L. Zhu, "NDSS: A Named Data= >>> Storage >>> 1226 System, in International Conference on Cloud and >>> Autonomic >>> 1227 Computing", DOI 10.1109/ICCAC.2015.12, September >>> 2014, >>> 1228 . >>> >>> 1230 [DiBenedettoGTU12] >>> 1231 DiBenedetto, S., Gasti, P., Tsudik, G., and E. Uzu= n, >>> 1232 "ANDaNA: Anonymous Named Data Networking Applicati= on, >>> in >>> 1233 NDSS 2012", DOI https://arxiv.org/abs/1112.2205v2,= >>> 2102, >>> 1234=09 >>> >> 1235 named-data-networking-application>. >>> >>> 1237 [Gasti2012] >>> 1238 Gasti, P., Tsudik, G., Uzun, Ersin., and L. Zhang,= >>> "DoS >>> 1239 and DDoS in Named Data Networking, in 22nd >>> International >>> 1240 Conference on Computer Communication and Networks >>> 1241 (ICCCN)", DOI 10.1109/ICCCN.2013.6614127, August >>> 2013, >>> 1242 . >>> >>> 1244 [Ghali2017] >>> 1245 Tsudik, G., Ghali, C., and C. Wood, "When encrypti= on >>> is >>> 1246 not enough: privacy attacks in content-centric >>> networking, >>> 1247 in ICN '17: Proceedings of the 4th ACM Conference = on >>> 1248 Information-Centric Networking", >>> 1249 DOI https://doi.org/10.1145/3125719.3125723, >>> September >>> 1250 2017, >>> 1251 . >>> >>> 1253 [Gundogan2018] >>> 1254 G=C3=BCndo=C4=9Fan, C., Kietzmann, P., Schmidt, T.= , and M. >>> W=C3=A4hlisch, >>> 1255 "HoPP: publish-subscribe for the constrained IoT, = in >>> ICN >>> 1256 '18: Proceedings of the 5th ACM Conference on >>> Information- >>> 1257 Centric Networking", DOI 10.1145/3267955.3269020, >>> 1258 September 2018, >>> 1259 . >>> >>> 1261 [I-D.irtf-icnrg-flic] >>> 1262 Tschudin, C., Wood, C., Mosko, M., and D. Oran, >>> "File-Like >>> 1263 ICN Collections (FLIC)", Work in Progress, >>> Internet-Draft, >>> 1264 draft-irtf-icnrg-flic-02, 4 November 2019, >>> 1265=09 >>> . >>> >>> 1267 [I-D.irtf-icnrg-terminology] >>> 1268 Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., >>> Oran, >>> 1269 D., and C. Tschudin, "Information-Centric Networki= ng >>> 1270 (ICN): CCNx and NDN Terminology", Work in Progress= , >>> 1271 Internet-Draft, draft-irtf-icnrg-terminology-08, 1= 7 >>> 1272 January 2020, >>> >> 1273 icnrg-terminology-08>. >>> >>> 1275 [I-D.oran-icnrg-pathsteering] >>> 1276 Moiseenko, I. and D. Oran, "Path Steering in CCNx = and >>> 1277 NDN", Work in Progress, Internet-Draft, >>> draft-oran-icnrg- >>> 1278 pathsteering-00, 21 October 2019, >>> 1279 >> 1280 pathsteering-00>. >>> >>> 1282 [Krol2018] Krol, M., Habak, K., Oran, D., Kutscher, D., and I= =2E >>> 1283 Psaras, "RICE: Remote Method Invocation in ICN, in= >>> 1284 Proceedings of the 5th ACM Conference on Informati= on- >>> 1285 Centric Networking - ICN '18", >>> 1286 DOI 10.1145/3267955.3267956, September 2018, >>> 1287=09 >>> >> 1288 icn18-final9.pdf>. >>> >>> 1290 [Lindgren2016] >>> 1291 Lindgren, A., Ben Abdessiem, F., Ahlgren, B., >>> Schlel=C3=A9n, >>> 1292 O., and A.M. Malik, "Design choices for the IoT in= >>> 1293 Information-Centric Networks, in 13th IEEE Annual >>> Consumer >>> 1294 Communications and Networking Conference (CCNC)", >>> 1295 DOI 10.1109/CCNC.2016.7444905, January 2016, >>> 1296=09 >>> . >>> >>> 1298 [Moiseenko2014] >>> 1299 Moiseenko, I., Stapp, M., and D. Oran, "Communicat= ion >>> 1300 patterns for web interaction in named data >>> networking", >>> 1301 DOI 10.1145/2660129.2660152, September 2014, >>> 1302 . >>> >>> 1304 [Mosko2017] >>> 1305 Mosko, M., "CCNx 1.0 Bidirectional Streams", >>> 1306 arXiv 1707.04738, July 2017, >>> 1307 . >>> >>> 1309 [NDN] "Named Data Networking", 2020, >>> 1310 . >>> >>> 1312 [NDNTLV] "NDN Packet Format Specification", 2016, >>> 1313 . >>> >>> 1315 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., >>> Johnston, >>> 1316 A., Peterson, J., Sparks, R., Handley, M., and E. >>> 1317 Schooler, "SIP: Session Initiation Protocol", RFC >>> 3261, >>> 1318 DOI 10.17487/RFC3261, June 2002, >>> 1319 . >>> >>> 1321 [RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session >>> 1322 Initiation Protocol (SIP) Usage of the Offer/Answe= r >>> 1323 Model", RFC 6337, DOI 10.17487/RFC6337, August 201= 1, >>> 1324 . >>> >>> 1326 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File >>> System >>> 1327 (NFS) Version 4 Protocol", RFC 7530, DOI >>> 10.17487/RFC7530, >>> 1328 March 2015, >>> . >>> >>> 1330 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) >>> Protocol >>> 1331 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, Augu= st >>> 2018, >>> 1332 . >>> >>> 1334 [Zhang2018] >>> 1335 Zhang, Y., Xia, Z., Mastorakis, S., and L. Zhang, >>> "KITE: >>> 1336 Producer Mobility Support in Named Data Networking= , >>> in >>> 1337 Proceedings of the 5th ACM Conference on Informati= on- >>> 1338 Centric Networking - ICN '18", >>> 1339 DOI 10.1145/3267955.3267959, September 2018, >>> 1340=09 >>> >> 1341 icn18-final23.pdf>. >>> >>> 1343 Authors' Addresses >>> >>> 1345 Dave Oran >>> 1346 Network Systems Research and Design >>> 1347 4 Shady Hill Square >>> 1348 Cambridge, MA 02138 >>> 1349 United States of America >>> >>> 1351 Email: daveoran@orandom.net >>> >>> 1353 Dirk Kutscher >>> 1354 University of Applied Sciences Emden/Leer >>> 1355 Constantiapl. 4 >>> 1356 26723 Emden >>> 1357 Germany >>> >>> 1359 Email: ietf@dkutscher.net >>> 1360 URI: https://dirk-kutscher.info >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> DaveO >>> >>> >>> >>> _______________________________________________ >>> xml2rfc mailing list >>> xml2rfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/xml2rfc >>> >=20 > DaveO >=20 --sVIEONXDRqgsflUFIXliqd2GVgNmv33aH-- --KjDVPXut9bS243k9aQUXJ2kAAWMH9vk7i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl6F+WAACgkQTptXS4+7 FxoTxRAAmhY41xvuDSP0gdqae0lzXh7+405IzzJHpnz8dClGsaghAGKsklgcQFK7 jwKqQ29HeqxoIjDjKvQCRXP7SczlVEu1taYx8gUcsGUijDw6qnxr4uYfkQq6yQNL kvi/J/IABzRNkhXOSfGqZPFjv29XnAziqJBIyopTzVXaAtg+TGkOxCP6RxF9zkec L018jaP1/9Jo1rUxUrPSehpMWCVpg0cdXvtX1Av39BqvbcL2kJoHt+IdwlIZx26D 6ZkXfB5o056NgLWrZUzw2cmEF6Ihv1AmltGkslDgdP77WoI5uAVuHCqv1+FdPb6u f5qMQD2xCGnQRDyLwf6asx1+8NNwD00eiE3T8HNt+rbETDyncgenmEzJ4jV8qhfm U+XO5S0jrroomDtbPbFlUD4dsjWKFWJj+pBYuvGppMNb/8gzRiB1qyDQl+2RWfIl YWaodkddR9nn5/GsXV23KNDAcuyE4EpZc/bNNtvHEaGZB+kOS/kAp0leNt4lsbv7 q2I4f7Dg4CCpLDV/8oK1vkFCYpIMckAJDsRJtKif881yHn+ofVJiSNvbA77RhtV6 n0dT/aTqsWCceHZ9vOimFalQY45+Gd85uCDz4A+vLgXnqZOCDMjjpbvyl1nMCMwU wzqjlti4xrSyI1LFwK73fTcSqVtYHaQEmM3a7357GJT9XMZhHAI= =gz21 -----END PGP SIGNATURE----- --KjDVPXut9bS243k9aQUXJ2kAAWMH9vk7i-- From nobody Thu Apr 2 07:58:09 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FE23A1426 for ; Thu, 2 Apr 2020 07:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDwLl1McCbOI for ; Thu, 2 Apr 2020 07:58:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D38E3A1409 for ; Thu, 2 Apr 2020 07:58:05 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:56929 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jK1Hq-000503-I2; Thu, 02 Apr 2020 07:58:04 -0700 To: "David R. Oran" References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> Cc: xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <9c42feff-2519-111b-1913-22699a4c9587@levkowetz.com> Date: Thu, 2 Apr 2020 16:57:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ShD6SdsbICbLIJvRSde6PrgPBrL0I6PnR" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, daveoran@orandom.net X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 14:58:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ShD6SdsbICbLIJvRSde6PrgPBrL0I6PnR Content-Type: multipart/mixed; boundary="960N4vBmdMEK5fQTuFbOGjmTbKXVBmCF2"; protected-headers="v1" From: Henrik Levkowetz To: "David R. Oran" Cc: xml2rfc@ietf.org Message-ID: <9c42feff-2519-111b-1913-22699a4c9587@levkowetz.com> Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> In-Reply-To: <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> --960N4vBmdMEK5fQTuFbOGjmTbKXVBmCF2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2020-04-02 16:35, David R. Oran wrote: > On 2 Apr 2020, at 10:20, Henrik Levkowetz wrote: >=20 >> Hi David, >> >> On 2020-04-02 16:10, David R. Oran wrote: >>> I tried to submit a V3 draft today by uploading the .txt, and got: >>> >>> Failed decoding the uploaded file: "'ascii' codec can't decode byte 0= xc3 >>> in position 69240: ordinal not in range(128)" >>> >>> this is in an element which in my .xml file is: >>> >>> >> asciiSurname=3D"Auge" asciiFullname=3D"Jordan Auge"/> >>> >>> But the .txt output of xml2rfc generates: >>> >>> [Auge2018] Aug=C3=A9, J., Carofiglio, G., Grassi, G., Muscariello= , L., >>> Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less >>> Producer Mobility in Content-Centric Networks, in IEEE= >>> Transactions on Network, Volume 15, Issue 2", >>> DOI 10.1109/TNSM.2018.2796720, June 2018, >>> . >>> >>> >>> Am I missing something obvious or is this a bug? >> >> This is probably caused by the file being identified as having ascii >> encoding by the uploading browser. There are currently two workaround= s: >> Upload the XML and let the submission tool do the conversion, > I can=E2=80=99t - it has included files and there seems to be no way to= > upload dependencies. Or am I missing something? The intention is that you should be able to generate an uploadable file by using the --expand switch; but while that processes XIncludes, it does not pull in external artwork at the moment, and it should. You can create an uploadable file using --prep, but that will also do a lot of other things, and result in a file which is not suited for later editing, due to the added verbiage. >> or use the >> --bom switch to generate an initial BOM in the file, which will let th= e >> browser identify the file as UTF-8, which should result in the right >> handling in the submission tool. >> > Ah, that worked. Didn=E2=80=99t know about that option. Good to know fo= r > future reference. GOod :-) Best regards, Henrik --960N4vBmdMEK5fQTuFbOGjmTbKXVBmCF2-- --ShD6SdsbICbLIJvRSde6PrgPBrL0I6PnR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl6F/V8ACgkQTptXS4+7 Fxrs3xAA1iKRF4cj0MoRkgy2Gpbj3Q5onS7BdDonRRT4j3jS9TNWPhiWkNjlkkxa zaLkIkx9uoo895Gh4Tg9BQWLiC1nfxh0B+QSMYDA9TWwX31nJbQGBDCVkEYngI7f bRsBbuLYLxMvDyJI3JmmDH3WVOjLK8WfK7U7LzPaw+wBf6lhG0SifW/i+jLK5lUT baFkNnctIBEURRylqV5h/4j3LviCKEA59trNgXTYuT0EbaRiq8He7LWODNid5zkS q6qZbUGuYM3hrPAYegjytBHsfm3rrftO5dvY7G9ZOUE+oeZDcnOgtE+U+eC1dJ5B aUMVqtE0WmNKPmdNeISFuNmYoZCihPZJwBLKqRkNDM7Vb2L/e+NwcOprqfx9Yv+2 rZHbkTvUNc34yGW689jhzFhuTGqidBVttD+oiJyMvBiPs+T4ioWKKov7ZvTfFCfQ 2f+rSRAD306d6Gh9pKIxnIAL+NBzjvaVUKC2FVzckFCUgLQazfSG5lod4C4RG7WZ fzDlPEyxdSLMI2nSqLw7BvGRHMCViEdHTDZP47P8oV2QhnLQ8Tb2BeVyDX5Fuzse 6sUaAnbXmF6BCGz+zE7x36/n8gtYVFDRyhHHnODCX0eZ4dFNrSF8SQOlOhChwfpz 76QHWZHi5Xb6RvULrfsQ2k+6KPnaGfoy3DgPaWpPjQaby3cybEM= =Ts+i -----END PGP SIGNATURE----- --ShD6SdsbICbLIJvRSde6PrgPBrL0I6PnR-- From nobody Thu Apr 2 08:03:12 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6043A13ED for ; Thu, 2 Apr 2020 08:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRDlSDziPJ1q for ; Thu, 2 Apr 2020 08:03:08 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093663A13B7 for ; Thu, 2 Apr 2020 08:03:07 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48tRBy1Ng4zyr5; Thu, 2 Apr 2020 17:03:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> Date: Thu, 2 Apr 2020 17:03:05 +0200 Cc: Henrik Levkowetz , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 607532585.627561-0452fc26055898e7bc4dcdc60247cb8c Content-Transfer-Encoding: quoted-printable Message-Id: <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> To: "David R. Oran" X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 15:03:11 -0000 On 2020-04-02, at 16:35, David R. Oran wrote: >=20 >> or use the >> --bom switch to generate an initial BOM in the file, which will let = the >> browser identify the file as UTF-8, which should result in the right >> handling in the submission tool. >>=20 > Ah, that worked. Didn=E2=80=99t know about that option. Good to know = for future reference. FYI: BOMs in UTF-8 are seriously deprecated. We are actively trying to get rid of BOM infections, and I=E2=80=99d = rather not see this being used as a workaround for anything. In particular not in the IETF. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 2 08:05:47 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E174A3A141D for ; Thu, 2 Apr 2020 08:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NXtLNgH95m7 for ; Thu, 2 Apr 2020 08:05:43 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CB33A142C for ; Thu, 2 Apr 2020 08:05:42 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48tRFw6mGbzysS; Thu, 2 Apr 2020 17:05:40 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <9c42feff-2519-111b-1913-22699a4c9587@levkowetz.com> Date: Thu, 2 Apr 2020 17:05:40 +0200 Cc: "David R. Oran" , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 607532740.000434-90333b2cd148d89a8aa4d0b2c4fdf18f Content-Transfer-Encoding: quoted-printable Message-Id: References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <9c42feff-2519-111b-1913-22699a4c9587@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 15:05:46 -0000 On 2020-04-02, at 16:57, Henrik Levkowetz wrote: >=20 > You can create an uploadable file using --prep, but that will also do > a lot of other things, and result in a file which is not suited for > later editing, due to the added verbiage. This works well, and is in active use (kdrfc -p, in kramdown-rfc). (There is no point in editing uploaded XML for I-Ds, unless we are = talking about final versions going to the RFC editor, where special = arrangements can easily be made.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 2 11:27:39 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327E03A0E52; Thu, 2 Apr 2020 11:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQTPitVZ-zq7; Thu, 2 Apr 2020 11:27:10 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986843A0E4F; Thu, 2 Apr 2020 11:27:10 -0700 (PDT) Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from ) id 1jK4YY-0006Ak-Am; Thu, 02 Apr 2020 11:27:10 -0700 To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org Cc: rfc-markdown@ietf.org Message-Id: From: Henrik Levkowetz Date: Thu, 02 Apr 2020 11:27:10 -0700 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc] New xml2rfc release: v2.42.0 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 18:27:15 -0000 Hi, This is an automatic notification about a new xml2rfc release, v2.42.0, generated when running the mkrelease script. Release notes: xml2rfc (2.42.0) ietf; urgency=medium * Changed the minimum whitespace distance between Updates/Obsoletes/etc. and Author/Organization in the document header in text rendering back to the value used in the v2 renderer (4 spaces) instead of the value used recently (3 spaces). * Added a guard against trying to normalize whitespace text that is None. * Added a guard against trying to create entries for reference content, avoiding a later exception. Fixes issue #501. * Changed the approach to avoiding page breaks inside artwork etc., and added styling to prevent page breaks between
and
in a
. Fixes issues #461, #463, and #491 * Did a variable name change and removed a 'del', to deal with a pyflakes issue under 2.7. Fixes issue #504. * Added missing keepWithNext support for PDF output. * Added a --v2 switch with the same meaning as --legacy. -- Henrik Levkowetz 02 Apr 2020 17:32:04 +0000 The preferred way to install xml2rfc is by doing 'pip install xml2rfc', and 'pip install --upgrade xml2rfc' to upgrade. If there are system- installed python modules which pip will not upgrade, you may have to use 'pip install --upgrade --no-deps xml2rfc' and install dependencies manually. The new version is also available through SVN checkout, with 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.42.0' Regards, Henrik (via the mkrelease script) From nobody Thu Apr 2 12:09:36 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A2C3A0C8E for ; Thu, 2 Apr 2020 12:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEA8TmNVV4bq for ; Thu, 2 Apr 2020 12:09:30 -0700 (PDT) Received: from blue.elm.relay.mailchannels.net (blue.elm.relay.mailchannels.net [23.83.212.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DD23A0C8F for ; Thu, 2 Apr 2020 12:09:29 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2C485180E1B; Thu, 2 Apr 2020 19:09:28 +0000 (UTC) Received: from pdx1-sub0-mail-a10.g.dreamhost.com (100-96-6-10.trex.outbound.svc.cluster.local [100.96.6.10]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6B1AC180D37; Thu, 2 Apr 2020 19:09:27 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a10.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Thu, 02 Apr 2020 19:09:28 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Left-Thread: 0a709f026eb0ca34_1585854567874_1454634273 X-MC-Loop-Signature: 1585854567874:1112430339 X-MC-Ingress-Time: 1585854567873 Received: from pdx1-sub0-mail-a10.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a10.g.dreamhost.com (Postfix) with ESMTP id 112EBB1B89; Thu, 2 Apr 2020 12:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=s4PrNkSJ8p/6laxyz26g6EMBKr0=; b=jZOzTn9x47j dI50nU8QySHlKMX2D/k1RI3xVCBzUlSz4jTQVuEK7gq6IR957kYNBLUJmNszcAxN fFEzKifoCuGRrHsIcISOFOyVAolKUNARSxOIzvHzxfKtHONjc39FNjqIQAgOZxbr c0X71DRafmPGdYtP0UjWjbrD6PH5gEec= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a10.g.dreamhost.com (Postfix) with ESMTPSA id 08CB1B1B88; Thu, 2 Apr 2020 12:09:23 -0700 (PDT) Date: Thu, 2 Apr 2020 14:09:21 -0500 X-DH-BACKEND: pdx1-sub0-mail-a10 From: Nico Williams To: Carsten Bormann Cc: "David R. Oran" , xml2rfc@ietf.org Message-ID: <20200402190920.GY18021@localhost> References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrtdeggdduvdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtugfgjggfsehtkeertddtreejnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 19:09:31 -0000 On Thu, Apr 02, 2020 at 05:03:05PM +0200, Carsten Bormann wrote: > On 2020-04-02, at 16:35, David R. Oran wrote: > >> or use the > >> --bom switch to generate an initial BOM in the file, which will let = the > >> browser identify the file as UTF-8, which should result in the right > >> handling in the submission tool. >=20 > FYI: BOMs in UTF-8 are seriously deprecated. > We are actively trying to get rid of BOM infections, and I=E2=80=99d ra= ther > not see this being used as a workaround for anything. In particular > not in the IETF. +1. The submission tool should require and assume UTF-8, or at most have a checkbox for ASCII vs UTF-8. In any case, there should be no codeset detection in the submission tool. Nico --=20 From nobody Thu Apr 2 12:14:29 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD863A0CB2 for ; Thu, 2 Apr 2020 12:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCVbSIYXAx1D for ; Thu, 2 Apr 2020 12:14:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABCE63A0CB1 for ; Thu, 2 Apr 2020 12:14:26 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:58227 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jK5Hx-0004ct-TA; Thu, 02 Apr 2020 12:14:26 -0700 To: Nico Williams , Carsten Bormann References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> Cc: xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: Date: Thu, 2 Apr 2020 21:13:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20200402190920.GY18021@localhost> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eLOTeDt8bLpUGdd4buCibajQr7b7qAJfH" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, cabo@tzi.org, nico@cryptonector.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 19:14:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eLOTeDt8bLpUGdd4buCibajQr7b7qAJfH Content-Type: multipart/mixed; boundary="LbKIDw8PNcM5WelhmQdnIUHfDIDUmhpGa"; protected-headers="v1" From: Henrik Levkowetz To: Nico Williams , Carsten Bormann Cc: xml2rfc@ietf.org Message-ID: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> In-Reply-To: <20200402190920.GY18021@localhost> --LbKIDw8PNcM5WelhmQdnIUHfDIDUmhpGa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2020-04-02 21:09, Nico Williams wrote: > On Thu, Apr 02, 2020 at 05:03:05PM +0200, Carsten Bormann wrote: >> On 2020-04-02, at 16:35, David R. Oran wrote: >> >> or use the >> >> --bom switch to generate an initial BOM in the file, which will let= the >> >> browser identify the file as UTF-8, which should result in the righ= t >> >> handling in the submission tool. >>=20 >> FYI: BOMs in UTF-8 are seriously deprecated. >> We are actively trying to get rid of BOM infections, and I=E2=80=99d r= ather >> not see this being used as a workaround for anything. In particular >> not in the IETF. >=20 > +1. >=20 > The submission tool should require and assume UTF-8, or at most have a > checkbox for ASCII vs UTF-8. In any case, there should be no codeset > detection in the submission tool. There isn't. The submission tool uses the charset provided by the browse= r at upload time. This fails if the browser says that an UTF-8 file is ASCII, which was the= case here. Henrik --LbKIDw8PNcM5WelhmQdnIUHfDIDUmhpGa-- --eLOTeDt8bLpUGdd4buCibajQr7b7qAJfH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl6GOXUACgkQTptXS4+7 FxoS4A/8Ch2cy8oxhKfjIrEm3h7lHi5d2cqsk31Mm1ewJ71eqsEOlTJhttltE8lG fW5SGafFSCqIYXfZawPphi8ySsuPPks5Qm9jKyGdOWZyJ0DEMzxvhNQuFMLjiz06 9NgBb2v+KC/JdnTQYGS9XWlavnXBN9YLes7oba4yftVfR9ovjBN66RwP1/PeQuOC iz07wAvniM0a6fZfGzfb0UVdBvIX0afiEVw4kR0HSsaqWOFLLEBWusne+kA9dT5T k4NlXxcAHy3owlZy6vukASoJ9L1+889TTu/guAX9FtwljOqqSrtybkRKftYq2Pw+ KWNrSrcIM15zG3yBEdaIATNMgNkuPhtbXimxucBkitUS311mfu9vvgAOl6KbYGI/ Uruqd6BcYbG/tJAcH5jA1gbhTTGaL+DC8Hx2uFC1yARJoojoOvP3HR7kmys3zm6B vtg3Til3YTFkw6nJXkccWRFo7hBd6Eium2+3RxRFQTCwH7v3fHWtgkuyDt5y/r4n 8bZyRtpdQmEekc98maeGiM+mlyV8xFdFPxSR68VFrbAv+GxPAoHRbWHoHrVnf1Ku 7xGEK8jMwr9ZI4Mtze4ncZWPtv5JykBY0mkpZpUan6+SRFqkhz6OGb9r0PNkyyX3 51MA6fxMAGvxscC5v+Tkf1kwosk9Lq4Wq2ijvA+X9P5DOnUOgvI= =55gq -----END PGP SIGNATURE----- --eLOTeDt8bLpUGdd4buCibajQr7b7qAJfH-- From nobody Thu Apr 2 12:20:07 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26943A0FC6 for ; Thu, 2 Apr 2020 12:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiQYC_MR6vpE for ; Thu, 2 Apr 2020 12:20:01 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4E73A0FCE for ; Thu, 2 Apr 2020 12:20:01 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48tXvM2rtvzyWg; Thu, 2 Apr 2020 21:19:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: Date: Thu, 2 Apr 2020 21:19:58 +0200 Cc: Nico Williams , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 607547998.914948-482e2aebdf300f5a627deab8bc738139 Content-Transfer-Encoding: quoted-printable Message-Id: References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 19:20:05 -0000 > On 2020-04-02, at 21:13, Henrik Levkowetz = wrote: >=20 >=20 >=20 > On 2020-04-02 21:09, Nico Williams wrote: >> On Thu, Apr 02, 2020 at 05:03:05PM +0200, Carsten Bormann wrote: >>> On 2020-04-02, at 16:35, David R. Oran wrote: >>>>> or use the >>>>> --bom switch to generate an initial BOM in the file, which will = let the >>>>> browser identify the file as UTF-8, which should result in the = right >>>>> handling in the submission tool. >>>=20 >>> FYI: BOMs in UTF-8 are seriously deprecated. >>> We are actively trying to get rid of BOM infections, and I=E2=80=99d = rather >>> not see this being used as a workaround for anything. In particular >>> not in the IETF. >>=20 >> +1. >>=20 >> The submission tool should require and assume UTF-8, or at most have = a >> checkbox for ASCII vs UTF-8. In any case, there should be no codeset >> detection in the submission tool. >=20 > There isn't. The submission tool uses the charset provided by the = browser > at upload time. Why? Browsers do get these things wrong =E2=80=94 how would they even know? =20= > This fails if the browser says that an UTF-8 file is ASCII, which was = the > case here. Why? It is extremely easy to sniff whether a file is UTF-8 or not, and rather = more reliable than what browsers say. Now if it is not, the submission = tool might want to translate koi-8r into UTF-8 if the browser says that = is the encoding, but that sounds marginal already. ASCII is irrelevant. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 2 12:31:49 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377E33A101C for ; Thu, 2 Apr 2020 12:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVEF70JQQc-7 for ; Thu, 2 Apr 2020 12:31:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679893A1014 for ; Thu, 2 Apr 2020 12:31:42 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:58348 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jK5Yf-0004QU-6D; Thu, 02 Apr 2020 12:31:41 -0700 To: Carsten Bormann References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> Cc: Nico Williams , xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> Date: Thu, 2 Apr 2020 21:31:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I2uVfwG0TJ19TjssV3vgnIPoirOJkrXOc" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, nico@cryptonector.com, cabo@tzi.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 19:31:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --I2uVfwG0TJ19TjssV3vgnIPoirOJkrXOc Content-Type: multipart/mixed; boundary="esOq5CRMp7nGpA2c7TnrMphFxnNqaAaMc"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann Cc: Nico Williams , xml2rfc@ietf.org Message-ID: <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> In-Reply-To: --esOq5CRMp7nGpA2c7TnrMphFxnNqaAaMc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2020-04-02 21:19, Carsten Bormann wrote: >=20 >=20 >> On 2020-04-02, at 21:13, Henrik Levkowetz wrote= : >>=20 >>=20 >>=20 >> On 2020-04-02 21:09, Nico Williams wrote: >>> On Thu, Apr 02, 2020 at 05:03:05PM +0200, Carsten Bormann wrote: >>>> On 2020-04-02, at 16:35, David R. Oran wrote:= >>>>>> or use the >>>>>> --bom switch to generate an initial BOM in the file, which will le= t the >>>>>> browser identify the file as UTF-8, which should result in the rig= ht >>>>>> handling in the submission tool. >>>>=20 >>>> FYI: BOMs in UTF-8 are seriously deprecated. >>>> We are actively trying to get rid of BOM infections, and I=E2=80=99d= rather >>>> not see this being used as a workaround for anything. In particular= >>>> not in the IETF. >>>=20 >>> +1. >>>=20 >>> The submission tool should require and assume UTF-8, or at most have = a >>> checkbox for ASCII vs UTF-8. In any case, there should be no codeset= >>> detection in the submission tool. >>=20 >> There isn't. The submission tool uses the charset provided by the bro= wser >> at upload time. >=20 > Why? > Browsers do get these things wrong =E2=80=94 how would they even know? Below you say that it's extremely easy to sniff whether a file is UTF-8 o= r not, and here you ask how would the browser even know. I see a contradic= tion. The upload comes with a mime type and charset -- why should the submissio= n tool _not_ use those? >> This fails if the browser says that an UTF-8 file is ASCII, which was = the >> case here. >=20 > Why? > It is extremely easy to sniff whether a file is UTF-8 or not, and > rather more reliable than what browsers say. Why? With browsers having a userbase of hundreds of millions, why should= we assume that our custom code will do better? Henrik > Now if it is not, the > submission tool might want to translate koi-8r into UTF-8 if the > browser says that is the encoding, but that sounds marginal already. > ASCII is irrelevant. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 --esOq5CRMp7nGpA2c7TnrMphFxnNqaAaMc-- --I2uVfwG0TJ19TjssV3vgnIPoirOJkrXOc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl6GPYEACgkQTptXS4+7 FxqnSxAAh6eTu1VkBOfPVV8U5tm0cKagWviedvhmqI7BIe32yC32t1L+JtBbPxmC UQONR6Hif8aH5sBPsYK9an4PYEEegJT789GDY/VPe8t5v9Fh7bIW6nxpogr04CYS lYqlg6mUK1veDOZ0OTVtPGxhH3p9rjZR0eX45v9R+Z9jKQTDP8Z9i0FADiQXX+vV 6dGukdakddh/rAUd9U3IFHfLftM/TzizoTBndywiy1iaHKHe9VLptOQPT9TcbUGC lyf0ELb+u/SEHufYrpFhEpcCZ4hzOWTnrEj/W8xeuSPLTKyHEVHjWtQnbC8lYdGi WieyW5twGU8WNWIoPnxcqi+l2e+XpDfj+/hFi6vWagEd2LAbmdVX4V3kw3kQQRHe xP180WyVVamiYSF5YAmfYl184bWXWHLN9UJLwolb7reHEfiNV/pjm1BkEUWt5lRB BxzFyLbK+UqJjU+s23JiLwbeZUv6Mi8GxK+loOkMlkkOW2Ems/ay6evRiJA7f2Ha kr7m4M8LH0uYyQjN031Fifaq/pyazuexPOPQOADpbyaC6+XW7DN/syJyLWnkLRFV z9nJaO1Xv5qsDpGTDaiUePNXaH/CgndwvmpMHqQ2Y4/tkenwN3R9R4EIrfz1WkRF 0+FdTK20SNm/ocebV/Cz02F0Olw2OBnEzILyngYdZv7xI4674jU= =dvni -----END PGP SIGNATURE----- --I2uVfwG0TJ19TjssV3vgnIPoirOJkrXOc-- From nobody Thu Apr 2 22:06:30 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEA43A0F39 for ; Thu, 2 Apr 2020 22:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_Hsl6KlKjKU for ; Thu, 2 Apr 2020 22:06:24 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711E83A0F35 for ; Thu, 2 Apr 2020 22:06:24 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48tnvy3WHvzyvK; Fri, 3 Apr 2020 07:06:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> Date: Fri, 3 Apr 2020 07:06:21 +0200 Cc: Nico Williams , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 607583181.625809-b60b001e844ca549522d19c15fa9cedf Content-Transfer-Encoding: quoted-printable Message-Id: <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 05:06:28 -0000 >>>>=20 >>>> +1. >>>>=20 >>>> The submission tool should require and assume UTF-8, or at most = have a >>>> checkbox for ASCII vs UTF-8. In any case, there should be no = codeset >>>> detection in the submission tool. >>>=20 >>> There isn't. The submission tool uses the charset provided by the = browser >>> at upload time. >>=20 >> Why? >> Browsers do get these things wrong =E2=80=94 how would they even = know? >=20 > Below you say that it's extremely easy to sniff whether a file is = UTF-8 or > not, and here you ask how would the browser even know. I see a = contradiction. >=20 > The upload comes with a mime type and charset -- why should the = submission > tool _not_ use those? Because they are mostly wrong. This thread started with an observation that the charset provided by the = browser was wrong. Previously, we have had discussions about markdown files being submitted = as application/octet-stream. The way browsers are set up, they are trying to use OS hints for = assigning a media type and, possibly, a charset. However, these OS = hints are not designed in a way that they can be relied upon. So in legacy environments with multiple charsets, server-side libraries = such as Microsoft's MLang are being used to sniff the uploads for their = charset. I=E2=80=99m not sure we are in such an environment any more in = 2020, but it is still easy to check for UTF-8-ness and fall back to a = supplied charset if that is not the case. It is never productive to believe a browser=E2=80=99s supplied media = type that an uploaded file is ASCII and then fail if it isn=E2=80=99t. (XML files, of course, carry their charset in them, so no guessing is = required, just checking.) >=20 >>> This fails if the browser says that an UTF-8 file is ASCII, which = was the >>> case here. >>=20 >> Why? >> It is extremely easy to sniff whether a file is UTF-8 or not, and >> rather more reliable than what browsers say. >=20 > Why? With browsers having a userbase of hundreds of millions, why = should > we assume that our custom code will do better? Because the browsers don=E2=80=99t try, and we could. I apologize that my Python-fu is not very strong, but the code looks = like these two lines (plus test harness): #!/usr/bin/env ruby data =3D ARGF.binmode.read text =3D data.force_encoding(Encoding::UTF_8) # Assume UTF-8 if text.valid_encoding? # and check warn "Valid UTF-8" else # ... guess charset from uploaded media type, maybe # or simply scrub: text =3D text.scrub("*") warn "Text wasn't valid UTF-8, scrubbed" end puts text Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > Henrik >=20 >> Now if it is not, the >> submission tool might want to translate koi-8r into UTF-8 if the >> browser says that is the encoding, but that sounds marginal already. >> ASCII is irrelevant. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 2 23:58:10 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ECC3A10F2 for ; Thu, 2 Apr 2020 23:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paVx0bI0m8RW for ; Thu, 2 Apr 2020 23:58:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0AB3A10F1 for ; Thu, 2 Apr 2020 23:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1585897028; bh=uW+d+1DrcKtiyMIyKYFTbjErXXw9sTex6RrDSVPN7ho=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=V6KgaHIxPX9rxaNZm8E7CH12E3QcO+nJ0W537F1Yqqu+rQmtPkI5TXbu+RzjIU3qy qwsdzqsgDMcMKAPKR00F8SvQpOq7qUiTRkZiRHIsJpjlU2GbdeUmZ8iaCH9+0Wf30P blgMx5anC71yzxKZgSVO/AI+U9TshgMjsSHWhiHw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.49.230]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Md6Mj-1ikeOd1smJ-00aAmM; Fri, 03 Apr 2020 08:57:08 +0200 To: Carsten Bormann , Henrik Levkowetz Cc: xml2rfc@ietf.org References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> From: Julian Reschke Message-ID: <62ba4b89-1956-9708-b366-cbecde9167e6@gmx.de> Date: Fri, 3 Apr 2020 08:57:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:nDQRKPS9OV9tyL5hDML/OHD9/ls4l0UMNAXuF8fhDvPAdto5Lza uYoP+ntvR/97ikX5AKlfX/ROZyEWlCXHIUN2+nHosMXSqp9omNE0OCA68B18LSRt/+qULfq 7OmzbBG9ro2IivkM2A9HbC0qzLdfdGrsJpH8DgeTGPMn/36swDyYOIX2tlHAaP+jirakyZi bdjX5RXcz9jj+Ck8m9keQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:3JmKpT0BYOY=:/umg8PFP75k/HNBdVB7G2g +IbtXQyBz9EFAg8Oi0orNOhwdvETAj5iFyWoAuS/VrTpiDm7UkVhqsVhWZYHlkS2GbyL/olEX k60+YDmWHy3ZuqT7L8MotZbF/AqdGYPSa/tKwwGiggJlXGE3ym+f1nLJ2zxgas+37AVcZ5s69 cSuqRrYANKfs0UwlM3WYjR7sI4c96fvqtNfhkwv1BTX40SXV+5k94v1pKrXfxplggoYjBOspj Um9Vg5Tm59JH4Ltm0vrnLwVXabT7R7IorZiAUkd2atH3N1NkAL+exZd/itZjat+9EP3fuwyfA hNY627wLInA+ysIfUCvZko06oFbUuVqbbo4arkf0fxPcDI50KxpLhLL31fr4nQRskdBDNr7ax 77frX7xcUgEUVvnDm/S9zNQ0vBboHM3YZwxRl5FsV8h6JFM7ZKREe6RBXlLIiX9SsdkQtO0P+ 4JywKmEn9CDkBAFnPYJIFGl5d9igv0pj1wgz4qsx0CdyAvav97F6rJxKCUCgGCeJyILBaYn5n Vbc23sSsntl07mYkuEOVMmE0wB403Lcz7KR4HLsDBts3yeO6XsH1VpO2Fu+yjirGv6nGvaVDh SovZw0hjD2uf/ISn6MEijCpoKJAtQFtNCjbl3DiwT07gLiNs+tp7Q8WqEZtvhvWcpvxBjS6P4 bivOlDPeiEqBzc0Uw1x/aeM+unYicV2YLI6ADsMIajv0oT4+fhWkY2ri1jxgl0KC7hG2Tt0RT sMWmVNS8YeRiYam60tQ3pk0lJ9rH/7Y62zFcy98mXdsD0MOIzvMqHZLdj62Wwqf/NJ3HDU/fv iaX8WWR+Q94RqCJl0yJePTHyFe98l+6bOITBcehjUI+8d5P/MnB9MpZYnROioLF0Au7GTOhf6 NgxFBvu2T5KeiM8Kv/8Y8r34D0VLaHL8y6BhCis6WznflsNCQPFRBKTk9XTSTG1ONxeZmMywo 1bHYSf3sSumu6xB6PhVvNJ6YUnYkNvEH6FzrLr7Fn2NvAqIgNQCiZgbDnC8VcxQppIHxmg9WA 5JsJeUUhkKU3rhHkYTUFhnIBF9VummPx53NkfwhWuv4ANTXUI1Jaus7N44V76F45+ExKeod8X ET323X8gXJ1nYYhUny1rQL3tkUd6yPSMZFFoMT0u4V/QDcs4TKEAxgUyQ93U/EAIdLbqZ0awx E9wLGfxYPtmv5iyH8TJQkA3MJg26VqSuintqU/RlN4CHPAOb+tRAYFhtPl7SsaF2sVZ8cQcO+ 2eB6TioEDEjlOCiO9 Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 06:58:08 -0000 On 03.04.2020 07:06, Carsten Bormann wrote: >>>>> >>>>> +1. >>>>> >>>>> The submission tool should require and assume UTF-8, or at most have= a >>>>> checkbox for ASCII vs UTF-8. In any case, there should be no codese= t >>>>> detection in the submission tool. >>>> >>>> There isn't. The submission tool uses the charset provided by the br= owser >>>> at upload time. >>> >>> Why? >>> Browsers do get these things wrong =E2=80=94 how would they even know? >> >> Below you say that it's extremely easy to sniff whether a file is UTF-8= or >> not, and here you ask how would the browser even know. I see a contrad= iction. >> >> The upload comes with a mime type and charset -- why should the submiss= ion >> tool _not_ use those? > > Because they are mostly wrong. > > This thread started with an observation that the charset provided by the= browser was wrong. Do we have any details/traces? Maybe it's worth filing browser issues. > ... Best regards, Julian From nobody Fri Apr 3 04:22:58 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1149A3A18CA for ; Fri, 3 Apr 2020 04:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL1l5pRbqhlK for ; Fri, 3 Apr 2020 04:22:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333AF3A17DC for ; Fri, 3 Apr 2020 04:09:30 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:63335 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jKKC4-00074S-SX; Fri, 03 Apr 2020 04:09:21 -0700 To: Carsten Bormann References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> Cc: Nico Williams , xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> Date: Fri, 3 Apr 2020 13:08:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J0SaDKg8k2j27fekRwvxkpJ99O7u3NMaL" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, nico@cryptonector.com, cabo@tzi.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 11:22:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --J0SaDKg8k2j27fekRwvxkpJ99O7u3NMaL Content-Type: multipart/mixed; boundary="3AnEMGr0Va9C4VqX1FObRtHKwohK8RWg0"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann Cc: Nico Williams , xml2rfc@ietf.org Message-ID: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> In-Reply-To: <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> --3AnEMGr0Va9C4VqX1FObRtHKwohK8RWg0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2020-04-03 07:06, Carsten Bormann wrote: >>>>>=20 >>>>> +1. >>>>>=20 >>>>> The submission tool should require and assume UTF-8, or at most hav= e a >>>>> checkbox for ASCII vs UTF-8. In any case, there should be no codes= et >>>>> detection in the submission tool. >>>>=20 >>>> There isn't. The submission tool uses the charset provided by the b= rowser >>>> at upload time. >>>=20 >>> Why? >>> Browsers do get these things wrong =E2=80=94 how would they even know= ? >>=20 >> Below you say that it's extremely easy to sniff whether a file is UTF-= 8 or >> not, and here you ask how would the browser even know. I see a contra= diction. >>=20 >> The upload comes with a mime type and charset -- why should the submis= sion >> tool _not_ use those? >=20 > Because they are mostly wrong. So far we've seen 2 cases (I think) of being wrong about the charset, out= of a large number of uploads. I think you're overstating things when you= say 'mostly wrong'. (Nevertheless, since I have already called the UTF-8 workaround for just that , a workaround, I've already started thinking of how to do better.) > This thread started with an observation that the charset provided by > the browser was wrong. Previously, we have had discussions about > markdown files being submitted as application/octet-stream. >=20 > The way browsers are set up, they are trying to use OS hints for > assigning a media type and, possibly, a charset. However, these OS > hints are not designed in a way that they can be relied upon. I've found 'libmagic' highly reliable on Debian Linux and BSD, less so on OpenSUSE Linux. > So in legacy environments with multiple charsets, server-side > libraries such as Microsoft's MLang are being used to sniff the > uploads for their charset. I=E2=80=99m not sure we are in such an envir= onment > any more in 2020, but it is still easy to check for UTF-8-ness and > fall back to a supplied charset if that is not the case. >=20 > It is never productive to believe a browser=E2=80=99s supplied media ty= pe > that an uploaded file is ASCII and then fail if it isn=E2=80=99t. Agreed; we should not fail (which is why the workaround is a workaround, not a solution). > (XML files, of course, carry their charset in them, so no guessing is > required, just checking.) >=20 >>=20 >>>> This fails if the browser says that an UTF-8 file is ASCII, which wa= s the >>>> case here. >>>=20 >>> Why? >>> It is extremely easy to sniff whether a file is UTF-8 or not, and >>> rather more reliable than what browsers say. >>=20 >> Why? With browsers having a userbase of hundreds of millions, why sho= uld >> we assume that our custom code will do better? >=20 > Because the browsers don=E2=80=99t try, and we could. Of course we could. But the browsers also should. If we start out writi= ng code with the assumption that everything we haven't coded ourselves is faulty, we're bound to re-invent the wheel and never have time to build a better carriage. I disagree with your implied assertion that we should= not first try to use the tools and libs around us. > I apologize that my Python-fu is not very strong, but the code looks > like these two lines (plus test harness): How to do something sensible isn't hard, and isn't really the point here;= we already have code to try to deal with similar things a few places, for= instance when reading files with unknown encoding off disk: https://trac.tools.ietf.org/tools/ietfdb/browser/trunk/ietf/group/utils.p= y#L59 I think the point here is that we should not try to replace existing libs= and tools that already exist with the assumption that they are broken bef= ore we even try to work with them. Of course we should do better when we find places where things fall down;= but your underlying premise when you say "Why?", "Why?" seems to be that we should have written more code from the start, rather than try to rely on existing code and fix at failure. Henrik >=20 > #!/usr/bin/env ruby > data =3D ARGF.binmode.read > text =3D data.force_encoding(Encoding::UTF_8) # Assume UTF-8 > if text.valid_encoding? # and check > warn "Valid UTF-8" > else > # ... guess charset from uploaded media type, maybe > # or simply scrub: > text =3D text.scrub("*") > warn "Text wasn't valid UTF-8, scrubbed" > end > puts text >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >>=20 >>=20 >> Henrik >>=20 >>> Now if it is not, the >>> submission tool might want to translate koi-8r into UTF-8 if the >>> browser says that is the encoding, but that sounds marginal already. >>> ASCII is irrelevant. >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 --3AnEMGr0Va9C4VqX1FObRtHKwohK8RWg0-- --J0SaDKg8k2j27fekRwvxkpJ99O7u3NMaL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl6HGUUACgkQTptXS4+7 FxpOhBAAl2hwUDViAJYyvdL2II2vJ+6I611576O5S5xgnVzK3YM8gpR+adMTDTP3 ek2EkJ/fVGwwOblILtyy29XxT5Wnr9QqkAcTW7uJ2fcHflVTcyaRj8V8KyYQHCKI o9JhxFI6Ue8r48lb19KDhLcJR5Wn3kI0gc3yF3EalXNznnEhKJKyLfqpNIdlgZWM NwovA1saaObRv8G4mNVic+ur3MT9HvprlI/RLOeuCpLry+PHkuMTHbzuyb/X1Qva XsckLlgBm0PJmuf2dKEDGFtx9INcUJdyUS/iFiKYBtVMJfNgyGILH9z0HVATvX3f y1jRxPY5nYIsFCr/WAINI9RAgufmG7VvaQyhgv9crp2yFLu86xBqF8OX2jYf6TeM Ff3P026Hzs1tvVZ10U3Hn52TWLt8l45CctNA20XoT7kU9+6keA/buB4jSaYAqgp7 b3I/rFMLJshlqfUexSWQZYTH1Qk90xVMa0eFLbjS9sl1Nb5Ju0Auu5vla6vgK7or HX73KnlVGp9e2OQ6M6dOGrCh/f6SJQzOGL8K/rpYv4r6a3R6PfnW2NnQzYoHopGJ pclf/2fuyNOeXEOvTXiMeSF7nuEB8+VlClSCMmP5qxSF0JUptY4hCxYd53wHZSCt 2Jsa8dFFdmdi+27QbqDPWoP0z2tYvS0g4Y088FXXX+fNsU4j21o= =MFc3 -----END PGP SIGNATURE----- --J0SaDKg8k2j27fekRwvxkpJ99O7u3NMaL-- From nobody Fri Apr 3 04:48:54 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B803A1837 for ; Fri, 3 Apr 2020 04:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AGbmf137U_Z for ; Fri, 3 Apr 2020 04:48:48 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2FA3A182B for ; Fri, 3 Apr 2020 04:48:47 -0700 (PDT) Received: from [IPv6:2601:184:407f:80ce:d8c:13c0:c014:c97d] ([IPv6:2601:184:407f:80ce:d8c:13c0:c014:c97d]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 033BmiWq010765 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Apr 2020 04:48:46 -0700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Oran Mime-Version: 1.0 (1.0) Date: Fri, 3 Apr 2020 07:48:38 -0400 Message-Id: References: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> Cc: Carsten Bormann , xml2rfc@ietf.org In-Reply-To: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> To: Henrik Levkowetz X-Mailer: iPad Mail (17E255) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 11:48:53 -0000 Warning: na=C3=AFf alert Since it was my .txt file generated from xml2rfc on Mac OS that generated th= e original bug report, and HenriK says this is not a common problem for uplo= ads (perhaps because very few people are doing V3 and with UTF-8 stated in t= he file yet), perhaps we could nip the problem in the bud so to speak. Could we not just make sure that on MacOS, xml2rfc outputs a .txt file marke= d correctly as UTF-8 in the OS file system? ___________________________ iDevice - please excuse typos. > On Apr 3, 2020, at 7:26 AM, Henrik Levkowetz wrote:= >=20 > =EF=BB=BF >> On 2020-04-03 07:06, Carsten Bormann wrote: >>>>>>>=20 >>>>>>> +1. >>>>>>>=20 >>>>>>> The submission tool should require and assume UTF-8, or at most have= a >>>>>>> checkbox for ASCII vs UTF-8. In any case, there should be no codese= t >>>>>>> detection in the submission tool. >>>>>>=20 >>>>>> There isn't. The submission tool uses the charset provided by the br= owser >>>>>> at upload time. >>>>>=20 >>>>> Why? >>>>> Browsers do get these things wrong =E2=80=94 how would they even know?= >>>=20 >>> Below you say that it's extremely easy to sniff whether a file is UTF-8 o= r >>> not, and here you ask how would the browser even know. I see a contradi= ction. >>>=20 >>> The upload comes with a mime type and charset -- why should the submissi= on >>> tool _not_ use those? >>=20 >> Because they are mostly wrong. >=20 > So far we've seen 2 cases (I think) of being wrong about the charset, out > of a large number of uploads. I think you're overstating things when you > say 'mostly wrong'. >=20 > (Nevertheless, since I have already called the UTF-8 workaround for just > that , a workaround, I've already started thinking of how to do better.) >=20 >> This thread started with an observation that the charset provided by >> the browser was wrong. Previously, we have had discussions about >> markdown files being submitted as application/octet-stream. >>=20 >> The way browsers are set up, they are trying to use OS hints for >> assigning a media type and, possibly, a charset. However, these OS >> hints are not designed in a way that they can be relied upon. >=20 > I've found 'libmagic' highly reliable on Debian Linux and BSD, less > so on OpenSUSE Linux. >=20 >> So in legacy environments with multiple charsets, server-side >> libraries such as Microsoft's MLang are being used to sniff the >> uploads for their charset. I=E2=80=99m not sure we are in such an environ= ment >> any more in 2020, but it is still easy to check for UTF-8-ness and >> fall back to a supplied charset if that is not the case. >>=20 >> It is never productive to believe a browser=E2=80=99s supplied media type= >> that an uploaded file is ASCII and then fail if it isn=E2=80=99t. >=20 > Agreed; we should not fail (which is why the workaround is a workaround, > not a solution). >=20 >> (XML files, of course, carry their charset in them, so no guessing is >> required, just checking.) >>=20 >>>=20 >>>>> This fails if the browser says that an UTF-8 file is ASCII, which was t= he >>>>> case here. >>>>=20 >>>> Why? >>>> It is extremely easy to sniff whether a file is UTF-8 or not, and >>>> rather more reliable than what browsers say. >>>=20 >>> Why? With browsers having a userbase of hundreds of millions, why shoul= d >>> we assume that our custom code will do better? >>=20 >> Because the browsers don=E2=80=99t try, and we could. >=20 > Of course we could. But the browsers also should. If we start out writin= g > code with the assumption that everything we haven't coded ourselves is > faulty, we're bound to re-invent the wheel and never have time to build > a better carriage. I disagree with your implied assertion that we should > not first try to use the tools and libs around us. >=20 >> I apologize that my Python-fu is not very strong, but the code looks >> like these two lines (plus test harness): >=20 > How to do something sensible isn't hard, and isn't really the point here; > we already have code to try to deal with similar things a few places, for > instance when reading files with unknown encoding off disk: >=20 > https://trac.tools.ietf.org/tools/ietfdb/browser/trunk/ietf/group/utils.py= #L59 >=20 > I think the point here is that we should not try to replace existing libs > and tools that already exist with the assumption that they are broken befo= re > we even try to work with them. >=20 > Of course we should do better when we find places where things fall down; > but your underlying premise when you say "Why?", "Why?" seems to be that > we should have written more code from the start, rather than try to rely > on existing code and fix at failure. >=20 >=20 > Henrik >=20 >=20 >>=20 >> #!/usr/bin/env ruby >> data =3D ARGF.binmode.read >> text =3D data.force_encoding(Encoding::UTF_8) # Assume UTF-8 >> if text.valid_encoding? # and check >> warn "Valid UTF-8" >> else >> # ... guess charset from uploaded media type, maybe >> # or simply scrub: >> text =3D text.scrub("*") >> warn "Text wasn't valid UTF-8, scrubbed" >> end >> puts text >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>>=20 >>>=20 >>> Henrik >>>=20 >>>> Now if it is not, the >>>> submission tool might want to translate koi-8r into UTF-8 if the >>>> browser says that is the encoding, but that sounds marginal already. >>>> ASCII is irrelevant. >>>>=20 >>>> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Fri Apr 3 05:19:24 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF2F3A18DD for ; Fri, 3 Apr 2020 05:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-vqi73TdTLN for ; Fri, 3 Apr 2020 05:19:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F206B3A18DA for ; Fri, 3 Apr 2020 05:19:17 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:63702 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jKLHj-0000JF-LU; Fri, 03 Apr 2020 05:19:17 -0700 To: David Oran References: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> Cc: Carsten Bormann , xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: Date: Fri, 3 Apr 2020 14:18:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="okm9ULPu97hlJFVIVNM0vFeeKHueKarJ9" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, cabo@tzi.org, daveoran@orandom.net X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 12:19:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --okm9ULPu97hlJFVIVNM0vFeeKHueKarJ9 Content-Type: multipart/mixed; boundary="3jBFLGlhptifUWP8fnTjUp2qhRlIvEEbK"; protected-headers="v1" From: Henrik Levkowetz To: David Oran Cc: Carsten Bormann , xml2rfc@ietf.org Message-ID: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output References: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> In-Reply-To: --3jBFLGlhptifUWP8fnTjUp2qhRlIvEEbK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi David, On 2020-04-03 13:48, David Oran wrote: > Warning: na=C3=AFf alert >=20 > Since it was my .txt file generated from xml2rfc on Mac OS that > generated the original bug report, and HenriK says this is not a > common problem for uploads (perhaps because very few people are doing > V3 and with UTF-8 stated in the file yet), perhaps we could nip the > problem in the bud so to speak. >=20 > Could we not just make sure that on MacOS, xml2rfc outputs a .txt > file marked correctly as UTF-8 in the OS file system? Ah! That's a thought. We could, and I'll add that in the next release. I think, however, that we'll still need to do better on the server side. I'll look more at that= once the work on improved interim support on the 'Upcoming Meetings' and related pages is in place. Best regards, Henrik > ___________________________ > iDevice - please excuse typos. >=20 >> On Apr 3, 2020, at 7:26 AM, Henrik Levkowetz wr= ote: >>=20 >> =EF=BB=BF >>> On 2020-04-03 07:06, Carsten Bormann wrote: >>>>>>>>=20 >>>>>>>> +1. >>>>>>>>=20 >>>>>>>> The submission tool should require and assume UTF-8, or at most = have a >>>>>>>> checkbox for ASCII vs UTF-8. In any case, there should be no co= deset >>>>>>>> detection in the submission tool. >>>>>>>=20 >>>>>>> There isn't. The submission tool uses the charset provided by th= e browser >>>>>>> at upload time. >>>>>>=20 >>>>>> Why? >>>>>> Browsers do get these things wrong =E2=80=94 how would they even k= now? >>>>=20 >>>> Below you say that it's extremely easy to sniff whether a file is UT= F-8 or >>>> not, and here you ask how would the browser even know. I see a cont= radiction. >>>>=20 >>>> The upload comes with a mime type and charset -- why should the subm= ission >>>> tool _not_ use those? >>>=20 >>> Because they are mostly wrong. >>=20 >> So far we've seen 2 cases (I think) of being wrong about the charset, = out >> of a large number of uploads. I think you're overstating things when = you >> say 'mostly wrong'. >>=20 >> (Nevertheless, since I have already called the UTF-8 workaround for ju= st >> that , a workaround, I've already started thinking of how to do better= =2E) >>=20 >>> This thread started with an observation that the charset provided by >>> the browser was wrong. Previously, we have had discussions about >>> markdown files being submitted as application/octet-stream. >>>=20 >>> The way browsers are set up, they are trying to use OS hints for >>> assigning a media type and, possibly, a charset. However, these OS >>> hints are not designed in a way that they can be relied upon. >>=20 >> I've found 'libmagic' highly reliable on Debian Linux and BSD, less >> so on OpenSUSE Linux. >>=20 >>> So in legacy environments with multiple charsets, server-side >>> libraries such as Microsoft's MLang are being used to sniff the >>> uploads for their charset. I=E2=80=99m not sure we are in such an env= ironment >>> any more in 2020, but it is still easy to check for UTF-8-ness and >>> fall back to a supplied charset if that is not the case. >>>=20 >>> It is never productive to believe a browser=E2=80=99s supplied media = type >>> that an uploaded file is ASCII and then fail if it isn=E2=80=99t. >>=20 >> Agreed; we should not fail (which is why the workaround is a workaroun= d, >> not a solution). >>=20 >>> (XML files, of course, carry their charset in them, so no guessing is= >>> required, just checking.) >>>=20 >>>>=20 >>>>>> This fails if the browser says that an UTF-8 file is ASCII, which = was the >>>>>> case here. >>>>>=20 >>>>> Why? >>>>> It is extremely easy to sniff whether a file is UTF-8 or not, and >>>>> rather more reliable than what browsers say. >>>>=20 >>>> Why? With browsers having a userbase of hundreds of millions, why s= hould >>>> we assume that our custom code will do better? >>>=20 >>> Because the browsers don=E2=80=99t try, and we could. >>=20 >> Of course we could. But the browsers also should. If we start out wr= iting >> code with the assumption that everything we haven't coded ourselves is= >> faulty, we're bound to re-invent the wheel and never have time to buil= d >> a better carriage. I disagree with your implied assertion that we sho= uld >> not first try to use the tools and libs around us. >>=20 >>> I apologize that my Python-fu is not very strong, but the code looks >>> like these two lines (plus test harness): >>=20 >> How to do something sensible isn't hard, and isn't really the point he= re; >> we already have code to try to deal with similar things a few places, = for >> instance when reading files with unknown encoding off disk: >>=20 >> https://trac.tools.ietf.org/tools/ietfdb/browser/trunk/ietf/group/util= s.py#L59 >>=20 >> I think the point here is that we should not try to replace existing l= ibs >> and tools that already exist with the assumption that they are broken = before >> we even try to work with them. >>=20 >> Of course we should do better when we find places where things fall do= wn; >> but your underlying premise when you say "Why?", "Why?" seems to be th= at >> we should have written more code from the start, rather than try to re= ly >> on existing code and fix at failure. >>=20 >>=20 >> Henrik >>=20 >>=20 >>>=20 >>> #!/usr/bin/env ruby >>> data =3D ARGF.binmode.read >>> text =3D data.force_encoding(Encoding::UTF_8) # Assume UTF-8 >>> if text.valid_encoding? # and check >>> warn "Valid UTF-8" >>> else >>> # ... guess charset from uploaded media type, maybe >>> # or simply scrub: >>> text =3D text.scrub("*") >>> warn "Text wasn't valid UTF-8, scrubbed" >>> end >>> puts text >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>>>=20 >>>>=20 >>>> Henrik >>>>=20 >>>>> Now if it is not, the >>>>> submission tool might want to translate koi-8r into UTF-8 if the >>>>> browser says that is the encoding, but that sounds marginal already= =2E >>>>> ASCII is irrelevant. >>>>>=20 >>>>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>>=20 >>=20 >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >=20 >=20 --3jBFLGlhptifUWP8fnTjUp2qhRlIvEEbK-- --okm9ULPu97hlJFVIVNM0vFeeKHueKarJ9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl6HKacACgkQTptXS4+7 FxqBuRAAztm9b1Kwq3/UWjWCrZqu6Tt3jPDxNVQ+Kb/XzcyPd4C1iK1nhK/X+X6g NpeFi1FekJ6RG4Q5fDpm1SD55Sfj87U630mptf6T23PRf5II6rzZdITTmlzt8OgW I/+mDLHpttmPwFST4ogn+9niCH13q6VnXkSJN1bVklg4kUzF9luGWK+fOP7hJESb U7fbBxpQGzfOAkXz/hQG6Yve5awybCTlNTRHjgbrKZHNajMwX/vDDLNX7hbfjQBy v34+aU/XE1iyfrii/YH92seIscr/xLw8iAL0sA9ePnjfseeUUEmPF4sB4Db6mLzK 9in/P/mSd967ul2P4p84aevnj78H2Bkx2eFlLlDc0gqtpgnJbOEcraKXHlpg1+Gr YrpK1OurOddU8sqWiZR62bGheK17d1COezmltaPHcXD0Ub/PTer34oEMP0Ecx8N5 wsWr62uV+bPOkWw8EcIx9F5db/+QSGelb7JflrDFcfR6jMbsmqffL4klfNj9s3j6 nbC+m7yONtUH54p7yhI+6+pY6y2GbDKmUa7sT1UOPZygnWxyPERlyRJuP8mjdYeb Iv+nvAzET3kTJwS1gAhNJ8mnrl6xmm4Ez49EvkgowRVOoTIfLyLOgDD63SyLzO9c sVz7g9MPFzXJ+6Pd9CJuiI642+AZchImzK2Ds2e9NlDl7EsT0w8= =l9yd -----END PGP SIGNATURE----- --okm9ULPu97hlJFVIVNM0vFeeKHueKarJ9-- From nobody Fri Apr 3 05:46:12 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E8A3A177E for ; Fri, 3 Apr 2020 05:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVMSF79TakLG for ; Fri, 3 Apr 2020 05:46:07 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504EE3A1778 for ; Fri, 3 Apr 2020 05:46:07 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48v06P04cvzydW; Fri, 3 Apr 2020 14:46:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> Date: Fri, 3 Apr 2020 14:46:04 +0200 Cc: xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 607610764.301001-894162620eb030202c7963672edaae40 Content-Transfer-Encoding: quoted-printable Message-Id: References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 12:46:10 -0000 >>=20 >> Because they are mostly wrong. >=20 > So far we've seen 2 cases (I think) of being wrong about the charset, = out > of a large number of uploads. I think you're overstating things when = you > say 'mostly wrong'. Well, I=E2=80=99ve seen hundreds of cases before. I do not think I am overstating this. Of course, the occurrences of tend to get fewer, as systems get cleaner = (i.e., UTF-8 only). >> The way browsers are set up, they are trying to use OS hints for >> assigning a media type and, possibly, a charset. However, these OS >> hints are not designed in a way that they can be relied upon. >=20 > I've found 'libmagic' highly reliable on Debian Linux and BSD, less > so on OpenSUSE Linux. OK, that is *not* using OS hints (which in these cases are limited to = filename =E2=80=9Cextensions=E2=80=9D and locale information). Libmagic on the server side would be mostly OK, with the occasional = misattribution(*) to be expected. On the client side: Which browsers use libmagic to derive content types = (media types + charsets) for uploads? >> It is never productive to believe a browser=E2=80=99s supplied media = type >> that an uploaded file is ASCII and then fail if it isn=E2=80=99t. >=20 > Agreed; we should not fail (which is why the workaround is a = workaround, > not a solution). This is the Internet, which is workaround stacked on workaround. I am not aware of a solution. >> Because the browsers don=E2=80=99t try, and we could. >=20 > Of course we could. But the browsers also should. If we start out = writing > code with the assumption that everything we haven't coded ourselves is > faulty, That would be futile. But on the other hand, believing something works because it =E2=80=9Cshoul= d work=E2=80=9D is not productive either. In particular in the presence of decades of experience to the contrary. (And, yes, when people are moving towards cleaning up things, I=E2=80=99m = all for following along. I=E2=80=99m not aware of that happening in the space of media type = sniffing.) > Of course we should do better when we find places where things fall = down; > but your underlying premise when you say "Why?", "Why?" seems to be = that > we should have written more code from the start, rather than try to = rely > on existing code and fix at failure. My =E2=80=9Cwhy=E2=80=9D was trying to find out if there is a design = rationale I=E2=80=99m oblivious to. Gr=C3=BC=C3=9Fe, Carsten (*) `file -I` on a random collection of "text files=E2=80=9D (by = filename) on my laptop: 1 application/json; charset=3Dus-ascii 4 application/octet-stream; charset=3Dbinary 2 message/rfc822; charset=3Dus-ascii 1 text/html; charset=3Diso-8859-1 2 text/html; charset=3Dutf-8 145 text/plain; charset=3Dus-ascii 99 text/plain; charset=3Dutf-8 1 text/x-c; charset=3Dus-ascii 1 text/x-diff; charset=3Dus-ascii 1 text/xml; charset=3Dus-ascii Using `file --mime-encoding` to get the charset part only: 4 binary 1 iso-8859-1 151 us-ascii 101 utf-8 The file identified as iso-8859-1 is windows-1252 actually. From nobody Fri Apr 3 06:01:23 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4173A08A2 for ; Fri, 3 Apr 2020 06:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3KsLcjQUXnv for ; Fri, 3 Apr 2020 06:01:17 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F0A3A089D for ; Fri, 3 Apr 2020 06:01:17 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48v0Rv1fYfz108H; Fri, 3 Apr 2020 15:01:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: Date: Fri, 3 Apr 2020 15:01:14 +0200 Cc: Henrik Levkowetz , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 607611674.583124-745b03e97ea646dd124b62a3b58babad Content-Transfer-Encoding: quoted-printable Message-Id: References: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> To: David Oran X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 13:01:21 -0000 On 2020-04-03, at 13:48, David Oran wrote: >=20 > Could we not just make sure that on MacOS, xml2rfc outputs a .txt file = marked correctly as UTF-8 in the OS file system? Hi Dave, unfortunately, macOS no longer has metadata in the file system about the = character encoding used for a text file. ISTR macOS classic had this, = but when OS X came out, Apple decided to follow the lead of UNIX here, = where a file is just a string of bytes. (Since xml2rfc is essentially = using the UNIX API internally, it would not be clear now to exercise a = metadata system even if macOS still had one.) [It gets more interesting with filenames as opposed to file content, but = going into that detail would be a whole paper on its own.] Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 3 06:04:53 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4233A08BD for ; Fri, 3 Apr 2020 06:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_GtpiPDaX-M for ; Fri, 3 Apr 2020 06:04:50 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594AF3A08B9 for ; Fri, 3 Apr 2020 06:04:50 -0700 (PDT) Received: from [192.168.15.102] ([IPv6:2601:184:407f:80ce:c105:8cce:5bc6:3a67]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 033D4hQc012762 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Apr 2020 06:04:45 -0700 From: "David R. Oran" To: "Carsten Bormann" Cc: "Henrik Levkowetz" , xml2rfc@ietf.org Date: Fri, 03 Apr 2020 09:04:38 -0400 X-Mailer: MailMate (1.13.1r5680) Message-ID: In-Reply-To: References: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 13:04:52 -0000 On 3 Apr 2020, at 9:01, Carsten Bormann wrote: > On 2020-04-03, at 13:48, David Oran wrote: >> >> Could we not just make sure that on MacOS, xml2rfc outputs a .txt = >> file marked correctly as UTF-8 in the OS file system? > > Hi Dave, > > unfortunately, macOS no longer has metadata in the file system about = > the character encoding used for a text file. Are you sure? Look at = https://developer.apple.com/documentation/mobilecoreservices/uttype/uti_t= ext_types which has let kUTTypeUTF8PlainText: CFString The type identifier for plain text in = a UTF-8 encoding. > ISTR macOS classic had this, but when OS X came out, Apple decided to = > follow the lead of UNIX here, where a file is just a string of bytes. = > (Since xml2rfc is essentially using the UNIX API internally, it would = > not be clear now to exercise a metadata system even if macOS still had = > one.) > > [It gets more interesting with filenames as opposed to file content, = > but going into that detail would be a whole paper on its own.] > > Gr=C3=BC=C3=9Fe, Carsten DaveO From nobody Fri Apr 3 06:12:26 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90D03A163B for ; Fri, 3 Apr 2020 06:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5jq08GPRyM4 for ; Fri, 3 Apr 2020 06:12:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F473A1637 for ; Fri, 3 Apr 2020 06:12:23 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:64154 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jKM78-0000JL-Ep; Fri, 03 Apr 2020 06:12:22 -0700 To: Carsten Bormann , David Oran References: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> Cc: xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <354d1b32-8772-58b1-0764-3389be4bf890@levkowetz.com> Date: Fri, 3 Apr 2020 15:11:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UkghcvVN51COWc22bfCQd2Q0MFP9TX03m" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, daveoran@orandom.net, cabo@tzi.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 13:12:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UkghcvVN51COWc22bfCQd2Q0MFP9TX03m Content-Type: multipart/mixed; boundary="E6KmIkcnLuhhTifwpKwV62n8U4UmjDkmv"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann , David Oran Cc: xml2rfc@ietf.org Message-ID: <354d1b32-8772-58b1-0764-3389be4bf890@levkowetz.com> Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output References: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> In-Reply-To: --E6KmIkcnLuhhTifwpKwV62n8U4UmjDkmv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2020-04-03 15:01, Carsten Bormann wrote: > On 2020-04-03, at 13:48, David Oran wrote: >>=20 >> Could we not just make sure that on MacOS, xml2rfc outputs a .txt file= marked correctly as UTF-8 in the OS file system? >=20 > Hi Dave, >=20 > unfortunately, macOS no longer has metadata in the file system about th= e character encoding used for a text file. ISTR macOS classic had this, = but when OS X came out, Apple decided to follow the lead of UNIX here, wh= ere a file is just a string of bytes. (Since xml2rfc is essentially usin= g the UNIX API internally, it would not be clear now to exercise a metada= ta system even if macOS still had one.) Modern OS-X instead has extended attributes, and there are attributes def= ined (and not exclusive to OS-X) for 'user.mime_type', 'user.charset', and mor= e. There's a Python lib 'xattr' that will let us set these, as appropriate. Henrik > [It gets more interesting with filenames as opposed to file content, bu= t going into that detail would be a whole paper on its own.] >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 --E6KmIkcnLuhhTifwpKwV62n8U4UmjDkmv-- --UkghcvVN51COWc22bfCQd2Q0MFP9TX03m Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl6HNhoACgkQTptXS4+7 Fxom7xAAh24aQLdEi+7GiyIswU/kMrhXelNIfyl+eYsI1XGfkbe+HApyc0mfwU7e oZSQctholXx00nikQAqf1rHA7J1b/u2pSar7Ec/73dXVimey3X+hGj9YHgn+1h4o 95Y6VqFQKXPDep/ew2JjngTQVbW69TZWTtmwk3Rce3TjOfzpZK3kl70DgMztqvMy u7l+TDjADc2T1zxOw8vSH7x+0C4XarWW3Qv83XjNK7L3O3s3MSi0AS0yI/F4eDQ2 FmXvN2aeVUO3i3HCWoq78f83nAGhkJhYffsuY3AFrrKoNTZjo28lyTS4eSSqY5vn 96InFmVFlUSgfDmb0zsYjcz+1MnW5/+bKaQeD6f8CYVlTVNxyomMN62X0AE4Qj8q hT92DAgW7Q4uFhxQPFdLNHSiLGwdsIIQvg263xr04wzQD5RiR64sTqnfRuQKqO/p 0dBFJawoVNk+arApgHmyt/hKc81xnobTVW22XJ8zhIcNTy3qyJyB3KcUsvepOFVJ HbD+hR4MmMfyIrNorjFUJnjybW1RDq8ly9fFK6/MMCBRhYNX4Tp3DnxVj88eXwE4 Vvzs51Q/vT/wRp6X7QVn6xD9dQMUHQEs/uXy2HiZ4DtsDUjRT/Lp5vrRQcprHRLi LnGkdTTRNIYFO/a3xRbEYuuLO2BGxyo/2+seHIxLjyJpInp/f+c= =1Q+a -----END PGP SIGNATURE----- --UkghcvVN51COWc22bfCQd2Q0MFP9TX03m-- From nobody Fri Apr 3 06:18:31 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83263A00C4 for ; Fri, 3 Apr 2020 06:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URG_BIZ=0.573] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mV6moFwQkm9 for ; Fri, 3 Apr 2020 06:18:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94CD93A00AD for ; Fri, 3 Apr 2020 06:18:27 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:64173 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jKMCy-0007lT-S6; Fri, 03 Apr 2020 06:18:26 -0700 To: Carsten Bormann References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> Cc: xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <2ff226a9-797d-19f3-194f-cc4e354539e4@levkowetz.com> Date: Fri, 3 Apr 2020 15:17:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uQtFkGQNhof9KNRIkcWUCKuv45MfkujJV" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, cabo@tzi.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 13:18:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uQtFkGQNhof9KNRIkcWUCKuv45MfkujJV Content-Type: multipart/mixed; boundary="Lb8iqSrCxpneSO92kbGxl6iOPIQQmOeNF"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann Cc: xml2rfc@ietf.org Message-ID: <2ff226a9-797d-19f3-194f-cc4e354539e4@levkowetz.com> Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> In-Reply-To: --Lb8iqSrCxpneSO92kbGxl6iOPIQQmOeNF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2020-04-03 14:46, Carsten Bormann wrote: >>>=20 >>> Because they are mostly wrong. >>=20 >> So far we've seen 2 cases (I think) of being wrong about the charset, = out >> of a large number of uploads. I think you're overstating things when = you >> say 'mostly wrong'. >=20 > Well, I=E2=80=99ve seen hundreds of cases before. > I do not think I am overstating this. > Of course, the occurrences of tend to get fewer, as systems get cleaner= (i.e., UTF-8 only). >=20 >>> The way browsers are set up, they are trying to use OS hints for >>> assigning a media type and, possibly, a charset. However, these OS >>> hints are not designed in a way that they can be relied upon. >>=20 >> I've found 'libmagic' highly reliable on Debian Linux and BSD, less >> so on OpenSUSE Linux. >=20 > OK, that is *not* using OS hints (which in these cases are limited to > filename =E2=80=9Cextensions=E2=80=9D and locale information). So your concept of OS hints did not match my concept of OS hints. > Libmagic on the server side would be mostly OK, with the occasional mis= attribution(*) to be expected. > On the client side: Which browsers use libmagic to derive content types= (media types + charsets) for uploads? I have no idea. >>> It is never productive to believe a browser=E2=80=99s supplied media = type >>> that an uploaded file is ASCII and then fail if it isn=E2=80=99t. >>=20 >> Agreed; we should not fail (which is why the workaround is a workaroun= d, >> not a solution). >=20 > This is the Internet, which is workaround stacked on workaround. > I am not aware of a solution. >=20 >>> Because the browsers don=E2=80=99t try, and we could. >>=20 >> Of course we could. But the browsers also should. If we start out wr= iting >> code with the assumption that everything we haven't coded ourselves is= >> faulty, >=20 > That would be futile. > But on the other hand, believing something works because it =E2=80=9Csh= ould work=E2=80=9D is not productive either. > In particular in the presence of decades of experience to the contrary.= >=20 > (And, yes, when people are moving towards cleaning up things, I=E2=80=99= m all for following along. > I=E2=80=99m not aware of that happening in the space of media type snif= fing.) >=20 >> Of course we should do better when we find places where things fall do= wn; >> but your underlying premise when you say "Why?", "Why?" seems to be th= at >> we should have written more code from the start, rather than try to re= ly >> on existing code and fix at failure. >=20 > My =E2=80=9Cwhy=E2=80=9D was trying to find out if there is a design ra= tionale I=E2=80=99m oblivious to. In this case, there's an attempt at sanity checking uploads, catching thi= ngs like binary and XML files uploaded by mistake or bad intent as if they we= re text, and when text, trying to accomidate various upload encodings. The current code has worked well for a number of years. Yes, we've now found a spot where we fall down. Yes, we're going to fix = it. But there's just a few people (like ~1.5 plus sprint participants) trying= to maintain a huge codebase, with urgent requests coming in quite often, and= trying to make everything work better every day, while still adding featu= res and upgrading to new releases of libs and frameworks. Please be gentle. Henrik >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > (*) `file -I` on a random collection of "text files=E2=80=9D (by filena= me) on my laptop: > 1 application/json; charset=3Dus-ascii > 4 application/octet-stream; charset=3Dbinary > 2 message/rfc822; charset=3Dus-ascii > 1 text/html; charset=3Diso-8859-1 > 2 text/html; charset=3Dutf-8 > 145 text/plain; charset=3Dus-ascii > 99 text/plain; charset=3Dutf-8 > 1 text/x-c; charset=3Dus-ascii > 1 text/x-diff; charset=3Dus-ascii > 1 text/xml; charset=3Dus-ascii >=20 > Using `file --mime-encoding` to get the charset part only: >=20 > 4 binary > 1 iso-8859-1 > 151 us-ascii > 101 utf-8 >=20 > The file identified as iso-8859-1 is windows-1252 actually. >=20 >=20 --Lb8iqSrCxpneSO92kbGxl6iOPIQQmOeNF-- --uQtFkGQNhof9KNRIkcWUCKuv45MfkujJV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl6HN4UACgkQTptXS4+7 FxqgzQ//Wp5ZE5+T5Hygi1NsQ2LZ2kbMwTWCMrhKbAfeY5HJCdJAeIWQJA6fbMxE L8RxPi4UiqD8iND1PkkhNg/lmK1X1FaZ3vp1moBYT9ynh4tVIaM5eTOeudd29lNI oW2Pd2dQfjSp3BOTJNESbOQgvFnY70F0xgGw0BCllXP5FIPlH6Wkfi6JSvPpUv/b XzqPtXYalPx1iBw/AWXmGarmdukwEICzmWc26OrGJaCIDPPlyaM2YVlpudVW/2Qm Oaj560i/iWhZ56vtW95wPKnVvqszzz+Ue0NO8QcqaUt4ZP+8rQNSQfW/wK1Sy1Wj TAA0x1qRepA/0F8ReOzGhRSfLKy62ecoUn2HccxJVMI4GExJWPWHVMAY5LHdMKr9 FVCjZnNCpoqvjXEPxsA8d/Pv3a/5PfvKpjF+dzx6RgvcXUyvM7lwcsPA2+Iw2bPX MDxqwpXKnH0xSm44UnygRxq/j2jEESmE93aE/7rGebvtE+TuSQ/XYqhgbNzF5wwA 4kZ2Nfx4Whje/K4zmDFrJW8h1+jNC889zF+4E65ItBKT6Xph0vomxc9THDbggEtk IflhqjpZ9AusebDcaF2beo7Wl/bw20uWlmWyYeNux4VTqwYcqqmYRwoP6BPpcwHe EWsmFb2kCqDBIzdiLCUZ4QMwZsBxbJ/yp44cJ60Tu22hs725MlA= =Rfis -----END PGP SIGNATURE----- --uQtFkGQNhof9KNRIkcWUCKuv45MfkujJV-- From nobody Fri Apr 3 07:54:32 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2058E3A12A8 for ; Fri, 3 Apr 2020 07:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwbdvlF1_LV7 for ; Fri, 3 Apr 2020 07:54:26 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87363A12A3 for ; Fri, 3 Apr 2020 07:54:26 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48v2yR64F8zyTT; Fri, 3 Apr 2020 16:54:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: Date: Fri, 3 Apr 2020 16:54:23 +0200 Cc: Henrik Levkowetz , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 607618463.194506-c5b59c3947ef5371c1cdfb9131f96cc5 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> To: "David R. Oran" X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 14:54:30 -0000 On 2020-04-03, at 15:04, David R. Oran wrote: >=20 >> unfortunately, macOS no longer has metadata in the file system about = the character encoding used for a text file. > Are you sure? > Look at = https://developer.apple.com/documentation/mobilecoreservices/uttype/uti_te= xt_types >=20 > which has > let kUTTypeUTF8PlainText: CFString The type identifier for plain text = in a UTF-8 encoding. =E2=80=9CUniform Type Identifiers=E2=80=9D (UTIs) are mostly there to = identify pasteboard content =E2=80=94 clearly, you need to know the = charset when copying and pasting data between applications, some of = which may be stuck in legacy. They are also used in a macOS structured = metadata thing called =E2=80=9CBundle=E2=80=9D. Within a program, they = may be useful as a summary of what you have learned from filename = extensions and the OSType file system metadata that was deprecated in = 2003 with OS X Panther. (I=E2=80=99m not sure how much remains of = OSType, but I=E2=80=99m not aware that ever contained charset = information.) Henrik seems to have dug out an ~2005 initiative from Lennart Poettering = to use file system xattr for media types and charsets. I=E2=80=99m not = aware of any traction this has had, except for the mod-mime-xattr Apache = module (the only recent information I can find about is from some bitrot = this module has accreted since it last was actively worked on at the = start of the previous decade). The specification lives on in = https://www.freedesktop.org/wiki/CommonExtendedAttributes/ which = essentially refers to mod-mime-xattr and = https://specifications.freedesktop.org/shared-mime-info-spec/latest/ar01s0= 2.html#idm46096015332608 . So I have to agree with Henrik that "there = are attributes defined=E2=80=9D, but it would be a bit of an = overstatement to say that macOS =E2=80=9Chas=E2=80=9D these attributes = =E2=80=94 yes, you can stash them there, but they will be ignored. I am not a fan of the current situation. It becomes bearable because = these are all problems of the past; they simply no longer occur on = modern UTF-8-clean systems. The reason this took 20 years to clear up = was because people were trying to be =E2=80=9Chelpful=E2=80=9D towards = deprecated stuff, and thus prolonged the problem for a near-eternity = [sound familiar from other transition situations?]. Here, people have = given up =E2=80=9Cbeing helpful=E2=80=9D for a while now, and the = situation is becoming better. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 3 08:10:46 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF913A16D8 for ; Fri, 3 Apr 2020 08:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXQbEXsI8DdA for ; Fri, 3 Apr 2020 08:10:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2682C3A16CC for ; Fri, 3 Apr 2020 08:10:42 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:64810 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jKNxd-0006GR-1y; Fri, 03 Apr 2020 08:10:41 -0700 To: Carsten Bormann , "David R. Oran" References: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> Cc: xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <8dcb3bf7-cd90-67ce-4336-8a5fcf6d42b3@levkowetz.com> Date: Fri, 3 Apr 2020 17:10:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="U2Je8hj47IdVnABe7fausGL0aE2Om9WJj" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, daveoran@orandom.net, cabo@tzi.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 15:10:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U2Je8hj47IdVnABe7fausGL0aE2Om9WJj Content-Type: multipart/mixed; boundary="1g3o6XrB5taEXexGSBifFb8xMtah2khri"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann , "David R. Oran" Cc: xml2rfc@ietf.org Message-ID: <8dcb3bf7-cd90-67ce-4336-8a5fcf6d42b3@levkowetz.com> Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output References: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> In-Reply-To: --1g3o6XrB5taEXexGSBifFb8xMtah2khri Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2020-04-03 16:54, Carsten Bormann wrote: > On 2020-04-03, at 15:04, David R. Oran wrote: >>=20 >>> unfortunately, macOS no longer has metadata in the file system about = the character encoding used for a text file. >> Are you sure? >> Look at https://developer.apple.com/documentation/mobilecoreservices/u= ttype/uti_text_types >>=20 >> which has >> let kUTTypeUTF8PlainText: CFString The type identifier for plain text = in a UTF-8 encoding. >=20 > =E2=80=9CUniform Type Identifiers=E2=80=9D (UTIs) are mostly there to i= dentify pasteboard content =E2=80=94 clearly, you need to know the charse= t when copying and pasting data between applications, some of which may b= e stuck in legacy. They are also used in a macOS structured metadata thi= ng called =E2=80=9CBundle=E2=80=9D. Within a program, they may be useful= as a summary of what you have learned from filename extensions and the O= SType file system metadata that was deprecated in 2003 with OS X Panther.= (I=E2=80=99m not sure how much remains of OSType, but I=E2=80=99m not a= ware that ever contained charset information.) >=20 > Henrik seems to have dug out an ~2005 initiative from Lennart Poetterin= g to use file system xattr for media types and charsets. I=E2=80=99m not= aware of any traction this has had, except for the mod-mime-xattr Apache= module (the only recent information I can find about is from some bitrot= this module has accreted since it last was actively worked on at the sta= rt of the previous decade). The specification lives on in https://www.fr= eedesktop.org/wiki/CommonExtendedAttributes/ which essentially refers to = mod-mime-xattr and https://specifications.freedesktop.org/shared-mime-inf= o-spec/latest/ar01s02.html#idm46096015332608 . So I have to agree with H= enrik that "there are attributes defined=E2=80=9D, but it would be a bit = of an overstatement to say that macOS =E2=80=9Chas=E2=80=9D these attribu= tes =E2=80=94 yes, you can stash them there, but they will be ignored. This is a rather severe misrepresentation of extended file attributes und= er OS X. Extended file attributes are in active use by the operating system= and applications, and help OS X do things such as displaying directory trees as documents where appropriate, and quarantining downloaded documen= ts. There's a bit more information here, although not a lot: https://en.wikipedia.org/wiki/Extended_file_attributes#macOS This also gives a bit of information: https://eclecticlight.co/2017/08/14/show-me-your-metadata-extended-attrib= utes-in-macos-sierra/ > I am not a fan of the current situation. It becomes bearable because > these are all problems of the past; they simply no longer occur on > modern UTF-8-clean systems. The reason this took 20 years to clear up > was because people were trying to be =E2=80=9Chelpful=E2=80=9D towards = deprecated > stuff, and thus prolonged the problem for a near-eternity [sound > familiar from other transition situations?]. Here, people have given > up =E2=80=9Cbeing helpful=E2=80=9D for a while now, and the situation i= s becoming > better. I think we're all happy that we're moving towards UTF-8 support becoming more ubiquitous. Henrik --1g3o6XrB5taEXexGSBifFb8xMtah2khri-- --U2Je8hj47IdVnABe7fausGL0aE2Om9WJj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl6HUdUACgkQTptXS4+7 FxoZFxAAqRYtfV6KVxwaYssvm6KGelPB+WRo3CdL9W77qaR0D9FYmHTI9W4MJRRc fgPcuOuUj70RRDu4wf+iL5oKEWjeXM4RKTiBX8bJ2Xpr/finE2/9Hbh5NA0lAC3t qWHnfKKQPLNIUwg6T90wD/jRtl4vmwUz64xc18DpnKHfk9ICFHcy6LI7xgksWEYD GE9zhkjuHc4NA9SWLYr6XKtEXLWz+/jBYhRxydSQU1EmWypcfVgj8n6a2aYKW1ii GtN1VKEJVoz3BcPNdEtyHXwJMDdKJ87If+VdKi7pCmKc0DA1LQPS+ZzxEz7usMpV VEyPg0+DwBqZU2dYHWtuLE2XuF0YVvs2XDqkp1MwYUSkV2W2y0SB8sQA3z5woRPP 8aILbDb5/SZyXuUIj4kkf7vmvk6m7kiRVf55PdvrHQkk7YSbQ06UbOWrP3o9LpvG C6S6ZGs/f1WCvRUz3/WyrvXGv/ndpABnMSApXeC0nF+4MtUApYpYHxZoPrl8LSyM 0Hg+GPcK2Nz+JrmQE13XtPnKiUBUXBJ9mbTsFZ450wp2q37Vj4lhmk0FEN0+ItyB 3JymAHJRYPHCNnQCfWsuWclbs7QWKQ7t2EH3QwJrpyZFSdta9AyvETvr9buyHpFC hAb0D0lqWHS10G9WPW6AIphblIZEiMuueTlJMtWFrfqzN90dubw= =2Vpp -----END PGP SIGNATURE----- --U2Je8hj47IdVnABe7fausGL0aE2Om9WJj-- From nobody Fri Apr 3 08:22:34 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3661B3A12FF for ; Fri, 3 Apr 2020 08:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfbZanAj7Q56 for ; Fri, 3 Apr 2020 08:22:31 -0700 (PDT) Received: from chocolate.birch.relay.mailchannels.net (chocolate.birch.relay.mailchannels.net [23.83.209.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1933A12E7 for ; Fri, 3 Apr 2020 08:22:31 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A3F38401755; Fri, 3 Apr 2020 15:22:30 +0000 (UTC) Received: from pdx1-sub0-mail-a9.g.dreamhost.com (100-96-14-17.trex.outbound.svc.cluster.local [100.96.14.17]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id EA37A401535; Fri, 3 Apr 2020 15:22:29 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a9.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Fri, 03 Apr 2020 15:22:30 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Trouble-Fumbling: 4e77f8097b2710c5_1585927350440_370509248 X-MC-Loop-Signature: 1585927350440:2907252660 X-MC-Ingress-Time: 1585927350440 Received: from pdx1-sub0-mail-a9.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTP id AA2607E5E9; Fri, 3 Apr 2020 08:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=J+j571CGQPesOKquFicIL0VnxIA=; b=AQRygH7zUeS nAiI99fd2AbCm+q43fupUP0HZu1sx8TZi4zh6+bh/hG1TMM9oRSoQyDC+C66ZrAc ipX0wPYqxUq5o3JLUYjwAFf2w3yE9VIHK3lDEQSn5jj3Gl9HRfBQB69zaoPgWGwk CRe4QFGdzvyA/y0dihYquqDhrkjgFw/4= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 11B3A7E5D3; Fri, 3 Apr 2020 08:22:26 -0700 (PDT) Date: Fri, 3 Apr 2020 10:22:23 -0500 X-DH-BACKEND: pdx1-sub0-mail-a9 From: Nico Williams To: Henrik Levkowetz Cc: Carsten Bormann , xml2rfc@ietf.org Message-ID: <20200403152222.GA18021@localhost> References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrtdeigdekjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 15:22:33 -0000 On Thu, Apr 02, 2020 at 09:31:13PM +0200, Henrik Levkowetz wrote: > On 2020-04-02 21:19, Carsten Bormann wrote: > >> On 2020-04-02, at 21:13, Henrik Levkowetz wro= te: > >> There isn't. The submission tool uses the charset provided by the b= rowser > >> at upload time. > >=20 > > Why? > > Browsers do get these things wrong =E2=80=94 how would they even know= ? >=20 > Below you say that it's extremely easy to sniff whether a file is UTF-8= or > not, and here you ask how would the browser even know. I see a contrad= iction. >=20 > The upload comes with a mime type and charset -- why should the submiss= ion > tool _not_ use those? We should require UTF-8. Or we should require ASCII | UTF-8. > >> This fails if the browser says that an UTF-8 file is ASCII, which wa= s the > >> case here. > >=20 > > Why? > > It is extremely easy to sniff whether a file is UTF-8 or not, and > > rather more reliable than what browsers say. >=20 > Why? With browsers having a userbase of hundreds of millions, why shou= ld > we assume that our custom code will do better? Requiring ASCII | UTF-8 would let us not care what the browser thinks. Certainly you could reject submissions where the browser thinks the text is in some codeset other than ASCII or UTF-8. And you should reject submissions where the contents is clearly not ASCII and not UTF-8. We have no need to support any other codeset. Not ISO-8859-*, not SHIFT-JIS, nothing. UTF-8 or bust. Nico --=20 From nobody Fri Apr 3 08:49:29 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333FB3A194D for ; Fri, 3 Apr 2020 08:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvCaIyDYuIW6 for ; Fri, 3 Apr 2020 08:49:25 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD2E3A1948 for ; Fri, 3 Apr 2020 08:49:25 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48v49v4h7zz1090; Fri, 3 Apr 2020 17:49:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <8dcb3bf7-cd90-67ce-4336-8a5fcf6d42b3@levkowetz.com> Date: Fri, 3 Apr 2020 17:49:23 +0200 Cc: xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 607621763.03907-9e58b2f3795045acc2dd8f493d08cc41 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> <8dcb3bf7-cd90-67ce-4336-8a5fcf6d42b3@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 15:49:27 -0000 On 2020-04-03, at 17:10, Henrik Levkowetz wrote: >=20 > This is a rather severe misrepresentation of extended file attributes = under > OS X. Extended file attributes are in active use by the operating = system > and applications, and help OS X do things such as displaying directory > trees as documents where appropriate, and quarantining downloaded = documents. >=20 > There's a bit more information here, although not a lot: >=20 > https://en.wikipedia.org/wiki/Extended_file_attributes#macOS >=20 > This also gives a bit of information: >=20 > = https://eclecticlight.co/2017/08/14/show-me-your-metadata-extended-attribu= tes-in-macos-sierra/ Certainly macOS uses xattr. I was talking about =E2=80=9Cuser.charset=E2=80=9D, which essentially = does not exist in macOS. There also is a =E2=80=9Ccom.apple.TextEncoding=E2=80=9D, which is used = by applications such as TextEdit and I think approximately two more. = But that is macOS-specific. You can set that to "utf-8;134217984=E2=80=9D= [sic] and TextEdit and BBedit will know that the file is UTF-8. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 3 12:56:32 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED033A012A for ; Fri, 3 Apr 2020 12:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stgUUae-HAHd for ; Fri, 3 Apr 2020 12:56:30 -0700 (PDT) Received: from fossa.birch.relay.mailchannels.net (fossa.birch.relay.mailchannels.net [23.83.209.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0D13A011D for ; Fri, 3 Apr 2020 12:56:30 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5D83254076B; Fri, 3 Apr 2020 19:56:29 +0000 (UTC) Received: from pdx1-sub0-mail-a9.g.dreamhost.com (100-96-14-18.trex.outbound.svc.cluster.local [100.96.14.18]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 8ED68540B81; Fri, 3 Apr 2020 19:56:28 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a9.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Fri, 03 Apr 2020 19:56:29 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Gusty-Chief: 65538e87071f47fe_1585943789101_2135256309 X-MC-Loop-Signature: 1585943789101:2884107779 X-MC-Ingress-Time: 1585943789101 Received: from pdx1-sub0-mail-a9.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTP id 2B2647EFFF; Fri, 3 Apr 2020 12:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=vpuc8WzTo+jBWnwJU+m9Ng/Y/CA=; b=FNDJXNPWNjb JSKjqs0yUvl+k+4hRd6FKeehBBZIdYYbigWUkai/ipxVelmse4sZk/GIIHzeStSH ZKfjfUhvxPPiycogtG9ge232YwazNmAGXITw5LUgoZYVJbKxbBAD+miyOEymV+r1 03nO3Sq6gT/5PgGkdPbMeJNbZI4da+R4= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 73F207F007; Fri, 3 Apr 2020 12:56:24 -0700 (PDT) Date: Fri, 3 Apr 2020 14:56:22 -0500 X-DH-BACKEND: pdx1-sub0-mail-a9 From: Nico Williams To: Carsten Bormann Cc: Henrik Levkowetz , xml2rfc@ietf.org Message-ID: <20200403195620.GB18021@localhost> References: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> <8dcb3bf7-cd90-67ce-4336-8a5fcf6d42b3@levkowetz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrtdeigddugedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtugfgjggfsehtkeertddtreejnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuffhomhgrihhnpeifihhkihhpvgguihgrrdhorhhgpdgvtghlvggtthhitghlihhghhhtrdgtohenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 19:56:32 -0000 On Fri, Apr 03, 2020 at 05:49:23PM +0200, Carsten Bormann wrote: > On 2020-04-03, at 17:10, Henrik Levkowetz wrote: > > This is a rather severe misrepresentation of extended file attributes= under > > OS X. Extended file attributes are in active use by the operating sy= stem > > and applications, and help OS X do things such as displaying director= y > > trees as documents where appropriate, and quarantining downloaded doc= uments. > >=20 > > There's a bit more information here, although not a lot: > >=20 > > https://en.wikipedia.org/wiki/Extended_file_attributes#macOS > >=20 > > This also gives a bit of information: > >=20 > > https://eclecticlight.co/2017/08/14/show-me-your-metadata-extended-at= tributes-in-macos-sierra/ >=20 > Certainly macOS uses xattr. >=20 > I was talking about =E2=80=9Cuser.charset=E2=80=9D, which essentially d= oes not exist in macOS. By which you mean "it's not universally used". > There also is a =E2=80=9Ccom.apple.TextEncoding=E2=80=9D, which is used= by > applications such as TextEdit and I think approximately two more. But > that is macOS-specific. You can set that to "utf-8;134217984=E2=80=9D = [sic] > and TextEdit and BBedit will know that the file is UTF-8. But the right thing is to just use UTF-8. Use UTF-8 locales only. Perform codeset conversions only as needed for interop, but default to UTF-8. No tasting of encoding. Do not trust, just validate, and do not taste. The I-D submission tool should loudly advertise that the .xml file MUST be in UTF-8 and should reject submissions with non-UTF-8. No tasting of the contents' encoding should be perfomed. If a user submits valid-looking garbage, then they'll get garbage and reviewers will notice. Another thing that could be done is require no alternate format submission when submitting XML: just apply xml2rfc on the server side. Cheers, Nico --=20 From nobody Fri Apr 3 12:57:42 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2434E3A03F8 for ; Fri, 3 Apr 2020 12:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ilLLXKWR; dkim=pass (1536-bit key) header.d=taugh.com header.b=GstTo0ul Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBH6jYXWAHUd for ; Fri, 3 Apr 2020 12:57:39 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E363A03F5 for ; Fri, 3 Apr 2020 12:57:39 -0700 (PDT) Received: (qmail 72786 invoked from network); 3 Apr 2020 19:57:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=11c4e.5e879532.k2004; bh=rlTce+FVx0BFBZTdlX4EYOW7Z6vSKmUr6YIKMrRsoQ4=; b=ilLLXKWRDF/67PUOrwS3HmwpsU8TKIB+Zkn0lm/buym19ZEpedcYA9QAWcLLb7uxGdP9WPjg015LoX4gpP9qnriKKU79i/xDxn6Me63nTZGqJlqdo+F3Qlvb90+OTck90aLTZHwsH/0x0zTLeXb1cyDlYwD+udDhyj42v4fFRiwUVq179YwmQ117kRrK2r8HoiXfA7XJ7FU74620u19QKtBqIPXp76GjreMJ53RnNPTjqDCbda3gvmOcMD96bdnI DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=11c4e.5e879532.k2004; bh=rlTce+FVx0BFBZTdlX4EYOW7Z6vSKmUr6YIKMrRsoQ4=; b=GstTo0ulyK0rHyJH8UVPhHb06okw4HFSOqpmR2w/1dDo5BwG49+6goiu5ZjlsiOQfN2tMnY7cQz39RJQdC1IftNupQWOPRYfcbq2EK5IMhKSoeOyRvD5KgZsdvXLbQyHRp2wcRX2OSiyW6xaZyDHfqYz+pT7pq3+0LUDl6cj0CbPml13tqi0+2i798v5hjqIHxkPpjL8WWhLvHRglrXivcjEm09zpwH/KKq70cGeGtzXXsIzySjmwAzo39bI8nQa Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 03 Apr 2020 19:57:37 -0000 Received: by ary.qy (Postfix, from userid 501) id 8BD6116FC8A2; Fri, 3 Apr 2020 15:57:36 -0400 (EDT) Date: 3 Apr 2020 15:57:36 -0400 Message-Id: <20200403195737.8BD6116FC8A2@ary.qy> From: "John Levine" To: xml2rfc@ietf.org Cc: julian.reschke@gmx.de In-Reply-To: <62ba4b89-1956-9708-b366-cbecde9167e6@gmx.de> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 19:57:41 -0000 In article <62ba4b89-1956-9708-b366-cbecde9167e6@gmx.de> you write: >> This thread started with an observation that the charset provided by the browser >was wrong. > >Do we have any details/traces? Maybe it's worth filing browser issues. My guess is that they would say the take the file type from the filename, that's the only clue they have and if we don't like it we should tell our users to go edit some obscure MIME type file. But here's a question: if we pretended that files that were tagged as ASCII are actually UTF-8, what bad things could happen? If they really are ASCII, that should be OK. If they're really UTF-8, that should be OK. I'd only expect a problem if they're some in other character set but these days that doesn't seem particularly likely. R's, John From nobody Fri Apr 3 13:12:33 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424863A09B9 for ; Fri, 3 Apr 2020 13:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roi2f7Q24uxy for ; Fri, 3 Apr 2020 13:12:27 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8533A09AD for ; Fri, 3 Apr 2020 13:12:26 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48vB1N6nNRzyNv; Fri, 3 Apr 2020 22:12:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <20200403195620.GB18021@localhost> Date: Fri, 3 Apr 2020 22:12:24 +0200 Cc: Henrik Levkowetz , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 607637544.344301-691a6747dba0f9bd91fbf6c4c21aa8ac Content-Transfer-Encoding: quoted-printable Message-Id: <307195D0-2DF5-4CBD-B8C4-C53348B80CB1@tzi.org> References: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> <8dcb3bf7-cd90-67ce-4336-8a5fcf6d42b3@levkowetz.com> <20200403195620.GB18021@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 20:12:31 -0000 On 2020-04-03, at 21:56, Nico Williams wrote: >=20 > On Fri, Apr 03, 2020 at 05:49:23PM +0200, Carsten Bormann wrote: >> On 2020-04-03, at 17:10, Henrik Levkowetz = wrote: >>> This is a rather severe misrepresentation of extended file = attributes under >>> OS X. Extended file attributes are in active use by the operating = system >>> and applications, and help OS X do things such as displaying = directory >>> trees as documents where appropriate, and quarantining downloaded = documents. >>>=20 >>> There's a bit more information here, although not a lot: >>>=20 >>> https://en.wikipedia.org/wiki/Extended_file_attributes#macOS >>>=20 >>> This also gives a bit of information: >>>=20 >>> = https://eclecticlight.co/2017/08/14/show-me-your-metadata-extended-attribu= tes-in-macos-sierra/ >>=20 >> Certainly macOS uses xattr. >>=20 >> I was talking about =E2=80=9Cuser.charset=E2=80=9D, which essentially = does not exist in macOS. >=20 > By which you mean "it's not universally used". I really meant =E2=80=9Cit=E2=80=99s universally not used=E2=80=9D. >=20 >> There also is a =E2=80=9Ccom.apple.TextEncoding=E2=80=9D, which is = used by >> applications such as TextEdit and I think approximately two more. = But >> that is macOS-specific. You can set that to "utf-8;134217984=E2=80=9D = [sic] >> and TextEdit and BBedit will know that the file is UTF-8. >=20 > But the right thing is to just use UTF-8. Use UTF-8 locales only. Yes! Up to a few years you would have been met with =E2=80=9Cmy IT = people set the locale on my laptop to Armenian ArmSCII and locked that = down so I can=E2=80=99t do UTF-8=E2=80=9D. This is no longer a problem = (*). > Perform codeset conversions only as needed for interop, but default to > UTF-8. I would be even more radical here. > No tasting of encoding. Do not trust, just validate, and do not = taste. Works for me. > The I-D submission tool should loudly advertise that the .xml file = MUST > be in UTF-8 and should reject submissions with non-UTF-8. No tasting = of > the contents' encoding should be perfomed. If a user submits > valid-looking garbage, then they'll get garbage and reviewers will > notice. (One hopes :-) > Another thing that could be done is require no alternate format > submission when submitting XML: just apply xml2rfc on the server side. I think we are slowly getting to the place where this may be a valid = option for most documents that go to RFC. But it remains important to = be able to type up an I-D in Wordperfect, and be able to submit it (as = long as it is UTF-8, which it may be by way of being ASCII), so I=E2=80=99= m not sure we can go the full way here. Gr=C3=BC=C3=9Fe, Carsten (*) At least I believe so; I have not talked to all Armenian IETFers to = verify this. From nobody Fri Apr 3 13:13:30 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0549E3A09AF for ; Fri, 3 Apr 2020 13:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDr5KpN9vFyS for ; Fri, 3 Apr 2020 13:13:27 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DED33A09A9 for ; Fri, 3 Apr 2020 13:13:27 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id fh8so3489385pjb.5 for ; Fri, 03 Apr 2020 13:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qNtzxzlBT2i3SsxGidDvkDs/HigZXJu47CECqkhW3OE=; b=NkUoySWoJ2nzxzYZ86GX7CZFWL7uNSO5lVrvWXn6vlUhb1/oyh0jitSxrByNur4sAT vZYd/ze5OJV6tZtqs65oJXkceW5q29ZereehX7iwfBuQQB74GWjxvEMzpsBpfTSuBKrO CalrSDS+O9Qjc7GiAFHSw/XKqqWOkEouRSWBzK3GEtzF7HeDCb6WUFPvN8zinw/Rm0C+ Eeak2Icd9KF+GyMEKVfGRoBeznodyll1wDn6n5EK3GlYq3MmYkzRMt1YINqC8EQlfNOJ 7lcFH9zPNTBLV9IuIiQktV2oQh6Z2XASbKw20ibfgOclZ+SIXt8Tq6uUltqhdRyowoj4 Bf7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qNtzxzlBT2i3SsxGidDvkDs/HigZXJu47CECqkhW3OE=; b=lu8D7GL632BZ7JWgKTVzIZ2SpDFkKvaloqq7OiVaI6Q9oSOhcFROXLNRv6d2qZ0mOd Yz4Tb0RYG6607YdbiiYzKlJNxmlw0BwKUnBPF18MBip5UWa9dVG73X23GF7ReDfy9UFL roJ8OnvSGUONNyUQZ3FlQY40nPffWQnf5SA2USArMlgIVeVUgtrAKUBpA6saslBpu6U5 gpXE1adG8YFePEbRbYk3jwlIJQYYCuxGZp/7FEAfhcw6IKDsybXJnSvito/OxefwYFL2 DRZcSEJ/cSCYmSu3B7WjA7uaZVAPXh7goQzf26obLX/RxmlfNMprYe2WZU5pjwx3bQZo iQ4g== X-Gm-Message-State: AGi0PuZ3yL9qTcjoODUDzfiOyozFhffwVbHGjg3hxm6yEMZ5t/ZB9gpx QrU7UW9W0eYW+ojywApFKVM= X-Google-Smtp-Source: APiQypKAgF05lZmteJoD62umXEWuwCro/EJSOqkgQKmsQWIX+CequYrV4AWjkEY75gFMBH+5/BRSZA== X-Received: by 2002:a17:902:7244:: with SMTP id c4mr9654118pll.88.1585944806992; Fri, 03 Apr 2020 13:13:26 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id p12sm6625168pfq.153.2020.04.03.13.13.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2020 13:13:26 -0700 (PDT) To: John Levine , xml2rfc@ietf.org Cc: julian.reschke@gmx.de References: <20200403195737.8BD6116FC8A2@ary.qy> From: Brian E Carpenter Message-ID: <05aa2e1c-7fea-9166-d803-e8247319b8a7@gmail.com> Date: Sat, 4 Apr 2020 09:13:22 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200403195737.8BD6116FC8A2@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 20:13:29 -0000 John, On 04-Apr-20 08:57, John Levine wrote: > In article <62ba4b89-1956-9708-b366-cbecde9167e6@gmx.de> you write: >>> This thread started with an observation that the charset provided by = the browser >> was wrong. >> >> Do we have any details/traces? Maybe it's worth filing browser issues.= >=20 > My guess is that they would say the take the file type from the > filename, that's the only clue they have and if we don't like it we > should tell our users to go edit some obscure MIME type file. >=20 > But here's a question: if we pretended that files that were tagged as > ASCII are actually UTF-8, what bad things could happen? If they > really are ASCII, that should be OK. If they're really UTF-8, that > should be OK. I'd only expect a problem if they're some in other > character set but these days that doesn't seem particularly likely. If you mean, idnits should not barf on valid UTF-8 for the purpose of I-D submission, I wouldn't see that as a disaster, but the problem still needs to be solved before the RPC posts RFCnnnn.txt. However, we would need to get used to things like Universit=C3=83=C2=A4t = Bremen. Brian From nobody Fri Apr 3 13:27:33 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682293A0A13 for ; Fri, 3 Apr 2020 13:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=kZZ3wCI9; dkim=pass (1536-bit key) header.d=taugh.com header.b=qENFNDFk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqLKX1AXboTm for ; Fri, 3 Apr 2020 13:27:29 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58AAA3A080A for ; Fri, 3 Apr 2020 13:27:29 -0700 (PDT) Received: (qmail 78140 invoked from network); 3 Apr 2020 20:27:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13139.5e879c30.k2004; i=johnl-iecc.com@submit.iecc.com; bh=BMJVxc8/KLD0KiXsWjDiGHXm0KOZNonAUSP0Q1fLwAY=; b=kZZ3wCI95rpc6PVlab6KCOX+bmTq4aOcpyKVvjaDQcmEEvspwevvJbMlFbYiS+Ho74hEPLvn9cR4aVrFK+sVYzxJJRBSe2jXQWPCj4rRJUEKNAAy20Rogbkfv0wOyKKV8JpreYqhysithOMVUewhoMwlPnJ7NJjKM3yBmrawn4789bq0UHM1HsdCmCRffY+oqgPBOMNF2GTQjYJNrlO8LW/2Y/BYiIDgvPf68j0XJQDw/4VUAr8EsNAZBCSJXCKI DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13139.5e879c30.k2004; olt=johnl-iecc.com@submit.iecc.com; bh=BMJVxc8/KLD0KiXsWjDiGHXm0KOZNonAUSP0Q1fLwAY=; b=qENFNDFk7U4pGLwJb5e2YIE+rXoxBJE9xkoa/PZJNKpClQa4xMXu7bfmEj22RHqwcSZwgbeeQ0LFfbbMXyd4eCkgyBDRg8ywvnuHauv4OGFaOwBbcBsh1QiGPQNew1Eg6RWGkZjK46oh8tllGmWIhQT59CmN+OIHviotnGrK05UgyMczeVkdC6eG33g9oaINVHbtUcB9GtJwycLnTMgnROvwFLRWqK3Pnb2ZveN56oOGr9UVSWZ75rlq7sFEu/FJ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 03 Apr 2020 20:27:27 -0000 Date: 3 Apr 2020 16:27:27 -0400 Message-ID: From: "John R Levine" To: "Brian E Carpenter" , xml2rfc@ietf.org In-Reply-To: <05aa2e1c-7fea-9166-d803-e8247319b8a7@gmail.com> References: <20200403195737.8BD6116FC8A2@ary.qy> <05aa2e1c-7fea-9166-d803-e8247319b8a7@gmail.com> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 20:27:31 -0000 > If you mean, idnits should not barf on valid UTF-8 for the purpose > of I-D submission, I wouldn't see that as a disaster, but the problem > still needs to be solved before the RPC posts RFCnnnn.txt. We allow all sorts of crud in I-D's that we fix before publication, of which rogue UTF-8 is a very minor example. We have policies about where and how non-ASCII text can appear in RFCs. That's what RFC 7997 is about. We need to update 7997, but that doesn't matter for this question. (See https://github.com/rfc-format/draft-iab-rfc-nonascii-bis if interested.) Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Apr 3 13:28:25 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEEC3A0A3F for ; Fri, 3 Apr 2020 13:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_myKxvKVTsi for ; Fri, 3 Apr 2020 13:28:21 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFD83A0A3B for ; Fri, 3 Apr 2020 13:28:21 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48vBMl2Qvszytv; Fri, 3 Apr 2020 22:28:19 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <05aa2e1c-7fea-9166-d803-e8247319b8a7@gmail.com> Date: Fri, 3 Apr 2020 22:28:18 +0200 Cc: John Levine , xml2rfc@ietf.org, julian.reschke@gmx.de X-Mao-Original-Outgoing-Id: 607638498.770013-78a07e9a4f6faa396ca14d2bf9d570cf Content-Transfer-Encoding: quoted-printable Message-Id: <1FD734D4-4E2B-4DB3-83BA-D32490A99E1B@tzi.org> References: <20200403195737.8BD6116FC8A2@ary.qy> <05aa2e1c-7fea-9166-d803-e8247319b8a7@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 20:28:23 -0000 On 2020-04-03, at 22:13, Brian E Carpenter = wrote: >=20 > However, we would need to get used to things like Universit=C3=83=C2=A4t= Bremen. Why? Since everything is UTF-8, there won=E2=80=99t be this kind of Mojibake = any more=E2=80=A6 (Yeah, I know, language tags, RTL, =E2=80=A6) Gr=C3=BC=C3=9Fe, Carsten (Of course, I *am* used to that. =46rom Websites done by the, er, less = competent or not updated since 1999. The people doing the tools for = IETF are way better than that.) From nobody Fri Apr 3 14:03:30 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8183A0AF6 for ; Fri, 3 Apr 2020 14:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFjFai0ea2N2 for ; Fri, 3 Apr 2020 14:03:27 -0700 (PDT) Received: from egyptian.birch.relay.mailchannels.net (egyptian.birch.relay.mailchannels.net [23.83.209.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11323A0AF4 for ; Fri, 3 Apr 2020 14:03:26 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C534D20597; Fri, 3 Apr 2020 21:03:25 +0000 (UTC) Received: from pdx1-sub0-mail-a9.g.dreamhost.com (100-96-2-17.trex.outbound.svc.cluster.local [100.96.2.17]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id CA2A621083; Fri, 3 Apr 2020 21:03:24 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a9.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Fri, 03 Apr 2020 21:03:25 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Battle-Wide-Eyed: 703b4c7649c7c98a_1585947805570_4034834215 X-MC-Loop-Signature: 1585947805570:3004659047 X-MC-Ingress-Time: 1585947805570 Received: from pdx1-sub0-mail-a9.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTP id 16F067F0CB; Fri, 3 Apr 2020 14:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=SIpstJeh+cYrIe0ZQxdPms0YJAo=; b=ZVhQ7kTZuZc 7iCITVMvynZKYO8YvaBh6xv/EyiruLmWMQ6qnqmHWxjVPpvQjs/i+QDYKVoJ/msj Jzws7QllWZgOxyVn7SddPawhZlPF+ae68VipHcPMPmjWS/jEwI1HNbntEEUnfrO5 6Ywn8oafNU4njwOTMPeWlKMrr9jaAojc= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTPSA id A632C7F0CA; Fri, 3 Apr 2020 14:03:19 -0700 (PDT) Date: Fri, 3 Apr 2020 16:03:17 -0500 X-DH-BACKEND: pdx1-sub0-mail-a9 From: Nico Williams To: Carsten Bormann Cc: Henrik Levkowetz , xml2rfc@ietf.org Message-ID: <20200403210315.GC18021@localhost> References: <56cdccd6-12e8-daec-8e4f-f843c4449310@levkowetz.com> <8dcb3bf7-cd90-67ce-4336-8a5fcf6d42b3@levkowetz.com> <20200403195620.GB18021@localhost> <307195D0-2DF5-4CBD-B8C4-C53348B80CB1@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <307195D0-2DF5-4CBD-B8C4-C53348B80CB1@tzi.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrtdeigdduhedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtugfgjggfsehtkeertddtreejnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 21:03:29 -0000 On Fri, Apr 03, 2020 at 10:12:24PM +0200, Carsten Bormann wrote: > On 2020-04-03, at 21:56, Nico Williams wrote: > > By which you mean "it's not universally used". >=20 > I really meant =E2=80=9Cit=E2=80=99s universally not used=E2=80=9D. :) > > Perform codeset conversions only as needed for interop, but default t= o > > UTF-8. >=20 > I would be even more radical here. Well, I mean, if people have archived documents in not-Unicode that they need converted to Unicode as needed -- that's OK. And clearly UTF-16 -horrible as it is- has to be used in some contexts. (But let us hope it dies eventually.) > > Another thing that could be done is require no alternate format > > submission when submitting XML: just apply xml2rfc on the server side= . >=20 > I think we are slowly getting to the place where this may be a valid > option for most documents that go to RFC. But it remains important to > be able to type up an I-D in Wordperfect, and be able to submit it (as > long as it is UTF-8, which it may be by way of being ASCII), so I=E2=80= =99m > not sure we can go the full way here. Note that I wrote "no alernate format .. when submitting XML" -- that does not exclude alternate formats when... not submitting XML! If you have XML, that's all that should be used, and might as well have that be all that is submitted too. Nico --=20 From nobody Sun Apr 5 13:09:15 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFE33A0AF6 for ; Sun, 5 Apr 2020 13:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXuH4V2BRyaO for ; Sun, 5 Apr 2020 13:09:12 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D7A3A0AF4 for ; Sun, 5 Apr 2020 13:09:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 883F062136 for ; Sun, 5 Apr 2020 16:09:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L2NwNjUpB-mS for ; Sun, 5 Apr 2020 16:09:06 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 0723062123 for ; Sun, 5 Apr 2020 16:09:06 -0400 (EDT) To: "xml2rfc@ietf.org" From: Robert Moskowitz Message-ID: <391cbf52-e067-3bcf-f8f5-c19698085830@htt-consult.com> Date: Sun, 5 Apr 2020 16:08:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [xml2rfc] Problem with Swedish characters in Region X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 20:09:14 -0000 Andrei Gurtov sent me this xml block for his address:         Linköping University    
              IDA         Linköping         Östergötland         58183         Sweden             gurtov@acm.org    
    I got the error: draft-moskowitz-drip-secure-nrid-c2-00.xml(59): Warning: Postal address part filled in, but not used: : Östergötland The address block in the draft is:    Andrei Gurtov    Linköping University    IDA    SE-58183 Linköping    Sweden    Email: gurtov@acm.org =============== How do I 'fix' this?  It seems it is ok in organization and city, but not region? Henrik, this strikes kind of close to home???? From nobody Sun Apr 5 14:36:16 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F813A0E3D for ; Sun, 5 Apr 2020 14:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLwPQUPVjH80 for ; Sun, 5 Apr 2020 14:36:11 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14CFC3A0E39 for ; Sun, 5 Apr 2020 14:36:10 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48wRn4008jzyZ4; Sun, 5 Apr 2020 23:36:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <391cbf52-e067-3bcf-f8f5-c19698085830@htt-consult.com> Date: Sun, 5 Apr 2020 23:36:07 +0200 Cc: "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 607815367.393104-27960ed2c735c838e93730918d049416 Content-Transfer-Encoding: quoted-printable Message-Id: <54666B77-D0DD-4870-B337-FE6D2500328A@tzi.org> References: <391cbf52-e067-3bcf-f8f5-c19698085830@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [xml2rfc] Problem with Swedish characters in Region X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 21:36:16 -0000 On 2020-04-05, at 22:08, Robert Moskowitz wrote: >=20 > draft-moskowitz-drip-secure-nrid-c2-00.xml(59): Warning: Postal = address part filled in, but not used: : =C3=96sterg=C3=B6tland Hmm, draft-levkowetz-xml2rfc-v3-implementation-notes-10.txt points to http://microformats.org/wiki/hcard and says that region is mapped to = country-area there. But hcard has a region and not a country-area. So = I=E2=80=99m not sure what the (current beta) spec says. The implementation stuffs the input into a library called i18naddress = (the I-D talks about something with a similar name but doesn=E2=80=99t = say what that actually might be); it seems to be the prerogative of the = library whether a state/province/canton/=E2=80=A6 is used in the country = being used in the address or not. That library seems to know that = providing the federal state in an address would be rather unusual in the = country of Germany (*), so maybe it thinks the same about Sweden. Gr=C3=BC=C3=9Fe, Carsten (*) 5 million stupid online shops that force me to enter that = information notwithstanding From nobody Sun Apr 5 14:41:42 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D526D3A0E62 for ; Sun, 5 Apr 2020 14:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUmdqtbHoZUW for ; Sun, 5 Apr 2020 14:41:37 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FFF3A0E63 for ; Sun, 5 Apr 2020 14:41:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3401662136; Sun, 5 Apr 2020 17:41:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yUXlYTEWkJUg; Sun, 5 Apr 2020 17:41:32 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id A28F562123; Sun, 5 Apr 2020 17:41:32 -0400 (EDT) To: Carsten Bormann Cc: "xml2rfc@ietf.org" References: <391cbf52-e067-3bcf-f8f5-c19698085830@htt-consult.com> <54666B77-D0DD-4870-B337-FE6D2500328A@tzi.org> From: Robert Moskowitz Message-ID: Date: Sun, 5 Apr 2020 17:41:25 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <54666B77-D0DD-4870-B337-FE6D2500328A@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Problem with Swedish characters in Region X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 21:41:40 -0000 On 4/5/20 5:36 PM, Carsten Bormann wrote: > On 2020-04-05, at 22:08, Robert Moskowitz wrote: >> draft-moskowitz-drip-secure-nrid-c2-00.xml(59): Warning: Postal address part filled in, but not used: : Östergötland > Hmm, draft-levkowetz-xml2rfc-v3-implementation-notes-10.txt points to > http://microformats.org/wiki/hcard and says that region is mapped to country-area there. Is there a tag? > But hcard has a region and not a country-area. So I’m not sure what the (current beta) spec says. > > The implementation stuffs the input into a library called i18naddress (the I-D talks about something with a similar name but doesn’t say what that actually might be); it seems to be the prerogative of the library whether a state/province/canton/… is used in the country being used in the address or not. That library seems to know that providing the federal state in an address would be rather unusual in the country of Germany (*), so maybe it thinks the same about Sweden. > > Grüße, Carsten > > (*) 5 million stupid online shops that force me to enter that information notwithstanding > From nobody Sun Apr 5 18:08:18 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B5F3A0A74 for ; Sun, 5 Apr 2020 18:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr8IQ20b8pZu for ; Sun, 5 Apr 2020 18:07:47 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320121.outbound.protection.outlook.com [40.107.132.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3E53A0A73 for ; Sun, 5 Apr 2020 18:07:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OiTOghm9EZ6gAgJzrrG3vNCZrM1z5iyMrvzwkHKrHhZoo13FzJAzsEqywZvdP155D4zOsqSMpHgnAfZtfQT00O5h6Jewbbqf2wjOyDS7HPbU35rmNP7mnaZo+Mx94l85QiBb9J5++B9M8qNqts7K82/ZbZOH9hZDcS0gIzm7qV3n/i2X3Xf8UJ2nIPnQ71hyDWVWgKVdAAmqsf9InMwOKjPFNUP1j9Nnuqo4veH7E6gM1CJnPA8c+pzna6Zh1DDTg9PexITD/UvzXP4+3JW38JzPV3NlZbh9G76ICaYchkUhKfenXjxBXMBjDgXcFqlwfQ5TvjsbqjV3ERkSSLhdGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pe2VACugm+BfmjMdmIqofwr/x64enTPA8xuNgbVq7jE=; b=X1F3e/vg4gmMGUKbsNCLpqOYNx9okpbH7myzFtO9rAaYUOoUMfYW+QfSrMEHdUvCWZY+b4mqzwb098CxXf34ieTJT+i3u65yJEqPkHpxFETCrPQuqbD2wvLCaFMNcJ+CDMjQF0Er+RaoOQF8XSGxVwuFEntVUK+JXtgHMTj7KHgAtUpWlGHFwZhKXdbYyI+259buYzuIreif5bPlCURpwnZhGZ+GbXRnzUmY8ON5YgJWIjQnA1g/wFawa+Q2TYIdlZ69mVCcHPK9pBUssO2/MC/g7UnOxqzp6IviM6oRSdHy6FKG+1Qt4tYyyoFm3iWCigZEY7zKowRJ/OJUHM8iBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pe2VACugm+BfmjMdmIqofwr/x64enTPA8xuNgbVq7jE=; b=Pojya+zfz419Osc9BGKuaqJM75ESrKMbZF3ksHfB2cEcXCtqweA+54qJVfkgM/MoWEAesf06JhcCAvBAfj8yKyApHQmLePUaKgbkp2P7VIEOUDFbJkMnTbuq5ioTzZ3zyjDn+aBJAGo4dlXLb2nzR1nbAvN2bcYwCwkq0Dx0yis= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from TY2PR01MB2780.jpnprd01.prod.outlook.com (20.177.98.11) by TY2PR01MB3163.jpnprd01.prod.outlook.com (20.177.100.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Mon, 6 Apr 2020 01:07:39 +0000 Received: from TY2PR01MB2780.jpnprd01.prod.outlook.com ([fe80::554:c050:5760:350]) by TY2PR01MB2780.jpnprd01.prod.outlook.com ([fe80::554:c050:5760:350%5]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 01:07:39 +0000 To: Carsten Bormann , Henrik Levkowetz Cc: xml2rfc@ietf.org References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> Date: Mon, 6 Apr 2020 10:07:36 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 In-Reply-To: <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYCPR01CA0083.jpnprd01.prod.outlook.com (2603:1096:405:3::23) To TY2PR01MB2780.jpnprd01.prod.outlook.com (2603:1096:404:72::11) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.10] (220.108.163.24) by TYCPR01CA0083.jpnprd01.prod.outlook.com (2603:1096:405:3::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16 via Frontend Transport; Mon, 6 Apr 2020 01:07:38 +0000 X-Originating-IP: [220.108.163.24] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d4749236-3772-40a3-48d6-08d7d9c6e688 X-MS-TrafficTypeDiagnostic: TY2PR01MB3163: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:389; X-Forefront-PRVS: 0365C0E14B X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TY2PR01MB2780.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(346002)(136003)(396003)(366004)(39840400004)(376002)(8676002)(81156014)(16576012)(16526019)(31696002)(186003)(2906002)(110136005)(5660300002)(81166006)(508600001)(786003)(26005)(86362001)(31686004)(66946007)(66574012)(2616005)(4326008)(52116002)(316002)(956004)(36916002)(66556008)(6486002)(66476007)(8936002)(53546011)(40753002)(133343001); DIR:OUT; SFP:1102; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LJMRoSpJXSO+YGf/rR9Xs8zECkhvUZKNz/9wycA8UlKBzTPz9QE+MqujXaoVpglOoCxR+OWF7F+GIkGpUEllGUrVqWUDG+Nk6CFlvg95nqtiEzXF4gQ35eyfr+CW0HIg93NNwuHjvTlN5KwdYwDzSXPXlhNG0te3NuoecobifsMy6VIZssSc5cCjhHKil2AWxpOkvzWBVN+ZszVW+B2Gnytj/FG+5FlsL6K/DNLR8l1vyU5PUifIkaidD+uGpgFsCtBGSwFacTvZtlHyopScQTQm/kaMlxJIkoli2lRsPJf3jl+w59W5ASuHGz53naWCWl43RAAcqaBoJUo4P5sLpb47eQ53W22Sxkho6id/WbakOkxCyPAHeN4BGmbdRpZs4XmZBwR8pBlqHfLdxy4n/caJ7uJOhRR/R5RhlGgNmEQs4l2WWmKZTtKE9Rgm6QGTe8xojKrjLbmXXSg0l3vdoOF7ChVxfvvMIIeED7Z7EzrgZBTo5TQ04duv9E3RNaRkcxsnULMyGx330B1ANOOtdA== X-MS-Exchange-AntiSpam-MessageData: QE9xcECMYlWpnWqX+jYLagKcXTq5rJica6wGUwDsGdMwaP747CV67PWth2bZ8B2rDBRgaUiCIdHZqUj/AVJZ36WDp0JQix5m+/9pwqiEGvKqpsITnXJc/IESSUrkN+YcEsxjc1nXu8INTOmMtkYajg== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: d4749236-3772-40a3-48d6-08d7d9c6e688 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 01:07:39.6214 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: t9i3EJ+jzHYUwCWNZrOv+dovWiEGWUv421UfYD+meBql1DqUZTkajpVE2UDXynjUo8ghvFP/365MDgmKs4516A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB3163 Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 01:08:09 -0000 On 03/04/2020 14:06, Carsten Bormann wrote: >>> Why? >>> Browsers do get these things wrong — how would they even know? >> >> Below you say that it's extremely easy to sniff whether a file is UTF-8 or >> not, and here you ask how would the browser even know. I see a contradiction. >> >> The upload comes with a mime type and charset -- why should the submission >> tool _not_ use those? > > Because they are mostly wrong. > > This thread started with an observation that the charset provided by the browser was wrong. > Previously, we have had discussions about markdown files being submitted as application/octet-stream. > > The way browsers are set up, they are trying to use OS hints for assigning a media type and, possibly, a charset. However, these OS hints are not designed in a way that they can be relied upon. Explaining things a bit differently, browsers have to send charset information based only on the information that they send it to *some* Web site. They also have to deal with historical issues such as "This browser used to send this charset information in this situation; the Web site is written with that assumption, so if the browser suddenly changes this (even if the new information is more often correct) the Web site may look bad, and the browser will be blamed." We have a big advantage on the server side: We know that what we get should be UTF-8 (or ASCII which is UTF-8 anyway) text. The browser doesn't have this knowledge about our application. That's why it makes sense to deal with this (to some extent) on the server side, even if in an ideal world, we wouldn't have to. Regards, Martin. From nobody Sun Apr 5 19:02:32 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BFF3A0B77 for ; Sun, 5 Apr 2020 19:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oesbDxlNvJXG for ; Sun, 5 Apr 2020 19:01:48 -0700 (PDT) Received: from antelope.elm.relay.mailchannels.net (antelope.elm.relay.mailchannels.net [23.83.212.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF11F3A0B7B for ; Sun, 5 Apr 2020 19:01:47 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id BD7D2340F0B; Mon, 6 Apr 2020 02:01:46 +0000 (UTC) Received: from pdx1-sub0-mail-a32.g.dreamhost.com (100-96-21-20.trex.outbound.svc.cluster.local [100.96.21.20]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 2FF883407C3; Mon, 6 Apr 2020 02:01:46 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a32.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Mon, 06 Apr 2020 02:01:46 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Turn-Trouble: 6bb0e4312ab25437_1586138506475_1187263987 X-MC-Loop-Signature: 1586138506474:342409299 X-MC-Ingress-Time: 1586138506474 Received: from pdx1-sub0-mail-a32.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a32.g.dreamhost.com (Postfix) with ESMTP id E7E8F7FF18; Sun, 5 Apr 2020 19:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=hdnAscK0mh5cFZAn2S340o9T4Iw=; b=fcjY0NpvS+r xLAOCaFf+chCH/FB0yCugmhRBsRUYXHfjzXT7IMRMwX1GYT7gFZqzpocqE+SFduk 1noRhicMR5CZpuHZTVy06l8kjAIhuRU/l0SqJivSC2BBfmGsPl/zlEukGX7uV/jj w7sr4TnVNG61eD/uYJ/64Xspoihmvaaw= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 054247FF1F; Sun, 5 Apr 2020 19:01:41 -0700 (PDT) Date: Sun, 5 Apr 2020 21:01:39 -0500 X-DH-BACKEND: pdx1-sub0-mail-a32 From: Nico Williams To: Martin =?iso-8859-1?Q?J=2E_D=FCrst?= Cc: Carsten Bormann , Henrik Levkowetz , xml2rfc@ietf.org Message-ID: <20200406020058.GH18021@localhost> References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedruddvgdehgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderudenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 02:01:52 -0000 On Mon, Apr 06, 2020 at 10:07:36AM +0900, Martin J. D=FCrst wrote: > Explaining things a bit differently, browsers have to send charset > information based only on the information that they send it to *some* > Web site. They also have to deal with historical issues such as "This > browser used to send this charset information in this situation; the > Web site is written with that assumption, so if the browser suddenly > changes this (even if the new information is more often correct) the > Web site may look bad, and the browser will be blamed." >=20 > We have a big advantage on the server side: We know that what we get > should be UTF-8 (or ASCII which is UTF-8 anyway) text. The browser > doesn't have this knowledge about our application. That's why it makes > sense to deal with this (to some extent) on the server side, even if > in an ideal world, we wouldn't have to. +1. For .xml files we should require UTF-8. Ditto for .txt files, but if .xml is submitted, then the .txt should be generated by the server. Nico --=20 From nobody Sun Apr 5 21:26:28 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A593A0794 for ; Sun, 5 Apr 2020 21:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rftTWdAifMYt for ; Sun, 5 Apr 2020 21:26:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA74C3A0791 for ; Sun, 5 Apr 2020 21:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586147167; bh=/rjNcPbecjdUesw1RKXAnw7ln1Su4gLg1vn2TLPVLf4=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=LF7QfpK6UNwUDL0qZIYnRrz6oUvciBdQ8URuZJd3aIrLVxRthkabLgGTafmCoWOzb RsDSTSj6oTqHCCm34CigobAzlR3uyK1+rslAVF+dnKLNjWodOrCDBpo8IkCfP1uHmk t0TVpx+IhzLplZdCrfvJor8pSXYLfdQISkFjW87o= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.53.180]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MJE27-1jaUXF3pdb-00KcnD; Mon, 06 Apr 2020 06:26:06 +0200 To: Nico Williams , =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Cc: xml2rfc@ietf.org References: <858E7B62-9768-4551-9BE7-C282AC4AFD06@orandom.net> <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> <20200406020058.GH18021@localhost> From: Julian Reschke Message-ID: Date: Mon, 6 Apr 2020 06:26:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200406020058.GH18021@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:HQKna+UIn3x26Oq52AWid6nJan/7fntxFg6QuK4npb7qYW9Lxn8 Scy9rJRNapTHjBXFLritir8P4Uv1iMbvKrdVxeWM3i9vrxf5HxNcBX+mxwGhdfp4CNAKNSw YA65JsIx5SB/y+D1X2XGUoU3T6TO+WA8azQrAgxe9FA/PIoZQEvP2PkwhwwnuCSqnc/0LMm zRmsd8820xGSpEofymnYg== X-UI-Out-Filterresults: notjunk:1;V03:K0:iHdHrptmtLs=:umxnVPojadADuiaAkydjBz tlMYkTp8CSvLX4oB3c9MrKX5UI8smHYY3Zjcf6pYfqGCIon4gb/hn40veuVXT1MVmyXnpG+sy vz81xDdElnOWadVhevNUy377iZ8wxFpcDMiP+sQcy2usg3f/v9YislLb6rb54iPwp2zWaXlw/ XxIwomFWQMop8dGVMZD4oKnt++AKir0riEkEcaOMVYqo/dTh55rO+XXkGLdwL26dAUkx6ouwY tIr9+Le/lzgueIc+QpfSKnpUAOmM+9yJxKdB3ffBhone35yTvbEKPD5mSCdl4+sPWSKi+tuBZ w9HSQ+k6GYa/tVBp+jQwmGyGDLr1nYXuqYzBuUjQQ6RiBYhvpRUKx0eCSUZugL4qsfOmanQYM vQTiIi0SPf40DuGpkWdgZ7PKPjtWnc4LYwupfeKArrkQWyheigkkBe9/tH1BJX7Vdtr7+KXYx 1VzvTVeRCf5czQw5jQsbMA0RLk+6wLgT/qO8bgREfyGevoIwdRB/aAIzQUk6WYZAgBdZWB4Ec /CCzuJEu3BHTQbLgV+TndCzofKIfwOX44Q7ArPjxf6K47IRrWfuUrQ8H9rVAbQ1TpVIRHvYsz bJyxiAKhliFRIk0tCi1bnl8FkQ6OkEX7y3MJP0bFzS5fCCfAuw3B/0SNV6klONEwJi744HkHJ kwLuYuEwIa9RDblnWcopsglqBjmDVHbaRGikxP8uTTM9LxjDkddja0+56BHK1rjAQMEKTEqfP Thh2TobMje9ME8ESyYm0zAsWkaNJdsVbnpcmY4hwed+0fhc4Q1ANmE8fUr9Cd1AAryDjKIX53 Clbm2NGSd5Za5F24RU420XwNInzd3+rDB+5zU2PvaKfkfJqIpKMgmW8Bsu1qL73H0ew8ojg8i bT15+VlZzkb0s4XvUmkstkL0HzVfIQobY2ID4WZ3XCzSmy+lXXfiyzlVq0lbOsVicKGcCgb3s d3x63x7XEY0O4R8KpxeSgSz+FP2ZGQiCRwaoualqWO8+Myck6Mg46GOMDNNTdSbhrGcDjD0I4 mRqU9M5gvR2xe+5o2qjCwVRCDIYYsSpqJE1zZrDQdVe8bAwh0g5vGJPXgSRRouW6o2TkFwojB fnx46MQVJc9OL1hfbPlhNdkJmvOCI8KNyEMGepJFvKz6AA6ZzRyXMpVVo7h1sCG9P1dBLuF3b go5UJcWt062DUEkM0YvI1rZC1RN+gi+rQAT84cywx6ibSMr23kY1sYthFn5MdTVZc3S1mHO/G b2S1ZqLQI6mYdiuTv Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 04:26:27 -0000 On 06.04.2020 04:01, Nico Williams wrote: > On Mon, Apr 06, 2020 at 10:07:36AM +0900, Martin J. D=C3=BCrst wrote: >> Explaining things a bit differently, browsers have to send charset >> information based only on the information that they send it to *some* >> Web site. They also have to deal with historical issues such as "This >> browser used to send this charset information in this situation; the >> Web site is written with that assumption, so if the browser suddenly >> changes this (even if the new information is more often correct) the >> Web site may look bad, and the browser will be blamed." >> >> We have a big advantage on the server side: We know that what we get >> should be UTF-8 (or ASCII which is UTF-8 anyway) text. The browser >> doesn't have this knowledge about our application. That's why it makes >> sense to deal with this (to some extent) on the server side, even if >> in an ideal world, we wouldn't have to. > > +1. Maybe. > For .xml files we should require UTF-8. Ditto for .txt files, but if No. Why? What problem are you solving here? > ..xml is submitted, then the .txt should be generated by the server. Optionally. Right now there are command line options that affect the output, and it would be necessary to support them in the UI. (Or better, get a way to get rid of them). Best regards, Julian From nobody Sun Apr 5 22:21:01 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1CF3A08F3 for ; Sun, 5 Apr 2020 22:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIXqtrOLng4G for ; Sun, 5 Apr 2020 22:12:11 -0700 (PDT) Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD023A08BE for ; Sun, 5 Apr 2020 22:07:41 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6DFFE34116F; Mon, 6 Apr 2020 05:07:19 +0000 (UTC) Received: from pdx1-sub0-mail-a32.g.dreamhost.com (100-96-2-17.trex.outbound.svc.cluster.local [100.96.2.17]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id F06C4340A6E; Mon, 6 Apr 2020 05:07:18 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a32.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Mon, 06 Apr 2020 05:07:19 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Spill-Illegal: 0f61e44a0c74ff8d_1586149639244_2475883779 X-MC-Loop-Signature: 1586149639244:1604227071 X-MC-Ingress-Time: 1586149639243 Received: from pdx1-sub0-mail-a32.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a32.g.dreamhost.com (Postfix) with ESMTP id B1F167FF4E; Sun, 5 Apr 2020 22:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=Y2eAbEcpZZLnnUvku8wl+1jBNGM=; b=MUX8+54Yeye tSXciiM1wwyMShXvRuSid/vzrQUexlynH7TEh2pNk1wujA6KDrzjUm84VVi+86Bc bfNoNSfd3RPnc684U4T6BfKsw9eJy0nEr+hVwVK7QLDVWbBYhdesUESc84hDWhRf lrdW4yOtEHVdM3QGoiA7xGTO7fAzUrd8= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 278017FF50; Sun, 5 Apr 2020 22:07:14 -0700 (PDT) Date: Mon, 6 Apr 2020 00:07:12 -0500 X-DH-BACKEND: pdx1-sub0-mail-a32 From: Nico Williams To: Julian Reschke Cc: Martin =?iso-8859-1?Q?J=2E_D=FCrst?= , xml2rfc@ietf.org Message-ID: <20200406050711.GI18021@localhost> References: <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> <20200406020058.GH18021@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedruddvgdelfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderudenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 05:13:52 -0000 X-List-Received-Date: Mon, 06 Apr 2020 05:13:52 -0000 X-List-Received-Date: Mon, 06 Apr 2020 05:13:52 -0000 On Mon, Apr 06, 2020 at 06:26:04AM +0200, Julian Reschke wrote: > On 06.04.2020 04:01, Nico Williams wrote: > > On Mon, Apr 06, 2020 at 10:07:36AM +0900, Martin J. D=FCrst wrote: > > > Explaining things a bit differently, browsers have to send charset > > > information based only on the information that they send it to *som= e* > > > Web site. They also have to deal with historical issues such as "Th= is > > > browser used to send this charset information in this situation; th= e > > > Web site is written with that assumption, so if the browser suddenl= y > > > changes this (even if the new information is more often correct) th= e > > > Web site may look bad, and the browser will be blamed." > > >=20 > > > We have a big advantage on the server side: We know that what we ge= t > > > should be UTF-8 (or ASCII which is UTF-8 anyway) text. The browser > > > doesn't have this knowledge about our application. That's why it ma= kes > > > sense to deal with this (to some extent) on the server side, even i= f > > > in an ideal world, we wouldn't have to. > >=20 > > +1. >=20 > Maybe. >=20 > > For .xml files we should require UTF-8. Ditto for .txt files, but if >=20 > No. Why? What problem are you solving here? Oh sure, the XML can tell us its codeset. If it simplifies things to require UTF-8, I'd rather do that. Certainly I don't want the codeset tasted. Who needs to edit I-D source XML in not-UTF-8? Can --exp or a new option transcode to UTF-8 for submission? > > ..xml is submitted, then the .txt should be generated by the server. >=20 > Optionally. Right now there are command line options that affect the > output, and it would be necessary to support them in the UI. (Or better= , > get a way to get rid of them). * Don't use --raw for submission. Unpaginated text is great for reviewing changes while editing so please don't remove it, but it shouldn't be accepted for submission). * -u should be required for submission if you're going to submit .txt. * Alternate DTDs... is there a use for that? anyways, the xml tells us which DTD, so the server can still generate the right .txt. * Any options I missed? Nico --=20 From nobody Mon Apr 6 01:14:09 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2D53A0AE8 for ; Mon, 6 Apr 2020 01:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCsg_whCAjRe for ; Mon, 6 Apr 2020 01:14:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32733A0AD0 for ; Mon, 6 Apr 2020 01:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586160823; bh=zQj094OBnhoEWYRYCDHxIz6WrRDjmelHdfPzceLMbfU=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=OQ//6vuALOb0dRFN3VbLDGBYsO05whI6RAw9V+P60ZUcebKsMZEMbtCtcgDb2hPNc ZNUARBbS9CpfF3wQlvAEQ6ggff2G0Crukw1CvvwtgIMcmc1at2C9/jYtZZjfTXmCrn HWv6dMcA/wUxTlxY1XEL4UhePjGHGp+Ca3qdS0BA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.53.180]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MfYPY-1ioG3b0TH6-00g1Wk; Mon, 06 Apr 2020 10:13:43 +0200 To: Nico Williams Cc: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , xml2rfc@ietf.org References: <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> <20200406020058.GH18021@localhost> <20200406050711.GI18021@localhost> From: Julian Reschke Message-ID: <583ce0c5-90b6-7e63-4445-06049d770c31@gmx.de> Date: Mon, 6 Apr 2020 10:13:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200406050711.GI18021@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Gqqvwo7wn+wMWBmcLXMbkxcUC4qlgoBUvudy74CcKi5c7vqhwXz LKbYanPXZv2PuLiROBmsQqIc7cdkotpidCnoo3SpBlg3Ss3lIsGNNr28P3jHoSOE4dg0AoK y7vG5HpIlokkjUr3SdE1Yy5pvJ6YLlEBMhEZRAv64/ycL0g1Hjct/xgWdn1J1yPcSFFil/o BISp+41jbpZF4oMdVVCag== X-UI-Out-Filterresults: notjunk:1;V03:K0:0cS03w4kkC0=:/9jKFqUjrYOPWjMccEXrfl HBblzc3eoe/zvr24x4ZdsNwK/ddX3pG4c55dGKCCICahcLLHM5NVPrqq9RYhT35xtZTqI6kOC aI+yA5dQviA0JJtT2YvH2mHFQE0uoftBQLMDAWdXAk1DofphhhpiYlviF0l9GJllGTg1MVC7x r50mQjzPTU4QC+ERNW0bJvjoQaj476hTUQea5y2JjQWtt015U87fhengPFVFEArdonE0SBFV4 5UZPLyxzbiqGhLdWbP7bE9/pr1V8Q24FrcsejuYPa+LtMTFBj2OKQgfGSX9Fz4XtB1E6VP4iL qL/BQIAxHdv7y9HOGUiq7BnDkWI2uW72JDh9oMKg/xYZdl9+/F3kORK18HirlZGZcbDpBBlOy JzIRiQO/BZeAQWhMF2YC6US6Dn3PZs+aHKZNa2ve8bKsdyBfaqLFA3Q4C9ekwJ2hAX/aSyiB/ /QZPdt9T8yT/ofsmO2Vy2gSAN95PIJ8kmjsRt+4apowces9fVAKjhHzUn3l7EtoirJ1VmVP8V PI4Zi40Hy39l1ytbCxPEzuo/v/UD2KWQZ6l2l66yK5/ReQtoAGAMdCoMEQHpkVveb0UEhPtg9 6BWqDd9RzanRFLEchTJDzxw4PD6OtY/si2HuVM5Kr/BtRSZo7FPDcNp2ugg2dzXClkCCOzAIx zq+PhZQe/Okt+tcge4wd+9SjH/stpB87a5wJzndiF13swYCZvjEkhwBAjGwBYLkWdt7oZx9Ix zYptUa9vCF1PJa6dmP1zcFckOfxUoT3/qLYgNizhexabZo7eEwseXw5+FGi0EHeCIvJWk9LZS NFI/7FzMwQfFgKMQry1UxJ8DV2EaYtDPrUagrty/VbVc0zbxN2YPB/r3DwS5f+0N/wTVKEHVl Qooj2UDQ3HbHLrDVuchR5IbOGTcsKjMb1JrU7j54j0arapnmqw8jIwQpEfTV4VNXzO3o4vvHu eTPYF5rURQ0ghne0R2WXf5XrOZTpxGFJAyNxtUoBq62lIBtmYPhxRcafKMjpMG79FYNCIRHZX mecjMkKxOS4TbPZbCuv4pdyRjHr5DiC5eTzIAJEGTnTGbH3jB0lO+jmRHNwMOpdLtUfzKGQnt xiBB3G/pcUASTVjQwfls0D6PNBH9364Y8fB/+OhwBV25ewpYBxEzg3/zf0yT/Tc+0QTlAu8dy j3Vvuw2gJd23xlxR5eJB6Uvz+IEAMcxJ5dEFErAZYcjt5ezhFChc9UAEFE3jrXsMG/XeFDMt+ +9mgLB5dcqnkeGsXt Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 08:14:06 -0000 On 06.04.2020 07:07, Nico Williams wrote: > ... >> Optionally. Right now there are command line options that affect the >> output, and it would be necessary to support them in the UI. (Or better= , >> get a way to get rid of them). > > * Don't use --raw for submission. Unpaginated text is great for > reviewing changes while editing so please don't remove it, but it > shouldn't be accepted for submission). > > * -u should be required for submission if you're going to submit .txt. > > * Alternate DTDs... is there a use for that? anyways, the xml tells u= s > which DTD, so the server can still generate the right .txt. > > * Any options I missed? > > Nico Date formats... Best regards, Julian From nobody Mon Apr 6 01:17:57 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6814C3A0B0D for ; Mon, 6 Apr 2020 01:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NMCMZCUIBu5 for ; Mon, 6 Apr 2020 01:17:51 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20CC53A0B08 for ; Mon, 6 Apr 2020 01:17:50 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48wk1S482RzyhB; Mon, 6 Apr 2020 10:17:48 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <583ce0c5-90b6-7e63-4445-06049d770c31@gmx.de> Date: Mon, 6 Apr 2020 10:17:48 +0200 Cc: Nico Williams , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 607853867.997882-7e086d94b770cdc9039a517b3c559fdd Content-Transfer-Encoding: quoted-printable Message-Id: <9FDECD41-0A6A-4238-9E58-A9003FFAC06D@tzi.org> References: <645E8F13-0FE4-47F7-8CB2-ECDF23281BF7@orandom.net> <34FE11F2-14F2-4B84-BE24-296A27BA9151@tzi.org> <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> <20200406020058.GH18021@localhost> <20200406050711.GI18021@localhost> <583ce0c5-90b6-7e63-4445-06049d770c31@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 08:17:55 -0000 On 2020-04-06, at 10:13, Julian Reschke wrote: >=20 > Date formats=E2=80=A6 Let=E2=80=99s introduce a few PIs for controlling that! Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 6 03:12:46 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262243A0D6B for ; Mon, 6 Apr 2020 03:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11_MLZctnxs2 for ; Mon, 6 Apr 2020 03:12:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1CD3A0D68 for ; Mon, 6 Apr 2020 03:12:44 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:65511 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jLOjs-0008JM-1w; Mon, 06 Apr 2020 03:12:43 -0700 To: Robert Moskowitz , "xml2rfc@ietf.org" References: <391cbf52-e067-3bcf-f8f5-c19698085830@htt-consult.com> From: Henrik Levkowetz Message-ID: <41d6435c-70aa-0669-596c-8350390c1b19@levkowetz.com> Date: Mon, 6 Apr 2020 12:12:02 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <391cbf52-e067-3bcf-f8f5-c19698085830@htt-consult.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="twCXH40tTa4A6B5wtTGqOr6uhvLpbUrOA" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, rgm@htt-consult.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Problem with Swedish characters in Region X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 10:12:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --twCXH40tTa4A6B5wtTGqOr6uhvLpbUrOA Content-Type: multipart/mixed; boundary="UcmeLiI1kNlHOHQ1AEOwFcXuShx9PoLpf"; protected-headers="v1" From: Henrik Levkowetz To: Robert Moskowitz , "xml2rfc@ietf.org" Message-ID: <41d6435c-70aa-0669-596c-8350390c1b19@levkowetz.com> Subject: Re: [xml2rfc] Problem with Swedish characters in Region References: <391cbf52-e067-3bcf-f8f5-c19698085830@htt-consult.com> In-Reply-To: <391cbf52-e067-3bcf-f8f5-c19698085830@htt-consult.com> --UcmeLiI1kNlHOHQ1AEOwFcXuShx9PoLpf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bob, On 2020-04-05 22:08, Robert Moskowitz wrote: > Andrei Gurtov sent me this xml block for his address: >=20 > > Link=C3=B6ping University >
> > IDA > Link=C3=B6ping > =C3=96sterg=C3=B6tland > 58183 > Sweden > > gurtov@acm.org >
> >=20 > I got the error: >=20 > draft-moskowitz-drip-secure-nrid-c2-00.xml(59): Warning: Postal address= =20 > part filled in, but not used: : =C3=96sterg=C3=B6tland >=20 >=20 > The address block in the draft is: >=20 > Andrei Gurtov > Link=C3=B6ping University > IDA > SE-58183 Link=C3=B6ping > Sweden >=20 > Email: gurtov@acm.org >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > How do I 'fix' this? It seems it is ok in organization and city, but=20 > not region? >=20 > Henrik, this strikes kind of close to home???? And the postal address format information the tool has is right. In Sweden, postal addresses do not use regions, the information is quite superfluous and could even be confusing for some postal employees. Simply remove the region, I'd say. Best regards, Henrik --UcmeLiI1kNlHOHQ1AEOwFcXuShx9PoLpf-- --twCXH40tTa4A6B5wtTGqOr6uhvLpbUrOA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl6LAHIACgkQTptXS4+7 FxpMyhAAjrwiDWy0Oaa89ItVI5eInjICZyf0f9nfzHz0ZEVuSwFHu6ArJvGFcWKv U6UTGUbu/DaNXkMcna+hEyfOuDotVGcjY0bDKYXe8HDf7v0yUyUNeDcv6iIHiki7 K1LqPinrssD7i1aAPlmtA4NKfcIlyLIpVrLB939/lG88SwjgHCyfH0DiUgtahUHp 7vxaXr4y/9z6Yt9+VrgHF0morzf4hlWgdJqSV7vT4SQC2bKRF352Gcht/5tUiON0 +uT0F/YNOUFy4VxnnvSv+iSoq4OEVPR8mIcOJf6Yu1d/QP8Xgyh7NGj99Ud4p8Vp b4hYHbsl/3i8CCJ0fVPZrQNJ9WwgEbONXrn6JpHDCUnyjdQHY9a+W3mZ98NET0ax QKgsLbdgwYtcsW2d4Oez3eTKqJNMorR3QAeb/u2ucPCVZGVV1K3XwM6aWyfs+kQb HDxG02dNgM6wykz1Samdtg5MNKb7E5wwsg8ZCsP7T56K08Mwn/rB2uQnTlbrCsr0 kgl+pBYXHIwG6ec7VfPkON4VLTaR0gWnvjxlfbvBQyRXnCzDFCFiDent2fB2I0y3 gtj9Ufd4ML70l4AqgdKJ31VS6PyJOTSCayOfxpytuOC41urhLU0fByjzblJ1eNCY R6YHrjtG7/0rNiWOhpjlSIdU0iZzhLEoewDz1tD4O521lOvdh98= =+gI+ -----END PGP SIGNATURE----- --twCXH40tTa4A6B5wtTGqOr6uhvLpbUrOA-- From nobody Mon Apr 6 03:48:21 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC233A0E07 for ; Mon, 6 Apr 2020 03:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lYymxHddFXb for ; Mon, 6 Apr 2020 03:48:17 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5ACB3A0E06 for ; Mon, 6 Apr 2020 03:48:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 700AF6218E; Mon, 6 Apr 2020 06:48:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AGh3x3xiftBe; Mon, 6 Apr 2020 06:48:09 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 6C94162136; Mon, 6 Apr 2020 06:48:07 -0400 (EDT) To: Henrik Levkowetz , "xml2rfc@ietf.org" References: <391cbf52-e067-3bcf-f8f5-c19698085830@htt-consult.com> <41d6435c-70aa-0669-596c-8350390c1b19@levkowetz.com> From: Robert Moskowitz Message-ID: <6c7d8e71-e8ac-00b1-6522-4c431f4e61cf@htt-consult.com> Date: Mon, 6 Apr 2020 06:47:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <41d6435c-70aa-0669-596c-8350390c1b19@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Problem with Swedish characters in Region X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 10:48:19 -0000 On 4/6/20 6:12 AM, Henrik Levkowetz wrote: > Hi Bob, > > On 2020-04-05 22:08, Robert Moskowitz wrote: >> Andrei Gurtov sent me this xml block for his address: >> >> >> Linköping University >>
>> >> IDA >> Linköping >> Östergötland >> 58183 >> Sweden >> >> gurtov@acm.org >>
>> >> >> I got the error: >> >> draft-moskowitz-drip-secure-nrid-c2-00.xml(59): Warning: Postal address >> part filled in, but not used: : Östergötland >> >> >> The address block in the draft is: >> >> Andrei Gurtov >> Linköping University >> IDA >> SE-58183 Linköping >> Sweden >> >> Email: gurtov@acm.org >> >> =============== >> >> How do I 'fix' this? It seems it is ok in organization and city, but >> not region? >> >> Henrik, this strikes kind of close to home???? > And the postal address format information the tool has is right. In > Sweden, postal addresses do not use regions, the information is quite > superfluous and could even be confusing for some postal employees. > > Simply remove the region, I'd say. That is what Andrei just told me to do... > > > Best regards, > > Henrik > From nobody Mon Apr 6 08:00:53 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77803A0A2F for ; Mon, 6 Apr 2020 08:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJIVNE6DLeWE for ; Mon, 6 Apr 2020 08:00:31 -0700 (PDT) Received: from butterfly.birch.relay.mailchannels.net (butterfly.birch.relay.mailchannels.net [23.83.209.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C16E3A0993 for ; Mon, 6 Apr 2020 08:00:17 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 116AA9218C9; Mon, 6 Apr 2020 15:00:16 +0000 (UTC) Received: from pdx1-sub0-mail-a94.g.dreamhost.com (100-96-23-11.trex.outbound.svc.cluster.local [100.96.23.11]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id C090C921894; Mon, 6 Apr 2020 15:00:14 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a94.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Mon, 06 Apr 2020 15:00:16 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Cold-Tasty: 0178b9d17b33645a_1586185215167_2401155808 X-MC-Loop-Signature: 1586185215167:46260636 X-MC-Ingress-Time: 1586185215167 Received: from pdx1-sub0-mail-a94.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTP id 2F58DB19FE; Mon, 6 Apr 2020 08:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=BO4fkjXSJhTwcp +NvxMD5zjlP9g=; b=gWQrymaJMV76frGxmDL2mFVNwrSMtziJiUpuTo/chQIutH DwDvkzXZfyrfetCO2O+7Y69jybr9bzRirq7SLre5hzmrx21h8iHKkDS+RAlnXt2B 5rTRrpbMOOQlAph7cj0etpo2IqL9ye46WFnieGtI4mfPwnPHTTA2IGyVR80sA= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTPSA id 087F4B19F9; Mon, 6 Apr 2020 08:00:11 -0700 (PDT) Date: Mon, 6 Apr 2020 10:00:08 -0500 X-DH-BACKEND: pdx1-sub0-mail-a94 From: Nico Williams To: Julian Reschke Cc: Martin =?iso-8859-1?Q?J=2E_D=FCrst?= , xml2rfc@ietf.org Message-ID: <20200406150006.GJ18021@localhost> References: <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> <20200406020058.GH18021@localhost> <20200406050711.GI18021@localhost> <583ce0c5-90b6-7e63-4445-06049d770c31@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <583ce0c5-90b6-7e63-4445-06049d770c31@gmx.de> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudefgdejiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 15:00:37 -0000 On Mon, Apr 06, 2020 at 10:13:42AM +0200, Julian Reschke wrote: > On 06.04.2020 07:07, Nico Williams wrote: > > * Any options I missed? > > Date formats... -D DATE, --date=DATE run as if the date is DATE (format: yyyy-mm-dd) That's an option to set a date. .xml should be submitted in "expanded" form, with all relevant options from the xml2rfc accounted for, and in UTF-8. Why require UTF-8? Simplicity, for one. We'll be producing UTF-8 anyways, so why require server-side codeset conversions? Nico -- From nobody Mon Apr 6 10:48:08 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3EF3A0D59 for ; Mon, 6 Apr 2020 10:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEqOSOCWc3k6 for ; Mon, 6 Apr 2020 10:47:52 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700068.outbound.protection.outlook.com [40.107.70.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CBFE3A0D50 for ; Mon, 6 Apr 2020 10:47:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CfNvFgRmp7sYpoZf+EmstEoB5xh6JvnQxMkzeB1MrBaQyYZRetrOtIby7f85O8FUsxsrhJ0AV4mTmm1XGKiZoM4z0ymBUK2ebLSsW7+VWoK8x2SFMzouLOuSw8bUH0b2bpMSZthVNHjNcvFOote7TUnl1zSZ9nECwqncPtbwN0oPWU4rD4z0Od9m/WhGFVw5Za0CWTqeCzKL3sChsvk4IzrqtlcA/Hi7B4+o2JI6fmlSFXITmjp3fFmSj4T7rJV0yXaLM9ZJ7vnJbVGLDkuoWeHnRE1aINZGfbxbC9g8Phmvr1j53VDxsOIzrSQWAHv7lWrxqmCxlBdRy9fKf/VlGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KNnuxAk988s29qLqIh3VzpAN+faUpzv+f80CkR6d9nE=; b=hnBeU6Sv6fNGrdBISNk//jZYCHVL6djYebUW22JuOanp/gr6BFfI/JgGYyv3G/78pJAqiIHt0ipDz37cO9Q/TrtlLWpU8BBLArDoKZK4N3hfBJfyQVVRPhsDfckfqhhMktP2Sth/1Vrh1qem4NpwvUuMYt+Gi/2V5CrWnYaKuCtkK6UY+yLxIK9IethJ9iEm521ZofXRbsU7npVrO/mb93PeooRXcKokRlR0oILjukYYwPE7H8uftYCDH3lUYgFzIcXnYJWshX1zHDDmuiP8ir37u8nsv72gHG87T5pjQSadCDMymLFiSDiUAI24Y4YgTqEKVbLXJneB7p/ruy8Tjg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KNnuxAk988s29qLqIh3VzpAN+faUpzv+f80CkR6d9nE=; b=LsGHWykOdV92m6/V/CP9AY/3VZG+2M20FO81f4bFgtP7pFt35r8754H8vSFr6GQuL9O2DBGix4psZuZ5gQ+JT1itw3o4nE4HL4caXczUzWwKtZ603Opy3LfVE9Kh2iKYVf6fjV7l/GNm4ZZXRYUaY15lHbPNlj1spwXToR+h/48= Received: from DM5PR04CA0071.namprd04.prod.outlook.com (2603:10b6:3:ef::33) by BYAPR12MB2965.namprd12.prod.outlook.com (2603:10b6:a03:ae::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Mon, 6 Apr 2020 17:47:50 +0000 Received: from SN1NAM02FT028.eop-nam02.prod.protection.outlook.com (2603:10b6:3:ef:cafe::a5) by DM5PR04CA0071.outlook.office365.com (2603:10b6:3:ef::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Mon, 6 Apr 2020 17:47:50 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT028.mail.protection.outlook.com (10.152.72.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Mon, 6 Apr 2020 17:47:49 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 036HllLD006180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 6 Apr 2020 13:47:48 -0400 To: xml2rfc@ietf.org References: <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> <20200406020058.GH18021@localhost> <20200406050711.GI18021@localhost> <583ce0c5-90b6-7e63-4445-06049d770c31@gmx.de> <20200406150006.GJ18021@localhost> From: Paul Kyzivat Message-ID: <037f6685-f364-e717-a86e-cbce9a182801@alum.mit.edu> Date: Mon, 6 Apr 2020 13:47:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200406150006.GJ18021@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(10009020)(396003)(39860400002)(346002)(136003)(376002)(46966005)(31686004)(70586007)(86362001)(31696002)(53546011)(70206006)(7596002)(47076004)(5660300002)(82740400003)(478600001)(26826003)(2906002)(8676002)(316002)(336012)(36906005)(26005)(186003)(2616005)(356004)(8936002)(246002)(6916009)(75432002)(786003)(956004)(40753002)(133343001); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a2fe52c7-0d2b-4712-f7b1-08d7da529fd6 X-MS-TrafficTypeDiagnostic: BYAPR12MB2965: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 0365C0E14B X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: E5NzF/8UMopPyqSIlag/gIWVNtQcJ6VNPFa4iXYaHrIMXB+WH5puvNCEpOesVXjzdUHtoh5xHg4wjN1E2mVSMcEP2C04kKe4RE+7w+/L+h2SHlGqfx4XrwcqO5KhM1U1/CnS7UERBz2cGHvE+l/fnXqdCn9OaoBLAMQ+92mFcLqKB/LD1mNTqQVbujwUGdkLsPjWPe56CG/WX1hVhrzvjMu/2ltQhiC4gSdb2XAy1KMQjL9fkEgKGtj4mCRusJfsDMMcEhPoYBmV7XZOIzm67/mQq1rWLfWU6VKYV77ugtl/IeUI0CU0ijt9HqL8Zq/le8fDzuQt0SQZfqyU1DD3Y1pbA335Xq5juMHri0x7NrWyAg+H68g7muVlUtwaY+kyq5YxREp2drrdryDOj4MB8EUy/9xw+GP6VywSH/vtMwFDqLta7rNZ7PZjM8Ex5+SZCtCwg3L2IlqAjePI5vsYv1R1oh6311DqrmHwXkfwXOc1Czg18LY2Rh4LWLpwEZemYaTx0gT18cVNkwmGqP1G9h5Hd5WzDQVEB5qCEnCH1zlr5cascxW1eTJ1uNH5t7uwEmEDqoLoGxf9vvaQua7qRRrQ3synuR0txA0WEp2vuaJCv4+mmOCruu81jIRme/EeHtNND4vPKPOXVXfaw5UODA== X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 17:47:49.7344 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a2fe52c7-0d2b-4712-f7b1-08d7da529fd6 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB2965 Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 17:47:54 -0000 On 4/6/20 11:00 AM, Nico Williams wrote: > On Mon, Apr 06, 2020 at 10:13:42AM +0200, Julian Reschke wrote: >> On 06.04.2020 07:07, Nico Williams wrote: >>> * Any options I missed? >> >> Date formats... > > -D DATE, --date=DATE run as if the date is DATE (format: yyyy-mm-dd) > > That's an option to set a date. > > ..xml should be submitted in "expanded" form, with all relevant options > from the xml2rfc accounted for, and in UTF-8. Why require UTF-8? > Simplicity, for one. We'll be producing UTF-8 anyways, so why require > server-side codeset conversions? If there are particular rules for the xml that is submitted, then please put a reference to them on . Is it sufficient to use with the "expanded XML " output option selected? And what do you mean by "submitted"? Do you mean with any draft submitted using ? Or do you only mean when submitting a final pre-rfc version intended for the editor? Or what? Thanks, Paul From nobody Mon Apr 6 10:52:59 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550213A09E1 for ; Mon, 6 Apr 2020 10:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b_Cp1jwQ1vE for ; Mon, 6 Apr 2020 10:52:43 -0700 (PDT) Received: from bumble.birch.relay.mailchannels.net (bumble.birch.relay.mailchannels.net [23.83.209.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A473A0DA4 for ; Mon, 6 Apr 2020 10:52:42 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 9C9E01212A3; Mon, 6 Apr 2020 17:52:41 +0000 (UTC) Received: from pdx1-sub0-mail-a85.g.dreamhost.com (100-96-14-18.trex.outbound.svc.cluster.local [100.96.14.18]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E5533120FDC; Mon, 6 Apr 2020 17:52:40 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a85.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Mon, 06 Apr 2020 17:52:41 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Grain-Plucky: 67ebf8777ad342e8_1586195561427_4063380901 X-MC-Loop-Signature: 1586195561427:3463027430 X-MC-Ingress-Time: 1586195561426 Received: from pdx1-sub0-mail-a85.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a85.g.dreamhost.com (Postfix) with ESMTP id AD9797F682; Mon, 6 Apr 2020 10:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=EgIFgoFaXKXlcV Q28KBbSpxFCBk=; b=Ga/4ruKy9pSAvrAcvUd971fYli+umEXkWYJy783HKngvcV gGlRrvkQy0ex8u/8/EbyV6NBiFy9arXOoM/eJUoIAmYbp4AHaE5cfuhbYOpy0rSW Kmhmhhv11UIVx09y4yan7RPhl8s7LKnW4WlfweGTgNJhrXCC1TJuYyegySA7A= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 86D9A7F67F; Mon, 6 Apr 2020 10:52:36 -0700 (PDT) Date: Mon, 6 Apr 2020 12:52:34 -0500 X-DH-BACKEND: pdx1-sub0-mail-a85 From: Nico Williams To: Paul Kyzivat Cc: xml2rfc@ietf.org Message-ID: <20200406175232.GN18021@localhost> References: <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> <20200406020058.GH18021@localhost> <20200406050711.GI18021@localhost> <583ce0c5-90b6-7e63-4445-06049d770c31@gmx.de> <20200406150006.GJ18021@localhost> <037f6685-f364-e717-a86e-cbce9a182801@alum.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <037f6685-f364-e717-a86e-cbce9a182801@alum.mit.edu> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudefgdduudduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 17:52:45 -0000 On Mon, Apr 06, 2020 at 01:47:47PM -0400, Paul Kyzivat wrote: > On 4/6/20 11:00 AM, Nico Williams wrote: > > On Mon, Apr 06, 2020 at 10:13:42AM +0200, Julian Reschke wrote: > > > On 06.04.2020 07:07, Nico Williams wrote: > > > > * Any options I missed? > > > > > > Date formats... > > > > -D DATE, --date=DATE run as if the date is DATE (format: yyyy-mm-dd) > > > > That's an option to set a date. > > > > ..xml should be submitted in "expanded" form, with all relevant options > > from the xml2rfc accounted for, and in UTF-8. Why require UTF-8? > > Simplicity, for one. We'll be producing UTF-8 anyways, so why require > > server-side codeset conversions? > > If there are particular rules for the xml that is submitted, then please put > a reference to them on . I'm advocating for new rules. I don't get to set them. > Is it sufficient to use with the "expanded > XML " output option selected? I'm saying that it should be. > And what do you mean by "submitted"? Do you mean with any draft submitted > using ? Or do you only mean when > submitting a final pre-rfc version intended for the editor? Or what? The former. Maybe xml2rfc could have a --submit option. Nico -- From nobody Mon Apr 6 10:58:46 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D68D3A0D80 for ; Mon, 6 Apr 2020 10:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yS_2c_0Z21QJ for ; Mon, 6 Apr 2020 10:58:21 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17AE63A0D7A for ; Mon, 6 Apr 2020 10:58:21 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48wyvH33TrzyWB; Mon, 6 Apr 2020 19:58:19 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <037f6685-f364-e717-a86e-cbce9a182801@alum.mit.edu> Date: Mon, 6 Apr 2020 19:58:18 +0200 Cc: xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 607888698.871031-408ddf53514f6f149db8b49cbcb77e7f Content-Transfer-Encoding: quoted-printable Message-Id: <13F6A42F-1559-47BA-A095-63CA8D7B9921@tzi.org> References: <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> <20200406020058.GH18021@localhost> <20200406050711.GI18021@localhost> <583ce0c5-90b6-7e63-4445-06049d770c31@gmx.de> <20200406150006.GJ18021@localhost> <037f6685-f364-e717-a86e-cbce9a182801@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 17:58:24 -0000 On 2020-04-06, at 19:47, Paul Kyzivat wrote: >=20 > And what do you mean by "submitted"? Do you mean with any draft = submitted using ? Or do you only = mean when submitting a final pre-rfc version intended for the editor? Or = what? Datatracker doesn=E2=80=99t know that. (It can=E2=80=99t, because = approval happens after submission.) If the RFC editor needs something special, they=E2=80=99ll make it or = discuss it with the authors. This discussion is *not* about RFCs, it is about XML2RFC=E2=80=99s = dominating usage: Authoring I-Ds. The name of the tool may obscure that, but it is really what we need to = optimize for. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 6 11:39:10 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8558A3A0C9B for ; Mon, 6 Apr 2020 11:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Zi1CfN84Ax5 for ; Mon, 6 Apr 2020 11:39:07 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2057.outbound.protection.outlook.com [40.107.243.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78CD3A0C99 for ; Mon, 6 Apr 2020 11:39:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UlkjhJ1w2doTcCKu2m04RGBLS/2s8prf/Qjz4XNkN6yQ+T8ym8AkHesDh6pII/hJrkOP8qWTbOLSuxxGOl3cZCYPGMlRFgx2DpJU0GUeY3K71i6yGEKKELPp5Dj9qUqb+B9/SAEC5nOMOvzaulNhcK21JQnaazo1o7zSiun1o479Qp+Z/sKhpFKWY4DQ3eNkYajnCcf+Gl/GUIvhZcPG98/jqMLgjWNtxhb45/GtKWwAwdJNpKywA2Q62L5VTqqxZNQFF7cJb8eriCXjL/wIoAOowJVzm0YlTkRzIjCHYm5itRQCmqWT4rqVC4LHad4WNRLEd+b55TBJNGoP5n+cxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n9IKE1nS4lLeyuiEkYgrH4LIwpaPOZNaLLajfIFqNPk=; b=Hj3oMaVI0ZilcuD1v1ngRx9m5NvkbDzEexfxQgpeljVm3FkQhZNcyuxFVWShVnBpuBidoHjCpoieqJrpbkpdRgXamHDafXBQ8/GiYSr01n4/bx17mdvxWPG8eKCAf8MopdkAjl09ARsmxNBvFYpF0RFw6+5Fuf2FFFMxs9P3uVHXaAXM0Kq9SgsK6vRW4fnfx3G/zZ7dbBLLyy4JZ9/+E+rr/Es7pLslLd/G8j15uvVx+1LEWGWzgGjcR3sCWoAv7/RBxYggaceSLBKu/FhnNZctDLkk7rCAIvAi/xxHIsUQfSxl7Naf3PQ8n3eLyyykJtKVrW/h7TnVRc6aJ91w+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=tzi.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n9IKE1nS4lLeyuiEkYgrH4LIwpaPOZNaLLajfIFqNPk=; b=bKqzSC9wscSimsfsjPV7xH6SB+6/9+4heXKF1SJHs4G27JU3FbqfQmJZsJs8gX4OZFnr6WEFgfJM1dSMbS5m9RZdzebEYGR44SdqtCx6DYNcjsWJYvUIp4eliDTVcRwdfeEWZhNwaqLZTqtSnwJuVVpgC06P/Pm++m/yoPRuHqo= Received: from BL0PR0102CA0028.prod.exchangelabs.com (2603:10b6:207:18::41) by BN8PR12MB3058.namprd12.prod.outlook.com (2603:10b6:408:66::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Mon, 6 Apr 2020 18:39:05 +0000 Received: from BL2NAM02FT036.eop-nam02.prod.protection.outlook.com (2603:10b6:207:18:cafe::e2) by BL0PR0102CA0028.outlook.office365.com (2603:10b6:207:18::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16 via Frontend Transport; Mon, 6 Apr 2020 18:39:05 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT036.mail.protection.outlook.com (10.152.77.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Mon, 6 Apr 2020 18:39:04 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 036Id2Xj009547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Apr 2020 14:39:03 -0400 To: Carsten Bormann Cc: xml2rfc@ietf.org References: <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> <20200406020058.GH18021@localhost> <20200406050711.GI18021@localhost> <583ce0c5-90b6-7e63-4445-06049d770c31@gmx.de> <20200406150006.GJ18021@localhost> <037f6685-f364-e717-a86e-cbce9a182801@alum.mit.edu> <13F6A42F-1559-47BA-A095-63CA8D7B9921@tzi.org> From: Paul Kyzivat Message-ID: <89b5164c-dee4-8ead-9e14-ad58abb45e9f@alum.mit.edu> Date: Mon, 6 Apr 2020 14:39:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <13F6A42F-1559-47BA-A095-63CA8D7B9921@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(10009020)(136003)(39860400002)(376002)(346002)(396003)(46966005)(356004)(6916009)(5660300002)(246002)(70206006)(82740400003)(7596002)(53546011)(31686004)(70586007)(8936002)(26005)(2616005)(26826003)(186003)(336012)(478600001)(956004)(36906005)(75432002)(47076004)(8676002)(31696002)(86362001)(2906002)(316002)(786003)(4326008)(40753002)(133343001); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c0e6c726-6a3a-41c5-d001-08d7da59c858 X-MS-TrafficTypeDiagnostic: BN8PR12MB3058: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0365C0E14B X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 53mNHgbRe8+rBG3/3teheBJI1BFHsVRP31hhbNgVwItDwEeu5hWegA9jjwiG18YauXmhPZkNMcsszYKRmwjGJIG3hTuALUP9pHEO3FLdzGA1FWSkVJQHnBfPBP3XS3b6BmHdq5edXKzoRWSvYJRVukbpDtvjvkmgxcBDZAJG4whNewSquJGWk9E7t84h5ImN06aiHXJB0oCTmPdjjUWIjrbleRGQ3ht7isB1vl1lnWh24LI14rw31K3KlpFNc4z6vbkeNG4dFQRc8ovKrHUQRKzmddja8+gkxI4Yxs6lPJoCsA1oTyzhW66Hfbpb5oJWox5x13Veqi9rcgtQHvQs8sKpfYgwTytutKeigQwQwZRiNNGIylEAe6Nclig4CmUI59qch+jjKp5Pfd4qj1vAFGJjST51bRSGBT3Qz/ZlZDLM0u5G3+d1H77kgcFXHkWBQ9d5fn/xC/+9qz9M66urcc99j8HY5WS6G4NUamEcQFAZsjD9ggNE45st7j66bZaxMM0xtBn3sZGflyYbhaRYZAe2f6EjlRM53fubsJbi43oAQGgWpb1Qxtgy9jrbzHMyI19fGx140wi8z6dRRHFq7UnWdXnCEcaLgDxcWCgq9zolNdd/daZq1xgtMhEMx55HTJUr7XtgtIAOTkUrwqf1hw== X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 18:39:04.3513 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c0e6c726-6a3a-41c5-d001-08d7da59c858 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR12MB3058 Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 18:39:08 -0000 On 4/6/20 1:58 PM, Carsten Bormann wrote: > On 2020-04-06, at 19:47, Paul Kyzivat wrote: >> >> And what do you mean by "submitted"? Do you mean with any draft submitted using ? Or do you only mean when submitting a final pre-rfc version intended for the editor? Or what? > > Datatracker doesn’t know that. (It can’t, because approval happens after submission.) > If the RFC editor needs something special, they’ll make it or discuss it with the authors. > > This discussion is *not* about RFCs, it is about XML2RFC’s dominating usage: Authoring I-Ds. > The name of the tool may obscure that, but it is really what we need to optimize for. OK. I just wanted to be sure. Is the need for expanded form to ensure that there are no dependencies on the local environment of the submitter? Or are there other reasons as well? (If I'm successfully using xml2rfc on the tools web page then there clearly aren't any dependencies on my local environment.) My preference with v2 was to submit the source xml along with the txt of each version, so that it is available to anybody else who might take up the pen on the document. Submitting the expanded form potentially divorces it from the *source*. Typically my use of includes in the xml has been limited to references, so dependencies were pretty stable. Requiring the expanded form be submitted means that there is no reliable and consistent way for somebody to obtain the *source* form. (E.g., somebody who wants it as the starting point for a bis.) I think we need a way to save both. Thanks, Paul From nobody Mon Apr 6 11:57:11 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113523A0C8C for ; Mon, 6 Apr 2020 11:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5hw3I9HIgjL for ; Mon, 6 Apr 2020 11:57:01 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389493A08F9 for ; Mon, 6 Apr 2020 11:56:58 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48x0Bw1PRQzyvk; Mon, 6 Apr 2020 20:56:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <89b5164c-dee4-8ead-9e14-ad58abb45e9f@alum.mit.edu> Date: Mon, 6 Apr 2020 20:56:55 +0200 Cc: xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 607892215.610103-cbcff8493263384ae2d5f02ab13dba49 Content-Transfer-Encoding: quoted-printable Message-Id: <6BAFADDF-08D3-4425-9455-AF5A1590D122@tzi.org> References: <20200402190920.GY18021@localhost> <7c9b973d-469f-23ac-af97-66c119fc8a42@levkowetz.com> <86689284-E18F-450B-8BDB-1A4F846DB9E5@tzi.org> <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> <20200406020058.GH18021@localhost> <20200406050711.GI18021@localhost> <583ce0c5-90b6-7e63-4445-06049d770c31@gmx.de> <20200406150006.GJ18021@localhost> <037f6685-f364-e717-a86e-cbce9a182801@alum.mit.edu> <13F6A42F-1559-47BA-A095-63CA8D7B9921@tzi.org> <89b5164c-dee4-8ead-9e14-ad58abb45e9f@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 18:57:09 -0000 >=20 > Is the need for expanded form to ensure that there are no dependencies = on the local environment of the submitter? Or are there other reasons as = well? The discussion of this started with svg files linked from the XML. These obviously need to be included for a single-file XML submission. > (If I'm successfully using xml2rfc on the tools web page then there = clearly aren't any dependencies on my local environment.) Right. One of the problems we sometime have is that the velocity of the = tools web page is divorced from the velocity on datatracker. > My preference with v2 was to submit the source xml along with the txt = of each version, so that it is available to anybody else who might take = up the pen on the document. I did that for a while, but then most documents nowadays live on github, = which is much sourcier. > Submitting the expanded form potentially divorces it from the = *source*. Typically my use of includes in the xml has been limited to = references, so dependencies were pretty stable. In the current system, most authors cannot submit their source anyway, = so one more or less processing step does not make a big difference. > Requiring the expanded form be submitted means that there is no = reliable and consistent way for somebody to obtain the *source* form. = (E.g., somebody who wants it as the starting point for a bis.) Point to the github=E2=80=A6 (If you write a bis after 10 years, the source is probably already much = less useful. Henrik even has a tool that upconverts .txt to .xml=E2=80=A6) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 6 12:44:47 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F533A0D8C for ; Mon, 6 Apr 2020 12:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVOx_IwnmMrK for ; Mon, 6 Apr 2020 12:44:44 -0700 (PDT) Received: from azure.elm.relay.mailchannels.net (azure.elm.relay.mailchannels.net [23.83.212.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92E33A0D8B for ; Mon, 6 Apr 2020 12:44:43 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id B405B5416B3; Mon, 6 Apr 2020 19:44:42 +0000 (UTC) Received: from pdx1-sub0-mail-a81.g.dreamhost.com (100-96-14-17.trex.outbound.svc.cluster.local [100.96.14.17]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 21D52541725; Mon, 6 Apr 2020 19:44:42 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a81.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Mon, 06 Apr 2020 19:44:42 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Fumbling-Towering: 0b2bbb0c3718a0b5_1586202282448_2232941386 X-MC-Loop-Signature: 1586202282448:1767761437 X-MC-Ingress-Time: 1586202282447 Received: from pdx1-sub0-mail-a81.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a81.g.dreamhost.com (Postfix) with ESMTP id BCF2E7F0C4; Mon, 6 Apr 2020 12:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=rLtqoRWPBTmwaDSCg4wBNGsjsKU=; b=Pi924geX+7Y wBnLSg0ODPXNVv1elmjFLGyEkAdJGP2uLs+VQV+44idHUUM+tA73OsIyKgO2sBk9 osc9Yh80dURKhPg1RqfXh0PdvacoeaIIw74v5brk3HQNklodBrf6z658OqyNEOW/ pOjCB3rD0k4t/2u0AXjq448euEyfS1XA= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a81.g.dreamhost.com (Postfix) with ESMTPSA id 9789F7F0D7; Mon, 6 Apr 2020 12:44:38 -0700 (PDT) Date: Mon, 6 Apr 2020 14:44:36 -0500 X-DH-BACKEND: pdx1-sub0-mail-a81 From: Nico Williams To: Carsten Bormann Cc: Paul Kyzivat , xml2rfc@ietf.org Message-ID: <20200406194434.GO18021@localhost> References: <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> <20200406020058.GH18021@localhost> <20200406050711.GI18021@localhost> <583ce0c5-90b6-7e63-4445-06049d770c31@gmx.de> <20200406150006.GJ18021@localhost> <037f6685-f364-e717-a86e-cbce9a182801@alum.mit.edu> <13F6A42F-1559-47BA-A095-63CA8D7B9921@tzi.org> <89b5164c-dee4-8ead-9e14-ad58abb45e9f@alum.mit.edu> <6BAFADDF-08D3-4425-9455-AF5A1590D122@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6BAFADDF-08D3-4425-9455-AF5A1590D122@tzi.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudefgddufeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtugfgjggfsehtkeertddtreejnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 19:44:46 -0000 On Mon, Apr 06, 2020 at 08:56:55PM +0200, Carsten Bormann wrote: > > Requiring the expanded form be submitted means that there is no > > reliable and consistent way for somebody to obtain the *source* > > form. (E.g., somebody who wants it as the starting point for a bis.) Not requiring the expanded form means possibly not being able to use the submitted .xml. Why even bother asking for the .xml then? It has got to be expanded. > Point to the github=E2=80=A6 Right, either you submit an expanded .xml, or a tarball with all the includes, or a Git repo URI that can be cloned server side to find the .xml and its dependencies. But what if you're building the .xml from other things? This way madness lies. E.g., I used to use LyX + lyx2rfc, so some of my canonical sources are .lyx files, not .xml, but I wouldn't expect the submission server to take a Git repo link and know what to do to get .xml. I just check in the .xml, and the .txt, and the .unpg, and the .html -- especially the .xml and the .unpg, since that makes reviewing commits much easier. No, the simplest thing to do is to require the expanded .xml, at which point it might as well be in UTF-8. And the server might as well use it to generate .txt and other formats, thus giving the server a chance to insist on expanded .xml. The form could also stand to have a field for a Git repository URI -- that would be very nice documentation, actually. And the datatracker page could link it too. Might as well also ask if issues and PRs are accepted at the link (if it's not just a Git link, but actually richer and supports issues and PRs). > (If you write a bis after 10 years, the source is probably already > much less useful. [...] Yes, but if the archived .xml is complete (expanded) then you can work from that, much better than working from the .txt, even if: > [...]. Henrik even has a tool that upconverts .txt to > .xml=E2=80=A6) Really! But that can't possibly be as good as working from the expanded .xml. Nico --=20 From nobody Mon Apr 6 12:59:08 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1EE3A0E11 for ; Mon, 6 Apr 2020 12:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-Bze7TQFBT7 for ; Mon, 6 Apr 2020 12:59:04 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859133A00E1 for ; Mon, 6 Apr 2020 12:59:04 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48x1ZZ4pMNzytW; Mon, 6 Apr 2020 21:59:02 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <20200406194434.GO18021@localhost> Date: Mon, 6 Apr 2020 21:59:02 +0200 Cc: Paul Kyzivat , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 607895942.150666-54ee3ff92ef01ddf7cebe05fd4a4f54b Content-Transfer-Encoding: quoted-printable Message-Id: References: <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> <20200406020058.GH18021@localhost> <20200406050711.GI18021@localhost> <583ce0c5-90b6-7e63-4445-06049d770c31@gmx.de> <20200406150006.GJ18021@localhost> <037f6685-f364-e717-a86e-cbce9a182801@alum.mit.edu> <13F6A42F-1559-47BA-A095-63CA8D7B9921@tzi.org> <89b5164c-dee4-8ead-9e14-ad58abb45e9f@alum.mit.edu> <6BAFADDF-08D3-4425-9455-AF5A1590D122@tzi.org> <20200406194434.GO18021@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 19:59:07 -0000 On 2020-04-06, at 21:44, Nico Williams wrote: >=20 > On Mon, Apr 06, 2020 at 08:56:55PM +0200, Carsten Bormann wrote: >>> Requiring the expanded form be submitted means that there is no >>> reliable and consistent way for somebody to obtain the *source* >>> form. (E.g., somebody who wants it as the starting point for a bis.) (Actually, I didn=E2=80=99t.) And I should maybe point out that kramdown-rfc cheats: it hides the = source (.md) in the generated XML, which survives prepping (I currently = use prepping as a slightly more reliable substitute for expansion). So = you get the markdown source, but not the source of the scripts that = generated and validated the examples etc. You need the github repo for = that. I like the idea of being able to submit via a repo link. Martin = Thomson=E2=80=99s template has the ghpages convention that could be used = to find the XML. And the repo could be cloned/fetched for future = perusal. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 6 13:04:38 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0163A0E60 for ; Mon, 6 Apr 2020 13:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnmZtm_36BbZ for ; Mon, 6 Apr 2020 13:04:36 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2076.outbound.protection.outlook.com [40.107.243.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD2B3A0E68 for ; Mon, 6 Apr 2020 13:04:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IAyjXcc/QVRsurlDHmnqWWU/4jG5dLB6BN8vOPL/CckzuagtBZfIi3HyqGqNGZxgyjQnwcwonaJI4sdnq/ApFWRxR3TXZHhITOLMdvRfdmLTTiiyS4RodDCNMsLSAbRM0fTJIS9bF7wPgS6lE4cTDt8K8oDMeJLp8IDZwvXEJTjCQ7fsJy+L3N/jkZ8SW+EWkRPpDjhTMAvORN7dqmMfwLHAdP9kKsdrTq4zR2xw3VzYV6ZJaOSHu71NDZHTI/9NqovyxRHnWzNxcXSfV76lpT1o0NAiPoNbGtc0nu9LEO1e3wYTxpluiHNxPcE/hBRJNjl9gC3pIdksVHk/rU5H3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oasoF8kCs5bilCTduMZRKoGgiWsi1eYMLWyDsCmgS4M=; b=oNL4W4a326t6Ox+6cwGQZREtzHNoVyDSdafnrjbq1h6TGk3E1Pc+URas88l1nPmBcHgHfP3klxlhwKqaZ3txi8Sfkvscpx52v6obN2+ynvM9onG4QuwTFSwKiyBHSIWGztBdHBosAQa31+XXe9dby9RCl8XrWXYIEmPSULlS1CMtIDOQdetthvJyhFwQwNxovvkmnVpr9sCVPArbYe/jnGd1eMc5DRbf8XVmkJ0vzAtFIwuWHFXc1DpBzCvVwgKGoLzTT7Z1Cj+2JZk5EPmJdQHuW66RT2R0j6XTfZs2K//H71XFvs5zEXbKyqWYjJk3RzAWQuwE8+X5rE9KmbFjJw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=cryptonector.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oasoF8kCs5bilCTduMZRKoGgiWsi1eYMLWyDsCmgS4M=; b=S1ZrqQwg64gjP6lPzjAsTsj8WBZ8cimSCXiPRI5TsghIN7qFcujHwUHLraytHxYdJBwE0HMoPtvVQGUy8XxyjB/t5OxcIkSCUUilIXAzcdu5+SgCMEqip4nygoRuFyAT8QI7umxcizjvJJCkUfMnbm73yybjpcruwdPn+nWRG9A= Received: from MN2PR12CA0020.namprd12.prod.outlook.com (2603:10b6:208:a8::33) by BYAPR12MB3544.namprd12.prod.outlook.com (2603:10b6:a03:131::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Mon, 6 Apr 2020 20:04:34 +0000 Received: from BL2NAM02FT020.eop-nam02.prod.protection.outlook.com (2603:10b6:208:a8:cafe::4e) by MN2PR12CA0020.outlook.office365.com (2603:10b6:208:a8::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Mon, 6 Apr 2020 20:04:34 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; cryptonector.com; dkim=none (message not signed) header.d=none;cryptonector.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT020.mail.protection.outlook.com (10.152.77.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Mon, 6 Apr 2020 20:04:33 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 036K4V7A015067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Apr 2020 16:04:32 -0400 To: Nico Williams , Carsten Bormann Cc: xml2rfc@ietf.org References: <04b4f429-43d7-83c3-6345-6c6c1848c2c5@it.aoyama.ac.jp> <20200406020058.GH18021@localhost> <20200406050711.GI18021@localhost> <583ce0c5-90b6-7e63-4445-06049d770c31@gmx.de> <20200406150006.GJ18021@localhost> <037f6685-f364-e717-a86e-cbce9a182801@alum.mit.edu> <13F6A42F-1559-47BA-A095-63CA8D7B9921@tzi.org> <89b5164c-dee4-8ead-9e14-ad58abb45e9f@alum.mit.edu> <6BAFADDF-08D3-4425-9455-AF5A1590D122@tzi.org> <20200406194434.GO18021@localhost> From: Paul Kyzivat Message-ID: <0e9cb49b-9720-17f6-1e86-ea4a7c75d305@alum.mit.edu> Date: Mon, 6 Apr 2020 16:04:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200406194434.GO18021@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(10009020)(396003)(376002)(346002)(39860400002)(136003)(46966005)(2616005)(336012)(956004)(31696002)(75432002)(186003)(5660300002)(47076004)(7596002)(82740400003)(4326008)(356004)(70206006)(70586007)(26005)(246002)(478600001)(31686004)(110136005)(53546011)(36906005)(8936002)(2906002)(26826003)(786003)(316002)(8676002)(86362001)(40753002)(133343001); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2b4de52c-1112-4fd8-b17b-08d7da65b986 X-MS-TrafficTypeDiagnostic: BYAPR12MB3544: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0365C0E14B X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gLO3QBG/WtnhT7njp/SnAygfaS29e1/xapnAudAAVIErns5RM4/Gm1gwefqJx245d8nBX+h59205lOCLftZbbB9t+luLZN/W1Q1w+MU0neu5tDhJuWshcHCuyRYmNuSrO3N54WVrZkHayRsfvzoVJvzFJGqQxhtXvmrWGZRcrHY7IUcAA5BDBBmFLgY5BdNbifIvzniWetKuUUkwhTiureDsdH8YXc3b/sKNVNxt5m9c2W2dXXS7hY7zviEdbVtJQStU/9T8zjHNCouZeJiyNXtLARBGuM1+biMT+soP8j9Pe6zhOZfHLzrb5By43qz0A9UhPbmvhZXuhbxw7SwTskVjnzDHaqq3NYVLqreCOrenWlv9uf1QYennT27IIpc5MeD5xkJTL/zqBUx9HOKzTBscSAhPsk6/iVOxbL9fODWGHgsFFi7XzDZ8Bqn+HEFW5sth0v2ROqxnTQXrZdeJqWhRLdI/e47VP2juq+4MXJKuNR0CF37InLo4QFYbGblhgRWO0exs2vjsjjfvTQ0FCzJeW0kwMgc+47SLVpjRPYehyKjJJirGhFnbFPAp6HMA X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 20:04:33.4489 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2b4de52c-1112-4fd8-b17b-08d7da65b986 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB3544 Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 20:04:38 -0000 On 4/6/20 3:44 PM, Nico Williams wrote: > On Mon, Apr 06, 2020 at 08:56:55PM +0200, Carsten Bormann wrote: >>> Requiring the expanded form be submitted means that there is no >>> reliable and consistent way for somebody to obtain the *source* >>> form. (E.g., somebody who wants it as the starting point for a bis.) > > Not requiring the expanded form means possibly not being able to use the > submitted .xml. Why even bother asking for the .xml then? It has got > to be expanded. > >> Point to the github… > > Right, either you submit an expanded .xml, or a tarball with all the > includes, or a Git repo URI that can be cloned server side to find the > .xml and its dependencies. But what if you're building the .xml from > other things? This way madness lies. > > E.g., I used to use LyX + lyx2rfc, so some of my canonical sources are > .lyx files, not .xml, but I wouldn't expect the submission server to > take a Git repo link and know what to do to get .xml. I just check in > the .xml, and the .txt, and the .unpg, and the .html -- especially the > .xml and the .unpg, since that makes reviewing commits much easier. > > No, the simplest thing to do is to require the expanded .xml, at which > point it might as well be in UTF-8. And the server might as well use it > to generate .txt and other formats, thus giving the server a chance to > insist on expanded .xml. > > The form could also stand to have a field for a Git repository URI -- > that would be very nice documentation, actually. And the datatracker > page could link it too. Might as well also ask if issues and PRs are > accepted at the link (if it's not just a Git link, but actually richer > and supports issues and PRs). "Source" is a very slippery term, and can include input to some very unstable home-brew tools. Yet, if it is to be possible for somebody new to take over authorship then it is very difficult without the source and the tools that expand it. Having a reference to the Git repository would be go quite a ways to achieving that. If that is the direction, then it indeed should be available in the datatracker. And there should be some assurance (how?) that the parts of the repository that this reference depends upon are stable and reliable. I've also long been bothered by the submission took accepting multiple forms where some are derived from others (e.g., an xml and a txt) because there is no guarantee that those forms are consistent. It is only an implied *assertion* by the submitter. It would be much better if derived forms were always created by the submission tool. And this could extend all the way to cases where the "source" is in a Git repository. But it only works if the tooling has access to, and understanding of, the tooling used for the derivation. Thanks, Paul From nobody Mon Apr 6 13:47:40 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91953A087F for ; Mon, 6 Apr 2020 13:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51gOuQoPQgQp for ; Mon, 6 Apr 2020 13:47:37 -0700 (PDT) Received: from chocolate.birch.relay.mailchannels.net (chocolate.birch.relay.mailchannels.net [23.83.209.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776953A0C75 for ; Mon, 6 Apr 2020 13:47:16 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C8AC69216AB; Mon, 6 Apr 2020 20:47:15 +0000 (UTC) Received: from pdx1-sub0-mail-a81.g.dreamhost.com (100-96-2-17.trex.outbound.svc.cluster.local [100.96.2.17]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 275EC92169E; Mon, 6 Apr 2020 20:47:15 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a81.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Mon, 06 Apr 2020 20:47:15 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Quick-Madly: 2c1be8a237c62968_1586206035462_2726922195 X-MC-Loop-Signature: 1586206035462:4131009852 X-MC-Ingress-Time: 1586206035461 Received: from pdx1-sub0-mail-a81.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a81.g.dreamhost.com (Postfix) with ESMTP id 7B7E87F0FA; Mon, 6 Apr 2020 13:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=bD8NRQlO+AFovD jtY8ybB9BZ1jY=; b=HCzLuztSamkBayj3vPctKHUIbTAM/CZiq8S5lCN756uZSu kVimySvG/bU6mZqUAW0JwBrCklpkitaX5CNbvqmyGLl/lXzRtUIN5MgnqJPYWSJ5 QddYbyuC+gMrV92i9lYbmuFaGd+Qjdw9kHn3djfd38u7LHK3Zl2dTkhwtQCbk= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a81.g.dreamhost.com (Postfix) with ESMTPSA id 405E57F0EF; Mon, 6 Apr 2020 13:47:08 -0700 (PDT) Date: Mon, 6 Apr 2020 15:47:06 -0500 X-DH-BACKEND: pdx1-sub0-mail-a81 From: Nico Williams To: Paul Kyzivat Cc: Carsten Bormann , xml2rfc@ietf.org Message-ID: <20200406204705.GQ18021@localhost> References: <20200406050711.GI18021@localhost> <583ce0c5-90b6-7e63-4445-06049d770c31@gmx.de> <20200406150006.GJ18021@localhost> <037f6685-f364-e717-a86e-cbce9a182801@alum.mit.edu> <13F6A42F-1559-47BA-A095-63CA8D7B9921@tzi.org> <89b5164c-dee4-8ead-9e14-ad58abb45e9f@alum.mit.edu> <6BAFADDF-08D3-4425-9455-AF5A1590D122@tzi.org> <20200406194434.GO18021@localhost> <0e9cb49b-9720-17f6-1e86-ea4a7c75d305@alum.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e9cb49b-9720-17f6-1e86-ea4a7c75d305@alum.mit.edu> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudefgddugeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [xml2rfc] Submission problem due to xmltrfc not putting asciiSurname into .txt output X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 20:47:39 -0000 On Mon, Apr 06, 2020 at 04:04:31PM -0400, Paul Kyzivat wrote: > "Source" is a very slippery term, and can include input to some very > unstable home-brew tools. Yet, if it is to be possible for somebody > new to take over authorship then it is very difficult without the > source and the tools that expand it. If the goal is to enable someone else to take over the editor baton, then a Git repo link should suffice. If the goal is to have the submission server be able to build the Internet-Draft, then you really need to submit expanded .xml. Of course, we could do both. > I've also long been bothered by the submission took accepting multiple > forms where some are derived from others (e.g., an xml and a txt) > because there is no guarantee that those forms are consistent. It is > only an implied *assertion* by the submitter. It would be much better > if derived forms were always created by the submission tool. And this With the caveat that some editors don't do XML and we insist on supporting that, so it has to be possible to submit .txt-but-not-.xml. But yes, that's my point: if you're submitting .xml, it should be expanded .xml and the .txt should either be left out or checked for exact match with the .txt produced by the server from the expanded .xml. > could extend all the way to cases where the "source" is in a Git > repository. But it only works if the tooling has access to, and > understanding of, the tooling used for the derivation. And that's hard. That's why the .xml needs to be expanded. That's just so much easier on everyone. And if it's expanded? It might as well be UTF-8. The .txt should absolutely be required to be UTF-8 when .xml is not submitted. Nico -- From nobody Tue Apr 14 07:02:33 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9413A0658; Tue, 14 Apr 2020 07:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAKCmT9l6m9W; Tue, 14 Apr 2020 07:02:22 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265763A065A; Tue, 14 Apr 2020 07:02:22 -0700 (PDT) Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from ) id 1jOM8r-0003E7-Ly; Tue, 14 Apr 2020 07:02:21 -0700 To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org Cc: rfc-markdown@ietf.org Message-Id: From: Henrik Levkowetz Date: Tue, 14 Apr 2020 07:02:21 -0700 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc] New xml2rfc release: v2.43.0 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 14:02:24 -0000 Hi, This is an automatic notification about a new xml2rfc release, v2.43.0, generated when running the mkrelease script. Release notes: xml2rfc (2.43.0) ietf; urgency=medium * Added a workaround for weasyprint's extreme unwillingness to break between
and
, which looks like a bug. Fixes issue #514. * Fixed a discrepancy in address handling between text and html output. Fixes issue #509 * Added more flexible text formatter handling of orphans and widows, and changed the default orphans/widows setting to 2 (matching the default CSS setting). * Changed the CSS to not page break before the ToC, support keepWithPrevious, and deal better with how some artwork, figures and tables break across pages. Fixes issue #511. * Changed the keepWithNext handling for the generated ToC to group the first 3 lines together, to avoid one-line orphans when page-breaking the ToC. Also fixed some pyflakes issues with regex strings. * Added text formatter support for 'keepWithPrevious', even if the preptool generally converts 'keepWithPrevious' to 'keepWithNext' on the previous element. * Added setting '.keepWithPrevious' on html elements when set on the precursor xml element. * Added v2v3 converter code to set 'keepWithNext' and 'keepWithPrevious' when converting and elements to elements, to keep the grouping. * Added code to the command-line runner to set some option default values that don't have matchinb command-line switches. * Added default settings for orphans and widows during text rendering. * Reduced the CSS font-family for body to only Noto Serif. Addresses issue #500. -- Henrik Levkowetz 11 Apr 2020 13:31:48 +0000 The preferred way to install xml2rfc is by doing 'pip install xml2rfc', and 'pip install --upgrade xml2rfc' to upgrade. If there are system- installed python modules which pip will not upgrade, you may have to use 'pip install --upgrade --no-deps xml2rfc' and install dependencies manually. The new version is also available through SVN checkout, with 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.43.0' Regards, Henrik (via the mkrelease script) From nobody Thu Apr 16 03:10:09 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892DD3A1392 for ; Thu, 16 Apr 2020 03:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4SwnDVCswVl for ; Thu, 16 Apr 2020 03:10:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0DA43A1390 for ; Thu, 16 Apr 2020 03:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1587031803; bh=e2xcapoWQZzyxuTgWCS3K8SRtLCMakF+FNCpmtOgrwE=; h=X-UI-Sender-Class:Subject:From:To:References:Date:In-Reply-To; b=asP9ahyBZiuEvhdGWzuZSxfOSiKy/RVpuVgesgDvvnvuU72L09E3pKyAVCakWRu8G y/Q9M7kvkxL1qBRJO+o0xDyrtqLlhZCG0H/MA+cwcsrPnvb8x0o5JbeAa5VZALG5lW tib0FuWB/dx88+v6EPR0Tsa2drgvMDBKHVcPYXU8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([217.91.35.233]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M6ll8-1jK4iT15bS-008Ja6 for ; Thu, 16 Apr 2020 12:10:03 +0200 From: Julian Reschke To: "xml2rfc@ietf.org" References: Message-ID: <7fb6223c-7182-48c3-7c95-3773c3187b03@gmx.de> Date: Thu, 16 Apr 2020 12:10:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:gFqd7D+fpTUhPyvrrgE/lLFc5EEfTpbXXjnmDlq8wPE54mqZRHK iIrDzbGx7KphJBZcIw6E3gv8pWMpbSTVSQTLXZP5OQloXEdG4dVQRhGIkD42znlZIGDG+g1 NMv6ZJ2fvh95hjvPNThGeXzpt5Hn/mEaTktdTQ8C2NDuXAf6LBoneIpK/3xTXpPMQ6jcm0I walG0eX9FkkQGlsKSp2sA== X-UI-Out-Filterresults: notjunk:1;V03:K0:7vKqtB1Ntv0=:ywhtbA4SAHcWjqE3FE0aH4 0OyeZO4wNXe4SLZmStYR4CzMBgQ76534vyvG3SBS7sIf+YFgAXPG46owPcUrZP5XVhQ1RlHJU aokW2wI7No+DvD/mLZnvqb61KTdIqwKoPWVqMSR/77jGpwAmBvX0/ZjEQRxCDmndHRB7lO6MZ XtfktnOzFalNK+ktfTWCagXY3pDftJzDQAYZB/R9XPlNeP7RGSq7TWi9CjI5dnEmVr+z7MR5I 14cOZu4T5mMbDR8vhMKGIZh8ZP1GrdHRsbTlSphwGnG0SuMECf7HMgJTcaNcrTx15tKFjZzpU 4halosbBOw680ENywtUMo6V1T6HOQK0kM6qStuqO9ZELt4X6knlUEsXulN6G2HbKoLAv381q4 2n6uB+8sYpmTdPkqQ/wLKsxSE8JFzSkeAFiTTRV76WpTLHAlVDuVQWxA+Cf2typrDw32vBeP+ m6RpettqbK8JrHDT5PSnFH+DceTz/5WhTPn58kAlbzsYcGXJlhP3iVkQblspwn+OELvOuJ/JR GxiZ++5WuFwVYahRtK8mNufFwgBx1vU1HiTAwy0vZ1MktT1C5/iqQZqIbIByUvBjNqFFl/SID QhkKN8LXPvQ+kxYtcAraJUNr9g6WErDmcYQcxdqvlgQmaryTPjHd86QMM7AZmxVX2O2pNi0Sj BpSPKm23jWz5kWud9a90ypC2ZliQxHg58fSnq/OEzHATBdt4hHH265g8gftaZM+bo+WlBZm4B lPMBpjBJUk/XInORAxZBkEuVkXNMKm30s1RSIBtBHso8LXMfxRQRB+fMg7qRmi9VKtRaIh3ZE 1doGPo6cxw9vUM05yUb1bgPtxdM67rfElBN/F3NQUuWQrQoZpTyc1EM2fqomAoR80nfqJ6DfL 6o5eNt2XKlcXNJ1aF+M7pz79Gw8VmA+qKCc633tryJqNiB5x7NrBmATKJNaX1Sd94gJMpNYBy 9OlXP2GuLkzUTN8VzJn2dlvlaJdWn1QYM0q49PZNQkIFXgOVaq2QmpCGeI6UGiHHM7HLN2rvY zF9dAGEzfZPqcpLjR+oaxMXYqiH2p0//JathKU/9hQClxoM1J84lubtlbv3lcQZu5nKNx82DJ GU8o9gBoSkCBxknKxlH4fTZ5Y+YUU3BFMF8TjG8BDEtFV7tAk2swdSZWlas5ZxKclRpHZwnGL +uUgjPO0NS0l0+DY8nREQ3KWYhI1VmlAPq22hPTDM9WraYyDD8K+6L3OTqCb0k6IFAjAJpyxV RtHv9B1hxOb3ixJcv Archived-At: Subject: [xml2rfc] https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml timing out X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 10:10:08 -0000 > curl -v https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 4.31.198.44... > * TCP_NODELAY set > 0 0 0 0 0 0 0 0 --:--:-- 0:00:20 --:--:-- 0* connect to 4.31.198.44 port 443 failed: Timed out > * Failed to connect to xml2rfc.ietf.org port 443: Timed out > * Closing connection 0 > curl: (7) Failed to connect to xml2rfc.ietf.org port 443: Timed out Best regards, Julian From nobody Thu Apr 16 05:41:43 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F0E3A160B for ; Thu, 16 Apr 2020 05:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMxs-KWWXB_J for ; Thu, 16 Apr 2020 05:41:38 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7673A1609 for ; Thu, 16 Apr 2020 05:41:38 -0700 (PDT) Received: from [192.168.217.150] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 492zPD4bcmz1082; Thu, 16 Apr 2020 14:41:36 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <7fb6223c-7182-48c3-7c95-3773c3187b03@gmx.de> Date: Thu, 16 Apr 2020 14:41:36 +0200 Cc: "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 608733696.04173-afe8ed68d78f2214eb49b94adaa8bc0e Content-Transfer-Encoding: quoted-printable Message-Id: References: <7fb6223c-7182-48c3-7c95-3773c3187b03@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [xml2rfc] https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml timing out X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 12:41:42 -0000 I generally have more luck with xml2rfc.tools.ietf.org; saves one 302 = and reduces two SPOFs to one SPOF. Gr=C3=BC=C3=9Fe, Carsten > On 2020-04-16, at 12:10, Julian Reschke wrote: >=20 >> curl -v = https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml >> % Total % Received % Xferd Average Speed Time Time Time = Current >> Dload Upload Total Spent Left = Speed >> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- = --:--:-- 0* Trying 4.31.198.44... >> * TCP_NODELAY set >> 0 0 0 0 0 0 0 0 --:--:-- 0:00:20 = --:--:-- 0* connect to 4.31.198.44 port 443 failed: Timed out >> * Failed to connect to xml2rfc.ietf.org port 443: Timed out >> * Closing connection 0 >> curl: (7) Failed to connect to xml2rfc.ietf.org port 443: Timed out >=20 > Best regards, Julian >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Thu Apr 16 06:23:55 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098D03A07BA for ; Thu, 16 Apr 2020 06:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XKZKac047J0 for ; Thu, 16 Apr 2020 06:23:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2043A07BE for ; Thu, 16 Apr 2020 06:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1587043415; bh=uaQ4Xp0lHurhtIu/MbqyJAbL9YFoIOdr1tw+OmAP31g=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Tw+2BgbVjz1dk4u6MG6K9wHqFDZH10kVHVC91t9s52y8jhuiDy6ukCqvgq19vJAg/ BIG/6tsv7F75L6SAUjKm2tgtA7ZqKkc7gByo9T0ASZKMg+D4BN4v9rkbkINm8h6ujI eNeLhxuBxbtBGg2dDMPmpP7WlD/xaL5eNhoVQ/wY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([217.91.35.233]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MyKHc-1j20nD26ii-00yhml; Thu, 16 Apr 2020 15:23:35 +0200 To: Carsten Bormann Cc: "xml2rfc@ietf.org" References: <7fb6223c-7182-48c3-7c95-3773c3187b03@gmx.de> From: Julian Reschke Message-ID: Date: Thu, 16 Apr 2020 15:23:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:yQJXidoeDNH6m1UcGUl9CT7YCqg/68UKmr+9ISHCTJSN44HrDl2 6zdoCuJvstytXFpUlcSray+aSfahq5jf0vQo8591iU43iIonPWlGbOLqoLC8+YuWjAiKj0v D6pW1q6m6b/YRIXPUVwyOls8eGq5soRKtnsQ+ZsQAQTpZiRFuA0ioUPpyG6tT/SI7mewR5H zY9TwdxgFSz56j+DyI+BA== X-UI-Out-Filterresults: notjunk:1;V03:K0:fua42jW9caE=:YSvjU1CfZzCBMZvSbNSaDZ 6jbs39Dwb/YmSHKch0sfrKBLMjX0x4hrKMwtw3D2GhFST5CNrm9csGtg5rTxGQNS4Jfj1jBh8 R+r3FhRI5280Qu3Vr8wBOtPqNJ5jiz8oTcY7Nvx8WZuztlKpHrcHJVvzgB9tkqdT9/T/HU/tE VeCEjcP0s4sUX66de/vDEu11kGx3++UMWt4AGfv3aysK9u0KoZ95CfIWovQo0PxvrAKOfLk6d d/AKzLsxEKU9Wcj+drgcCq77xYuVca7xC0FXjYbqi3IGNG2CM57I62pkUfIDub9cy3lHE9GbW J8xgDeuIsAmBWLgJHL1OCK7VpylhI4m7/vNc6SscAfvvDuclUDbbGAUnqnY5GBUjFtP1h/45O A/Lf8H0u49bGedQukXbV5uF0aTqmaWbAtqF/SKwjTWP38amJe/pYPisrqUrR7RQbhTdVEao/a ZZ/N/ZvXnK71/OlzHJOfbjpUkxkmqDEX/itnsQxDfVEgAEaGNdVs4XnTcq04SpbYI6JudenAN Fp53jHWUiz7iY+YTsriP5MxLm5cA7rFEtPSWtpD5RJNKDMBU9Xjv4xudtJllKjNGshzEckn03 gTSMa9sZmX94/CMF1aWHTf2/F2uQwdYl8dZMSXq5BJrGk7u00QCUZomNwwb8/Gm3UCTbxFbeU lk1096TpSVbI25y6FWRBa8tlpSJoMn7mIH6Dzjblt0s5OATb94ylEStPofz2R6s0u1qBDgAOT gFNzIx1uAm3Uo51wSHsjIOOnP5td95EQgOW7MH8TEMHi+4pWCaXZvtSzhbIVvXYmHe3eO0YNM zL764RTUvmVuIS0vcAoLxeB8fVu0BpNdHoNgE4a7hPxTYzMXDZRA40UFHdC1gQ+AR4KmnfqtC CVmrf5+sUdrvh+cN3PRC7pHl9S0AAZT5jbaeveyPseh25PS3qDhuqxTv6Es8jlqmkqs7LBxdf zloXn12738222UOHxds6MzJMdnDTtNfXODsCW1T/cRLJFmyqo6mXQAMXGNWadMgK91g8NkJUp g4CE0/U4OrnMk4/K9QJy93u0kE0Q8ly/CwNSbTVY4yDMTSAUDXpzL0jexdUUzMHxf7YxyYh+O RfQeh36WZAN2FDoQTc/CCRkO4wDzhOdA9ZdfeIE4ibFQ1oDJNMZObaVJaGbTXkoHmgmlhqFLk kr0L5Z+3G5sFsTAtlRLLhfMzYrQcMxTIMjUa3vDM5Hk6PNBxDqYdlfc8cEQmaD52tb9mApx4i 3LODsoQu0i6lH1twJ Archived-At: Subject: Re: [xml2rfc] https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml timing out X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 13:23:53 -0000 On 16.04.2020 14:41, Carsten Bormann wrote: > I generally have more luck with xml2rfc.tools.ietf.org; saves one 302 an= d reduces two SPOFs to one SPOF. > ... Understood. It's just that I'm running a large test suite against historic documents, and these are really not supposed to break, right? Best regards, Julian From nobody Thu Apr 16 07:15:37 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4693A093D for ; Thu, 16 Apr 2020 07:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je5vo8Z6_GNW for ; Thu, 16 Apr 2020 07:15:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1303A0938 for ; Thu, 16 Apr 2020 07:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1587046524; bh=FeGJfKOS2Gc0wQl8SVKCJ/7JqqeOFExDtrNSzLYEBVc=; h=X-UI-Sender-Class:Subject:From:To:Cc:References:Date:In-Reply-To; b=bufEf7I+AYo+5QU82DLgoSwMYFg4D9216cNJWrsLuX661LywvPnkPLeXMUKN2oY6a Tzyi4fQJF91cHqmOxBFKrY5GBNkz4Tq1Voc1rfBgV6J/kJn7ibbSENI9AVio3J9hmx pbOOQ6DW7gDiZl3AtXxo6ivxmq4Jmup4ilCicWdw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([217.91.35.233]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mr9G2-1iw3zh4730-00oCgg; Thu, 16 Apr 2020 16:15:24 +0200 From: Julian Reschke To: Carsten Bormann Cc: "xml2rfc@ietf.org" References: <7fb6223c-7182-48c3-7c95-3773c3187b03@gmx.de> Message-ID: <441d407f-7591-ca6e-dab7-04c1153362a5@gmx.de> Date: Thu, 16 Apr 2020 16:15:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:jyFPvPqewJNxHUFg0mGAgwF52HHXLEtik3uFhRx5TdbyYGQFaPR gzrbRTGdm/SFngJL7B5gAjBrVyqDEg5E62hAoldCB731DP5YOq5Ul0I++DM6q/C2YglcGeO 0swxGfuT8tyCnUHfpdlG3YycF5wVhKdL9Pn/3U63ZabJ0VH1bv3kzh2Q+WmsnMI2dKfqstF QddmdTVbxNcjE+f6fs+HA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Pqq9lDcHXkM=:Fme/eFpSZuxhV+A9d9lWQk gBs7iKmTTL0KxmshPyQvoWgkaQsfGEhR8ih0OtOB4sFzYde8Kex473d3jAVUZOzVMyFJXZFvD mdHWmAAH65pNsEpJy+jHJ4p2iAZGWRooEuKofBwZ9ltYyiUIoARpf3hawAaqMA3bKTl7TQ/Mu n4gvROFK3i+Gt9+aDelaYPwzmKd8oBAa8C9YV7z3vO4jS1AKrhOEsVRol9sKZa+xwSbGZbnMm htwOyidEdmZmqVksCtiWTA5lX0zpDtDlLwm9ciGm19JbFXfyJzm0kgfOt0SlhwRiSGH8dS7eq 9isr1TG+wITufdZTmctjwFzf51SuGzHPpV4YcBTKnCo8Hgk5ofgsp90bd/28C0y08OomIrr84 61+2MzccklTEucI0JjOwzAZQkgbFT3yhxkh2ZzuLBFZlrIslJTOYpEVvWGgKPuXa1yxMD5cpq EjWCy80+dNFtCUDacy/ILD28ciC07D+zDk4KzVsM2k+EKf6ez0woFU3oTPBBwXbvjyAfX3KtG +n7EciB5g7VgmAq5GboGgkyPA4yaygvLaZibpWO+fw5Qc6rZkwSwQAIR/H41T9CBUrYG12NZz Kk1KQDLO75BQBI6izyz8veHSIHprAxa3EBjWm+cp9xKmkIeZR901xeZogOkGNdKMV57G+teZS KMzteWp20VWnIiDbVZ73fOa/Vu4cwCZWLeP7ItXtDX55q4GrV8jlVNyH7LxU89irT4Ie4ipXX BvK0AI1Qjbn3YP2NcutXU3lQsrKYQTE43P3g2q/WR+Han8PoF/OGDEFsC4lEOhYwaVYMEVtAh bp/Pg7fTzgiajlvC2MPFc28oHNSdOMItqPSfnGQQAvUrJHTt/DMsDYYenoOX03ZxQBHoixQn8 YmEhqQ99rvf1XZR7i3d9N+KBmSBnX4mVK7Mh1pLdmbp97YfjIPGSv1T6EUnTcDzw/SVaKvGuQ 9hnpoYOdtS1bBTnls8bmTfzwpRM7PbgCK6mGQubMYQ/N9yy7esr3DGsMN5aSWvmA09WDcrZHg gCykitozbisBHuBYpTSYvdpQIdMAfo7odza1I90nWIdo6HQO5dtrXKHT9UCodGUgFH8D6q7xe ZN6ezRu5KaFzc8YB250rAQHS46/UAyiXk+8inkyScnE+pTIkFmrFpugrZQmbD8djSsb6W70nI TtmIuC8d6Wi+WPlENFxDpADPkb6AdfH+thB6WWx198jqtMeDt0cIzsKgSHDndk41Vy44m//SG 0Pg8BiIbCDrn+SgKB Archived-At: Subject: Re: [xml2rfc] https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml timing out X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 14:15:36 -0000 On 16.04.2020 15:23, Julian Reschke wrote: > On 16.04.2020 14:41, Carsten Bormann wrote: >> I generally have more luck with xml2rfc.tools.ietf.org; saves one 302 >> and reduces two SPOFs to one SPOF. >> ... > > Understood. > > It's just that I'm running a large test suite against historic > documents, and these are really not supposed to break, right? > > Best regards, Julian FWIW, https://datatracker.ietf.org resolves to the same IP and times out as well. Best regards, Julian From nobody Thu Apr 16 07:43:13 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC053A09EE for ; Thu, 16 Apr 2020 07:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43HLTyQyWItQ for ; Thu, 16 Apr 2020 07:43:09 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD613A09EC for ; Thu, 16 Apr 2020 07:43:08 -0700 (PDT) Received: from [192.168.217.150] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49325R1F36z10Qx; Thu, 16 Apr 2020 16:43:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <441d407f-7591-ca6e-dab7-04c1153362a5@gmx.de> Date: Thu, 16 Apr 2020 16:43:06 +0200 Cc: "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 608740986.485429-e4494cefda85bb9001f3b69b8d5f96ad Content-Transfer-Encoding: quoted-printable Message-Id: <5D992E37-26B5-49FC-8EE4-68279362FE80@tzi.org> References: <7fb6223c-7182-48c3-7c95-3773c3187b03@gmx.de> <441d407f-7591-ca6e-dab7-04c1153362a5@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [xml2rfc] https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml timing out X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 14:43:12 -0000 > FWIW, https://datatracker.ietf.org resolves to the same IP Right. > and times out > as well. WFM. Did you traceroute? Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 16 08:21:16 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFDB3A0AB9 for ; Thu, 16 Apr 2020 08:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMmORpuuZuCU for ; Thu, 16 Apr 2020 08:21:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66E503A0ABC for ; Thu, 16 Apr 2020 08:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1587050461; bh=yI8FV3pDMWKvfH1YPPjLCL7s6973nN7rBEDOebN4YbE=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=KoxFuWuNvPPLYpAUKF+wGvByYtmu4guJ8WEpaBy50xB4U/5o2ONWZIyvurobf1Jw1 lwi1iMW5QRqmFV/umZmHYHM7eQhWr+AeLfOyGTC5ngjWnM9J9GiJ4OwPKNH2NesUGM p82MSRJA+rOmBmCpTxb0iyL3Rac8uOIacqBBHW8o= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([93.203.251.129]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N6bk4-1jBN1m42nu-0187Ra; Thu, 16 Apr 2020 17:21:01 +0200 To: Carsten Bormann Cc: "xml2rfc@ietf.org" References: <7fb6223c-7182-48c3-7c95-3773c3187b03@gmx.de> <441d407f-7591-ca6e-dab7-04c1153362a5@gmx.de> <5D992E37-26B5-49FC-8EE4-68279362FE80@tzi.org> From: Julian Reschke Message-ID: Date: Thu, 16 Apr 2020 17:20:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <5D992E37-26B5-49FC-8EE4-68279362FE80@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:7uHGyAOBCFm2dGrUPmJsuaEbvqV5i0x7kaEgJWGCE/1GZz87oDX kTjoBRHw7F+YumXHR7jv9uZthaci37F2sBYSK9iWnXiRIWqCYJ7QjazWFSKRj79d8YQCGnA YTqnRN7LN+A62PURxjZ27LCFP0+A9VqLKzP4ycRMbCpQApAF/hM8Zl3J26XV/nh617bfkGA xzzpWUsz07QFQs6RfiI8Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:A83ZdsMXpdw=:8mXEJN836mX+rw9lTItcKS Tq++dEywEqIs0/86VoTFg3nGT1nX93PWmbpdlXXaDGkb63wN5/5rXez9VBaENLOKdK6v4uZmr gDf548PUq3qpiAGdBqK+r4msPW+5Eabmkx6EjbCvi6ReDwVjo4kX1pjEbmvamEA6JYiI1uRzJ 2qlF48KVTukGJXQzHWwavqt7rINHvLuBZLkJWWd0F19Vf2i1Jm30IVWd6/mdnEA9lS90VKGf/ 7hBjeANnQ/rK85XYc569tmKqYDvbJPr3SnWVzMlXDw35z16UbeKMc614690aRPMUP5J2nNVEu mklLG3jzGc3kKVQmcv1QY56obr5cd00FHf/tQyzMaUjVL8rzt+qQOiGGfd9n8SJZ5hO8xhYNL XatRFCf1baVHOHIn2vadNvrNgAC4UZbXtFD+ogNXUFMTdChPgDIqy4tYIOWpoDBQcyV85ZQuP RAjzQ/Lds7Plpx3uWTGmL3L3aCrGnrziJlPAQreFLZRmnFrC6FG9T3Twaj7QJ9IemACh8PXWb 74MmB9np+0gbTxCZLSxf8nfRz/TJz20kQ2RdlVHIJXIoLUMODwBwnJRWeRqu2uMx1e4ZST95/ O6zb8lRUsyiql1djT1qat32DKTMvo+jDHqZIQGKkFo3//OsD51XDr1xgmDAH5ruopfu6rUv7D HoqmZi57mNVSjbQ2vuKU3ZkZAb7DGnV/yRnBj6I9LZJs/Nyb3EctqlcJwDr55CG9367ZJaeZ3 7Pw+LKJVXIBBYo+Lv8lcKtRxv913K4Vvj0pPrkxsNrjK/uAWEQRq/nG5RHC71T7oqWzTnSJhf 9umW3nOvFy/RUJRBz8skfzj6xscdKS1wpHjNfxk0Pf/+/Ci7g5zrL707kGZQ/FrSBZIPbQiOm /8aDbRap/yES0l4vA+u10KfhuHH5zBIh6otEt5bnVAtvnqAvEnnmGoIbESJBuxzR0mpkHv3C/ 5k5YdA4WtY80lpMzLMIbIwG+ffo3kp1vDy/e0D8piL9dWVX4UJwzqWbAPVPY7dEGPO42Y8qJV 2vDm37rmyTn9w9vRW/wNYPnWuXQnWdRewRXoHLwH4tZfTLN6SWjIDTDHiAFC4oaWb+U0bvoC4 YPb5Px6dodgRqIhL/tyj0JdvgGZqZ/4prfdIvMd6/ydz881/y9znDvhVccpUUTgIbc8GJYvtB mMaZWOLiyFypPnSfiy4/634nDznoGLcuTkBye/b53Dte7TQXqA6q/QGJKMGkDx3+Ph00ab4IF gAw4hfl4UN+a6O0gm Archived-At: Subject: Re: [xml2rfc] https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml timing out X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 15:21:14 -0000 On 16.04.2020 16:43, Carsten Bormann wrote: > >> FWIW, https://datatracker.ietf.org resolves to the same IP > > Right. > >> and times out >> as well. > > WFM. Did you traceroute? I did not. I just moved, and now I get a success (over a German Telekom network). The NW over which it was failing IMHO is UnityMedia. Best regards, Julian From nobody Fri Apr 17 12:07:19 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6CF3A0908 for ; Fri, 17 Apr 2020 12:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRRcG5fLOjFB for ; Fri, 17 Apr 2020 12:07:17 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB68E3A0902 for ; Fri, 17 Apr 2020 12:07:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4A7146224B for ; Fri, 17 Apr 2020 15:07:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QIG4ECGtOrm7 for ; Fri, 17 Apr 2020 15:07:12 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id EE73F621F2 for ; Fri, 17 Apr 2020 15:07:09 -0400 (EDT) To: "xml2rfc@ietf.org" From: Robert Moskowitz Message-ID: <45ac98cd-1a7e-0494-ba58-9a4a52f8469a@htt-consult.com> Date: Fri, 17 Apr 2020 15:07:01 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [xml2rfc] Style Format in
    X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 19:07:18 -0000 The FAQ https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor20 shows: REQ1: REQ2:  is   REQ3: How do I specify this  with in the new
      method? thanks From nobody Fri Apr 17 12:21:30 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE2F3A10B6 for ; Fri, 17 Apr 2020 12:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2bnmUIdk3B3 for ; Fri, 17 Apr 2020 12:21:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2673A10B3 for ; Fri, 17 Apr 2020 12:21:27 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:61038 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jPWYI-0002qi-Jz; Fri, 17 Apr 2020 12:21:27 -0700 To: Robert Moskowitz , "xml2rfc@ietf.org" References: <45ac98cd-1a7e-0494-ba58-9a4a52f8469a@htt-consult.com> From: Henrik Levkowetz Message-ID: <53e30621-720c-eafe-de14-5b3c3cc97987@levkowetz.com> Date: Fri, 17 Apr 2020 21:20:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <45ac98cd-1a7e-0494-ba58-9a4a52f8469a@htt-consult.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="X8cW9ipOiOtb86dFVc3LRpsHhUoPc4scF" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, rgm@htt-consult.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Style Format in
        X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 19:21:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X8cW9ipOiOtb86dFVc3LRpsHhUoPc4scF Content-Type: multipart/mixed; boundary="mFj6JDrFmjuf1MdOaufP22hg0cBb0Xkbe"; protected-headers="v1" From: Henrik Levkowetz To: Robert Moskowitz , "xml2rfc@ietf.org" Message-ID: <53e30621-720c-eafe-de14-5b3c3cc97987@levkowetz.com> Subject: Re: [xml2rfc] Style Format in
          References: <45ac98cd-1a7e-0494-ba58-9a4a52f8469a@htt-consult.com> In-Reply-To: <45ac98cd-1a7e-0494-ba58-9a4a52f8469a@htt-consult.com> --mFj6JDrFmjuf1MdOaufP22hg0cBb0Xkbe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bob, On 2020-04-17 21:07, Robert Moskowitz wrote: > The FAQ >=20 > https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor20 >=20 > shows: >=20 > REQ1: > REQ2: is > REQ3: >=20 > How do I specify this with in the new
            method? Use the 'type' attribute, https://tools.ietf.org/html/rfc7991#section-2.3= 4.5:
            1. ....
            2. ....
            Best regards, Henrik --mFj6JDrFmjuf1MdOaufP22hg0cBb0Xkbe-- --X8cW9ipOiOtb86dFVc3LRpsHhUoPc4scF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl6aAZIACgkQTptXS4+7 FxqZiw//e3GG838aJc1Zgh60/CjbfgQex3en7oVzSrIteTCWfDxAdK0c38BPYOld pMukUwEJ9xhrTOK3RaPlj0UaWJUZLoNcJ1dokiXoKP3r43/pdzwTXQyFGNCAMivA DBc4TaEm78UFmQYr1VJRshE3E7ObZWHQ97RMqrWLYekdUKaJbwQl/j3EX8zaIYdM eFTEqay7P1Ss/IumBc/r9+NnN4URVj089vX2p0ltbfK7VYaM2T3Ce6XCzPCsnvTT XbXv0ldnHypC0o3Lu9WDvpomY1BSkB3+/5vH5TdULtEmLVI2tDZBjPLgvZXW9vXM T66M1uECUyWnrQtWzpmCJMJIiNMK1TIElpnnXZ/6iM+iPDoVis6SbdqM2gxSoAgo UMRw2d6G0D808Z6Cn5nHtYIa6EyftYk0vTp8/Livfy4R2zHD74cR+/qNgHxDsnGF mKRNRDibTKTUeo7bQ/fMWzKs4l7qnashCOm1JZI/daB0riyYlnmLq+5pCrmVrBHT 8UQNO/JttR6e8DNAiU1PZS8ZRuravDmNL+gzGr8xneetGU9WpfPJYBCo47pDYzb4 Pqg7h/6qG5Nx9iM5JQ2Bw/YmJJdgE5N7rtovMn5Yt+6FL03gk2rOZXr7Wly8BcXx lXKJ5ar3kpkQomUmvDYWrIOBGEg3t+cXs8hH18VONAGbETIEegA= =vjdi -----END PGP SIGNATURE----- --X8cW9ipOiOtb86dFVc3LRpsHhUoPc4scF-- From nobody Fri Apr 17 12:22:37 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7253A10EE for ; Fri, 17 Apr 2020 12:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAMxKhVXSJkr for ; Fri, 17 Apr 2020 12:22:33 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1363A10EC for ; Fri, 17 Apr 2020 12:22:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 57ABB203E7A; Fri, 17 Apr 2020 12:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYCYjiWj0R4R; Fri, 17 Apr 2020 12:18:37 -0700 (PDT) Received: from [IPv6:2605:e000:1524:de:edf9:c2f6:f515:e03b] (unknown [IPv6:2605:e000:1524:de:edf9:c2f6:f515:e03b]) by c8a.amsl.com (Postfix) with ESMTPSA id 174FC203E77; Fri, 17 Apr 2020 12:18:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sandy Ginoza In-Reply-To: <45ac98cd-1a7e-0494-ba58-9a4a52f8469a@htt-consult.com> Date: Fri, 17 Apr 2020 12:22:32 -0700 Cc: "xml2rfc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <45ac98cd-1a7e-0494-ba58-9a4a52f8469a@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] Style Format in
              X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 19:22:36 -0000 Hi Robert, > On Apr 17, 2020, at 12:07 PM, Robert Moskowitz = wrote: >=20 > The FAQ >=20 > https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor20 >=20 > shows: >=20 > REQ1: > REQ2: is > REQ3: >=20 > How do I specify this with in the new
                method? I believe this should work:
                  See = = . Thanks, Sandy=20 >=20 > thanks >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Sat Apr 18 13:56:13 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C0C3A113C for ; Sat, 18 Apr 2020 13:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XudJTR40a9pW for ; Sat, 18 Apr 2020 13:56:10 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1BC73A113B for ; Sat, 18 Apr 2020 13:56:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jPuVU-0003cS-JX for xml2rfc@ietf.org; Sat, 18 Apr 2020 20:56:08 +0000 Date: Sat, 18 Apr 2020 13:56:08 -0700 Message-ID: From: Randy Bush To: XML2RFC Interest Group User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [xml2rfc] unreachable? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 20:56:12 -0000 Error: Failure fetching URL https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8481 (HTTPSConnectionPool(host='xml2rfc.tools.ietf.org', port=443): Max retries exceeded with url: /public/rfc/bibxml/reference.RFC.8481 (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 51] Network is unreachable',))) % ping xml2rfc.ietf.org PING ietf.org (4.31.198.44): 56 data bytes 64 bytes from 4.31.198.44: icmp_seq=0 ttl=56 time=7.075 ms 64 bytes from 4.31.198.44: icmp_seq=1 ttl=56 time=7.184 ms From nobody Sat Apr 18 14:33:12 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0202F3A1213 for ; Sat, 18 Apr 2020 14:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVXDHmh-zuER for ; Sat, 18 Apr 2020 14:33:07 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E3C3A1211 for ; Sat, 18 Apr 2020 14:33:06 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 494R5R4qCVz10LK; Sat, 18 Apr 2020 23:32:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Sat, 18 Apr 2020 23:32:57 +0200 Cc: XML2RFC Interest Group X-Mao-Original-Outgoing-Id: 608938377.267346-e032aefe7b186b208717f8ac811f6c30 Content-Transfer-Encoding: quoted-printable Message-Id: <4BA73B0D-3620-4BDE-B69F-43F16D0658D4@tzi.org> References: To: Randy Bush X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [xml2rfc] unreachable? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 21:33:10 -0000 Not eally unreachable, but connection refused on the tools server for = me: $ curl -LI https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8481 HTTP/1.1 302 Found Date: Sat, 18 Apr 2020 21:28:07 GMT Server: Apache Location: = https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8481 Content-Type: text/html; charset=3Diso-8859-1 curl: (7) Failed to connect to xml2rfc.tools.ietf.org port 443: = Connection refused $ host xml2rfc.tools.ietf.org xml2rfc.tools.ietf.org is an alias for durif.tools.ietf.org. durif.tools.ietf.org has address 4.31.198.61 durif.tools.ietf.org has IPv6 address 2001:1900:3001:11::3d $ ping xml2rfc.tools.ietf.org PING durif.tools.ietf.org (4.31.198.61): 56 data bytes 64 bytes from 4.31.198.61: icmp_seq=3D0 ttl=3D57 time=3D213.952 ms 64 bytes from 4.31.198.61: icmp_seq=3D1 ttl=3D57 time=3D235.747 ms ^C --- durif.tools.ietf.org ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev =3D 213.952/224.850/235.747/10.897 ms $ telnet xml2rfc.tools.ietf.org 80 Trying 4.31.198.61... telnet: Unable to connect to remote host: Connection refused $ telnet xml2rfc.tools.ietf.org 443 Trying 4.31.198.61... telnet: Unable to connect to remote host: Connection refused $ Gr=C3=BC=C3=9Fe, Carsten > On 2020-04-18, at 22:56, Randy Bush wrote: >=20 > Error: Failure fetching URL = https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8481 = (HTTPSConnectionPool(host=3D'xml2rfc.tools.ietf.org', port=3D443): Max = retries exceeded with url: /public/rfc/bibxml/reference.RFC.8481 (Caused = by NewConnectionError(': Failed to establish a new connection: [Errno 51] = Network is unreachable',))) >=20 > % ping xml2rfc.ietf.org > PING ietf.org (4.31.198.44): 56 data bytes > 64 bytes from 4.31.198.44: icmp_seq=3D0 ttl=3D56 time=3D7.075 ms > 64 bytes from 4.31.198.44: icmp_seq=3D1 ttl=3D56 time=3D7.184 ms >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Sat Apr 18 19:31:16 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AB93A16A2 for ; Sat, 18 Apr 2020 19:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoHuzd4Le3Wq for ; Sat, 18 Apr 2020 19:31:12 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38C93A16A0 for ; Sat, 18 Apr 2020 19:31:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id E409F62156; Sat, 18 Apr 2020 22:31:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BModSivarn02; Sat, 18 Apr 2020 22:31:05 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 489506213A; Sat, 18 Apr 2020 22:31:05 -0400 (EDT) To: Sandy Ginoza Cc: "xml2rfc@ietf.org" References: <45ac98cd-1a7e-0494-ba58-9a4a52f8469a@htt-consult.com> From: Robert Moskowitz Message-ID: Date: Sat, 18 Apr 2020 22:30:57 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Style Format in
                    X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 02:31:14 -0000 On 4/17/20 3:22 PM, Sandy Ginoza wrote: > Hi Robert, > >> On Apr 17, 2020, at 12:07 PM, Robert Moskowitz wrote: >> >> The FAQ >> >> https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor20 >> >> shows: >> >> REQ1: >> REQ2: is >> REQ3: >> >> How do I specify this with in the new
                      method? > I believe this should work: >
                        > > See . > > Thanks, > Sandy > I missed this newer FAQ, thanks for that pointer. Now how do I get the list indented a bit.  In my case, where I really would like the list in a tab:    
                                 
                        1.             a static, manufacturer assigned, hardware serial number per             ANSI/CTA-2063-A "Small Unmanned Aerial System Serial             Numbers" .        
                          2.        
                        2.             a CAA assigned (presumably static) ID.        
                          3.        
                        3.             a UAS Traffic Management (UTM) system assigned UUID , which can but need not             be dynamic.        
                          4.    
                        From nobody Mon Apr 20 17:52:48 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411CB3A1440 for ; Mon, 20 Apr 2020 17:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uSv-3vh4Elo for ; Mon, 20 Apr 2020 17:52:43 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99EB03A142F for ; Mon, 20 Apr 2020 17:52:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 509CE204C19; Mon, 20 Apr 2020 17:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ_qsQacViPA; Mon, 20 Apr 2020 17:52:17 -0700 (PDT) Received: from [IPv6:2605:e000:1524:de:b08f:c2e0:ddd:2fdd] (unknown [IPv6:2605:e000:1524:de:b08f:c2e0:ddd:2fdd]) by c8a.amsl.com (Postfix) with ESMTPSA id 0DBB5204C18; Mon, 20 Apr 2020 17:52:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sandy Ginoza In-Reply-To: Date: Mon, 20 Apr 2020 17:49:14 -0700 Cc: "xml2rfc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <45ac98cd-1a7e-0494-ba58-9a4a52f8469a@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] Style Format in
                          X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 00:52:47 -0000 Hi Robert,=20 > On Apr 18, 2020, at 7:30 PM, Robert Moskowitz = wrote: >=20 >=20 >=20 > On 4/17/20 3:22 PM, Sandy Ginoza wrote: >> Hi Robert, >>=20 >>> On Apr 17, 2020, at 12:07 PM, Robert Moskowitz = wrote: >>>=20 >>> The FAQ >>>=20 >>> https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor20 >>>=20 >>> shows: >>>=20 >>> REQ1: >>> REQ2: is >>> REQ3: >>>=20 >>> How do I specify this with in the new
                            method? >> I believe this should work: >>
                              >>=20 >> See = = . >>=20 >> Thanks, >> Sandy >>=20 >=20 > I missed this newer FAQ, thanks for that pointer. >=20 > Now how do I get the list indented a bit. In my case, where I really = would like the list in a tab: Wrapping the
                                within
                                  may achieve = the indentation you desire. It=E2=80=99s not clear whether this is = considered good practice, but that is the only way we are aware of to = get added indentation. =20 Thanks, Sandy=20 >=20 >
                                    >
                                  1. > a static, manufacturer assigned, hardware serial number = per > ANSI/CTA-2063-A "Small Unmanned Aerial System Serial > Numbers" . >
                                    2. >
                                  2. > a CAA assigned (presumably static) ID. >
                                    3. >
                                  3. > a UAS Traffic Management (UTM) system assigned UUID target=3D"RFC4122" format=3D"default"/>, which can but = need not > be dynamic. >
                                    4. >
                                  >=20 >=20 From nobody Mon Apr 20 18:46:50 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B133A1508 for ; Mon, 20 Apr 2020 18:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIMD96dIkUaP for ; Mon, 20 Apr 2020 18:46:46 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7DB93A1506 for ; Mon, 20 Apr 2020 18:46:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id E10FC6212C; Mon, 20 Apr 2020 21:46:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DkS8x0uKjS7j; Mon, 20 Apr 2020 21:46:37 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 6F31C62123; Mon, 20 Apr 2020 21:46:35 -0400 (EDT) To: Sandy Ginoza Cc: "xml2rfc@ietf.org" References: <45ac98cd-1a7e-0494-ba58-9a4a52f8469a@htt-consult.com> From: Robert Moskowitz Message-ID: Date: Mon, 20 Apr 2020 21:46:26 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Style Format in
                                    X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 01:46:49 -0000 Doesn't work... On 4/20/20 8:49 PM, Sandy Ginoza wrote: > Hi Robert, > >> On Apr 18, 2020, at 7:30 PM, Robert Moskowitz wrote: >> >> >> >> On 4/17/20 3:22 PM, Sandy Ginoza wrote: >>> Hi Robert, >>> >>>> On Apr 17, 2020, at 12:07 PM, Robert Moskowitz wrote: >>>> >>>> The FAQ >>>> >>>> https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor20 >>>> >>>> shows: >>>> >>>> REQ1: >>>> REQ2: is >>>> REQ3: >>>> >>>> How do I specify this with in the new
                                      method? >>> I believe this should work: >>>
                                        >>> >>> See . >>> >>> Thanks, >>> Sandy >>> >> I missed this newer FAQ, thanks for that pointer. >> >> Now how do I get the list indented a bit. In my case, where I really would like the list in a tab: > Wrapping the
                                          within
                                            may achieve the indentation you desire. It’s not clear whether this is considered good practice, but that is the only way we are aware of to get added indentation. > > Thanks, > Sandy
                                                 
                                                       
                                              1.             a static, manufacturer assigned, hardware serial number per             ANSI/CTA-2063-A "Small Unmanned Aerial System Serial             Numbers" .        
                                                2.        
                                              2.             a CAA assigned (presumably static) ID.        
                                                3.        
                                              3.             a UAS Traffic Management (UTM) system assigned UUID , which can but need not             be dynamic.        
                                                4.    
                                            results in: xml2rfc --v3 draft-card-drip-arch-02.xml draft-card-drip-arch-02.xml(144): Error: Did not expect element ol there, at /rfc/middle/section[1]/ul[2]/ol draft-card-drip-arch-02.xml(144): Error: Element ul has extra content: ol, at /rfc/middle/section[1]/ul[2]/ol draft-card-drip-arch-02.xml(15): Error: Invalid document before running preptool. Unable to complete processing draft-card-drip-arch-02.xml Oh well.  Indenting, IMHO would be nice.  Here is what I am getting without the extra indent:    [F3411-19] specifies 3 UAS ID types.    Type 1:  a static, manufacturer assigned, hardware serial number per             ANSI/CTA-2063-A "Small Unmanned Aerial System Serial             Numbers" [CTA2063A].    Type 2:  a CAA assigned (presumably static) ID.    Type 3:  a UAS Traffic Management (UTM) system assigned UUID             [RFC4122], which can but need not be dynamic.    The EU allows only Type 1; the US allows Types 1 and 3, but requires It would read better if the Type... list were indented. From nobody Mon Apr 20 19:35:56 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50A03A15B8 for ; Mon, 20 Apr 2020 19:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QAt9tkiKoq7 for ; Mon, 20 Apr 2020 19:35:49 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9007E3A15C2 for ; Mon, 20 Apr 2020 19:35:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 65C3D204D18; Mon, 20 Apr 2020 19:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0wCw8aUU7pH; Mon, 20 Apr 2020 19:35:21 -0700 (PDT) Received: from [IPv6:2605:e000:1524:de:b08f:c2e0:ddd:2fdd] (unknown [IPv6:2605:e000:1524:de:b08f:c2e0:ddd:2fdd]) by c8a.amsl.com (Postfix) with ESMTPSA id 0C470204D16; Mon, 20 Apr 2020 19:35:21 -0700 (PDT) From: Sandy Ginoza Message-Id: <743B67E2-040F-475A-99F1-B6D0C95B9D44@amsl.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CAAFF21F-F3FB-4B62-B156-01A784D05F64" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 20 Apr 2020 19:32:17 -0700 In-Reply-To: Cc: "xml2rfc@ietf.org" To: Robert Moskowitz References: <45ac98cd-1a7e-0494-ba58-9a4a52f8469a@htt-consult.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] Style Format in
                                              X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 02:35:54 -0000 --Apple-Mail=_CAAFF21F-F3FB-4B62-B156-01A784D05F64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 20, 2020, at 6:46 PM, Robert Moskowitz = wrote: >=20 > Doesn't work=E2=80=A6 See below. >=20 > On 4/20/20 8:49 PM, Sandy Ginoza wrote: >> Hi Robert, >>=20 >>> On Apr 18, 2020, at 7:30 PM, Robert Moskowitz = wrote: >>>=20 >>>=20 >>>=20 >>> On 4/17/20 3:22 PM, Sandy Ginoza wrote: >>>> Hi Robert, >>>>=20 >>>>> On Apr 17, 2020, at 12:07 PM, Robert Moskowitz = wrote: >>>>>=20 >>>>> The FAQ >>>>>=20 >>>>> https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor20 >>>>>=20 >>>>> shows: >>>>>=20 >>>>> REQ1: >>>>> REQ2: is >>>>> REQ3: >>>>>=20 >>>>> How do I specify this with in the new
                                                method? >>>> I believe this should work: >>>>
                                                  >>>>=20 >>>> See = = . >>>>=20 >>>> Thanks, >>>> Sandy >>>>=20 >>> I missed this newer FAQ, thanks for that pointer. >>>=20 >>> Now how do I get the list indented a bit. In my case, where I = really would like the list in a tab: >> Wrapping the
                                                    within
                                                      may = achieve the indentation you desire. It=E2=80=99s not clear whether this = is considered good practice, but that is the only way we are aware of to = get added indentation. >>=20 >> Thanks, >> Sandy >=20 >
                                                        >
                                                          >
                                                        1. > a static, manufacturer assigned, hardware serial number = per > ANSI/CTA-2063-A "Small Unmanned Aerial System Serial > Numbers" . >
                                                          2. >
                                                        2. > a CAA assigned (presumably static) ID. >
                                                          3. >
                                                        3. > a UAS Traffic Management (UTM) system assigned UUID target=3D"RFC4122" format=3D"default"/>, which can but = need not > be dynamic. >
                                                          4. >
                                                        >
                                                      >=20 > results in: >=20 > xml2rfc --v3 draft-card-drip-arch-02.xml > draft-card-drip-arch-02.xml(144): Error: Did not expect element ol = there, at /rfc/middle/section[1]/ul[2]/ol > draft-card-drip-arch-02.xml(144): Error: Element ul has extra content: = ol, at /rfc/middle/section[1]/ul[2]/ol > draft-card-drip-arch-02.xml(15): Error: Invalid document before = running preptool. > Unable to complete processing draft-card-drip-arch-02.xml You can try adding
                                                    • ; I tested this and believe it works:
                                                        1. = =20 a static, manufacturer assigned, hardware serial number per = =20 ANSI/CTA-2063-A "Small Unmanned Aerial System Serial = =20 Numbers". = =20
                                                        2. = =20 a CAA assigned (presumably static) ID. = =20
                                                      > Oh well. Indenting, IMHO would be nice. Here is what I am getting = without the extra indent: Imho, the list below is clear; no indentation needed. =20 >=20 > [F3411-19] specifies 3 UAS ID types. >=20 > Type 1: a static, manufacturer assigned, hardware serial number = per > ANSI/CTA-2063-A "Small Unmanned Aerial System Serial > Numbers" [CTA2063A]. >=20 > Type 2: a CAA assigned (presumably static) ID. >=20 > Type 3: a UAS Traffic Management (UTM) system assigned UUID > [RFC4122], which can but need not be dynamic. >=20 > The EU allows only Type 1; the US allows Types 1 and 3, but = requires >=20 >=20 > It would read better if the Type... list were indented. >=20 --Apple-Mail=_CAAFF21F-F3FB-4B62-B156-01A784D05F64 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

                                                      On Apr 20, 2020, at 6:46 PM, = Robert Moskowitz <rgm@htt-consult.com> wrote:

                                                      Doesn't work=E2=80=A6

                                                      See below.



                                                      On 4/20/20 8:49 PM, Sandy Ginoza wrote:
                                                      Hi Robert,

                                                      On Apr = 18, 2020, at 7:30 PM, Robert Moskowitz <rgm@htt-consult.com>= wrote:



                                                      On = 4/17/20 3:22 PM, Sandy Ginoza wrote:
                                                      Hi Robert,

                                                      On Apr 17, 2020, at = 12:07 PM, Robert Moskowitz <rgm@htt-consult.com> wrote:

                                                      The FAQ

                                                      https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor20

                                                      shows:

                                                      REQ1:
                                                      REQ2:  is   <list style=3D"format = REQ%d:">
                                                      REQ3:

                                                      How do I = specify this  with in the new <ol> method?
                                                      I believe this should work:
                                                      <ol = type=3D"REQ%d:">

                                                      See <https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#name-us= ing-lists>.

                                                      Thanks,
                                                      Sandy

                                                      I missed this = newer FAQ, thanks for that pointer.

                                                      Now how = do I get the list indented a bit.  In my case, where I really would = like the list in a tab:
                                                      Wrapping the = <ol> within <ul empty=3D=E2=80=9Ctrue=E2=80=9D> may achieve = the indentation you desire.  It=E2=80=99s not clear whether this is = considered good practice, but that is the only way we are aware of to = get added indentation.

                                                      Thanks,
                                                      Sandy

                                                      <ul = empty=3D"true">
                                                          <ol type=3D"Type = %d:">
                                                              = <li>
                                                              =     a static, manufacturer assigned, hardware serial = number per
                                                              =     ANSI/CTA-2063-A "Small Unmanned Aerial System = Serial
                                                              =     Numbers" <xref target=3D"CTA2063A" = format=3D"default"/>.
                                                          =     </li>
                                                          =     <li>
                                                          =         a CAA assigned (presumably static) = ID.
                                                              </li>
                                                              <li>
                                                                  a = UAS Traffic Management (UTM) system assigned UUID <xref
                                                                  = target=3D"RFC4122" format=3D"default"/>, which can but need not
                                                                  be = dynamic.
                                                              = </li>
                                                          </ol>
                                                      </ul>

                                                      results in:

                                                      xml2rfc --v3 draft-card-drip-arch-02.xml
                                                      draft-card-drip-arch-02.xml(144): Error: Did not expect = element ol there, at /rfc/middle/section[1]/ul[2]/ol
                                                      draft-card-drip-arch-02.xml(144): Error: Element ul has extra = content: ol, at /rfc/middle/section[1]/ul[2]/ol
                                                      draft-card-drip-arch-02.xml(15): Error: Invalid document = before running preptool.
                                                      Unable to complete processing = draft-card-drip-arch-02.xml

                                                      You = can try adding <li>; I tested this and believe it = works:

                                                      <ul = empty=3D"true"><li>
                                                        =   <ol = type=3D"Type %d:">
                                                              <li>          =                     =                     =                     =                     =          
                                                                  a static, = manufacturer assigned, hardware serial number per       =                     =              
                                                                =   ANSI/CTA-2063-A "Small Unmanned Aerial System Serial    =                     =                     =    
                                                        =           Numbers".         =                     =                     =                     =                     =  
                                                        =       </li>
                                                        =       <li>                =                     =                     =                     =                     =    
                                                        =           a CAA assigned (presumably static) = ID.                    =                     =                     =  
                                                        =       </li>

                                                          </ol></li>
                                                      </ul>


                                                      Oh well.  = Indenting, IMHO would be nice.  Here is what I am getting without = the extra indent:

                                                      Imho, the list below is clear; no indentation = needed.  


                                                         = [F3411-19] specifies 3 UAS ID types.

                                                         Type 1:  a static, manufacturer assigned, = hardware serial number per
                                                                &nb= sp; ANSI/CTA-2063-A "Small Unmanned Aerial System Serial
                                                                &nb= sp; Numbers" [CTA2063A].

                                                         Type = 2:  a CAA assigned (presumably static) ID.

                                                         Type 3:  a UAS Traffic Management (UTM) = system assigned UUID
                                                                &nb= sp; [RFC4122], which can but need not be dynamic.

                                                         The EU allows only Type 1; the US allows Types 1 = and 3, but requires


                                                      It would = read better if the Type... list were indented.


                                                      = --Apple-Mail=_CAAFF21F-F3FB-4B62-B156-01A784D05F64-- From nobody Wed Apr 22 20:48:05 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3AF3A12B6; Wed, 22 Apr 2020 20:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cv77wKPO20-a; Wed, 22 Apr 2020 20:47:51 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962183A12B2; Wed, 22 Apr 2020 20:47:51 -0700 (PDT) Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from ) id 1jRSq7-0008Dn-Dd; Wed, 22 Apr 2020 20:47:51 -0700 To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org Cc: rfc-markdown@ietf.org Message-Id: From: Henrik Levkowetz Date: Wed, 22 Apr 2020 20:47:51 -0700 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc] New xml2rfc release: v2.44.0 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 03:47:55 -0000 Hi, This is an automatic notification about a new xml2rfc release, v2.44.0, generated when running the mkrelease script. Release notes: xml2rfc (2.44.0) ietf; urgency=medium * Added an '--unprep' switch and formatter to undo changes made by '--prep' which make a file unsuitable for continued editing. This will help the RPC when the .xml file received from draft authors for an upcoming RFC is in 'prepped' format. * Updated the v3 --expand formatter to expand external sourcecode and artwork, in addition to handling XIncludes. This should make it possible to produce single consolidated .xml files without using the --prep workaround. * Did some refactoring, moving the dispatch method that calls processing methods based on XPath expressions, and some other generic methods, into the V3 formatter base class. * Moved slugify() function, used in several writers, from v2v3 to utils.py. * Did a minor CSS tweak to improve orphan/widow handling of
                                                      elements. -- Henrik Levkowetz 22 Apr 2020 21:20:47 +0000 The preferred way to install xml2rfc is by doing 'pip install xml2rfc', and 'pip install --upgrade xml2rfc' to upgrade. If there are system- installed python modules which pip will not upgrade, you may have to use 'pip install --upgrade --no-deps xml2rfc' and install dependencies manually. The new version is also available through SVN checkout, with 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.44.0' Regards, Henrik (via the mkrelease script) From nobody Thu Apr 23 12:44:40 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA2D3A12BE for ; Thu, 23 Apr 2020 12:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWhlu1-Du1_H for ; Thu, 23 Apr 2020 12:44:36 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01B13A12BD for ; Thu, 23 Apr 2020 12:44:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jRhlz-0003x2-0p for xml2rfc@ietf.org; Thu, 23 Apr 2020 19:44:35 +0000 Date: Thu, 23 Apr 2020 12:44:34 -0700 Message-ID: From: Randy Bush To: XML2RFC Interest Group User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [xml2rfc] subsection failure X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 19:44:38 -0000 why does including a subsection give me Error: Unable to validate the XML document: draft-ymbk-sidrops-rpki-rov-timing.xml : Line 105: Element section content does not follow the DTD, expecting ((t | figure | texttable | iref)* , section*), got (t section t t t t t t t t ) make: *** [all] Error 1 if i pull it to a separate section it works. if i eliminte the paragraphs after the first it works. binary search elimination got me nothing
                                                      This document explores, and makes recommendations for, timing of Resource Public Key Infrastructure (RPKI) publication of ROV data, their propagation, and their use in Relying Parties (RP), caches and routers.
                                                      The RPKI supply chain from CAs to reach routers has a structure as follows: The authoritative data of the RPKI are published by a distributed set of servers, Certification Authorities, at the IANA, RIRs, NIRs, and ISPs (see ). The CAs publish their authoritative data in publicly accessible repositories which have a Publication Point (PP) for each CA. Relying Parties are a local set of one or more collected and verified caches of RPKI data which are collected from the PPs. Note that RPs can pull from other RPs, thereby creating a somewhat complex topology. Validating routers fetch data from local caches using the RPKI to Router Protocol, . Routers are clients of the caches. Validating routers MUST have a trust relationship with, and a trusted transport channel to, any RP(s) they use. specifies mechanisms for the router to assure itself of the authenticity of the cache and to authenticate itself to the cache.
                                                      As Resource Public Key Infrastructure (RPKI) based Route Origin Validation (ROV) becomes deployed in the Internet, the quality of the routing control plane, and hence timely and accurate delivery of packets in the data plane, depend more and more on prompt and accurate propagation of the RPKI data from the originating Certification Authorities (CAs), to Relying Parties (RPs), to Border Gateway Protocol (BGP) speaking routers. Origin Validation based on stale ROAs allows accidental mis-origination. While delays in ROA propagation to ROV in routers can cause loss of good traffic. Therefore minimizing propagation time of data from CAs to routers is critical. Before the data can start on the CA to router chain, the resource holder (operator) MUST create or delete the relevant ROA(s) through the CA's operational interface(s). The operator is responsible for anticipating their future needs for ROAs, be aware of the propagation time from creating ROAs to effect on routing, and SHOULD create, delete, or modify ROAs sufficiently in advance of any needs in the routing system. There are questions of how frequently a CA publishes, how often an RP pulls, and how often routers pull from their RP(s). Overall, the router(s) SHOULD react within an hour of ROA publication. For CAs publishing to PPs, a few seconds to a minute seems easily achieved with reasonable software. See . Relying Party validating caches periodically retrieve data from CA publication points. RPs using rsync to poll publication points every ten minutes would be a burden today, given the load it would put on publication services, cf. one notorious repository which is structured against specification. RPs using RRDP impose no such load. As the infrastructure moves from rsync to RRDP, fetching every ten minutes would be reasonable. For rsync, an hour would be the longest acceptable window. See . For the BGP speaking router(s) pulling from the RP(s), five minutes to an hour is a wide window. But, the RPKI-Rtr protocol does have the Serial Notify PDU, the equivalent of DNS Notify, where the cache tells the router that it has new data. See . We discuss each of these in detail below.
                                                      From nobody Thu Apr 23 14:32:05 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51B33A1405 for ; Thu, 23 Apr 2020 14:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45fUvhy0SMaI for ; Thu, 23 Apr 2020 14:32:01 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7FA3A140A for ; Thu, 23 Apr 2020 14:32:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 264F26221B; Thu, 23 Apr 2020 17:31:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id O8Jtn7KhCht4; Thu, 23 Apr 2020 17:31:49 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 43EDC6216A; Thu, 23 Apr 2020 17:31:49 -0400 (EDT) To: Randy Bush , XML2RFC Interest Group References: From: Robert Moskowitz Message-ID: <0e83776e-831a-1b9a-2a96-7026c0b25ee8@htt-consult.com> Date: Thu, 23 Apr 2020 17:31:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] subsection failure X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 21:32:03 -0000 My experience is that you cannot have text for a section after a subsection. It all must go before the subsection or be in its own subsection. On 4/23/20 3:44 PM, Randy Bush wrote: > why does including a subsection give me > > Error: Unable to validate the XML document: draft-ymbk-sidrops-rpki-rov-timing.xml > : Line 105: Element section content does not follow the DTD, expecting ((t | figure | texttable | iref)* , section*), got (t section t t t t t t t t ) > make: *** [all] Error 1 > > if i pull it to a separate section it works. > > if i eliminte the paragraphs after the first it works. > binary search elimination got me nothing > >
                                                      > > > This document explores, and makes recommendations for, timing of > Resource Public Key Infrastructure (RPKI) publication of ROV data, > their propagation, and their use in Relying Parties (RP), caches > and routers. > > >
                                                      > > The RPKI supply chain from CAs to reach routers has a structure > as follows: > > > > > > The authoritative data of the RPKI are published by a > distributed set of servers, Certification Authorities, at the > IANA, RIRs, NIRs, and ISPs (see ). > > > > The CAs publish their authoritative data in publicly > accessible repositories which have a Publication Point (PP) > for each CA. > > > > Relying Parties are a local set of one or more collected and > verified caches of RPKI data which are collected from the PPs. > > > Note that RPs can pull from other RPs, thereby creating a > somewhat complex topology. > > > > Validating routers fetch data from local caches using the RPKI > to Router Protocol, . > Routers are clients of the caches. Validating routers MUST > have a trust relationship with, and a trusted transport > channel to, any RP(s) they use. target="I-D.ietf-sidrops-8210bis"/> specifies mechanisms for > the router to assure itself of the authenticity of the cache > and to authenticate itself to the cache. > > > >
                                                      > > > As Resource Public Key Infrastructure (RPKI) based Route Origin > Validation (ROV) becomes deployed in the Internet, the quality of > the routing control plane, and hence timely and accurate delivery > of packets in the data plane, depend more and more on prompt and > accurate propagation of the RPKI data from the originating > Certification Authorities (CAs), to Relying Parties (RPs), to > Border Gateway Protocol (BGP) speaking routers. > > > > Origin Validation based on stale ROAs allows accidental > mis-origination. While delays in ROA propagation to ROV in > routers can cause loss of good traffic. Therefore minimizing > propagation time of data from CAs to routers is critical. > > > > Before the data can start on the CA to router chain, the resource > holder (operator) MUST create or delete the relevant ROA(s) > through the CA's operational interface(s). The operator is > responsible for anticipating their future needs for ROAs, be aware > of the propagation time from creating ROAs to effect on routing, > and SHOULD create, delete, or modify ROAs sufficiently in advance > of any needs in the routing system. > > > > There are questions of how frequently a CA publishes, how often an > RP pulls, and how often routers pull from their RP(s). Overall, > the router(s) SHOULD react within an hour of ROA publication. > > > > For CAs publishing to PPs, a few seconds to a minute seems easily > achieved with reasonable software. See . > > > > Relying Party validating caches periodically retrieve data from CA > publication points. RPs using rsync to poll publication points > every ten minutes would be a burden today, given the load it would > put on publication services, cf. one notorious repository which is > structured against specification. RPs using RRDP impose no such > load. As the infrastructure moves from rsync to RRDP, fetching > every ten minutes would be reasonable. For rsync, an hour would > be the longest acceptable window. See . > > > > For the BGP speaking router(s) pulling from the RP(s), five > minutes to an hour is a wide window. But, the RPKI-Rtr protocol > does have the Serial Notify PDU, the equivalent of DNS Notify, > where the cache tells the router that it has new data. See target="router-pull"/>. > > > > We discuss each of these in detail below. > > >
                                                      > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Thu Apr 23 14:35:50 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D223A1421 for ; Thu, 23 Apr 2020 14:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO_FgamzZtHn for ; Thu, 23 Apr 2020 14:35:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606D73A1420 for ; Thu, 23 Apr 2020 14:35:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jRjVX-0004NJ-FG; Thu, 23 Apr 2020 21:35:43 +0000 Date: Thu, 23 Apr 2020 14:35:42 -0700 Message-ID: From: Randy Bush To: Robert Moskowitz Cc: XML2RFC Interest Group In-Reply-To: <0e83776e-831a-1b9a-2a96-7026c0b25ee8@htt-consult.com> References: <0e83776e-831a-1b9a-2a96-7026c0b25ee8@htt-consult.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [xml2rfc] subsection failure X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 21:35:48 -0000 > My experience is that you cannot have text for a section after a > subsection. > > It all must go before the subsection or be in its own subsection. yikes! From nobody Thu Apr 23 14:47:27 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D802C3A1436 for ; Thu, 23 Apr 2020 14:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1qIE5n5Gboo for ; Thu, 23 Apr 2020 14:47:25 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBEA43A0A54 for ; Thu, 23 Apr 2020 14:47:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id BD4076221B; Thu, 23 Apr 2020 17:47:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Nhc+s5sR9mUS; Thu, 23 Apr 2020 17:47:22 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id CD3986216A; Thu, 23 Apr 2020 17:47:19 -0400 (EDT) To: Randy Bush Cc: XML2RFC Interest Group References: <0e83776e-831a-1b9a-2a96-7026c0b25ee8@htt-consult.com> From: Robert Moskowitz Message-ID: <8784b823-b1eb-1920-0a89-f6e28d0966db@htt-consult.com> Date: Thu, 23 Apr 2020 17:47:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] subsection failure X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 21:47:27 -0000 On 4/23/20 5:35 PM, Randy Bush wrote: >> My experience is that you cannot have text for a section after a >> subsection. >> >> It all must go before the subsection or be in its own subsection. > yikes! that was my feeling when I figured out i had to think about writing as: 2. stuff 2.1    more stuff 2.2   more stuff ============= there can be NO stuff of level 2 after the end of level 2.2 .... But I can kind of see it.  In that how can the reader, necessarily see that 2.2 above ended and the following text is back to 2? From nobody Thu Apr 23 14:50:00 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4354E3A1439 for ; Thu, 23 Apr 2020 14:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id On5GrCW5FQnH for ; Thu, 23 Apr 2020 14:49:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0CB3A1438 for ; Thu, 23 Apr 2020 14:49:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jRjjI-0004QD-Q0; Thu, 23 Apr 2020 21:49:56 +0000 Date: Thu, 23 Apr 2020 14:49:56 -0700 Message-ID: From: Randy Bush To: Robert Moskowitz Cc: XML2RFC Interest Group In-Reply-To: <8784b823-b1eb-1920-0a89-f6e28d0966db@htt-consult.com> References: <0e83776e-831a-1b9a-2a96-7026c0b25ee8@htt-consult.com> <8784b823-b1eb-1920-0a89-f6e28d0966db@htt-consult.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] subsection failure X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 21:49:59 -0000 >>> It all must go before the subsection or be in its own subsection. >> yikes! >=20 > that was my feeling when I figured out i had to think about writing as: >=20 > 2. >=20 > stuff >=20 > 2.1 >=20 > =A0=A0 more stuff >=20 > 2.2 >=20 > =A0 more stuff does not work when 2 is the introduction, as it is in this case > But I can kind of see it.=A0 In that how can the reader, necessarily see > that 2.2 above ended and the following text is back to 2? indentation? yes, i know. randy From nobody Thu Apr 23 15:04:50 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE033A0A99 for ; Thu, 23 Apr 2020 15:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL0jFsW75yNM for ; Thu, 23 Apr 2020 15:04:37 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA903A146A for ; Thu, 23 Apr 2020 15:04:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 6A9B262271; Thu, 23 Apr 2020 18:04:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OQELGAgDAHPr; Thu, 23 Apr 2020 18:04:26 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 18A3E6216A; Thu, 23 Apr 2020 18:04:25 -0400 (EDT) To: Randy Bush Cc: XML2RFC Interest Group References: <0e83776e-831a-1b9a-2a96-7026c0b25ee8@htt-consult.com> <8784b823-b1eb-1920-0a89-f6e28d0966db@htt-consult.com> From: Robert Moskowitz Message-ID: <307d1dad-6e3b-2f86-3383-04b76eeee161@htt-consult.com> Date: Thu, 23 Apr 2020 18:04:19 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] subsection failure X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 22:04:43 -0000 On 4/23/20 5:49 PM, Randy Bush wrote: >>>> It all must go before the subsection or be in its own subsection. >>> yikes! >> that was my feeling when I figured out i had to think about writing as: >> >> 2. >> >> stuff >> >> 2.1 >> >>    more stuff >> >> 2.2 >> >>   more stuff > does not work when 2 is the introduction, as it is in this case Change all my 2. to 1. and the same is true. > >> But I can kind of see it.  In that how can the reader, necessarily see >> that 2.2 above ended and the following text is back to 2? > indentation? yes, i know. We do not indent subsections.  Not our style.   ;) In fact I have seen subsections 6 deep.  Think about how little space would be left for text with the extent of the left white space! > > randy From nobody Thu Apr 23 15:06:30 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7224D3A146A for ; Thu, 23 Apr 2020 15:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o12-3nlP-Su9 for ; Thu, 23 Apr 2020 15:06:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35ACA3A146D for ; Thu, 23 Apr 2020 15:06:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jRjzF-0004T0-FG; Thu, 23 Apr 2020 22:06:25 +0000 Date: Thu, 23 Apr 2020 15:06:24 -0700 Message-ID: From: Randy Bush To: Robert Moskowitz Cc: XML2RFC Interest Group In-Reply-To: <307d1dad-6e3b-2f86-3383-04b76eeee161@htt-consult.com> References: <0e83776e-831a-1b9a-2a96-7026c0b25ee8@htt-consult.com> <8784b823-b1eb-1920-0a89-f6e28d0966db@htt-consult.com> <307d1dad-6e3b-2f86-3383-04b76eeee161@htt-consult.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] subsection failure X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 22:06:29 -0000 > In fact I have seen subsections 6 deep.=A0 Think about how little space > would be left for text with the extent of the left white space! From nobody Thu Apr 23 15:09:54 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438FB3A14AB for ; Thu, 23 Apr 2020 15:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzr8IGW8Fj_B for ; Thu, 23 Apr 2020 15:09:51 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8483A149A for ; Thu, 23 Apr 2020 15:09:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 440E06221B; Thu, 23 Apr 2020 18:09:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2xbwhGdpeF0g; Thu, 23 Apr 2020 18:09:44 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 9A6AC6216A; Thu, 23 Apr 2020 18:09:44 -0400 (EDT) To: Randy Bush Cc: XML2RFC Interest Group References: <0e83776e-831a-1b9a-2a96-7026c0b25ee8@htt-consult.com> <8784b823-b1eb-1920-0a89-f6e28d0966db@htt-consult.com> <307d1dad-6e3b-2f86-3383-04b76eeee161@htt-consult.com> From: Robert Moskowitz Message-ID: <210894bc-8eff-b366-0349-4861444a7dbe@htt-consult.com> Date: Thu, 23 Apr 2020 18:09:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] subsection failure X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 22:09:52 -0000 On 4/23/20 6:06 PM, Randy Bush wrote: >> In fact I have seen subsections 6 deep.  Think about how little space >> would be left for text with the extent of the left white space! > Put in a proposal.  I suspect it would have to be an addendum to the rfc on rfc style.... Hey, all I wanted was to indent a list.  The hack was to put the list inside a list of one entry with no bullets.  Sheesh. From nobody Thu Apr 23 15:41:57 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F023A0593 for ; Thu, 23 Apr 2020 15:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFXN_0iW5ZBZ for ; Thu, 23 Apr 2020 15:41:54 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073523A047D for ; Thu, 23 Apr 2020 15:41:53 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 497XNc1DY4z10QX; Fri, 24 Apr 2020 00:41:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <0e83776e-831a-1b9a-2a96-7026c0b25ee8@htt-consult.com> Date: Fri, 24 Apr 2020 00:41:51 +0200 Cc: Randy Bush , XML2RFC Interest Group X-Mao-Original-Outgoing-Id: 609374511.683951-50065397b45f7209583d711031504368 Content-Transfer-Encoding: quoted-printable Message-Id: <00D455AE-A4DE-4C32-AC65-BFC8EE7CC9DF@tzi.org> References: <0e83776e-831a-1b9a-2a96-7026c0b25ee8@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [xml2rfc] subsection failure X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 22:41:56 -0000 On 2020-04-23, at 23:31, Robert Moskowitz wrote: >=20 > My experience is that you cannot have text for a section after a = subsection. >=20 > It all must go before the subsection or be in its own subsection. Right. This is pretty much a universal property of the = section/subsection concept. There is no way in standard typography to tell where a subsection ends = without ending the entire section, except by starting another subsection = on the same level. So the (recursive) grammar is essentially: section =3D t* section* Where the t* is the introductory text for this section. I don't think trying to innovate against centuries of the established = practice for this is a useful exercise(*). Gr=C3=BC=C3=9Fe, Carsten (*) In case of insurmountable urge to do so, you can always write a = Python program. From nobody Thu Apr 23 16:07:00 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DAF3A08E5 for ; Thu, 23 Apr 2020 16:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tf5u_Ea_bMwQ for ; Thu, 23 Apr 2020 16:06:58 -0700 (PDT) Received: from dog.birch.relay.mailchannels.net (dog.birch.relay.mailchannels.net [23.83.209.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B8A3A08EB for ; Thu, 23 Apr 2020 16:06:52 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 1344A341329; Thu, 23 Apr 2020 23:06:52 +0000 (UTC) Received: from pdx1-sub0-mail-a53.g.dreamhost.com (100-96-2-17.trex.outbound.svc.cluster.local [100.96.2.17]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 941FC340A9D; Thu, 23 Apr 2020 23:06:51 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a53.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Thu, 23 Apr 2020 23:06:52 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Average-Continue: 33292c50788367d6_1587683211857_3904223699 X-MC-Loop-Signature: 1587683211857:2412527994 X-MC-Ingress-Time: 1587683211857 Received: from pdx1-sub0-mail-a53.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a53.g.dreamhost.com (Postfix) with ESMTP id 4FC909531D; Thu, 23 Apr 2020 16:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=EpGrBqj+boMOiDWgSbp8PTlmEyA=; b=aU/6feIW14U ZPaVHIo4I0x5ZKJH+TKLPC7u750YkvJDH6VE+KcKvv0roI9NdC+miGLD9fq1LJR6 +8FYhgbUEsRomN9KLZ0YRNPphyErS1duN6rMSWOlEEGWQ34sw8+EOunPbrbgn6Si YE9B3mQk4b3nz90VfVkpBAg370Dfwf5w= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a53.g.dreamhost.com (Postfix) with ESMTPSA id ED7D895314; Thu, 23 Apr 2020 16:06:47 -0700 (PDT) Date: Thu, 23 Apr 2020 18:06:45 -0500 X-DH-BACKEND: pdx1-sub0-mail-a53 From: Nico Williams To: Robert Moskowitz Cc: Randy Bush , XML2RFC Interest Group Message-ID: <20200423230644.GC18021@localhost> References: <0e83776e-831a-1b9a-2a96-7026c0b25ee8@htt-consult.com> <8784b823-b1eb-1920-0a89-f6e28d0966db@htt-consult.com> <307d1dad-6e3b-2f86-3383-04b76eeee161@htt-consult.com> <210894bc-8eff-b366-0349-4861444a7dbe@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <210894bc-8eff-b366-0349-4861444a7dbe@htt-consult.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrhedtgdduiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderudenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] subsection failure X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 23:06:59 -0000 On Thu, Apr 23, 2020 at 06:09:43PM -0400, Robert Moskowitz wrote: > On 4/23/20 6:06 PM, Randy Bush wrote: > > > In fact I have seen subsections 6 deep.=A0 Think about how little s= pace > > > would be left for text with the extent of the left white space! > > >=20 > Put in a proposal.=A0 I suspect it would have to be an addendum to the = rfc on > rfc style.... Maybe 343 days from now. From nobody Tue Apr 28 12:12:29 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556A23A09A5 for ; Tue, 28 Apr 2020 12:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvGDNR5IsAoB for ; Tue, 28 Apr 2020 12:12:26 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CF13A0990 for ; Tue, 28 Apr 2020 12:12:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 8AD4A62199 for ; Tue, 28 Apr 2020 15:12:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id q6fEaOY1CzyC for ; Tue, 28 Apr 2020 15:12:13 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 202426216A for ; Tue, 28 Apr 2020 15:12:13 -0400 (EDT) To: "xml2rfc@ietf.org" From: Robert Moskowitz Message-ID: <555f5ab1-a3a0-7710-0581-4d13bb641325@htt-consult.com> Date: Tue, 28 Apr 2020 15:12:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [xml2rfc] Word enforcing 1 space between sentences X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 19:12:28 -0000 I recently saw a fluff piece about MS Word now enforcing 1 space between sentences.  If you put in 2 you get the terrible squiggly line (which you can always turn off with a right-click, ignore all). The argument for single space is the font handles inter-sentence spacing just fine as mono-spacing went out with the typewriter.... I wonder what it does if your font IS mono-space? Like our style guide.... Enjoy! From nobody Tue Apr 28 12:16:39 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF203A0A01 for ; Tue, 28 Apr 2020 12:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-JWY7Y8Y2Q4 for ; Tue, 28 Apr 2020 12:16:36 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3C81C3A09F8 for ; Tue, 28 Apr 2020 12:16:36 -0700 (PDT) Received: from [IPv6:::1] (bill@grace.encs.concordia.ca [132.205.2.217] port 55951) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id 03SJGSkc008228; Tue, 28 Apr 2020 15:16:28 -0400 To: Robert Moskowitz , xml2rfc@ietf.org References: <555f5ab1-a3a0-7710-0581-4d13bb641325@htt-consult.com> From: William Atwood Autocrypt: addr=william.atwood@concordia.ca; prefer-encrypt=mutual; keydata= mQGiBEmjdrMRBADawl3I6QQW9RTYKHQk0tMhjbbgi7clCKZzmgTOOHKYDil9J68+xyTdXlBT ud5crBx2kYf334Uf5fOBNBh6Z/3kUr2qkvVHXAp+yox81wao8pBwQ5wcnhPmnGhpsapCMeBA 3deiCQfvd9AVygrNZOJvW526PIHiNvob2pDT4ef0iwCgroVoHugkt+84Ly3jL9lcFFmqW38D /2exybJrzefDFGHExaQinYRwIovHhdilirh3k6BcRaS6xWUbWsra+w0OSQWCt+Ooaj6Zmeio 13U5lybjD4M0Se7TI0AW6JJsHot3x69/2Uq2OWb1cddezafZ4+vlNybC5LZ+tynTVt2RB7lE Yy34W9kTWIHsaFOLUjDaZW+ScpKoA/9yXM3FY7hUTBEgP5+CUyX4zYsnxtmeurhVi4D3Ri1e TRQhE/WxaVsxxqJuFNx/rzOPwnekWa06cb4mKYHJ6HJ/q1hjSCOvhlSUgLwQ6XiqYW/dulfL ulq6d9w01gApWPNdaimLOnZi/Of52YO7RZroSNPBwC71hOxzQCzeHZLgaLQxSm9obiBXaWxs aWFtIEF0d29vZCA8d2lsbGlhbS5hdHdvb2RAY29uY29yZGlhLmNhPohjBBMRAgAjAhsjBgsJ CAcDAgQVAggDBBYCAwECHgECF4AFAlC5EYcCGQEACgkQV5o4IdDwBVhFdACePdBrMqD3jC9V 53DbmgWkIR5oHVAAn1HPsfaMXQsIyim9d2wpwQunGDcXuQINBEmjdrMQCACDziZLszCCtC0i 195vC7UlKnKEE7rLKP+tzpJuPb6EW27xBtJ2cr6RXZQ84rrHvgczmhaht7kUPyyAFVUG2pbK 9vOBPcurdimtz4cc5FJ6v2wi9NoNaxag8MY2WYYzH7Fs4Bh7ZK7B6pR/lYVNltu8vxT7MO4p k+jjDaKkYU4VlN9dWrwTapmBbYafdOHhxnvxYrr3TsLdpYbGiucDwLtWGgd7+jx9LUT9tStg RgSYpwULZbQWHjSGRAXHtOzsk01TcTUP+rzbqteQ+3n867848rnJxoOWdOF73TR32dif0osf DAr4EuHHSkRI8a7me8zcVVZGhjQsp6JGsnhKO0AfAAMFB/9Cym72Z7nNw4ewqhVAVPal+tQG zkyh1S8vTEo6GdOK7eapc1OaSK7YCAS6UmFVTgoAjRBUPA5L7aLorSUXwzjZ7X26Pn2ywlnI c8+7AlbeGnggEg1h95QQTly+xU3ZEiBF0LhhyAwpISqGiz7zq44w2pqAxnAiKNX2xZxjHdZ+ yDMxT86Yj/U7K6ITv4/GwygS7bMt9+wXYRzvr9gHr5jKMEsTeIJHi5UNWLYfpfmhyF6sZ3KT qHFVAZ6yu2xDuAEhnIWaOUC2+Z9XHLMvgSrxIleqkKJiWZbAc9C1F/iV+DeQ7rNPNg9pN2Kr imkVfjdMTCwORUeeGprBurp3wCy/iEkEGBECAAkFAkmjdrMCGwwACgkQV5o4IdDwBVgd9gCf YD8t+Q9rphTC4HpOX9lHYEIIko8An2V2hchJax+LOGzSQOXOj8OgK3g3 Organization: Concordia University, Montreal Message-ID: <75b25501-ae08-a4f4-2dcf-79a7ef8d789a@concordia.ca> Date: Tue, 28 Apr 2020 15:16:28 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <555f5ab1-a3a0-7710-0581-4d13bb641325@htt-consult.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2020-04-28 15:16:29 EDT Archived-At: Subject: Re: [xml2rfc] Word enforcing 1 space between sentences X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 19:16:38 -0000 LaTeX (my favorite text processor) _uses_ the double-space after a period to _detect_ the end of a sentence. Down with WORD!! jwa On 2020-04-28 3:12 p.m., Robert Moskowitz wrote: > I recently saw a fluff piece about MS Word now enforcing 1 space between > sentences.  If you put in 2 you get the terrible squiggly line (which > you can always turn off with a right-click, ignore all). > > The argument for single space is the font handles inter-sentence spacing > just fine as mono-spacing went out with the typewriter.... > > I wonder what it does if your font IS mono-space? > > Like our style guide.... > > Enjoy! > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Thu Apr 30 12:41:20 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0233A11C9 for ; Thu, 30 Apr 2020 12:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9vkb-EldxhC for ; Thu, 30 Apr 2020 12:41:16 -0700 (PDT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA513A11C4 for ; Thu, 30 Apr 2020 12:41:16 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id h12so3882458pjz.1 for ; Thu, 30 Apr 2020 12:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GhWAmP7lfBUW6Ul8rXrJ5FZiXcySfalOI3FXFJFSSdI=; b=lWrNBvhJt/8TvEjddklooHEWp8mb4E+wGPH2hKwu/U21TfUxzBF5Q5AHEo8TWbsI6r QOqLGFpaPUEQ8mnuat12YRe7J40/ERIY7GpoMXatP9kSP0TuwiEiLuBkL6p6tP3W8IdA 73iMSVhlCGwRlc8NAEkQLSSVzvfbAmx8GMUKaLhdPSFbcqAS31v+AlUbfXFwG8POoP2B gxcyuUrUv5bcDU9ZNoL/c+hwuABomNiA837zH26sjaNxS722Pwa++SG+EcLR74Q3g2Gr K4cUGYkIFyGjtGvpdKH9ubGCFHvEITzzKdGoNf/btNYYP7Yv+ZsABWAf/sQpTBM0SbM4 8XDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GhWAmP7lfBUW6Ul8rXrJ5FZiXcySfalOI3FXFJFSSdI=; b=CWUVaozGzLDj9tGqA2dKr+a+xX7lNW2pKkKsfKsU5ptFb+fxm74ZJVv7bIqLr9p7BE BuCGIqEDQwH/+ydtNKvnSlaUDa6l9XiSqPJjiHuz1mq44zv5X2zFGtXlhzKCdRCi/iHD RzQGlez3U46sUSt+6xwnLfZEG7ZZjH4srPzrxvV/lhYKK4z0w0r3rysS4eSQSm5Y0oJf ZMgeolfMi6R1dvqi65be3gJDi2n4jnY0TyUdz+rLov3r6BRVWpjk/htvIGvaYEWKr1eh 6D4H4+DwxRkyiHymufGtdWPxbxX5Za1rwJYECj8oS2xuQMvQK0msaZU6BglzzX2My3b0 KFjw== X-Gm-Message-State: AGi0PuZhWON6Ton8/bGhJL2rNIllkpt7AdaozOu932xH07eUY+Amfjb6 Vf1xQ/SVGfTpQ1f0cHTLaq0S5f1g X-Google-Smtp-Source: APiQypJRYQIZGkqlpnfXxrv62cVBH+csV5a5LlLMWOhe1rlbLyYfDVD15DkkF51J3TPC1dzwGNzzMw== X-Received: by 2002:a17:902:8e8b:: with SMTP id bg11mr549818plb.139.1588275676217; Thu, 30 Apr 2020 12:41:16 -0700 (PDT) Received: from [10.128.64.149] ([136.60.227.81]) by smtp.gmail.com with ESMTPSA id c2sm497769pfp.118.2020.04.30.12.41.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2020 12:41:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Bret Jordan In-Reply-To: <555f5ab1-a3a0-7710-0581-4d13bb641325@htt-consult.com> Date: Thu, 30 Apr 2020 13:41:12 -0600 Cc: "xml2rfc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <082DF79F-9BD8-4248-906E-D413E88A7419@gmail.com> References: <555f5ab1-a3a0-7710-0581-4d13bb641325@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [xml2rfc] Word enforcing 1 space between sentences X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 19:41:19 -0000 It is important to note that you can change this behavior in settings. I = use a double space out of muscle memory. I learned to type in type class = because my parents knew that one day people would have their own = computers and I would need to know how to type.=20 Like all things like this, this style guides will come and go and change = with the whims of who ever is in the position of power of the day. All = organizations are often highly influenced by a small number of very = vocal individuals that try to force their view of the world on others. Bret > On Apr 28, 2020, at 1:12 PM, Robert Moskowitz = wrote: >=20 > I recently saw a fluff piece about MS Word now enforcing 1 space = between sentences. If you put in 2 you get the terrible squiggly line = (which you can always turn off with a right-click, ignore all). >=20 > The argument for single space is the font handles inter-sentence = spacing just fine as mono-spacing went out with the typewriter.... >=20 > I wonder what it does if your font IS mono-space? >=20 > Like our style guide.... >=20 > Enjoy! >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Thu Apr 30 12:57:07 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E393A1214 for ; Thu, 30 Apr 2020 12:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_BL=0.001, RCVD_IN_MSPIKE_L3=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzENvywKF-Dd for ; Thu, 30 Apr 2020 12:57:03 -0700 (PDT) Received: from fossa.birch.relay.mailchannels.net (fossa.birch.relay.mailchannels.net [23.83.209.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931BE3A1212 for ; Thu, 30 Apr 2020 12:57:03 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id BEF2F921ADD; Thu, 30 Apr 2020 19:57:02 +0000 (UTC) Received: from pdx1-sub0-mail-a9.g.dreamhost.com (100-96-23-11.trex.outbound.svc.cluster.local [100.96.23.11]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 4F729921992; Thu, 30 Apr 2020 19:57:02 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a9.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Thu, 30 Apr 2020 19:57:02 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Arch-Illegal: 307bffdc3bb6b877_1588276622586_2041652538 X-MC-Loop-Signature: 1588276622586:1188805750 X-MC-Ingress-Time: 1588276622586 Received: from pdx1-sub0-mail-a9.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTP id 048B87F004; Thu, 30 Apr 2020 12:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=Utl4Z4dpw6qd3UUErG+KEBFn2ng=; b=CWiq7yOhbL/ JL9IhCauf7z28Gp7eq8wtfq6rhbQIi9MSLO10/ayMu0B/LmU8BDZ+gq9ZsU2iFIQ C8YCzkVwLPXP9GXBcl8eERMrywdaGODV7V+VU3mJ+Yd/Gh3WM1tw6N8720DDxKUZ C0WoLoDvsXqJNiRYaL5TRH1vWk2Nxol0= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 8F18A7F001; Thu, 30 Apr 2020 12:56:59 -0700 (PDT) Date: Thu, 30 Apr 2020 14:56:56 -0500 X-DH-BACKEND: pdx1-sub0-mail-a9 From: Nico Williams To: Robert Moskowitz Cc: "xml2rfc@ietf.org" Message-ID: <20200430195655.GF18021@localhost> References: <555f5ab1-a3a0-7710-0581-4d13bb641325@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <555f5ab1-a3a0-7710-0581-4d13bb641325@htt-consult.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrieehgddugeduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderudenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpeevleelleetuedtteeiledtueethfetffehteevudevvedthfevfffhtddttdehleenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] Word enforcing 1 space between sentences X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 19:57:06 -0000 On Tue, Apr 28, 2020 at 03:12:10PM -0400, Robert Moskowitz wrote: > I recently saw a fluff piece about MS Word now enforcing 1 space betwee= n > sentences.=A0 If you put in 2 you get the terrible squiggly line (which= you > can always turn off with a right-click, ignore all). >=20 > The argument for single space is the font handles inter-sentence spacin= g > just fine as mono-spacing went out with the typewriter.... This debate is a recurring one. Opinions vary. IMO: - Two spaces after sentence-ending periods function as markup that distinguishes from non-sentence-ending periods and avoids the need for either explicit markup or sentence-ending heuristics. Editors should let me type two spaces to end sentences because that's a damned common thing to do. They can turn it into something else, I don't care, as long as the intended purpose is served. - Rendering such '. ' as . and a wider space is perfectly fine and desirable. > I wonder what it does if your font IS mono-space? I hope you get two spaces after the sentence-ending period. Anything else would be a bug. Anyways, prepare for this to turn into a bit of a flame war, or for it to end with a reference to past ones. Nico --=20 From nobody Thu Apr 30 12:58:24 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B813A1216 for ; Thu, 30 Apr 2020 12:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cEr16FFuqB7 for ; Thu, 30 Apr 2020 12:58:17 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD65D3A121A for ; Thu, 30 Apr 2020 12:58:16 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49CmQb19MCzyjR; Thu, 30 Apr 2020 21:58:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <555f5ab1-a3a0-7710-0581-4d13bb641325@htt-consult.com> Date: Thu, 30 Apr 2020 21:58:14 +0200 Cc: "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 609969494.715591-6e7107be99ebb800d02cbe6acb60b8a3 Content-Transfer-Encoding: quoted-printable Message-Id: <54653F71-5459-4D88-9661-25F22E1DF6D7@tzi.org> References: <555f5ab1-a3a0-7710-0581-4d13bb641325@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [xml2rfc] Word enforcing 1 space between sentences X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 19:58:23 -0000 Hi Bob, > On 2020-04-28, at 21:12, Robert Moskowitz wrote: >=20 > I recently saw a fluff piece about MS Word now enforcing 1 space = between sentences. If you put in 2 you get the terrible squiggly line = (which you can always turn off with a right-click, ignore all). As Bret said, this probably can be configured. > The argument for single space is the font handles inter-sentence = spacing just fine as mono-spacing went out with the typewriter.... Well, this is a long story I don't want to re-tell here. Let's just say that there are some typographic fashions that don't = respect the prime directive: Legibility. I tend to ignore those. But as Bill notes, the question of typographic presentation is somewhat = distinct from the keyboarding convention. People who expertly keyboard manuscripts for usage by document = processing systems always try to indicate where sentence ends are and = where they aren't. =20 The document processing system can then decide on the presentation style = of the day. A double space is a conventional signal for keyboarding a sentence end; = it has been for half a century now. As is a newline. I am (and I'd want to believe most people who have been using document = processing systems since the 1970s are) used to the latter: end each = sentence with a newline. Look, ma, no double spaces in the manuscript, and still clearly = indicated sentence ends! (And look how much more readable the message becomes that way. And, you'll notice, your git diffs do, too!) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 30 13:07:22 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DEF3A1254 for ; Thu, 30 Apr 2020 13:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYz2EkzwkuQz for ; Thu, 30 Apr 2020 13:07:19 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803A33A124F for ; Thu, 30 Apr 2020 13:07:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id B7A526212C; Thu, 30 Apr 2020 16:07:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fO-V3qpYwQNq; Thu, 30 Apr 2020 16:07:12 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id BEA156211C; Thu, 30 Apr 2020 16:07:12 -0400 (EDT) To: Nico Williams Cc: "xml2rfc@ietf.org" References: <555f5ab1-a3a0-7710-0581-4d13bb641325@htt-consult.com> <20200430195655.GF18021@localhost> From: Robert Moskowitz Message-ID: <480d6039-59e3-a802-43ac-9089244ac7f6@htt-consult.com> Date: Thu, 30 Apr 2020 16:07:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200430195655.GF18021@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Word enforcing 1 space between sentences X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 20:07:21 -0000 On 4/30/20 3:56 PM, Nico Williams wrote: > On Tue, Apr 28, 2020 at 03:12:10PM -0400, Robert Moskowitz wrote: >> I recently saw a fluff piece about MS Word now enforcing 1 space between >> sentences.  If you put in 2 you get the terrible squiggly line (which you >> can always turn off with a right-click, ignore all). >> >> The argument for single space is the font handles inter-sentence spacing >> just fine as mono-spacing went out with the typewriter.... > This debate is a recurring one. Opinions vary. > > IMO: > > - Two spaces after sentence-ending periods function as markup that > distinguishes from non-sentence-ending periods and avoids the need > for either explicit markup or sentence-ending heuristics. > > Editors should let me type two spaces to end sentences because that's > a damned common thing to do. They can turn it into something else, I > don't care, as long as the intended purpose is served. > > - Rendering such '. ' as . and a wider space is perfectly fine and > desirable. > >> I wonder what it does if your font IS mono-space? > I hope you get two spaces after the sentence-ending period. Anything > else would be a bug. > > Anyways, prepare for this to turn into a bit of a flame war, or for it > to end with a reference to past ones. I had my typing class in '64 (9th grade US) on a Royal manual typewriter.  You had to type at 40WPM after corrections to pass.  I still have my typing style guide with lots of things not done today.  2 spaces after a sentence is a small one!  My  wife and I occasionally argue (she came through the program 4 years later and they had already changed business letter layouts). I use to write for Network Computing Magazine (back in the mid-90s).  My editor and I reached an agreement that I typed as I learned and she changed it to the Mag's style guide.  Made for a much better interaction.  Of course I was the acronym king of the writers and she had a struggle figuring out which to expand and which to leave to the readers as I had a 500w budget and typically hit it on the head. So in large measure I care little what they are teaching today and what styles are being enforced.  I will write as I do and if some editor enforces a style guide, have at it. Have a good day! From nobody Thu Apr 30 13:12:39 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286703A1273 for ; Thu, 30 Apr 2020 13:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyVoohmlmk5Q; Thu, 30 Apr 2020 13:12:35 -0700 (PDT) Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 536303A120E; Thu, 30 Apr 2020 13:12:34 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9409E41C-06BF-4820-9EB8-7E3DBAAC3AAB" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 1 May 2020 08:12:31 +1200 In-Reply-To: <54653F71-5459-4D88-9661-25F22E1DF6D7@tzi.org> Cc: Robert Moskowitz , "xml2rfc@ietf.org" To: Carsten Bormann References: <555f5ab1-a3a0-7710-0581-4d13bb641325@htt-consult.com> <54653F71-5459-4D88-9661-25F22E1DF6D7@tzi.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [xml2rfc] Word enforcing 1 space between sentences X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 20:12:37 -0000 --Apple-Mail=_9409E41C-06BF-4820-9EB8-7E3DBAAC3AAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Science is on the side of us over-40s: = https://www.independent.co.uk/life-style/gadgets-and-tech/news/one-space-o= r-two-spaces-after-a-full-stop-scientists-have-finally-found-the-answer-a8= 337646.html Jay (whose mother is a typesetter and knows more about this than anyone = else I=E2=80=99ve met) > On 1/05/2020, at 7:58 AM, Carsten Bormann wrote: >=20 > Hi Bob, >=20 >> On 2020-04-28, at 21:12, Robert Moskowitz = wrote: >>=20 >> I recently saw a fluff piece about MS Word now enforcing 1 space = between sentences. If you put in 2 you get the terrible squiggly line = (which you can always turn off with a right-click, ignore all). >=20 > As Bret said, this probably can be configured. >=20 >> The argument for single space is the font handles inter-sentence = spacing just fine as mono-spacing went out with the typewriter.... >=20 > Well, this is a long story I don't want to re-tell here. > Let's just say that there are some typographic fashions that don't = respect the prime directive: Legibility. > I tend to ignore those. >=20 > But as Bill notes, the question of typographic presentation is = somewhat distinct from the keyboarding convention. > People who expertly keyboard manuscripts for usage by document = processing systems always try to indicate where sentence ends are and = where they aren't. =20 > The document processing system can then decide on the presentation = style of the day. >=20 > A double space is a conventional signal for keyboarding a sentence = end; it has been for half a century now. > As is a newline. >=20 > I am (and I'd want to believe most people who have been using document = processing systems since the 1970s are) used to the latter: end each = sentence with a newline. > Look, ma, no double spaces in the manuscript, and still clearly = indicated sentence ends! > (And look how much more readable the message becomes that way. > And, you'll notice, your git diffs do, too!) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_9409E41C-06BF-4820-9EB8-7E3DBAAC3AAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Science is on the side of us over-40s:

                                                      https://www.independent.co.uk/life-style/gadgets-and-tech/news/= one-space-or-two-spaces-after-a-full-stop-scientists-have-finally-found-th= e-answer-a8337646.html

                                                      Jay (whose mother is a typesetter and knows more about this = than anyone else I=E2=80=99ve met)

                                                      On = 1/05/2020, at 7:58 AM, Carsten Bormann <cabo@tzi.org> wrote:

                                                      Hi = Bob,

                                                      On = 2020-04-28, at 21:12, Robert Moskowitz <rgm@htt-consult.com>= wrote:

                                                      I recently saw a fluff piece about = MS Word now enforcing 1 space between sentences.  If you put in 2 = you get the terrible squiggly line (which you can always turn off with a = right-click, ignore all).

                                                      As = Bret said, this probably can be configured.

                                                      The argument for single = space is the font handles inter-sentence spacing just fine as = mono-spacing went out with the typewriter....

                                                      Well, this is a long story I = don't want to re-tell here.
                                                      Let's just say that there are = some typographic fashions that don't respect the prime directive: = Legibility.
                                                      I tend to ignore those.

                                                      But as Bill notes, the question of typographic presentation = is somewhat distinct from the keyboarding convention.
                                                      People= who expertly keyboard manuscripts for usage by document processing = systems always try to indicate where sentence ends are and where they = aren't.  
                                                      The document processing system can then = decide on the presentation style of the day.

                                                      A double space is a conventional signal for keyboarding a = sentence end; it has been for half a century now.
                                                      As is a = newline.

                                                      I am (and I'd want to believe most = people who have been using document processing systems since the 1970s = are) used to the latter: end each sentence with a newline.
                                                      Look, ma, no double spaces in the manuscript, and still = clearly indicated sentence ends!
                                                      (And look how much more = readable the message becomes that way.
                                                      And, you'll notice, = your git diffs do, too!)

                                                      Gr=C3=BC=C3=9Fe, = Carsten

                                                      _______________________________________________
                                                      xml2rfc mailing list
                                                      xml2rfc@ietf.org
                                                      https://www.ietf.org/mailman/listinfo/xml2rfc

                                                      -- 
                                                      Jay Daley
                                                      IETF = Executive Director
                                                      jay@ietf.org

                                                      = --Apple-Mail=_9409E41C-06BF-4820-9EB8-7E3DBAAC3AAB-- From nobody Thu Apr 30 13:14:31 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E683A127A for ; Thu, 30 Apr 2020 13:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XJG0V4jxRfx for ; Thu, 30 Apr 2020 13:14:23 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F6F3A1279 for ; Thu, 30 Apr 2020 13:14:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9DAF06216E; Thu, 30 Apr 2020 16:14:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WhYsXAp1u3L1; Thu, 30 Apr 2020 16:14:17 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 9667C6211C; Thu, 30 Apr 2020 16:14:17 -0400 (EDT) To: Carsten Bormann Cc: "xml2rfc@ietf.org" References: <555f5ab1-a3a0-7710-0581-4d13bb641325@htt-consult.com> <54653F71-5459-4D88-9661-25F22E1DF6D7@tzi.org> From: Robert Moskowitz Message-ID: <2a100c7a-1b95-0daf-295a-0df9a8944919@htt-consult.com> Date: Thu, 30 Apr 2020 16:14:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <54653F71-5459-4D88-9661-25F22E1DF6D7@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Word enforcing 1 space between sentences X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 20:14:29 -0000 On 4/30/20 3:58 PM, Carsten Bormann wrote: > Hi Bob, > >> On 2020-04-28, at 21:12, Robert Moskowitz wrote: >> >> I recently saw a fluff piece about MS Word now enforcing 1 space between sentences. If you put in 2 you get the terrible squiggly line (which you can always turn off with a right-click, ignore all). > As Bret said, this probably can be configured. > >> The argument for single space is the font handles inter-sentence spacing just fine as mono-spacing went out with the typewriter.... > Well, this is a long story I don't want to re-tell here. > Let's just say that there are some typographic fashions that don't respect the prime directive: Legibility. > I tend to ignore those. > > But as Bill notes, the question of typographic presentation is somewhat distinct from the keyboarding convention. > People who expertly keyboard manuscripts for usage by document processing systems always try to indicate where sentence ends are and where they aren't. > The document processing system can then decide on the presentation style of the day. > > A double space is a conventional signal for keyboarding a sentence end; it has been for half a century now. > As is a newline. > > I am (and I'd want to believe most people who have been using document processing systems since the 1970s are) used to the latter: end each sentence with a newline. Hemingway would have had a tough time with this.  Not Faulkner or Conrad (in "the Niger of the Narcissus" there is a sentence a page long and it reads beautifully, but it can take a few readings to get all the imagery from it). I will still pull my copy of "Typhoon" from the shelf and reread it.  I never did like "Lord Jim", his earlier works IMHO were much better.  Ah, the age of sail just at its end. Put those in your document processing systems. > Look, ma, no double spaces in the manuscript, and still clearly indicated sentence ends! > (And look how much more readable the message becomes that way. > And, you'll notice, your git diffs do, too!) > > Grüße, Carsten >