Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)

Alessandro Vesely <vesely@tana.it> Mon, 10 May 2021 16:29 UTC

Return-Path: <vesely@tana.it>
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 F2A103A228F for <dmarc@ietfa.amsl.com>; Mon, 10 May 2021 09:29:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 w550GMeLHkW7 for <dmarc@ietfa.amsl.com>; Mon, 10 May 2021 09:29:42 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 1AA913A2293 for <dmarc@ietf.org>; Mon, 10 May 2021 09:29:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1620664179; bh=HWR6NulE0urB/Ei5yAkzSmoLdCK9DTlVqDc4YzDWsaQ=; l=1780; h=To:References:From:Date:In-Reply-To; b=CVdqZR/OL75YYwaQn1jrQOwlBpjDFIr1aOiBRslQ+ALeoFdyQMz7LHcWc5v2z6oIw sIVqOZLe9UuhLkR5NkT0HJqV1hP4arPMhWyylFFb9zb/8OP90O/HFfgRT569pB6DnJ OkGYyhvw3mhEKu6/c9HRzUXPA3gz/Z8OHeZVzbM0y/x6IX/PPJX7DqmOL1IbF
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC028.0000000060995F73.000022FD; Mon, 10 May 2021 18:29:39 +0200
To: Dave Crocker <dcrocker@gmail.com>, =?UTF-8?Q?Matth=c3=a4us_Wander?= <mail@wander.science>, dmarc@ietf.org
References: <bc3c25c0-2ec9-2e39-1dd6-1cc08521d03b@wander.science> <2bfed96b-9247-2af1-809c-4f8065ebf64c@gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <c49bc771-a95e-b78b-dc11-db0cb06ad688@tana.it>
Date: Mon, 10 May 2021 18:29:37 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <2bfed96b-9247-2af1-809c-4f8065ebf64c@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/37QyIzuXXO_5hzFnlVhIrwoGmAI>
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: Mon, 10 May 2021 16:29:47 -0000

On Mon 10/May/2021 17:28:20 +0200 Dave Crocker wrote:
> On 5/10/2021 7:10 AM, Matthäus Wander wrote:
>> I support the use of the namespace declaration. A report with namespace
>> declaration allows for automatic syntax checks with XML Schema
>> Validation.
> 
> Version numbers, and the like, tend to be a lot less useful than intuition 
> leads one to expect.


Automatic syntax checks are a different beast, though.


> The distinction to make is 'increments' versus 'incompatibilities'.
> 
> 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".

The added complexity of using proper XML constructs to define the format, as 
well as properly formatting each instance, enables advanced use of XML parsing 
tools.  Did you notice no site offers aggregate report validation services?


> Incompatibilities, where new constructs conflict with previous ones, mean that 
> the new specification is not a new version.  It is an independent 
> specification.  It needs to be labeled accordingly.


This is not our case.  Even if we find a better TLD for the targetNamespace 
URL, the format is going to be the first official version of DMARC aggregate 
report format, following the one(s) in use since 2012.


Best
Ale
--