Re: [mile] What is Version (5070bis, enum, etc.)

Eric Burger <eburger-l@standardstrack.com> Wed, 13 March 2013 15:27 UTC

Return-Path: <eburger-l@standardstrack.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF1021F8EAC for <mile@ietfa.amsl.com>; Wed, 13 Mar 2013 08:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeRbo8UbMfYd for <mile@ietfa.amsl.com>; Wed, 13 Mar 2013 08:27:52 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7657621F89AA for <mile@ietf.org>; Wed, 13 Mar 2013 08:27:51 -0700 (PDT)
Received: from dhcp-42e0.meeting.ietf.org ([130.129.66.224]:57498) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <eburger-l@standardstrack.com>) id 1UFnah-00017C-Eo for mile@ietf.org; Wed, 13 Mar 2013 08:27:43 -0700
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Eric Burger <eburger-l@standardstrack.com>
In-Reply-To: <75782EF7-F21F-44DD-929C-AF4A37BDD860@standardstrack.com>
Date: Wed, 13 Mar 2013 11:27:43 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <384B5B5D-09AE-4A6A-AFCA-93DA799E014E@standardstrack.com>
References: <75782EF7-F21F-44DD-929C-AF4A37BDD860@standardstrack.com>
To: MILE IETF <mile@ietf.org>
X-Mailer: Apple Mail (2.1499)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [mile] What is Version (5070bis, enum, etc.)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2013 15:27:52 -0000

5070, 5070bis, and ENUM all use a 'version' attribute. 

Section 3.1 of both 5070 and 5070bis define version as:
     Required.  STRING.  The IODEF specification version number to
     which this IODEF document conforms.  The value of this attribute
     MUST be "1.00"

OK, I will bite. The schema of 5070 and 5070bis are different. How do I know I have a 5070bis schema if it says <IODEF-Document version="1.00">? It is totally non-normative, but I suppose someone who is clueless about protocols would look at the double super secret <documentation> tag that says "Incident Object Description Exchange Format v1.00, see RFC 5070" for a 5070 document and "Incident Object Description Exchange Format v1.10, RFC5070-bis" for a 5070bis document. I say "double super secret" because that string only appears in the schema but has no text describing it. Also, making a programatic decision based on XML Schema documentation is not a very smart idea.

Let me push this further. What happens if a 5070bis document has <IODEF-Document version="1.10">? 5070 and 5070bis both say… nothing. However, a good protocol writer will see the 'MUST be "1.00"' and thus will reject the document. Is this the desired behavior? If so, say so. I doubt it, but we are begging for interoperability failure if IODEF becomes successful and we enhance it in the future.

Enum reference format suffers from this as well, but I will address that in a separate email.