Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)
Matthäus Wander <mail@wander.science> Thu, 13 May 2021 21:29 UTC
Return-Path: <mail@wander.science>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E603A14B3 for <dmarc@ietfa.amsl.com>; Thu, 13 May 2021 14:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-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=wander.science
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 i-OzP3PjqIut for <dmarc@ietfa.amsl.com>; Thu, 13 May 2021 14:29:08 -0700 (PDT)
Received: from mail.swznet.de (cathay.swznet.de [IPv6:2a01:4f8:13b:2048::113]) (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 3E7A43A149A for <dmarc@ietf.org>; Thu, 13 May 2021 14:29:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wander.science; s=cathay; h=Subject:Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Sender:Reply-To: Cc:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=aa3zlwzzRj9AmEG4NCP0CQ/DokuC4DJLcKnlKYJMNAs=; b=Aik/WNJMS0beLOF3kiyG318/g1 X1IzKpn0lTwu0jT++CEsmYuxZypsikXda1BuIuiYJbDZFXRp1GATOzkKppOTNa38cwtQ2bKA+OaES bFMxsRWypOMjHcQkbTXg4qZvXD4mn+nf4WoKtCXwgIEa1ab/BSJi5I8pP4PTX61YCukvhdx2hTDY3 s/Guvd8vwR2TvZPx2LmCFuyT5mJtoc9vWMVLrzMnk4PTfQ6Dsk0uAcw4oCfEuUMqNvwu0arVlGBbF Q/NAlARUD6/s44LJjGiVsq6Pdh1eW5fgOl194famJv5o2vjpuXPEXYgmU5+D1VlnEqkly/D8tZo4D GUDFXaHA==;
Received: from dynamic-2a01-0c23-6cab-5b00-ac54-fc74-5990-35b2.c23.pool.telefonica.de ([2a01:c23:6cab:5b00:ac54:fc74:5990:35b2]) by mail.swznet.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <mail@wander.science>) id 1lhItE-0002p8-Co for dmarc@ietf.org; Thu, 13 May 2021 23:29:05 +0200
To: dmarc@ietf.org
References: <bc3c25c0-2ec9-2e39-1dd6-1cc08521d03b@wander.science> <2bfed96b-9247-2af1-809c-4f8065ebf64c@gmail.com> <c49bc771-a95e-b78b-dc11-db0cb06ad688@tana.it>
From: Matthäus Wander <mail@wander.science>
Message-ID: <44bdbe41-a43a-f6a4-9788-faaf67db6636@wander.science>
Date: Thu, 13 May 2021 23:29:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <c49bc771-a95e-b78b-dc11-db0cb06ad688@tana.it>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 2a01:c23:6cab:5b00:ac54:fc74:5990:35b2
X-SA-Exim-Mail-From: mail@wander.science
X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +0000)
X-SA-Exim-Scanned: Yes (on mail.swznet.de)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/R_x_eDLmxqkE3vxTBZMBYcCU1DE>
Subject: Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2021 21:29:13 -0000
Alessandro Vesely wrote on 2021-05-10 18:29: > On Mon 10/May/2021 17:28:20 +0200 Dave Crocker wrote: >> If an new spec merely /adds/ to a previous spec, then the presence of >> the new constructs is self-declaring. The only requirement is to have >> the base specification declare that unrecognized constructs are to be >> ignored. So, versioning adds the illusion of utility, but really only >> adds unnecessary complexity. > > > I think the format we'll end up with will be pretty compatible with the > existing practice, meaning that existing report consumers that use a > proper XML parser and ignore unknown tags can work unchanged. I don't > think any consumer parses reports "by hands". Alright, introducing incompabilities is off the table and backward compability is a must. This brings #51 into question, which may affect backward compability. https://trac.ietf.org/trac/dmarc/ticket/51 Regarding the existing top-level <version> below <feedback>: Even if parsers don't require the version to function, it remains useful for measuring the adoption of the different DMARC specifications (as requested in #70). In fact, one implementation I looked at (parsedmarc) uses it for only this purpose. A missing <version> is logged as "draft" schema version. Regarding the XML namespace declaration: The XML schema serves not only as specification for developers, but can be also used for automatic syntax checks of reports -- provided that the namespace declaration is fixed. XSD validation is an immensely useful tool for testing the output of report generators. It helped me to discover two nasty bugs in an implementation, which appeared in 2 out of ~10k reports and would have gone unnoticed otherwise. A version number within the schema is not necessary for this use case. A different matter is whether automatic XSD validation on the report consumer side is a supported use case. There is some value in it: two lines of code suffice to perform input validation. However, the validation is strict and does not allow for being liberal in what you accept (might be handy for protocol police, though). Achieving upward compatibility is not trivial, because there is no general "ignore all unknown elements" statement in XSD. It is possible to define a <xs:any> placeholder in the schema, but this element must be inserted explicitly into each place where extensibility is desired. This would require careful foresight in the schema design. Regards, Matt
- [dmarc-ietf] Versioning and XML namespaces in agg… Matthäus Wander
- Re: [dmarc-ietf] Versioning and XML namespaces in… John Levine
- Re: [dmarc-ietf] Versioning and XML namespaces in… Dave Crocker
- Re: [dmarc-ietf] Versioning and XML namespaces in… Matthäus Wander
- Re: [dmarc-ietf] Versioning and XML namespaces in… Alessandro Vesely
- Re: [dmarc-ietf] Versioning and XML namespaces in… Matthäus Wander
- Re: [dmarc-ietf] Versioning and XML namespaces in… Brotman, Alex
- Re: [dmarc-ietf] Versioning and XML namespaces in… Alessandro Vesely
- Re: [dmarc-ietf] Versioning and XML namespaces in… Brotman, Alex
- Re: [dmarc-ietf] Versioning and XML namespaces in… Matthäus Wander
- Re: [dmarc-ietf] Versioning and XML namespaces in… Alessandro Vesely