From nobody Wed Oct 6 06:57:33 2021 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 CDA3E3A1C5F for ; Wed, 6 Oct 2021 06:57: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 Es_Qfxb6Yy4n for ; Wed, 6 Oct 2021 06:57: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 8D4D63A1C59 for ; Wed, 6 Oct 2021 06:57:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 777F9626AF for ; Wed, 6 Oct 2021 09:56: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 4q6m97vxo3Kv for ; Wed, 6 Oct 2021 09:56:03 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 893666256E for ; Wed, 6 Oct 2021 09:56:01 -0400 (EDT) To: "xml2rfc@ietf.org" From: Robert Moskowitz Message-ID: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> Date: Wed, 6 Oct 2021 09:56:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------9D11D29971CE2897EA8CE846" Content-Language: en-US Archived-At: Subject: [xml2rfc] Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 13:57:32 -0000 This is a multi-part message in MIME format. --------------9D11D29971CE2897EA8CE846 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I am submitting the attached xml draft at https://datatracker.ietf.org/submit/ I get errors like: /tmp/draft-moskowitz-drip-operator-privacy-08-lx98crix.xml(0): Error: IDREF attribute target references an unknown ID "I-D.ietf-drip-reqs", at None I have no problem with the local xml2rfc with the --v3 option or online at: https://xml2rfc.tools.ietf.org What is submit doing wrong??? thanks --------------9D11D29971CE2897EA8CE846 Content-Type: text/xml; charset=UTF-8; name="draft-moskowitz-drip-operator-privacy-08.xml" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="draft-moskowitz-drip-operator-privacy-08.xml"  UAS Operator Privacy for RemoteID Messages HTT Consulting
Oak Park MI 48237 USA rgm@labs.htt-consult.com
AX Enterprize
4947 Commercial Drive Yorkville NY 13495 USA stu.card@axenterprize.com
AX Enterprize
4947 Commercial Drive Yorkville NY 13495 USA adam.wiethuechter@axenterprize.com
Internet DRIP RFC Request for Comments I-D Internet-Draft RID This document describes a method of providing privacy for UAS Operator/Pilot information specified in the ASTM UAS Remote ID and Tracking messages. This is achieved by encrypting, in place, those fields containing Operator sensitive data using a hybrid ECIES.
Introduction This document defines a mechanism to provide privacy in the ASTM Remote ID and Tracking messages by encrypting, in place, those fields that contain sensitive UAS Operator/Pilot information. Encrypting in place means that the ciphertext is exactly the same length as the cleartext, and directly replaces it. An example of and an initial application of this mechanism is the 8 bytes of UAS Operator/Pilot (hereafter called simply Operator) longitude and latitude location in the ASTM System Message (Msg Type 0x4). This meets the Drip Requirements, Priv-01. It is assumed that the Operator, via the UAS, registers an operation with its USS. During this operation registration, the UAS and USS exchange public keys to use in the hybrid ECIES. The USS key may be long lived, but the UAS key SHOULD be unique to a specific operation. This provides protection if the ECIES secret is exposed from prior operations. The actual Tracking message field encryption MUST be an "encrypt in place" cipher. There is rarely any room in the tracking messages for a cipher IV or encryption MAC (AEAD tag). There is rarely any data in the messages that can be used as an IV. The AES-CFB32 mode of operation proposed here can encrypt a multiple of 4 bytes. The System Message is not a simple, one-time, encrypt the PII with the ECIES derived key. The Operator may move during a operation and these fields change, correspondingly. Further, not all messages will be received by the USS, so each message's encryption must stand on its own and not be at risk of attack by the content of other messages. Another candidate message is the optional ASTM Operator ID Message (Msg Type 0x5) with its 20 character Operator ID field. The Operator ID does not change during an operation, so this is a one-time encryption operation for the operation. The same cipher SHOULD be used for all messages from the UAS and this will influence the cipher selection. Future applications of this mechanism may be provided. The content of the System Message may change to meet CAA requirements, requiring encrypting a different amount of data. At that time, they will be added to this document. Editor note: The Rules for allowing encryption need to be updated to handle the UA operating in Broadcast Remote ID only mode. That is conditions where the USS cannot notify the UAS to stop encrypting.
Terms and Definitions
Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Definitions See Drip Requirements for common DRIP terms.
ECIES
Elliptic Curve Integrated Encryption Scheme. A hybrid encryption scheme which provides semantic security against an adversary who is allowed to use chosen-plaintext and chosen-ciphertext attacks.
Keccak (KECCAK Message Authentication Code):
The family of all sponge functions with a KECCAK-f permutation as the underlying function and multi-rate padding as the padding rule.
KMAC (KECCAK Message Authentication Code):
A PRF and keyed hash function based on KECCAK.
The Operator - USS Security Relationship All CAAs have rules defining which UAS must be registered to operate in their National Airspace. This includes UAS and Operator registration in a USS. Further, operator's are expected to report flight operations to their USS. This operation reporting provides a mechanism for the USS and operator to establish an operation security context. Here it will be used to exchange public keys for use in ECIES. The operator's ECIES public key SHOULD be unique for each operation. The USS ECIES public key may be unique for each operator and operation, but not required. For best post-compromise security (PCS), the USS ECIES public key should be changed over some operational window. The public key algorithm should be Curve25519. Correspondingly, the ECIES 128 bit shared secret should be generated using KMAC.
ECIES Shared Secret Generation The KMAC function provides a new, more efficient, key derivation function over HKDF . This will be referred to as KKDF. HKDF needs a minimum of 4 hash functions (e.g. SHA256). KKDF does an equivalent shared secret generation in a single Keccak Sponge operation. When the USS - UAS Operation Security Context is established, the UAS provides its UAS ID (null padded to 20 characters per ) and a 256 bit random nonce to the USS. These are inputs, along with the ECDH keys to produce the shared secret as follows. A 64 bit UNIX timestamp for the operation time is also included in the Operation Security Context. This will be used in the IV construction. Per , Section 4.1, Option 3: L is the derived key bit length. Since only a single key is needed, L=128. S is the byte string 01001011 || 01000100 || 01000110, which represents the sequence of characters "K", "D", and "F" in 8-bit ASCII. There are special security considerations for IKM per . The IKM as follows:
System Message Privacy The System Message contains 8 bytes of Operator specific information: Longitude and Latitude of the Remote Operator (Pilot in the field description) of the UA. The GCS MAY encrypt these as follows. Editors Note: The next version of , currently in ballot, is adding a 4 byte Operator Altitude field, thus increasing the Operator specific information to 12 bytes. This change will be delineated via Protocol Version field. The 8 bytes of Operator information are encrypted, using the ECIES derived 128 bit shared secret, with one of the cipher's specified below. The choice of cipher is based on USS policy and is agreed to as part of the operation registration. AES-CFB32 is the recommended default cipher. ASTM Remote ID and Tracking messages SHOULD be updated to allow Bit 2 of the Flags byte in the System Message set to "1" to indicate the Operator information is encrypted. The USS similarly decrypts these 8 bytes and provides the information to authorized entities.
Rules for encrypting System Message content If the Operator location is encrypted the encrypted bit flag MUST be set to 1. The Operator MAY be notified by the USS that the operation has entered a location or time where privacy of Operator location is not allowed. In this case the Operator MUST disable this privacy feature and send the location unencrypted or land the UA or route around the restricted area. If the UAS looses connectivity to the USS, the privacy feature SHOULD be disabled or land the UA. If the operation is in an area or time with no Internet Connectivity, the privacy feature MUST NOT be used.
Rules for decrypting System Message content An Observer receives a System Message with the encrypt bit set to 1. The Observer sends a query to its USS Display Provider containing the UA's ID and the encrypted fields. The USS Display Provider MAY deny the request if the Observer does not have the proper authorization. The USS Display Provider MAY reply to the request with the decrypted fields if the Observer has the proper authorization. The USS Display Provider MAY reply to the request with the decrypting key if the Observer has the proper authorization. The Observer MAY notify the USS through its USS Display Provider that content privacy for a UAS in this location/time is not allowed. If the Observer has the proper authorization for this action, the USS notifies the Operator to disable this privacy feature.
Operator ID Message Privacy The Operator ID Message contains the 20 byte Operator ID. The GCS MAY encrypt these as follows. The 20 bytes Operator ID is encrypted, using the ECIES derived 128 bit shared secret, with one of the cipher's specified below. The choice of cipher is based on USS policy and is agreed to as part of the operation registration. AES-CFB32 is the recommended default cipher. ASTM Remote ID and Tracking messages SHOULD be updated to allow Operator ID Type in the Operator ID Message set to "1" to indicate the Operator ID is encrypted. The USS similarly decrypts these 20 bytes and provides the information to authorized entities.
Rules for encrypting Operator ID Message content If the Operator ID is encrypted the Operator ID Type field MUST be set to 1. The Operator MAY be notified by the USS that the operation has entered a location or time where privacy of Operator ID is not allowed. In this case the Operator MUST disable this privacy feature and send the ID unencrypted or land the UA or route around the restricted area. If the UAS looses connectivity to the USS, the privacy feature SHOULD be disabled or land the UA. If the operation is in an area or time with no Internet Connectivity, the privacy feature MUST NOT be used.
Rules for decrypting Operator ID Message content An Observer receives a Operator ID Message with the Operator ID Type field set to 1. The Observer sends a query to its USS Display Provider containing the UA's ID and the encrypted fields. The USS Display Provider MAY deny the request if the Observer does not have the proper authorization. The USS Display Provider MAY reply to the request with the decrypted fields if the Observer has the proper authorization. The USS Display Provider MAY reply to the request with the decrypting key if the Observer has the proper authorization. The Observer MAY notify the USS through its USS Display Provider that content privacy for a UAS in this location/time is not allowed. If the Observer has the proper authorization for this action, the USS notifies the Operator to disable this privacy feature.
Cipher choices for Operator PII encryption
Using AES-CFB32 CFB32 is defined in , Section 6.3. This is the Cipher Feedback (CFB) mode operating on 32 bits at a time. This variant of CFB can be used to encrypt any multiple of 4 bytes of cleartext. The Operator includes a 64 bit UNIX timestamp for the operation time, along with its operation pubic key. The Operator also includes the UA MAC address (or multiple addresses if flying multiple UA). The 128 bit IV for AES-CFB32 is constructed by the Operator and USS as: SHAKE128(MAC|UTCTime|Message_Type, 128). Inclusion of the ASTM Message_Type ensures a unique IV for each Message type that contains PII to encrypt. AES-CFB32 would then be used to encrypt the Operator information.
Using a Feistel scheme If the encryption speed doesn't matter, we can use the following approach based on the Feistel scheme. This approach is already being used in format-preserving encryption (e.g. credit card numbers). The Feistal scheme is explained in .
Using AES-CTR If 2 bytes of the Message can be set aside to contain a counter that is incremented each time the Operator information changes, AES-CTR can be used as follows. The Operator includes a 64 bit UNIX timestamp for the operation time, along with its operation pubic key. The Operator also includes the UA MAC address (or multiple addresses if flying multiple UA). The high order bits of an AES-CTR counter is constructed by the Operator and USS as: SHAKE128(MAC|UTCTime|Message_Type, 112). Inclusion of the ASTM Message_Type ensures a unique IV for each Message type that contains PII to encrypt. AES-CTR would then be used to encrypt the Operator information.
DRIP Requirements addressed This document provides solution to PRIV-1 for PII in the ASTM System Message.
ASTM Considerations ASTM will need to make the following changes to the "Flags" in the System Message (Msg Type 0x4):
Bit 2:
Value 1 for encrypted; 0 for cleartext (see ).
ASTM will need to make the following changes to the "Operator ID Type" in the Operator ID Message (Msg Type 0x5):
Operator ID Type
Value 1 for encrypted Operator ID (see ).
IANA Considerations TBD
Security Considerations An attacker has no known text after decrypting to determine a successful attack. An attacker can make assumptions about the high order byte values for Operator Longitude and Latitude that may substitute for known cleartext. There is no knowledge of where the operator is in relation to the UA. Only if changing location values "make sense" might an attacker assume to have revealed the operator's location.
CFB32 Risks Using the same IV for different Operator information values with CFB32 presents a cyptoanalysis risk. Typically only the low order bits would change as the Operators position changes. The risk is mitigated due to the short-term value of the data. Further analysis is need to properly place risk.
Crypto Agility The ASTM Remote ID Messages do not provide any space for a crypto suite indicator or any other method to manage crypto agility. All crypto agility is left to the USS policy and the relation between the USS and operator/UAS. The selection of the ECIES public key algorithm, the shared secret key derivation function, and the actual symmetric cipher used for on the System Message are set by the USS which informs the operator what to do.
Key Derivation vulnerabilities warns about using Curve25519 and Curve448 in Diffie-Hellman for key derivation: Designers using these curves should be aware that for each public key, there are several publicly computable public keys that are equivalent to it, i.e., they produce the same shared secrets. Thus using a public key as an identifier and knowledge of a shared secret as proof of ownership (without including the public keys in the key derivation) might lead to subtle vulnerabilities. This applies here, but may have broader consequences. Thus two endpoint IDs are included with the Diffie-Hellman secret.
KMAC Security as a KDF Section 4.1 of NIST SP 800-185 states: "The KECCAK Message Authentication Code (KMAC) algorithm is a PRF and keyed hash function based on KECCAK . It provides variable-length output" That is, the output of KMAC is indistinguishable from a random string, regardless of the length of the output. As such, the output of KMAC can be divided into multiple substrings, each with the strength of the function (KMAC128 or KMAC256) and provided that a long enough key is used, as discussed in Sec. 8.4.1 of SP 800-185. For example KMAC128(K, X, 512, S), where K is at least 128 bits, can produce 4 128 bit keys each with a strength of 128 bits. That is a single sponge operation is replacing perhaps 5 HMAC-SHA256 operations (each 2 SHA256 operations) in HKDF.
Standard Specification for Remote ID and Tracking ASTM International
Feistel Scheme This approach is already being used in format-preserving encryption. According to the theory, to provide CCA security guarantees (CCA = Chosen Ciphertext Attacks) for m-bit encryption X |-> Y, we should choose d >= 6. It seems very ineffective that when shortening the block length, we have to use 6 times more block encryptions. On the other hand, we preserve both the block cipher interface and security guarantees in a simple way. m? Enc(X, K): 1. Y <- X. 2. Split Y into 2 equal parts: Y = Y1 || Y2 (let us assume for simplicity that m is even). 3. For i = 1, 2, ..., d do: Y <- Y2 || (Y1 ^ first_m/2_bits(E_K(Y2 || Ci)), where Ci is a (n - m/2)-bit round constant. 4. Y <- Y2 || Y1. 5. Return Y. Dec(Y, K): 1. X <- Y. 2. Split X into 2 equal parts: X = X1 || X2. 3. For i = d, ..., 2, 1 do: X <- X2 || (X1 ^ first_m/2_bits(E_K(X2 || Ci)). 4. X <- X2 || X1. 5. Return X. ]]>
Acknowledgments The recommended ciphers come from discussions on the IRTF CFRG mailing list.
--------------9D11D29971CE2897EA8CE846-- From nobody Wed Oct 6 07:09:21 2021 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 928133A1C71 for ; Wed, 6 Oct 2021 07:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 DmNoqwyVucVF for ; Wed, 6 Oct 2021 07:09:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 5A44A3A1C70 for ; Wed, 6 Oct 2021 07:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1633529347; bh=t9kYGL+1ktb0+0xU+SLbqnc8BKEJ2ttGI1Dx/DJMIWs=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=Nu8fJKbgJqWKwJcRbmASYrIP8h875EXMIAiA+yhrDRUIAJEU1GJ0AJ24Fmyq0gws/ VwMrQN2FgN84jXjzlsva8egKKiKBxitNneJuLFH1eIW7SGWRkw0b5nOL6F58Xv5a9M N1uKwACrOPxqH6VvmrezJlm4HdZWMGouvL5G1q/A= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([5.10.171.186]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MbRk3-1n4hT80X05-00bpcC for ; Wed, 06 Oct 2021 16:09:07 +0200 To: xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> From: Julian Reschke Message-ID: Date: Wed, 6 Oct 2021 16:09:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:MjyKoeGKzYfldJT1ttOh0GLuzG8YNtpGVUfPeKS/GUIiM+nX3CV Gfgsbnho6/s4PJkCq5utHLITTCfH7YF9iFMZq06+WDuTLGXdRKnu+m/7KgNSc2At7hcQ2gl yaxwgd4dnTdiqaHCvr4y+qiNOvzuugkDLiOfK/M0pOf+LOebLlD+a5wHtBveErfEmKgeCME 2JWqx2/4asyvDmqEGkCkg== X-UI-Out-Filterresults: notjunk:1;V03:K0:myBeEOIKDXc=:lNJLMVzz2526/hupbMuOZn ONDN4MD0SJ3/4jayKyTMm6QmU6LFuCbeTIZKzCbsaqo5qYzRW+inOz8zxi9yfBYAg26+2pTOK 5JGC2Ny0K9g1k0aExr95jdbXmwSCFz3Vh/ToW2PwRLYNiGYHUoPpJTQsy/WgEEEPYS9W3ziPt cboqJl+U49rcQUaDEFHRzXs8FsrH8VNL/+1MJ2nH5RKdOvviomBKnF/LECbSPNGRsym/rIP2c 4EQe2hn6/YD4206BW+GjQW+ywnx5oJ7yop7kjhvcG+Pb5QMUkVQizuvQSig679M/Um0k8Syai nqrVX+vpE9fmeFxyZVPnLi4Waafg/YpHqW2NkAU10WRvpLoaJkfY4Mh0sR3m+Dtc0UsHTi8SJ VusJwSh1CixHaoRN+Y/o2EOX4vbuykP3RVewmoW1pbB5qpvkMM3WsJL/LP0JdlfKtVU9eaQ6P jg9Gf7xgEQdYfQn4rKIAhrvRt8JyLsoM2w7w2vMLEE+S8hH/xgOl6WF9xXwrHv5jIkSSSLlM/ pAGWopgdSi6CSEe5Cpt9posTmBCOgx3fjMQ5OBXc4g9HQ0kShtl8+6sf1o9sdbemSfqk5jbo7 cJHdoVFLnHSUeNsQwpGElzg2xeDFcBHKD63FvNqZXZkeFUE8eSu/BdRp5qnRaofcbuGhUS8Ms AyK50VQXq39SWzHCAjzgbip17joMN2FcQQPVIZyRJzjjxC6/6y5K9koI6XCiK+SpjK0GwEyDu zv7Mfxyn9B7p4+ueJDTeIhUvIR8SSX9RPLqovt0mB9rTi0napBzhUctc0ys9d/IJ15Vt3Yx3I KqTkN7budqjBYOQyDpT/MP6ciVlEUhWfbncCmf+OSFczX9DfgKjdUI1tkQD19BEkulU6P+aMz gekuBy8zdFlEd2S18HKNnQSCyYqkBJk2PiENseadGa9wcGk4sNTMIER0yxTqei687jb60Rmyw Mic4UIjpTLfG321G2uVuQ26qwM6JTrgOY91a1xeHRAIbMRjH3T+b9vmg3FY2W6vGJcyHgxN9s 3UMPQXxUEsB1PiNMYRfND6VuqNykrehC05jLxUO8G6sec3DRH7h2uZYJoB7xLQd4jBT0Zhddg d7ORv0SrYQBqzU= Archived-At: Subject: Re: [xml2rfc] Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 14:09:18 -0000 Am 06.10.2021 um 15:56 schrieb Robert Moskowitz: > I am submitting the attached xml draft at > https://datatracker.ietf.org/submit/ > > I get errors like: > > /tmp/draft-moskowitz-drip-operator-privacy-08-lx98crix.xml(0): Error: > IDREF attribute target references an unknown ID "I-D.ietf-drip-reqs", at > None > > I have no problem with the local xml2rfc with the --v3 option or online > at: https://xml2rfc.tools.ietf.org > > What is submit doing wrong??? > > thanks The attached document looks good to me (so far :-), but it seems to be different from the one you are trying to submit... (judging from the filename). Best regards, Julian From nobody Wed Oct 6 07:19:17 2021 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 50EFA3A1C80 for ; Wed, 6 Oct 2021 07:19:15 -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, NICE_REPLY_A=-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 3ZRnTYZ216ps for ; Wed, 6 Oct 2021 07:19:10 -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 716AD3A1C81 for ; Wed, 6 Oct 2021 07:19:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 6E5F16258A; Wed, 6 Oct 2021 10:18:07 -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 xL0HAJxm1qix; Wed, 6 Oct 2021 10:17:59 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 51A076256E; Wed, 6 Oct 2021 10:17:57 -0400 (EDT) To: Julian Reschke , xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> From: Robert Moskowitz Message-ID: <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> Date: Wed, 6 Oct 2021 10:18:49 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 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] Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 14:19:16 -0000 On 10/6/21 10:09 AM, Julian Reschke wrote: > Am 06.10.2021 um 15:56 schrieb Robert Moskowitz: >> I am submitting the attached xml draft at >> https://datatracker.ietf.org/submit/ >> >> I get errors like: >> >> /tmp/draft-moskowitz-drip-operator-privacy-08-lx98crix.xml(0): Error: >> IDREF attribute target references an unknown ID "I-D.ietf-drip-reqs", at >> None >> >> I have no problem with the local xml2rfc with the --v3 option or online >> at: https://xml2rfc.tools.ietf.org >> >> What is submit doing wrong??? >> >> thanks > > The attached document looks good to me (so far :-), but it seems to be > different from the one you are trying to submit... (judging from the > filename). This is strange.  I tried it yet again, and got a different file name there. /tmp/draft-moskowitz-drip-operator-privacy-08-mzufzex8.xml(13): Error: Invalid document before running preptool. In the browse line, the "proper" file name is showing. Something is adding that 8 character piece to the name. From nobody Wed Oct 6 07:25:20 2021 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 82F433A1C84 for ; Wed, 6 Oct 2021 07:25:17 -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, NICE_REPLY_A=-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 nsn28M9ZEqTB for ; Wed, 6 Oct 2021 07:25:13 -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 592123A1C90 for ; Wed, 6 Oct 2021 07:25:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0484C626AF; Wed, 6 Oct 2021 10:24:12 -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 Nhe7u2Y+56IG; Wed, 6 Oct 2021 10:24:08 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id F0E8F6258A; Wed, 6 Oct 2021 10:24:06 -0400 (EDT) From: Robert Moskowitz To: Julian Reschke , xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> Message-ID: <80b98788-2d45-0815-0d5f-d8990d105a67@htt-consult.com> Date: Wed, 6 Oct 2021 10:25:05 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.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 submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 14:25:18 -0000 And I just tried it from a Win system also with Firefox, and got the same failure. Of course with a different 8 char addition to the file name. On 10/6/21 10:18 AM, Robert Moskowitz wrote: > > > On 10/6/21 10:09 AM, Julian Reschke wrote: >> Am 06.10.2021 um 15:56 schrieb Robert Moskowitz: >>> I am submitting the attached xml draft at >>> https://datatracker.ietf.org/submit/ >>> >>> I get errors like: >>> >>> /tmp/draft-moskowitz-drip-operator-privacy-08-lx98crix.xml(0): Error: >>> IDREF attribute target references an unknown ID >>> "I-D.ietf-drip-reqs", at >>> None >>> >>> I have no problem with the local xml2rfc with the --v3 option or online >>> at: https://xml2rfc.tools.ietf.org >>> >>> What is submit doing wrong??? >>> >>> thanks >> >> The attached document looks good to me (so far :-), but it seems to be >> different from the one you are trying to submit... (judging from the >> filename). > > This is strange.  I tried it yet again, and got a different file name > there. > > /tmp/draft-moskowitz-drip-operator-privacy-08-mzufzex8.xml(13): Error: > Invalid document before running preptool. > > In the browse line, the "proper" file name is showing. > > Something is adding that 8 character piece to the name. > > > > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Wed Oct 6 07:25:55 2021 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 1D2EF3A1C91 for ; Wed, 6 Oct 2021 07:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-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 (2048-bit key) header.d=painless-security-com.20210112.gappssmtp.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 YWTfu-Py7T-N for ; Wed, 6 Oct 2021 07:25:47 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 99C233A1C90 for ; Wed, 6 Oct 2021 07:25:47 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id p4so2630756qki.3 for ; Wed, 06 Oct 2021 07:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=painless-security-com.20210112.gappssmtp.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=uNu5fAvEa/ZDhlKjoWhXEP+FoRIYFmtn/zpabIwZodY=; b=4SnQH3HqreDCXCAaX44uUUR5voATmQT15u1ksqfTK1i4+DNnTUrgh5C9mgnY6FIZhQ +EMhBxX+jSJeffvK2WPyB6iNUuOhHL01RIMAYU9F8Y4v8XSVKcZi1yXQvVuLhOiRhZym Ocn2iiam+nVptumy5omldiXYRGPDrsLfubcM8rPpvtaB99Rb4yXK3Ip3AKUkDyyBfWS2 vKC/D6VCnp4+JBUrEIcrV5B+fRelyPsKXzkrDcol0WYafNSrtZ/DTSlnAwSl0JnDLqrO PZ3xw3ZQWRNhdkYKo+ktMZLJtRVChUAwF/ewaOzqMTRL7zWiKb13Dv4s17BMT8QV5GfO zR6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uNu5fAvEa/ZDhlKjoWhXEP+FoRIYFmtn/zpabIwZodY=; b=WzaNROT1iwLz0oIF92HNnyssnN9QKqSvzXeLFtql1dD0z05fx9I5lNE5QcuT26fFiT Zh8JxEIqwgac7KsN5XBwk0r/0mW+lZrYLV93i7HUthxbtoBYFe6WYexApDDAxEm1U/P0 y7L9Wtj9WaAedWo/US7mKtBl4mQu60FHlnTnSMWE3Xas2t2S+VaqKarRpI6k40J3QFsw Iy9gHgedAKQbXhfc0YyLPIQjfxJnqKwv6Beps9KfKon/u4LKPLiegGCdwuicCHSzw1JU sjVWnDlRIK13kRPDuM421BJropClVRsfLTj+C8fNbYOG02x64NmmBwe6je5lB9IDVGfx 4b0A== X-Gm-Message-State: AOAM530hmF86pWMdqS3+W8zgLW6OpeiCjtz6zZfeujJopgVNNfM8iBlR mYDZAILMOAb0UlLe+woZcBGOI5BmhexrE6nB4fDbKBEhBw3hwL7lQf31arklDMZzJjeDZdC03Nr txofms9nxUTMCkcH/t+uCjbhNBbxj5u1FX8hh46cymjQP0J97Jipq+btT08tspcC5hGhacFFTWz THnbo= X-Google-Smtp-Source: ABdhPJzWDiDn9qzUBugDLVDX3EENHDfmbTuOmqW2Wa9miNWL44dRlRRWBp6RCKWtqflQtGib7if8xw== X-Received: by 2002:a37:a413:: with SMTP id n19mr20100425qke.461.1633530345612; Wed, 06 Oct 2021 07:25:45 -0700 (PDT) Received: from [192.168.50.26] (hlfxns016cw-156-34-4-220.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.4.220]) by smtp.gmail.com with ESMTPSA id u189sm11458692qkh.14.2021.10.06.07.25.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 07:25:45 -0700 (PDT) To: xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> From: Jennifer Richards Message-ID: Date: Wed, 6 Oct 2021 11:25:44 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [xml2rfc] Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 14:25:53 -0000 On 10/6/21 11:18 AM, Robert Moskowitz wrote: > > This is strange.  I tried it yet again, and got a different file name > there. > > /tmp/draft-moskowitz-drip-operator-privacy-08-mzufzex8.xml(13): Error: > Invalid document before running preptool. > > In the browse line, the "proper" file name is showing. > > Something is adding that 8 character piece to the name. > The Django file upload mechanism will add the random string like that to a filename if there's a filename collision. From nobody Wed Oct 6 07:30:28 2021 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 B0F653A1CAA for ; Wed, 6 Oct 2021 07:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 hGpqk8ThmVOX for ; Wed, 6 Oct 2021 07:30:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 5CBBD3A1CA8 for ; Wed, 6 Oct 2021 07:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1633530612; bh=fvD30dS9SAVcTC1Ng4ci1X4G1telHByMC621Udf7VA0=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=hdV8btwW3mxkbNqRka7G6Hq2WOcaegfCB/+4lAH5tx1AasMlxsS9HpGRY4QjL6svq DVpZj0u2AixmyZD9RiRAwDQKThcx4s0An9L3fpiI6ZKcynoF8HHMstb+l6MmSldni/ xj8/GB0GRbQOP3EtpDuPYDXu9dutU4CbpKB3VMjY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([5.10.171.186]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MC34h-1mdKak3bmH-00CQdG; Wed, 06 Oct 2021 16:30:11 +0200 To: Robert Moskowitz , xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> From: Julian Reschke Message-ID: Date: Wed, 6 Oct 2021 16:30:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:QQn0gHV73tPir+rAdMfTT19Tsf4DFWYJVw2J9NU3UiPwxnUP03z frzd8o08zmhz0dv5QqubwYbqVv2EU5uq5hYOWZFnEYjZZbObc4sXIzHql8wgORBXxKffisj DNgghdtFs2L1EIXI7sRKH7JpK5h+442/bx6Ksfv7tAtH+6AfHGyGwMb/iVMUQm+V/cf+s8k 627fMmmQkNuveJ3xV0E6A== X-UI-Out-Filterresults: notjunk:1;V03:K0:f1qB36Ch74g=:5t6jYrKaDkvR2BTgWUb0iZ IAUzGIQdQwl7/ViDI/maj+7It8yejnQahuzEU7xkkayTUWsfJKzql8sbmUKKWvTT9w6rCGQm0 VR/3Gb+Wyd5Q5+9cCpG/7hN67UExdz6VEAoNzzhV59Gk65oheNLoU+xu1A/oDYiFTk72kcX1c 3dWO/JU+1wWIDp2y1pP6epHnce/Jaxy2GqEQqeToHveWPCdDE2g7cSfuIJgUxksd3ijdUNjeF Z6KYNxKxyB6mQdz9fAEtUTFhTiUvHL2XK3ui6IG5/DbObBCvHEzWoZ7+tPc9zkBY01a5O12Oh tYDE1TMnINhGxFWKc/ykj6wCdfxkTyVF+eEL9x99PRSbPnAmAkp2OcrhFwsDHCf/YbgHez7M1 35MsYDLhWr3uX87OSE1SCTko2eACGSxLSX9ehL6nQUGKlUbVmT1+/KbY0z3uhx3Q44Yx5gzW5 07xWW2bukdNbw4oUPgqmQhRXLrQ5+wEKQOuCMLdMId9/M1J7xtYSC5VoO975TFdMSwgYdFbsh m+e45ARKV4DQ/mFBrbV3zMPoBhS94uQKIL20hpLxuDpAfG5czYSHWaogwdMtyhPak5Er0Gz6G bozHerMzZTCyRwNczXQyO+E7Y2hzm2McWOvdy7TQ9fP8C4NH2q5xixN8xtU6R+H1a/0oO0sJh u6ckwwKawCJyEaS+LQ0QIGihmCRFyjbwbwJxmkxXx0EsSPQi+lytUTELr9YtnQMmc3Y0k8HoG gipUX7WxCaZHpn4Sodl+xcZUIvzXhTVhPkhham4h6uovz34u9dXosOj9YbPngBXcEcjiYX8Qr EBpZTDGjnbd3iMCDmyENpE924IS2m6FGW4nhwvOz3TY318SgNfFku4QmmU787cDzAH2SZ2bme cQdGn3b/sXXTh0qYxtouQG2s2Hu8/N8z7X5nRasCwDJH9DCu3M88dK25v3p37uiRKyHxYmXPR WSNIdjbXN5ovpFiB8g7M8evq5C/J8NrocJ4mF6SjJDBzxibhYSzjA5JUlf8SnQnzt88iTvnO5 sQ7QMLVuxF+p7ARQl8HcOBCAYUD7H8jsqZNhHTwza9JwMom694bgJ5iFgtuSFLXiRmXSO7BSL sS0p4FQ7WTq0so= Archived-At: Subject: Re: [xml2rfc] Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 14:30:25 -0000 Am 06.10.2021 um 16:18 schrieb Robert Moskowitz: > > > On 10/6/21 10:09 AM, Julian Reschke wrote: >> Am 06.10.2021 um 15:56 schrieb Robert Moskowitz: >>> I am submitting the attached xml draft at >>> https://datatracker.ietf.org/submit/ >>> >>> I get errors like: >>> >>> /tmp/draft-moskowitz-drip-operator-privacy-08-lx98crix.xml(0): Error: >>> IDREF attribute target references an unknown ID "I-D.ietf-drip-reqs", = at >>> None >>> >>> I have no problem with the local xml2rfc with the --v3 option or onlin= e >>> at: https://xml2rfc.tools.ietf.org >>> >>> What is submit doing wrong??? >>> >>> thanks >> >> The attached document looks good to me (so far :-), but it seems to be >> different from the one you are trying to submit... (judging from the >> filename). > > This is strange.=C2=A0 I tried it yet again, and got a different file na= me > there. > > /tmp/draft-moskowitz-drip-operator-privacy-08-mzufzex8.xml(13): Error: > Invalid document before running preptool. > > In the browse line, the "proper" file name is showing. > > Something is adding that 8 character piece to the name. Ah. Probably on purpose, to avoid race conditions in the file system. It seems that the online version fails to resolve the xi:include for that symbol. Getting and pasting it into the source (minus the XML declaration) fixes it for me. (In case you're in a hurry to submit). Best regards, Julian From nobody Wed Oct 6 07:33:45 2021 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 7C2F93A1CC1 for ; Wed, 6 Oct 2021 07:33:42 -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, NICE_REPLY_A=-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 u5BMV5tEI1Dq for ; Wed, 6 Oct 2021 07:33:38 -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 29B403A1CB9 for ; Wed, 6 Oct 2021 07:33:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D18B76258A; Wed, 6 Oct 2021 10:32: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 cak2K5btI05N; Wed, 6 Oct 2021 10:32:30 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 5E4CE6256E; Wed, 6 Oct 2021 10:32:30 -0400 (EDT) To: Julian Reschke , xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> From: Robert Moskowitz Message-ID: Date: Wed, 6 Oct 2021 10:33:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 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] Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 14:33:43 -0000 On 10/6/21 10:30 AM, Julian Reschke wrote: > Am 06.10.2021 um 16:18 schrieb Robert Moskowitz: >> >> >> On 10/6/21 10:09 AM, Julian Reschke wrote: >>> Am 06.10.2021 um 15:56 schrieb Robert Moskowitz: >>>> I am submitting the attached xml draft at >>>> https://datatracker.ietf.org/submit/ >>>> >>>> I get errors like: >>>> >>>> /tmp/draft-moskowitz-drip-operator-privacy-08-lx98crix.xml(0): Error: >>>> IDREF attribute target references an unknown ID >>>> "I-D.ietf-drip-reqs", at >>>> None >>>> >>>> I have no problem with the local xml2rfc with the --v3 option or >>>> online >>>> at: https://xml2rfc.tools.ietf.org >>>> >>>> What is submit doing wrong??? >>>> >>>> thanks >>> >>> The attached document looks good to me (so far :-), but it seems to be >>> different from the one you are trying to submit... (judging from the >>> filename). >> >> This is strange.  I tried it yet again, and got a different file name >> there. >> >> /tmp/draft-moskowitz-drip-operator-privacy-08-mzufzex8.xml(13): Error: >> Invalid document before running preptool. >> >> In the browse line, the "proper" file name is showing. >> >> Something is adding that 8 character piece to the name. > > Ah. > > Probably on purpose, to avoid race conditions in the file system. > > It seems that the online version fails to resolve the xi:include for > that symbol. Getting > and > pasting it into the source (minus the XML declaration) fixes it for me. > (In case you're in a hurry to submit). Well not really in a hurry.  I got all day.   :) Really all week.  Still. It works with https://xml2rfc.tools.ietf.org/ but not the submit tool? Seems something wrong there. From nobody Wed Oct 6 07:37:04 2021 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 4FBBC3A1CE9 for ; Wed, 6 Oct 2021 07:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 Eg7lTiloBrxV for ; Wed, 6 Oct 2021 07:36:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 C94643A1CE5 for ; Wed, 6 Oct 2021 07:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1633531011; bh=/wzDaO3eHVEwIw9UGfMLiHH6JSOO5wwEdnKLdp8U3hc=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=a1vtDk86Z9ryn2g/AhZYyoudQkXBtwhNbmXXtLScQFFOI2Q6+v1r38wFgZbNLaGil XgiVNuD9IXBSHbTWBCzgKhnY4riKvZmzzaKRmMnVHnkWBb0iSjG+nMSYsRpGtw1jre /G0/Zv/qBTNVTk5hRwISveD06HPxCaIoLjSuloHo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([5.10.171.186]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MORAa-1m9RFt1U7y-00PvIR; Wed, 06 Oct 2021 16:36:51 +0200 To: Robert Moskowitz , xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> From: Julian Reschke Message-ID: <783cabcd-77da-9792-558b-3f46b7dc86a7@gmx.de> Date: Wed, 6 Oct 2021 16:36:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:TyA1M/t9Rshph3EMV33nGQDuAsUf3BnDNPC3FjThVX+QzGVsvwa U6vBUfKF5AvQZJSbsLdWe6j2cNqfBBkg/ECWRAtIILKROHG10CG/mooBLg+ygXMH12qkXb2 JzhPMQXCeo+dPcsuL7SjaScpyhKh6zxCkko0UYOZSdZyw+B8c2FpvnlPxwWq4SUo4pWT/sV UgwKAyX3JIDylk9L3sATQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:EXaWBsFFEmI=:3uIj0973hgSBpsN3ENhI0K IhpS2LAHdFoUVn5vJYkE5uUmVg+U6i7JyysRW4gtLOttH5MMNjpZ7xYDu5rqfxMDyb/f9OMVa 3Gz4/0WRS1O0s31s/KkR4f1wa1VtbWyyhly8gpYVOuI5xRwnCHUh8QTG9hc0h8Ad8UqdS1bMY 781AuCcmaaNngHfgKVuU00dTmBEFex923XEOiuWu+knzA7YpDvR5HcKhp0Jl4S2322XTRA47H AXo1RsI0bycOnep14Lc52pDhn8kVZflwnBWjReZs66ppkFVqID1e6dMRHhqF63WUjANjsoHUV 8HlnJ/lP83tVFzY1fvomQPyGHwey8jhLi3Y56DLX9O8h1ymQgZBQB0lFbT3JFOvjFerMiGO1u 05+Bi7Zsvy6P+3ybHjgKv6d0S5o2LKDrO0l+oUzI7UfW3xGzNPJ88xUgTDTCAf/kPQELpnK5j lU4le98G0JXVDg/Y1V1mUefo/MPJC9TWq+wtxMBRSXo6m1XYTADMw9ZGgWbgQ7IJfuRAbv5N5 OfIOO4GP7V/loENUlwH5cuQKet5ztGxjNuKF8KHBWMFdmq7eVWwdNYvWSZstlVVLAnvVvLv6A MhtNEhUHWgRa/vxpdCy8MTNaiLsgtSYGj4HQv2PGZIZpUobPf4KT03WvpwBLABd9RN4j7U816 Gkthsar3QC69GRxMGoaYhcZCXw1F1wpYKfLsc7urTlu/tlrPswfTn0HfENJgerDf7MPKw+WXA p+ajafh3UO9MRFkVejtRwynbTAFq/wkmv+CbEKL1n/cLYpH9adNRHjGKamKVUHLRnJeTchvVB gPYgsd6SBI6NCTy3SBT6WYtVwspIJXWC7h0oBUkgt9fFZnfH24qhWzcIxHpuh3xo09o8jO7oV hN8mGrTTWbS+G44S7L80ncj14xOPTaRfyJv1k4CsRLQrBilr5hKM326Qmg1WXb37UYdhiLZoZ /oQuWjxHAqBFnKJoQaXYuAk9z1j4Wmx3WcbKh4QTzMmLTIgS0y5NB1GaMUF6SOAUJumFqD46h Z+FXowrnEVONB/EyWon+M/xQeDwexzS6rSbdwEx6I5Mqbt2AwxFCxoYsUV/WNCFo3dfqjcfF1 yP+b16onb8Jzy8= Archived-At: Subject: Re: [xml2rfc] Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 14:37:01 -0000 Am 06.10.2021 um 16:33 schrieb Robert Moskowitz: > ... >> Ah. >> >> Probably on purpose, to avoid race conditions in the file system. >> >> It seems that the online version fails to resolve the xi:include for >> that symbol. Getting >> and >> pasting it into the source (minus the XML declaration) fixes it for me. >> (In case you're in a hurry to submit). > > Well not really in a hurry.=C2=A0 I got all day.=C2=A0=C2=A0 :) > Really all week.=C2=A0 Still. > > It works with https://xml2rfc.tools.ietf.org/ but not the submit tool? > > Seems something wrong there. Absolutely. Best regards, Julian From nobody Wed Oct 6 07:42:09 2021 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 53F0E3A1CF9 for ; Wed, 6 Oct 2021 07:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-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 (2048-bit key) header.d=painless-security-com.20210112.gappssmtp.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 B6dxLca4CIUX for ; Wed, 6 Oct 2021 07:40:53 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 152AC3A1CF1 for ; Wed, 6 Oct 2021 07:40:53 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id m13so1004640qvk.1 for ; Wed, 06 Oct 2021 07:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=painless-security-com.20210112.gappssmtp.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=123zmBLXGqDZ2LhjNzpqVOJ7hZlCeViurHk0Ut2uZiM=; b=g2FE2ZdJ/bU2oEkunB2MxrKFuaW/Yj0BIftQa8Qbr9GpiF5+HSUSQDxkH2VQ/hh4zH Jcd0Iq+hjydDUaqBCHGVB19xh7hkz8h3DuS7GdmxEQmr+MEl+pXTjSxzQJORIYmOirhc g/k/4QGczSNgce+LU8qIRAa3tTZN0dyapxESVhLvVO0NXOaAiIdcRWkum/9nyxFZO30R Oj47N5SDzcRrRu8NRNhKiqeblUCKjhiQDlHQezQlvXTiI2oxR39QDaYdtiQzwk0sF97U rNvyvGb3S2Fn+nCITPUUMOF71ojPPrH46afdQEJrpu96Nio0XQno7m6sYXYxohK1Uhvh ahxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=123zmBLXGqDZ2LhjNzpqVOJ7hZlCeViurHk0Ut2uZiM=; b=UB1huSdqWD4AEFxQjpsoy310P4hKIJHbYfAhEw9sgYNuQY8VXA3tANYEXCBJnXNk+b j1ZIcQ2qriaSz/cqbF9JoVnK46+0mY7wewRudRYe7gEsJhTksLFfMqqQ3/BC0kJE9REX 697lvPuf9dYyxRqKHBduURbcj7hp/3ONOKv76qRR/WS9SruY1bWjNvWQkkgpqECssbnc ahRUKpoekXvs9eg7W7w7yLTa2avBMwyezYrvIKF7lIzQS7QKEEaVsnq0ovcg3ZVpMVak 1lHwfbbinuIosxd0S9gcCGbE7BqxMfmCZ79Sd/lzH+17uv48E1NmmkLT1XdrgsQxO1z1 EeCQ== X-Gm-Message-State: AOAM532JrRWFkVRU9v9vF7VJISW9pCT0UZ/dq+QEaJbDDdw6l4BmKl/9 WMoywI0+KiLazLPHk9DtKvde/NLNXFUitwjAtx5EzsXEiOe+b7Wf3K/YfRtUGx3IvCNP2sHng9f YBV4iQn6MFnoAUdefkBMh7fqTXujabt/eiMiwkAov4EA8wtNa2hBpwty5TXi/QYFhOXeb07Boer /7oy0= X-Google-Smtp-Source: ABdhPJzOPqlouF8G9fa2UDSUyuBohrp9yk44a21AiH1ct9s5cW2mk5gI4lmznHNLwcXNNzkRzwmiDg== X-Received: by 2002:a0c:8cc5:: with SMTP id q5mr25001678qvb.52.1633531251472; Wed, 06 Oct 2021 07:40:51 -0700 (PDT) Received: from [192.168.50.26] (hlfxns016cw-156-34-4-220.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.4.220]) by smtp.gmail.com with ESMTPSA id h11sm11454944qkl.32.2021.10.06.07.40.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 07:40:51 -0700 (PDT) To: xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> From: Jennifer Richards Message-ID: Date: Wed, 6 Oct 2021 11:40:50 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.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 Archived-At: Subject: Re: [xml2rfc] Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 14:41:01 -0000 On 10/6/21 11:30 AM, Julian Reschke wrote: >> In the browse line, the "proper" file name is showing. >> >> Something is adding that 8 character piece to the name. > > Ah. > > Probably on purpose, to avoid race conditions in the file system. > The first upload for a given name will appear as uploaded, only subsequent files will be given the random suffix. It seems likely that something is not being cleaned up properly and the datatracker is not properly handling the case where the saved filename is modified. I think that would cause it to ignore the new file and keep trying to process the original file. From nobody Wed Oct 6 08:26:56 2021 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 1A20F3A1DB0 for ; Wed, 6 Oct 2021 08:26:53 -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, NICE_REPLY_A=-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 uTl582sDyLMH for ; Wed, 6 Oct 2021 08:26:47 -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 9A2013A0FDE for ; Wed, 6 Oct 2021 08:26:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 15E5B6258A; Wed, 6 Oct 2021 11:25:45 -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 Yza3zWkqnlZo; Wed, 6 Oct 2021 11:25:37 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id EFBBE6256E; Wed, 6 Oct 2021 11:25:36 -0400 (EDT) To: Julian Reschke , xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> <783cabcd-77da-9792-558b-3f46b7dc86a7@gmx.de> From: Robert Moskowitz Message-ID: <32a996f9-c277-5ac0-00d9-e75fe7e799e1@htt-consult.com> Date: Wed, 6 Oct 2021 11:26:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <783cabcd-77da-9792-558b-3f46b7dc86a7@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 15:26:53 -0000 On 10/6/21 10:36 AM, Julian Reschke wrote: > Am 06.10.2021 um 16:33 schrieb Robert Moskowitz: >> ... >>> Ah. >>> >>> Probably on purpose, to avoid race conditions in the file system. >>> >>> It seems that the online version fails to resolve the xi:include for >>> that symbol. Getting >>> and >>> pasting it into the source (minus the XML declaration) fixes it for me. >>> (In case you're in a hurry to submit). >> >> Well not really in a hurry.  I got all day.   :) >> Really all week.  Still. >> >> It works with https://xml2rfc.tools.ietf.org/ but not the submit tool? >> >> Seems something wrong there. > > Absolutely. So what might be the problem?  ietf-drip-reqs is not yet approved for RFC and thus maybe no longer available as a draft.  Why is the submit script not getting that draft's info? draft-ietf-drip-rid worked back on 9-14 to reference the reqs draft...  :) From nobody Wed Oct 6 09:12:51 2021 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 6813A3A1ECD for ; Wed, 6 Oct 2021 09:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 2fNhEWuAH7Fl for ; Wed, 6 Oct 2021 09:12:43 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.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 5ABC93A1ECC for ; Wed, 6 Oct 2021 09:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1633536759; bh=pOHJOauIPIyLoInqzfQGuzNUT+h4iKRGYe1AjrIi6wQ=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=bD8kI01nukw2yNcul9GAg7I7c2Z3jQsivJqOQkVepsGoskg2R46CT5gCNhvMfM5VR eTVzz7b9We5qbUgU5ZxrpWWrNSRokQHndi+3x0GCJOav3lHAnAtN5rBMAlf+IR2v9r 05gzUhj4XsDE+9AWKVvkZrGcae1Zifwf8zDe6u20= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.20] ([91.61.51.123]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MSt8W-1mMYvJ23A6-00UNLR for ; Wed, 06 Oct 2021 18:12:39 +0200 To: xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> <783cabcd-77da-9792-558b-3f46b7dc86a7@gmx.de> <32a996f9-c277-5ac0-00d9-e75fe7e799e1@htt-consult.com> From: Julian Reschke Message-ID: <783232f2-7e34-72eb-64b5-3050f026b5a0@gmx.de> Date: Wed, 6 Oct 2021 18:12:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <32a996f9-c277-5ac0-00d9-e75fe7e799e1@htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:YzkwPB94NxyKdgss6J3Vz6wIy67U9Hw9jXAeXlIWpQDaXOdlDUZ Mx51//swGkli4HyB87n2H311bOWS/WvyVf8vrhWjYYou/+2tiblF8X07yeoMfm/t7MZHqoQ XHsvdpAbyFUHJ3UtMlyNpSkTnTkcNv1PGin+xbc60SiYh6ZDhxAOJWjd13kDFLIQxUk6+bN s/XGVQ8eIeaSBswwiLaeQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:Apx7VzgUS88=:UOl+r1cQaiIVWZ2ogSI7J/ PngkdMlH2udK0hmdKvU9NLww9xi6jt36Nh/zBLBwAK2avi4Nl2MZ2bZycyHOUy3oDP0ohUCvF YFbcB2qTNSFniMUNMiXoGQTOL6GPr/Wse5v3ZxVC2YV5RqovPqxBXm8B0Oyq9Ej5SSgSnvRxL 90QbEg9WXhTBKNDYTJKHWk0DPPLvAj9Lre8pnQ3jiFirsNPFzW/rRdlr7V/Ai+d0mvI5dPpH9 eH41XeysezTcs/ywvX31KhXs5zKmfGue5a/+CKRpf7bpSwivjz3XAxxG/R6x33k3eHrZFY9xm 0oWaJzXU+1NEp7Y2knVF/q8D3KT8f4LRVCadY+c5gsLxh4yHWyvEi385p+hhTSEbMcOUbdI+h qnFB5RtigapCpE8Suz+HbiLj5lirnu/78WOnbBtyhbWzZ1wOTBJwmzOjps/kP5NCkHYQ6hqms ck52DwZr+cPfoUqp8xp7SZ1Qp1Hsw3USf4fbJINqppybHQcFcJqeWTs20zykex0hSGd4gala1 UnuVqHTsiy8aKW/zTOLfZLaQGj2/eH6iBks+f/9GSFAiB3hVltB783XGDtVbWAExJTQwb8gjA Wqd5VogQ+QL/otovrTI+1IMwGcNfGnIbNnzKg/swsQkFohqlsLC0WSjjcbsLRwvKMiSLzmxFi /ZEzEvXJ2X628ZAM2JkN8k49Z0kIOD5/EoXAti6RPVSzCOC4H9NyIxMYHskNZhFXrCV5V0Htl /Y+39tSMIhz+qlhq+yWtCk+nkE1StAAc9URHVaX/ilS1Fh80vb1GdjvhN/np4eNOi0DHtQ8nT pVnI0ZTWJMOlFBdU4eSO9xoxMClU75hfkt+4YgKB+kGRcYPAaehzRTdLpLtlmLYDV/WB1C35g EdQPTE5J5k4Y0ZyWyx2kt8IJ6ArKtsj5ctN80c3DqYBLNDyHIFAzMPk9QkzOTq02UOOSL20bj YlV8668MnOFwxMl4PdeXKoqzs8ZeiQbPvaFVZ2PrIM7dPaz/UfBWJbkg7ZL+M75EByQZjsa2f wmKHwoZ3ry21vzdDAeopC3DPglopdL4dAbfv7p5DaZMEkOVON4UgKT8M64H3BANQqXhsujoiW i0sSDdyqd7VP6o= Archived-At: Subject: Re: [xml2rfc] Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 16:12:49 -0000 Am 06.10.2021 um 17:26 schrieb Robert Moskowitz: > ... >> Absolutely. > > So what might be the problem?=C2=A0 ietf-drip-reqs is not yet approved f= or > RFC and thus maybe no longer available as a draft.=C2=A0 Why is the subm= it > script not getting that draft's info? > > draft-ietf-drip-rid worked back on 9-14 to reference the reqs draft...= =C2=A0 :) > ... It *is* strange. With a local install of xml2rfc and --expand, the following line apparently gets expanded to: > > > Extensible Prioritization Scheme for HTTP > > Fastly > > > Cloudflare > > > > This document describes a scheme for prioritizing HTTP= responses. > This scheme expresses the priority of each HTTP response using > absolute values, rather than as a relative relationship between a > group of HTTP responses. > > This document defines the Priority header field for communicating the > initial priority in an HTTP version-independent manner, as well as > HTTP/2 and HTTP/3 frames for reprioritizing the responses. These > share a common format structure that is designed to provide future > extensibility. > > > > > > > which of course produces reference errors. After clearing the cache (xml2rfc -C) everything seems to be ok. The simplest explanation would be that at some point the past, had content for a different draft. Or there's a strange bug in xml2rfc. Best regards, Julian From nobody Wed Oct 6 09:56:36 2021 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 A9C713A20BF for ; Wed, 6 Oct 2021 09:56:17 -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 8ZoQPpUSuYMW for ; Wed, 6 Oct 2021 09:56: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 78B9D3A20B6 for ; Wed, 6 Oct 2021 09:55:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 022FD626AF; Wed, 6 Oct 2021 12:54:56 -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 iu2KrYsr2VQ9; Wed, 6 Oct 2021 12:54:48 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 6FA116258A; Wed, 6 Oct 2021 12:54:48 -0400 (EDT) To: Julian Reschke , xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> <783cabcd-77da-9792-558b-3f46b7dc86a7@gmx.de> <32a996f9-c277-5ac0-00d9-e75fe7e799e1@htt-consult.com> <783232f2-7e34-72eb-64b5-3050f026b5a0@gmx.de> From: Robert Moskowitz Message-ID: <62bedd1f-ad3c-1aa6-c9c2-070e33297cd7@htt-consult.com> Date: Wed, 6 Oct 2021 12:55:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <783232f2-7e34-72eb-64b5-3050f026b5a0@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [xml2rfc] Solved? - Re: Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 16:56:24 -0000 I changed:     to:     And it works. Why? On 10/6/21 12:12 PM, Julian Reschke wrote: > Am 06.10.2021 um 17:26 schrieb Robert Moskowitz: >> ... >> Absolutely. >> >> So what might be the problem?  ietf-drip-reqs is not yet approved for >> RFC and thus maybe no longer available as a draft.  Why is the submit >> script not getting that draft's info? >> >> draft-ietf-drip-rid worked back on 9-14 to reference the reqs >> draft...  :) >> ... > > It *is* strange. With a local install of xml2rfc and --expand, the > following line > >   href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs/xml"/> > > > apparently gets expanded to: > >>      > xml:base="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-httpbis-priority/xml"> >>         >>           Extensible Prioritization Scheme for HTTP >>           >>             Fastly >>           >>           >>             Cloudflare >>           >>           >>           >>                This document describes a scheme for prioritizing >> HTTP responses. >>    This scheme expresses the priority of each HTTP response using >>    absolute values, rather than as a relative relationship between a >>    group of HTTP responses. >> >>    This document defines the Priority header field for communicating the >>    initial priority in an HTTP version-independent manner, as well as >>    HTTP/2 and HTTP/3 frames for reprioritizing the responses. These >>    share a common format structure that is designed to provide future >>    extensibility. >> >>             >>           >>         >>         > value="draft-ietf-httpbis-priority-05"/> >>         > target="https://www.ietf.org/archive/id/draft-ietf-httpbis-priority-05.txt"/> >>       > > > which of course produces reference errors. > > After clearing the cache (xml2rfc -C) everything seems to be ok. > > The simplest explanation would be that at some point the past, > had > content for a different draft. Or there's a strange bug in xml2rfc. > > Best regards, Julian > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Wed Oct 6 11:20:56 2021 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 8C0663A00C4 for ; Wed, 6 Oct 2021 11:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 bZ3CqYjzECyf for ; Wed, 6 Oct 2021 11:20:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.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 7E46E3A00C1 for ; Wed, 6 Oct 2021 11:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1633544441; bh=cbnt+jzMs1dI5GoRqgqKFPta7lpccwikmsDW4dphGxc=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=lve0KhcWizs4N69i+R8xoYbIBhdB8dmgYaMo3qVcnl5H0iwsw2icNlzQMXNcyN5sH QoofYYKJPCtRuQS5V7fdiYE8Rks/8T9HvHVWCxvi2amYXl0BgnhXyNkk9368x25Fm9 R2CoYqQYKMiRyUryfK9kOa+Zwn9XKR5sCM+6IB/w= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.20] ([91.61.51.123]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N8ofE-1mtPpf18r8-015o7H; Wed, 06 Oct 2021 20:20:41 +0200 To: Robert Moskowitz , xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> <783cabcd-77da-9792-558b-3f46b7dc86a7@gmx.de> <32a996f9-c277-5ac0-00d9-e75fe7e799e1@htt-consult.com> <783232f2-7e34-72eb-64b5-3050f026b5a0@gmx.de> <62bedd1f-ad3c-1aa6-c9c2-070e33297cd7@htt-consult.com> From: Julian Reschke Message-ID: Date: Wed, 6 Oct 2021 20:20:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <62bedd1f-ad3c-1aa6-c9c2-070e33297cd7@htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:eVCtq/redEK+hleDn6pAg8siKNvmeOOnRH/kJuYDW30QNJD2Uqe gjkqcprjG5sbbs+lwgEkan8TpW2RCsRiEajVvUczkrAXaqywglVc+okfsCm8UKhFYyXN13A aqCGRX9eDonnk8ayycyio1TJv6M8/VzX/7uUUGprN1ePOdRL2MJ6DHVreXOaQuYv5yeVkJM vUJMb0x/WuqblI1s3zHfw== X-UI-Out-Filterresults: notjunk:1;V03:K0:Hhx6Yys0ay4=:mAlcQToIfwpvzqM2h5K6aN ST7Kj+WC+wv64wwd2ZTKyPzt2DQ+xPE1/kEzV8aaiqmU5CRKkSvYmnlTJAmj2HGeIPhigoGIb rQQu3BTgZ+qsfYc7oo1lA+MkEMpA1sDJNF3F/W242LtRqkaoJPSb3RDz34UoAI0J3fCShru/2 7vPZtupF4pEAriynG6TGvEDu2SDkNNZVhi/7CS3cGv3TGyc1Z6ugXGJNFomOq/bWLAiEVdrui 0/AwRakMGXU7sS09LHTgmvDzhPuDFlwLiPjsikJawt/qDLRpkm4bPhqbwQ494PdvJAoBC0+Gg gJi2UiYoCGscTIdeJ5qrmgXXepiVeqnnfQmzFC1aOepv/QNHPRt4iVx0qef0iufzNKVDf1MK2 WqFFZeAqDWHiV0VGqDikcHVcLfiuhHS+mnmTmU3rl5nzEiw5VLZOdLFXAP/8A2IMANZ2gUBWD WDLCpNaEfaGuIIPfZ+DuOEJhKJgCfsGjHGY2wIQceSbJNlUFYq0RsxiW8i6hlGwRXD7Lef+6f QUHVIr7fRMrrg2O25kCJ4aEydBtHrmXpRJZc9xn2xgeixnAoxqjn8/nc76QUSG+iDfTqBJ62M FFoAzst33HrfKLFjW/CjvKJGnQlgVK4PbEWDcBDavKe1Gz+9918lv6aCka0R1LTc5HK/OH096 X/zRLW3qdMAWvH4rUZAD+8xOd34aoMkPZr7YgUOAVtaq+lZEdQG2IEITUPOVx0o3CSx6ez4Hp QE6mn737bZlrsSqkbrf7m3zLkQlI2ec8y+AfOUefhW3ppsxxqHDWfFgVJoP/OlB2AaD7ZizUa oKdde2MBwNYQj4fjYWdYoM7yScmzH7Tm3tV9Y1OG0K2yKQOfpUTDxOaSWwKliYIBj9Wktdy6/ 2GUK/7mGKDKEuy3XthAWsh3DD8tyL+TQm7KKWTNZGJ4bDHivJzkEghVQWxkkyeJiIDNABmgKJ xtyzjKie5GtqRA+z8aAe38md7p+hoIScOQ0GvpWkCCi1lUOPQ2AL4OOwjN/R0S/QUWliG7dYE ZXRfy0YF9KUO4O2rOrqIjs/8gSmzXx2VlowvSqmH377DhsY5d1sPLvRQWNo4Fq8qoU7FuBgHM 9ezZzwyF2ntEEo= Archived-At: Subject: Re: [xml2rfc] Solved? - Re: Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 18:20:55 -0000 Am 06.10.2021 um 18:55 schrieb Robert Moskowitz: > I changed: > > =C2=A0=C2=A0=C2=A0 href=3D"https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs/xm= l"/> > > to: > > =C2=A0=C2=A0=C2=A0 href=3D"https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.= ietf-drip-reqs.xml"/> > > > And it works. > > Why? > ... If the theory about a bad file/cache entry is correct, then of course changing to a different URI will solve that. Best regards, Julian From nobody Wed Oct 6 15:54:34 2021 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 91CA63A0860 for ; Wed, 6 Oct 2021 15:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 40_0KVwPrjwZ for ; Wed, 6 Oct 2021 15:54:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E5B7B3A085F for ; Wed, 6 Oct 2021 15:54:27 -0700 (PDT) Received: from unformal.local ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 196MsCUh059367 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 6 Oct 2021 17:54:13 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1633560853; bh=IZ3O6amb0QOIapfc52WUz9IHNMVD3cgRQVKqkXPX4fg=; h=To:References:From:Subject:Date:In-Reply-To; b=F3Jgp1DHeOFMCNrOdJBNo6bTnUT3usRxkgM9+6yeN3nERyT9ookdS1BBU234KOCIM wFAIjbCKIptIr1zNM0O0Sn+8/aEd2u8lH0WoKL0UiUKkduX6oTbqgMIUDi2X5Qv4+H e1eOEQBufECpZ17usrvTCJ2wpndR5ZQckFa0O9Fw= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be unformal.local To: Julian Reschke , Robert Moskowitz , xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> <783cabcd-77da-9792-558b-3f46b7dc86a7@gmx.de> <32a996f9-c277-5ac0-00d9-e75fe7e799e1@htt-consult.com> <783232f2-7e34-72eb-64b5-3050f026b5a0@gmx.de> <62bedd1f-ad3c-1aa6-c9c2-070e33297cd7@htt-consult.com> From: Robert Sparks Message-ID: Date: Wed, 6 Oct 2021 17:54:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Solved? - Re: Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 22:54:33 -0000 Right this second,=20 https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs/xml=20 expands to what looks like the right thing. There is a possible hint in the existence of a file named simply 'xml'=20 in the xml2rfc cache directory that the datatracker submit function=20 uses, that has the odd content Julian points to (it's from 23Sep fwiw). Also reference.I-D.ietf-drip-reqs.xml in that cache directory has=20 content that reflects the drip-reqs draft. We'll go look through the xml2rfc code to see what codepath that might=20 result in reading/writing a filename as simply "xml", which is my best=20 current guess as to what Bob ran into. RjS On 10/6/21 1:20 PM, Julian Reschke wrote: > Am 06.10.2021 um 18:55 schrieb Robert Moskowitz: >> I changed: >> >> =C2=A0=C2=A0=C2=A0=C2=A0 > href=3D"https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs/= xml"/>=20 >> >> >> to: >> >> =C2=A0=C2=A0=C2=A0=C2=A0 > href=3D"https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-= D.ietf-drip-reqs.xml"/>=20 >> >> >> >> And it works. >> >> Why? >> ... > > If the theory about a bad file/cache entry is correct, then of course > changing to a different URI will solve that. > > Best regards, Julian > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Wed Oct 6 16:13:08 2021 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 2C0533A0980 for ; Wed, 6 Oct 2021 16:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 4Z_CzUzLgxMi for ; Wed, 6 Oct 2021 16:13:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C2EC73A0982 for ; Wed, 6 Oct 2021 16:13:02 -0700 (PDT) Received: from unformal.local ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 196NCpXN062970 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 6 Oct 2021 18:12:51 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1633561972; bh=sC1eDCXMWtlxealMGvpHERKM63d34oHT+0X2t4D2F24=; h=Subject:From:To:References:Date:In-Reply-To; b=W3StyoKV6ejIKAEQzo9Ur4ZlE1ak3cwF3sJGLFJvVChLQ7IxUd/7BQi3SxAegO1/j q8+97/mIa+hM4h5823eFba6kt/Zgj4dx6jC1iK/5gvuZiycTWYR+aKFqczHf48cd3f 5VAGzoUXA0okhTBrpaAjcVlE91+JnbrzZC/QKWjA= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be unformal.local From: Robert Sparks To: Julian Reschke , Robert Moskowitz , xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> <783cabcd-77da-9792-558b-3f46b7dc86a7@gmx.de> <32a996f9-c277-5ac0-00d9-e75fe7e799e1@htt-consult.com> <783232f2-7e34-72eb-64b5-3050f026b5a0@gmx.de> <62bedd1f-ad3c-1aa6-c9c2-070e33297cd7@htt-consult.com> Message-ID: <22ce0472-2c5a-979f-4dbf-26addff513a5@nostrum.com> Date: Wed, 6 Oct 2021 18:12:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.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] Solved? - Re: Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 23:13:07 -0000 (And I did remove that stray file from the cache) On 10/6/21 5:54 PM, Robert Sparks wrote: > Right this second, > https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs/xml > expands to what looks like the right thing. > > There is a possible hint in the existence of a file named simply 'xml' > in the xml2rfc cache directory that the datatracker submit function > uses, that has the odd content Julian points to (it's from 23Sep fwiw). > > Also reference.I-D.ietf-drip-reqs.xml in that cache directory has > content that reflects the drip-reqs draft. > > We'll go look through the xml2rfc code to see what codepath that might > result in reading/writing a filename as simply "xml", which is my best > current guess as to what Bob ran into. > > RjS > > On 10/6/21 1:20 PM, Julian Reschke wrote: >> Am 06.10.2021 um 18:55 schrieb Robert Moskowitz: >>> I changed: >>> >>>      >> href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs/xml"/> >>> >>> >>> to: >>> >>>      >> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-drip-reqs.xml"/> >>> >>> >>> >>> And it works. >>> >>> Why? >>> ... >> >> If the theory about a bad file/cache entry is correct, then of course >> changing to a different URI will solve that. >> >> Best regards, Julian >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc > From nobody Wed Oct 6 16:47:41 2021 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 171A13A0AE7 for ; Wed, 6 Oct 2021 16:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 6crjDC44IxIP for ; Wed, 6 Oct 2021 16:47:35 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B87B33A0AC1 for ; Wed, 6 Oct 2021 16:47:35 -0700 (PDT) Received: from unformal.local ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 196NlQ6l069550 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 6 Oct 2021 18:47:26 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1633564047; bh=CrR+zuS/vrDcQVnwC25xysPmnrb1jMqiuD5c/iDia58=; h=From:To:References:Subject:Date:In-Reply-To; b=UjzFoYSNYpU8IFqLUYmtWEroY7lSOKmNxeA9sIA0QguLJ8Gl4myldD2fXRHHwgL2n NEUV00sOHkYKdGh704tWWCiKaphMabNlwTVU3IKcdQK7tPP0HpOTrTFyZsHwpIH7kM ntKeGYD30TVSHkYJO4v1RR+ISZS/kkxkhZ132M64= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be unformal.local From: Robert Sparks To: Julian Reschke , Robert Moskowitz , xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> <783cabcd-77da-9792-558b-3f46b7dc86a7@gmx.de> <32a996f9-c277-5ac0-00d9-e75fe7e799e1@htt-consult.com> <783232f2-7e34-72eb-64b5-3050f026b5a0@gmx.de> <62bedd1f-ad3c-1aa6-c9c2-070e33297cd7@htt-consult.com> <22ce0472-2c5a-979f-4dbf-26addff513a5@nostrum.com> Message-ID: <2ddaab60-1e78-59a9-18ff-ff3dd239632f@nostrum.com> Date: Wed, 6 Oct 2021 18:47:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <22ce0472-2c5a-979f-4dbf-26addff513a5@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Solved? - Re: Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 23:47:40 -0000 Ah - So, the reference bob should have been using is=20 https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs.xml that is _dot_ xml instead of _slash_ xml. That the /xml variant worked at the datatracker was unintended, and it's = directly leading to the issue that's appearing in cache. RjS p.s. - the thing that let the slash work at the bibxml endpoint is the=20 failure to escape the . in this regexp: =C2=A0=C2=A0=C2=A0 url(r'^bibxml3/%(name)s(?:-%(rev)s)?.xml$' % settings= =2EURL_REGEXPS,=20 views_doc.document_bibxml), On 10/6/21 6:12 PM, Robert Sparks wrote: > (And I did remove that stray file from the cache) > > On 10/6/21 5:54 PM, Robert Sparks wrote: >> Right this second,=20 >> https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs/xml=20 >> expands to what looks like the right thing. >> >> There is a possible hint in the existence of a file named simply=20 >> 'xml' in the xml2rfc cache directory that the datatracker submit=20 >> function uses, that has the odd content Julian points to (it's from=20 >> 23Sep fwiw). >> >> Also reference.I-D.ietf-drip-reqs.xml in that cache directory has=20 >> content that reflects the drip-reqs draft. >> >> We'll go look through the xml2rfc code to see what codepath that=20 >> might result in reading/writing a filename as simply "xml", which is=20 >> my best current guess as to what Bob ran into. >> >> RjS >> >> On 10/6/21 1:20 PM, Julian Reschke wrote: >>> Am 06.10.2021 um 18:55 schrieb Robert Moskowitz: >>>> I changed: >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 >>> href=3D"https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-req= s/xml"/>=20 >>>> >>>> >>>> to: >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 >>> href=3D"https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.= I-D.ietf-drip-reqs.xml"/>=20 >>>> >>>> >>>> >>>> And it works. >>>> >>>> Why? >>>> ... >>> >>> If the theory about a bad file/cache entry is correct, then of course= >>> changing to a different URI will solve that. >>> >>> Best regards, Julian >>> >>> _______________________________________________ >>> xml2rfc mailing list >>> xml2rfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/xml2rfc >> > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Wed Oct 6 18:27:48 2021 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 1FFCF3A0E3A for ; Wed, 6 Oct 2021 18:27:47 -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 2kM48ifqhp02 for ; Wed, 6 Oct 2021 18:27:42 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F963A0E4A for ; Wed, 6 Oct 2021 18:27:41 -0700 (PDT) Received: from smtpclient.apple (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HPtwk2D1Cz2xjm; Thu, 7 Oct 2021 03:27:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: <2ddaab60-1e78-59a9-18ff-ff3dd239632f@nostrum.com> Date: Thu, 7 Oct 2021 03:27:33 +0200 Cc: Julian Reschke , Robert Moskowitz , xml2rfc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> <783cabcd-77da-9792-558b-3f46b7dc86a7@gmx.de> <32a996f9-c277-5ac0-00d9-e75fe7e799e1@htt-consult.com> <783232f2-7e34-72eb-64b5-3050f026b5a0@gmx.de> <62bedd1f-ad3c-1aa6-c9c2-070e33297cd7@htt-consult.com> <22ce0472-2c5a-979f-4dbf-26addff513a5@nostrum.com> <2ddaab60-1e78-59a9-18ff-ff3dd239632f@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [xml2rfc] Solved? - Re: Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 01:27:47 -0000 On 7. Oct 2021, at 01:47, Robert Sparks wrote: >=20 > Ah - >=20 > So, the reference bob should have been using is = https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs.xml >=20 > that is _dot_ xml instead of _slash_ xml. >=20 > That the /xml variant worked at the datatracker was unintended, and = it's directly leading to the issue that's appearing in cache. Thanks. I just pushed a fix for kramdown-rfc that no longer uses the = /xml form (1.5.8). In case some documentation needs to be updated, I tried to find where I = picked up the /xml form. I used it in a private email I sent *to* Henrik on 2020-02-11. I haven=E2=80=99t found the message where I actually learned about the = datatracker feature (which must have used /xml). (BTW: kramdown-rfc-cache-i-d-bibxml was bulk-updating from =E2=80=A6/xml = all the time, and I never saw that caching glitch we had today.) Gr=C3=BC=C3=9Fe, Carsten >=20 > RjS >=20 > p.s. - the thing that let the slash work at the bibxml endpoint is the = failure to escape the . in this regexp: >=20 > url(r'^bibxml3/%(name)s(?:-%(rev)s)?.xml$' % settings.URL_REGEXPS, = views_doc.document_bibxml), >=20 >=20 > On 10/6/21 6:12 PM, Robert Sparks wrote: >> (And I did remove that stray file from the cache) >>=20 >> On 10/6/21 5:54 PM, Robert Sparks wrote: >>> Right this second, = https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs/xml = expands to what looks like the right thing. >>>=20 >>> There is a possible hint in the existence of a file named simply = 'xml' in the xml2rfc cache directory that the datatracker submit = function uses, that has the odd content Julian points to (it's from = 23Sep fwiw). >>>=20 >>> Also reference.I-D.ietf-drip-reqs.xml in that cache directory has = content that reflects the drip-reqs draft. >>>=20 >>> We'll go look through the xml2rfc code to see what codepath that = might result in reading/writing a filename as simply "xml", which is my = best current guess as to what Bob ran into. >>>=20 >>> RjS >>>=20 >>> On 10/6/21 1:20 PM, Julian Reschke wrote: >>>> Am 06.10.2021 um 18:55 schrieb Robert Moskowitz: >>>>> I changed: >>>>>=20 >>>>> >>>> = href=3D"https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs/xml"= />=20 >>>>>=20 >>>>> to: >>>>>=20 >>>>> >>>> = href=3D"https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ie= tf-drip-reqs.xml"/>=20 >>>>>=20 >>>>>=20 >>>>> And it works. >>>>>=20 >>>>> Why? >>>>> ... >>>>=20 >>>> If the theory about a bad file/cache entry is correct, then of = course >>>> changing to a different URI will solve that. >>>>=20 >>>> Best regards, Julian >>>>=20 >>>> _______________________________________________ >>>> xml2rfc mailing list >>>> xml2rfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/xml2rfc >>>=20 >>=20 >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Wed Oct 6 23:55:26 2021 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 CF2EB3A093B for ; Wed, 6 Oct 2021 23:55: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 W3zh3steRAII for ; Wed, 6 Oct 2021 23:55:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 7F59E3A0965 for ; Wed, 6 Oct 2021 23:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1633589692; bh=+cq7mHsJvnn9C3vjwV6W2yHJ3vXhkEvH5cxHnZ6RrzQ=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=e35Udc8Qy5kLk8KkRKCROSVYpJSDVDBjOryheig5gzxt6TJNou4ENYJ1piAGuB5hN Ugw3Dk92Xy1J1XjCSldnlp2AsZdnZZjthzan5g8SLW8DfYRb8JDBJGOcnbkNaE9fji g/jNxlcMVR9xrSG3n3RpjB0efHswg2uOmwjKCH7A= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.20] ([91.61.50.17]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mi2Nv-1n3I8T0dWr-00e1ft; Thu, 07 Oct 2021 08:54:52 +0200 To: Robert Sparks , Robert Moskowitz , xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> <783cabcd-77da-9792-558b-3f46b7dc86a7@gmx.de> <32a996f9-c277-5ac0-00d9-e75fe7e799e1@htt-consult.com> <783232f2-7e34-72eb-64b5-3050f026b5a0@gmx.de> <62bedd1f-ad3c-1aa6-c9c2-070e33297cd7@htt-consult.com> <22ce0472-2c5a-979f-4dbf-26addff513a5@nostrum.com> <2ddaab60-1e78-59a9-18ff-ff3dd239632f@nostrum.com> From: Julian Reschke Message-ID: <2e2cbf40-e100-52e8-e1fa-cde9f49758d3@gmx.de> Date: Thu, 7 Oct 2021 08:54:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <2ddaab60-1e78-59a9-18ff-ff3dd239632f@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:bklZD8besOsVjpaL8XiIy6x8XOwSM0FgR3UiyIWvLP+w0LpIrOs b6iStK0PNjdLXTZU7NoYVgzV6TxMN2ilaZue4kn57ZAwj/pvhMqIsG+I9F4ShH91ISjm2fq OgoEBbr2M6e5+Ay6kXFXY1W62NiJQubxi62k4982xtZAzJoAnVwwkQFOsggfFuaz9Rfa4DY QzKhZi/1l2W1KLM/C2suw== X-UI-Out-Filterresults: notjunk:1;V03:K0:8u6GTUf87UU=:5VcISaaZyi7qklL8p8kvXD 54CAjKTkkDlqx5B0KDxnJwOlc+QBqz5uN3f0KdsVuzqFO0bB+axi6noKgBI3Po/kXiXVlkwOf Lo4GyYGkGSssv9tt8UfOINQDeXnk0Sc8vEsylAR6J7ty7gQxYm6jfp3VIuoaIP2674on10S2s TvkmZE6A5lcTnSh7LXEU+t85IIzrfQZF8G5xs3YPD7Ju3ZZ5yd2jmVHUyAiuXd5L6r7Z2RK07 Pq4PjoVuHWtSyZxp8rKxayfhl8gbaoHksXfW3b68KMOsIsvUkEtYITeSKUITykvSpJ+PXY1Zn 0jc+b3bnNUIvZoCMqbFgvxjj0g7nDlNl03weV5O9XASQisSuVkRoN34e1RAYl94/aT4o2pA3H YwdKVvFMmjYOpLnf2d2QwNa7+89y3nrL0CuhNh+ymL6LxVrBnEU7AhRE9SNExFYfAp6yOXh0h sXnaxvOcoQo96P23HRotsMUG0gl46SCxG+BF2/gmTI8sK1IxiMSy1ELNB+7BJd446zk1TVRfG I3KGvjNR7j6dAk4YkKPiSu6cjByAJk6ARwyLuPEUKdkHpqFhPOsDXBQ7bFMQIi6lQyYZ4aL9x sey0HW6643y//NLFVlZZTOyL2jsayqEfoJ1mxn84BylAtCNX5TS2tEK8TiMJar7zhkGQkUOPG 8+ewH1UYm1858vwSJaV08rI5H4KbUNukL95/wQnrbPisQ9rj49kuUPL+oGBVZzwM77Cq7uK0W ADKm2WnpFCjlZ8a5ABot1ptRJgi1pG8Tbe+66RJkFcwbquhTaPqjuLLGPcTeec21T6mJ9jAlg 0+nmSCxuuCT2B5cZCk+StejHWs6NOMDi3LSFL/Xs4kuZv1WaBxMSVnfbmCUnkJ+L0pEvtLzfu geU9U5F9CBYsh9xNva2wOkPw75jdtpP4GyzXRoU/zkrQWAu3+oEWw3YDqLScB6ejV6MhrXtlx 6sSEvkOuWBMo3DD7N0jen2EKQfCmDcugVwvBjBTWfVKG5MveGg7PHfLvI9LanxaPdUF7aJzQQ tIhVLXmW5lUquWHTukhVMglJCdk5F7P+Qozb3AfSmoMfRTJeIVa5/0DHombuqfEcE2xfd8/Nz J3bpvkLtspRCoE= Archived-At: Subject: Re: [xml2rfc] Solved? - Re: Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 06:55:24 -0000 Am 07.10.2021 um 01:47 schrieb Robert Sparks: > Ah - > > So, the reference bob should have been using is > https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs.xml > > that is _dot_ xml instead of _slash_ xml. > > That the /xml variant worked at the datatracker was unintended, and it's > directly leading to the issue that's appearing in cache. > > RjS > > p.s. - the thing that let the slash work at the bibxml endpoint is the > failure to escape the . in this regexp: > > =C2=A0=C2=A0=C2=A0 url(r'^bibxml3/%(name)s(?:-%(rev)s)?.xml$' % setting= s.URL_REGEXPS, > views_doc.document_bibxml), Thanks a lot for the quick analysis! Best regards, Julian From nobody Thu Oct 7 02:54:05 2021 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 4E6203A0C29 for ; Thu, 7 Oct 2021 02:54:03 -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 PCsPgaRAjRWP for ; Thu, 7 Oct 2021 02:53:58 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7D43A0C81 for ; Thu, 7 Oct 2021 02:53:58 -0700 (PDT) Received: from [192.168.217.118] (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HQ68x1dRTz2xhD; Thu, 7 Oct 2021 11:53:53 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <2e2cbf40-e100-52e8-e1fa-cde9f49758d3@gmx.de> Date: Thu, 7 Oct 2021 11:53:52 +0200 Cc: Robert Sparks , Robert Moskowitz , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 655293232.534394-fe9ffddf4be33986f762fa9e779f491c Content-Transfer-Encoding: quoted-printable Message-Id: <18D77244-42BB-4229-B8E2-CC2959EAC53D@tzi.org> References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> <783cabcd-77da-9792-558b-3f46b7dc86a7@gmx.de> <32a996f9-c277-5ac0-00d9-e75fe7e799e1@htt-consult.com> <783232f2-7e34-72eb-64b5-3050f026b5a0@gmx.de> <62bedd1f-ad3c-1aa6-c9c2-070e33297cd7@htt-consult.com> <22ce0472-2c5a-979f-4dbf-26addff513a5@nostrum.com> <2ddaab60-1e78-59a9-18ff-ff3dd239632f@nostrum.com> <2e2cbf40-e100-52e8-e1fa-cde9f49758d3@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [xml2rfc] Solved? - Re: Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 09:54:04 -0000 On 2021-10-07, at 08:54, Julian Reschke wrote: >=20 >> url(r'^bibxml3/%(name)s(?:-%(rev)s)?.xml$' % = settings.URL_REGEXPS, >> views_doc.document_bibxml), >=20 > Thanks a lot for the quick analysis! I think we knew about this bug (accepting /xml) for a while, but it = wasn=E2=80=99t fixed because the /xml form was in use. We didn=E2=80=99t = know that this can lead to the caching bug, and given that we now have = experienced it, the choice is (1) disabling /xml, maybe with some transition time (2) fixing the caching bug The caching bug doesn=E2=80=99t seem to occur in normal operation of = kramdown-rfc, which has been using /xml by default for about half a year = now (fixed in 1.5.8). I suspect an interaction between the xinclude function of the submission = interface and the caching logic made this bug appear with Bob=E2=80=99s = input =E2=80=94 the submission input generated by kramdown-rfc output = does not exercise xinclude, so we wouldn=E2=80=99t have noticed the = caching bug. Note that kramdown-rfc does not typically create an error when it gets = the wrong answer (if the caching bug were triggered by it), as it = ignores the anchor=3D attribute (replacing it with an anchor chosen by = the author, which for historical reasons defaults to what *should* be in = the reference XML). But of course the wrong output should be visible in = the draft=E2=80=99s bibliography. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 7 03:06:27 2021 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 0D9983A0CAF for ; Thu, 7 Oct 2021 03:06:24 -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, NICE_REPLY_A=-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 o2XETKOWz13l for ; Thu, 7 Oct 2021 03:06: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 D41A53A0CAE for ; Thu, 7 Oct 2021 03:06:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id DD6CE6258A; Thu, 7 Oct 2021 06:05: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 1ksy8P6H8-lx; Thu, 7 Oct 2021 06:05:08 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 7580B624C7; Thu, 7 Oct 2021 06:05:06 -0400 (EDT) To: Robert Sparks , Julian Reschke , xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> <783cabcd-77da-9792-558b-3f46b7dc86a7@gmx.de> <32a996f9-c277-5ac0-00d9-e75fe7e799e1@htt-consult.com> <783232f2-7e34-72eb-64b5-3050f026b5a0@gmx.de> <62bedd1f-ad3c-1aa6-c9c2-070e33297cd7@htt-consult.com> <22ce0472-2c5a-979f-4dbf-26addff513a5@nostrum.com> <2ddaab60-1e78-59a9-18ff-ff3dd239632f@nostrum.com> From: Robert Moskowitz Message-ID: <5f27c325-dca1-183f-02e2-6ff8a40acc24@htt-consult.com> Date: Thu, 7 Oct 2021 06:05:57 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <2ddaab60-1e78-59a9-18ff-ff3dd239632f@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Solved? - Re: Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 10:06:24 -0000 I got a comment on the latest ver and I will be making an update soon. Hopefully this week, after I figure out the best way to fix the crypto.  I really don't want to use CFB16, but I might not have a choice... So I will also make this fix. On 10/6/21 7:47 PM, Robert Sparks wrote: > Ah - > > So, the reference bob should have been using is > https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs.xml > > that is _dot_ xml instead of _slash_ xml. > > That the /xml variant worked at the datatracker was unintended, and > it's directly leading to the issue that's appearing in cache. > > RjS > > p.s. - the thing that let the slash work at the bibxml endpoint is the > failure to escape the . in this regexp: > >     url(r'^bibxml3/%(name)s(?:-%(rev)s)?.xml$' % settings.URL_REGEXPS, > views_doc.document_bibxml), > > > On 10/6/21 6:12 PM, Robert Sparks wrote: >> (And I did remove that stray file from the cache) >> >> On 10/6/21 5:54 PM, Robert Sparks wrote: >>> Right this second, >>> https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs/xml >>> expands to what looks like the right thing. >>> >>> There is a possible hint in the existence of a file named simply >>> 'xml' in the xml2rfc cache directory that the datatracker submit >>> function uses, that has the odd content Julian points to (it's from >>> 23Sep fwiw). >>> >>> Also reference.I-D.ietf-drip-reqs.xml in that cache directory has >>> content that reflects the drip-reqs draft. >>> >>> We'll go look through the xml2rfc code to see what codepath that >>> might result in reading/writing a filename as simply "xml", which is >>> my best current guess as to what Bob ran into. >>> >>> RjS >>> >>> On 10/6/21 1:20 PM, Julian Reschke wrote: >>>> Am 06.10.2021 um 18:55 schrieb Robert Moskowitz: >>>>> I changed: >>>>> >>>>>      >>>> href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs/xml"/> >>>>> >>>>> >>>>> to: >>>>> >>>>>      >>>> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-drip-reqs.xml"/> >>>>> >>>>> >>>>> >>>>> And it works. >>>>> >>>>> Why? >>>>> ... >>>> >>>> If the theory about a bad file/cache entry is correct, then of course >>>> changing to a different URI will solve that. >>>> >>>> Best regards, Julian >>>> >>>> _______________________________________________ >>>> xml2rfc mailing list >>>> xml2rfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/xml2rfc >>> >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc > From nobody Thu Oct 7 07:11:47 2021 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 8F19B3A05DE for ; Thu, 7 Oct 2021 07:11:44 -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, NICE_REPLY_A=-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 LyvM82ZVPR9o for ; Thu, 7 Oct 2021 07:11:40 -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 70B993A091E for ; Thu, 7 Oct 2021 07:10:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0429F626AF; Thu, 7 Oct 2021 10:09:53 -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 Qw1wArrR89ts; Thu, 7 Oct 2021 10:09:47 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 38ABA624C7; Thu, 7 Oct 2021 10:09:47 -0400 (EDT) To: Robert Sparks , Julian Reschke , xml2rfc@ietf.org References: <3883cc94-013e-7ea3-8d8d-89ab5d12bc11@htt-consult.com> <408b7ef7-eb96-63ea-6b5a-e33406f7bbd2@htt-consult.com> <783cabcd-77da-9792-558b-3f46b7dc86a7@gmx.de> <32a996f9-c277-5ac0-00d9-e75fe7e799e1@htt-consult.com> <783232f2-7e34-72eb-64b5-3050f026b5a0@gmx.de> <62bedd1f-ad3c-1aa6-c9c2-070e33297cd7@htt-consult.com> From: Robert Moskowitz Message-ID: Date: Thu, 7 Oct 2021 10:10:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 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] Solved? - Re: Problem with submitting xml X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 14:11:45 -0000 Just successfully submitted ver -09 using .xml I don't know what I did to get the /xml variant, and you said, it worked so I just was working with it for some time... thanks for the assistance all. On 10/6/21 6:54 PM, Robert Sparks wrote: > Right this second, > https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs/xml > expands to what looks like the right thing. > > There is a possible hint in the existence of a file named simply 'xml' > in the xml2rfc cache directory that the datatracker submit function > uses, that has the odd content Julian points to (it's from 23Sep fwiw). > > Also reference.I-D.ietf-drip-reqs.xml in that cache directory has > content that reflects the drip-reqs draft. > > We'll go look through the xml2rfc code to see what codepath that might > result in reading/writing a filename as simply "xml", which is my best > current guess as to what Bob ran into. > > RjS > > On 10/6/21 1:20 PM, Julian Reschke wrote: >> Am 06.10.2021 um 18:55 schrieb Robert Moskowitz: >>> I changed: >>> >>>      >> href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-drip-reqs/xml"/> >>> >>> >>> to: >>> >>>      >> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-drip-reqs.xml"/> >>> >>> >>> >>> And it works. >>> >>> Why? >>> ... >> >> If the theory about a bad file/cache entry is correct, then of course >> changing to a different URI will solve that. >> >> Best regards, Julian >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc > From nobody Wed Oct 13 17:37:05 2021 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 9DBDF3A1495 for ; Wed, 13 Oct 2021 17:37: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 AWTmCGQ306TO for ; Wed, 13 Oct 2021 17:36:58 -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 947DC3A0DA5 for ; Wed, 13 Oct 2021 17:36:55 -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 1maojt-0000oH-B1 for xml2rfc@ietf.org; Thu, 14 Oct 2021 00:36:53 +0000 Date: Wed, 13 Oct 2021 17:36:52 -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] two txt draft upload errors X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 00:37:03 -0000 when submitting the text resulting from the xml (v2, blush) at https://git.rg.net/randy/draft-l3dl/src/master/draft-ietf-lsvr-l3dl.xml i get two errors i do not understand Revision not found when this is -08 and -07 is the expired previous and i get Failed decoding the uploaded file: "'ascii' codec can't decode byte 0xc3 in position 81426: ordinal not in range(128)" which i believe to be about #include #include /* The F table from Skipjack, and it would work for the S-Box. */ static const uint8_t sbox[256] = { 0xa3,0xd7,0x09,0x83,0xf8,0x48,0xf6,0xf4,0xb3,0x21,0x15,0x78, 0x99,0xb1,0xaf,0xf9,0xe7,0x2d,0x4d,0x8a,0xce,0x4c,0xca,0x2e, 0x52,0x95,0xd9,0x1e,0x4e,0x38,0x44,0x28,0x0a,0xdf,0x02,0xa0, 0x17,0xf1,0x60,0x68,0x12,0xb7,0x7a,0xc3,0xe9,0xfa,0x3d,0x53, <<-- 0x96,0x84,0x6b,0xba,0xf2,0x63,0x9a,0x19,0x7c,0xae,0xe5,0xf5, 0xf7,0x16,0x6a,0xa2,0x39,0xb6,0x7b,0x0f,0xc1,0x93,0x81,0x1b, 0xee,0xb4,0x1a,0xea,0xd0,0x91,0x2f,0xb8,0x55,0xb9,0xda,0x85, 0x3f,0x41,0xbf,0xe0,0x5a,0x58,0x80,0x5f,0x66,0x0b,0xd8,0x90, as it is the only 0xc3 in the document a clue bat or two as to what i am doing wrongly would be appreciated thanks randy From nobody Wed Oct 13 20:28:20 2021 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 5B8203A0C42 for ; Wed, 13 Oct 2021 20:28:18 -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, HEADER_FROM_DIFFERENT_DOMAINS=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=iecc.com header.b=RubTLERt; dkim=pass (2048-bit key) header.d=taugh.com header.b=UrKioLGk 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 G9IV-tZccZaE for ; Wed, 13 Oct 2021 20:28:12 -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 4F61A3A0C3C for ; Wed, 13 Oct 2021 20:28:12 -0700 (PDT) Received: (qmail 31254 invoked from network); 14 Oct 2021 03:28:10 -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:cleverness; s=7a13.6167a3ca.k2110; bh=gsEcryI53OUuCVejaVXfiiQU6+WovIjo0HAKqbqE2Vs=; b=RubTLERtHU9O5Ecc3HGnpQNIsmolacSGsZ6tyfSK/ceHfjTxMvfV6rqSbLyQA1uVQmyCTuLUtl3Pw0ydgtICUqueUwNnHnqFRuYQhTLZBCeIzGgVKZgGbPmEEduSpxRzGFpcrYUROudEMYeLK+nXeZ0LR8CDSYiVCgExKqL49LiR+yhDUt4Ub2axwG7JCmaO5Lx+NQDQ0y3Kuhb8USOVzjsFUkZ6nTeACjJ7Kzz09DQxKG5p1Gej6UDTCoh4pYCzxA4G+Ly/2bWYFgnWt2QHMUO0xqEO7R0WO81SFrOuCbLowphg5aayvA1dxeVXDx9SFqnH541Y505mac7IWE1bsQ== 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:cleverness; s=7a13.6167a3ca.k2110; bh=gsEcryI53OUuCVejaVXfiiQU6+WovIjo0HAKqbqE2Vs=; b=UrKioLGkZGAa4XYcAVQVBgaY99Yczp8rOsTAS1GJOBGqIRkcxYeTyy8JxUwq652oLM6FUi2fIfQYyp1hcxXBmK6G7BayG0shsAFLKWu5TS8+UleYNJhCjiXtG93s5WzZiXU0buH4QlAB7f1e555RTUaxPSbLDazuQzADUYrr3oftRYswtyA0kDGy7nyvA7lm5OozJN7kdtPJ+LKsWcUxl29RhtTTcRoYvprj+1jduvbItd1wkZj2/7yCoFXxKcXcZr5KuyMvpCenCF0b2Mk8dOJRXPw2fC/Scm9OlduyMEwvKQUcq/vIzcEx03g2xH/UoHvhzdu3soHHnR4Unmv4jA== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 14 Oct 2021 03:28:10 -0000 Received: by ary.qy (Postfix, from userid 501) id 41EE92A51265; Wed, 13 Oct 2021 23:28:08 -0400 (EDT) Date: 13 Oct 2021 23:28:08 -0400 Message-Id: <20211014032810.41EE92A51265@ary.qy> From: "John Levine" To: xml2rfc@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [xml2rfc] two txt draft upload errors X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 03:28:19 -0000 It appears that Randy Bush said: >when submitting the text resulting from the xml (v2, blush) at >https://git.rg.net/randy/draft-l3dl/src/master/draft-ietf-lsvr-l3dl.xml >i get two errors i do not understand > > Revision not found > >when this is -08 and -07 is the expired previous > >and i get > > Failed decoding the uploaded file: "'ascii' codec can't decode byte > 0xc3 in position 81426: ordinal not in range(128)" No, I think it is complaining about the second letter in Jrg Ott's name. This smells to me like a config error on a new server in which the default character set is set to ASCII rather than UTF-8. Dunno about Revision not found, though. R's, John From nobody Wed Oct 13 21:09:09 2021 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 F3B863A0E4C for ; Wed, 13 Oct 2021 21:09:06 -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 bywmGFZM04uM for ; Wed, 13 Oct 2021 21:09:05 -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 DB4EB3A0E2F for ; Wed, 13 Oct 2021 21:09:05 -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 1mas3D-0001HL-AI; Thu, 14 Oct 2021 04:09:03 +0000 Date: Wed, 13 Oct 2021 21:09:02 -0700 Message-ID: From: Randy Bush To: John Levine Cc: XML2RFC Interest Group In-Reply-To: <20211014032810.41EE92A51265@ary.qy> References: <20211014032810.41EE92A51265@ary.qy> 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=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] two txt draft upload errors X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 04:09:07 -0000 > No, I think it is complaining about the second letter in J=F6rg Ott's > name. thanks. it is J=C3=B6rg Ott in the xml but what is really weird is that, when i look at the .txt in less or emacs on my mac, i see it expanded to Joerg comments, Joerg Ott for > This smells to me like a config error on a new server in which the > default character set is set to ASCII rather than UTF-8. so i should try again and might get a different server. nope, seems reproducible. > Dunno about Revision not found, though. the moon is in klutz randy From nobody Thu Oct 14 00:37:39 2021 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 1B0063A0DA8 for ; Thu, 14 Oct 2021 00:37:37 -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 PHkPsIsEIlDq for ; Thu, 14 Oct 2021 00:37:32 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A2D3A0C47 for ; Thu, 14 Oct 2021 00:37:30 -0700 (PDT) Received: from [192.168.217.118] (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HVLpH379wz2xlT; Thu, 14 Oct 2021 09:37:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Thu, 14 Oct 2021 09:37:26 +0200 Cc: "John R. Levine" , XML2RFC Interest Group X-Mao-Original-Outgoing-Id: 655889846.366222-383aa5c8bdf116ccce10b83c22676abb Content-Transfer-Encoding: quoted-printable Message-Id: <6C358391-BD78-4706-959A-39065323F50C@tzi.org> References: <20211014032810.41EE92A51265@ary.qy> To: Randy Bush X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [xml2rfc] two txt draft upload errors X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 07:37:37 -0000 On 2021-10-14, at 06:09, Randy Bush wrote: >=20 > thanks. it is J=C3=B6rg Ott in the xml >=20 > but what is really weird is that, when i look at the .txt in less or > emacs on my mac, i see it expanded to Joerg >=20 > comments, Joerg Ott for The v2 processor in xml2rfc does that. The .txt should not have beyond-ASCII in it, IIRC. Why don=E2=80=99t you just submit the XML, BTW? Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 14 07:38:12 2021 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 CF37E3A16D9 for ; Thu, 14 Oct 2021 07:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.282 X-Spam-Level: X-Spam-Status: No, score=-1.282 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 zTKGcuQjo6QD for ; Thu, 14 Oct 2021 07:38:05 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8755B3A08A9 for ; Thu, 14 Oct 2021 07:38:03 -0700 (PDT) Received: from [192.168.1.114] ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 19EEc0Vm035347 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 Oct 2021 09:38:01 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1634222282; bh=FPF/hD5T3nOK1gCrcH9qMlmNBkSM1ZCaZ0jsq93xg/M=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=S9ohGDL8dSiyNWXGrG1NVdomLth/Vn8eYxg+s4gpaJKESFXaOzVPY1D5o9iaunKK7 py5D33a5jxhCTdvICzcQ7bFlxFQ8lOipYYtC4tOfhkZfcS0lVzQiF4HBRIAUNU8pKe qZtKscK+6gExzhan+zWtzz09ZcNGma3OkDu03GS0= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be [192.168.1.114] Message-ID: <2286ea37-ab96-b39f-98a2-0e7129e22e50@nostrum.com> Date: Thu, 14 Oct 2021 09:37:55 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: Carsten Bormann , Randy Bush Cc: XML2RFC Interest Group , "John R. Levine" References: <20211014032810.41EE92A51265@ary.qy> <6C358391-BD78-4706-959A-39065323F50C@tzi.org> From: Robert Sparks In-Reply-To: <6C358391-BD78-4706-959A-39065323F50C@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [xml2rfc] two txt draft upload errors X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 14:38:10 -0000 I don't see a submission for -08 in production. I'll work with Randy directly to find out what's happening. RjS On 10/14/21 2:37 AM, Carsten Bormann wrote: > On 2021-10-14, at 06:09, Randy Bush wrote: >> thanks. it is Jörg Ott in the xml >> >> but what is really weird is that, when i look at the .txt in less or >> emacs on my mac, i see it expanded to Joerg >> >> comments, Joerg Ott for > The v2 processor in xml2rfc does that. > The .txt should not have beyond-ASCII in it, IIRC. > > Why don’t you just submit the XML, BTW? > > Grüße, Carsten > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Thu Oct 14 09:28:18 2021 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 BBAF03A1756 for ; Thu, 14 Oct 2021 09:28:04 -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 qdJ3Ug0Q7WKF for ; Thu, 14 Oct 2021 09:27:59 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729503A1766 for ; Thu, 14 Oct 2021 09:27:58 -0700 (PDT) Received: from [192.168.217.118] (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HVZZM0gxfz2xdC; Thu, 14 Oct 2021 18:27:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <6C358391-BD78-4706-959A-39065323F50C@tzi.org> Date: Thu, 14 Oct 2021 18:27:54 +0200 Cc: "John R. Levine" , XML2RFC Interest Group X-Mao-Original-Outgoing-Id: 655921674.481951-37a7cb472268d013be6342f7f3015d68 Content-Transfer-Encoding: quoted-printable Message-Id: <29A38EC1-8FB2-4ECB-99DB-CD9254982AAD@tzi.org> References: <20211014032810.41EE92A51265@ary.qy> <6C358391-BD78-4706-959A-39065323F50C@tzi.org> To: Randy Bush X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [xml2rfc] two txt draft upload errors X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 16:28:12 -0000 On 2021-10-14, at 09:37, Carsten Bormann wrote: >=20 >> thanks. it is J=C3=B6rg Ott in the xml >>=20 >> but what is really weird is that, when i look at the .txt in less or >> emacs on my mac, i see it expanded to Joerg >>=20 >> comments, Joerg Ott for >=20 > The v2 processor in xml2rfc does that. > The .txt should not have beyond-ASCII in it, IIRC. It=E2=80=99s Urs H=C3=B6lzle, coming in via the reference JUPITER. [JUPITER] Singh, A., Ong, J., Agarwal, A., Anderson, G., Armistead, A., Bannon, R., Boving, S., Desai, G., Felderman, B., Germano, P., Kanagala, A., Liu, H., Provost, J., Simmons, J., Tanda, E., Wanderer, J., H=C3=B6lzle, U., Stuart, S., = and A. Vahdat, "Jupiter rising: a decade of clos topologies and centralized control in Google's datacenter network", Communications of the ACM Vol. 59, pp. 88-97, DOI 10.1145/2975159, August 2016, . I didn=E2=80=99t know that the ASCIIfication in the xml2rfc v2 = processing doesn=E2=80=99t apply to references. Interesting historical = tidbit. I stick with:, though. > Why don=E2=80=99t you just submit the XML, BTW? Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 14 09:30:12 2021 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 E47DB3A0B98 for ; Thu, 14 Oct 2021 09:30: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 NJYCYP13hIBu for ; Thu, 14 Oct 2021 09:30:08 -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 1C3073A0B6F for ; Thu, 14 Oct 2021 09:30:08 -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 1mb3cK-0002oc-3q; Thu, 14 Oct 2021 16:30:04 +0000 Date: Thu, 14 Oct 2021 09:30:03 -0700 Message-ID: From: Randy Bush To: Carsten Bormann Cc: "John R. Levine" , XML2RFC Interest Group In-Reply-To: <29A38EC1-8FB2-4ECB-99DB-CD9254982AAD@tzi.org> References: <20211014032810.41EE92A51265@ary.qy> <6C358391-BD78-4706-959A-39065323F50C@tzi.org> <29A38EC1-8FB2-4ECB-99DB-CD9254982AAD@tzi.org> 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=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] two txt draft upload errors X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 16:30:11 -0000 > It=E2=80=99s Urs H=C3=B6lzle it would be :) From nobody Thu Oct 14 09:49:21 2021 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 3889D3A170C for ; Thu, 14 Oct 2021 09:49:18 -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 zrNV0YUBE1RV for ; Thu, 14 Oct 2021 09:49:16 -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 7FFAA3A0BD7 for ; Thu, 14 Oct 2021 09:49:16 -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 1mb3ur-0002rI-8C; Thu, 14 Oct 2021 16:49:13 +0000 Date: Thu, 14 Oct 2021 09:49:12 -0700 Message-ID: From: Randy Bush To: Carsten Bormann Cc: "John R. Levine" , XML2RFC Interest Group In-Reply-To: <29A38EC1-8FB2-4ECB-99DB-CD9254982AAD@tzi.org> References: <20211014032810.41EE92A51265@ary.qy> <6C358391-BD78-4706-959A-39065323F50C@tzi.org> <29A38EC1-8FB2-4ECB-99DB-CD9254982AAD@tzi.org> 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-7 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] two txt draft upload errors X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 16:49:19 -0000 > Why don=A2t you just submit the XML, BTW? A submission with same name and revision is currently being processed. Check the status here. :) From nobody Sun Oct 24 08:08:16 2021 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 751783A087D for ; Sun, 24 Oct 2021 08:08:15 -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 X7jYEcYHm6dE for ; Sun, 24 Oct 2021 08:08: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 8F9973A086C for ; Sun, 24 Oct 2021 08:08:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id C65726256E for ; Sun, 24 Oct 2021 11:07:09 -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 e-9NmdgcUt4S for ; Sun, 24 Oct 2021 11:07:05 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id B518762569 for ; Sun, 24 Oct 2021 11:07:05 -0400 (EDT) To: "xml2rfc@ietf.org" From: Robert Moskowitz Message-ID: Date: Sun, 24 Oct 2021 11:07:57 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [xml2rfc] Is the --v3 switch still needed? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2021 15:08:15 -0000 Do we still need to include the --v3 switch on the command line? particularly if we have getting tired typing it in all the time... From nobody Sun Oct 24 09:33:40 2021 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 D52213A07CC; Sun, 24 Oct 2021 09:33:33 -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 t2JVh7OGp5TR; Sun, 24 Oct 2021 09:33:29 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6FE73A079D; Sun, 24 Oct 2021 09:33:29 -0700 (PDT) Received: from [192.168.217.118] (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HckD71DNcz30SP; Sun, 24 Oct 2021 18:33:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Sun, 24 Oct 2021 18:33:26 +0200 Cc: "xml2rfc@ietf.org" , rfc-markdown@ietf.org X-Mao-Original-Outgoing-Id: 656786006.353845-fbba82cac6cbbea70b7ff0c94f787f1f Reply-To: rfc-markdown@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2A985F36-1332-497F-8DDC-2531245FA8A3@tzi.org> References: To: Robert Moskowitz X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [xml2rfc] Is the --v3 switch still needed? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2021 16:33:34 -0000 On 2021-10-24, at 17:07, Robert Moskowitz wrote: >=20 > Do we still need to include the --v3 switch on the command line? >=20 > particularly if we have >=20 > >=20 > getting tired typing it in all the time... It is generally a big thing to change a command line interface, as the = command may be embedded in a lot of scripts (it certainly is for = xml2rfc), which then do unexpected things. I happen to be thinking about a related kind of change for kdrfc, the = =E2=80=9Cdriver=E2=80=9D command for kramdown-rfc2629. That change = would require some indication of v3ness in the markdown file; but maybe = that same indication would be a nice way to get rid of needing to = override old defaults (such as setting stand_alone: true, consensus: = true if category: std; also the need to declare ipr: trust200902 or pi: = [toc, sortrefs, symrefs, comments], etc.). Feedback about the latter welcome to rfc-markdown@ietf.org. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Oct 24 12:31:11 2021 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 DF6733A08CC; Sun, 24 Oct 2021 12:31: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 GcHtlS8bTXvQ; Sun, 24 Oct 2021 12:31:01 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 D59223A0889; Sun, 24 Oct 2021 12:31:00 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id g8so6229954ljn.4; Sun, 24 Oct 2021 12:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yuW6nMN/ZjIx8w4QbZWmfGLBklY9A/GLVPmq6fvE4SM=; b=WQsDjSbAL026qMDzFogRcwYX+ShekGu+4lbJ41P5YKwbBt3O70SNTsIGsakjjFC3tN ej0xyoFSJRiXQ0pqD830k8lVnGlrKFyt7icwcGRR18n3iJv2TA8T1k9npPxca1kvdGBR ckl/SXMI4rfN/PBN6tA8PaDrVhGf/9yXKbt3bfctL7rryLXJ5AqL17oRQBRtBFzfiZji JhBym4+v9ZwvBStVBR1Vt/xiAEKQ4p6YHLJfpOfVoYO3Iz/zf8A2qiHfpXaYjIHY+X0/ 8jCSzcupC1zXClH5dH6k0DE6Dg6RNpXjSOwUoK+0NFfE0avwweGt9vq2uxR2FDTeXeW3 SJ5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yuW6nMN/ZjIx8w4QbZWmfGLBklY9A/GLVPmq6fvE4SM=; b=yFx1ZnU7tQteOa6iba+uikS4C2tSjwMVfCVtv+4vs79kJqGb6jKT6lNNC41y6aT16e Er1NGnlRTlgHHB7g2tVwV7AXi2o3PmdvFhiK0KT7RWz4fdMWLoL4ZXzAwQdNi62gF1s3 EoKU2c09AJSEP4oHMI/Igmw2J/vZdZ3AE+KZzE0h6lcEPrXdvqN+DRKJyBSxiK/EqrJK AnlfxH2W/LNypcLqH4bmmg2efDp9vMKHe9Alo2HWf3f0bApEObQK2kIHpXZY9VKgkMXK b+49WvudPMmTOgC/9OiU/wxV9IY3XFrJ9tkyimFVjvfnntkWmbEbJvdHhTWZ1L1YfZss rlrA== X-Gm-Message-State: AOAM5310WWyd5MCGx4WCaE0kBBZpBhtPlBVGKrB6LdnmQBH71CpbU85J wap23RoFl65pm0ckTykoGJxsNofyLZCyx8gKVLxCoIH22hA= X-Google-Smtp-Source: ABdhPJzkkRqPZXW+2Z7zcAjQyeBxw/FgQvgQ60TGutCMumG6la5eLg+dAAJleS3JVI0L5mVdJ1miuupdG4DT92Eyo00= X-Received: by 2002:a2e:7807:: with SMTP id t7mr14408252ljc.449.1635103856926; Sun, 24 Oct 2021 12:30:56 -0700 (PDT) MIME-Version: 1.0 References: <2A985F36-1332-497F-8DDC-2531245FA8A3@tzi.org> In-Reply-To: <2A985F36-1332-497F-8DDC-2531245FA8A3@tzi.org> From: Tim Wicinski Date: Sun, 24 Oct 2021 15:30:45 -0400 Message-ID: To: rfc-markdown@ietf.org Cc: Robert Moskowitz , "xml2rfc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009021fa05cf1e4865" Archived-At: Subject: Re: [xml2rfc] [Rfc-markdown] Is the --v3 switch still needed? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2021 19:31:06 -0000 --0000000000009021fa05cf1e4865 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In version 3.10.0 It appears the default for --v3 is True, which is what I would have done: formatoptions.add_argument('--v3', action=3D'store_true', default=3DTru= e, help=3D'with --text and --html: use the v3 formatter, rather than the legacy one') Try it w/out the --v3 if you are up to date (and if not....) tim On Sun, Oct 24, 2021 at 12:33 PM Carsten Bormann wrote: > On 2021-10-24, at 17:07, Robert Moskowitz wrote: > > > > Do we still need to include the --v3 switch on the command line? > > > > particularly if we have > > > > > > > > getting tired typing it in all the time... > > It is generally a big thing to change a command line interface, as the > command may be embedded in a lot of scripts (it certainly is for xml2rfc)= , > which then do unexpected things. > > I happen to be thinking about a related kind of change for kdrfc, the > =E2=80=9Cdriver=E2=80=9D command for kramdown-rfc2629. That change would= require some > indication of v3ness in the markdown file; but maybe that same indication > would be a nice way to get rid of needing to override old defaults (such = as > setting stand_alone: true, consensus: true if category: std; also the nee= d > to declare ipr: trust200902 or pi: [toc, sortrefs, symrefs, comments], > etc.). > > Feedback about the latter welcome to rfc-markdown@ietf.org. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > Rfc-markdown mailing list > Rfc-markdown@ietf.org > https://www.ietf.org/mailman/listinfo/rfc-markdown > --0000000000009021fa05cf1e4865 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In version 3.10.0 It appears the default for --v3 is True, which is what= I would have done:

=C2=A0 =C2=A0 formatoptions.add_argument('--v3', action=3D&#= 39;store_true', default=3DTrue,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0help=3D'w= ith --text and --html: use the v3 formatter, rather than the legacy one'= ;)
Try it= w/out the --v3 if you=C2=A0are up to date (and if not....)

tim


On Sun, Oct 24, 2021 at= 12:33 PM Carsten Bormann <cabo@tzi.org<= /a>> wrote:
O= n 2021-10-24, at 17:07, Robert Moskowitz <rgm@htt-consult.com> wrote:
>
> Do we still need to include the --v3 switch on the command line?
>
> particularly if we have
>
> <rfc ... version=3D"3">
>
> getting tired typing it in all the time...

It is generally a big thing to change a command line interface, as the comm= and may be embedded in a lot of scripts (it certainly is for xml2rfc), whic= h then do unexpected things.

I happen to be thinking about a related kind of change for kdrfc, the =E2= =80=9Cdriver=E2=80=9D command for kramdown-rfc2629.=C2=A0 That change would= require some indication of v3ness in the markdown file; but maybe that sam= e indication would be a nice way to get rid of needing to override old defa= ults (such as setting stand_alone: true, consensus: true if category: std; = also the need to declare ipr: trust200902 or pi: [toc, sortrefs, symrefs, c= omments], etc.).

Feedback about the latter welcome to rfc-markdown@ietf.org.

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

_______________________________________________
Rfc-markdown mailing list
Rfc-markdown@iet= f.org
https://www.ietf.org/mailman/listinfo/rfc-markdown=
--0000000000009021fa05cf1e4865-- From nobody Sun Oct 24 12:39:20 2021 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 45AA13A08E5; Sun, 24 Oct 2021 12:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.228 X-Spam-Level: X-Spam-Status: No, score=-5.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-3.33, 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 T2dE1SVhA1rZ; Sun, 24 Oct 2021 12:39:14 -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 F01733A0926; Sun, 24 Oct 2021 12:39:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 6D7306256E; Sun, 24 Oct 2021 15:38:06 -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 O8i63PDTn1IV; Sun, 24 Oct 2021 15:37:59 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 53C5C62569; Sun, 24 Oct 2021 15:37:59 -0400 (EDT) To: Tim Wicinski , rfc-markdown@ietf.org Cc: "xml2rfc@ietf.org" References: <2A985F36-1332-497F-8DDC-2531245FA8A3@tzi.org> From: Robert Moskowitz Message-ID: <17adc707-6d65-3455-7fb0-ae82d88e0b77@htt-consult.com> Date: Sun, 24 Oct 2021 15:38:57 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AE132AD7D315D8D9048C5CDF" Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] [Rfc-markdown] Is the --v3 switch still needed? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2021 19:39:19 -0000 This is a multi-part message in MIME format. --------------AE132AD7D315D8D9048C5CDF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I am on ver 3.10.0, but like how do you know that the proper txt was built and not some fall back to whatever v2 would do? Perhaps mv what I did with --v3 to a different name, run without the option and use rfcdiff to compare the two txt files? On 10/24/21 3:30 PM, Tim Wicinski wrote: > In version 3.10.0 It appears the default for --v3 is True, which is > what I would have done: > > formatoptions.add_argument('--v3', action='store_true', default=True, >                            help='with --text and --html: use the v3 > formatter, rather than the legacy one') > > Try it w/out the --v3 if you are up to date (and if not....) > > tim > > > On Sun, Oct 24, 2021 at 12:33 PM Carsten Bormann > wrote: > > On 2021-10-24, at 17:07, Robert Moskowitz > wrote: > > > > Do we still need to include the --v3 switch on the command line? > > > > particularly if we have > > > > > > > > getting tired typing it in all the time... > > It is generally a big thing to change a command line interface, as > the command may be embedded in a lot of scripts (it certainly is > for xml2rfc), which then do unexpected things. > > I happen to be thinking about a related kind of change for kdrfc, > the “driver” command for kramdown-rfc2629.  That change would > require some indication of v3ness in the markdown file; but maybe > that same indication would be a nice way to get rid of needing to > override old defaults (such as setting stand_alone: true, > consensus: true if category: std; also the need to declare ipr: > trust200902 or pi: [toc, sortrefs, symrefs, comments], etc.). > > Feedback about the latter welcome to rfc-markdown@ietf.org > . > > Grüße, Carsten > > _______________________________________________ > Rfc-markdown mailing list > Rfc-markdown@ietf.org > https://www.ietf.org/mailman/listinfo/rfc-markdown > > --------------AE132AD7D315D8D9048C5CDF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I am on ver 3.10.0, but like how do you know that the proper txt was built and not some fall back to whatever v2 would do?

Perhaps mv what I did with --v3 to a different name, run without the option and use rfcdiff to compare the two txt files?

On 10/24/21 3:30 PM, Tim Wicinski wrote:
In version 3.10.0 It appears the default for --v3 is True, which is what I would have done:

    formatoptions.add_argument('--v3', action='store_true', default=True,
                           help='with --text and --html: use the v3 formatter, rather than the legacy one')

Try it w/out the --v3 if you are up to date (and if not....)

tim


On Sun, Oct 24, 2021 at 12:33 PM Carsten Bormann <cabo@tzi.org> wrote:
On 2021-10-24, at 17:07, Robert Moskowitz <rgm@htt-consult.com> wrote:
>
> Do we still need to include the --v3 switch on the command line?
>
> particularly if we have
>
> <rfc ... version="3">
>
> getting tired typing it in all the time...

It is generally a big thing to change a command line interface, as the command may be embedded in a lot of scripts (it certainly is for xml2rfc), which then do unexpected things.

I happen to be thinking about a related kind of change for kdrfc, the “driver” command for kramdown-rfc2629.  That change would require some indication of v3ness in the markdown file; but maybe that same indication would be a nice way to get rid of needing to override old defaults (such as setting stand_alone: true, consensus: true if category: std; also the need to declare ipr: trust200902 or pi: [toc, sortrefs, symrefs, comments], etc.).

Feedback about the latter welcome to rfc-markdown@ietf.org.

Grüße, Carsten

_______________________________________________
Rfc-markdown mailing list
Rfc-markdown@ietf.org
https://www.ietf.org/mailman/listinfo/rfc-markdown

--------------AE132AD7D315D8D9048C5CDF-- From nobody Sun Oct 24 13:36:19 2021 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 88B3F3A083C; Sun, 24 Oct 2021 13:36:18 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 VDc5CZ25Ey4t; Sun, 24 Oct 2021 13:36:14 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 705293A0805; Sun, 24 Oct 2021 13:35:42 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id j9so4729428lfu.7; Sun, 24 Oct 2021 13:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MRqBbYocihLaUKai6ZRTxoiBNvfBGEGMmYuvMKLRmmo=; b=LTa64XINLGHecxkj26wFwnqbnRUr6iFJ9lea8jgQFnC3ZsPGddWdzmC+PikfAlGifb fNFKgG0iC11VTAfaUoEuCXG088Off14fO5FDapRGsgvw3P0VaaiV3oiIXQD4SE/Lc3NY lJnYWza/qoJMVlWBW6HUFLEpozkaJltLQGMX0srLkUAE+/eE67GlQLw6QVnlv5dRSuIp b4EaOBT2giDXHahnenjqbNAxfa0YhkFFPpoZ/8rma0DUKR5fEfZv+GQsbKfXIc2E/kM3 8EhGE6tcANjC4HvM4EtYp99BxbRZ3bD9rhaMZQEicMs+KINefbP9/Ryjw7uFQbEp8qGh 7NUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MRqBbYocihLaUKai6ZRTxoiBNvfBGEGMmYuvMKLRmmo=; b=APzhH4Rq7Ee1fPEZa/GA84kRgMFK8srXzc/deUBIVt5LAbJwXQnWit3M8pMw77ipgN QDS/guUQLOwx6APffTy/5zxKWBCVLSbaf2bPPLz5V7UsFfkgwaDdHilQkfOo2J/t9f9t +KlbvKuvV6TqySZ9ZjIHdY5M4WMDE9ZBCYNlqArAF1obXvkIEc5ADYDISfCfUdmsHLzs WsK+fjhHc5QVJQ7KneJuNJ7GkHSuA9u6pyS/MyVlLiXb9xDytmIY7RtMdnUneFBiUdef rb9SCSyjrcZbJ83i+3aGN6P3UVbrm4450ZCWLGFHePbGTcIxqfp+imo2KlXUbqMea3Ez yEoA== X-Gm-Message-State: AOAM5317HqdvscwtZaGPe5XnYwxQ/uw9NX9Ht7H47uyLNbfNVj5hySTT IsxWqTCoNXzQzP1rHGUMFZxu+2D1HNqBd5RG+54= X-Google-Smtp-Source: ABdhPJwjU7qcXz+QGSnZt+Xv317SKdj5VM3bhaV12/GPP26uCaFwwAjOSu/RoHmuFP7i/iyUu25sbirDbNXYW908AmA= X-Received: by 2002:a05:6512:39c7:: with SMTP id k7mr13075200lfu.571.1635107738234; Sun, 24 Oct 2021 13:35:38 -0700 (PDT) MIME-Version: 1.0 References: <2A985F36-1332-497F-8DDC-2531245FA8A3@tzi.org> <17adc707-6d65-3455-7fb0-ae82d88e0b77@htt-consult.com> In-Reply-To: <17adc707-6d65-3455-7fb0-ae82d88e0b77@htt-consult.com> From: Tim Wicinski Date: Sun, 24 Oct 2021 16:35:27 -0400 Message-ID: To: Robert Moskowitz Cc: rfc-markdown@ietf.org, "xml2rfc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e832c405cf1f2f5c" Archived-At: Subject: Re: [xml2rfc] [Rfc-markdown] Is the --v3 switch still needed? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2021 20:36:19 -0000 --000000000000e832c405cf1f2f5c Content-Type: text/plain; charset="UTF-8" On Sun, Oct 24, 2021 at 3:39 PM Robert Moskowitz wrote: > I am on ver 3.10.0, but like how do you know that the proper txt was built > and not some fall back to whatever v2 would do? > > Perhaps mv what I did with --v3 to a different name, run without the > option and use rfcdiff to compare the two txt files? > > I tested it just as you said and my files were identical. Your Mileage, etc etc tim --000000000000e832c405cf1f2f5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Oct 24, 2021 at 3:39 PM Robert Moskow= itz <rgm@htt-consult.com> = wrote:
=20 =20 =20
I am on ver 3.10.0, but like how do you know that the proper txt was built and not some fall back to whatever v2 would do?

Perhaps mv what I did with --v3 to a different name, run without the option and use rfcdiff to compare the two txt files?


I tested it just as you said and my files were identical.=C2=A0=C2= =A0

<= /div>
Your Mile= age, etc etc=C2=A0


tim
--000000000000e832c405cf1f2f5c-- From nobody Sun Oct 24 13:40:26 2021 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 7E5B63A085A; Sun, 24 Oct 2021 13:40:21 -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 v08mUnv1_4C9; Sun, 24 Oct 2021 13:40:17 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348BD3A0825; Sun, 24 Oct 2021 13:40:17 -0700 (PDT) Received: from [192.168.217.118] (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Hcqhk4X7hz30Sr; Sun, 24 Oct 2021 22:40:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Sun, 24 Oct 2021 22:40:06 +0200 Cc: Robert Moskowitz , rfc-markdown@ietf.org, "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 656800805.974104-3cfce6ec26649f6890f17233c004df3e Content-Transfer-Encoding: quoted-printable Message-Id: <4FF224D5-90E4-45C4-83C9-C4DC4614FD66@tzi.org> References: <2A985F36-1332-497F-8DDC-2531245FA8A3@tzi.org> <17adc707-6d65-3455-7fb0-ae82d88e0b77@htt-consult.com> To: Tim Wicinski X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [xml2rfc] [Rfc-markdown] Is the --v3 switch still needed? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2021 20:40:22 -0000 On 2021-10-24, at 22:35, Tim Wicinski wrote: >=20 > I am on ver 3.10.0, but like how do you know that the proper txt was = built and not some fall back to whatever v2 would do? The v3 formatter uses a different date format; that is usually the = easiest giveaway. Compare = https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5322bis/ 29 September 2021 (v3 formatter date format) with https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321bis/ October 24, 2021 (v2 formatter date format) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Oct 25 08:29:57 2021 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 36D313A08DC; Mon, 25 Oct 2021 08:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.228 X-Spam-Level: X-Spam-Status: No, score=-5.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-3.33, 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 lT2zX9BJAZdj; Mon, 25 Oct 2021 08:29:41 -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 E1F6B3A0905; Mon, 25 Oct 2021 08:29:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 996C06256E; Mon, 25 Oct 2021 11:28:34 -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 Ow2jEQSh1qj2; Mon, 25 Oct 2021 11:28:26 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id BF1D66247F; Mon, 25 Oct 2021 11:28:25 -0400 (EDT) To: Tim Wicinski Cc: rfc-markdown@ietf.org, "xml2rfc@ietf.org" References: <2A985F36-1332-497F-8DDC-2531245FA8A3@tzi.org> <17adc707-6d65-3455-7fb0-ae82d88e0b77@htt-consult.com> From: Robert Moskowitz Message-ID: <57487cdf-aafa-52d6-bf84-c66bdadcb0c3@htt-consult.com> Date: Mon, 25 Oct 2021 11:29:12 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1F5822CF567F5E0ED666C471" Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] [Rfc-markdown] Is the --v3 switch still needed? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 15:29:46 -0000 This is a multi-part message in MIME format. --------------1F5822CF567F5E0ED666C471 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I just did the test with my draft-ietf-drip-rid doc and they were identical. I will proceed with caution, but being I am lazy and saving typing 5 characters (when I copy the draft file name into the terminal window) I will happily stop including this option. As I said, I would *THINK* that the content in the xml should flag xml2rfc how to proceed. On 10/24/21 4:35 PM, Tim Wicinski wrote: > > > On Sun, Oct 24, 2021 at 3:39 PM Robert Moskowitz > wrote: > > I am on ver 3.10.0, but like how do you know that the proper txt > was built and not some fall back to whatever v2 would do? > > Perhaps mv what I did with --v3 to a different name, run without > the option and use rfcdiff to compare the two txt files? > > > I tested it just as you said and my files were identical. > > Your Mileage, etc etc > > > tim > --------------1F5822CF567F5E0ED666C471 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I just did the test with my draft-ietf-drip-rid doc and they were identical.

I will proceed with caution, but being I am lazy and saving typing 5 characters (when I copy the draft file name into the terminal window) I will happily stop including this option.

As I said, I would *THINK* that the <rfc ... verison=3> content in the xml should flag xml2rfc how to proceed.

On 10/24/21 4:35 PM, Tim Wicinski wrote:


On Sun, Oct 24, 2021 at 3:39 PM Robert Moskowitz <rgm@htt-consult.com> wrote:
I am on ver 3.10.0, but like how do you know that the proper txt was built and not some fall back to whatever v2 would do?

Perhaps mv what I did with --v3 to a different name, run without the option and use rfcdiff to compare the two txt files?


I tested it just as you said and my files were identical.  

Your Mileage, etc etc 


tim


--------------1F5822CF567F5E0ED666C471-- From nobody Mon Oct 25 08:43:21 2021 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 679223A0AE8; Mon, 25 Oct 2021 08:43: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 Cap4O9QxzqTl; Mon, 25 Oct 2021 08:43:11 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070EC3A096F; Mon, 25 Oct 2021 08:43:11 -0700 (PDT) Received: from [192.168.217.118] (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HdK3b3fzQz30ZP; Mon, 25 Oct 2021 17:43:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <57487cdf-aafa-52d6-bf84-c66bdadcb0c3@htt-consult.com> Date: Mon, 25 Oct 2021 17:43:07 +0200 Cc: Tim Wicinski , rfc-markdown@ietf.org, "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 656869387.238229-9ba0c7879ecfa343244d10e2de4e1a8b Content-Transfer-Encoding: quoted-printable Message-Id: <8ACC084C-C16D-40BC-8569-6235F89DC8F4@tzi.org> References: <2A985F36-1332-497F-8DDC-2531245FA8A3@tzi.org> <17adc707-6d65-3455-7fb0-ae82d88e0b77@htt-consult.com> <57487cdf-aafa-52d6-bf84-c66bdadcb0c3@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [xml2rfc] [Rfc-markdown] Is the --v3 switch still needed? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 15:43:16 -0000 On 2021-10-25, at 17:29, Robert Moskowitz wrote: >=20 > I just did the test with my draft-ietf-drip-rid doc and they were = identical. >=20 > I will proceed with caution, but being I am lazy and saving typing 5 = characters (when I copy the draft file name into the terminal window) I = will happily stop including this option. >=20 > As I said, I would *THINK* that the content in = the xml should flag xml2rfc how to proceed. Makes sense. The most important thing is that, when you are done, you submit the XML = and *not* the TXT. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Oct 25 08:51:14 2021 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 0BBA53A0AE2; Mon, 25 Oct 2021 08:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.229 X-Spam-Level: X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, 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 AHuVR3Dir6FF; Mon, 25 Oct 2021 08:51:07 -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 A9F7B3A0AE6; Mon, 25 Oct 2021 08:51:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 02A566256E; Mon, 25 Oct 2021 11:50:02 -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 QpBCuFgxcYuK; Mon, 25 Oct 2021 11:49:56 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2F2256247F; Mon, 25 Oct 2021 11:49:56 -0400 (EDT) To: Carsten Bormann Cc: Tim Wicinski , rfc-markdown@ietf.org, "xml2rfc@ietf.org" References: <2A985F36-1332-497F-8DDC-2531245FA8A3@tzi.org> <17adc707-6d65-3455-7fb0-ae82d88e0b77@htt-consult.com> <57487cdf-aafa-52d6-bf84-c66bdadcb0c3@htt-consult.com> <8ACC084C-C16D-40BC-8569-6235F89DC8F4@tzi.org> From: Robert Moskowitz Message-ID: <34bd2511-a0b9-27da-dd59-71d1c253f033@htt-consult.com> Date: Mon, 25 Oct 2021 11:50:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <8ACC084C-C16D-40BC-8569-6235F89DC8F4@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] [Rfc-markdown] Is the --v3 switch still needed? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 15:51:12 -0000 On 10/25/21 11:43 AM, Carsten Bormann wrote: > On 2021-10-25, at 17:29, Robert Moskowitz wrote: >> I just did the test with my draft-ietf-drip-rid doc and they were identical. >> >> I will proceed with caution, but being I am lazy and saving typing 5 characters (when I copy the draft file name into the terminal window) I will happily stop including this option. >> >> As I said, I would *THINK* that the content in the xml should flag xml2rfc how to proceed. > Makes sense. > The most important thing is that, when you are done, you submit the XML and *not* the TXT. Except when you encounter a bug in the submission tool and it can't generate your txt from your xml like I had a couple weeks ago... :) From nobody Fri Oct 29 05:40:06 2021 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 799F53A117D for ; Fri, 29 Oct 2021 05:40:03 -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_FAIL=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 dXqEttVlfnSs for ; Fri, 29 Oct 2021 05:39:59 -0700 (PDT) Received: from implementers.org (implementers.org [92.243.22.217]) (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 679A13A1197 for ; Fri, 29 Oct 2021 05:39:38 -0700 (PDT) Received: from [IPV6:2601:204:e600:411:d250:99ff:fedf:93cd] (unknown [IPv6:2601:204:e600:411:d250:99ff:fedf:93cd]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) client-signature RSA-PSS (2048 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 5A3A0AE269; Fri, 29 Oct 2021 14:39:36 +0200 (CEST) Message-ID: Date: Fri, 29 Oct 2021 05:39:34 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 From: Marc Petit-Huguenin Cc: Colin Perkins , Stephen McQuistin Content-Language: en-US To: xml2rfc list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [xml2rfc] Machine-readable documents at Hackathon 112 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 12:40:04 -0000 Stephen, Colin, and I would like to invite you to participate in the online IETF 112 Hackathon on our umbrella project of "Machine-readable documents and their tools": https://trac.ietf.org/trac/ietf/meeting/wiki/112hackathon#MachineReadable If you have done some work on that subject that you would like to present or discuss, or if you have opinions on that topic, or simply are curious about how machine-readable documents can make the Internet work better, and what tools are available to produce and use these documents, please join us. Stephen and I will be presenting our work with shorts live presentations at scheduled times during the week: https://trac.ietf.org/trac/ietf/meeting/wiki/112hackathon/teamschedule Feel free to add your project to either or both Wiki pages. The Hackathon itself is free to attend and open to everyone: https://www.ietf.org/how/runningcode/hackathons/112-hackathon/ We are looking forward to meet you there. -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug From nobody Fri Oct 29 10:57:41 2021 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 44EF13A1531; Fri, 29 Oct 2021 10:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 QjjytOxzeoXI; Fri, 29 Oct 2021 10:57:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 85F003A152F; Fri, 29 Oct 2021 10:57:26 -0700 (PDT) Received: from c162ff772b9a ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 19THvK3L010352 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 29 Oct 2021 12:57:20 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1635530240; bh=q3KSVBaZqAUyzbcR+yqG0xhWlBAnj0UMlpYw6jlO4Nc=; h=From:To:Subject:Cc:Date; b=q58dT8ntWFTQn+UQTlbXqCPG1A/Evmm66yGHnZ/TlW67KwifWTOejig6qyosmoHvX vIeHKPUYWnPCY6O+YYY8XJErS/wkXA1wFk0qPz1SjHyx47cWnFtDbN/4zMUc8cMnKp 2P/OUJ9lXb6vhTpo9c4YE2D2wQoFIV5HA1FGgPZ0= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be c162ff772b9a Received: from rjsparks by c162ff772b9a with local (Exim 4.92) (envelope-from ) id 1mgW7u-0000C7-U4; Fri, 29 Oct 2021 17:57:14 +0000 From: rjsparks@nostrum.com To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org Cc: rfc-markdown@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Message-Id: Date: Fri, 29 Oct 2021 17:57:14 +0000 Archived-At: Subject: [xml2rfc] New xml2rfc release: v3.11.0 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 17:57:32 -0000 Hi, This is an automatic notification about a new xml2rfc release, v3.11.0, generated when running the mkrelease script. Release notes: xml2rfc (3.11.0) ietf; urgency=high * Merged in [4061] from krathnayake@ietf.org: Fixes a case where an infinite loop could occur in text rendering. Fixes #684. * Merged in [4059] from krathnayake@ietf.org: Updates TPL 5 boilerplate text from Simplified to Revised. Fixes #676. * Merged in [4058] from krathnayake@ietf.org: Reverts back Apple M1 specific changes from docker/run. xml2rfc (3.10.0) ietf; urgency=low * Merged in [4043] from krathnayake@ietf.org: Fixes Python compatibility issues in bin/uglifycall. * Merged in [4042] and [4045] from krathnayake@ietf.org: Updates docker/run command to support Apple M1. Fixes #675. * Merged in [4041] from krathnayake@ietf.org: Adds missing line joiner settings for
    and
      . Fixes #673. * Merged in [4040] from jennifer@painless-security.com: Fix Makefile rule precedence and repair canonical.xml test to work with yestest. Fixes #671. * Merged in [4037] from krathnayake@ietf.org: Changes RFC regression test to be a seperate test. * Merged in [4036] from krathnayake@ietf.org: Adds RFC regression tests. Fixes #667. * Merged in [4016] from krathnayake@ietf.org: Fix for bad PDF breaks. * pin weasyprint<53 for tox tests * Merged in [4020] from krathnayake@ietf.org: Sort class values in HTML output. Fixes #553. * Merged in [4018] and [4019] from jennifer@painless-security.com: Keep pns from incoming xml when present; handle case that an author does not have an after-next element. Fixes #664. * Merged in [4012] from krathnayake@ietf.org: Remove quotes from the text rendering of . Fixes #600 and #647. * Merged in [4011] from krathnayake@ietf.org: Fix info block runoff issue in PDFs. Fixes #606. * Merged in [4010] from krathnayake@ietf.org: Remove unicode entity replacement step from v2v3 conversion. Fixes #641. * Merged in [4009] from krathnayake@ietf.org: Cache XML XInclude files with referencegroup. Fixes #653. -- Robert Sparks 21 Sep 2021 18:10: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 https://svn.ietf.org/svn/tools/xml2rfc/tags/cli/3.11.0' Documentation for this release is built-in, and also available at: https://xml2rfc.tools.ietf.org/xml2rfc-doc-3.11.0.html Regards, Robert Sparks (via the mkrelease script) From nobody Fri Oct 29 11:06:43 2021 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 35C763A150A; Fri, 29 Oct 2021 11:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 csUVfTC4ytOg; Fri, 29 Oct 2021 11:06:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BE4443A1531; Fri, 29 Oct 2021 11:06:30 -0700 (PDT) Received: from c162ff772b9a ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 19TI6TRv021917 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 29 Oct 2021 13:06:30 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1635530790; bh=alaFXTopE8auNRkriwzV437d3Rgz8+OXO/b3xL/At7M=; h=From:To:Subject:Cc:Date; b=UuA7j2gfJKxCDD5tB+mat3ThazmVlZi7miHyk4+cJvp/DtFCuVcZVmzoNjAYGv5Ko kQow65xYUcG2IfywV3Zas+RNO1b5OBGhlU32R1u0k0ddT6/o4i9wZYRcXMDOEcBGVr AUtuoDlIX6wD+DJAXEGdhCYJ8Z/Xeufu5On5TAag= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be c162ff772b9a Received: from rjsparks by c162ff772b9a with local (Exim 4.92) (envelope-from ) id 1mgWGm-0000Fr-MX; Fri, 29 Oct 2021 18:06:24 +0000 From: rjsparks@nostrum.com To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org Cc: rfc-markdown@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Message-Id: Date: Fri, 29 Oct 2021 18:06:24 +0000 Archived-At: Subject: [xml2rfc] New xml2rfc release: v3.11.1 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 18:06:36 -0000 Hi, This is an automatic notification about a new xml2rfc release, v3.11.1, generated when running the mkrelease script. Release notes: xml2rfc (3.11.1) ietf; urgency=high * Cosmetic release to address changelog formatting -- Robert Sparks 29 Oct 2021 17:55:18 +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 https://svn.ietf.org/svn/tools/xml2rfc/tags/cli/3.11.1' Documentation for this release is built-in, and also available at: https://xml2rfc.tools.ietf.org/xml2rfc-doc-3.11.1.html Regards, Robert Sparks (via the mkrelease script) From nobody Sat Oct 30 04:33:44 2021 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 F24BE3A08FA for ; Sat, 30 Oct 2021 04:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.229 X-Spam-Level: X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H2=-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 s8NqMN_H3vbE for ; Sat, 30 Oct 2021 04:33:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 191FE3A0870 for ; Sat, 30 Oct 2021 04:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1635593607; bh=OTtldC4YAGT1NGtcjwodvJGqeZGfsMA0MVh1wRs8ydU=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=JD9bqtTq4BRt1WtdjoebLM5lY6caJ51tOxlHGgK2Ph0KAsWect9iJlkUAm1b24582 VqlQ2kY9oCiIyhrKyT47y6uR7Lz54kUijTijypHNvhz5rzdYKotFEeyWhLC3VuGjOx 2bx5s9mtsGHmOYTykqZf6BgbEk5XFrusaCl58AY4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.20] ([91.61.62.10]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mlf4S-1n7puH29R4-00ikrO; Sat, 30 Oct 2021 13:33:27 +0200 Message-ID: Date: Sat, 30 Oct 2021 13:33:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 To: xml2rfc@ietf.org References: From: Julian Reschke In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:7kobxvprgZ6LatWGgzMiSAiE4oD4PAeoqUasfxV/pgsw7qUKcup Vw5Uz9G5LkDCAbfAyciTmODFTs6gtZQdY2gUacDvl+tubTcStaHEJPi52Pl+FxBJlLxr57p ukIbGENYApgP19ltCX1hMifgHBa+YYuVGx6d9XuzqqniI45kwFo5ki6wcsRtIVNP5tXpS4m SjHeAyW1TUZUanLuYVHGw== X-UI-Out-Filterresults: notjunk:1;V03:K0:1mbmPTa24kI=:diuXd2EBoH0++P5zQDFMll SSIhbchSY/iHFsFBVJ1QbNiaQfKcCyfXzpdbaNWudCFXxOl7IhN0jX/HFSZfOuu5Qj7FuMBA0 OFf9YjpME76b2iglZsOBESWHbwNZ/9jPlHa5PXDXT1cI7Q6fUVUMf0QmPsa39yJ8tsPtYCDJD wTLtFQx/rTstO6GHQD7f7mww+/vVEDiAI2DAfHypF7ViF7SsFPm0Sv3Y8vxTDsWSvMUj+dw7S SWrrfQiusexH4gunwDFfRw2bqkvkReHumipws5XSiNchTtwUS0eI3p9Eo8uKCCp9/3mBypmqU IIbb4I2s0TKY27MQ9hISg8iEnqz+n8Ro+ec2c6ZDW85CIfiU4ckOYJtaqzs+qmDTANGwH0HmC MTP53nqmGPqjvKGT30BCol9Jz5Ty9KjqCgsmq5eVIyabvN9LBUdhAXfjRnlYNSc6lceSXWTfE wIf1VnkoQuWhmnc/6cMEeYQk7bfnt1brphMmTYypg7aLf4omRVRfYTcHaP68mwfFIXqtYNKUe 3tYHAmshQI1DBI+Ym9+lc5T5TbDfX2QtRR8+5MZtNKMqmTyHkUrfWJ8EEPicnWw3oKXM7akie NiZ+M7axXc+mUGpiDeWFDFKxeXG2d6EgeVFO+ebm8hvEnuS8dd5o7lFdT58DhJOhkIXl0m0s0 OiJlx07UCCmT2CpfrG9AysttsQ2tbC4JFBJUJ/7RfPVdW5Qn1AwYXNK0Ai35dxt6fjjfJG71h H7GhOGQIcNjAQ0IirB5mYK+WVmV0e4qk5b4ClEpLFki78XvyqSoWrITRvsIZXp+gEp5hzVGxf JgrtpH/qDYvcv3hdm0lSZ7xPcWrI1Wv6OYP6QRSrtO1Xb3nmVOoyKD3GvIsmUdRQWz5W86hBq saVFFDJ4UsJxfQqF4LiHV5T4dp7AhMfxY0WqHO58Z5Wpsbrbs5jtqG56At7wMTAw/YjtGH/Ax 8rzdVHRga/LdnQvwLFJGGo0lSw7BfHJTh2AdB2iSJlor7MdODlJnhg4n9RLfPne5bthEFM+/+ eg5R19njshZopMyQT4zud33kJd4eTvgcS6EKHcaX9qFVnIvhzhj0G0mn7/RYZwrRSqhqKmrKY 1nC0MlAKtSOBVY= Archived-At: Subject: Re: [xml2rfc] New xml2rfc release: v3.11.0 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2021 11:33:43 -0000 Am 29.10.2021 um 19:57 schrieb rjsparks@nostrum.com: > > Hi, > > This is an automatic notification about a new xml2rfc release, > v3.11.0, generated when running the mkrelease script. > > Release notes: > > xml2rfc (3.11.0) ietf; urgency=3Dhigh > > * Merged in [4061] from krathnayake@ietf.org: > Fixes a case where an infinite loop could occur in text rendering. > Fixes #684. > > * Merged in [4059] from krathnayake@ietf.org: > Updates TPL 5 boilerplate text from Simplified to Revised. Fixes #6= 76. > ... FWIW, this is problematic, because it will change the copyright text of *published* RFCs should they ever be re-generated from XML. It would be better to make this depend on the publication date. Best regards, Julian From nobody Sat Oct 30 07:42:05 2021 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 E8CDE3A0E84 for ; Sat, 30 Oct 2021 07:42:03 -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 (2048-bit key) header.d=iecc.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 vEMsH9a2KCKK for ; Sat, 30 Oct 2021 07:41:59 -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 F1AB73A0E7C for ; Sat, 30 Oct 2021 07:41:58 -0700 (PDT) Received: (qmail 53794 invoked from network); 30 Oct 2021 14:41:55 -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; s=d21e.617d59b3.k2110; bh=3t2hgSeMHeE2fPi9dH3r6Xk9Nv46oJHHjJ7MFrQDUfc=; b=P1suBbcN+CXlR209/MYjJq6UOT7MMMj9rl19rPS/JQ6FT39ODvydofHKvbttdWOhaKBniOonkFS+C914sUVAdvjXRhoSeA8cQDXmv/KEOl95eNSJsgQAciKvnfi3R336HzNkHCzRCYmT8XcosP1V9LPLh5JrVOxH9RO/+r9XOpbO271R+Fxf4kWP5xZKH3FzQhOp+SFp9PTFxORx73yZBnDuhDoBcGwvTHOnE7oHkDxJXGs23BPCXc6ah2/TzfyVdGJnLFf+K1FuATNNWwaQiqgYBoLcKq13LWwipz2M80Dy1cOO5LCuBsE22lGPZppF1c+mQ2aJ+FVmDGXd8fyuVg== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 30 Oct 2021 14:41:55 -0000 Received: by ary.qy (Postfix, from userid 501) id 308F82F4610D; Sat, 30 Oct 2021 10:41:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 9E5AD2F460EF; Sat, 30 Oct 2021 10:41:54 -0400 (EDT) Date: 30 Oct 2021 10:41:54 -0400 Message-ID: From: "John R. Levine" To: "Julian Reschke" , xml2rfc@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [xml2rfc] New xml2rfc release: v3.11.0 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XML2RFC discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2021 14:42:04 -0000 It's not a problem. The license has not changed, only the name we use to refer to it. The old name was wrong so I suppose we could send in several thousand errata reports to correct it in all the places it appears, but that doesn't seem like a good use of anyone's time. R's, John > Am 29.10.2021 um 19:57 schrieb rjsparks@nostrum.com: >> >> Hi, >> >> This is an automatic notification about a new xml2rfc release, >> v3.11.0, generated when running the mkrelease script. >> >> Release notes: >> >> xml2rfc (3.11.0) ietf; urgency=high >> >> * Merged in [4061] from krathnayake@ietf.org: >> Fixes a case where an infinite loop could occur in text rendering. >> Fixes #684. >> >> * Merged in [4059] from krathnayake@ietf.org: >> Updates TPL 5 boilerplate text from Simplified to Revised. Fixes #676. >> ... > > FWIW, this is problematic, because it will change the copyright text of > *published* RFCs should they ever be re-generated from XML. It would be > better to make this depend on the publication date. > > Best regards, Julian