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

Matthäus Wander <mail@wander.science> Mon, 10 May 2021 14:10 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 BC5F53A1E29 for <dmarc@ietfa.amsl.com>; Mon, 10 May 2021 07:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 h3RqwCLJfH6I for <dmarc@ietfa.amsl.com>; Mon, 10 May 2021 07:10:38 -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 5246D3A1E2A for <dmarc@ietf.org>; Mon, 10 May 2021 07:10:38 -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: MIME-Version:Date:Message-ID:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Px6Xiu/zLMjyBOp3Bv9UxEzx5vneXaNQ98Os+2D8LUc=; b=F5Si1mTA7IH7+wNVJVNDzJloxI 5A9pjbd3JHRNT5Lt+K+PbZD/VNPC++ffFWydVdwuDjPY1lEpPnED9/s++XW9RZl9kowNj9DCr0LB+ 80Ggl4hF3EuWEAjs+gxBxUqGStwrx1+nB8VpbYbORw2W58wIphFcQDLBV83Rigcj6h0c7I0NgT828 87SVLAWA6VBzJQC16UGiuX6o0BfRRjw9rkz7YFc9ef4ZrU0Nl4ueUSXZZToCcncMC3m8Q9mYnV+Ki mm5WVrlDjJq8ERIoop/AG2jboC765LVhmGK5yj249+nslhBE/pUWWXs54dxSqngF3gxt8NGMz/R84 7L+BBkTQ==;
Received: from dynamic-2a01-0c23-7438-1000-3171-3371-9450-e3dd.c23.pool.telefonica.de ([2a01:c23:7438:1000:3171:3371:9450:e3dd]) by mail.swznet.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <mail@wander.science>) id 1lg6cD-0006hp-4L for dmarc@ietf.org; Mon, 10 May 2021 16:10:35 +0200
To: dmarc@ietf.org
From: Matthäus Wander <mail@wander.science>
Message-ID: <bc3c25c0-2ec9-2e39-1dd6-1cc08521d03b@wander.science>
Date: Mon, 10 May 2021 16:10:30 +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
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 2a01:c23:7438:1000:3171:3371:9450:e3dd
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/JdRxmT9Aw3HkWM7rr3Av9B3EwRc>
Subject: [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 14:10:44 -0000

1) #33 suggests to add a versioned XML namespace declaration in the root
<feedback> element.
https://trac.ietf.org/trac/dmarc/ticket/33

I support the use of the namespace declaration. A report with namespace
declaration allows for automatic syntax checks with XML Schema
Validation. XSD validators refuse to work without the declaration. It
should be added to the examples in the I-D.

Example report:
  <dmarc:feedback xmlns:dmarc="http://dmarc.org/dmarc-xml/0.2">
  ...
  </dmarc:feedback>

A shorter variant is possible if we change the schema slightly:
  <feedback xmlns="http://dmarc.org/dmarc-xml/0.2">
  ...
  </feedback>

Adapted schema with elementFormDefault:
  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://dmarc.org/dmarc-xml/0.2"
    xmlns="http://dmarc.org/dmarc-xml/0.2"
    elementFormDefault="qualified">

Nit: I'd use 2.0 instead of 0.2.

2) #33 goes further and suggests to remove the <version> tag below
<feedback>, because it is redundant with the namespace declaration.

I wouldn't recommend the removal. RFC 7489 has introduced tag
<version>1.0</version> and existing implementations will rely on its
existence. Without <version>, chances are the report consumer interprets
the report as pre-IETF draft version.

3) #70 introduces a new <version> field, but this one is below
<report_metadata> and seems to have the purpose to inform about which
DMARC standard has been used for validation.
https://trac.ietf.org/trac/dmarc/ticket/70

Is it useful to announce separate version numbers for the DMARC
algorithm and the report format? I imagine, the RFC 7489 <version> would
do the job for both purposes.

4) How does the report generator know which format version the consumer
supports?

Ideas:
a) Send new format and don't care about old versions.
b) Send new format but avoid compatibility breaking changes in the XML
design. Add new fields, but do not change existing ones like
<disposition> (cf. #51, #75).
c) Consumer announces supported version in DNS record ("rua2=" or whatever).
d) Send both versions (... for how long?).

Regards,
Matt