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

Dave Crocker <> Mon, 10 May 2021 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B94D3A20D2 for <>; Mon, 10 May 2021 08:28:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NBVDO8qrgRIu for <>; Mon, 10 May 2021 08:28:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 146783A20D0 for <>; Mon, 10 May 2021 08:28:24 -0700 (PDT)
Received: by with SMTP id n16so9307135plf.7 for <>; Mon, 10 May 2021 08:28:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=oZKxVcC1oBbTr8fzsEVbj5bm6PIf5cH8Toq6CdepCHU=; b=YVunuhAMb+1aiDhPIxBpjgOIHF66qyhu5W8wqr7oc6Su8SzFJhjCoy79eGJv4xVO3z UYbrWylqscGm/Ejr15VFTrW4j/EA0kKe0ImUtbYj86XelZSPm+z+VjL3CUdaKS5VvDMR fiWJ1oXeHe4hxN6VqNCS6UGgIiEK4EflREz04aj/oLtz7zUlHEV0v3G4pVcWSPix3lOx RJuIz0laOPWVg6KuIxhFlFnaU5tjS64t5CsTQttsjF1k/VHzDOUFNG39GYfVCEA6ifz2 KvJrV8VramYHFqjhT10UlXSyt3kkDPbNm6xx5Fmeq5RXm9QwlsxV4TrC6SPXaXBaLsqd kZ9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=oZKxVcC1oBbTr8fzsEVbj5bm6PIf5cH8Toq6CdepCHU=; b=oV6AJOiyPfDzrUGk3VDM/7Jku//dA5QJ4JuRzmuVAzrHmGt2YG59yjIPppyhy+JXg2 o2QOrezpCQzP5TgNOzqYpPwiVROtvavt89bAXzvOp8P2a40+jaaZ4tBaCM4NHm0+sBX7 ixFTlSDmTDn6QB/vHA4E25d6OxFPnjG8SQkgaMeR8II8dW3Ywa2+rD0WQGBnnRmvUZa5 Xu1aDarD3PvTSUiVvUKPjGZBw8sXEO5VK9I7ftDPDCQNe/dWpKT/9ucGE0KmzINbOuyz sFKyuZlPqlwFaHbDtXz87UrfJo52HrjLhX6oYOl52rj/y06HDE7GPRShxOZXP32WKz1v Rruw==
X-Gm-Message-State: AOAM531Ax2cFTO31vGMOfpLAmpKdqgNwuoat0l2NKcY8f937uZDf7/br +7ArhFqb3A39M4lZEzkHLHJaC157hAnQGg==
X-Google-Smtp-Source: ABdhPJya4dObtybm4i4bWsz86hKZTSRIYwlUodPgDzwpKGi4LNouYYRWo1C/hr+hU7T2RAReq4Egmw==
X-Received: by 2002:a17:90a:eb08:: with SMTP id j8mr28752569pjz.54.1620660503467; Mon, 10 May 2021 08:28:23 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id v14sm7773887pgl.86.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 May 2021 08:28:23 -0700 (PDT)
To: =?UTF-8?Q?Matth=c3=a4us_Wander?= <>,
References: <>
From: Dave Crocker <>
Message-ID: <>
Date: Mon, 10 May 2021 08:28:20 -0700
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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 May 2021 15:28:29 -0000

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.

The distinction to make is 'increments' versus 'incompatibilities'.l

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.

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.


Dave Crocker

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross