From rden@loc.gov Mon Feb 23 14:17:18 2009 Return-Path: X-Original-To: architecture-discuss@core3.amsl.com Delivered-To: architecture-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F4828C207 for ; Mon, 23 Feb 2009 14:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.184 X-Spam-Level: X-Spam-Status: No, score=-4.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poXs8uA+iiYi for ; Mon, 23 Feb 2009 14:17:17 -0800 (PST) Received: from ntgwgate.loc.gov (ntgwgate.loc.gov [140.147.137.18]) by core3.amsl.com (Postfix) with ESMTP id 8243B28C198 for ; Mon, 23 Feb 2009 14:17:14 -0800 (PST) Received: from LCHub-MTA by ntgwgate.loc.gov with Novell_GroupWise; Mon, 23 Feb 2009 17:17:24 -0500 Mime-Version: 1.0 Date: Mon, 23 Feb 2009 17:17:14 -0500 X-Mailer: Groupwise 6.5 Message-ID: <20090223T171714Z_ADBF00110000@loc.gov> From: "Ray Denenberg" To: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="____PPIYIJTFQJRIHUSVPFHZ____" Subject: [arch-d] Please ignore this message X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:17:18 -0000 --____PPIYIJTFQJRIHUSVPFHZ____ Content-Type: text/plain; charset=utf-8 Content-Language: Content-Transfer-Encoding: base64 U29ycnkuICBJJ3ZlIGhhZCBhIGhlbGwgb2YgYSB0aW1lIHRyeWluZyB0byBzdWJzY3JpYmUgdG8g dGhpcyBsaXN0LCBhbmQgSSB3YW50IHRvIHNlZSBpZiBJJ3ZlIGZpbmFsbHkgYmVlbiBhYmxlIHRv LiA= --____PPIYIJTFQJRIHUSVPFHZ____ Content-Type: multipart/related; boundary="____SSGWVMPZORBBJMWQMQXL____" --____SSGWVMPZORBBJMWQMQXL____ Content-Type: text/html; charset=utf-8 Content-Language: Content-Transfer-Encoding: base64 PEhUTUw+PEhFQUQ+DQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC4z NDkyIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBzdHlsZT0iTUFSR0lOOiA0cHggNHB4 IDFweDsgRk9OVDogMTBwdCBUYWhvbWEiPlNvcnJ5LiAmbmJzcDtJJ3ZlIGhhZCBhIGhlbGwgb2Yg YSB0aW1lIHRyeWluZyB0byZuYnNwO3N1YnNjcmliZSB0byB0aGlzIGxpc3QsIGFuZCBJIHdhbnQg dG8gc2VlIGlmIEkndmUgZmluYWxseSBiZWVuIGFibGUgdG8uIDwvQk9EWT48L0hUTUw+ --____SSGWVMPZORBBJMWQMQXL____-- --____PPIYIJTFQJRIHUSVPFHZ____-- From rden@loc.gov Mon Feb 23 14:25:51 2009 Return-Path: X-Original-To: architecture-discuss@core3.amsl.com Delivered-To: architecture-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6423A6810 for ; Mon, 23 Feb 2009 14:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.462 X-Spam-Level: X-Spam-Status: No, score=-4.462 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-NCBC+R8vom for ; Mon, 23 Feb 2009 14:25:50 -0800 (PST) Received: from sun8.loc.gov (sun8.loc.gov [140.147.249.48]) by core3.amsl.com (Postfix) with ESMTP id EA86D3A67B4 for ; Mon, 23 Feb 2009 14:25:49 -0800 (PST) Received: from lsdds9qg1 (lsdds9qg1.lib.loc.gov [140.147.175.24]) by sun8.loc.gov with SMTP id n1NMQ6li003862; Mon, 23 Feb 2009 17:26:07 -0500 (EST) Message-ID: <136001c99605$b8ae3fc0$18af938c@lib.loc.gov> From: "Ray Denenberg, Library of Congress" To: References: <20090223T171714Z_ADBF00110000@loc.gov> Date: Mon, 23 Feb 2009 17:26:06 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_135D_01C995DB.CF89A290" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Proofpoint-Spam-Reason: safe Subject: Re: [arch-d] version numbers X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:25:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_135D_01C995DB.CF89A290 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (This is intended to be part of the thread on version numbers.) I just ran across this thread. I'm very much interested in the subject, = not so much for protocols -- I agree with the sentiments expressed on = versions for protocols -- but I'm interested in the issue of versions = for formats. Let's take an example. The MODS format for bibliographic metadata.=20 Homepage at http://www.loc.gov/standards/mods/ and the current schema is = http://www.loc.gov/standards/mods/v3/mods-3-3.xsd. The latest version is 3.3. There are several earlier version, and, as is = common practice: when we move to a new minor version (e.g. 3.2 to 3.3) = instances of the earlier version conform to the new version (though not = vice versa); when we move to a new major version (e.g. 3.3 to 4.0) all = bets are off. There is a version attribute defined within the schema, a = mandatory attribute for every instance. Now, I am in the process of putting together a registration request for = a mime type for MODS, "application/mods+xml". (Among other related = formats. This is because people want to do content negotiation among the = related formats. But let's not get into that or we'll get terribly = sidetracked.) Studying existing mime type registrations, I cannot find one in which = the issue of different possible versions of a format is taken into = consideration.=20 For example, "application/xhtml+xml" is for xhtml 1.0, according to rfc = 3236 . So how does that apply to xhtml 1.1? Is the statement in the rfc = that it's for 1.0 just ignored?=20 Clearly we don't want to be registering a mime type for every new = version, so wouldn't it be better if the registration is independent of = version? Could the version instead be indicated, for example by a mime = parameter? I'm very interested in thoughts on this. --Ray Denenberg ------=_NextPart_000_135D_01C995DB.CF89A290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF

(This is intended to be part of the thread on version=20 numbers.)

I just ran across this thread. I'm very much = interested in the=20 subject, not so much for protocols -- I agree with the sentiments = expressed on=20 versions for protocols -- but I'm interested in the issue of versions = for=20 formats.

Let's take an example. The MODS format for = bibliographic=20 metadata.

Homepage at http://www.loc.gov/standards/mods/ and = the=20 current schema is http://www.loc.gov/standards/mods/v3/mods-3-3.xsd.

The latest version is 3.3. There are several earlier version, and, as = is=20 common practice: when we move to a new minor version (e.g. 3.2 to 3.3) = instances=20 of the earlier version conform to the new version (though not vice = versa); when=20 we move to a new major version (e.g. 3.3 to 4.0) all bets are off. There = is a=20 version attribute defined within the schema, a mandatory attribute for = every=20 instance.

Now, I am in the process of putting together a registration request = for a=20 mime type for MODS, "application/mods+xml". (Among other related = formats. This=20 is because people want to do content negotiation among the related = formats. But=20 let's not get into that or we'll get terribly sidetracked.)

Studying existing mime type registrations, I cannot find one in which = the=20 issue of different possible versions of a format is taken into = consideration.=20

For example, "application/xhtml+xml" is for xhtml 1.0, according to = rfc 3236=20 . So how does that apply to xhtml 1.1? Is the statement in the rfc that = it's for=20 1.0 just ignored?

Clearly we don't want to be registering a mime type for every new = version, so=20 wouldn't it be better if the registration is independent of version? = Could the=20 version instead be indicated, for example by a mime parameter?

I'm very interested in thoughts on this.

--Ray Denenberg

 

 

 

 

------=_NextPart_000_135D_01C995DB.CF89A290--