Re: Basic ietf process question ...

"Joe Hildebrand (jhildebr)" <jhildebr@cisco.com> Thu, 02 August 2012 21:17 UTC

Return-Path: <jhildebr@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A26C11E81C5 for <ietf@ietfa.amsl.com>; Thu, 2 Aug 2012 14:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 rd8rc9dUBGW6 for <ietf@ietfa.amsl.com>; Thu, 2 Aug 2012 14:17:41 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9B33211E81B3 for <ietf@ietf.org>; Thu, 2 Aug 2012 14:17:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=1265; q=dns/txt; s=iport; t=1343942261; x=1345151861; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=HzoEA7JTuBatVAFRUn3qUUgAe97uV3w2HS8lz8vawDg=; b=YTFOK2bbwfHqEr+uDdx4fSCfT/s8TFgujkPVm2J6D6v8Qy5uXMWVmsgC kGo+1C+Sf83QQLUARQopC3cWx/HAQZjLAv55mye/+Jqu2m0cRKvnjdOJf pq3Ws+yLjxnRYJ1VwAWP3LwZfODpgWU5H5BGiRMlZuJt9tXkT94hhPFm7 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAFHtGlCtJV2Y/2dsb2JhbABFuRuBB4InEgEnPxIBCDZCJQIEDgUih2ucfaBGkk4DlUeLDQGDGYFmgl8
X-IronPort-AV: E=Sophos;i="4.77,703,1336348800"; d="scan'208";a="108002247"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 02 Aug 2012 21:17:41 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q72LHf1I021569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 21:17:41 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.184]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 16:17:40 -0500
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: "robert@raszuk.net" <robert@raszuk.net>
Subject: Re: Basic ietf process question ...
Thread-Topic: Basic ietf process question ...
Thread-Index: AQHNcPQ/BZi3xKSMb02eb5YX2IuheA==
Date: Thu, 02 Aug 2012 21:17:39 +0000
Message-ID: <CC403A23.1BE60%jhildebr@cisco.com>
In-Reply-To: <501AA9DF.6010208@raszuk.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.73.213]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.000
x-tm-as-result: No--36.795500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8B808C9C9F6D9C479E4ADD9EBE4A3AE7@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 03 Aug 2012 08:52:14 -0700
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 21:17:42 -0000

On 8/2/12 9:25 AM, "Robert Raszuk" <robert@raszuk.net> wrote:

>Does anyone have a good reason why any new protocol definition or
>enhancement does not have a build in mandatory "XML schema" section
>which would allow to actually use such standards based enhancement in
>vendor agnostic way ?

For docs that use XML, requiring some form of schema makes sense.
However, what we're finding at the application layer is that often times
using JSON (see RFC 4627) ends up with better interoperability more
quickly than using XML, except in the case of human-readable content like
marked-up text.  See RFC 6120, Appendix A (http://goo.gl/CBv8G) for
another example.

For those that insist on XML, RelaxNG (http://goo.gl/MYnB1) is another
language you can use to describe your XML, which is a little easier to
learn than XSD.

However, for implementors, if you start with the schema and blindly use it
for conformance checking of real-world traffic, you are likely to have
both performance and extensibility issues in practice.

If folks at other layers in the stack would like input from Apps folks,
I'm sure that we would be happy to share our lessons learned.  Join
apps-discuss (http://goo.gl/0Otjv) and ask for help.

-- 
Joe Hildebrand