IETF Logo Mail Archive

Re: [Lager] Stephen Farrell's Discuss on draft-ietf-lager-specification-11: (with DISCUSS and COMMENT)

"Asmus Freytag (c)" <asmusf@ix.netcom.com> Sat, 23 April 2016 17:54 UTC

Return-Path: <asmusf@ix.netcom.com>
X-Original-To: lager@ietfa.amsl.com
Delivered-To: lager@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3505012D508 for <lager@ietfa.amsl.com>; Sat, 23 Apr 2016 10:54:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.819
X-Spam-Level:
X-Spam-Status: No, score=-0.819 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com
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 eGojqJvF2pLQ for <lager@ietfa.amsl.com>; Sat, 23 Apr 2016 10:54:04 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id CF60A12D1B7 for <lager@ietf.org>; Sat, 23 Apr 2016 10:54:03 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=hk51ISXUlEwu4zgx5gn3bRs/Hbm6axhswHmGQk60s6F4WTxDYtxrLwOfC6NQ4Sqp; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [71.212.2.16] (helo=[192.168.0.4]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <asmusf@ix.netcom.com>) id 1au1kh-0006fS-Gk for lager@ietf.org; Sat, 23 Apr 2016 13:53:55 -0400
To: lager@ietf.org
References: <20160421102401.19578.54300.idtracker@ietfa.amsl.com> <1461412191.851961.587365345.53A5CC4C@webmail.messagingengine.com> <571B634F.9070600@cs.tcd.ie>
From: "Asmus Freytag (c)" <asmusf@ix.netcom.com>
Message-ID: <571BB6C2.3050906@ix.netcom.com>
Date: Sat, 23 Apr 2016 10:54:10 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <571B634F.9070600@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="------------040400070806060205050906"
X-ELNK-Trace: 464f085de979d7246f36dc87813833b2b484d7840976cb7e691d3568164324f2209e1f604c622c0b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 71.212.2.16
Archived-At: <http://mailarchive.ietf.org/arch/msg/lager/_w6gnBTHlg6dWyfcdEphSki0wLo>
Subject: Re: [Lager] Stephen Farrell's Discuss on draft-ietf-lager-specification-11: (with DISCUSS and COMMENT)
X-BeenThere: lager@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Label Generation Rules <lager.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lager>, <mailto:lager-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lager/>
List-Post: <mailto:lager@ietf.org>
List-Help: <mailto:lager-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lager>, <mailto:lager-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Apr 2016 17:54:05 -0000

On 4/23/2016 4:58 AM, Stephen Farrell wrote:
>> Correct me if I am wrong, but I haven't seen any XML generator that
>> >reorders XML elements, unless they understand XML schema for a
>> >particular XML document. So by default order of XML elements withing
>> >parent elements is fixed, so I don't think this is an issue.
> I'm happy to be corrected, but this was a big (and painful) deal
> for xmldsig, so I'm not sure why it'd not be an equal PITA here;-)

There are many XML schema where the order of elements cannot be 
rearranged without changing the content of what the document describes. 
Anything where the XML elements correspond to nodes of a text document, 
for example.

I'm sure we can add a sentence, perhaps to the document structure 
section, that warns about the nature of this constraint, so that one 
doesn't have to discover it from the places where the specific details 
are mentioned.

Otherwise, the issue seems to have been a non-issue for the existing 
implementations.

A./

v2.23.0 | Report a Bug | By Email