From discuss-bounces@apps.ietf.org Tue Jan 01 16:11:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9oOW-0005yc-6r; Tue, 01 Jan 2008 16:11:28 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J9oOU-0005pE-57 for discuss-confirm+ok@megatron.ietf.org; Tue, 01 Jan 2008 16:11:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9oOT-0005ns-RJ for discuss@apps.ietf.org; Tue, 01 Jan 2008 16:11:25 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9oOT-0006iw-1b for discuss@apps.ietf.org; Tue, 01 Jan 2008 16:11:25 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DAEBC142254; Tue, 1 Jan 2008 13:11:26 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4B05khDts-85; Tue, 1 Jan 2008 13:11:24 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 21E9F142245; Tue, 1 Jan 2008 13:11:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-3--276137684 To: Apps Discuss , Lisa Dusseault's Chairs Subject: Lisa's Apps Area activity for Dec 2007 From: Lisa Dusseault Date: Tue, 1 Jan 2008 13:11:17 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-3--276137684 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Notes Brief report due to not much activity over holidays Document Status and Progress Active Documents: my action - draft-ellermann-news-nntp-uri (Proposed Standard): I need to review - draft-wilde-sms-uri (Proposed Standard): I need to do a writeup -- no doc shepherd. Major issue to deal with: overlap with tel URI. Stalled, in review, waiting on other: - draft-ietf-sieve-body (Proposed Standard): On agenda 1/10 for IESG Evaluation - draft-adolf-dvb-urn (Informational): same - draft-evain-ebu-urn (Informational): Need new text or version to address secdir review - draft-klensin-rfc2821bis (Draft Standard): IETF Last Call is over, author and shepherd are taking some time before deciding how to address last call issues. - draft-ietf-sieve-notify: Doc shepherd is dealing with DISCUSS issues - draft-ietf-sieve-notify-xmpp: same - draft-creed-ogc-urn (Informational): Waiting for new version to deal with IESG eval input. - draft-ietf-sieve-notify-mailto: waiting on new version after IETF last call - draft-snell-atompub-bidi (Proposed Standard): author waiting on some implementation feedback - draft-ietf-imapext-sort (Proposed Standard) : waiting for authors to revise or decide it's ready Finished Processing -- RFC Ed queue and new RFCs - draft-goodwin-iso-urn (Informational): Approved, waiting until post-holiday processing to enter RFC queue - draft-sjdcox-cgi-urn (Informational): same - draft-mealling-epc-urn (Informational) - draft-saintandre-rfc4622bis (Proposed Standard) - draft-crocker-rfc4234bis (Standard) - draft-ietf-sieve-3028bis (Proposed Standard) WG Status - not much action other than SIEVE, CALSIFY and HTTP meetings at IETF71. --Apple-Mail-3--276137684 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Brief report due to not much = activity over holidays

Document Status and Progress

Active = Documents: my action
=A0-=A0draft-wilde-sms-uri = (Proposed Standard):=A0I need to do a writeup -- no doc shepherd.=A0 = Major issue to deal with: overlap with tel URI.

Stalled, = in review, waiting on other:
=A0-=A0draft-adolf-dvb-urn = (Informational): same
=A0-=A0draft-evain-ebu-urn = (Informational): Need new text or version=A0 to address secdir = review=A0
=A0- = draft-ietf-sieve-notify: Doc shepherd is dealing with DISCUSS = issues
=A0- = draft-ietf-sieve-notify-xmpp:=A0 same
=A0- = draft-ietf-sieve-notify-mailto:=A0waiting on new version after IETF last = call
=A0-=A0draft-snell-atompub-bidi = (Proposed Standard): author waiting on some implementation = feedback
=A0-=A0draft-ietf-imapext-sort = (Proposed Standard) : waiting for authors to revise or decide it's = ready

Finished Processing -- RFC Ed queue and new = RFCs
=A0-=A0draft-goodwin-iso-urn = (Informational): Approved, waiting until post-holiday processing to = enter RFC queue
-=A0draft-sjdcox-cgi-urn = (Informational): same
=A0-=A0draft-mealling-epc-urn= (Informational)
=A0-=A0draft-saintandre-rfc4622bis= (Proposed Standard)
=A0-=A0draft-crocker-rfc4234b= is (Standard)
=A0-=A0draft-ietf-sieve-3028bis = (Proposed Standard)

WG Status
=A0- not much = action other than SIEVE, CALSIFY and HTTP meetings at = IETF71.

= --Apple-Mail-3--276137684-- From discuss-bounces@apps.ietf.org Thu Jan 03 19:20:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAaI3-0005HH-B6; Thu, 03 Jan 2008 19:19:59 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAaG2-0003Ad-AS for discuss-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 19:17:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAaG2-0003AU-0i for discuss@apps.ietf.org; Thu, 03 Jan 2008 19:17:54 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAaG0-00033N-Aj for discuss@apps.ietf.org; Thu, 03 Jan 2008 19:17:53 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EA43214229C; Thu, 3 Jan 2008 16:17:53 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYv-W0JGtQWw; Thu, 3 Jan 2008 16:17:51 -0800 (PST) Received: from [10.1.1.107] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9B052142207; Thu, 3 Jan 2008 16:17:47 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) To: "Ray S. Atarashi" , Yoshifumi Atarashi , Leslie Daigle , Joe Gregorio , Ted Hardie , Jeff Hodges , Rohan Mahy , Peter Saint-Andre , "Kurt D. Zeilenga" , Russ Housley , "Cullen \"Fluffy\" Jennings" , Larry Masinter , Chris Newman , Mark Nottingham , Jon Peterson , Thomas Roessler , Yves Lafon , James M Snell , Nicolas Williams , Pete Resnick , Tony Hansen , Leif Johansson Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-2--92152296 Subject: Application Area Architecture Workshop ("AAAW") host and attendance From: Lisa Dusseault Date: Thu, 3 Jan 2008 16:17:43 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-Mailman-Approved-At: Thu, 03 Jan 2008 19:19:57 -0500 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-2--92152296 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed We have a host for the workshop: Google will host at some Mountain View location, and include breakfast and lunch. That means that attendance will be free-- just get yourself here, house yourself, pay for your own dinner and you're done. Dates are still Feb 11 and Feb 12, 9am to 6pm. We'll try to all do dinner at a restaurant Feb 11, and possibly again Feb 12 for those who haven't run off already. Attendees and papers: Ray Atarashi: Collaboration between Application and Network Layers Yoshifumi Atarashi: Application Area Advice on use of Web and XML Leslie Daigle: Architecting of Identifier Expansion Lisa Dusseault: The Three Laws of Robotics Using HTTP as a Transport Joe Gregorio: A Theory of Templating Languages Ted Hardie: LoST: Location Routing and Application Architecture Jeff Hodges: Server Identity Check Rohan Mahy: HTTP Change Notification via SIP Peter Saint-Andre: Push and Pull Tradeoffs Kurt Zeilenga: Extending LDAP schemas in support of Applications Other possible attendees, may still be working on papers or claimed exemption from position papers: Tony Hansen Russ Housley Cullen Jennings Leif Johansson Yves Lafon Larry Masinter Chris Newman Mark Nottingham Jon Peterson Pete Resnick Thomas Roessler James Snell Nico Williams I'll be posting position papers myself to this list (discuss@apps.ietf.org) if attendees don't do so themselves. Lisa --Apple-Mail-2--92152296 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

We have a host for the = workshop: Google will host at some Mountain View location, and include = breakfast and lunch.=A0 That means that attendance will be free-- just = get yourself here, house yourself, pay for your own dinner and you're = done.

Dates = are still Feb 11 and Feb 12, 9am to 6pm.=A0 We'll try to all do dinner = at a restaurant Feb 11, and possibly again Feb 12 for those who haven't = run off already.

Attendees and = papers:

Ray = Atarashi: Collaboration between Application and Network = Layers
Yoshifumi Atarashi: Application Area Advice on use of = Web and XML
Leslie Daigle: Architecting of Identifier = Expansion
Lisa Dusseault: The = Three Laws of Robotics=A0Using HTTP as a = Transport
Joe Gregorio: A Theory of Templating = Languages
Ted Hardie: LoST: Location Routing and Application = Architecture
Jeff Hodges: Server Identity = Check
Rohan Mahy: HTTP Change Notification via = SIP
Peter Saint-Andre: Push and Pull Tradeoffs
Kurt = Zeilenga: Extending LDAP schemas in support of = Applications

Other possible attendees, = may still be working on papers or claimed exemption from position = papers:

Tony = Hansen
Russ Housley
Cullen Jennings
Leif = Johansson
Yves Lafon
Larry Masinter
Chris = Newman
Mark Nottingham
Jon Peterson
Pete = Resnick
Thomas Roessler
James Snell
Nico = Williams

I'll = be posting position papers myself to this list (discuss@apps.ietf.org) if = attendees don't do so themselves.=A0

Lisa
= --Apple-Mail-2--92152296-- From discuss-bounces@apps.ietf.org Fri Jan 04 10:23:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAoON-0005iE-KK; Fri, 04 Jan 2008 10:23:27 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAoOM-0005hz-5D for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 10:23:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAoOL-0005hq-RL for discuss@apps.ietf.org; Fri, 04 Jan 2008 10:23:25 -0500 Received: from mk-outboundfilter-2.mail.uk.tiscali.com ([212.74.114.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAoOK-0005xO-D1 for discuss@apps.ietf.org; Fri, 04 Jan 2008 10:23:25 -0500 X-Trace: 6801795/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.162.32 X-SBRS: None X-RemoteIP: 62.241.162.32 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAF/efUc+8aIg/2dsb2JhbACrLQ Received: from ranger.systems.pipex.net ([62.241.162.32]) by smtp.pipex.tiscali.co.uk with ESMTP; 04 Jan 2008 15:23:22 +0000 Received: from pc6 (1Cust30.tnt7.lnd4.gbr.da.uu.net [62.188.136.30]) by ranger.systems.pipex.net (Postfix) with SMTP id F2E66E000095 for ; Fri, 4 Jan 2008 15:23:12 +0000 (GMT) Message-ID: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> From: "tom.petch" To: "Apps Discuss" References: Subject: URI for XML schema and namespace Date: Fri, 4 Jan 2008 14:19:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org What is the currently recommended form for a URI for an XML schema and an XML namespace? The question has come up on ForCES where I, citing RFC3688 say it should be urn: whereas the others cite RFC3470 to say that http: is recommended. Other opinions welcome. Tom Petch From discuss-bounces@apps.ietf.org Fri Jan 04 10:42:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAohF-0004qe-NA; Fri, 04 Jan 2008 10:42:57 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAohF-0004qD-1S for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 10:42:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAohE-0004pT-Nu for discuss@apps.ietf.org; Fri, 04 Jan 2008 10:42:56 -0500 Received: from eastrmmtao105.cox.net ([68.230.240.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAohC-0006Yq-8i for discuss@apps.ietf.org; Fri, 04 Jan 2008 10:42:56 -0500 Received: from eastrmimpo03.cox.net ([68.1.16.126]) by eastrmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080104154253.XQXQ15951.eastrmmtao105.cox.net@eastrmimpo03.cox.net>; Fri, 4 Jan 2008 10:42:53 -0500 Received: from charger ([68.100.33.12]) by eastrmimpo03.cox.net with bizsmtp id Z3Wg1Y00K0FiBvo0000000; Fri, 04 Jan 2008 10:30:40 -0500 From: "Scott Hollenbeck" To: "'tom.petch'" , "'Apps Discuss'" References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> Subject: RE: URI for XML schema and namespace Date: Fri, 4 Jan 2008 10:42:53 -0500 Message-ID: <000001c84ee8$789307a0$0223520a@charger> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchO5c6O2coVpXMzS+et/6CcBePZZgAAi2Yg In-Reply-To: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Friday, January 04, 2008 8:19 AM > To: Apps Discuss > Subject: URI for XML schema and namespace > > What is the currently recommended form for a URI for an XML > schema and an XML namespace? > > The question has come up on ForCES where I, citing RFC3688 > say it should be urn: > whereas the others cite RFC3470 to say that http: is recommended. > > Other opinions welcome. Those folks looking at 3470 might have missed the third paragraph in section 4.9: "In the case of namespaces in IETF standards-track documents, it would be useful if there were some permanent part of the IETF's own web space that could be used for this purpose. In lieu of such, other permanent URIs can be used, e.g., URNs in the IETF URN namespace" URNs in the IETF namespace seems to be the more common practice in the IETF: http://www.iana.org/assignments/xml-registry/ns.html http://www.iana.org/assignments/xml-registry/schema.html -Scott- From discuss-bounces@apps.ietf.org Fri Jan 04 10:53:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAort-0003Gs-Qy; Fri, 04 Jan 2008 10:53:57 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAors-0003Gf-Fg for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 10:53:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAors-0003GV-5h for discuss@apps.ietf.org; Fri, 04 Jan 2008 10:53:56 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JAorq-0006jq-GT for discuss@apps.ietf.org; Fri, 04 Jan 2008 10:53:56 -0500 Received: (qmail invoked by alias); 04 Jan 2008 15:53:53 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.118]) [217.91.35.233] by mail.gmx.net (mp003) with SMTP; 04 Jan 2008 16:53:53 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+2CxJFZNi2v0uM+bC5k4PpRFb9GJqSrVfyf8r9Kx vpIjX3/7epgwk2 Message-ID: <477E568E.8050307@gmx.de> Date: Fri, 04 Jan 2008 16:53:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Scott Hollenbeck Subject: Re: URI for XML schema and namespace References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <000001c84ee8$789307a0$0223520a@charger> In-Reply-To: <000001c84ee8$789307a0$0223520a@charger> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Scott Hollenbeck wrote: >> -----Original Message----- >> From: tom.petch [mailto:cfinss@dial.pipex.com] >> Sent: Friday, January 04, 2008 8:19 AM >> To: Apps Discuss >> Subject: URI for XML schema and namespace >> >> What is the currently recommended form for a URI for an XML >> schema and an XML namespace? >> >> The question has come up on ForCES where I, citing RFC3688 >> say it should be urn: >> whereas the others cite RFC3470 to say that http: is recommended. >> >> Other opinions welcome. > > Those folks looking at 3470 might have missed the third paragraph in section > 4.9: > > "In the case of namespaces in IETF standards-track documents, it would > be useful if there were some permanent part of the IETF's own web > space that could be used for this purpose. In lieu of such, other > permanent URIs can be used, e.g., URNs in the IETF URN namespace" > ... Unfortunately, the IETF so far hasn't followed the BCP's advice to actually make http-based namespace URIs available. Thus, if it's considered A Good Thing to provide a description of the namespace *at* the namespace URI - and when would it not? - I'd suggest to still use an http based namespace URL. There are some IETF specs that for that very reason use URI assigned by the W3C (Atom, Atompub), and lots of other IETF specs use URIs on purl.org. BR, Julian From discuss-bounces@apps.ietf.org Fri Jan 04 10:58:07 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAovv-0004v7-Cl; Fri, 04 Jan 2008 10:58:07 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAovu-0004v2-So for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 10:58:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAovu-0004uu-J2 for discuss@apps.ietf.org; Fri, 04 Jan 2008 10:58:06 -0500 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAovs-0006nv-BE for discuss@apps.ietf.org; Fri, 04 Jan 2008 10:58:06 -0500 Received: by wa-out-1112.google.com with SMTP id m16so9590140waf.20 for ; Fri, 04 Jan 2008 07:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=K3KdeGRxCE3o5sFOp1PSkRAUG2Jhk1JBwq1bWbtuCPw=; b=GbWuvO/lu2wy42yQ/kl1SoeRcxsPAnrYb01TYjBI0m9pAolkHDkREcZLyT3XB26jrOY4LlgEoI/l5erzHqno5FP3q3RF4XYrDbAcnnI/cB5bDikZj4cyfRSROOaHr4mXBS0N0BPyDR4Qrwf4kWdsyhK+RghcFmr3um4Zn2EMSJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=MEdQvHDjGZRGE1TZlWOwrT5Fp2BIniPuok4YtjBUsVtUfb0cpFebmnq4/IpbjboimQiFRgZ/5yCa+Xg8Yp56y6HuAHpzA5zYetNYL/ctRD7HpymI8/QK5FgXPgrkuthojKYrB2DjNsa4C4yd/AJyFsBFynZLY2tTumHiVcFD6yE= Received: by 10.115.88.1 with SMTP id q1mr15364586wal.98.1199462283677; Fri, 04 Jan 2008 07:58:03 -0800 (PST) Received: by 10.114.161.15 with HTTP; Fri, 4 Jan 2008 07:58:03 -0800 (PST) Message-ID: <517bf110801040758l1e304856i8ade84f1c98eefed@mail.gmail.com> Date: Fri, 4 Jan 2008 07:58:03 -0800 From: "Tim Bray" To: tom.petch , "Apps Discuss" Subject: Re: URI for XML schema and namespace In-Reply-To: <000001c84ee8$789307a0$0223520a@charger> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <000001c84ee8$789307a0$0223520a@charger> X-Google-Sender-Auth: dc2ec37e5e71613d X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tbray@textuality.com List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Jan 4, 2008 7:42 AM, Scott Hollenbeck wrote: > > What is the currently recommended form for a URI for an XML > > schema and an XML namespace? > > > > The question has come up on ForCES where I, citing RFC3688 > > say it should be urn: > > whereas the others cite RFC3470 to say that http: is recommended. > > > > Other opinions welcome. Well, the Architecture of the World Wide Web (http://www.w3.org/TR/webarch) argues strongly that http: URIs are generally useful on the grounds that they can in principle (don't have to be, but can) be used to retrieve some human-readable explanatory material about whatever it is the URI names. Also the URI itself tends to be a bit more human-readable, which seems worthwhile to me. The downside, as Scott points out, is that if you want to do that, you have to find a domain to put after the http:// part, and the IETF just doesn't do that. In the case of RFC4287 and 5023, we borrowed one from the W3C. -Tim From discuss-bounces@apps.ietf.org Fri Jan 04 11:04:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAp21-0000ha-3O; Fri, 04 Jan 2008 11:04:25 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAp20-0000XE-0E for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 11:04:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAp1z-0000Ux-Le for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:04:23 -0500 Received: from eastrmmtao104.cox.net ([68.230.240.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAp1x-0006uv-Dd for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:04:23 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080104160421.UEYT23675.eastrmmtao104.cox.net@eastrmimpo02.cox.net>; Fri, 4 Jan 2008 11:04:21 -0500 Received: from charger ([68.100.33.12]) by eastrmimpo02.cox.net with bizsmtp id Z43l1Y00E0FiBvo0000000; Fri, 04 Jan 2008 11:03:46 -0500 From: "Scott Hollenbeck" To: "'Julian Reschke'" References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> Subject: RE: URI for XML schema and namespace Date: Fri, 4 Jan 2008 11:04:21 -0500 Message-ID: <000201c84eeb$77c9e3e0$0223520a@charger> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchO6gmSsf0uLKbvQf+fBRNMbdbakAAAG4Sw In-Reply-To: <477E568E.8050307@gmx.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, January 04, 2008 10:54 AM > To: Scott Hollenbeck > Cc: 'tom.petch'; 'Apps Discuss' > Subject: Re: URI for XML schema and namespace > > Scott Hollenbeck wrote: > >> -----Original Message----- > >> From: tom.petch [mailto:cfinss@dial.pipex.com] > >> Sent: Friday, January 04, 2008 8:19 AM > >> To: Apps Discuss > >> Subject: URI for XML schema and namespace > >> > >> What is the currently recommended form for a URI for an XML schema > >> and an XML namespace? > >> > >> The question has come up on ForCES where I, citing RFC3688 say it > >> should be urn: > >> whereas the others cite RFC3470 to say that http: is recommended. > >> > >> Other opinions welcome. > > > > Those folks looking at 3470 might have missed the third > paragraph in > > section > > 4.9: > > > > "In the case of namespaces in IETF standards-track > documents, it would > > be useful if there were some permanent part of the IETF's own web > > space that could be used for this purpose. In lieu of such, other > > permanent URIs can be used, e.g., URNs in the IETF URN namespace" > > ... > > Unfortunately, the IETF so far hasn't followed the BCP's > advice to actually make http-based namespace URIs available. As one of the authors of 3470 I can say very clearly that 3470 doesn't provide advice on this point. It states fact: "Typically (and recommended practice in W3C) is to assign namespace names using persistent http URIs." Notice that there's no "may", "should", "must", etc. > Thus, if it's considered A Good Thing to provide a > description of the namespace *at* the namespace URI - and > when would it not? - I'd suggest to still use an http based > namespace URL. > > There are some IETF specs that for that very reason use URI > assigned by the W3C (Atom, Atompub), and lots of other IETF > specs use URIs on purl.org. That's certainly a valid option. I'm not saying that one is better than the other. What I am saying is that people shouldn't think that 3470 recommends one over the other. -Scott- From discuss-bounces@apps.ietf.org Fri Jan 04 11:15:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApCy-0008EE-Nl; Fri, 04 Jan 2008 11:15:44 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JApCx-0008E7-3g for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 11:15:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApCw-0008Dz-QI for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:15:42 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JApCw-00075q-Cz for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:15:42 -0500 Received: (qmail invoked by alias); 04 Jan 2008 16:15:41 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.118]) [217.91.35.233] by mail.gmx.net (mp046) with SMTP; 04 Jan 2008 17:15:41 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18nPp1YMAUnQiLzs3mayfjz/VPDwM/JyD5U8RiOp3 1lNbkQCaqwHhGU Message-ID: <477E5BAB.1050000@gmx.de> Date: Fri, 04 Jan 2008 17:15:39 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Scott Hollenbeck Subject: Re: URI for XML schema and namespace References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> In-Reply-To: <000201c84eeb$77c9e3e0$0223520a@charger> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Scott Hollenbeck wrote: >> Unfortunately, the IETF so far hasn't followed the BCP's >> advice to actually make http-based namespace URIs available. > > As one of the authors of 3470 I can say very clearly that 3470 doesn't > provide advice on this point. It states fact: > > "Typically (and recommended practice in W3C) is to assign namespace names > using persistent http URIs." > > Notice that there's no "may", "should", "must", etc. It also says: In the case of namespaces in IETF standards-track documents, it would be useful if there were some permanent part of the IETF's own web space that could be used for this purpose. (...) Isn't that advice? > ... BR, Julian From discuss-bounces@apps.ietf.org Fri Jan 04 11:16:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApDy-0008Tp-4j; Fri, 04 Jan 2008 11:16:46 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JApDw-0008Tk-On for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 11:16:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApDw-0008Tc-En for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:16:44 -0500 Received: from qmta01.westchester.pa.mail.comcast.net ([76.96.62.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JApDw-00077G-1y for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:16:44 -0500 Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA01.westchester.pa.mail.comcast.net with comcast id Z1E51Y00H16LCl0050E800; Fri, 04 Jan 2008 16:16:43 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.westchester.pa.mail.comcast.net with comcast id Z4GY1Y00A4HwxpC3S00000; Fri, 04 Jan 2008 16:16:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=nm2f_ct9wm0Dz89CVJcA:9 a=c7tlGeTfE12_kD1q38cA:7 a=7r2wZTz6hmKobGeuIqWDsC3UzbsA:4 a=nPLcb18tl68A:10 a=BntDIBrHCV4A:10 a=2uiCRmbCp6AA:10 From: "David Harrington" To: "'Scott Hollenbeck'" , "'Julian Reschke'" References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6><000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> Subject: RE: URI for XML schema and namespace Date: Fri, 4 Jan 2008 11:16:05 -0500 Message-ID: <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000201c84eeb$77c9e3e0$0223520a@charger> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AchO6gmSsf0uLKbvQf+fBRNMbdbakAAAG4SwAACQnZA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Has anybody actually asked Ray to get such a permanent part of IETF's own web space allocated and setup? Would entries on the web site require IANA assignment, e.g. as a registry? I'm asking because I am new to the discussion, and simply don't know the answer. dbh > -----Original Message----- > From: Scott Hollenbeck [mailto:sah-ietf@tengwar.com] > Sent: Friday, January 04, 2008 11:04 AM > To: 'Julian Reschke' > Cc: 'Apps Discuss' > Subject: RE: URI for XML schema and namespace > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Friday, January 04, 2008 10:54 AM > > To: Scott Hollenbeck > > Cc: 'tom.petch'; 'Apps Discuss' > > Subject: Re: URI for XML schema and namespace > > > > Scott Hollenbeck wrote: > > >> -----Original Message----- > > >> From: tom.petch [mailto:cfinss@dial.pipex.com] > > >> Sent: Friday, January 04, 2008 8:19 AM > > >> To: Apps Discuss > > >> Subject: URI for XML schema and namespace > > >> > > >> What is the currently recommended form for a URI for an > XML schema > > >> and an XML namespace? > > >> > > >> The question has come up on ForCES where I, citing > RFC3688 say it > > >> should be urn: > > >> whereas the others cite RFC3470 to say that http: is recommended. > > >> > > >> Other opinions welcome. > > > > > > Those folks looking at 3470 might have missed the third > > paragraph in > > > section > > > 4.9: > > > > > > "In the case of namespaces in IETF standards-track > > documents, it would > > > be useful if there were some permanent part of the IETF's own web > > > space that could be used for this purpose. In lieu of > such, other > > > permanent URIs can be used, e.g., URNs in the IETF URN namespace" > > > ... > > > > Unfortunately, the IETF so far hasn't followed the BCP's > > advice to actually make http-based namespace URIs available. > > As one of the authors of 3470 I can say very clearly that 3470 doesn't > provide advice on this point. It states fact: > > "Typically (and recommended practice in W3C) is to assign > namespace names > using persistent http URIs." > > Notice that there's no "may", "should", "must", etc. > > > Thus, if it's considered A Good Thing to provide a > > description of the namespace *at* the namespace URI - and > > when would it not? - I'd suggest to still use an http based > > namespace URL. > > > > There are some IETF specs that for that very reason use URI > > assigned by the W3C (Atom, Atompub), and lots of other IETF > > specs use URIs on purl.org. > > That's certainly a valid option. I'm not saying that one is > better than the > other. What I am saying is that people shouldn't think that > 3470 recommends > one over the other. > > -Scott- > > > > From discuss-bounces@apps.ietf.org Fri Jan 04 11:20:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApHO-000346-0I; Fri, 04 Jan 2008 11:20:18 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JApHM-00033x-5q for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 11:20:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApHL-00033p-SB for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:20:15 -0500 Received: from dizzyd.com ([207.210.219.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JApHL-0007B0-6Z for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:20:15 -0500 Received: from wrk225.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTP id A19C3404A1; Fri, 4 Jan 2008 09:20:08 -0700 (MST) Message-ID: <477E5CB6.3040705@stpeter.im> Date: Fri, 04 Jan 2008 09:20:06 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: tbray@textuality.com Subject: Re: URI for XML schema and namespace References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <000001c84ee8$789307a0$0223520a@charger> <517bf110801040758l1e304856i8ade84f1c98eefed@mail.gmail.com> In-Reply-To: <517bf110801040758l1e304856i8ade84f1c98eefed@mail.gmail.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080309090907070208060707" X-Spam-Score: -0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is a cryptographically signed message in MIME format. --------------ms080309090907070208060707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tim Bray wrote: > On Jan 4, 2008 7:42 AM, Scott Hollenbeck wrote: > >>> What is the currently recommended form for a URI for an XML >>> schema and an XML namespace? >>> >>> The question has come up on ForCES where I, citing RFC3688 >>> say it should be urn: >>> whereas the others cite RFC3470 to say that http: is recommended. >>> >>> Other opinions welcome. > > Well, the Architecture of the World Wide Web > (http://www.w3.org/TR/webarch) argues strongly that http: URIs are > generally useful on the grounds that they can in principle (don't have > to be, but can) be used to retrieve some human-readable explanatory > material about whatever it is the URI names. Also the URI itself > tends to be a bit more human-readable, which seems worthwhile to me. If http URI, type into browser location bar. If URN, type into browser search bar. I don't see a great deal of difference. :) > The downside, as Scott points out, is that if you want to do that, you > have to find a domain to put after the http:// part, ... and ensure that the domain is stable, and that the people running the domain will reliably host your namespace, and ... > and the IETF just > doesn't do that. In the case of RFC4287 and 5023, we borrowed one > from the W3C. FWIW, we Jabberites used https URIs like http://jabber.org/protocol/* for a long time but recently switched to URNs like urn:xmpp:* because they're more stable (what happens if the person registering jabber.org loses control over the domain?) and will last forever. The choice of http URI vs. URN seems like a toss-up to me. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms080309090907070208060707 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+ JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE 9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0 ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/ yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA 75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna 1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf 5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0 dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1 My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODAxMDQxNjIwMDZaMCMGCSqG SIb3DQEJBDEWBBSF60OZBwConjcs4a7y5rPW/Y8tijBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC AQBQMlIUSbaZiqLA/YlTSeWglFZsbf4W0MCnLBGBAj2+let/h2xcqN7SN2fiDEb2RcqALDoc XGXw7Yf3XPRK7hDxqz79KA0/rpxtNyRiEwdRGzvXZkiIRVO7cyigitHihhFGzeCcr+/tDUDL Hh3DSKIFwEU/hptcL0A1WTuVJ7sOk5fIo1ZPSR8lqny0/4SQde44xuoS185/K3PxMQHto9Bb dR8JzMIyhn5/XQojL9GDR7xnThGSnTOFO2traIxCPp408AaVqoCjFuEUOaAIBE3n1VOYDyQU cxM9vaWPilmEeYsgvSJb3btACUvmmrWCrazCHRpClowPVrRZrpRr/Jo8AAAAAAAA --------------ms080309090907070208060707-- From discuss-bounces@apps.ietf.org Fri Jan 04 11:24:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApL6-0000b5-Ht; Fri, 04 Jan 2008 11:24:08 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JApL5-0000az-GL for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 11:24:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApL5-0000ar-6e for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:24:07 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JApL4-0007Dz-PC for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:24:07 -0500 Received: (qmail invoked by alias); 04 Jan 2008 16:24:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.118]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 04 Jan 2008 17:24:05 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+yvU0/iImyOfHin58jIvaxFgCnrSrqfBuZvREfh0 lxe5luzA9GAZ8t Message-ID: <477E5DA1.9040504@gmx.de> Date: Fri, 04 Jan 2008 17:24:01 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: David Harrington Subject: Re: URI for XML schema and namespace References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6><000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> In-Reply-To: <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org David Harrington wrote: > Has anybody actually asked Ray to get such a permanent part of IETF's > own web space allocated and setup? Would entries on the web site > require IANA assignment, e.g. as a registry? > > I'm asking because I am new to the discussion, and simply don't know > the answer. > > dbh I think historically there's a lot of reluctance inside IANA (or the whole IESG) to consider any URI starting with "http" as permanent. BR, Julian From discuss-bounces@apps.ietf.org Fri Jan 04 11:25:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApMY-0001Ci-9J; Fri, 04 Jan 2008 11:25:38 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JApMX-0001Cb-85 for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 11:25:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApMW-0001CT-Ub for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:25:36 -0500 Received: from dizzyd.com ([207.210.219.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JApMV-0007FZ-Ii for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:25:36 -0500 Received: from wrk225.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTP id B16AC404A1; Fri, 4 Jan 2008 09:25:34 -0700 (MST) Message-ID: <477E5DFD.10302@stpeter.im> Date: Fri, 04 Jan 2008 09:25:33 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Julian Reschke Subject: Re: URI for XML schema and namespace References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6><000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> <477E5DA1.9040504@gmx.de> In-Reply-To: <477E5DA1.9040504@gmx.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000905080809020102020408" X-Spam-Score: -0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is a cryptographically signed message in MIME format. --------------ms000905080809020102020408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Julian Reschke wrote: > David Harrington wrote: >> Has anybody actually asked Ray to get such a permanent part of IETF's >> own web space allocated and setup? Would entries on the web site >> require IANA assignment, e.g. as a registry? >> >> I'm asking because I am new to the discussion, and simply don't know >> the answer. >> >> dbh > > I think historically there's a lot of reluctance inside IANA (or the > whole IESG) to consider any URI starting with "http" as permanent. Besides, URNs are relatively easy to obtain, so why not use them? Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms000905080809020102020408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+ JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE 9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0 ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/ yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA 75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna 1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf 5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0 dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1 My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODAxMDQxNjI1MzNaMCMGCSqG SIb3DQEJBDEWBBQ913bDKAMnA+nNfn0NF5AH6CrqsDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC AQCAM097iML/ams4+AZYAfb+FqO2dQn4sRfEuGewSIoct6s2I7D6dNufqi06ENSt6PImCUBG +q74LhI4oUDNV26YxC6H72lQ1f8cUJyxXKKAmo1VFVidcWh/c0/98zkaIq3BP+4FqOtwhnMb t33wwpmHNstS0t8nV5RQQKzGimIUkC3WDbWkoauserqjM5a8rM4EoZyLYagMjDnbvOO0pPB1 xYmWllrdMoicablmlBg4Tw0HVHYqrKig9u48s597/yERNPISCy/jnjC5eK9OUczPnzAvMFkl gfSF4b7vbRmeBzqB3AdPCpEAf1bZJi5ZJLOlEM5X8dXuyqoxm/DfUt99AAAAAAAA --------------ms000905080809020102020408-- From discuss-bounces@apps.ietf.org Fri Jan 04 11:36:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApXP-0005vG-PY; Fri, 04 Jan 2008 11:36:51 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JApXO-0005v3-Im for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 11:36:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApXN-0005us-S8 for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:36:50 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JApXM-0007Rb-T6 for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:36:49 -0500 Received: (qmail invoked by alias); 04 Jan 2008 16:36:47 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.118]) [217.91.35.233] by mail.gmx.net (mp055) with SMTP; 04 Jan 2008 17:36:47 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/2v51DSjz2r2CYij61/Kb2R2GWL7j5FilhXpNi2c JTIUEQTDAWvrhK Message-ID: <477E609E.6010402@gmx.de> Date: Fri, 04 Jan 2008 17:36:46 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: URI for XML schema and namespace References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6><000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> <477E5DA1.9040504@gmx.de> <477E5DFD.10302@stpeter.im> In-Reply-To: <477E5DFD.10302@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Peter Saint-Andre wrote: > Besides, URNs are relatively easy to obtain, so why not use them? Because you can't resolve them, unless you have out-of-band information about how to do that. If you encounter a namespace URI such as "urn:ietf:params:xml:ns:contact-1.0", you'll have to google for it to obtain information about what it is. In this case, you'll find the right thing, but it would be much easier if the IANA just assigned namespace URIs such as in the first place. The fact that it does not has caused many specs to get their namespace URIs from other places, such as the W3C and purl.org. BR, Julian From discuss-bounces@apps.ietf.org Fri Jan 04 11:48:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApit-0005yQ-BU; Fri, 04 Jan 2008 11:48:43 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JApir-0005ub-Vf for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 11:48:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApir-0005uT-M1 for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:48:41 -0500 Received: from qmta06.westchester.pa.mail.comcast.net ([76.96.62.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JApip-0007dU-HY for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:48:41 -0500 Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA06.westchester.pa.mail.comcast.net with comcast id Z2Hv1Y00517dt5G050Jr00; Fri, 04 Jan 2008 16:48:38 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA13.westchester.pa.mail.comcast.net with comcast id Z4oU1Y0094HwxpC3Z00000; Fri, 04 Jan 2008 16:48:32 +0000 X-Authority-Analysis: v=1.0 c=1 a=fknL6YPdPNYhVTTA9QkA:9 a=vInoGFtGHQDX6hR1G3AA:7 a=J75xMBGrYdrGl7IJfgD5B0ycACIA:4 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Julian Reschke'" References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6><000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> <477E5DA1.9040504@gmx.de> Subject: RE: URI for XML schema and namespace Date: Fri, 4 Jan 2008 11:47:59 -0500 Message-ID: <105601c84ef1$90d0d870$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <477E5DA1.9040504@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AchO7kI0OJfitIttRLG4hU9THeBaPwAAOzBw X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi Julian, That's an interesting observation, but it didn't answer my question. Has anybody explicitly asked the people who can create such a permanent web site to do so? Has anybody fashioned an explicit proposal for the establishment of permanent IETF URIs? Am I off-target with my question? Would this simply be a bad idea? If it is a good idea, who wants it badly enough to write such a proposal? David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, January 04, 2008 11:24 AM > To: David Harrington > Cc: 'Scott Hollenbeck'; 'Apps Discuss' > Subject: Re: URI for XML schema and namespace > > David Harrington wrote: > > Has anybody actually asked Ray to get such a permanent > part of IETF's > > own web space allocated and setup? Would entries on the web site > > require IANA assignment, e.g. as a registry? > > > > I'm asking because I am new to the discussion, and simply don't know > > the answer. > > > > dbh > > I think historically there's a lot of reluctance inside IANA (or the > whole IESG) to consider any URI starting with "http" as permanent. > > BR, Julian > From discuss-bounces@apps.ietf.org Fri Jan 04 11:56:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAppw-0006rV-8j; Fri, 04 Jan 2008 11:56:00 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAppu-0006cJ-9U for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 11:55:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAppt-0006Wd-R5 for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:55:57 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JApps-0007lw-9o for discuss@apps.ietf.org; Fri, 04 Jan 2008 11:55:57 -0500 Received: (qmail invoked by alias); 04 Jan 2008 16:55:54 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.118]) [217.91.35.233] by mail.gmx.net (mp036) with SMTP; 04 Jan 2008 17:55:54 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19S57d7QbtSYxeCEzdBvME1N7lIFBHGm93lbtoWld xJH8Jt/szONKPX Message-ID: <477E6519.7080305@gmx.de> Date: Fri, 04 Jan 2008 17:55:53 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: David Harrington Subject: Re: URI for XML schema and namespace References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6><000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> <477E5DA1.9040504@gmx.de> <105601c84ef1$90d0d870$6502a8c0@china.huawei.com> In-Reply-To: <105601c84ef1$90d0d870$6502a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org David Harrington wrote: > Hi Julian, > > That's an interesting observation, but it didn't answer my question. > Has anybody explicitly asked the people who can create such a > permanent web site to do so? > Has anybody fashioned an explicit proposal for the establishment of > permanent IETF URIs? Hi David, I actually don't know. > Am I off-target with my question? Nope. > Would this simply be a bad idea? I think it would be a very good idea (same as making IANA registries more extensible by using URIs as identifier, and let IANA only maintain "shorthand" identifiers). > If it is a good idea, who wants it badly enough to write such a > proposal? Good question. So far, the workaround (getting the namespace name from somebody else) has worked well enough, so maybe the problem just isn't big enough. BR, Julian From discuss-bounces@apps.ietf.org Fri Jan 04 12:35:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqRv-0006Ef-4n; Fri, 04 Jan 2008 12:35:15 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAqRt-0006EY-Ou for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 12:35:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqRt-0006EQ-FJ for discuss@apps.ietf.org; Fri, 04 Jan 2008 12:35:13 -0500 Received: from eastrmmtao103.cox.net ([68.230.240.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAqRt-0008Uz-5q for discuss@apps.ietf.org; Fri, 04 Jan 2008 12:35:13 -0500 Received: from eastrmimpo03.cox.net ([68.1.16.126]) by eastrmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080104173512.VXAT24467.eastrmmtao103.cox.net@eastrmimpo03.cox.net>; Fri, 4 Jan 2008 12:35:12 -0500 Received: from charger ([68.100.33.12]) by eastrmimpo03.cox.net with bizsmtp id Z5Ny1Y00F0FiBvo0000000; Fri, 04 Jan 2008 12:22:58 -0500 From: "Scott Hollenbeck" To: "'David Harrington'" , "'Julian Reschke'" References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6><000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> Subject: RE: URI for XML schema and namespace Date: Fri, 4 Jan 2008 12:35:12 -0500 Message-ID: <001d01c84ef8$2941c050$0223520a@charger> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchO6gmSsf0uLKbvQf+fBRNMbdbakAAAG4SwAACQnZAAAtNLIA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Friday, January 04, 2008 11:16 AM > To: 'Scott Hollenbeck'; 'Julian Reschke' > Cc: 'Apps Discuss' > Subject: RE: URI for XML schema and namespace > > Has anybody actually asked Ray to get such a permanent part > of IETF's own web space allocated and setup? Would entries on > the web site require IANA assignment, e.g. as a registry? > > I'm asking because I am new to the discussion, and simply > don't know the answer. No one has as far as I know, either. -Scott- From discuss-bounces@apps.ietf.org Fri Jan 04 12:36:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqTK-000705-O9; Fri, 04 Jan 2008 12:36:42 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAqTK-0006zv-0e for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 12:36:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqTJ-0006zn-NK for discuss@apps.ietf.org; Fri, 04 Jan 2008 12:36:41 -0500 Received: from eastrmmtao101.cox.net ([68.230.240.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAqTJ-00004q-CF for discuss@apps.ietf.org; Fri, 04 Jan 2008 12:36:41 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao101.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080104173641.KTUJ129.eastrmmtao101.cox.net@eastrmimpo02.cox.net>; Fri, 4 Jan 2008 12:36:41 -0500 Received: from charger ([68.100.33.12]) by eastrmimpo02.cox.net with bizsmtp id Z5c61Y00D0FiBvo0000000; Fri, 04 Jan 2008 12:36:06 -0500 From: "Scott Hollenbeck" To: "'Julian Reschke'" References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <477E5BAB.1050000@gmx.de> Subject: RE: URI for XML schema and namespace Date: Fri, 4 Jan 2008 12:36:41 -0500 Message-ID: <001e01c84ef8$5e233240$0223520a@charger> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <477E5BAB.1050000@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchO7RXML0lB6qyJTnStg2ry2T4HQgACyRGw X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, January 04, 2008 11:16 AM > To: Scott Hollenbeck > Cc: 'tom.petch'; 'Apps Discuss' > Subject: Re: URI for XML schema and namespace > > Scott Hollenbeck wrote: > >> Unfortunately, the IETF so far hasn't followed the BCP's advice to > >> actually make http-based namespace URIs available. > > > > As one of the authors of 3470 I can say very clearly that > 3470 doesn't > > provide advice on this point. It states fact: > > > > "Typically (and recommended practice in W3C) is to assign namespace > > names using persistent http URIs." > > > > Notice that there's no "may", "should", "must", etc. > > It also says: > > In the case of namespaces in IETF standards-track > documents, it would > be useful if there were some permanent part of the IETF's own web > space that could be used for this purpose. (...) > > Isn't that advice? No, it isn't. It's an observation and was intended to be an observation. -Scott- From discuss-bounces@apps.ietf.org Fri Jan 04 12:41:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqXT-0005oL-Lq; Fri, 04 Jan 2008 12:40:59 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAqXS-0005oC-GS for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 12:40:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqXS-0005n3-6F for discuss@apps.ietf.org; Fri, 04 Jan 2008 12:40:58 -0500 Received: from eastrmmtao103.cox.net ([68.230.240.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAqXR-00008s-Tj for discuss@apps.ietf.org; Fri, 04 Jan 2008 12:40:58 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080104174058.VZKK24467.eastrmmtao103.cox.net@eastrmimpo02.cox.net>; Fri, 4 Jan 2008 12:40:58 -0500 Received: from charger ([68.100.33.12]) by eastrmimpo02.cox.net with bizsmtp id Z5gN1Y00E0FiBvo0000000; Fri, 04 Jan 2008 12:40:23 -0500 From: "Scott Hollenbeck" To: "'Julian Reschke'" , "'Peter Saint-Andre'" References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6><000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de><000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com><477E5DA1.9040504@gmx.de> <477E5DFD.10302@stpeter.im> <477E609E.6010402@gmx.de> Subject: RE: URI for XML schema and namespace Date: Fri, 4 Jan 2008 12:40:58 -0500 Message-ID: <001f01c84ef8$f7142e50$0223520a@charger> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <477E609E.6010402@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchO8AmVh67TW/dCSf+/wnZd1F/SfAACFhWA X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, January 04, 2008 11:37 AM > To: Peter Saint-Andre > Cc: 'Apps Discuss' > Subject: Re: URI for XML schema and namespace > > Peter Saint-Andre wrote: > > Besides, URNs are relatively easy to obtain, so why not use them? > > Because you can't resolve them, unless you have out-of-band > information about how to do that. That assumes that they need to be resolved. When they're used to uniquely identify an XML namespace they don't *need* to be, though I agree that it might be nice if they *could* be. -Scott- From discuss-bounces@apps.ietf.org Fri Jan 04 13:45:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JArY1-0005e9-Ra; Fri, 04 Jan 2008 13:45:37 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JArY0-0005Sn-62 for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 13:45:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JArXz-0005Se-SM for discuss@apps.ietf.org; Fri, 04 Jan 2008 13:45:35 -0500 Received: from dizzyd.com ([207.210.219.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JArXy-0001Gn-CA for discuss@apps.ietf.org; Fri, 04 Jan 2008 13:45:35 -0500 Received: from wrk225.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTP id 1CA644049C; Fri, 4 Jan 2008 11:45:25 -0700 (MST) Message-ID: <477E7EC3.4090408@stpeter.im> Date: Fri, 04 Jan 2008 11:45:23 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Scott Hollenbeck Subject: Re: URI for XML schema and namespace References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6><000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de><000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com><477E5DA1.9040504@gmx.de> <477E5DFD.10302@stpeter.im> <477E609E.6010402@gmx.de> <001f01c84ef8$f7142e50$0223520a@charger> In-Reply-To: <001f01c84ef8$f7142e50$0223520a@charger> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020902050408020001050702" X-Spam-Score: -0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is a cryptographically signed message in MIME format. --------------ms020902050408020001050702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Scott Hollenbeck wrote: >> -----Original Message----- >> From: Julian Reschke [mailto:julian.reschke@gmx.de] >> Sent: Friday, January 04, 2008 11:37 AM >> To: Peter Saint-Andre >> Cc: 'Apps Discuss' >> Subject: Re: URI for XML schema and namespace >> >> Peter Saint-Andre wrote: >>> Besides, URNs are relatively easy to obtain, so why not use them? >> Because you can't resolve them, unless you have out-of-band >> information about how to do that. > > That assumes that they need to be resolved. When they're used to uniquely > identify an XML namespace they don't *need* to be, though I agree that it > might be nice if they *could* be. Right. In my experience, developers want to resolve namespaces when they're trying to figure out what the namespace means, what the schema is, etc. But applications don't need to resolve namespaces, nor do end users. At least as a general rule... Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms020902050408020001050702 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+ JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE 9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0 ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/ yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA 75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna 1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf 5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0 dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1 My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODAxMDQxODQ1MjNaMCMGCSqG SIb3DQEJBDEWBBSTXRlPgZ/Y+QvZFyNMva8/qMksHDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC AQBKqr3K9ENTtwjTVLmxthGkdCSucaOBcFTpigIhGUV54KdZkldnQxQJwscOh300k0orEa82 rZ35fzUrpFSFXnbMDSC1hXrCtTOisV9wDJtgApRWifxI6zHsTH3aJcK55EV2HxyTMcbFK9FP Id60woGX3moOrRYfLnT5EYiNs87cBuAtV2Tk4mSWF7FpfI3/tYhRGEhEKj7pvRl1omYI2Vjf Z2SmXz5MJjFBbucSB2evupBlXJiQPA/9kAPoYviw9AyTVdvMNMKpFLWUdUSo3V8xcAO5JeAJ L9iP+/uTDsx8pA4UQQLtNBbo8u66hT9dnKXbDInNVuMAXvwdD3HB6djEAAAAAAAA --------------ms020902050408020001050702-- From discuss-bounces@apps.ietf.org Fri Jan 04 14:07:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JArsi-0002dc-5T; Fri, 04 Jan 2008 14:07:00 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JArsg-0002dX-SV for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 14:06:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JArsg-0002dP-IT for discuss@apps.ietf.org; Fri, 04 Jan 2008 14:06:58 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JArse-0001hf-Qr for discuss@apps.ietf.org; Fri, 04 Jan 2008 14:06:58 -0500 Received: (qmail invoked by alias); 04 Jan 2008 19:06:55 -0000 Received: from p508FA0A9.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.160.169] by mail.gmx.net (mp010) with SMTP; 04 Jan 2008 20:06:55 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19WIBRiOl1W+FrfaMv6MFHkzxfqMnhsVajJ/NxORa trxEETrn2EdDEA Message-ID: <477E83CD.8040400@gmx.de> Date: Fri, 04 Jan 2008 20:06:53 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: URI for XML schema and namespace References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6><000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de><000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com><477E5DA1.9040504@gmx.de> <477E5DFD.10302@stpeter.im> <477E609E.6010402@gmx.de> <001f01c84ef8$f7142e50$0223520a@charger> <477E7EC3.4090408@stpeter.im> In-Reply-To: <477E7EC3.4090408@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Peter Saint-Andre wrote: > Right. > > In my experience, developers want to resolve namespaces when they're > trying to figure out what the namespace means, what the schema is, etc. > But applications don't need to resolve namespaces, nor do end users. At > least as a general rule... > > Peter Of course. It's sad that this need to be pointed out from time to time :-) BR, Julian From discuss-bounces@apps.ietf.org Fri Jan 04 14:17:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAs38-0008V0-NB; Fri, 04 Jan 2008 14:17:46 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAs37-0008G9-44 for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 14:17:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAs36-0008E4-NG for discuss@apps.ietf.org; Fri, 04 Jan 2008 14:17:44 -0500 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAs34-00020V-Fc for discuss@apps.ietf.org; Fri, 04 Jan 2008 14:17:44 -0500 Received: by wa-out-1112.google.com with SMTP id m16so9679266waf.20 for ; Fri, 04 Jan 2008 11:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=Qi/Wnf1US95S/6cxHnPh8mEX0w14UhTI5SY2DJyxv/o=; b=N37fcRoiTgQQchyaYcBX7slQKbjafAm3UylXLuryn0T8hRJzRpHXIa2Hnuugknd3tu2FXXfkjEoqJz1dMD14WpHgkfLXs368UX04l11HSaKjDnhsF93EMVBDUVc10ObA/6SUqd5PCzeJQIXxYMPrGAIPVSEPkl4BfSIrgx4hjEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=uqPnSkJhdcAPtYdEOuS8IqvJcvkth1XW6qxjvWlB2qG9cmiAKnCq/dBB13S5LG49hQ9o4y+gQi/J1HqXDdRWfCxSW4avGXl4XxmkQh6lNwy9D/IkK3aZ3tooXd1155QkRmAFjEWZ/Oe6rjq/u/caCX+EBIj7u/PAU1DUkuVRtGs= Received: by 10.114.53.1 with SMTP id b1mr2197161waa.134.1199474261256; Fri, 04 Jan 2008 11:17:41 -0800 (PST) Received: by 10.114.161.15 with HTTP; Fri, 4 Jan 2008 11:17:41 -0800 (PST) Message-ID: <517bf110801041117sefe07c6i934517934cad368@mail.gmail.com> Date: Fri, 4 Jan 2008 11:17:41 -0800 From: "Tim Bray" To: "Peter Saint-Andre" Subject: Re: URI for XML schema and namespace In-Reply-To: <477E7EC3.4090408@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> <477E5DA1.9040504@gmx.de> <477E5DFD.10302@stpeter.im> <477E609E.6010402@gmx.de> <001f01c84ef8$f7142e50$0223520a@charger> <477E7EC3.4090408@stpeter.im> X-Google-Sender-Auth: 9fc7fe6ef7168291 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tbray@textuality.com List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Jan 4, 2008 10:45 AM, Peter Saint-Andre wrote: > > In my experience, developers want to resolve namespaces when they're > trying to figure out what the namespace means, what the schema is, etc. > But applications don't need to resolve namespaces, nor do end users. At > least as a general rule... Exactly. I have been told (I forget by whom) that there is some doubt as to who actually controls ietf.org. Sigh. -Tim From discuss-bounces@apps.ietf.org Fri Jan 04 16:18:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAtwF-0001Lq-AP; Fri, 04 Jan 2008 16:18:47 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAtwD-00019o-Qo for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 16:18:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAtwD-000187-GJ for discuss@apps.ietf.org; Fri, 04 Jan 2008 16:18:45 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAtwB-000528-Gk for discuss@apps.ietf.org; Fri, 04 Jan 2008 16:18:45 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1JAtw9-0008ip-Md; Fri, 04 Jan 2008 16:18:42 -0500 Date: Fri, 04 Jan 2008 16:18:40 -0500 From: John C Klensin To: Frank Ellermann Subject: Re: Comments on draft-klensin-net-utf8-06 Message-ID: <00C50AA9B75A816BAB602CBD@p3.JCK.COM> In-Reply-To: References: <1CEEB76FCFC0070A7B2BDEAE@[10.1.0.164]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Wednesday, 17 October, 2007 08:21 +0200 Frank Ellermann wrote: > John C Klensin wrote: > >>> * Section 4: "the string order of RFC 3629". It's not very >>> clear to me what is meant with this. Byte order? Sorting >>> order? > >> 3629 specifies a byte order (in section 4). It does not >> address or mention sort order except to note (in the >> introduction) that UTF-8 preserves it and that sort order >> based on code point sequence is likely to be fairly useless. > >> I _think_ I would welcome text to clarify this > > Please simplify the remark and remove one "that": > > -| Were Unicode to be changed in a way that violated these > -| assumptions, i.e., that either invalidated the string order > -| of RFC 3629 or that that changed the stability of NFC as > -| stated above, this specification would not apply. > > +| Were Unicode to be changed in a way that violated these > +| assumptions, i.e., that changed the stability of NFC as > +| stated above, this specification would not apply. > > UTF-8 as specified in STD 63 is stable. Sure it is. But, were the definition of normal UTF-8 string order _in the Unicode spec_ to change (however unlikely that might be) we would be in deep trouble since many (most?) implementers depend on UTF-8 libraries not RFC 3629-specific ones. Those added words have no effect as long as these basic definitions (NFC or byte order) don't change, but they do help to explain where the dependencies lie. >> So I am loathe to cover things that are well-covered in >> 3629 lest more confusion be created. > > Yes, just don't mention the "byte-value lexicographic sorting > order of UTF-8 strings", it's covered in STD 63, and besides > not very interesting. That is one of several reasons I left it out. >>> * Section 4: I would drop the last paragraph, since it is a >>> repetition of what is exhaustively explained in section 5.2. >>> I got a parsing error at the last sentence of that paragraph >>> anyway. > > Indeed, that paragraph is unnecessary. I also can't parse its > first sentence. > >> That last sentence could be restated, less formally, as: > >> If one encounters a UTF-8 string in a protocol, and its >> syntax and properties are not specifically defined, then >> it is reasonable to assume that it conforms to this >> specification. > > I still don't understand this. What is an UTF-8 string with > "unspecified syntax" ? STD 63 specifies the syntax of UTF-8, > anything not following this syntax is invalid. I've rewritten that paragraph a bit, but unless (contrary to the letter and spirit of RFC 3629) we require BOM indications in every UTF-8 string, there will be strings floating around that look like UTF-8 but that may or may not follow the rules of 3629 (e.g., minimal forms) or this spec (e.g., 3629 plus NFC). In that regard, protocols that don't reference this spec for a definition/ set of requirements are out of luck -- this spec can't say anything about them (that is an advantage for some purposes). If the relevant protocol _does_ reference this spec, then we have a robustness principle issue, specifically whether the receiving system can assume that an incoming string conforms (and generate an error message or behave in unexpected ways if it does not) or if it required to somehow make it conform, regardless of what nonsense (even nonsense that doesn't conform to 3629) it might be sent. This sentence is intended to point in the former direction. I don't think spelling it out much more explicitly in the spec is desirable, although I could be talked into that if someone supplied text. > The net-utf8 I-D doesn't specify any default properties, what > is an assumption that "unspecified properties" conform to > net-utf8 supposed to do ? > > If you're talking about unassigned code points please say so. > In that case it's covered in 5.2, and you can simply delete > the last paragraph of section 4. I hope the above more or less answers your question. Yes, unassigned code points are on that list, but they aren't the only thing. >> I'm going to hold the document for a few days before >> re-posting in the hope of getting comments from others. > > Please update the [NFC] reference, s/March 2005/2006-10-12/ > for the version belonging to TUS 5.0. Done thanks, john From discuss-bounces@apps.ietf.org Fri Jan 04 16:34:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAuBL-0005aL-Pw; Fri, 04 Jan 2008 16:34:23 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAuBK-0005Zc-Tf for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 16:34:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAuBK-0005ZR-JN for discuss@apps.ietf.org; Fri, 04 Jan 2008 16:34:22 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAuBK-0005Ga-9d for discuss@apps.ietf.org; Fri, 04 Jan 2008 16:34:22 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1JAuB8-0009MX-7s; Fri, 04 Jan 2008 16:34:10 -0500 Date: Fri, 04 Jan 2008 16:34:09 -0500 From: John C Klensin To: Bill McQuillan , Apps-Discusssion Subject: Re: draft-klensin-net-utf8-06 Message-ID: <92F9B0A1A09F6C8A70CDBED1@p3.JCK.COM> In-Reply-To: <50134794.20071016093853@pobox.com> References: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> <50134794.20071016093853@pobox.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Tuesday, 16 October, 2007 09:38 -0700 Bill McQuillan wrote: > In section 2.1, I understand that the ONLY way to indicate the > end of a line, for text parsing purposes, is the pair . > Any other appearance of either CR or LF, whether or not > allowed by a SHOULD, MUST NOT be considered to be a > "line-ending" and only can be considered as text mark up. > > For example, this > sentence is a single, malformed line. > > Right? Certainly it is a single line. Under the original NVT rules, it is not malformed although it is often bad news. > A typo: Appendix B, bullet 4, penultimate line: > > interpreted as one or spaces, but, in general, it cannot be > ^ > more Got it. Thanks. john From discuss-bounces@apps.ietf.org Fri Jan 04 18:46:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAwEo-000084-LA; Fri, 04 Jan 2008 18:46:06 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAwEn-0008Vo-TO for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 18:46:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAwEn-0008Tc-Gu for discuss@apps.ietf.org; Fri, 04 Jan 2008 18:46:05 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAwEj-0008SX-R6 for discuss@apps.ietf.org; Fri, 04 Jan 2008 18:46:05 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m04Nk1nR011675 for ; Fri, 4 Jan 2008 23:46:01 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JU500F018IN3N00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Fri, 04 Jan 2008 16:46:01 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JU500H178ONF910@mail-amer.sun.com>; Fri, 04 Jan 2008 16:46:01 -0700 (MST) Date: Fri, 04 Jan 2008 15:46:02 -0800 From: Chris Newman Subject: RE: URI for XML schema and namespace In-reply-to: <105601c84ef1$90d0d870$6502a8c0@china.huawei.com> To: David Harrington , "'Julian Reschke'" Message-id: MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> <477E5DA1.9040504@gmx.de> <105601c84ef1$90d0d870$6502a8c0@china.huawei.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org As Applications Area Director, I'm not aware of anyone ever asking for that. I'm holding a discuss position on: draft-narten-iana-considerations-rfc2434bis-08 because the present text forbids use of IANA URLs and I consider that an unacceptable new restriction for IANA considerations. Current IETF practice discourages use of IANA URLs in IETF specifications. However, we have one case, RFC 4790, where stable iana.org http URLs are provided to registry elements and that was done with IANA's permission. In that case, the registry was created to be useful to both the IETF and the W3C. The stable http URLs make the W3C happier so it was worth doing that way. I would support a similar approach for iana.org http XML namespaces if someone spent the time to write up the rules and get IANA's consent. Using an ietf.org http URIs for XML namespaces is a bad idea. The IETF has deliberately kept the registry function for our standards separate and I consider that a feature. Also, ietf.org is operated by the Secretariat function so using that domain for registrations would require additional (and more expensive) coordination than iana.org. It _might_ be feasible to set up a redirect from ietf.org to iana.org for XML namespaces, but I worry that's just one additional level of complexity where things could break (especially if we transition the secretariat function between vendors periodically as we're in the process of doing now). To summarize the options: 1. URNs for XML namespaces -- present IETF common practice 2. non-IETF http URLs for XML namespaces -- acceptable 3. iana.org http URLs for XML namespaces -- nobody has tried this, seems feasible to me. 4. ietf.org http URLs for XML namespaces -- nobody has tried this. I think it's a bad idea. - Chris David Harrington wrote on 1/4/08 11:47 -0500: > Hi Julian, > > That's an interesting observation, but it didn't answer my question. > Has anybody explicitly asked the people who can create such a > permanent web site to do so? > Has anybody fashioned an explicit proposal for the establishment of > permanent IETF URIs? > > Am I off-target with my question? > Would this simply be a bad idea? > If it is a good idea, who wants it badly enough to write such a > proposal? > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > >> -----Original Message----- >> From: Julian Reschke [mailto:julian.reschke@gmx.de] >> Sent: Friday, January 04, 2008 11:24 AM >> To: David Harrington >> Cc: 'Scott Hollenbeck'; 'Apps Discuss' >> Subject: Re: URI for XML schema and namespace >> >> David Harrington wrote: >> > Has anybody actually asked Ray to get such a permanent >> part of IETF's >> > own web space allocated and setup? Would entries on the web site >> > require IANA assignment, e.g. as a registry? >> > >> > I'm asking because I am new to the discussion, and simply don't > know >> > the answer. >> > >> > dbh >> >> I think historically there's a lot of reluctance inside IANA (or the > >> whole IESG) to consider any URI starting with "http" as permanent. >> >> BR, Julian >> > > > > > From discuss-bounces@apps.ietf.org Fri Jan 04 19:56:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAxKm-0002RH-Bq; Fri, 04 Jan 2008 19:56:20 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAxKk-0002Qs-Ik for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 19:56:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAxKk-0002Qk-8h for discuss@apps.ietf.org; Fri, 04 Jan 2008 19:56:18 -0500 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAxKi-0001YD-3y for discuss@apps.ietf.org; Fri, 04 Jan 2008 19:56:18 -0500 Received: by wa-out-1112.google.com with SMTP id m16so9826479waf.20 for ; Fri, 04 Jan 2008 16:56:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=D0dQn2ycXmyKzzJPhQVGnXO1TOMNkKFyEKJ73XmhYb4=; b=PW3fCv4dGERzEs/EWmGLn07Q+ztA0jtxB43GpxMVThzCUpni/lhkwa1Q/6C4nIVkMAtjwiJ/lxpDzlqpM6aXOMgULLOmWgpN3MSSVqIPTs5rPpMgHM6xClsKkDR4es327pYYpHtb5WcyxIaV1VDDS9+euSczv3YCCKRkSPEr2P4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=eMNYoVBTN3H15S4EDwT5Q8s38Xwnfm9WhSSQKaOUuARRW+8kVMS668BlvqmEo0yrZasmKN3h25XKR9jYlNcCsAlElFo+gzAXsbYXrJD9dlLBlnxn9E/af+l4rSIohCD7hDcz10B++fefFqDztgu9q17mE8T5Jm0U6PEUDoDE+8U= Received: by 10.114.194.1 with SMTP id r1mr16155048waf.40.1199494574509; Fri, 04 Jan 2008 16:56:14 -0800 (PST) Received: by 10.114.161.15 with HTTP; Fri, 4 Jan 2008 16:56:14 -0800 (PST) Message-ID: <517bf110801041656t51b17d3eo970576bf7d7cac01@mail.gmail.com> Date: Fri, 4 Jan 2008 16:56:14 -0800 From: "Tim Bray" To: "Chris Newman" Subject: Re: URI for XML schema and namespace In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> <477E5DA1.9040504@gmx.de> <105601c84ef1$90d0d870$6502a8c0@china.huawei.com> X-Google-Sender-Auth: 2373360945f31dbc X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tbray@textuality.com List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Jan 4, 2008 3:46 PM, Chris Newman wrote: > I would support a similar approach for iana.org http XML namespaces if someone > spent the time to write up the rules and get IANA's consent. ... > To summarize the options: > 1. URNs for XML namespaces -- present IETF common practice > 2. non-IETF http URLs for XML namespaces -- acceptable > 3. iana.org http URLs for XML namespaces -- nobody has tried this, seems > feasible to me. > 4. ietf.org http URLs for XML namespaces -- nobody has tried this. I think > it's a bad idea. Sounds very sensible to me. As a Web Geek First Class, I'd volunteer to help with the writing. Don't know anyone @IANA so would need an intro if I were going to help there. Were you thinking of an I-D? -Tim From discuss-bounces@apps.ietf.org Fri Jan 04 21:08:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAySL-0001Am-Vz; Fri, 04 Jan 2008 21:08:13 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JAySL-0001Ag-1N for discuss-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 21:08:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAySK-0001AY-NE for discuss@apps.ietf.org; Fri, 04 Jan 2008 21:08:12 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAySI-0002wP-7C for discuss@apps.ietf.org; Fri, 04 Jan 2008 21:08:12 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id m05285AV024853 for ; Sat, 5 Jan 2008 11:08:05 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 182c_0d027590_bb33_11dc_8a34_0014221fa3c9; Sat, 05 Jan 2008 11:08:04 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:53966) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 5 Jan 2008 11:03:56 +0900 Message-Id: <6.0.0.20.2.20080105105045.074c6ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 05 Jan 2008 11:03:27 +0900 To: Chris Newman , David Harrington , "'Julian Reschke'" From: Martin Duerst Subject: RE: URI for XML schema and namespace In-Reply-To: References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> <477E5DA1.9040504@gmx.de> <105601c84ef1$90d0d870$6502a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 08:46 08/01/05, Chris Newman wrote: >As Applications Area Director, I'm not aware of anyone ever asking for that. > >I'm holding a discuss position on: > draft-narten-iana-considerations-rfc2434bis-08 >because the present text forbids use of IANA URLs and I consider that an unacceptable new restriction for IANA considerations. Great, thanks. Please hold on firmly to this discuss until things are fixed. >Current IETF practice discourages use of IANA URLs in IETF specifications. However, we have one case, RFC 4790, where stable iana.org http URLs are provided to registry elements and that was done with IANA's permission. I wanted to bring up this case, but I'm glad Chris has done it. >In that case, the registry was created to be useful to both the IETF and the W3C. The stable http URLs make the W3C happier so it was worth doing that way. Yes indeed. The W3C uses URIs for a lot of things. One reason is that it helps to avoid registries, or allows decentralized registration, depending on the way you look at it. >I would support a similar approach for iana.org http XML namespaces if someone spent the time to write up the rules and get IANA's consent. Great to know. I'd probably be able to help, or can try to make sure somebody from the W3C can help. Regards, Martin. >Using an ietf.org http URIs for XML namespaces is a bad idea. The IETF has deliberately kept the registry function for our standards separate and I consider that a feature. Also, ietf.org is operated by the Secretariat function so using that domain for registrations would require additional (and more expensive) coordination than iana.org. It _might_ be feasible to set up a redirect from ietf.org to iana.org for XML namespaces, but I worry that's just one additional level of complexity where things could break (especially if we transition the secretariat function between vendors periodically as we're in the process of doing now). > >To summarize the options: >1. URNs for XML namespaces -- present IETF common practice >2. non-IETF http URLs for XML namespaces -- acceptable >3. iana.org http URLs for XML namespaces -- nobody has tried this, seems feasible to me. >4. ietf.org http URLs for XML namespaces -- nobody has tried this. I think it's a bad idea. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Mon Jan 07 04:25:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBoEM-0001Jm-2a; Mon, 07 Jan 2008 04:25:14 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JBoEK-0001Jh-Il for discuss-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 04:25:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBoEK-0001JY-83 for discuss@apps.ietf.org; Mon, 07 Jan 2008 04:25:12 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBoEI-0001YO-PM for discuss@apps.ietf.org; Mon, 07 Jan 2008 04:25:12 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 6A1DA1C011C; Mon, 7 Jan 2008 10:25:09 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 658861C00F9; Mon, 7 Jan 2008 10:25:09 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 591BD58ECBD; Mon, 7 Jan 2008 10:25:09 +0100 (CET) Date: Mon, 7 Jan 2008 10:25:09 +0100 From: Stephane Bortzmeyer To: Chris Newman Subject: Re: URI for XML schema and namespace Message-ID: <20080107092509.GA15174@nic.fr> References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> <477E5DA1.9040504@gmx.de> <105601c84ef1$90d0d870$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Fri, Jan 04, 2008 at 03:46:02PM -0800, Chris Newman wrote a message of 90 lines which said: > To summarize the options: 5. Eat our own dog food and use RFC 4151? From discuss-bounces@apps.ietf.org Mon Jan 07 11:10:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBuYO-0003DJ-R7; Mon, 07 Jan 2008 11:10:20 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JBuYM-0003Bb-M4 for discuss-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 11:10:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBuYM-0003BT-CG for discuss@apps.ietf.org; Mon, 07 Jan 2008 11:10:18 -0500 Received: from mk-outboundfilter-2.mail.uk.tiscali.com ([212.74.114.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBuYK-0000Gz-QN for discuss@apps.ietf.org; Mon, 07 Jan 2008 11:10:18 -0500 X-Trace: 8110421/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.162.31 X-SBRS: None X-RemoteIP: 62.241.162.31 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKbdgUc+8aIf/2dsb2JhbACoIg Received: from galaxy.systems.pipex.net ([62.241.162.31]) by smtp.pipex.tiscali.co.uk with ESMTP; 07 Jan 2008 16:10:14 +0000 Received: from pc6 (1Cust9.tnt5.lnd4.gbr.da.uu.net [62.188.134.9]) by galaxy.systems.pipex.net (Postfix) with SMTP id B7F6FE0000C9; Mon, 7 Jan 2008 16:10:27 +0000 (GMT) Message-ID: <021301c8513f$35f1fce0$0601a8c0@pc6> From: "tom.petch" To: "Chris Newman" References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6><000001c84ee8$789307a0$0223520a@charger><477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger><104301c84eed$1bbd8500$6502a8c0@china.huawei.com><477E5DA1.9040504@gmx.de><105601c84ef1$90d0d870$6502a8c0@china.huawei.com> Subject: Re: URI for XML schema and namespace Date: Mon, 7 Jan 2008 12:16:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -98.6 (---------------------------------------------------) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ----- Original Message ----- From: "Chris Newman" To: "David Harrington" ; "'Julian Reschke'" Cc: "'Apps Discuss'" Sent: Saturday, January 05, 2008 12:46 AM Subject: RE: URI for XML schema and namespace > > To summarize the options: > 1. URNs for XML namespaces -- present IETF common practice > 2. non-IETF http URLs for XML namespaces -- acceptable > 3. iana.org http URLs for XML namespaces -- nobody has tried this, seems > feasible to me. > 4. ietf.org http URLs for XML namespaces -- nobody has tried this. I think > it's a bad idea. > > - Chris The I-D that prompted me to raise this, draft-ietf-forces-model-09.txt, contains so ForCES might be trying 4) (and I am trying to persuade them otherwise). Tom Petch From discuss-bounces@apps.ietf.org Mon Jan 07 11:10:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBuYP-0003DP-06; Mon, 07 Jan 2008 11:10:21 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JBuYN-0003D3-TV for discuss-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 11:10:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBuYN-0003Cu-JR for discuss@apps.ietf.org; Mon, 07 Jan 2008 11:10:19 -0500 Received: from mk-outboundfilter-2.mail.uk.tiscali.com ([212.74.114.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBuYM-0000H2-7h for discuss@apps.ietf.org; Mon, 07 Jan 2008 11:10:19 -0500 X-Trace: 8110479/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.162.31 X-SBRS: None X-RemoteIP: 62.241.162.31 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKbdgUc+8aIf/2dsb2JhbACoIg Received: from galaxy.systems.pipex.net ([62.241.162.31]) by smtp.pipex.tiscali.co.uk with ESMTP; 07 Jan 2008 16:10:17 +0000 Received: from pc6 (1Cust9.tnt5.lnd4.gbr.da.uu.net [62.188.134.9]) by galaxy.systems.pipex.net (Postfix) with SMTP id 6CC81E000088; Mon, 7 Jan 2008 16:10:33 +0000 (GMT) Message-ID: <021401c8513f$377d30c0$0601a8c0@pc6> From: "tom.petch" To: , "Peter Saint-Andre" References: <000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de><000201c84eeb$77c9e3e0$0223520a@charger><104301c84eed$1bbd8500$6502a8c0@china.huawei.com><477E5DA1.9040504@gmx.de> <477E5DFD.10302@stpeter.im><477E609E.6010402@gmx.de> <001f01c84ef8$f7142e50$0223520a@charger><477E7EC3.4090408@stpeter.im> <517bf110801041117sefe07c6i934517934cad368@mail.gmail.com> Subject: Re: URI for XML schema and namespace Date: Mon, 7 Jan 2008 12:26:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -98.6 (---------------------------------------------------) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ----- Original Message ----- From: "Tim Bray" To: "Peter Saint-Andre" Cc: "Apps Discuss" Sent: Friday, January 04, 2008 8:17 PM Subject: Re: URI for XML schema and namespace > On Jan 4, 2008 10:45 AM, Peter Saint-Andre wrote: > > > > In my experience, developers want to resolve namespaces when they're > > trying to figure out what the namespace means, what the schema is, etc. > > But applications don't need to resolve namespaces, nor do end users. At > > least as a general rule... > > Exactly. > In my role as an end user, I have spent a lot of time using SNMP MIBs to understand the data model that they represent and to interpret what I am seeing. Mostly I succeed because SMI does a good job of this or allows applications such as OpenView to do a good job. Now, increasingly I am doing the same thing with XML - and it's a nightmare, a big component of which is namespaces. I think that XML (or the users of XML) has got them horrendously wrong. What would make life bearable would be if each and every namespace was resolvable, and resolved to a 'data dictionary' of some shape or form which listed all the names currently defined in that namespace with syntax and some level of description and reference - those familiar with SNMP and SMI and RFC4181 may see where I am coming from (or wanting to get to). Tom Petch > I have been told (I forget by whom) that there is some doubt as to who > actually controls ietf.org. Sigh. -Tim > > From discuss-bounces@apps.ietf.org Mon Jan 07 12:47:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBw3u-0002o3-RL; Mon, 07 Jan 2008 12:46:58 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JBw3t-0002nm-Hd for discuss-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 12:46:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBw3t-0002nd-7s for discuss@apps.ietf.org; Mon, 07 Jan 2008 12:46:57 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBw3r-0003vY-Fo for discuss@apps.ietf.org; Mon, 07 Jan 2008 12:46:57 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m07HksA5028144 for ; Mon, 7 Jan 2008 17:46:55 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUA00901BRGZS00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Mon, 07 Jan 2008 10:46:54 -0700 (MST) Received: from [10.1.110.5] (24-205-138-209.dhcp.psdn.ca.charter.com [24.205.138.209]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUA008QHC1W2Z50@mail-amer.sun.com>; Mon, 07 Jan 2008 10:46:46 -0700 (MST) Date: Mon, 07 Jan 2008 09:46:51 -0800 From: Chris Newman Subject: Re: URI for XML schema and namespace In-reply-to: <20080107092509.GA15174@nic.fr> To: Stephane Bortzmeyer Message-id: MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> <477E5DA1.9040504@gmx.de> <105601c84ef1$90d0d870$6502a8c0@china.huawei.com> <20080107092509.GA15174@nic.fr> X-Spam-Score: -1.0 (-) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Stephane Bortzmeyer wrote on 1/7/08 10:25 +0100: > On Fri, Jan 04, 2008 at 03:46:02PM -0800, > Chris Newman wrote > a message of 90 lines which said: > >> To summarize the options: > > 5. Eat our own dog food and use RFC 4151? As RFC 4151 is informational, it's debatable whose dog food it is. But it appears to be another option. For this purpose it would seem to have the same issues that URNs have. - Chris From discuss-bounces@apps.ietf.org Mon Jan 07 17:21:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0LU-0000M3-Io; Mon, 07 Jan 2008 17:21:24 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JC0LT-0000LV-GN for discuss-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 17:21:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0LT-0000LM-6a for discuss@apps.ietf.org; Mon, 07 Jan 2008 17:21:23 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC0LR-0001wS-48 for discuss@apps.ietf.org; Mon, 07 Jan 2008 17:21:23 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DF01714229B for ; Mon, 7 Jan 2008 14:21:22 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmR5U+VO4li9 for ; Mon, 7 Jan 2008 14:21:18 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 42BE0142207 for ; Mon, 7 Jan 2008 14:21:18 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) To: Apps Discuss Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-2-246458101 From: Lisa Dusseault Subject: PP1: To smart collaboration between the applications and the network Date: Mon, 7 Jan 2008 14:21:13 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-2-246458101 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed This is the first in the position papers for February's workshop I'm forwarding from attendees. I'll be posting them with PP# for easy search and threading. -- L --- PP1 To smart collaboration between the applications and the network Ray Atarashi (IIJ) 1. Motivation I have proposed the importance of collaboration between applications and the network. From the application point of view, we want to use network resources (ex. bandwidth, response time) and new network functions (ex. QoS, VLAN) flexibly. Applications and services have requirements for network behavior depending on the functions provided by the application. For example, a streaming service requires high bandwidth and low delay network; database transactions need no-packet- loss network but don't need high bandwidth. From the network point of view, it is useful for operation software to know the application behavior. If they can know the requirements of the application, it may be possible to prepare the responded environment. I expect that NETCONF can be an interface to achieve the collaboration. That's because I'm working at NETCONF WG. When we develop an application common architecture, we should think about both the application and the network. It may be useful to organize how each function should be defined and implemented at which layer. On the other hand, though NETCONF is defined based on XML, they don't take advantage of the XML-related technologies. We need advice from APP Area to use application technologies, such as SOAP, SASL, ACL, version control, etc. 2. Problems One of the reasons that collaboration is difficult is that we don't share a common architecture and terminology. There is a gap between application requirements and network functions. Application requirements and behavior are defined by service level, but network functions are implemented by routing and low level configurations. When we have a requirement for network behavior, we have to configure routers using CLI (Command Line Interface). It is hard because we have to master router configuration. And it is impossible that configuration changes automatically and frequently. We need an interface to collaborate between the applications and the network. IMO, the interface is defined not API-like function, but also model-like description. For, example, - Application service model - Network function model These kinds of models may be higher level concept than API. As a application user for the NETCONF, we need a guideline to use and combine the application technologies and protocols. The requirement examples that we select the application technologies are; - easy to implement, related tools are provided, - easy to maintenance, - enough security functions, - easy to extend, - etc.. 3. Proposal To discuss the common architecture, we need to clarify the related technologies, protocol, and so on. To discuss collaboration, we can start to talk about use cases to use network resources from an application. It can be helpful to clarify where the interfaces are needed. --Apple-Mail-2-246458101 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
This is the first in the = position papers for February's workshop I'm forwarding from attendees.=A0 = I'll be posting them with PP# for easy search and threading. -- = L
---
PP1

To smart = collaboration between the applications and the network

Ray = Atarashi (IIJ)
1. Motivation

I have proposed the importance of collaboration = between applications and the network. =46rom the application point of = view, we want to use network resources (ex. bandwidth, response time) = and new network functions (ex. QoS, VLAN) flexibly. Applications and = services have requirements for network behavior depending on the = functions provided by the application. For example, a streaming service = requires high bandwidth and low delay network; database transactions = need no-packet-loss network but don't need high bandwidth.

=46rom the network point of view, it is useful for = operation software to know the application behavior. If they can know = the requirements of the application, it may be possible to prepare the = responded environment. I expect that NETCONF can be an interface to = achieve the collaboration. That's because I'm working at NETCONF = WG.

When we = develop an application common architecture, we should think about both = the application and the network. It may be useful to organize how each = function should be defined and implemented at which layer.

On the other hand, though NETCONF is defined based = on XML, they don't take advantage of the XML-related technologies. We = need advice from APP Area to use application technologies, such as SOAP, = SASL, ACL, version control, etc.

2. Problems

One of the reasons that collaboration is difficult = is that we don't share a common architecture and terminology. There is a = gap between application requirements and network functions. Application = requirements and behavior are defined by service level, but network = functions are implemented by routing and low level configurations. When = we have a requirement for network behavior, we have to configure routers = using CLI (Command Line Interface). It is hard because we have to master = router configuration. And it is impossible that configuration changes = automatically and frequently.

We need an = interface to collaborate between the applications and the network. IMO, = the interface is defined not API-like function, but also model-like = description. For, example,
- Application = service model
- Network function = model
These kinds of models may be = higher level concept than API.
=A0As a = application user for the NETCONF, we need a guideline to use and combine = the application technologies and protocols. The requirement examples = that we select the application technologies are;
- easy to implement, related tools are = provided,
- easy to maintenance,
- enough security functions,
- easy to extend,
- = etc..

3. Proposal

=A0To discuss = the common architecture, we need to clarify the related technologies, = protocol, and so on. To discuss collaboration, we can start to talk = about use cases to use network resources from an application. It can be = helpful to clarify where the interfaces are needed.


= --Apple-Mail-2-246458101-- From discuss-bounces@apps.ietf.org Mon Jan 07 17:28:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0Rx-00008Q-CV; Mon, 07 Jan 2008 17:28:05 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JC0Rw-00008G-1J for discuss-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 17:28:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0Rv-000086-Nh for discuss@apps.ietf.org; Mon, 07 Jan 2008 17:28:03 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC0Rv-00023R-8W for discuss@apps.ietf.org; Mon, 07 Jan 2008 17:28:03 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 34B1B14229B for ; Mon, 7 Jan 2008 14:28:05 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VT-LulbpTUXM for ; Mon, 7 Jan 2008 14:28:03 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C3C19142207 for ; Mon, 7 Jan 2008 14:28:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <44832CA3-43EF-4244-A44D-59A6ADD9CCC7@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Apps Discuss From: Lisa Dusseault Subject: PP2: Application Area Advice on use of Web and XML; energy conservation Date: Mon, 7 Jan 2008 14:27:59 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org PP2 Position Paper Yoshifumi Atarashi (atarashi@alaxala.net) Hiroyasu Kimura (h-kimura@alaxala.com) ALAXLA Networks Corp. We are netconf system developers and contributors of netconf/NGO in the OPS area. Now, OPS area people want to make new Network Manegement System protocol suites based on XML. These include SNMP, MIB and SMI. A few years ago, when netconf wg started, we wanted to use application technologies supporting XML. It was the main reason for the XML choice. But almost OPS area people couldn't use Web service technology. Now they are making an original protocol using only XML format. But we are thinking netconf system using Web service implementations. So we suggest some isses about collaboration APP area and other area. Problem of using application technology in other areas: - don't understand how to use Web technology/XML technology - don't understand application system overview and direction/ architecture of new network services systems The evolution of application services is faster than network services and operations. So we can accelerate low layer network system development by using application technology. And also by using the same technology, we can think of new services involving application and network cooperation. For example, applications demanding QoS, security system using network control from application, on-demand filtering system and so on. For such occations, we have to study application technologies and their implementation techniques with some concept and architecture. Therefore we think that APP area people can write infomational RFC for collaboration with other areas. - How to use and implement web technology/XML technology systems (http, soap, apache, axis, etc.) - How to make XML base protocols and implementations (If needed, think extension of soap/http/XML base protocol for realtime mechanism. ) - New generation Internet architecture (IPv6, security, QoS ...) from the APP area viewpoint. We think these items contribute towards the "Wild Success" of APP area's works. In addition, as network products engineers, we consider the effect of application protocols on energy conservation. We think application protocols behavior are very important for router and switch's energy saving. Routers and switches often decrease performance or sleep for short times for energy manegement, if it is implemented in network products. So some application protocols may come under the influence of packet drop or delay. If needed, we have to think up application protocol extensions for energy conservation. From discuss-bounces@apps.ietf.org Mon Jan 07 17:29:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0T8-0000Fa-0M; Mon, 07 Jan 2008 17:29:18 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JC0T6-0000FQ-3O for discuss-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 17:29:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0T5-0000FI-Pg for discuss@apps.ietf.org; Mon, 07 Jan 2008 17:29:15 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC0T4-00024t-Qj for discuss@apps.ietf.org; Mon, 07 Jan 2008 17:29:15 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DFFE4142207 for ; Mon, 7 Jan 2008 14:29:16 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMSKyVF-F7k3 for ; Mon, 7 Jan 2008 14:29:12 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2722714229B for ; Mon, 7 Jan 2008 14:29:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <1816D113-D902-42CC-B291-80DE72E22018@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Apps Discuss From: Lisa Dusseault Subject: PP3: The Architecting of Identifier Expansion Date: Mon, 7 Jan 2008 14:29:08 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org PP3 ============================================================ The Architecting of Identifier Expansion February 2008 APPS Area Architecture Workshop ============================================================ This text: December 2007 Leslie Daigle. ---------------------------------------- Introduction ---------------------------------------- I'd like to take this opportunity to explore one particular aspect of applications infrastructure architecture. Namely, I'd like to offer some commentary on, and foster discussion about, the general approach to expanding Internet application/ identifiers to accommodate new uses. ---------------------------------------- First reality: Deploying new infrastructure is hard ---------------------------------------- Stepping back from the specifics of technology for a moment, there is a larger question of what to standardize and/or specify in order to facilitate and promote applications that work in the global Internet. That is, rather than standardizing specific piece protocols, are there well understood principles for what is deployable/not? Do we know what "application infrastructure" is? A decade ago, the focus was on developing a directory service (or services) and a stack of Internet identifiers -- uniform names that lead to uniform locators that relied (often) on the DNS for final resolution. Global directories didn't pan out -- at least in part because the need for globally interoperable access to (potentially) sensitive data was not clear. And the struggle over control of the one successfully-deployed lookup infrastructure (DNS) was fostering concerns over the notion of a centrally "controled" infrastructure in a globally-dispersed network. We're still working through the ramifications of that today, as national governments express concerns that their country's commercial reality is in some way dependent on the US government's continued willingness to support their DNS country code in the DNS root. (It's a tortuous argument, but that really is the line of logic). We can see the spillover of this problem when the French agitate to set up a separate ONS root (for RFID-based supply chain management infrastructure), on the argument that they need/want their own control. (The formally sanctioned root of the ONS global tree is operated under contract by a US-based company. There is no formal relation to the USG the way there is for the DNS root, but the argument is that any company is subject to its (home) nation's government). That is, whether or not we manage to keep a single root in the DNS, the DNS-based global argument is spilling into a general philosophy of "nationally-controlled infrastructure". So, what does all this higher-layer politicking mean for applications infrastructure architecture for the Internet? An obvious and already well-understood conclusion is that services must have distributed control (peer to peer, etc). However, it is also worth recognizing that we are not about to dismantle or stop using existing infrastructure services. We're going to keep piling on top of them, because it is very hard to get ubiquitous deployment of new, cooperatively managed, infrastructure services. this is as true for DNS as for routing and addressing. ---------------------------------------- Second reality: Stretching existing infrastructure is painful ---------------------------------------- If deploying new infrastructure is hard, the next thing to try is extending existing protocols, protocol elements, and infrastructures. There are at least 3 different types of challenge in doing this well: 1/ the obvious challenge of compatibility within the protocol(s) being extended; 2/ the equally obvious challenge of ensuring continued compatibility on the wire if there is interplay between servers/clients of different generations; and 3/ the somewhat less obvious issue of expectations and dependencies that may have been built by unrelated protocols and services. For example, when Internationalized domain names were discussed, the primary focus was on the first two challenges. The implications of the 3rd are still being explored: should protocols that carry "domain names" now allow "internationalized domain names"? The answer should be a clear "no", from a protocol perspective: IDNs are strings of unicode characters. *IDNA* representations are valid domain names. However, this consideration gets a little trickier from a human usage point of view. A slightly more subtle version of the question is: what label goes into the distinguished name of an X.509 certificate domain component? These are not resolved in the DNS, so they could be IDNs, right? If the use of the domain component is to show the end user a domain and ask them to confirm it is the domain they intended to access, the IDNA representation is not likely to be useful. However, it's probably equally difficult for a machine to compute a comparison between two IDNs, particularly once one factors in the various equivalence tables supported by different top level domains. ---------------------------------------- Building Archaeologically: New layers on top of old ones ---------------------------------------- Maybe we can think of applications infrastructure in the light of layering on top of existing systems in as clean a fashion as possible. Applications infrastructure itself should evolve as applicatons' needs do: but deploying completely new infrastructure is always a challenge, and simply dumping more stuff into the existing one is not a winning solution for technical and operational reasons. If we want to layer, then we have to have well understood: . semantics at each layer . translation between layers This is more or less the general theory behind the basic Internet identifiers in the Internet protocol stack -- and there's an expired IAB Internet-Draft by Geoff Huston and others that provides a taxonomy of the characteristics that define identifiers at a given layer, as well as eventual dependencies between the layers (draft-iab-identities, expired). Do we need to take that to another level and formalize the notion of the "presentation layer", allow the human-facing identifiers to be more human, without perturbing the functioning of machine processing of protocols? And, does this separation more than just a difference of size of character set, and have more to do with a difference of representation? John Klensin proposed that approach in defining a "layer above the DNS (draft-klensin-dns-search, expired); Michael Mealling and I worked on framing a protocol that would support just such a separation (draft-mealling-sls, expired). From the fact that I'm referring to a bunch of (long since) expired Internet-Drafts, it should be clear that this approach has not been brought to completion. We got to the point of development where it was perfectly clear that the technology was not the challenge: we could provide a sound protocol/infrastructure proposal to support the layer above the DNS approach to separating "identifying things that are maybe network accessible" from "identifying network things". Instead, the challenge was the apparent lack of will or interest in deployment. ---------------------------------------- Questions for further exploration ---------------------------------------- The need to extend and expand Internet identifiers, particularly with respect to supporting an internationalized Internet experience, is not going to go away. And we know that deploying new systems is (impossibly hard) and extending existing systems is (unexpectedly) painful. 1/ Do we just keep muddling with extensions, putting out fires where they appear, or can we take some architectural step back and get ahead of the development curve? 2/ Is layering an answer? Can start this discussion from the perspective of looking at what does/not work with the layer above DNS approach. From discuss-bounces@apps.ietf.org Mon Jan 07 23:48:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC6OI-00024z-2P; Mon, 07 Jan 2008 23:48:42 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JC6OG-00024K-Cr for discuss-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 23:48:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC6OG-00024C-3C for discuss@apps.ietf.org; Mon, 07 Jan 2008 23:48:40 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC6OD-0007ny-Jh for discuss@apps.ietf.org; Mon, 07 Jan 2008 23:48:40 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id m084mYiC026322 for ; Tue, 8 Jan 2008 13:48:34 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4260_f7cf5b88_bda4_11dc_9d4f_0014221fa3c9; Tue, 08 Jan 2008 13:48:34 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:55408) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 8 Jan 2008 13:44:25 +0900 Message-Id: <6.0.0.20.2.20080108104826.09b13570@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 08 Jan 2008 10:49:43 +0900 To: "tom.petch" , "Chris Newman" From: Martin Duerst Subject: Re: URI for XML schema and namespace In-Reply-To: <021301c8513f$35f1fce0$0601a8c0@pc6> References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> <477E5DA1.9040504@gmx.de> <105601c84ef1$90d0d870$6502a8c0@china.huawei.com> <021301c8513f$35f1fce0$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello Tom, Are they using things such as http://ietf.org/forces/1.0/lfbmodel as resolvable URIs or are they using them without planning to have them resolvable? Regards, Martin. At 20:16 08/01/07, tom.petch wrote: >----- Original Message ----- >From: "Chris Newman" >To: "David Harrington" ; "'Julian Reschke'" > >Cc: "'Apps Discuss'" >Sent: Saturday, January 05, 2008 12:46 AM >Subject: RE: URI for XML schema and namespace > > > > >> >> To summarize the options: >> 1. URNs for XML namespaces -- present IETF common practice >> 2. non-IETF http URLs for XML namespaces -- acceptable >> 3. iana.org http URLs for XML namespaces -- nobody has tried this, seems >> feasible to me. >> 4. ietf.org http URLs for XML namespaces -- nobody has tried this. I think >> it's a bad idea. >> >> - Chris > >The I-D that prompted me to raise this, draft-ietf-forces-model-09.txt, contains > > xmlns="http://ietf.org/forces/1.0/lfbmodel" > xmlns:lfb="http://ietf.org/forces/1.0/lfbmodel" > targetNamespace="http://ietf.org/forces/1.0/lfbmodel" > attributeFormDefault="unqualified" > elementFormDefault="qualified"> > > >so ForCES might be trying 4) (and I am trying to persuade them otherwise). > >Tom Petch > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Tue Jan 08 07:39:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCDjg-0007Rn-Et; Tue, 08 Jan 2008 07:39:16 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JCDje-0007RY-PP for discuss-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 07:39:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCDje-0007RO-Fc for discuss@apps.ietf.org; Tue, 08 Jan 2008 07:39:14 -0500 Received: from mk-outboundfilter-1.mail.uk.tiscali.com ([212.74.114.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCDjc-0007RW-J7 for discuss@apps.ietf.org; Tue, 08 Jan 2008 07:39:14 -0500 X-Trace: 14757602/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.163.6 X-SBRS: None X-RemoteIP: 62.241.163.6 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHb9gkc+8aMG/2dsb2JhbACpKw Received: from astro.systems.pipex.net ([62.241.163.6]) by smtp.pipex.tiscali.co.uk with ESMTP; 08 Jan 2008 12:39:10 +0000 Received: from pc6 (1Cust24.tnt110.lnd4.gbr.da.uu.net [62.188.174.24]) by astro.systems.pipex.net (Postfix) with SMTP id F1C6BE000098; Tue, 8 Jan 2008 12:38:46 +0000 (GMT) Message-ID: <000e01c851ea$e2b6ff60$0601a8c0@pc6> From: "tom.petch" To: "Chris Newman" , "Martin Duerst" References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <000001c84ee8$789307a0$0223520a@charger> <477E568E.8050307@gmx.de> <000201c84eeb$77c9e3e0$0223520a@charger> <104301c84eed$1bbd8500$6502a8c0@china.huawei.com> <477E5DA1.9040504@gmx.de> <105601c84ef1$90d0d870$6502a8c0@china.huawei.com> <021301c8513f$35f1fce0$0601a8c0@pc6> <6.0.0.20.2.20080108104826.09b13570@localhost> Subject: Re: URI for XML schema and namespace Date: Tue, 8 Jan 2008 10:49:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ---- Original Message ----- From: "Martin Duerst" To: "tom.petch" ; "Chris Newman" Cc: "'Apps Discuss'" Sent: Tuesday, January 08, 2008 2:49 AM Subject: Re: URI for XML schema and namespace > Hello Tom, > > Are they using things such as http://ietf.org/forces/1.0/lfbmodel > as resolvable URIs or are they using them without planning to > have them resolvable? > > Regards, Martin. Without resolution as far as I can tell. To quote from an e-mail on the ForCES list, > The second issue appears to be our use of an http uri rather than a > field delimited urn as the namespace. The use of HTTP URIs seems fully > conformant. And the use of web space URIs seems recommended by RFC > 3470. The use of URNs for namespaces is offered there as a fallback > alternative. So it is not clear to me what the problem is with our usage. > So RFC3470 was taken as recommending an HTTP URI; but, after the recent discussion on this list, for which many thanks to all who contributed, I think that ForCES will switch to a urn: Tom Petch > > At 20:16 08/01/07, tom.petch wrote: > >----- Original Message ----- > >From: "Chris Newman" > >To: "David Harrington" ; "'Julian Reschke'" > > > >Cc: "'Apps Discuss'" > >Sent: Saturday, January 05, 2008 12:46 AM > >Subject: RE: URI for XML schema and namespace > > > > > > > > > >> > >> To summarize the options: > >> 1. URNs for XML namespaces -- present IETF common practice > >> 2. non-IETF http URLs for XML namespaces -- acceptable > >> 3. iana.org http URLs for XML namespaces -- nobody has tried this, seems > >> feasible to me. > >> 4. ietf.org http URLs for XML namespaces -- nobody has tried this. I think > >> it's a bad idea. > >> > >> - Chris > > > >The I-D that prompted me to raise this, draft-ietf-forces-model-09.txt, contains > > > > > xmlns="http://ietf.org/forces/1.0/lfbmodel" > > xmlns:lfb="http://ietf.org/forces/1.0/lfbmodel" > > targetNamespace="http://ietf.org/forces/1.0/lfbmodel" > > attributeFormDefault="unqualified" > > elementFormDefault="qualified"> > > > > > >so ForCES might be trying 4) (and I am trying to persuade them otherwise). > > > >Tom Petch > > > > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > From discuss-bounces@apps.ietf.org Tue Jan 08 18:59:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCOM9-0004GU-MS; Tue, 08 Jan 2008 18:59:41 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JCOM8-0004GJ-Ru for discuss-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 18:59:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCOM8-0004GB-HT for discuss@apps.ietf.org; Tue, 08 Jan 2008 18:59:40 -0500 Received: from outbound-mail-16.bluehost.com ([69.89.20.231]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JCOM7-0003Tk-0S for discuss@apps.ietf.org; Tue, 08 Jan 2008 18:59:40 -0500 Received: (qmail 32203 invoked by uid 0); 8 Jan 2008 22:52:01 -0000 Received: from unknown (HELO box7.bluehost.com) (69.89.30.147) by mailproxy1.bluehost.com with SMTP; 8 Jan 2008 22:52:01 -0000 Received: from [209.234.108.194] (helo=KingsMountain.com) by box7.bluehost.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1JCNId-0002C1-RC for discuss@apps.ietf.org; Tue, 08 Jan 2008 15:51:59 -0700 X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-7) with nmh-1.1 Subject: Re: URI for XML schema and namespace To: "Apps Discuss" In-reply-to: "tom.petch" 's message of Fri, 04 Jan 2008 14:19:10 +0100 From: ' =JeffH ' Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Jan 2008 14:52:02 -0800 X-Identified-User: {32571:box7.bluehost.com:kingsmou:kingsmountain.com} {sentby:bopbeforesmtp 209.234.108.194 authed with kingsmountain.com} X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Message-Id: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Apps Discuss List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org FWIW, in the SAML specifications, we used URNs. E.g. see the table on pp 7-8 in section 1.1 of.. http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf urn:oasis:names:tc:SAML:2.0:assertion urn:oasis:names:tc:SAML:2.0:protocol Likewise, we used URNs in the Liberty Alliance specifications. E.g. see table 1 on p-8, section 2.1 of.. http://www.projectliberty.org/liberty/content/download/3484/23078/file/libert y-idwsf-soap-binding-v2.0-original.pdf urn:liberty:sb:2006-08 urn:liberty:sb =JeffH From discuss-bounces@apps.ietf.org Thu Jan 10 19:53:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD89N-0003aY-73; Thu, 10 Jan 2008 19:53:33 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JD89L-0003aO-Ni for discuss-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 19:53:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD89L-0003aF-Dv for discuss@apps.ietf.org; Thu, 10 Jan 2008 19:53:31 -0500 Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD89K-0002Z5-2U for discuss@apps.ietf.org; Thu, 10 Jan 2008 19:53:31 -0500 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id DD1651699; Thu, 10 Jan 2008 01:13:19 +0000 (GMT) Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID623maJBNu6016Xo2; Thu, 10 Jan 2008 01:13:20 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID623maJBNu6016Xo2 Received: from [10.1.1.107] ([157.22.41.236]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 18:13:19 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6929B465-1C9E-47FD-8D6C-1D65E23448EA@commerce.net> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Call for interop proposals Date: Wed, 9 Jan 2008 17:13:17 -0800 To: Apps Discuss X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Jan 2008 01:13:19.0492 (UTC) FILETIME=[FC7BB440:01C85325] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Lisa Dusseault's Chairs , chris-newman-chairs@tools.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At the Apps area open meeting in Vancouver, Chris & I mentioned the possibility of doing a day of interoperability events at the next IETF meeting. This would replace a day of Apps area meetings during the normal meeting hours and in the normal meeting location. Ideally it would allow people to come to the IETF for more than just "their" meeting (although we have always hoped they can attend other WG meetings as well) and participants may get more benefit and better justification for attending. If we're going to do this, we need proposals: what topic ( IDs, RFCs, suites or functionality) will be tested. I don't think interops will need a lot of management but volunteer coordinators would be ideal. Proposals will need to be followed quickly by some indications of who will participate. WG scheduling is already open and we need to tell the Secretariat immediately if they need to reserve a day for interops. Proposals should probably be posted on some relevant subject mailing list to quickly generate discussion among potential participants -- not everybody reads Apps Discuss. Thanks, Lisa From discuss-bounces@apps.ietf.org Thu Jan 10 20:19:51 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD8Yo-0005BR-T5; Thu, 10 Jan 2008 20:19:50 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JD8Yn-0005BM-Rp for discuss-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 20:19:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD8Yn-0005BE-Hz for discuss@apps.ietf.org; Thu, 10 Jan 2008 20:19:49 -0500 Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD8Yk-0002uv-47 for discuss@apps.ietf.org; Thu, 10 Jan 2008 20:19:49 -0500 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id A43BF211B for ; Fri, 11 Jan 2008 01:19:45 +0000 (GMT) Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID254makBTt4356Xo1; Fri, 11 Jan 2008 01:19:45 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID254makBTt4356Xo1 Received: from [10.1.1.107] ([157.22.41.236]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 18:19:44 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) To: Apps Discuss Message-Id: <85B1F813-0EA1-4EB5-A828-E93AD89BB222@commerce.net> Content-Type: multipart/alternative; boundary=Apple-Mail-8-516367523 From: Lisa Dusseault Subject: PP4: The Three Laws of HTTP Usage Date: Thu, 10 Jan 2008 17:19:43 -0800 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Jan 2008 01:19:44.0935 (UTC) FILETIME=[0CA36370:01C853F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7191030d885084e634ab0f488bcd9d53 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-8-516367523 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed The Three Laws of Robotics HTTP Usage Lisa Dusseault Jan 10, 2008 This is an attempt to rationalize and justify the requirements we make for IETF standards that use HTTP. The rationalization is inspired by the three laws of robotics described by Isaac Asimov. This categorization may help us figure out who is protected by HTTP reuse guidelines: - deployed systems, - implementors of the new application, - protocol designers (especially future application extensions), or - nobody. These guidelines and requirements may be less applicable to HTTP extensions, such as WebDAV and Atom, where the application makes use of many HTTP resource features and not just its transport characteristics. Those kinds of extensions are even harder to do and require HTTP experts and deep familiarity with RFC2616. A META-NOTE on the state of this document: The reminders and requirements in section 2 are intended to be complete in this draft, not reasonable. I look forward to very interesting discussions about which requirements are not reasonable, particularly if such discussions can happen before HTTP is revised by HTTPBIS WG, in time to influence that revision. 1. First law: Do no harm These are requirements on the design of the application, particularly whether it uses GET or POST and registers new MIME types or ports. These questions should be dealt with early in protocol design and specification. 1.1 Allow filtering Some organizations need to filter or otherwise identify traffic from various HTTP applications. Here are the most reasonable ways to filter HTTP traffic: - Well-known site - New methods - New HTTP version - New port - New MIME Type Defining a single site is not usually appropriate to IETF standards. Setting a new version for a protocol extending HTTP would be pretty nuts. New methods are more often used and appropriate in HTTP extensions than for applications that just want to transmit application requests to HTTP servers for handling by a lightweight extension module. Ruling those three out for most cases leaves us with new port numbers and new MIME types. Both of these use a registry which helps people monitoring traffic to figure out what is going on. BCP 56 recommends new ports, but new MIME types is becoming more common and seems acceptable under these "moral" principles. To make filtering with MIME types reasonable, the MIME type must be unique to the application, registered, and both requests and responses that have bodies MUST use filterable MIME types. It's a little hard to imagine an application using HTTP as a transport that doesn't have any message bodies, but that would definitely be a special case to consider if it were proposed. 1.2 Support intermediaries A few features must be supported correctly, or else intermediaries may do the wrong thing. Since intermediaries can cache responses and retransmit requests, the application needs to support caching and retransmission correctly. Intermediaries are allowed to retransmit any request using a method that is defined as idempotent methods; the most important such method is GET. Thus, an application can only tunnel over GET requests if no harm results from intermediaries retransmitting GET requests. An example of an idempotent application GET request is querying for a certificate from a repository. The POST method should be used to tunnel non-idempotent requests. Since GET responses can be cached, application responses to GET requests need to be cacheable or have the correct cache prevention headers. 2. Second Law: Obey orders This section is more about helping implementations get HTTP right than about designing the new application. A specification using HTTP can get theoretical compliance with RFC2616 just by making a normative reference. However, implementations of such specifications typically do not comply properly with RFC2616. Perhaps implementors need a couple reminders? Specifications should provide a list of oft-violated requirements and remind implementors that they really are requirements. (Alternatively, a protocol specification could overrule HTTP requirements, often by requiring the opposite: instead of requiring servers to handle HEAD requests, the specification could require clients not to send HEAD requests). This extra work to ensure that implementors follow HTTP2616 is not just for pedantic perfection. There are two main reasons, both of which protect the application protocol and its implementors. First, proper support for all features protects the full feature set in case it is needed later. If a few early clients don't support a feature that isn't used by early server implementations, this seems innocuous. But later, one finds that the application servers cannot be updated to make use of the full feature set even if it would be very useful. There's no way to advertise or negotiate for these features because they are REQUIRED in HTTP. When required and un-advertised features are poorly implemented, they become practically impossible to use later. Second, proper support for all features makes general-purpose client libraries and general-purpose server libraries work better. Again, this protects the new application by making it easier to implement with standard libraries -- but this only works if early implementations really do the right thing. Designers of a new protocol might instead make the choice that the new protocol cannot use existing HTTP client or server libraries, in which case the choice should be explicitly stated and version number or protocol name changes should be considered. These features are typically very easy to support properly. In some cases it's just returning the right error -- e.g. servers can fail a request containing unrecognized Content-* headers. Requirements reminders for server implementors: - MUST handle the HEAD request properly, returning no body in the response. - MUST be prepared to handle OPTIONS * requests. - MUST use an error responding to unrecognized methods. - MUST examine conditional headers on requests, and if necessary, fail the request (If-* and ) - MUST honour Content-* headers on requests. Any Content-* headers that are not recognized or cannot be parsed, should cause a ??? error. - MUST handle the Range header or fail the request. - MUST look for the Expect header and be able to do 100 Continue (without waiting for request body) or fail. - MUST either support persistent connections or include the "close" connection option in every response. If the server allows persistent connections it MUST also implement pipelining, not dropping pipelined requests and handling responses in order. Requirements reminders for client implementors: - MUST include a Host header on requests - MUST support several ways response endings may be handled: chunked transfer-encoding, connection closing, and Content-Length. - MUST either support persistent connections or include the "close" connection option in every request. - If the client supports HTTP caching, it MUST examine the Vary, Cache-Control and Expires headers. - MUST NOT automatically follow redirects for methods other than GET and HEAD. - MUST handle a variety of success responses as successes (202, 203, 205) - MUST handle the 407 Proxy Authentication Required response and be able to use the Proxy-Authenticate response-header to authenticate. Requirements on protocol design: - HTTP status codes MUST preserve the same meaning to interoperate well with HTTP client libraries. For example, the 401 Unauthorized code triggers a login request using HTTP authentication. A tricky one is 412 Precondition failed, which can only be used when the client put a precondition on the request. 3. Third Law: Protect yourself These are considerations that can protect the security or extensibility of an application using HTTP. Being considerations, these might not be enforced in outside review of the specification, but they are well worth considering. Thus, this section does not have normative requirements. 3.1 Security Protocol designers may consider whether redirects may safely be followed in all cases or in limited cases. The application could require clients to support redirects, which gives servers more deployment flexibility. On the other hand, the application could limit redirects (only within local site) or forbid the use entirely. Recall that HTTP supports TLS proxies, and these are used in some corporate sites. What this means is that rather than have the client connect directly to the target site, the client connects to the proxy and the proxy initiates its own TLS connection to the target site. The proxy thus gains full access to the content of the application protocol. If this is not an acceptable situation, the application cannot use HTTP as-is. HTTP authentication is not as secure as many other more modern IETF authentication technologies. An application that requires better-than-standard authentication over HTTP may find that default client and server libraries cannot be used. 3.2 Discoverability and interoperability: URL considerations Decide how URLs are known or discovered. Do application requests go straight to http://app.example.org? Can there be a path part? An extended example in this section is the Noogie application, where users have personal Noogie URLs. These URLs identify resources that can receive Noogie application requests, which may trigger virtual noogies given to the receiving user, and result in success or failure responses to the requestor. 3.2.1 Scheme Applications that use HTTP can of course use the HTTP URL scheme. However, protocol designers should consider defining a new URL scheme anyway. In cases where the URL can be found along with other HTTP URLs, this allows clients to select a URL that does what they want. Example: the Noogie application URLs are intended to appear in VCards, presence information documents and on Web sites. In order to allow clients to immediately detect such a URL and know what it's for, the Noogie standard designers can register the "noogie" scheme and explain how this scheme maps to the "http" scheme. 3.2.2 Path part Does the URL path part have any structure? If so, make sure that the path part still allows application servers to be deployed in places where development frameworks and site policies dictate prefixes to this path part. E.g. Legal Noogie URLs must also be able to contain prefixes like "servlets/noogie/" at sites that have policies about service framework usage. One resulting URL would be http://www.example.org/ servlets/noogie/John/Doe even though another site might prefer http:// noogie.example.org/John/Doe. 3.2.3 Query part Most applications that use HTTP do not extend or formalize the query part of an HTTP URL. In this case, the protocol specification might forbid query parts or require that they be stripped from URLs. Query strings have been used to exploit security holes in many HTTP servers. --Apple-Mail-8-516367523 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1


The Three Laws of Robotics HTTP Usage

Lisa = Dusseault
Jan 10, 2008


This is an attempt to = rationalize and justify the requirements we make
for IETF = standards that use HTTP.=A0 The rationalization is inspired by the =
three laws of robotics described by Isaac Asimov.=A0 This = categorization may
help us figure out who is protected by = HTTP reuse guidelines:
- deployed systems,
- = implementors of the new application,
- protocol designers = (especially future application extensions), or
- = nobody.

These = guidelines and requirements may be less applicable to HTTP =
extensions, such as WebDAV and Atom, where the application =
makes use of many HTTP resource features and not just its = transport
characteristics.=A0 Those kinds of extensions are = even harder to do and=A0
require=A0HTTP experts and deep = familiarity with RFC2616.

A META-NOTE on the state of = this document: The reminders and requirements
in section 2 = are intended to be complete in this draft, not reasonable.=A0 =
I look forward to very interesting discussions about which = requirements
are not reasonable, particularly if such = discussions can happen before
HTTP is revised by HTTPBIS WG, = in time to influence that revision.



1.=A0 First law: Do no = harm

These = are requirements on the design of the application, particularly =
whether it uses GET or POST and registers new MIME types or = ports.=A0 These
questions should be dealt with early in = protocol design and specification.

1.1 Allow = filtering

Some = organizations need to filter or otherwise identify traffic from=A0 =
various HTTP applications.=A0 Here are the most reasonable = ways to filter HTTP=A0
traffic:
- = Well-known site
- New methods
- New = HTTP version
- New port
- New = MIME Type
Defining a single site = is not usually appropriate to IETF standards.
Setting a new = version for a protocol extending HTTP would be pretty = nuts.
New methods are more often used and appropriate in HTTP = extensions than
for applications that just want to transmit = application requests to HTTP
servers for handling by a = lightweight extension module.

Ruling those three out for = most cases leaves us with new port numbers and new
MIME = types.=A0 Both of these use a registry which helps people monitoring =
traffic to figure out what is going on.=A0 BCP 56 recommends = new ports, but
new MIME types is becoming more common and = seems acceptable under these
"moral" principles.

To make filtering with MIME = types reasonable, the MIME type must be
unique to the = application, registered, and both requests and responses
that = have bodies MUST use filterable MIME types.=A0 It's a little hard = to
imagine an application using HTTP as a transport that = doesn't have any
message bodies, but that would definitely be = a special case to consider
if it were proposed.

1.2 Support = intermediaries

A few features must be = supported correctly, or else intermediaries=A0
may do the = wrong thing.=A0 Since intermediaries can cache responses and=A0 =
retransmit requests, the application needs to support caching = and=A0
retransmission correctly.

Intermediaries are allowed = to retransmit any request using a method
that is defined as = idempotent methods; the most important such method
is GET.=A0 = Thus, an application can only tunnel over GET requests if no =
harm results from intermediaries retransmitting GET = requests.

An = example of an idempotent application GET request is querying for a=A0 =
certificate from a repository.=A0 The POST method should be = used to
tunnel non-idempotent requests.

Since GET responses can be = cached, application responses to GET requests
need to be = cacheable or have the correct cache prevention headers.
=
2.=A0 Second Law: Obey orders

This section is more about = helping implementations get HTTP right
than about designing = the new application.=A0 A specification using
HTTP can get = theoretical compliance with RFC2616 just by making a =
normative reference. However, implementations of such = specifications
typically do not comply properly with = RFC2616.=A0 Perhaps implementors
need a couple reminders?=A0 = Specifications should provide a list of
oft-violated = requirements and remind implementors that they really
are = requirements.=A0 (Alternatively, a protocol specification = could
overrule HTTP requirements, often by requiring the = opposite:=A0 instead
of requiring servers to handle HEAD = requests, the specification could
require clients not to send = HEAD requests).

This extra work to ensure = that implementors follow HTTP2616 is not=A0
just for pedantic = perfection.=A0 There are two main reasons, both of
which = protect the application protocol and its implementors.

First, proper support for = all features protects the full feature set in=A0
case it is = needed later. If a few early clients don't support a feature=A0 =
that isn't used by early server implementations, this seems = innocuous.=A0=A0
But later, one finds that the application = servers cannot be updated=A0
to make use of the full feature = set even if it would be very useful.=A0=A0
There's no way to = advertise or negotiate for these features because=A0
they are = REQUIRED in HTTP.=A0 When required and un-advertised = features
are poorly implemented, they become practically = impossible to use later.

Second, proper support for = all features makes general-purpose client
libraries and = general-purpose server libraries work better.=A0 Again,
this = protects the new application by making it easier to implement =
with standard libraries -- but this only works if early = implementations
really do the right thing.=A0 Designers of a = new protocol might instead
make the choice that the new = protocol cannot use existing HTTP client or
server libraries, = in which case the choice should be explicitly stated
and = version number or protocol name changes should be = considered.

These features are = typically very easy to support properly.=A0 In some=A0
cases = it's just returning the right error -- e.g. servers can fail a=A0 =
request containing unrecognized Content-* = headers.

Requirements reminders for = server implementors:
- MUST = handle the HEAD request properly, returning no body in the=A0 =
response.
- MUST be prepared to handle = OPTIONS * requests.
- MUST use an error responding to = unrecognized methods.
- MUST examine conditional = headers on requests, and if necessary,=A0
fail the request = (If-* and )
- MUST honour Content-* headers = on requests.=A0 Any Content-* headers=A0
that are not = recognized or cannot be parsed, should cause a ??? = error.
= - MUST handle the Range header or fail the = request.
- MUST look for the Expect header = and be able to do 100 Continue=A0
(without waiting for = request body) or fail.
- MUST either support persistent = connections or include the "close"=A0
connection option in = every response.=A0=A0 If the server allows persistent =
connections it MUST also implement pipelining, not dropping = pipelined
requests and handling responses in = order.

Requirements reminders for = client implementors:

- MUST = include a Host header on requests
- MUST support several ways = response endings may be handled: chunked=A0 =
transfer-encoding, connection closing, and=A0 = Content-Length.
- MUST either support persistent = connections or include the "close"=A0
connection option in = every request.
- If the client supports HTTP = caching, it MUST examine the Vary,=A0
Cache-Control and = Expires headers.
- MUST NOT automatically follow = redirects for methods other than GET
and = HEAD.
= - MUST handle a variety of success responses as successes (202, = 203,=A0
205)
- MUST handle the 407 Proxy = Authentication Required response and be
able to use the = Proxy-Authenticate response-header to authenticate.

Requirements on protocol = design:

- HTTP = status codes MUST preserve the same meaning to interoperate=A0 =
well with HTTP client libraries.=A0 For example, the 401 = Unauthorized code=A0
triggers a login request using HTTP = authentication.=A0 A tricky one is=A0
412 Precondition = failed, which can only be used when the client put a=A0 =
precondition on the request.

3.=A0 Third Law: Protect = yourself

These = are considerations that can protect the security or=A0 =
extensibility of an application using HTTP.=A0 Being = considerations,
these might not be enforced in outside review = of the specification,
but they are well worth considering.=A0 = Thus, this section does not
have normative = requirements.

3.1 Security

Protocol designers may = consider whether redirects may safely be
followed in all = cases or in limited cases.=A0 The application could
require = clients to support redirects, which gives servers more =
deployment flexibility.=A0 On the other hand, the application = could
limit redirects (only within local site) or forbid the = use entirely.

Recall that HTTP supports = TLS proxies, and these are used in some
corporate sites.=A0 = What this means is that rather than have the client
connect = directly to the target site, the client connects to the proxy =
and the proxy initiates its own TLS connection to the target = site.
The proxy thus gains full access to the content of the = application
protocol. If this is not an acceptable situation, = the application
cannot use HTTP as-is.

HTTP authentication is not = as secure as many other more modern=A0
IETF authentication = technologies.=A0 An application that = requires
better-than-standard authentication over HTTP may = find that default
client and server libraries cannot be = used. =

3.2 = Discoverability and interoperability: URL considerations

Decide how URLs are known = or discovered.=A0 Do application requests go=A0
straight to = http://app.example.org?=A0 Can = there be a path part?

An extended example in this = section is the Noogie application, where
users have personal = Noogie URLs.=A0 These URLs identify resources that
can receive = Noogie application requests, which may trigger virtual =
noogies given to the receiving user, and result in success or = failure
responses to the requestor.

3.2.1 Scheme

Applications that use HTTP = can of course use the HTTP URL scheme.
However, protocol = designers should consider defining a new URL scheme
anyway.=A0 = In cases where the URL can be found along with other HTTP=A0 =
URLs, this allows clients to select a URL that does what they = want.

Example: = the Noogie application URLs are intended to appear in=A0 =
VCards, presence information documents and on Web sites.=A0 = In order to=A0
allow clients to immediately detect such a URL = and know what it's=A0
for, the Noogie standard designers can = register the "noogie" scheme=A0
and explain how this scheme = maps to the "http" scheme.
3.2.2 Path = part

Does the = URL path part have any structure?=A0 If so, make sure that the=A0 =
path part still allows application servers to be deployed in = places
where development frameworks and site policies dictate = prefixes to
this path part.

E.g.=A0=A0 Legal Noogie = URLs must also be able to contain prefixes like=A0 =
"servlets/noogie/" at sites that have policies about service=A0=
framework usage.=A0 One resulting URL would be http://www.example.org/ =
servlets/noogie/John/Doe even though another site might = prefer http://
noogie.example.org/John/Doe.


3.2.3 Query = part

Most = applications that use HTTP do not extend or formalize the query =
part of an HTTP URL.=A0 In this case, the protocol = specification might
forbid query parts or require that they be = stripped from URLs.=A0
Query strings have been used to = exploit security holes in many HTTP
servers.


= --Apple-Mail-8-516367523-- From discuss-bounces@apps.ietf.org Thu Jan 10 20:22:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD8bY-0007du-SZ; Thu, 10 Jan 2008 20:22:40 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JD8bW-0007cJ-U2 for discuss-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 20:22:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD8bW-0007cB-KH for discuss@apps.ietf.org; Thu, 10 Jan 2008 20:22:38 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD8bV-0002we-JS for discuss@apps.ietf.org; Thu, 10 Jan 2008 20:22:38 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 801FC14220C for ; Thu, 10 Jan 2008 17:22:39 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYEUKQiUaHI8 for ; Thu, 10 Jan 2008 17:22:34 -0800 (PST) Received: from [10.1.1.107] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 00D9A142203 for ; Thu, 10 Jan 2008 17:22:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) To: Apps Discuss Message-Id: <328AD3B5-F0E1-46D5-8203-B51EE70C51BF@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-9-516535019 References: <3f1451f50712140820p14e08eberc8799e5a517e81d3@mail.gmail.com> From: Lisa Dusseault Subject: PP5: A Theory of Templating Languages Date: Thu, 10 Jan 2008 17:22:30 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: e367d58950869b6582535ddf5a673488 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-9-516535019 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: "Joe Gregorio" > Date: December 14, 2007 8:20:17 AM PST > To: "Lisa Dusseault" , Chris.Newman@sun.com > Subject: Re: Position papers due Dec 14 > > Here is my brief position paper: > > Working on the URI Templating specification has made me realize that > there is a pretty substantial hole > in computer science theory: a lack of a theory of templating > languages. For example, the current version of > URI Templates is not Turing-complete, which excludes a whole bunch of > possible attacks. In the specification I state: > > On the balance, the template processing is not Turing complete, > thus avoiding a number of > security issues, ala the billion-laughs attack of XML DTDs. > > I was rightly called out on this on the W3C URI mailing list: > > This reads a little odd, as not being Turing-complete is not > sufficient > to avoid the attack. (And DTDs are not Turing-complete either.) > > The criticism is correct. The problem is that I don't know of any > finer grained levels of classifications > of templating languages than Turing/non-Turing, and not only for > security reasons, but for general capabilities. > > For example, if there were classes of templating languages, I could > say that URI Templates fell into 'class X', and > if that class had a known set of limitations and capabilities then I > could say that URI Templates thus had those > limitations and capabilities. The weakness to the billion laughs > attack comes from two facets of DTD usage, the > first being that templates can be defined in terms of other templates, > and the second is that the depth of template > definition, in terms of other templates, isn't limited. But the > converse isn't true, that is, I don't have a general > theory of templating to lean on that says since URI Template > expansions are never defined in terms of other > expansions then URI Templates are immune to such resource > exhaustion attacks. > > I did find one paper that makes a start at such work, "Enforcing > Strict Model-View Separation in Template Engines", > but the theory is a little weak and it focuses on the nebulous idea of > separation of model and view, as opposed to > a classification of capabilities and limitations. In addition there > seems to not be a lot of work on sub-turing languages, > and most interestingly the contemporary work that is being done is on > Membrane Computing Systems, which > is in turn motivated by studying cell evolutions and chemical > reactions. I am bringing this topic forward in the > hopes of learning of other pointers into the literature, and also > learning if this problem applies to others > in the Apps area, of if I'm all alone with this problem in URI > Templates. --Apple-Mail-9-516535019 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin = forwarded message:

From: = "Joe Gregorio" <joe@bitworking.org>
=
Date: = December 14, 2007 8:20:17 AM PST
To: "Lisa = Dusseault" <lisa@osafoundation.org>, = Chris.Newman@sun.com
=
Subject: = Re: Position papers due Dec 14

Here is = my brief position paper:

Working on the URI Templating = specification has made me realize that
there is = a pretty substantial hole
in computer = science theory: a lack of a theory of templating
languages. For example, the current version = of
URI Templates is not Turing-complete, which = excludes a whole bunch of
possible = attacks. In the specification I state:

=A0 =A0 On the balance, the = template processing is not Turing complete,
thus = avoiding a number of
=A0=A0 =A0 security issues, ala = the billion-laughs attack of XML DTDs.

I was rightly = called out on this on the W3C URI mailing list:

=A0 =A0 This reads a little odd, = as not being Turing-complete is not sufficient
=A0 =A0 = to avoid the attack.=A0 = (And DTDs are not Turing-complete either.)

The = criticism is correct. The problem is that I don't know of any
finer grained levels of classifications
of templating languages than Turing/non-Turing, and = not only for
security reasons, but for = general capabilities.
For example, if there were = classes of templating languages, I could
say that = URI Templates fell into 'class X', and
if that = class had a known set of limitations and capabilities then I
could say that URI Templates thus had = those
limitations and capabilities. = The weakness to the billion laughs
attack comes = from two facets of DTD usage, the
first being = that templates can be defined in terms of other templates,
and the second is that the depth of = template
definition, in terms of other = templates, isn't limited. But the
converse = isn't true, that is, I don't have a general
theory = of templating to lean on that says since URI Template
expansions are never defined in terms of = other
expansions then URI Templates = are immune to such resource exhaustion attacks.

I did = find one paper that makes a start at such work, "Enforcing
Strict Model-View Separation in Template = Engines",
but the theory is a little weak = and it focuses on the nebulous idea of
a classification of capabilities and limitations. In = addition there
seems to not be a lot of work on = sub-turing languages,
and most interestingly the = contemporary work that is being done is on
Membrane = Computing Systems, which
is in turn = motivated by studying cell evolutions and chemical
reactions. I am bringing this topic forward in = the
hopes of learning of other = pointers into the literature, and also
learning = if this problem applies to others
in the Apps = area, of if I'm all alone with this problem in URI = Templates.

= --Apple-Mail-9-516535019-- From discuss-bounces@apps.ietf.org Tue Jan 15 04:57:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEiXJ-0007gO-Rg; Tue, 15 Jan 2008 04:56:49 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JEiXI-0007gA-Tp for discuss-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 04:56:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEiXB-0007fh-Dj for discuss@apps.ietf.org; Tue, 15 Jan 2008 04:56:41 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEiXA-0001HG-3x for discuss@apps.ietf.org; Tue, 15 Jan 2008 04:56:41 -0500 X-IronPort-AV: E=Sophos;i="4.24,286,1196658000"; d="scan'208,217";a="92280704" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 15 Jan 2008 04:56:38 -0500 X-IronPort-AV: E=Sophos;i="4.24,286,1196658000"; d="scan'208,217";a="150062779" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Jan 2008 04:56:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8575C.E83DBC6C" Subject: FW: Invitation: Joint XML Guidelines Discussion Date: Tue, 15 Jan 2008 10:56:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Invitation: Joint XML Guidelines Discussion Thread-Index: AchXXOe8htGFo+fPR+ORIszbvgxaAg== From: "Romascanu, Dan (Dan)" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Cc: Bert Wijnen - IETF X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8575C.E83DBC6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This came to our attention through the ITU-T NGN Management Focus Group which I and Bert Wijnen are participating in.=20 =20 I believe it would be interesting to have somebody from the APPS area, maybe also from the XML Directorate and YANG team attending. If folks are interested please let me know, as there is still an open discussion about the date (either 2/4 or 2/5).=20 =20 Regards, =20 Dan =20 =20 =20 =20 ________________________________ From: Davis, Nigel (HAL02:QT10) [mailto:NIGELD@nortel.com]=20 Sent: Friday, January 11, 2008 2:13 PM To: Sidor, Dave (NC1:1A00); *Mak, Leen; *Toche, Christian; Divialle, Marie (CTF:ZZ00); *Johannessen, Knut; *Fujii, Nobuo; *Kurakova, Tatiana; *Burkett, Debbie; *Caruso, Francesco; *Garbanati, Linda; Frode Nergard; *Geipl, Michael; *Ronco, Enrico; *Caryer, Geoff; *Zoicas, Adrian; *Huang, Shuqiang; *Wang, Zhili; Amit Kleinmann; Magnet, Jerome (CAR:QT32) Subject: Invitation: Joint XML Guidelines Discussion Hi all,=20 Apologies for my delay in setting up this meeting (I fear this year has started as it means to go on!).=20 Firstly, Dave Sidor, I would be grateful if you could ensure that this gets sent to the appropriate distribution(s) to enable the NGNMFG community to participate in this activity appropriately, I have only sent this to those who were at the meeting that triggered the discussion and other parties who have expressed specific interest. Introduction=20 As discussed and agreed at the "Joint Conference Call on Methodology between ITU-T SG4, 3GPP SA5, TISPAN WG8, TMF mTOP and ATIS TMOC" held 2007-12-12, I am calling a meeting to discuss "XML guidelines" and to potentially initiate combined work (study etc) in the area of generation and refinement of XML guidelines and definitions for application to management system interfaces. Important Note=20 The meeting was originally planned for Tuesday 5th February and I am considering keeping to that date, however at this point I will have some difficulty holding the meeting on 5th February and would prefer to hold the meeting on Monday 4th February (at the same times as originally planned). If anyone who feels that they wish to attend can not attend on Monday 4th Feb I will maintain the original plan of 5th February. I would request that all interested parties please currently keep dates/times available and respond to me by end of day 18th January (by reply to this mail) with respect to your availability on 4th February. If anyone objects to 4th Feb I will stay with 5th Feb otherwise I will hold the meeting on 4th Feb. I would be grateful if all interested parties could respond so I can get an idea of numbers and representation etc. Agenda=20 * Introductions=20 * IPR declaration=20 * Brief overview of purpose=20 * Some initial considerations=20 * Next steps=20 * AOB=20 =09 Meeting Logistics=20 * Date:=20 * Either Monday 4th February or Tuesday 5th February (as discussed above)=20 * Time:=20 * 13:00 GMT - 15:00 GMT=20 * Local time conversion: http://www.timeanddate.com/worldclock/fixedtime.html?day=3D4&month=3D2&ye= ar=3D 2008&hour=3D13&min=3D0&sec=3D0&p1=3D0 =20 * Phone Access Details:=20 * Number:=20 * +1-972-684-5262 (US)=20 * +44-162-843-5262 (UK)=20 * +33-16-955-2262 (France)=20 * +49-696-697-1262 (Germany)=20 * +39-065-152-9162 (Italy)=20 * +34-91-709-4762 (Spain)=20 * +61-2-6279-7721 (Australia (Canberra))=20 * 6-427-5262 (Nortel)=20 * Access code: 59781#=20 * Webmeeting Access Details=20 * https://www.gotomeeting.com/join/146470527 =20 * Meeting ID: 146-470-527=20 =09 I may need to change the Webmeeting access but will inform you by mail before the meeting.=20 If you have any comments on the above please do not hesitate to contact me by return of mail or by phone (as below).=20 Thanks=20 Nigel Davis=20 Nortel=20 Desk/ip/vm : +44-1279-403978 (ESN 742-3978) Mobile/vm : +44-7740-670288 (ESN 748-0288) Fax : +44-1279-405904 (ESN 742-5904)=20 London Road Harlow, Essex CM17 9NA United Kingdom=20 Confidentiality Notice: This message and any attachments may contain information that is privileged and confidential. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender immediately by reply email and destroy all copies of the original message. ------_=_NextPart_001_01C8575C.E83DBC6C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Invitation: Joint XML Guidelines Discussion
This came to our attention through the = ITU-T NGN=20 Management Focus Group which I and Bert Wijnen are participating in.=20
 
I believe it would be interesting to have = somebody from=20 the APPS area, maybe also from the XML Directorate and YANG team = attending. If=20 folks are interested please let me know, as there is still an open = discussion=20 about the date (either 2/4 or 2/5).
 
Regards,
 
Dan
 
 
 
 

From: Davis, Nigel (HAL02:QT10)=20 [mailto:NIGELD@nortel.com]
Sent: Friday, January 11, 2008 = 2:13=20 PM
To: Sidor, Dave (NC1:1A00); *Mak, Leen; *Toche, Christian;=20 Divialle, Marie (CTF:ZZ00); *Johannessen, Knut; *Fujii, Nobuo; = *Kurakova,=20 Tatiana; *Burkett, Debbie; *Caruso, Francesco; *Garbanati, Linda; Frode = Nergard;=20 *Geipl, Michael; *Ronco, Enrico; *Caryer, Geoff; *Zoicas, Adrian; = *Huang,=20 Shuqiang; *Wang, Zhili; Amit Kleinmann; Magnet, Jerome=20 (CAR:QT32)
Subject: Invitation: Joint XML Guidelines=20 Discussion

Hi all, =

Apologies for my delay = in setting up=20 this meeting (I fear this year has started as it means to go on!).=20

Firstly, Dave Sidor, I = would be=20 grateful if you could ensure that this gets sent to the appropriate=20 distribution(s) to enable the NGNMFG community to participate in this = activity=20 appropriately, I have only sent this to those who were at the meeting = that=20 triggered the discussion and other parties who have expressed specific=20 interest.

Introduction=20
As discussed and = agreed at the=20 "Joint Conference Call on Methodology between ITU-T SG4, 3GPP SA5, = TISPAN WG8,=20 TMF mTOP and ATIS TMOC" held 2007-12-12,  I am calling a meeting to = discuss=20 "XML guidelines" and to potentially initiate combined work (study etc) = in the=20 area of generation and refinement of XML guidelines and definitions for=20 application to management system interfaces.

Important=20 Note
The meeting=20 was originally planned for Tuesday 5th February and I am considering = keeping to=20 that date, however at this point I will have some difficulty holding the = meeting=20 on 5th February and would prefer to hold the meeting on Monday 4th = February (at=20 the same times as originally planned). If anyone who feels that they = wish to=20 attend can not attend on Monday 4th Feb I will maintain the original = plan of 5th=20 February. I would request that all interested parties please currently = keep=20 dates/times available and respond to me by end of day 18th January (by = reply to=20 this mail) with respect to your availability on 4th February. If anyone = objects=20 to 4th Feb I will stay with 5th Feb otherwise I will hold the meeting on = 4th=20 Feb. I would be grateful if all interested parties could respond so I = can get an=20 idea of numbers and representation etc.

Agenda=20

  • Introductions=20
  • IPR = declaration=20
  • Brief overview of=20 purpose=20
  • Some initial=20 considerations=20
  • Next = steps=20
  • AOB =

Meeting=20 Logistics=20

  • Date: =
    • Either Monday 4th = February or=20 Tuesday 5th February (as discussed above)
  • Time: =
    • 13:00 GMT - 15:00 = GMT=20
    • Local time = conversion:=20 http://www.timeanddate.com/worldclock/fixedtime.html?day=3D4&= ;month=3D2&year=3D2008&hour=3D13&min=3D0&sec=3D0&p1=3D= 0
  • Phone Access=20 Details:=20
    • Number: =
      • +1-972-684-5262 = (US)=20
      • +44-162-843-5262=20 (UK)=20
      • +33-16-955-2262 = (France)=20
      • +49-696-697-1262=20 (Germany)=20
      • +39-065-152-9162=20 (Italy)=20
      • +34-91-709-4762 = (Spain)=20
      • +61-2-6279-7721 = (Australia=20 (Canberra))=20
      • 6-427-5262=20 (Nortel)
    • Access code: = 59781#=20
  • Webmeeting Access=20 Details=20
    • https://www.gotomeeting.com/join/146470527=
    • Meeting ID: = 146-470-527=20

I may need to change = the Webmeeting=20 access but will inform you by mail before the meeting. =

If you have any = comments on the=20 above please do not hesitate to contact me by return of mail or by phone = (as=20 below).

Thanks =

Nigel Davis =
Nortel
Desk/ip/vm : +44-1279-403978 = (ESN=20 742-3978)
Mobile/vm   : +44-7740-670288 (ESN = 748-0288)
Fax          &= nbsp;   =20 : +44-1279-405904 (ESN 742-5904)=20
London = Road
Harlow, = Essex
CM17 = 9NA
United = Kingdom
Confidentiality Notice: This message and any attachments may = contain=20 information that is privileged and confidential. If you have reason to = believe=20 that you are not the intended recipient or a person responsible for = delivering=20 this message to an intended recipient, you are hereby notified that any = review,=20 dissemination, distribution, or copying of this message is strictly = prohibited.=20 If you have reason to believe that you are not the intended recipient or = a=20 person responsible for delivering this message to an intended recipient, = please=20 contact the sender immediately by reply email and destroy all copies of = the=20 original message.



------_=_NextPart_001_01C8575C.E83DBC6C-- From discuss-bounces@apps.ietf.org Tue Jan 15 08:48:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEm8v-0005nz-Ob; Tue, 15 Jan 2008 08:47:53 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JEm8u-0005nf-9x for discuss-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 08:47:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEm8t-0005nO-W5 for discuss@apps.ietf.org; Tue, 15 Jan 2008 08:47:51 -0500 Received: from exprod7og111.obsmtp.com ([64.18.2.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEm8t-0004h9-Ko for discuss@apps.ietf.org; Tue, 15 Jan 2008 08:47:51 -0500 Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Tue, 15 Jan 2008 05:47:09 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jan 2008 05:46:23 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m0FDkM965071; Tue, 15 Jan 2008 05:46:22 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m0FDkFK5064146; Tue, 15 Jan 2008 13:46:15 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801151346.m0FDkFK5064146@idle.juniper.net> To: "Romascanu, Dan (Dan)" Subject: Re: [YANG] FW: Invitation: Joint XML Guidelines Discussion In-reply-to: Date: Tue, 15 Jan 2008 08:46:15 -0500 From: Phil Shafer X-OriginalArrivalTime: 15 Jan 2008 13:46:23.0102 (UTC) FILETIME=[041431E0:01C8577D] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: yang@ietf.org, discuss@apps.ietf.org, xml-dir@ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org "Romascanu, Dan (Dan)" writes: >I believe it would be interesting to have somebody from the APPS area, >maybe also from the XML Directorate and YANG team attending. If folks >are interested please let me know, as there is still an open discussion >about the date (either 2/4 or 2/5). I'll be willing to call in. Thanks, Phil From discuss-bounces@apps.ietf.org Thu Jan 17 16:25:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFcEP-0000o2-12; Thu, 17 Jan 2008 16:25:01 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JD7cK-00015f-9F for discuss-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 19:19:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD7cJ-00015X-Vm for discuss@apps.ietf.org; Thu, 10 Jan 2008 19:19:23 -0500 Received: from gateway.tr-sys.de ([213.178.172.147] helo=WOTAN.TR-Sys.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD7cI-00023u-B3 for discuss@apps.ietf.org; Thu, 10 Jan 2008 19:19:23 -0500 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA267350703; Fri, 11 Jan 2008 01:18:23 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA09710; Thu, 10 Jan 2008 19:01:58 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200801101801.TAA09710@TR-Sys.de> Subject: draft-klensin-net-utf8-07 To: john-ietf@jck.com, the.map@alum.mit.edu Date: Thu, 10 Jan 2008 19:01:57 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-Mailman-Approved-At: Thu, 17 Jan 2008 16:25:00 -0500 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello, after studying the Internet-Draft authored by you, draft-klensin-net-utf8-07 , I once again would like to point you to a few small textual flaws I found left in the current version of that memo, and some metadata considerations. (1) Section 4, last paragraph -- word replication Please remove the spurious duplicate word 'were' : Were such changes to be were made, the IETF would be ... --- ^^^^^ Were such changes to be made, the IETF would be ... (2) Appendix B (2a) list item # 4., 3rd-to-last line -- typo s/unlkely/unlikely/ (2b) last paragraph The draft says: It is worth noting that the telnet IAC character (an octet consisting of all ones, i.e., %xFF) itself is not a problem for UTF-8. [...] For clarification, I suggest to amend this sentence, explaining why that's the case, for instance: It is worth noting that the telnet IAC character (an octet consisting of all ones, i.e., %xFF) itself is not a problem for UTF-8, because it is not a legal codepoint in UTF-8 and as such can easily be discerned by a telnet style command processor that will strip the entire command sequences from the data stream before handing the proper Network Unicode text to the application layer (or a user interface). [...] (3) Relationship to other documents The last item in D.2 says: o Clarified relationships to existing protocols, stressing that this is not, in itself, a proposal to change any of them. This is in contrast to the heading of the memo saying: Obsoletes: RFC 698 (if approved) <-- Telnet extended ASCII Option Updates: RFC854 (if approved) <-- Telnet IMHO, the above statement does not hold strictly any more with the current draft text. But if we accept the draft to change protocols (or at least one, Telnet), wouldn't it make sense to declare this draft to also obsolete RFC 1641, (RFC 1642 -->) RFC 2152, and perhaps other early IETF I18N documents as well? In particular, the registrations for legacy representations of Unicode should be marked "deprecated" in the IANA charset registry; to this end, a substantive IANA Considerations section needs to be added to the draft. Best regards, Alfred H=CEnes. -- = +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From discuss-bounces@apps.ietf.org Fri Jan 18 13:58:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwQL-000764-BQ; Fri, 18 Jan 2008 13:58:41 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JFwQK-00075x-7A for discuss-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 13:58:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwQJ-00075p-Tk for discuss@apps.ietf.org; Fri, 18 Jan 2008 13:58:39 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFwQH-0001dp-I6 for discuss@apps.ietf.org; Fri, 18 Jan 2008 13:58:39 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 59711142201 for ; Fri, 18 Jan 2008 10:58:39 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAGTUDuIG5AD for ; Fri, 18 Jan 2008 10:58:32 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B5EB2142274 for ; Fri, 18 Jan 2008 10:58:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Apps Discuss From: Lisa Dusseault Subject: PP6: LoST, location based routing, and application Infrastructure. Date: Fri, 18 Jan 2008 10:58:28 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org LoST, location based routing, and application Infrastructure. Ted Hardie Work done in the ECRIT working group to support location-based routing of emergency calls has resulted in LoST (A Location to Service Translation protocol). The current draft, draft-ietf-ecrit-lost, will be revised in the next few weeks to handle Last Call comments, and then submitted to the IESG. Assuming there is no major architectural issues raised, it will become part of the toolkit available for applications. This position paper discusses who might use it and why. Basic LoST protocol transactions start with a location expressed in XML (using either a civic or geolocation profile) and a service URN; one or more contact URIs is returned along with the boundaries for which that contact URI is valid, if that information is available. The protocol also supports getting the service boundaries as a direct query, as well as a request to list the services supported. LoST servers are identified using U-NAPTR, and there is a mechanism for tree traversal and referral for finding the server authoritative for a particular location, service tuple. The infrastructure deployment needed for a new LoST service currently involves registering an appropriate service URN, deploying the servers which map locations to specific URIs, and making clients aware of the service. While clients can discover supported services using the listService command, this carries no direct information about the nature of the service, so some out-of-band information channel is needed to explain the value of any new service. It also requires that the service be delivered in a way that has location-specific catchment areas. Delivery of emergency services has this because of a mapping of PSAPs (public safety access points) and emergency responders to specific areas by public safety officials. Some other industries have delineated areas which are associated with specific providers. In the U.S., for example, Major League Baseball has delineated areas which are associated with specific teams; while anyone can be a fan of any team from anywhere, there are rules which relate to specific territories and a default team for that territory. In most cases, though, this is not done through industry-scale cooperative agreements; a particular provider may divide up the territory associated with their stores, but the same division is unlikely to hold for other providers, absent regulation. So Pizza Igloo and Pizza Lean-to are both likely to divide up their territories, but the division will likely not match. Taxi services, on the other hand, might match because of licensing regulations, but this is likely due to the aggregation of specific local licenses rather than an industry-wide delineation or large catchment-area assignment. There are three main branches of deployment, in other words. The first is for services where catchment areas have been assigned by jurisdiction, as PSAPs are assigned. Identifying the post office responsible for mail delivery to a specific address, for example, would be jurisdictionally determined. The second is for services delivered by specific branches of a single provider. These might be physical services (the Pizza Lean-to which will deliver to an address) or online services (World of Statecraft might offer to associate new players with political parties forming in their local areas in order to foster team creation, even though the team's efforts in WoS would not be locally bound). The third is deployment using aggregators who determine what services from various providers are available in specific areas and make that available; such an aggregator might get the service areas for Pizza Lean-to, Pizza Igloo, and Pizza Yurt, then provide any salient contact URIs when a lookup for pizza services occurs. An architectural problem which arises with each of these three models sharing a protocol is a strong possibility of namespace partition at the URN level. For the jurisdictional services like sos or postal, it is easy to see how to resolve what the service names should be and how registration can proceed. But should it be urn:service:pizza or urn:service:food.delivery.pizza? Should individual providers' lost services be urn:service:Pizza- Leanto.delivery or urn:service:food.delivery.Pizza-Leanto? Having IANA organize this set of namespaces for all services which might be delivered anywhere seems like a non-starter. Having a small set of widely agreed services registered under urn:service seems possible, but IANA doesn't have the time, attention, or expertise to act as Linnaeus to the service world. That, in turn, tends to imply that there will be multiple trees, each run by a different organization, if LoST becomes common; the other option, of course, is that LoST stays in the jurisdictional space and other mechanisms become popular for the other two. Practically speaking, the tuple of location and any service- identifying URI is sufficient once an appropriate LoST server has been found, so the problem devolves to one of configuration/ discovery. That problem, though, could hit us hard in retaining user control. Current location-based service delivery mechanisms have a strong flavor of provider lock-in, especially on the ISP side; moving to LoST could move to a more fully independent LBS industry, but that will not work if the only LoST server discovery mechanisms rely on ISP deployments to maintain. Further work on discovery, in other words, may be needed to maintain end-user independence of operator control. From discuss-bounces@apps.ietf.org Fri Jan 18 13:59:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwRb-0001R3-AA; Fri, 18 Jan 2008 13:59:59 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JFwRa-0001Qx-37 for discuss-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 13:59:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwRZ-0001Qp-PF for discuss@apps.ietf.org; Fri, 18 Jan 2008 13:59:57 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFwRY-0001fS-Gb for discuss@apps.ietf.org; Fri, 18 Jan 2008 13:59:57 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A464614227E for ; Fri, 18 Jan 2008 10:59:58 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ5NrBUY7aHp for ; Fri, 18 Jan 2008 10:59:51 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C20B8142201 for ; Fri, 18 Jan 2008 10:59:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) To: Apps Discuss Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-3--962710845 References: <476AD1C2.6010600@neustar.biz> From: Lisa Dusseault Subject: PP7: Server Identity Check Date: Fri, 18 Jan 2008 10:59:48 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-3--962710845 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: =JeffH > > The overall topic is "Server Identity Check", as discussed/ > specified in http://ietf.org/rfc/rfc2830.txt... > > > > 3.6. Server Identity Check > > The client MUST check its understanding of the server's hostname > against the server's identity as presented in the server's > Certificate message, in order to prevent man-in-the-middle attacks. > > Matching is performed according to these rules: > > - The client MUST use the server hostname it used to open the LDAP > connection as the value to compare against the server name as > expressed in the server's certificate. The client MUST NOT > use the > server's canonical DNS name or any other derived form of name. > > - If a subjectAltName extension of type dNSName is present in the > certificate, it SHOULD be used as the source of the server's > identity. > > - Matching is case-insensitive. > > - The "*" wildcard character is allowed. If present, it applies > only > to the left-most name component. > > E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not > bar.com. If more than one identity of a given type is present > in the > certificate (e.g. more than one dNSName name), a match in any > one of > the set is considered acceptable. > > If the hostname does not match the dNSName-based identity in the > certificate per the above check, user-oriented clients SHOULD > either > notify the user (clients MAY give the user the opportunity to > continue with the connection in any case) or terminate the > connection > and indicate that the server's identity is suspect. Automated > clients > SHOULD close the connection, returning and/or logging an error > indicating that the server's identity is suspect. > > Beyond the server identity checks described in this section, > clients > SHOULD be prepared to do further checking to ensure that the server > is authorized to provide the service it is observed to provide. The > client MAY need to make use of local policy information. > > > > Which apparently is either being referenced in various RFCs/I-Ds, > or is being ignored in other various I-Ds/RFCs, who then re-invent > their own version, or don't at all. > > Thus it has been suggested (by ChrisN to me, at Vancouver last > month) to extract the above and make it into a BCP applicable to at > least the apps area. > > So also from RFC2830, are sections.. > > > > 3.5. Assertion of Client's Authorization Identity > > 3.7. Refresh of Server Capabilities Information > > 5. Effects of TLS on a Client's Authorization Identity > > 5.1. TLS Connection Establishment Effects > > > > ..or any of the other RFC2830 (sub)sections relevant for inclusion > in this postulated BCP? > > As part of my submission, I'll bring an initial -00 rev I-D of said > BCP to the workshop and/or distribute it appropriately beforhand. > > thanks, > > =JeffH > > > > > --Apple-Mail-3--962710845 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin = forwarded message:

From: = =3DJeffH <Jeff.Hodges@neustar.biz>

The overall topic is "Server Identity Check", as = discussed/specified in http://ietf.org/rfc/rfc2830.txt...





























=

= --Apple-Mail-3--962710845-- From discuss-bounces@apps.ietf.org Fri Jan 18 14:01:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwSk-0002VV-SU; Fri, 18 Jan 2008 14:01:10 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JFwSj-0002UN-F6 for discuss-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 14:01:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwSj-0002Ta-54 for discuss@apps.ietf.org; Fri, 18 Jan 2008 14:01:09 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFwSi-0001hH-E0 for discuss@apps.ietf.org; Fri, 18 Jan 2008 14:01:09 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8D2A71421FD for ; Fri, 18 Jan 2008 11:01:10 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuLnScK3KqKe for ; Fri, 18 Jan 2008 11:01:01 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 493CF142201 for ; Fri, 18 Jan 2008 11:01:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Apps Discuss From: Lisa Dusseault Subject: PP8: Asynchronous change notification for HTTP-based resources Date: Fri, 18 Jan 2008 11:00:57 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Asynchronous change notification for HTTP-based resources Rohan Mahy see also: http://svn.resiprocate.org/rep/ietf-drafts/rohan/web-notify/ draft-mahy-http-change-notification-via-sip-00.html Many applications are interested in timely notification about changes of HTTP-based resources. For example: - appointments changing in a set of CalDAV calendars - web-based news or blog-articles updated (the typical domain of Atom and RSS) - my photo directory changing - a subdirectory changing in a large software project's source code repository - a change to the state of an Internet Draft in the tracker. Current practices in change notification involve polling individual HTTP resources, or polling some kind of HTTP "catalog" resource to see what resources have changed. Both of these methods inherently suck. The "catalog" approach at least substantially reduces the number of resources that need to be polled, but the amount of time to wait between polls is always one-sided compromise and rarely optimal for response time, network usage, and battery life. In many applications it is useful to listen for changes for whole subtrees starting from a specific collection. For example, registering interest once for all photos in my "family" photo directory or all source code for the "foo" project. In other applications it is useful to find out only when a small part of a single large XML document changes. I believe we need async notifications for these types of events. SIP and XMPP both have notification mechanisms (SIP Events and XMPP PubSub, respectively). Both of these protocols are appropriate. I used SIP to make a concrete draft [1] because I am more familiar with it. There is also a WebDAV-specific notification scheme described for XMPP in [2]. In some cases details about what resources have changed needs to be filtered for privacy reasons. For example, assume Alice has publicly-readable photos and photos viewable only by a handful of her friends. If Alice adds (or deletes) a new private photo, we want to notify those who were authorized to fetch the photo only, not everyone who asks to be notified when Alice's photos change. This could result in different notifications based on who is requesting them. We usually care about the state or status or these resources, rather than a detailed blow-by-blow about how a resource ended up in a particular state. However, sometimes we may want to track a version history for some resources. Regardless, the native representation of an HTTP-resource could be anything, not just files and directories in a filesystem. Changes to these resources could be caused by non-HTTP operations (such as modifying a database), using standard HTTP methods, or using WebDAV. From discuss-bounces@apps.ietf.org Fri Jan 18 14:02:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwTX-0002bm-VO; Fri, 18 Jan 2008 14:01:59 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JFwTX-0002bd-4g for discuss-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 14:01:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwTW-0002bU-R2 for discuss@apps.ietf.org; Fri, 18 Jan 2008 14:01:58 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFwTW-0001ix-GG for discuss@apps.ietf.org; Fri, 18 Jan 2008 14:01:58 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A1E4D14229C for ; Fri, 18 Jan 2008 11:02:00 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0tI-ViIup3s for ; Fri, 18 Jan 2008 11:01:54 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 928F51421FD for ; Fri, 18 Jan 2008 11:01:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <476308CB.4060103@stpeter.im> References: <476308CB.4060103@stpeter.im> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: PP9: Re: push and pull Date: Fri, 18 Jan 2008 11:01:51 -0800 To: Apps Discuss X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Already posted but I'm identifying it as PP9... On Dec 14, 2007, at 2:50 PM, Peter Saint-Andre wrote: > I started to write a paper for the Apps Area Architecture Workshop, > but > it morphed into a blog post. Folks here may or may not find it of > interest: > > https://stpeter.im/?p=2108 > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > From discuss-bounces@apps.ietf.org Fri Jan 18 14:42:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFx6W-00068Y-8V; Fri, 18 Jan 2008 14:42:16 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JFx6U-00068S-Q5 for discuss-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 14:42:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFx6U-00068K-B2 for discuss@apps.ietf.org; Fri, 18 Jan 2008 14:42:14 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFx6S-0002bK-El for discuss@apps.ietf.org; Fri, 18 Jan 2008 14:42:14 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 601D6142254 for ; Fri, 18 Jan 2008 11:42:14 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBm2sNdHNQBR for ; Fri, 18 Jan 2008 11:42:08 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 065AD142203 for ; Fri, 18 Jan 2008 11:42:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) To: Apps Discuss Message-Id: <5DAA4297-0D1D-4B71-A587-F8C702BE9296@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-4--960174947 References: <1625A315-9B63-4FA8-B042-8BF4F8B0A64B@Isode.com> From: Lisa Dusseault Subject: PP10: Extending LDAP schemas in support of Applications Date: Fri, 18 Jan 2008 11:42:04 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-4--960174947 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: Kurt Zeilenga > Date: January 18, 2008 11:33:45 AM PST > To: Lisa Dusseault > Subject: Re: Directory Position > > Here's a bit more... -- Kurt > > > LDAP directory systems are in wide spread use as repositories for > information used in providing Internet services, including Email > services (SMTP, IMAP, POP, SIEVE, MANAGESIEVE), instant messaging > and presence services (XMPP, SIP), and calendaring and scheduling > (CALDAV). Despite this wide spread use, schema used in > representing Internet service information is rarely standardized. > This hinders interoperability. > > To improve interoperability, the IETF should engineer standards, > where appropriate, of LDAP schema used for representing information > used in providing Internet services. This engineering would > include specification of generalized schema elements, such as for > representing Internet users and their credentials, and > specification of service-specific elements, such as representing > objects in support of Email services. > > Example generalized schema elements include: > > - Define schema to represent a user of Internet services. > - Define schema to represent a user's authorization to utilize > Internet services. > > Example service-specific schema elements include: > > - Define email service schema in support of SMTP, IMAP, POP, SIEVE, > MANAGESIEVE, etc. This would not be limited to just routing (as > LASER is), but also represent things such as the user's current > SIEVE script. > > The generalized elements would aide one in deploying multiple > different services using components provided by different vendors > (for instance an Isode email solution with an Apple calendaring > solution). The service-specific elements would aide one in > deploying within a single service, such as email, components from > different vendors (for instance, Sendmail incoming SMTP servers, > Postfix outing SMTP, Apple submission SMTP, and an Isode IMAP server). > > > --Apple-Mail-4--960174947 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin forwarded = message:

Date: January 18, 2008 11:33:45 AM = PST
To: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: Directory = Position
Here's a bit more...=A0 -- Kurt


LDAP = directory systems are in wide spread use as repositories for information = used in providing Internet services, including Email services (SMTP, = IMAP, POP, SIEVE, MANAGESIEVE), instant messaging and presence services = (XMPP, SIP), and calendaring and scheduling (CALDAV).=A0 Despite this wide spread use, = schema used in representing Internet service information is rarely = standardized.=A0 This = hinders interoperability.

To improve interoperability, the = IETF should engineer standards, where appropriate, of LDAP schema used = for representing information used in providing Internet services.=A0 This engineering would = include specification of generalized schema elements, such as for = representing Internet users and their credentials, and specification of = service-specific elements, such as representing objects in support of = Email services.

Example generalized schema elements = include:

- Define schema to represent a user of Internet = services.
- Define schema to represent a = user's authorization to utilize Internet services.

Example = service-specific schema elements include:

- Define = email service schema in support of SMTP, IMAP, POP, SIEVE, MANAGESIEVE, = etc.=A0 This would not be = limited to just routing (as LASER is), but also represent things such as = the user's current SIEVE script.

The generalized elements would = aide one in deploying multiple different services using components = provided by different vendors (for instance an Isode email solution with = an Apple calendaring solution). =A0 = The service-specific elements would aide one in deploying within = a single service, such as email, components from different vendors (for = instance, Sendmail incoming SMTP servers, Postfix outing SMTP, Apple = submission SMTP, and an Isode IMAP server).



=

= --Apple-Mail-4--960174947-- From discuss-bounces@apps.ietf.org Fri Jan 18 14:54:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFxIA-0004ZT-3U; Fri, 18 Jan 2008 14:54:18 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JFxI8-0004ZJ-Td for discuss-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 14:54:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFxI8-0004Z6-Js for discuss@apps.ietf.org; Fri, 18 Jan 2008 14:54:16 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFxI6-0003gd-FW for discuss@apps.ietf.org; Fri, 18 Jan 2008 14:54:16 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9DF9C142254 for ; Fri, 18 Jan 2008 11:54:16 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxiamsRuVsnz for ; Fri, 18 Jan 2008 11:54:10 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DF10F142203 for ; Fri, 18 Jan 2008 11:54:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) References: <9161E0244AEE1807CA22ECF7@p3.JCK.COM> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9576353B-8071-4258-8B68-FD27002D8C33@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: PP11: Internationalized Identifiers -- Taking Another Look Date: Fri, 18 Jan 2008 11:54:06 -0800 To: Apps Discuss X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Internationalized Identifiers -- Taking Another Look February 2008 Applications Area Architecture Workshop John C Klensin -- Working Draft, 20080107 ------------------------ I've been wrestling with questions of how we should really be looking at internationalization of applications-level identifiers for some years. Examining the questions in the context of internationalization and localization efforts seems to bring many of the issues into clearer focus. It has become clear to me, for reasons discussed below, that IRIs are not the answer to the set of problems that I, and most of the people who are worried about culturally-appropriate localization for end users, are concerned about. They may be the solution to some other set of problems but, if so, part of our job is to make that role clear. This note tries to summarize the issues and some of the requirements for a way forward. _ Problem Description _ People want, or believe they want, identifiers that can be expressed fully in their own language and script and in a way that is consistent with the associated culture. This is not just a matter of being able to use extended (i.e., beyond ASCII or Latin-1) character codings. If the culture is one in which any identifier that uses hierarchy (or nested categories) runs from largest category to smallest, then it is a reasonable expectation and possibly a requirement that localized identifiers run in the same direction. In the middle of the IDNA work, James Seng pointed out that, in most of Asia, a construction such as username at local-domain.bigger-domain.biggest-domain was quite foreign and that, independent of the character set used, the culturally-appropriate ordering would be (using a fairly arbitrary choice of delimiters): biggest-domain>bigger-domain>local-domain>>username or at least, if fully-qualified domain names could be construed, by habit, as atomic, as local-domain.bigger-domain.biggest-domain>>username Similar, and worse, issues arise with scripts whose natural directionality is from right to left. More on that below, in the more complicated case. In many quarters, expectations for IDNs are very high. When IDNA was finished in late 2002 and early 2003, many people assumed that widespread adoption of IDNs would follow quickly and would make it possible for people to use identifiers, pass them to others, and generally communicate with the Internet in their own languages. It didn't happen. Some of the reasons involved relatively slow deployment of supporting software in the web context and the need to do further work in the context of other protocols (such as the email i18n work now going on in the EAI WG). But a more fundamental reason (or excuse) was that domain names went from being ASCII-name.ASCII-name.ASCII-TLD-name to being Local-script-name.Local-script-name.ASCII-TLD-name The mixture didn't solve anyone's problem, at least as understood after some observation of user behavior. So, today, there is a lot of activity around ICANN (and elsewhere) about top-level IDNs. That discussion is mostly about politics and, where it is not, the technical issues are no longer considered applications matters, so this paper doesn't describe it further. However, it is fairly clear that even Local-script-name.Local-script-name.Local-script-name or, as often written, IDN.IDN.IDN will not solve the underlying problems either. There are two major reasons for this which bear directly on the problem at hand. (1) Users really don't use domain names. They use email addresses, URIs, or other pieces of syntax of which domain names are a part. There is a common assumption that one can just type IDN1.IDN2.IDN3 and have the application software (browser or whatever) magically turn it into http://IDN1.IDN2.IDN3/ Of course, that plan doesn't work for more than one protocol, or even for https versus http. Those who think it will are a little naive and it is very much in our interest, and that of the Internet, to figure out solutions before they notice. (2) The problem, however, gets worse because, at least in areas where the web and similar references are well-developed, the current trends are consistent with what almost everyone with real experience predicted starting 15 or more years ago: that we would move from attempts to make domain names identify resources to URLs, and then URIs, with longer and more complex tails. Put differently, we would move backward to using domain names to identify resources on the network (again) and forward to using the rest of the URI to identify the kinds of objects end users cared about, with the network resources providing context. Digression: Of course, there are another set of approaches in which the user-visible identifiers point to user-objects in some way that doesn't involve a reference to a host or equivalent resource, but those sorts of identifiers -- often known as "above DNS" -- are mostly outside the scope of this discussion except insofar as they use URI syntax. "Mostly" because such "above DNS" identifiers might be a complete alternate solution to the problems discussed here. But, so far, the marketplace hasn't been ready to take them seriously: we are still investing heavily (intellectually as well as financially) in domain names and URLs. So now, in many cases, we are looking at a URI that consists of a protocol identifier, some syntax, a domain name, some syntax, and a tail that contains a good deal of syntax as well. We can internationalize the domain names and present them, more or less, in local characters. We can internationalize the variable substrings of the tail and present them, again more or less, in local characters. When we have gotten through doing those things and applying a few very subtle rules (especially for right-to-left scripts), we have IRIs. Unfortunately, relative to the desire to see things in a linguistically and culturally-appropriate way, this just doesn't do it. We've still got ASCII protocol identifiers, and required ASCII pieces of syntax that differ from one protocol to another. As part of that syntax, the overall structure of the URI still runs from left to right. Even if one decides to localize the IRI by translating or transliterating the protocol identifier (the common practice in many parts of the world already) and transcoding the syntax bits into local characters (done sometimes, but much less common today), converting to and from URI format as things go out onto, and come in from, the wire, we are still in trouble once one leaves the web environment and, to some extent, while still in it. The problem is that there are enough variations on URI syntax -- variations that depend on knowledge of the protocol identifier and the properties of, and syntax required by, that protocol -- that one cannot tell, in the general case, what is a syntax element and what might be part of an identifier. That, in turn, means that one cannot write a general-purpose localization engine that does the right things for a particular language and culture. One has to, somehow, build an engine that knows about each protocol identifier and keep updating it as new protocol identifiers are added... a process that is sufficiently burdensome and error-prone as to be impractical and probably implausible. _A Pointer to a Solution_ We need to rethink the IRI as our primary internationalization tool in the light of the problem and target discussed above. Our goal should be a collection of data elements that are identified in a sufficiently clear way that it becomes possible to do a large part of the localization job algorithmically, without having to rely on either knowledge of the particular syntax associated with a given protocol identifier or on parsing heuristics that will mostly work. Ideally, we need to be able to identify an internationalized identifier in running text so that it can be localized. That, in turn, probably means that, for internationalized forms, we need to revisit the decision that URIs (or equivalent) can appear without unambiguous opening and ending delimiters. I'm not prepared to propose a syntax, but, to demonstrate that it is not impossible, note that it it clear that one could start with the general URI spec in RFC 3986, use it to create a list of data element and specific delimiter types, and then use an XML-based syntax to express a URI in tagged data element form (with the standard delimiters expressed as attribute values). From that form, one could perform transformations to a localized version of the XML form (e.g., using internationalized identifiers and local delimiters) and, from that, to a localized (no tag) identifier presentation form if desired (including those local delimiters and local ordering). Again, that may not be the only solution. But if we are going to preserve both * compatibility across the global Internet, with URIs in standard form, with standard protocol identifier names and standard delimiters, and * the ability to have presentation and information-entry forms that are localized to local cultures and needs, including the names and delimiters used, the ways in which data elements are presented and ordered, and so on, then we need to move beyond the IRI and its simple character-by-character, syntax-preserving, mapping to and from URIs. If we don't do it, we will certainly see local solutions that will make global interoperability and global references a thing of the past. From discuss-bounces@apps.ietf.org Fri Jan 18 14:55:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFxJU-0005Ag-3k; Fri, 18 Jan 2008 14:55:40 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JFxJT-000597-BP for discuss-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 14:55:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFxJT-00058x-1Q for discuss@apps.ietf.org; Fri, 18 Jan 2008 14:55:39 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFxJQ-0003t1-VX for discuss@apps.ietf.org; Fri, 18 Jan 2008 14:55:39 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 22FCC142217 for ; Fri, 18 Jan 2008 11:55:39 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsWq0pBYhMSk for ; Fri, 18 Jan 2008 11:55:32 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D9BA3142254 for ; Fri, 18 Jan 2008 11:55:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) To: Apps Discuss Message-Id: <3F090B94-3CD1-4ACD-998C-114490225696@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-7--959370904 References: <47833E67.3010507@it.su.se> From: Lisa Dusseault Subject: PP12: Identity Experiences from Open Metadir 2 Date: Fri, 18 Jan 2008 11:55:28 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -3.4 (---) X-Scan-Signature: 9ce0328cdf9c90e4680655d09dccace5 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-7--959370904 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: Leif Johansson > > Experiences from OM2 > > Abstract > > The OM2 (Open Metadir 2) project was initiated by Roland Hedberg and > Leif Johansson and started out as an attempt to build an open > framework > for identity provisioning at the campus and inter-campus level. By > drawing on our experiences of (and opinions about the limitations of) > LDAP and WS-* and drawing on RFC3254 for additional moral support we > are attempting a new spin on both the directory and the "SOA". > > This paper attempts to highlight some aspects of OM2 as input to the > applications area of the IETF. In many ways the OM2 tries to be a > good IETF citizen, utilizing as many "products" of the IETF as > possible. > > This document outlines OM2 (from 10' feet) with the intent to show > how the IETF has supplied "infrastructure" for the OM2 protocol. We > also try to show where that infrastructure (and the "products" of > other SDOs) was found lacking. > > 1. The OM2 vs WS-* > > OM2 is a message-oriented layered architecture where OWL-DL ontologies > play the role that XML-schema play in the WS-* architecture. OM2 > messages > are XML serializations of RDF graphs adhering the OM2 message > ontology. > The OM2 is transport neutral - any mechanism which can be used to > reliably send an XML message from between two endpoints can be used to > send OM2 messages. The OM2 has no concept of message routing. All > communication is point-to-point and security is provided by XML-DSIG > at the XML serialization layer. The OM2 uses a fire-and-forget > messaging > model with optional semantics for error handling and message ACKs. > > When devising OM2 we (at least in retrospect) identified some > limitations > of the current WS-* architecture which we attempted to rectify: > > * No coherent addressing scheme. Dealing with multiple transports in > WS-* presents a real challenge for application developers since > there > isn't even a coherent way to address services without implicitly > choosing a transport. The OM2 introduces a simple "RFC2822-like" > address which isn't tied to any one transport of OM2. > * The lack of a scalable service directory. Clearly UDDI will never > fulfill this promise. Instead the OM2 uses the DDDS to resolve OM2 > addresses to references to OM2 node metadata documents which are > RDF graphs adhering to the OM2 node ontology. These documents play > the role that WSDL/WS-Policy play in the WS-* architecture. > > On top of the OM2 message layer is the OM2 application layer - > corresponding to individual services in the WS-* architecture. The OM2 > application layers are also specified by OWL-DL ontologies and the > "body" > of an OM2 message contains (the XML serialization of) an RDF graph > which > adheres to one of these ontologies. > > 2. The OM2 vs LDAP > > The main application of OM2 (which after all is in its infancy > still) is > campus and inter-campus identity provisioning. This is a field with > lots > of commercial vendors aswell as OpenSource tools. Initially OM2 was > seen > as neutral technology with which to build gateways between vendor > systems > and protocols. The requirement to handle multiple vendors view of what > are suitable information- and operational models for identity > provisioning > was what initially lead us to consider OWL as the schema language - > OWL > has been shown to be semantically equivalent to UML2. > > There are important differences in the expressive power of XML schema > and OWL (and probably also ASN.1) which means that by using RDF and > OWL > there is less need to create simplified externalized information > models > which is what often happens when building SOAP-based RPCs - in essence > the information model used in the RPC layer is the same information > model > that is used in the system itself. This is a (overlooked?) property of > LDAP which even if it sometimes leads to confusion serves to simplify > the LDAP protocol. > > In spite of the simplicity of LDAP it has become common practice in > the campus and other enterprise settings to build the enterprise LDAP > directory from a separate data store, sometimes constructed from > one of > the many "identity management" products on the market. > > The technology used in this backend data store is typically a > relational > database possibly in combination with an ORM (Object Relational > Mapping) > mechanism used to provide an object oriented view to the data. The > LDAP > information model however is quite far removed from the relational > model > and surprisingly far from the object-oriented model too. > > The impedance mismatch between LDAP and these provisioning data stores > in our experience translate into high cost of changes in the > information > model, eg when a user data store needs to grow support for groups. > > On the other hand there are often (at least perceived) good reasons > for > having a separate provisioning data store. Some of those reasons are > probably related to some specific well-known limitations of LDAP: > > * Lack of referential integrity. > * Lack "complex" data types. > * Lack of meta data for associations1. > > These limitations are probably perceived as especially important since > they represent deviations from the expected behavior of object- > oriented > data-stores. > > In the OM2 project we initially tried to address these limitations > by trying to view a native RDF data store (aka "triple store") as a > generalization of a directory. By selecting the "right" ontologies for > the graphs stored in the RDF store it is easy to see how the LDAP tree > model could be represented in RDF/OWL. > > The real challenge however, is to define an operational model on > RDF stores which share (at least some of) the properties of the LDAP > protocol. This is where we used RFC3254 as a way to understand the > differences between the requirements and the implementation (LDAP). > > After working on several variations on the common CRUD operational > model > (Create Remove UPdate) we came up with the notion of the graph- > oriented > MIRO operation (Match Replace Insert Otherwize) which resembles a > generalized 'sed' operation operating on RDF graphs. This operation > seems > to have enough atomicity across related modifications to the graph to > share some important properties of LDAP operations. The MIRO operation > can easily support idempotency (op*op == op) which is important in > order > to achieve loose consistency in a distributed model. > > 3. Final thoughts and questions > > * Will the world ever be ready for a successor to LDAP? Do we > need one? > * Can a "SOA framework" grow out of the "IETF architecture"? Do > we care? > * Formal languages is a point of contentions in the IETF but is > still a commonly used tool. Why is this such a problem for the > IETF? > * Is this a problem of the IETF process or a factual problem or not > a problem at all? > * Can we concieve of a way to adress application endpoints that is > transport and protocol independent? Would that be at all useful? > > The OM2 identified and used a few key IETF technologies in several > parts of > the stack, notably: > > * Transports for XML-based messages - XMPP, HTTP > * Security for XML-based messages - XML-DSig > * Location of service endpoints - DDDS > > Is this the end? The OM2 is in many ways a fairly simple application > framework. Are these the only LEGO building blocks which could be > of use > by an application. Does this mean the applications area of the IETF is > done now? > --Apple-Mail-7--959370904 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin = forwarded message:

From: = Leif Johansson <leifj@it.su.se>

= Experiences from OM2

Abstract=A0

The OM2 (Open = Metadir 2) project was initiated by Roland Hedberg and=A0
Leif = Johansson and started out as an attempt to build an open framework=A0
for = identity provisioning at the campus and inter-campus level. By=A0
drawing = on our experiences of (and opinions about the limitations of)=A0
LDAP and = WS-* and drawing on RFC3254 for additional moral support we=A0
are = attempting a new spin on both the directory and the "SOA".

This = paper attempts to highlight some aspects of OM2 as input to the=A0
=A0
good = IETF citizen, utilizing as many "products" of the IETF as=A0
=A0

This = document outlines OM2 (from 10' feet) with the intent to show
how the IETF has supplied "infrastructure" for the = OM2 protocol. We
also try to show where that = infrastructure (and the "products" of
other = SDOs) was found lacking.

1. The OM2 vs WS-*=A0

OM2 is a = message-oriented layered architecture where OWL-DL ontologies=A0
play the = role that XML-schema play in the WS-* architecture. OM2 messages=A0
are XML = serializations of RDF graphs adhering the OM2 message ontology.=A0
The OM2 = is transport neutral - any mechanism which can be used to=A0
reliably = send an XML message from between two endpoints can be used to=A0
send OM2 = messages. The OM2 has no concept of message routing. All=A0
=A0
at the XML serialization layer. The OM2 uses a = fire-and-forget messaging=A0
model = with optional semantics for error handling and message ACKs.

When = devising OM2 we (at least in retrospect) identified some = limitations
of the current WS-* architecture = which we attempted to rectify:

=A0* No coherent addressing = scheme. Dealing with multiple transports in=A0
=A0=A0 WS-* presents a real = challenge for application developers since there=A0
=A0=A0 isn't even a coherent way = to address services without implicitly=A0
=A0=A0 choosing a transport. The = OM2 introduces a simple "RFC2822-like"=A0
=A0=A0 address which isn't tied = to any one transport of OM2. =A0
=A0* The lack of a scalable = service directory. Clearly UDDI will never=A0
=A0=A0 fulfill this promise. = Instead the OM2 uses the DDDS to resolve OM2=A0
=A0=A0 addresses to references to = OM2 node metadata documents which are=A0
=A0=A0 RDF graphs adhering to the = OM2 node ontology. These documents play=A0
=A0=A0 the role that = WSDL/WS-Policy play in the WS-* architecture. =A0

On top of the = OM2 message layer is the OM2 application layer -
corresponding to individual services in the WS-* = architecture. The OM2
application layers are also = specified by OWL-DL ontologies and the "body"
of an OM2 message contains (the XML serialization = of) an RDF graph which
adheres to one of these = ontologies.

2. The OM2 vs LDAP=A0

The main = application of OM2 (which after all is in its infancy still) is=A0
campus = and inter-campus identity provisioning. This is a field with lots=A0
of = commercial vendors aswell as OpenSource tools. Initially OM2 was = seen=A0
as neutral technology with which to build gateways = between vendor systems=A0
and = protocols. The requirement to handle multiple vendors view of what=A0
are = suitable information- and operational models for identity = provisioning=A0
was what initially lead us to consider OWL as the = schema language - OWL=A0
has been = shown to be semantically equivalent to UML2.

There = are important differences in the expressive power of XML = schema
and OWL (and probably also = ASN.1) which means that by using RDF and OWL
there is less need to create simplified externalized = information models
which is what often happens = when building SOAP-based RPCs - in essence
the = information model used in the RPC layer is the same information = model
that is used in the system = itself. This is a (overlooked?) property of
LDAP = which even if it sometimes leads to confusion serves to = simplify
the LDAP protocol.

In spite = of the simplicity of LDAP it has become common practice in
the campus and other enterprise settings to build = the enterprise LDAP
directory from a separate = data store, sometimes constructed from one of
the many "identity management" products on the = market.

The technology used in this backend data store is = typically a relational
database possibly in = combination with an ORM (Object Relational Mapping)
mechanism used to provide an object oriented view to = the data. The LDAP
information model however = is quite far removed from the relational model
and surprisingly far from the object-oriented model = too.

The impedance mismatch between LDAP and these = provisioning data stores
in our = experience translate into high cost of changes in the = information
model, eg when a user data store = needs to grow support for groups.

On the other hand there are = often (at least perceived) good reasons for
having = a separate provisioning data store. Some of those reasons are
probably related to some specific well-known = limitations of LDAP:
=A0 * Lack of referential = integrity.
=A0 * Lack "complex" data = types.
=A0 * Lack of meta data for = associations1.

These limitations are probably perceived as = especially important since
they = represent deviations from the expected behavior of = object-oriented
data-stores.

In the = OM2 project we initially tried to address these limitations
by trying to view a native RDF data store (aka = "triple store") as a
generalization of a = directory. By selecting the "right" ontologies for
the graphs stored in the RDF store it is easy to see = how the LDAP tree
model could be represented in = RDF/OWL.

The real challenge however, is to define an = operational model on
RDF stores which share (at = least some of) the properties of the LDAP
differences between the = requirements and the implementation (LDAP).

After working = on several variations on the common CRUD operational model
(Create Remove UPdate) we came up with the notion of = the graph-oriented
MIRO operation (Match = Replace Insert Otherwize) which resembles a
to have enough atomicity = across=A0 related = modifications to the graph to
share some = important properties of LDAP operations. The MIRO operation
can easily support idempotency (op*op =3D=3D op) = which is important in order
to achieve = loose consistency in a distributed model. =A0

3. Final = thoughts and questions=A0

=A0 * Will the world ever be = ready for a successor to LDAP? Do we need one?=A0
=A0 * Can a "SOA framework" grow = out of the "IETF architecture"? Do we care? =A0
=A0 * Formal languages is a point = of contentions in the IETF but is
=A0 =A0 still a commonly used = tool. Why is this such a problem for the IETF?
=A0 * = Is this a problem of the IETF process or a factual problem or not=A0
=A0 =A0 a problem at = all?
=A0 * Can we concieve of a way to = adress application endpoints that is
=A0 =A0 transport and protocol = independent? Would that be at all useful?

The OM2 = identified and used a few key IETF technologies in several parts = of
the stack, notably:

=A0 * Transports for XML-based = messages - XMPP, HTTP=A0
=A0 * Security for XML-based = messages - XML-DSig=A0
=A0 * Location of service = endpoints - DDDS

Is this the end? The OM2 is in many ways a fairly = simple application
framework. Are these the = only LEGO building blocks which could be of use
by an application. Does this mean the applications = area of the IETF is
done now?

=

= --Apple-Mail-7--959370904-- From discuss-bounces@apps.ietf.org Fri Jan 18 21:42:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG3em-0003Ia-Pm; Fri, 18 Jan 2008 21:42:04 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JG3em-0003IN-02 for discuss-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 21:42:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG3el-0003IF-3E for discuss@apps.ietf.org; Fri, 18 Jan 2008 21:42:03 -0500 Received: from boole.openldap.org ([2001:4f8:3:ba:2e0:18ff:fe02:efec]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JG3ek-0004tZ-NM for discuss@apps.ietf.org; Fri, 18 Jan 2008 21:42:03 -0500 Received: from [192.168.1.102] ([75.141.236.208]) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m0J2fsYF033712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 19 Jan 2008 02:41:59 GMT (envelope-from Kurt.Zeilenga@Isode.com) Message-Id: From: Kurt Zeilenga To: Apps Discuss In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: PP7: Server Identity Check Date: Fri, 18 Jan 2008 18:41:54 -0800 References: <476AD1C2.6010600@neustar.biz> X-Mailer: Apple Mail (2.915) X-Spam-Score: -1.4 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> >> Which apparently is either being referenced in various RFCs/I-Ds, >> or is being ignored in other various I-Ds/RFCs, who then re-invent >> their own version, or don't at all. RFC 2830 was obsoleted by RFC 4513. While RFC 4313 (in Section 3.1.3) retains the basic server identity checks described in RFC 2830, it does expand on server identity checks a bit. For instance, RFC 4513 discussions not only checks based upon DNS names, but also discussions checks based upon IP addresses and other subjectName types. The DNS name check specification also has been updated to discuss IDNA issues. >> >> Thus it has been suggested (by ChrisN to me, at Vancouver last >> month) to extract the above and make it into a BCP applicable to at >> least the apps area. >> >> So also from RFC2830, are sections.. >> >> ..or any of the other RFC2830 (sub)sections relevant for inclusion >> in this postulated BCP? I think Section 3.1.3 of RFC 4513 might serve as a better basis for postulating a generic "server identity check" BCP in this than Section 3.6 of RFC 2830. -- Kurt From discuss-bounces@apps.ietf.org Sat Jan 19 06:00:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGBR8-0006ig-DE; Sat, 19 Jan 2008 06:00:30 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JGBR7-0006ia-6F for discuss-confirm+ok@megatron.ietf.org; Sat, 19 Jan 2008 06:00:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGBR0-0006iR-EG for discuss@apps.ietf.org; Sat, 19 Jan 2008 06:00:22 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGBQx-0003zZ-Ox for discuss@apps.ietf.org; Sat, 19 Jan 2008 06:00:22 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JGBQt-0000DZ-Bd for discuss@apps.ietf.org; Sat, 19 Jan 2008 11:00:15 +0000 Received: from c-180-160-3.hh.dial.de.ignite.net ([62.180.160.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Jan 2008 11:00:15 +0000 Received: from nobody by c-180-160-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Jan 2008 11:00:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: "Frank Ellermann" Subject: Unicode-1-1 and UTF-7 (was: draft-klensin-net-utf8-07) Date: Sat, 19 Jan 2008 12:00:34 +0100 Organization: Lines: 50 Message-ID: References: <200801101801.TAA09710@TR-Sys.de> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-3.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Alfred H=CEnes wrote: Just an observation, hp-roman8 isn't registered, and apparently my MUA has no clue what it is, this might be a case where using the old RFC 1641 Unicode-1-1 could be "better" from my POV (you likely have reasons for your choice, if it's only your software you could trick it into using another charset in the address). > if we accept the draft to change protocols (or at least one, > Telnet), wouldn't it make sense to declare this draft to also > obsolete RFC 1641, (RFC 1642 -->) RFC 2152, and perhaps other > early IETF I18N documents as well? That's IMO not the job of net-utf8, it's not about updating the IANA charset registry, or deprecating (this version of) UTF-7. It is a good idea to do this, and I *think* that Mark Davis (one of the 1641-1642-2152 co-authors) and others also consider these charsets as obsolete or historic. But maybe not bad enough to post a "1641 + 2152 to historic" Internet draft with some IANA considerations about the charset registry. If you feel that it should be done now how about trying it ? In the worst case your draft doesn't make it, no harm done compared with the status quo. > In particular, the registrations for legacy representations of > Unicode should be marked "deprecated" in the IANA charset > registry; to this end, a substantive IANA Considerations > section needs to be added to the draft. AFAIK you can't "unregister" a registered charset, you can only update the registry entry with an updated source (that would be your draft). The source would need references to the old 2152 and 1641 definitions, because you don't want to change or copy the charset definitions, you want to say that the charsets are obsolete and the defining document historic. Users of the charset registry trying to find out what UTF-7 *is* still need to find the definition. I sometimes get UNICODE-1-1 delivery status notifications from old mailers, so it's not yet as dead as you might hope. =20 Check http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?dep=3D1641 and http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?dep=3D2152 to see if there are later standards with normative references to RFC 1641 or 2152, if yes this "decruft" procedure could be more ambitious than I think. Frank From discuss-bounces@apps.ietf.org Sun Jan 20 13:32:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGexa-0004iT-Ar; Sun, 20 Jan 2008 13:31:58 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JGexY-0004ek-OU for discuss-confirm+ok@megatron.ietf.org; Sun, 20 Jan 2008 13:31:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGexY-0004eb-EP for discuss@apps.ietf.org; Sun, 20 Jan 2008 13:31:56 -0500 Received: from hadron.switch.ch ([2001:620:0:4:203:baff:fe4c:d99b]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGexX-0001gs-Il for discuss@apps.ietf.org; Sun, 20 Jan 2008 13:31:56 -0500 Received: from hadron.switch.ch (localhost [IPv6:::1]) by hadron.switch.ch (8.14.0+Sun/8.14.0) with ESMTP id m0KIVrcj022107; Sun, 20 Jan 2008 19:31:53 +0100 (CET) Received: (from leinen@localhost) by hadron.switch.ch (8.14.0+Sun/8.14.0/Submit) id m0KIVqHi022106; Sun, 20 Jan 2008 19:31:52 +0100 (CET) X-Authentication-Warning: hadron.switch.ch: leinen set sender to simon.leinen@switch.ch using -f To: Rohan Mahy Subject: Re: PP8: Asynchronous change notification for HTTP-based resources X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: (Lisa Dusseault's message of "Fri, 18 Jan 2008 11:00:57 -0800") References: Date: Sun, 20 Jan 2008 19:31:52 +0100 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Asynchronous change notification for HTTP-based resources > Rohan Mahy [...] > Current practices in change notification involve polling individual > HTTP resources, or polling some kind of HTTP "catalog" resource to > see what resources have changed. Both of these methods inherently > suck. The "catalog" approach at least substantially reduces the > number of resources that need to be polled, but the amount of time > to wait between polls is always one-sided compromise and rarely > optimal for response time, network usage, and battery life. FYI, there are a few interesting techniques to make server-to-client notifications over HTTP more efficient. The buzzword for this is "Comet", and the Wikipedia article has good descriptions on some of these techniques, e.g. "long polling": http://en.wikipedia.org/wiki/Comet_(programming) -- Simon. From discuss-bounces@apps.ietf.org Mon Jan 21 10:59:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGz3L-00089q-GH; Mon, 21 Jan 2008 10:59:15 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JGz3K-00089l-Bg for discuss-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 10:59:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGz3K-00089d-1e for discuss@apps.ietf.org; Mon, 21 Jan 2008 10:59:14 -0500 Received: from dizzyd.com ([207.210.219.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGz3J-0001o0-EJ for discuss@apps.ietf.org; Mon, 21 Jan 2008 10:59:14 -0500 Received: from wrk225.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTP id ED86940498; Mon, 21 Jan 2008 08:59:07 -0700 (MST) Message-ID: <4794C13E.902@stpeter.im> Date: Mon, 21 Jan 2008 08:58:54 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Simon Leinen Subject: Re: PP8: Asynchronous change notification for HTTP-based resources References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070702080000020108050300" X-Spam-Score: -0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: Rohan Mahy , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is a cryptographically signed message in MIME format. --------------ms070702080000020108050300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Simon Leinen wrote: >> Asynchronous change notification for HTTP-based resources >> Rohan Mahy > [...] >> Current practices in change notification involve polling individual >> HTTP resources, or polling some kind of HTTP "catalog" resource to >> see what resources have changed. Both of these methods inherently >> suck. The "catalog" approach at least substantially reduces the >> number of resources that need to be polled, but the amount of time >> to wait between polls is always one-sided compromise and rarely >> optimal for response time, network usage, and battery life. > > FYI, there are a few interesting techniques to make server-to-client > notifications over HTTP more efficient. The buzzword for this is > "Comet", and the Wikipedia article has good descriptions on some of > these techniques, e.g. "long polling": > > http://en.wikipedia.org/wiki/Comet_(programming) In the XMPP community we have developed a technology called BOSH, which has some similarities to the Comet approach. BOSH was originally developed as a method for XMPP servers to offer an HTTP transport for XMPP traffic instead of the TCP transport defined in RFC 3920, but we have generalized it so that it is no longer specific to XMPP: http://www.xmpp.org/extensions/xep-0124.html We've talked about contributing this to the Internet Standards Process but haven't gotten around to it yet... Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms070702080000020108050300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+ JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE 9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0 ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/ yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA 75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna 1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf 5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0 dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1 My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODAxMjExNTU4NTRaMCMGCSqG SIb3DQEJBDEWBBS/cIf1ZRMdRYLQpjByZVHniHoefDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC AQCwlk8LARyJRnpnPcl/YFA4bVI6PjslvKdoZJqBKO5cY2yzyLYwwTKgx11FawVhTTBKQP5d veenzwkp7sw36Vpc5Cq2neImCe/dTKWH0gj01YThN6UOtKkA57mT95W+8DfkaAWVFx14lxxG sakpHfhx/alqLGQHDTStxvjjP/Yux2MNoqQi0rdw5o1FAZjHg+mnwLQctnBh4bw9ReH2Q5qM ZcZQrZR7/BEObutTwGrbsdk5X/Aus9MTPtN3JPAudfExqxMAZ93lzHIdZfZjnmD2UFAa7XME Tvsj4ZDaMwf6d7RzNgwB8RAL2uOv7rtXlLLyD4FtixqIgw07DLNfv3evAAAAAAAA --------------ms070702080000020108050300-- From discuss-bounces@apps.ietf.org Wed Jan 23 01:57:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHZXx-0002M7-NH; Wed, 23 Jan 2008 01:57:17 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JHZXw-0002LR-CQ for discuss-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 01:57:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHZXv-0002LE-Qz for discuss@apps.ietf.org; Wed, 23 Jan 2008 01:57:15 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHZXu-0004Q8-BO for discuss@apps.ietf.org; Wed, 23 Jan 2008 01:57:15 -0500 X-IronPort-AV: E=Sophos;i="4.25,236,1199682000"; d="scan'208,217";a="94188670" Received: from 5.6.8.135.in-addr.arpa (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 23 Jan 2008 01:57:09 -0500 X-IronPort-AV: E=Sophos;i="4.25,236,1199682000"; d="scan'208,217";a="145567747" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 23 Jan 2008 01:57:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85D8D.24C66066" Subject: FW: Invitation: Joint XML Guidelines Discussion (20080205) - Update Date: Wed, 23 Jan 2008 07:56:56 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Invitation: Joint XML Guidelines Discussion (20080205) - Update Thread-Index: AchUS0dt7/yNFsMLTr+3YjNYjOcZZgIfbjRAADDvPsA= From: "Romascanu, Dan (Dan)" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 031b5f42d6d2cd097710e6b68613cb36 Cc: Bert Wijnen X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C85D8D.24C66066 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is the final invitation for the Joint XML Guidelines call organized by the ITU-T NGN Management Focus Group. The date of the call was set for 2/5. It would be good I think if somebody from the APPS area and/or XML Directorate could join.=20 =20 Dan =20 =20 =20 =20 ________________________________ From: Nigel Davis [mailto:nigeld@nortel.com]=20 Sent: Tuesday, January 22, 2008 10:12 AM To: Dave Sidor; *Mak, Leen; *Toche, Christian; Marie Divialle; *Johannessen, Knut; *Fujii, Nobuo; *Kurakova, Tatiana; *Burkett, Debbie; *Caruso, Francesco; *Garbanati, Linda; Frode Nergard; *Geipl, Michael; *Caryer, Geoff; *Zoicas, Adrian; *Huang, Shuqiang; *Wang, Zhili; Amit Kleinmann; Tang, Yong-Ping (TSG-GDCC-SH); Jerome Magnet; Marc.Flauw@hp.com; Vincent Perrot; Richard Craddock (rcraddoc); Ramanathan.Krishnamurthy@iona.com; *Caruso, Francesco; *Burkett, Debbie; Frode Nergard; dkaplan@telcordia.com; Steve.Edwards@qwest.com; *Kurakova, Tatiana; Carl Larson; yreigle@atis.org; Fargano, Michael; GARBANATI Linda; *Yoshida, Tatsuhiko; Bert Wijnen (ITU); Romascanu, Dan (Dan); Thomas Tovinger; Phil Shafer Cc: Ian Best; *Ronco, Enrico; Fratini, Stephen Subject: Invitation: Joint XML Guidelines Discussion (20080205) - Update Hi all,=20 This follows on from the email invitation I sent 2008-01-11. At that point I had suggested an alternative to the original date proposed at the meeting that initiated this call. As a consequence of various email exchanges I have decided to keep to the original date (Tuesday 5th February 2008 as detailed below). I have extended the invitation to several others who have shown interest in attending since the initial invitation. If you think I have missed someone interested in attending that you are aware please do not hesitate to forward this mail (copying me so I can get a view of numbers). DaveS: Again I would be grateful if you would forward this as appropriate to enable the NGNMFG community to participate. Titania: I would be grateful if you could arrange a room for this call as requested by Dave Sidor.=20 The following is extracted from the original mail:=20 Introduction=20 As discussed and agreed at the "Joint Conference Call on Methodology between ITU-T SG4, 3GPP SA5, TISPAN WG8, TMF mTOP and ATIS TMOC" held 2007-12-12, I am calling a meeting to discuss "XML guidelines" and to potentially initiate combined work (study etc) in the area of generation and refinement of XML guidelines and definitions for application to management system interfaces. Agenda=20 * Introductions=20 * IPR declaration=20 * Brief overview of purpose=20 * Some initial considerations=20 * Next steps=20 * AOB=20 =09 Meeting Logistics=20 * Date:=20 * Tuesday 5th February=20 * Time:=20 * 13:00 GMT - 15:00 GMT=20 * Local time conversion: http://www.timeanddate.com/worldclock/fixedtime.html?day=3D5&month=3D2&ye= ar=3D 2008&hour=3D13&min=3D0&sec=3D0&p1=3D0 =20 * Phone Access Details:=20 * Number:=20 * +1-972-684-5262 (US)=20 * +44-162-843-5262 (UK)=20 * +33-16-955-2262 (France)=20 * +49-696-697-1262 (Germany)=20 * +39-065-152-9162 (Italy)=20 * +34-91-709-4762 (Spain)=20 * +61-2-6279-7721 (Australia (Canberra))=20 * 6-427-5262 (Nortel)=20 * Access code: 59781#=20 * Webmeeting Access Details=20 * https://www.gotomeeting.com/join/146470527 =20 * Meeting ID: 146-470-527=20 =09 I may need to change the Webmeeting access but will inform you by mail before the meeting.=20 If you have any comments on the above please do not hesitate to contact me by return of mail or by phone (as below).=20 Thanks=20 Nigel Davis=20 Nortel=20 Desk/ip/vm : +44-1279-403978 (ESN 742-3978) Mobile/vm : +44-7740-670288 (ESN 748-0288) Fax : +44-1279-405904 (ESN 742-5904)=20 London Road Harlow, Essex CM17 9NA United Kingdom=20 Confidentiality Notice: This message and any attachments may contain information that is privileged and confidential. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender immediately by reply email and destroy all copies of the original message. _____________________________________________=20 This email was protected during delivery to Avaya with TLS encryption ------_=_NextPart_001_01C85D8D.24C66066 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Invitation: Joint XML Guidelines Discussion = (20080205) - Update
This is the final invitation for the Joint = XML=20 Guidelines call organized by the ITU-T NGN Management Focus Group. The = date of=20 the call was set for 2/5. It would be good I think if somebody from = the=20 APPS area and/or XML Directorate could join. =
 
Dan
 
 
 
 

From: Nigel Davis = [mailto:nigeld@nortel.com]=20
Sent: Tuesday, January 22, 2008 10:12 AM
To: Dave = Sidor;=20 *Mak, Leen; *Toche, Christian; Marie Divialle; *Johannessen, Knut; = *Fujii,=20 Nobuo; *Kurakova, Tatiana; *Burkett, Debbie; *Caruso, Francesco; = *Garbanati,=20 Linda; Frode Nergard; *Geipl, Michael; *Caryer, Geoff; *Zoicas, Adrian; = *Huang,=20 Shuqiang; *Wang, Zhili; Amit Kleinmann; Tang, Yong-Ping (TSG-GDCC-SH); = Jerome=20 Magnet; Marc.Flauw@hp.com; Vincent Perrot; Richard Craddock (rcraddoc);=20 Ramanathan.Krishnamurthy@iona.com; *Caruso, Francesco; *Burkett, Debbie; = Frode=20 Nergard; dkaplan@telcordia.com; Steve.Edwards@qwest.com; *Kurakova, = Tatiana;=20 Carl Larson; yreigle@atis.org; Fargano, Michael; GARBANATI Linda; = *Yoshida,=20 Tatsuhiko; Bert Wijnen (ITU); Romascanu, Dan (Dan); Thomas Tovinger; = Phil=20 Shafer
Cc: Ian Best; *Ronco, Enrico; Fratini,=20 Stephen
Subject: Invitation: Joint XML Guidelines Discussion=20 (20080205) - Update

Hi = all,=20

This = follows on from=20 the email invitation I sent 2008-01-11. At that point I had suggested an = alternative to the original date proposed at the meeting that initiated = this=20 call. As a consequence of various email exchanges I have decided to keep = to the=20 original date (Tuesday 5th February 2008 as detailed below). I have = extended the=20 invitation to several others who have shown interest in attending since = the=20 initial invitation. If you think I have missed someone interested in = attending=20 that you are aware please do not hesitate to forward this mail (copying = me so I=20 can get a view of numbers).

DaveS: = Again I would=20 be grateful if you would forward this as appropriate to enable the = NGNMFG=20 community to participate.

Titania: I would be=20 grateful if you could arrange a room for this call as requested by Dave=20 Sidor.

The = following is=20 extracted from the original mail:

Introduction=20
As discussed and = agreed at the=20 "Joint Conference Call on Methodology between ITU-T SG4, 3GPP SA5, = TISPAN WG8,=20 TMF mTOP and ATIS TMOC" held 2007-12-12,  I am calling a meeting to = discuss=20 "XML guidelines" and to potentially initiate combined work (study etc) = in the=20 area of generation and refinement of XML guidelines and definitions for=20 application to management system interfaces.

Agenda=20

  • Introductions=20
  • IPR = declaration=20
  • Brief overview of=20 purpose=20
  • Some initial=20 considerations=20
  • Next = steps=20
  • AOB =

Meeting=20 Logistics=20

  • Date: =
    • Tuesday 5th=20 February
  • Time: =
    • 13:00 GMT - 15:00 = GMT=20
    • Local time = conversion:=20 http://www.timeanddate.com/worldclock/fixedtime.html?day=3D5&= ;month=3D2&year=3D2008&hour=3D13&min=3D0&sec=3D0&p1=3D= 0
  • Phone Access=20 Details:=20
    • Number: =
      • +1-972-684-5262 = (US)=20
      • +44-162-843-5262=20 (UK)=20
      • +33-16-955-2262 = (France)=20
      • +49-696-697-1262=20 (Germany)=20
      • +39-065-152-9162=20 (Italy)=20
      • +34-91-709-4762 = (Spain)=20
      • +61-2-6279-7721 = (Australia=20 (Canberra))=20
      • 6-427-5262=20 (Nortel)
    • Access code: = 59781#=20
  • Webmeeting Access=20 Details=20
    • https://www.gotomeeting.com/join/146470527=
    • Meeting ID: = 146-470-527=20

I may need to change = the Webmeeting=20 access but will inform you by mail before the meeting. =

If you have any = comments on the=20 above please do not hesitate to contact me by return of mail or by phone = (as=20 below).

Thanks =

Nigel Davis =
Nortel
Desk/ip/vm : +44-1279-403978 = (ESN=20 742-3978)
Mobile/vm   : +44-7740-670288 (ESN = 748-0288)
Fax          &= nbsp;   =20 : +44-1279-405904 (ESN 742-5904)=20
London = Road
Harlow, = Essex
CM17 = 9NA
United = Kingdom
Confidentiality Notice: This message and any attachments may = contain=20 information that is privileged and confidential. If you have reason to = believe=20 that you are not the intended recipient or a person responsible for = delivering=20 this message to an intended recipient, you are hereby notified that any = review,=20 dissemination, distribution, or copying of this message is strictly = prohibited.=20 If you have reason to believe that you are not the intended recipient or = a=20 person responsible for delivering this message to an intended recipient, = please=20 contact the sender immediately by reply email and destroy all copies of = the=20 original message.

=20


_____________________________________________ = 

This email was protected during delivery to Avaya =
with TLS encryption
------_=_NextPart_001_01C85D8D.24C66066-- From discuss-bounces@apps.ietf.org Wed Jan 23 05:45:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHd6P-00052W-IU; Wed, 23 Jan 2008 05:45:05 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JHd6O-00052O-C1 for discuss-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 05:45:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHd6O-00052G-22 for discuss@apps.ietf.org; Wed, 23 Jan 2008 05:45:04 -0500 Received: from mk-outboundfilter-1.mail.uk.tiscali.com ([212.74.114.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHd6L-0002nS-UO for discuss@apps.ietf.org; Wed, 23 Jan 2008 05:45:04 -0500 X-Trace: 24928003/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.163.7 X-SBRS: None X-RemoteIP: 62.241.163.7 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJCplkc+8aMH/2dsb2JhbACtWA X-IP-Direction: IN Received: from blaster.systems.pipex.net ([62.241.163.7]) by smtp.pipex.tiscali.co.uk with ESMTP; 23 Jan 2008 10:44:59 +0000 Received: from pc6 (1Cust217.tnt10.lnd4.gbr.da.uu.net [62.188.139.217]) by blaster.systems.pipex.net (Postfix) with SMTP id AEE40E0000A6; Wed, 23 Jan 2008 10:44:53 +0000 (GMT) Message-ID: <051e01c85da4$5f7ff460$0601a8c0@pc6> From: "tom.petch" To: "Romascanu, Dan (Dan)" , References: Subject: Re: Invitation: Joint XML Guidelines Discussion (20080205) - Update Date: Wed, 23 Jan 2008 10:27:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Having read this announcement several times, I still wonder what it is announcing. A physical meeting? A physical meeting plus conference call? A conference call? A video conference? The reason it catches my attention is the London UK address, and meetings this side of the pond being relatively rare, and the cost of crossing the pond being a barrier, I take an interest in any addresses on this side. And perhaps also because I have strong views about the desperate need that XML has for an RFC 4181. Tom Petch ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: ; Cc: "Bert Wijnen" Sent: Wednesday, January 23, 2008 7:56 AM Subject: FW: Invitation: Joint XML Guidelines Discussion (20080205) - Update This is the final invitation for the Joint XML Guidelines call organized by the ITU-T NGN Management Focus Group. The date of the call was set for 2/5. It would be good I think if somebody from the APPS area and/or XML Directorate could join. Dan ________________________________ From: Nigel Davis [mailto:nigeld@nortel.com] Sent: Tuesday, January 22, 2008 10:12 AM To: Dave Sidor; *Mak, Leen; *Toche, Christian; Marie Divialle; *Johannessen, Knut; *Fujii, Nobuo; *Kurakova, Tatiana; *Burkett, Debbie; *Caruso, Francesco; *Garbanati, Linda; Frode Nergard; *Geipl, Michael; *Caryer, Geoff; *Zoicas, Adrian; *Huang, Shuqiang; *Wang, Zhili; Amit Kleinmann; Tang, Yong-Ping (TSG-GDCC-SH); Jerome Magnet; Marc.Flauw@hp.com; Vincent Perrot; Richard Craddock (rcraddoc); Ramanathan.Krishnamurthy@iona.com; *Caruso, Francesco; *Burkett, Debbie; Frode Nergard; dkaplan@telcordia.com; Steve.Edwards@qwest.com; *Kurakova, Tatiana; Carl Larson; yreigle@atis.org; Fargano, Michael; GARBANATI Linda; *Yoshida, Tatsuhiko; Bert Wijnen (ITU); Romascanu, Dan (Dan); Thomas Tovinger; Phil Shafer Cc: Ian Best; *Ronco, Enrico; Fratini, Stephen Subject: Invitation: Joint XML Guidelines Discussion (20080205) - Update Hi all, This follows on from the email invitation I sent 2008-01-11. At that point I had suggested an alternative to the original date proposed at the meeting that initiated this call. As a consequence of various email exchanges I have decided to keep to the original date (Tuesday 5th February 2008 as detailed below). I have extended the invitation to several others who have shown interest in attending since the initial invitation. If you think I have missed someone interested in attending that you are aware please do not hesitate to forward this mail (copying me so I can get a view of numbers). DaveS: Again I would be grateful if you would forward this as appropriate to enable the NGNMFG community to participate. Titania: I would be grateful if you could arrange a room for this call as requested by Dave Sidor. The following is extracted from the original mail: Introduction As discussed and agreed at the "Joint Conference Call on Methodology between ITU-T SG4, 3GPP SA5, TISPAN WG8, TMF mTOP and ATIS TMOC" held 2007-12-12, I am calling a meeting to discuss "XML guidelines" and to potentially initiate combined work (study etc) in the area of generation and refinement of XML guidelines and definitions for application to management system interfaces. Agenda * Introductions * IPR declaration * Brief overview of purpose * Some initial considerations * Next steps * AOB Meeting Logistics * Date: * Tuesday 5th February * Time: * 13:00 GMT - 15:00 GMT * Local time conversion: http://www.timeanddate.com/worldclock/fixedtime.html?day=5&month=2&year= 2008&hour=13&min=0&sec=0&p1=0 * Phone Access Details: * Number: * +1-972-684-5262 (US) * +44-162-843-5262 (UK) * +33-16-955-2262 (France) * +49-696-697-1262 (Germany) * +39-065-152-9162 (Italy) * +34-91-709-4762 (Spain) * +61-2-6279-7721 (Australia (Canberra)) * 6-427-5262 (Nortel) * Access code: 59781# * Webmeeting Access Details * https://www.gotomeeting.com/join/146470527 * Meeting ID: 146-470-527 I may need to change the Webmeeting access but will inform you by mail before the meeting. If you have any comments on the above please do not hesitate to contact me by return of mail or by phone (as below). Thanks Nigel Davis Nortel Desk/ip/vm : +44-1279-403978 (ESN 742-3978) Mobile/vm : +44-7740-670288 (ESN 748-0288) Fax : +44-1279-405904 (ESN 742-5904) London Road Harlow, Essex CM17 9NA United Kingdom Confidentiality Notice: This message and any attachments may contain information that is privileged and confidential. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender immediately by reply email and destroy all copies of the original message. _____________________________________________ This email was protected during delivery to Avaya with TLS encryption From discuss-bounces@apps.ietf.org Thu Jan 24 08:22:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI22N-00075y-Cd; Thu, 24 Jan 2008 08:22:35 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JI22M-00075t-IW for discuss-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 08:22:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI22L-00075l-Cq for discuss@apps.ietf.org; Thu, 24 Jan 2008 08:22:34 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JI22L-0004Fl-44 for discuss@apps.ietf.org; Thu, 24 Jan 2008 08:22:33 -0500 Received: (qmail invoked by alias); 24 Jan 2008 13:22:31 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp030) with SMTP; 24 Jan 2008 14:22:31 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+qFE1vIqGqqFvQS8U40A0i7hOEhQbzPrzhHLM0ER 00lHOoJy82HYZ3 Message-ID: <47989114.7050808@gmx.de> Date: Thu, 24 Jan 2008 14:22:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Apps Discuss Subject: Status of RFC4234bis (RFC5234) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi, I notice that RFC4234bis has been in state AUTH48 for over a month now. Does anybody know what's going on? Curious, Julian From discuss-bounces@apps.ietf.org Thu Jan 24 10:39:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI4BG-0002cw-7K; Thu, 24 Jan 2008 10:39:54 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JI4BF-0002co-OQ for discuss-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 10:39:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI4BF-0002cZ-EI for discuss@apps.ietf.org; Thu, 24 Jan 2008 10:39:53 -0500 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI4BD-0007pO-Qk for discuss@apps.ietf.org; Thu, 24 Jan 2008 10:39:53 -0500 Received: from [192.168.0.3] (ppp-68-122-72-83.dsl.pltn13.pacbell.net [68.122.72.83]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m0OFdDDN027985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jan 2008 07:39:14 -0800 Message-ID: <4798B142.8020806@dcrocker.net> Date: Thu, 24 Jan 2008 07:39:46 -0800 From: Dave Crocker User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Julian Reschke Subject: Re: Status of RFC4234bis (RFC5234) References: <47989114.7050808@gmx.de> In-Reply-To: <47989114.7050808@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Julian Reschke wrote: > I notice that RFC4234bis has been in state AUTH48 for over a month now. > Does anybody know what's going on? sent in what i hope will be a final tweak a week and a half ago. i had missed some hanging references. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Thu Jan 24 19:37:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JICZW-000138-0j; Thu, 24 Jan 2008 19:37:30 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JICZU-0000wT-V8 for discuss-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 19:37:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JICZU-0000tI-IJ for discuss@apps.ietf.org; Thu, 24 Jan 2008 19:37:28 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JICZS-0005mL-Gu for discuss@apps.ietf.org; Thu, 24 Jan 2008 19:37:28 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0P0bPI5027715 for ; Fri, 25 Jan 2008 00:37:26 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JV600M01C8JRM00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Thu, 24 Jan 2008 17:37:25 -0700 (MST) Received: from nifty-silver.stc.com ([129.150.18.42]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JV6007I6CE728A0@mail-amer.sun.com>; Thu, 24 Jan 2008 17:37:22 -0700 (MST) Date: Thu, 24 Jan 2008 16:37:25 -0800 From: Chris Newman Subject: Re: draft-klensin-net-utf8-07 In-reply-to: <200801101801.TAA09710@TR-Sys.de> To: Alfred H?nes , john-ietf@jck.com, the.map@alum.mit.edu Message-id: MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200801101801.TAA09710@TR-Sys.de> X-Spam-Score: -1.0 (-) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Alfred H?nes wrote on 1/10/08 19:01 +0100: > RFC 1641, (RFC 1642 -->) RFC 2152, > and perhaps other early IETF I18N documents as well? > > In particular, the registrations for legacy representations of > Unicode should be marked "deprecated" in the IANA charset registry; > to this end, a substantive IANA Considerations section needs to be > added to the draft. I think these would distract from the primary focus of net-utf8. However, they are good proposals and if you wrote them up in a separate document, it's very likely you could find a friendly area director to sponsor them ;-) - Chris From discuss-bounces@apps.ietf.org Fri Jan 25 05:43:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIM1N-0006Wq-4F; Fri, 25 Jan 2008 05:42:53 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JIM1L-0006Wk-Kn for discuss-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 05:42:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIM1L-0006Wc-At for discuss@apps.ietf.org; Fri, 25 Jan 2008 05:42:51 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIM1J-0002Xp-OV for discuss@apps.ietf.org; Fri, 25 Jan 2008 05:42:51 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JIM1I-0006We-8b for discuss@apps.ietf.org; Fri, 25 Jan 2008 10:42:48 +0000 Received: from c-134-88-207.hh.dial.de.ignite.net ([62.134.88.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jan 2008 10:42:48 +0000 Received: from nobody by c-134-88-207.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jan 2008 10:42:48 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: "Frank Ellermann" Subject: Re: draft-klensin-net-utf8-07 Date: Fri, 25 Jan 2008 11:43:04 +0100 Organization: Lines: 11 Message-ID: References: <200801101801.TAA09710@TR-Sys.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-207.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Chris Newman wrote: > good proposals and if you wrote them up in a separate document, it's > very likely you could find a friendly area director to sponsor them = ;-) The 2616bis folks, friendly or otherwise, could then reference it, the "HTML5" cabale could also make use of it. At the moment it is not clear whose "fault" UTF-7 is, but they do want to get rid of it. Frank From discuss-bounces@apps.ietf.org Sun Jan 27 14:51:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJDXY-0008Hi-RS; Sun, 27 Jan 2008 14:51:40 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JJDXX-0008G9-8G for discuss-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 14:51:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJDXW-0008F5-UG for discuss@apps.ietf.org; Sun, 27 Jan 2008 14:51:38 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJDXU-00045j-2z for discuss@apps.ietf.org; Sun, 27 Jan 2008 14:51:38 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7366D142217 for ; Sun, 27 Jan 2008 11:51:36 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MD+6ITSZdxIP for ; Sun, 27 Jan 2008 11:51:29 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D62E8142203 for ; Sun, 27 Jan 2008 11:51:28 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) To: Apps Discuss Message-Id: <18F9E6E9-2AD4-4491-BEFD-FCEBCF62FB7D@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-10--182015883 References: From: Lisa Dusseault Subject: PP13: Toward a Simpler Message Access Architecture Date: Sun, 27 Jan 2008 11:51:23 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-10--182015883 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: Pete Resnick > > Toward a Simpler Message Access Architecture > > The architecture for the transport of mail messages embodies a core > principle: Messages move through the Internet simply, without > examination or transformation of their contents, and that they are > transported according to envelope information that is separate from > the contents. The Simple Mail Transfer Protocol (SMTP) and its > implementations live up to this principle to greater or lesser > degrees, but this is certainly the ideal that we strive for, and we > use it as a benchmark for SMTP design and extension. In addition, > when it comes to the contents of messages, the Internet Message > Format (IMF) and Multipurpose Internet Mail Extensions (MIME) have > a canonical format that is specifically independent of any > particular storage or user interface constraints. Again, > implementations keep storage and user interface constraints from > appearing to differing degrees, but we still strive toward this > platform independence in implementation and protocol development. > However, the structure has given us the ability to have relatively > complex messages (sometimes with a great deal of structure and > representing all sorts of complex data types) transported in a > relatively simple fashion. This architecture lends itself to > relatively simple implementation for both clients and servers: > Clients prepare the message object (however complex) and the > envelope, convert the message from any local conventions to > canonical format, and transmit the message using the independent > envelope information. End-to-end, the transport is relatively simple. > > In contrast to message transport, message access has not fared as > well in these regards. The only two message access protocols we > have, the Post Office Protocol (POP) and the Internet Message > Access Protocol (IMAP), sit at opposite ends of a spectrum with > regard to simplicity of implementation and operation, ability to > deal with complexity in message structures, and platform > independence. Of course, with regard to simplicity of > implementation and operation, POP shines: For a client to simply > connect to a server and download messages in their entirety, POP is > very straightforward. However, this simplicity pushes a great deal > of complexity and some computing horsepower requirements from > servers onto clients. Clients must have enough bandwidth to get > messages, enough local storage to manipulate and interpret the > messages they have downloaded, and enough compute power to locally > parse through complex message structures. In this time of smaller > client devices with less compute, bandwidth, and storage, this > makes POP use problematic. Of course, assorted extensions have been > added to POP to facilitate use by smaller devices, but they are > generally ad-hoc specialized extensions that do not address more > general issues for lower capability clients. > > IMAP on the other hand does not suffer POP's problems. IMAP servers > parse the structure of messages for the client and present only > those parts (or parts of parts) that the client requests. Recent > extensions have made access to and manipulation of message parts > even easier for lower capability clients. There is, of course, an > increase in protocol complexity in IMAP as compared to POP. Some of > that is counter-balanced by the fact that the client does not have > to do much of the parsing work locally, but can instead rely on the > server to do so. However, IMAP's central shortcoming, due to a > design principle that was necessary at the time of its creation, is > that clients have to deal with a great deal of complexity because > IMAP exposes much of the semantics of the server's local > environment to the client. IMAP was designed such that protocol > constructs map relatively easily to extant servers' message storage > models. (It should be noted that failure to have this design > principle at the time would have resulted in an undeployable > protocol.) The result is a protocol where messages are stored > grouped in mailboxes (which paralleled existing implementations' > file storage structure), much of the ancillary data associated with > messages is stored in the mailboxes themselves (requiring a small > set of data), and operations may be either synchronous or > asynchronous in nature depending on the particular operation. These > design choices introduce interesting and unexpected implementation > complexities on clients. IMAP's support of a hierarchical store of > messages (as against POP, which has a single flat spool of > messages) means that even if a client only wants to present a > simple one-dimensional view of messages, it still must support > IMAP's hierarchical store in order to discover all of the messages > on the server. In particular, in order to discover changes to the > mail store, clients must SELECT those mailboxes in which the client > has interest and can not get information about changes to arbitrary > parts of the store. With regard to the data storage model, clients > that perform operations outside of IMAP's architectural model that > might need to store and retrieve ancillary data with messages to > support those operations (for instance, a particular messages > display size and screen positioning) must either rely on the server > to implement such functionality (which is not a requirement for > servers) or must store that information locally (which is > infeasible for some clients). Finally, the mixture of synchronous > and asynchronous operation sometimes makes for tricky > implementation choices. Of course, there are the well-understood > examples of certain command sequences that cannot run concurrently, > but restrictions on untagged EXPUNGE responses also make > implementation difficult. > > Server technology has come a long way in the past 20 years. In > particular, scalable multiple-access database storage > implementations are now widely available and in use. Not only does > this mean that arbitrary data can be easily stored and retrieved > (including by multiple simultaneous users), but it also means that > hierarchical file structure needn't be maintained by the > application in order to obtain decent performance. Use of such a > system as a backend for a message access protocol simplifies design > significantly and greatly aids flexibility. I suggest that a new > message access architecture could maintain all of the advantages > that IMAP has over POP, yet remove some of the difficulties > associated with reflection of underlying design constraints in > protocol considerations. > > What follows is a rough outline of such an architecture. It maps > onto current technologies in such a way that transition to the > architecture would be more straightforward, sometimes at the > expense of simplicity. (Consider this a target at which to shoot > rather than a fully-fleshed out solution. In particular, neither > access control nor end-to-end security issues are discussed in this > proposal.) > > 1. A message access store will contain three sorts of objects: > message objects, multipart objects, and terminal objects. All > objects have attributes. The objects are comprised as follows: > a. Message objects must contain one multipart or one terminal > object. Each message must have a "unique identifier" attribute > which is unique within the message store. A message will normally > also have a series of attributes that contain message source and > transport information. (This would normally consist of things > normally found in RFC 822 headers. However, it will not include > MIME information.) > b. Multipart objects are an ordered collection containing one or > more message, multipart, or terminal objects. Each multipart will > have a type attribute, indicating the type of collection, and may > have attributes corresponding to MIME disposition, description, or > identifier information. > c. Terminal objects contain data that comprises the object. > Terminal objects have a type attribute, indicating the type of data > contained in the object, and may have attributes corresponding to > MIME disposition, description, or identifier information. > > All of the attributes mentioned above are read-only. Message store > objects may also have writeable attributes associated with them. > These are talked about below with regard to message access clients. > In any event, these attributes are for clients only. Message access > servers do not add or change them. > > Multiple objects may contain a given object. The deletion of a > container object only deletes once instance of a shared contained > object. > > A message access server will likely house several message stores. > These message stores may share data, in which case unique > identifiers must remain unique and object instances must be > maintained across all message stores. > > 2. A message access client may perform the following functions with > regard to the message store: > a. Authenticate itself to the message store server. > b. Search for messages with particular attributes, receiving a > list of message identifiers. (The client may request that the > results of searches be sorted by any particular attribute. The > client may request to be returned only a particular portion of the > search results.) > c. Retrieve any message or object contained therein (or portion > thereof). > d. Retrieve the attributes of any message or object contained > therein (including a list of objects contained in the message or > object, recursively if desired). > e. Store a message (allowing that message to contain parts already > in the message store). > f. Store or change writeable attributes. (Writeable attributes are > arbitrary in nature; that is, an arbitrary attribute name may be > used and it may be given an arbitrary value. Although there may be > a registry of such attributes, they are strictly for client use.) > g. Given an attribute, search for all unique values of that > attribute across the message store. > h. Delete a message. > > All client actions are sent and completed asynchronously. Responses > to client actions are tagged to indicate the order in which they > were completed. A client will receive responses regarding storage, > deletion, and changes of objects and attributes even if the > particular client in question did not initiate those actions. > > It is imagined that a message delivery agent is just another > message access client. > > > -- > Pete Resnick > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858) > 651-1102 --Apple-Mail-10--182015883 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin = forwarded message:

From: = Pete Resnick <presnick@qualcomm.com>=

Toward a Simpler Message Access = Architecture

The architecture for the transport of mail messages = embodies a core principle: Messages move through the Internet simply, = without examination or transformation of their contents, and that they = are transported according to envelope information that is separate from = the contents. The Simple Mail Transfer Protocol (SMTP) and its = implementations live up to this principle to greater or lesser degrees, = but this is certainly the ideal that we strive for, and we use it as a = benchmark for SMTP design and extension. In addition, when it comes to = the contents of messages, the Internet Message Format (IMF) and = Multipurpose Internet Mail Extensions (MIME) have a canonical format = that is specifically independent of any particular storage or user = interface constraints. Again, implementations keep storage and user = interface constraints from appearing to differing degrees, but we still = strive toward this platform independence in implementation and protocol = development. However, the structure has given us the ability to have = relatively complex messages (sometimes with a great deal of structure = and representing all sorts of complex data types) transported in a = relatively simple fashion. This architecture lends itself to relatively = simple implementation for both clients and servers: Clients prepare the = message object (however complex) and the envelope, convert the message = from any local conventions to canonical format, and transmit the message = using the independent envelope information. End-to-end, the transport is = relatively simple.
In contrast to message = transport, message access has not fared as well in these regards. The = only two message access protocols we have, the Post Office Protocol = (POP) and the Internet Message Access Protocol (IMAP), sit at opposite = ends of a spectrum with regard to simplicity of implementation and = operation, ability to deal with complexity in message structures, and = platform independence. Of course, with regard to simplicity of = implementation and operation, POP shines: For a client to simply connect = to a server and download messages in their entirety, POP is very = straightforward. However, this simplicity pushes a great deal of = complexity and some computing horsepower requirements from servers onto = clients. Clients must have enough bandwidth to get messages, enough = local storage to manipulate and interpret the messages they have = downloaded, and enough compute power to locally parse through complex = message structures. In this time of smaller client devices with less = compute, bandwidth, and storage, this makes POP use problematic. Of = course, assorted extensions have been added to POP to facilitate use by = smaller devices, but they are generally ad-hoc specialized extensions = that do not address more general issues for lower capability = clients.

IMAP on the other hand does not suffer POP's = problems. IMAP servers parse the structure of messages for the client = and present only those parts (or parts of parts) that the client = requests. Recent extensions have made access to and manipulation of = message parts even easier for lower capability clients. There is, of = course, an increase in protocol complexity in IMAP as compared to POP. = Some of that is counter-balanced by the fact that the client does not = have to do much of the parsing work locally, but can instead rely on the = server to do so. However, IMAP's central shortcoming, due to a design = principle that was necessary at the time of its creation, is that = clients have to deal with a great deal of complexity because IMAP = exposes much of the semantics of the server's local environment to the = client. IMAP was designed such that protocol constructs map relatively = easily to extant servers' message storage models. (It should be noted = that failure to have this design principle at the time would have = resulted in an undeployable protocol.) The result is a protocol where = messages are stored grouped in mailboxes (which paralleled existing = implementations' file storage structure), much of the ancillary data = associated with messages is stored in the mailboxes themselves = (requiring a small set of data), and operations may be either = synchronous or asynchronous in nature depending on the particular = operation. These design choices introduce interesting and unexpected = implementation complexities on clients.=A0 IMAP's support of a = hierarchical store of messages (as against POP, which has a single flat = spool of messages) means that even if a client only wants to present a = simple one-dimensional view of messages, it still must support IMAP's = hierarchical store in order to discover all of the messages on the = server. In particular, in order to discover changes to the mail store, = clients must SELECT those mailboxes in which the client has interest and = can not get information about changes to arbitrary parts of the store. = With regard to the data storage model, clients that perform operations = outside of IMAP's architectural model that might need to store and = retrieve ancillary data with messages to support those operations (for = instance, a particular messages display size and screen positioning) = must either rely on the server to implement such functionality (which is = not a requirement for servers) or must store that information locally = (which is infeasible for some clients). Finally, the mixture of = synchronous and asynchronous operation sometimes makes for tricky = implementation choices. Of course, there are the well-understood = examples of certain command sequences that cannot run concurrently, but = restrictions on untagged EXPUNGE responses also make implementation = difficult.

Server technology has come a long way in the past 20 = years. In particular, scalable multiple-access database storage = implementations are now widely available and in use. Not only does this = mean that arbitrary data can be easily stored and retrieved (including = by multiple simultaneous users), but it also means that hierarchical = file structure needn't be maintained by the application in order to = obtain decent performance. Use of such a system as a backend for a = message access protocol simplifies design significantly and greatly aids = flexibility. I suggest that a new message access architecture could = maintain all of the advantages that IMAP has over POP, yet remove some = of the difficulties associated with reflection of underlying design = constraints in protocol considerations.

What follows = is a rough outline of such an architecture. It maps onto current = technologies in such a way that transition to the architecture would be = more straightforward, sometimes at the expense of simplicity. (Consider = this a target at which to shoot rather than a fully-fleshed out = solution. In particular, neither access control nor end-to-end security = issues are discussed in this proposal.)

1. A message = access store will contain three sorts of objects: message objects, = multipart objects, and terminal objects. All objects have attributes. = The objects are comprised as follows:
a. = Message objects must contain one multipart or one terminal object. Each = message must have a "unique identifier" attribute which is unique within = the message store. A message will normally also have a series of = attributes that contain message source and transport information. (This = would normally consist of things normally found in RFC 822 headers. = However, it will not include MIME information.)
b. Multipart objects are an = ordered collection containing one or more message, multipart, or = terminal objects. Each multipart will have a type attribute, indicating = the type of collection, and may have attributes corresponding to MIME = disposition, description, or identifier information.
c. Terminal objects contain data = that comprises the object. Terminal objects have a type attribute, = indicating the type of data contained in the object, and may have = attributes corresponding to MIME disposition, description, or identifier = information.

All of the attributes mentioned above are read-only. = Message store objects may also have writeable attributes associated with = them. These are talked about below with regard to message access = clients. In any event, these attributes are for clients only. Message = access servers do not add or change them.

Multiple = objects may contain a given object. The deletion of a container object = only deletes once instance of a shared contained object.

A = message access server will likely house several message stores. These = message stores may share data, in which case unique identifiers must = remain unique and object instances must be maintained across all message = stores.

2. A message access client may perform the following = functions with regard to the message store:
a. = Authenticate itself to the message store server.
b. Search for messages with = particular attributes, receiving a list of message identifiers. (The = client may request that the results of searches be sorted by any = particular attribute. The client may request to be returned only a = particular portion of the search results.)
c. = Retrieve any message or object contained therein (or portion = thereof).
d. Retrieve the attributes of any = message or object contained therein (including a list of objects = contained in the message or object, recursively if desired).
e. Store a message (allowing that = message to contain parts already in the message store).
f. Store or change writeable = attributes. (Writeable attributes are arbitrary in nature; that is, an = arbitrary attribute name may be used and it may be given an arbitrary = value. Although there may be a registry of such attributes, they are = strictly for client use.)
g. Given = an attribute, search for all unique values of that attribute across the = message store.
h. Delete a message.

All = client actions are sent and completed asynchronously. Responses to = client actions are tagged to indicate the order in which they were = completed. A client will receive responses regarding storage, deletion, = and changes of objects and attributes even if the particular client in = question did not initiate those actions.

It is = imagined that a message delivery agent is just another message access = client.


--=A0
Qualcomm Incorporated - Direct = phone: (858)651-4478, Fax: (858)651-1102
=

= --Apple-Mail-10--182015883-- From discuss-bounces@apps.ietf.org Sun Jan 27 15:20:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJDzK-0004bg-Ro; Sun, 27 Jan 2008 15:20:22 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JJDzI-0004bZ-VL for discuss-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 15:20:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJDzI-0004bR-Li for discuss@apps.ietf.org; Sun, 27 Jan 2008 15:20:20 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJDzI-0004ld-2h for discuss@apps.ietf.org; Sun, 27 Jan 2008 15:20:20 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8AE22142245 for ; Sun, 27 Jan 2008 12:20:22 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqjKrlnTm4TD for ; Sun, 27 Jan 2008 12:20:16 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5369E142217 for ; Sun, 27 Jan 2008 12:20:16 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Apps Discuss From: Lisa Dusseault Subject: PP14: HTTP as a substrate -- five years later Date: Sun, 27 Jan 2008 12:20:11 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org HTTP as a substrate -- five years later Yves Lafon Thomas Roessler Abstract In this position paper, we revisit some of the questions that BCP 56 addresses, from the point of view of today's technological environment. Using HTTP as an element to build protocols BCP56 provides useful guidance on the use of HTTP as a substrate. However, the document mixes considerations that arise when extension points within HTTP are exercised with considerations that arise when a new protocol is derived from HTTP. This mix does not contribute to the document's clarity. Additionally, some issues that arise in today's environment are not covered in BCP 56. The Cost of New Methods HTTP methods are allocated from a single pool of flat strings; coining new HTTP methods is therefore inherently costly, as it requires social coordination. Use of existing HTTP methods to underpin protocols that identify the semantics of individual messages in a way that can be reduced to URI-based extensibility patterns might often turn out to be lest costly, and ultimately scale to a broader set of applications. It can be argued, then, that new methods should only be introduced when they would be found useful to the Web in general and not one particular protocol built as an extension of HTTP. Client Expectations BCP56 uses a notion of "browser-based HTTP" as one of its criteria. With the arrival of almost arbitrary socket-style interfaces in commonly deployed Web Browsers, and with broad use of XMLHttpRequest in AJAX style applications, that notion has changed fundamentally over the last five years. Clients for many TCP/IP based protocols can be readily implemented using a commonly deployed web browser as a platform, and almost arbitrary variants of HTTP can be used readily and on a standardized basis. As clients are able to automatically trigger HTTP requests, additional questions might become more critical for the choice of HTTP as a substrate: - Does the HTTP-based protocol stick to pre-existing method semantics (e.g., safe vs unsafe)? If a protocol adds semantic expectations to existing HTTP methods that are not present in these methods' original designs, then that suggests strongly to either use a different protocol, or introduce a new method. - How will the protocol deal with unattended execution of unsafe HTTP methods? In today's browser-based environment, even some of the original design constraints on HTTP methods don't hold any more. Server Expectations BCP56 uses notions such as a "different data set" and "distinct server processes" as suggestions for criteria that should be taken into account when deciding whether a separate port should be used for a new HTTP-based protocol. In some cases, like WebDAV, new methods were introduced that affect new data sets, while regular Web cotnent could be served using the default HTTP method. Should such protocols run on a different port? Instead, we suggest that designers of HTTP-based protocols consider the impact of their design decisions on URI space as a whole. * Are safe HTTP methods still able to work as intended? * Does the newly designed protocol rely on specific expectations, like well-known locations, without injecting a discovery phase? * Does it involve a completely separated data set? RESTfulness? Another dimension in the design of HTTP-based protocols that isn't addressed in BCP56 is the relation between the newly designed protocol and the REST design paradigm: What protocol states should be identifiable by URI themselves, and what protocol states should maybe not be addressable? From discuss-bounces@apps.ietf.org Sun Jan 27 15:21:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJE0A-0005XR-Rd; Sun, 27 Jan 2008 15:21:14 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JJE09-0005Qs-7S for discuss-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 15:21:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJE08-0005Pm-Th for discuss@apps.ietf.org; Sun, 27 Jan 2008 15:21:12 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJE06-0004mt-LZ for discuss@apps.ietf.org; Sun, 27 Jan 2008 15:21:12 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 25787142245 for ; Sun, 27 Jan 2008 12:21:13 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AozqVdgPUBeb for ; Sun, 27 Jan 2008 12:21:05 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C3C3A142217 for ; Sun, 27 Jan 2008 12:21:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) To: Apps Discuss Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-13--180238426 References: <31D151A3D66E404AACBBB0247ACA54A7029D3A@STNTEXCH11.cis.neustar.com> From: Lisa Dusseault Subject: PP15: Does Applicability Matter for Applications? Date: Sun, 27 Jan 2008 12:21:00 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-13--180238426 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: "Peterson, Jon" > Does Applicability Matter for Applications? > Jon Peterson > > > There is a longstanding maxim of Internet protocol design that > successful application protocols invariably devolve into generic > transports. The canonical example would be HTTP; the parody in > RFC3093 (the "Firewall Enhancement Protocol") is frighteningly > close to the truth. A number of protocols which have little to do > with the delivery of hypertext take advantage of the ubiquitous > deployment of HTTP, piggybacking on it or masquerading as it on the > wire. > > It is widely believed that this slide into the generic is > undesirable. Most application protocols have a specific intended > sphere of applicability, and this applicability informs the design. > HTTP was certainly not intended to be a transport for arbitrary data. > > So why does this occur? > > One reason is because there is a certain barrier to entry for new > protocols on the Internet. Once a protocol enjoys widespread > implementation and deployment, the Internet has adapted to its > presence: endpoints support it, middleboxes allow it, servers are > optimized for it. It becomes difficult to sell devices that inhibit > a dominant protocol. When a new application goes shopping for a > protocol, the level of effort required to overcome this barrier to > entry is a significant consideration, and riding on the coat-tails > of an existing dominant protocol appears an attractive path to > rapid deployment. > > This paper argues that furthermore, a class of tools exist that can > render application protocols generic, a class that will be referred > to here as "genericizers". In the case of HTTP, SOAP would be a > prime example of this sort of tool. The effect of a genericizer is > to broaden the applicability of a protocol by enabling its fields > or payloads to carry unanticipated material with different, > potentially radically different, characteristics than the protocol > designers intended. From a standardization perspective, > genericizers furthermore perform this function without requiring > any modification to the underlying protocol. These tools thus allow > implementers, and designers of derivative specifications, to > reinterpret the applicability of a protocol entirely. > > As a case study of the phenomenon of genericizers, this paper > explores the data URL (RFC2397) and considers the manner in which > proposed uses of the data URL impact and genericize protocols in > the RAI Area, particularly ENUM and SIP. > > Broadly, the purpose of the data URL is to provide literal data by- > value when the use of a URI is required, but a reference is > undesirable. RFC2397 suggests that the intended use was to provide > relatively small chunks of inline data, ranging from text strings > (the default MIME type for data) to encoded binary representation > of modestly-sized image files. The intended applicability of the > data URL is more or less unlimited; RFC2397 says little more than > "Some applications that use URLs also have a need to embed (small) > media type data directly inline", and that "The "data:" URL scheme > is only useful for short values." > > It is arguable whether or not data URL meets the definition of a > URI - not because it fails to yield a resource, given the term > 'resource' is defined quite liberally in RFC2396, but because there > is no meaningful sense in which it serves as an identifier. As > RFC2396 says, "An identifier is an object that can act as a > reference to something that has identity." The data URL is not a > reference, it is a literal. Similarly, a URL is defined as "the > subset of URI that identify resources via a representation of their > primary access mechanism", and a data URL clearly does not > constitute a representation nor does it reflect any sort of access. > Already these deviations from the conventional purpose of URIs and > URLs suggest that that use of the data scheme might have unintended > consequences. > > Consider the use of the data URI in ENUM (RFC3761). ENUM is a > mechanism for using the DNS to discover URIs associated with > telephone numbers. For this purpose ENUM builds off the DDDS > framework, albeit ENUM benefits from only a subset of DDDS's > capabilities (for instance, it has no pressing need for the order > v. preference distinction, the replacement field, or a non-greed > LHS of the regular expression, not to mention that lookups targets > a pre-established "golden root" domain). > > The data URL entered the ENUM community through draft-ietf-enum- > cnam, a document which proposes a way to look up a text string > associated with a telephone number (the text string contains the > name one would see when Caller ID is displayed on a telephone). > This string is stored as a data URL within a NAPTR record. On some > level, the motivation for this work is obvious. ENUM as a query- > response protocol is implemented on the target devices for this > application, the devices need some additional query-response > functionality; ENUM is in other words perceived as a dominant > protocol, and enum-cnam proposes to piggyback additional data onto > it. > > But once a genericizer has been introduced, ENUM no longer > neccesarily shows "how DNS can be used for identifying available > services connected to one E.164 number", since the data URL in no > way identifies services. Instead, it renders ENUM a generic > database protocol whose keys are telephone numbers and values are > arbitrary data. Once the capability to parse data URLs is present > in ENUM resolvers, arbitrary data then can be served via the DNS. > Effectively this allows domain administrators to embed TXT RRs > within NAPTR RRs, with the added bonus of MIME typing to allow > various binary data types. Proposals that have been informally > discussed with this regard include embedding public keys, ringtones > and vCards within data URLs in NAPTR RRs. It would not be much of a > stretch to suggest that HTML documents could be served directly > from the DNS in a similar fashion. All of these proposals have > familiar implications on DNS response message size, caching, > security, privacy, and so on. None of these problems arise in the > use of typical URIs, which identify resources in the network and > thus provide a layer of indirection. ENUM assumes the existence of > that layer of indirection; without it, ENUM's architectural > underpinnings look increasingly suspect. > > The current version of draft-ietf-enum-cnam has abandoned the data > URL, due to pushback - it does however propose a new 'pstndata' URL > scheme, with more or less identical properties but a slightly > constrained applicability to PSTN-related data. However, despite > this setback the data URL still enjoys a vogue in ENUM circles. One > current notable draft is draft-ietf-enum-unused-02, which proposes > the use of a text string within a data URL to indicate that a > particular telephone number is not in service in the PSTN. > > The data URL has also begun to made a few appearances in the SIP > WG, as a manner of transporting large chunks of data in headers. > The SIP (RFC3261) architecture distinguishes envelope from body in > a manner similar to email; intermediaries inspect and modify > headers in the process of routing requests, whereas message bodies > are payloads that are delivered to applications at the endpoints. > While intermediaries are not strictly forbidden from inspecting SIP > message bodies, there is no standard routing procedure that relies > on them doing so, and intermediaries are forbidden explicitly from > modifying SIP message bodies. However, there are members of the SIP > community who would like intermediaries to have control over the > bodies of SIP messages, mostly so that SDP can be modified to > enforce policies familiar to operators in the PSTN. So, as is the > case with email, there has for some time been an impetus in the SIP > WG from this contingent end the tyranny of endpoints over bodies, > but here has not been a standard way to permit unilateral > modification of bodies by intermediaries. > > However, given that SIP message bodies could conceivably be encoded > as data URLs, and numerous SIP header fields permit arbitrary URIs > as their value, there is apparently an easy workaround. Ordinarily, > location information such as PIDF-LO (RFC4119) is carried as a body > within SIP; for the Location header field proposed by draft-ietf- > sip-location-conveyance, it has been proposed that a data URI be > used when an intermediary needs to insert location information. > Similar suggestions have been made related to some bodies used for > security properties, and for SDP itself. > > Leaving aside practical concerns about the length of SIP headers > that parsers can withstand, the effect of moving information from > bodies to headers fundamentally changes the SIP architecture. For > example, SIP's security model is focused on providing end-to-end > security services for bodies, but not for headers. Moreover, > applications at the endpoints that want to consume bodies should > have some reasonable sense of who created them. That is clear in > the RFC3261 architecture, but much less so if bodies migrate into > headers. The acceptance of more or less any proposal to encode data > URLs in SIP headers would open the doors to numerous > > So what's to be done? > > This study sheds light on genericizers in order to make them easier > to identify when they arise in future standardization efforts, and > also to illustrate that they have significant architectural > implications. Given how long a protocol like RFC2397 has been > around, it is unlikely that it will be deprecated; nor is it > reasonable for protocols that use URIs to single out that the data > URI is inappropriate for use in a particular field - as the enum- > cnam "pstndata" URI proposal illustrates, it is quite easy to > circumvent such a prohibition. However, the lessons learned from > studying the manner in which genericizers are leveraged may assist > in preventing similar architectural loopholes in the future. > > Unfortunately, the primary reason why the data URL is not more > widely used in the IETF is, in all likelihood, that relatively few > participants are aware of it. > > Finally, it is important to note that the data URL did not create > the impetus in ENUM or SIP to genericize their architectures; the > data URL is merely an enabler used by the advocates of those > positions to advance more generic architectures without having to > contest the underlying design choices of ENUM and SIP. > --Apple-Mail-13--180238426 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin = forwarded message:

From: = "Peterson, Jon" <jon.peterson@neustar.biz><= /FONT>

Does Applicability = Matter for Applications?
Jon Peterson


There is a longstanding maxim of Internet protocol design that = successful application protocols invariably devolve into generic = transports. The canonical example would be HTTP; the parody in RFC3093 = (the "Firewall Enhancement Protocol") is frighteningly close to the = truth. A number of protocols which have little to do with the delivery = of hypertext take advantage of the ubiquitous deployment of HTTP, = piggybacking on it or masquerading as it on the wire.

It is widely believed that this slide = into the generic is undesirable. Most application protocols have a = specific intended sphere of applicability, and this applicability = informs the design. HTTP was certainly not intended to be a transport = for arbitrary data.

So why does this occur?

One reason is because there is a certain barrier to = entry for new protocols on the Internet. Once a protocol enjoys = widespread implementation and deployment, the Internet has adapted to = its presence: endpoints support it, middleboxes allow it, servers are = optimized for it. It becomes difficult to sell devices that inhibit a = dominant protocol. When a new application goes shopping for a protocol, = the level of effort required to overcome this barrier to entry is a = significant consideration, and riding on the coat-tails of an existing = dominant protocol appears an attractive path to rapid = deployment.

This = paper argues that furthermore, a class of tools exist that can render = application protocols generic, a class that will be referred to here as = "genericizers". In the case of HTTP, SOAP would be a prime example of = this sort of tool. The effect of a genericizer is to broaden the = applicability of a protocol by enabling its fields or payloads to carry = unanticipated material with different, potentially radically different, = characteristics than the protocol designers intended. =46rom a = standardization perspective, genericizers furthermore perform this = function without requiring any modification to the underlying protocol. = These tools thus allow implementers, and designers of derivative = specifications, to reinterpret the applicability of a protocol = entirely.

As a case = study of the phenomenon of genericizers, this paper explores the data = URL (RFC2397) and considers the manner in which proposed uses of the = data URL impact and genericize protocols in the RAI Area, particularly = ENUM and SIP.

Broadly, the purpose of the data URL is to provide literal data = by-value when the use of a URI is required, but a reference is = undesirable. RFC2397 suggests that the intended use was to provide = relatively small chunks of inline data, ranging from text strings (the = default MIME type for data) to encoded binary representation of = modestly-sized image files. The intended applicability of the data URL = is more or less unlimited; RFC2397 says little more than "Some = applications that use URLs also have a need to embed (small) media type = data directly inline", and that "The "data:" URL scheme is only useful = for short values."

It = is arguable whether or not data URL meets the definition of a URI - not = because it fails to yield a resource, given the term 'resource' is = defined quite liberally in RFC2396, but because there is no meaningful = sense in which it serves as an identifier. As RFC2396 says, "An = identifier is an object that can act as a reference to something that = has identity." The data URL is not a reference, it is a literal. = Similarly, a URL is defined as "the subset of URI that identify = resources via a representation of their primary access mechanism", and a = data URL clearly does not constitute a representation nor does it = reflect any sort of access. Already these deviations from the = conventional purpose of URIs and URLs suggest that that use of the data = scheme might have unintended consequences.

Consider the use of the data URI in ENUM (RFC3761). = ENUM is a mechanism for using the DNS to discover URIs associated with = telephone numbers. For this purpose ENUM builds off the DDDS framework, = albeit ENUM benefits from only a subset of DDDS's capabilities (for = instance, it has no pressing need for the order v. preference = distinction, the replacement field, or a non-greed LHS of the regular = expression, not to mention that lookups targets a pre-established = "golden root" domain).

The data URL entered the ENUM community through = draft-ietf-enum-cnam, a document which proposes a way to look up a text = string associated with a telephone number (the text string contains the = name one would see when Caller ID is displayed on a telephone). This = string is stored as a data URL within a NAPTR record. On some level, the = motivation for this work is obvious. ENUM as a query-response protocol = is implemented on the target devices for this application, the devices = need some additional query-response functionality; ENUM is in other = words perceived as a dominant protocol, and enum-cnam=A0 proposes to = piggyback additional data onto it.

But once a genericizer has been introduced, ENUM no = longer neccesarily shows "how DNS can be used for identifying available = services connected to one E.164 number", since the data URL in no way = identifies services. Instead, it renders ENUM a generic database = protocol whose keys are telephone numbers and values are arbitrary data. = Once the capability to parse data URLs is present in ENUM resolvers, = arbitrary data then can be served via the DNS. Effectively this allows = domain administrators to embed TXT RRs within NAPTR RRs, with the added = bonus of MIME typing to allow various binary data types. Proposals that = have been informally discussed with this regard include embedding public = keys, ringtones and vCards within data URLs in NAPTR RRs. It would not = be much of a stretch to suggest that HTML documents could be served = directly from the DNS in a similar fashion. All of these proposals have = familiar implications on DNS response message size, caching, security, = privacy, and so on. None of these problems arise in the use of typical = URIs, which identify resources in the network and thus provide a layer = of indirection. ENUM assumes the existence of that layer of indirection; = without it, ENUM's architectural underpinnings look increasingly = suspect.

The current = version of draft-ietf-enum-cnam has abandoned the data URL, due to = pushback - it does however propose a new 'pstndata' URL scheme, with = more or less identical properties but a slightly constrained = applicability to PSTN-related data. However, despite this setback the = data URL still enjoys a vogue in ENUM circles. One current notable draft = is draft-ietf-enum-unused-02, which proposes the use of a text string = within a data URL to indicate that a particular telephone number is not = in service in the PSTN.

The data URL has also begun to made a few appearances in the SIP = WG, as a manner of transporting large chunks of data in headers. The SIP = (RFC3261) architecture distinguishes envelope from body in a manner = similar to email; intermediaries inspect and modify headers in the = process of routing requests, whereas message bodies are payloads that = are delivered to applications at the endpoints. While intermediaries are = not strictly forbidden from inspecting SIP message bodies, there is no = standard routing procedure that relies on them doing so, and = intermediaries are forbidden explicitly from modifying SIP message = bodies. However, there are members of the SIP community who would like = intermediaries to have control over the bodies of SIP messages, mostly = so that SDP can be modified to enforce policies familiar to operators in = the PSTN. So, as is the case with email, there has for some time been an = impetus in the SIP WG from this contingent end the tyranny of endpoints = over bodies, but here has not been a standard way to permit unilateral = modification of bodies by intermediaries.

However, given that SIP message bodies could = conceivably be encoded as data URLs, and numerous SIP header fields = permit arbitrary URIs as their value, there is apparently an easy = workaround. Ordinarily, location information such as PIDF-LO (RFC4119) = is carried as a body within SIP; for the Location header field proposed = by draft-ietf-sip-location-conveyance, it has been proposed that a data = URI be used when an intermediary needs to insert location information. = Similar suggestions have been made related to some bodies used for = security properties, and for SDP itself.

Leaving aside practical concerns about the length = of SIP headers that parsers can withstand, the effect of moving = information from bodies to headers fundamentally changes the SIP = architecture. For example, SIP's security model is focused on providing = end-to-end security services for bodies, but not for headers. Moreover, = applications at the endpoints that want to consume bodies should have = some reasonable sense of who created them. That is clear in the RFC3261 = architecture, but much less so if bodies migrate into headers. The = acceptance of more or less any proposal to encode data URLs in SIP = headers would open the doors to numerous

So what's to be done?

This study sheds light on genericizers in order to = make them easier to identify when they arise in future standardization = efforts, and also to illustrate that they have significant architectural = implications. Given how long a protocol like RFC2397 has been around, it = is unlikely that it will be deprecated; nor is it reasonable for = protocols that use URIs to single out that the data URI is inappropriate = for use in a particular field - as the enum-cnam "pstndata" URI proposal = illustrates, it is quite easy to circumvent such a prohibition. However, = the lessons learned from studying the manner in which genericizers are = leveraged may assist in preventing similar architectural loopholes in = the future.

Unfortunately, the primary reason why the data URL is not more = widely used in the IETF is, in all likelihood, that relatively few = participants are aware of it.

Finally, it is important to note that the data URL = did not create the impetus in ENUM or SIP to genericize their = architectures; the data URL is merely an enabler used by the advocates = of those positions to advance more generic architectures without having = to contest the underlying design choices of ENUM and SIP.

=

= --Apple-Mail-13--180238426-- From discuss-bounces@apps.ietf.org Sun Jan 27 15:22:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJE1Y-0005tg-M6; Sun, 27 Jan 2008 15:22:40 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JJE1X-0005tQ-0T for discuss-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 15:22:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJE1W-0005tI-Mx for discuss@apps.ietf.org; Sun, 27 Jan 2008 15:22:38 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJE1U-0004ob-IP for discuss@apps.ietf.org; Sun, 27 Jan 2008 15:22:38 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F25FB142245 for ; Sun, 27 Jan 2008 12:22:38 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBYxTRQw1IFl for ; Sun, 27 Jan 2008 12:22:32 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 32512142217 for ; Sun, 27 Jan 2008 12:22:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Apps Discuss From: Lisa Dusseault Subject: PP16: Generic Synchronization Date: Sun, 27 Jan 2008 12:22:25 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Network Working Group C. Jennings Internet-Draft Cisco Intended status: Standards Track January 26, 2008 Expires: July 29, 2008 Generic Synchronization draft-jennings-apps-sync-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 29, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This brief note discusses the growing need for a standardized sync protocol for generic information and looks at one possibility for what such a protocol might look like. It lists some of the things people are syncing today, introduces a "ferry" concept of synchronization, and briefly sketches a possible synchronization scheme. Jennings Expires July 29, 2008 [Page 1] Internet-Draft SYNC January 2008 1. Introduction Synchronization is about keeping a set of data consistent between a set of devices. The classic example of this would be a user's Personal Address Book (PAB) but there are many other things that are becoming common to sync: media play lists, photo albums, missed call lists on phones or dialed call lists, task lists, gps location tracks, and many more. One way to deal with sync issues is to have a central server that is the master source of truth, with all the devices periodically connecting to that server and updating. However, in many situations having every device connect to a master source is impossible. This note is about synchronization in environments in which a centralized server architecture is impossible. This note looks at systems in which all the devices are equivalent and there is no master server that all devices can reach. This allows a device to act as ferry to bridge the synced information. As an example, I sync my PAB in my notebook computer to my phone using USB, and then I sync my phone to the navigation system in my car using bluetooth. In this case my phone has acted as a ferry to transfer the data from my PC to car. The car does not have internet connectivity and could not have contacted a central server. With the price of flash memory falling below $10 per gigabyte, phones, PDAs, and even just plain USB keys are rapidly becoming usable to synchronizing multiple gigabytes of data, making it practical to use a device like a phone as a ferry for music and video. The device that is acting as the ferry could easily synchronize information that it did not understand or use itself. The most critical functionality of any sync system is that a user never wants to see "you have 376 conflicts! how would you like to resolve them?" It is also important that any sync protocol be able to gracefully deal with syncs that have been brutally interrupted by events such as the plug being pulled out part way through the sync. It is also key that when the communication mechanism between the two devices is very slow, large chunks of data that do not need to be transferred should not be transferred. 2. Synchronization Approaches Data schemas that need to be synchronized need to be designed for this if you want them to have reasonable conflict resolution properties. This note uses two terms: record and fields. Records are just a collection of fields. Fields are an atomic piece of data from a synchronization point of view. A field can be more complex than a single data item. For example in a PAB, a telephone number Jennings Expires July 29, 2008 [Page 2] Internet-Draft SYNC January 2008 may contain an indication that it is a mobile, home or work number. This indication would likely be in the same field as the phone number since they need to handled as a single atomic unit when dealing with conflict resolution. However a PAB would not want the the email address and phone number in the same field because then you could not successfully synchronize in a situation in which one device has added a new phone number for a particular user and another device has added a new email address. The point of this is that the data schema needs to clearly outline what the atomic blocks are. The approach proposed here gives every record and field a UUID and fields have a time-stamp of when they were last modified. One can debate the issues with time synchronization but from a pragmatic point of view, just about every device today has a rough idea of time. The sync protocol starts with both sides exchanging their UUIDs and checking whether either device has any fields that are missing from the other and if so transferring them. For fields that have changed on both sides, the devices would compare the time-stamps and select the most recent one. It would be possible to query the users about resolving conflicts at this point but for many cases it would not be necessary. Deletion would be done by removing all the data from the field except the UUID and time-stamp, and marking a deleted flag on the field. Devices that were not capable of knowing the time could just slightly increment the time-stamp when they changed a field. Each device would also have a UUID; when a pair of devices had previously synced, they could optimize the sync by only exchanging records and fields that had changed since the previous sync. This type of sync protocol could be realized other ways. For example one could just have an XML file on a USB key that had all the records and fields in the file; the USB key would be used as a ferry between the devices to be synchronized. Author's Address Cullen Jennings Cisco 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 USA Phone: +1 408 421-9990 Email: fluffy@cisco.com Jennings Expires July 29, 2008 [Page 3] Internet-Draft SYNC January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Jennings Expires July 29, 2008 [Page 4] From discuss-bounces@apps.ietf.org Mon Jan 28 05:34:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJRJo-00030L-R8; Mon, 28 Jan 2008 05:34:24 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JJRJo-0002ye-1w for discuss-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 05:34:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJRJn-0002xo-F2 for discuss@apps.ietf.org; Mon, 28 Jan 2008 05:34:23 -0500 Received: from mk-outboundfilter-1.mail.uk.tiscali.com ([212.74.114.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJRJl-0003rt-87 for discuss@apps.ietf.org; Mon, 28 Jan 2008 05:34:23 -0500 X-Trace: 28077668/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.162.31 X-SBRS: None X-RemoteIP: 62.241.162.31 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOg+nUc+8aIf/2dsb2JhbACKUKAN X-IP-Direction: IN Received: from galaxy.systems.pipex.net ([62.241.162.31]) by smtp.pipex.tiscali.co.uk with ESMTP; 28 Jan 2008 10:34:19 +0000 Received: from pc6 (1Cust138.tnt6.lnd4.gbr.da.uu.net [62.188.135.138]) by galaxy.systems.pipex.net (Postfix) with SMTP id 023CFE00009C for ; Mon, 28 Jan 2008 10:34:17 +0000 (GMT) Message-ID: <00e701c86190$b25ec7c0$0601a8c0@pc6> From: "tom.petch" To: "Apps Discuss" References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> Subject: URI for XML schema - why bother? Date: Mon, 28 Jan 2008 10:32:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Well, actually it was ' there is not point in having a schema name'. I asked before what form URI should take for namespace and schema, and I got a very clear answer, for which thank you. But in two separate WGs I have proposed that schema should be given a URI and it hasn't happened, in one case with the reply to the effect that they add no value and are not worth having. Instinctively I disagree and know of other WGs that do define them (although I also saw an I-D which used a schema URI and then removed it before becoming an RFC). So what rational arguments might I advance as to why it is a good idea to name a schema with a URI? Tom Petch. From discuss-bounces@apps.ietf.org Mon Jan 28 06:35:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJSH9-0000DH-2v; Mon, 28 Jan 2008 06:35:43 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JJSH8-0000Ar-85 for discuss-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 06:35:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJSH7-0008TS-Ll for discuss@apps.ietf.org; Mon, 28 Jan 2008 06:35:41 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJSH6-0005dA-DD for discuss@apps.ietf.org; Mon, 28 Jan 2008 06:35:41 -0500 X-IronPort-AV: E=Sophos;i="4.25,259,1199682000"; d="scan'208";a="95673846" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 28 Jan 2008 06:35:37 -0500 X-IronPort-AV: E=Sophos;i="4.25,259,1199682000"; d="scan'208";a="154861371" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Jan 2008 06:23:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: URI for XML schema - why bother? Date: Mon, 28 Jan 2008 12:22:52 +0100 Message-ID: In-Reply-To: <00e701c86190$b25ec7c0$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URI for XML schema - why bother? Thread-Index: AchhmXFkuv9prU0XRImHEG6k6ksZkwABpg6g References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <00e701c86190$b25ec7c0$0601a8c0@pc6> From: "Romascanu, Dan (Dan)" To: "tom.petch" , "Apps Discuss" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org I believe that such a recommendation is implicit in documents like RFC 3688.=20 Dan =20 =20 > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com]=20 > Sent: Monday, January 28, 2008 11:32 AM > To: Apps Discuss > Subject: URI for XML schema - why bother? >=20 > Well, actually it was ' there is not point in having a schema name'. >=20 > I asked before what form URI should take for namespace and=20 > schema, and I got a very clear answer, for which thank you. >=20 > But in two separate WGs I have proposed that schema should be=20 > given a URI and it hasn't happened, in one case with the=20 > reply to the effect that they add no value and are not worth having. >=20 > Instinctively I disagree and know of other WGs that do define=20 > them (although I also saw an I-D which used a schema URI and=20 > then removed it before becoming an RFC). >=20 > So what rational arguments might I advance as to why it is a=20 > good idea to name a schema with a URI? >=20 > Tom Petch. >=20 >=20 >=20 >=20 > This email was protected during delivery to Avaya with TLS encryption >=20 >=20 From discuss-bounces@apps.ietf.org Mon Jan 28 13:02:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJYJc-0000Dj-FJ; Mon, 28 Jan 2008 13:02:40 -0500 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JJYJb-0000DY-MQ for discuss-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 13:02:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJYJb-0000DQ-CS for discuss@apps.ietf.org; Mon, 28 Jan 2008 13:02:39 -0500 Received: from mk-outboundfilter-2.mail.uk.tiscali.com ([212.74.114.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJYJZ-0006fL-RL for discuss@apps.ietf.org; Mon, 28 Jan 2008 13:02:39 -0500 X-Trace: 19009183/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.162.31 X-SBRS: None X-RemoteIP: 62.241.162.31 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAO+mnUc+8aIf/2dsb2JhbACKUaEW X-IP-Direction: IN Received: from galaxy.systems.pipex.net ([62.241.162.31]) by smtp.pipex.tiscali.co.uk with ESMTP; 28 Jan 2008 18:02:36 +0000 Received: from pc6 (1Cust112.tnt110.lnd4.gbr.da.uu.net [62.188.174.112]) by galaxy.systems.pipex.net (Postfix) with SMTP id E93EBE0000C1; Mon, 28 Jan 2008 18:02:33 +0000 (GMT) Message-ID: <06ec01c861cf$51f9a960$0601a8c0@pc6> From: "tom.petch" To: "Romascanu, Dan (Dan)" , "Apps Discuss" References: <00a601c84edd$2ca4dcc0$0601a8c0@pc6> <00e701c86190$b25ec7c0$0601a8c0@pc6> Subject: Re: URI for XML schema - why bother? Date: Mon, 28 Jan 2008 16:45:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "tom.petch" ; "Apps Discuss" Sent: Monday, January 28, 2008 12:22 PM Subject: RE: URI for XML schema - why bother? I believe that such a recommendation is implicit in documents like RFC 3688. Dan I don't see that in the RFC. I see that it defines a registry mechanism that can be used, I can read between the lines and see that a namespace URN will be created if no URI is specified but I cannot see an interpretation that says that a schema URN will be created if nothing is in the I-D. Tom Petch > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Monday, January 28, 2008 11:32 AM > To: Apps Discuss > Subject: URI for XML schema - why bother? > > Well, actually it was ' there is not point in having a schema name'. > > I asked before what form URI should take for namespace and > schema, and I got a very clear answer, for which thank you. > > But in two separate WGs I have proposed that schema should be > given a URI and it hasn't happened, in one case with the > reply to the effect that they add no value and are not worth having. > > Instinctively I disagree and know of other WGs that do define > them (although I also saw an I-D which used a schema URI and > then removed it before becoming an RFC). > > So what rational arguments might I advance as to why it is a > good idea to name a schema with a URI? > > Tom Petch. > > > > > This email was protected during delivery to Avaya with TLS encryption > > From discsa@dis.wa.gov Thu Jan 31 17:15:45 2008 Return-Path: X-Original-To: ietfarch-discuss-archive@core3.amsl.com Delivered-To: ietfarch-discuss-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B26E3A67B1 for ; Thu, 31 Jan 2008 17:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: SALE 73% OFF on VIAGRA\256 \n X-Spam-Flag: YES X-Spam-Score: 90.962 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=90.962 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=1, HTML_SHORT_LINK_IMG_3=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SUBJECT_NEEDS_ENCODING=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 0.3 DRUG_ED_CAPS BODY: Mentions an E.D. drug * 1.5 HTML_IMAGE_ONLY_20 BODY: HTML: images with 1600-2000 bytes of words * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: swinhertare.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: swinhertare.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: swinhertare.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: swinhertare.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: swinhertare.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [200.121.239.252 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [200.121.239.252 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 20 URIBL_SBL Contains an URL listed in the SBL blocklist * [URIs: swinhertare.com] * 0.0 HTML_SHORT_LINK_IMG_3 HTML is very short with a linked image * 1.0 DRUGS_ERECTILE Refers to an erectile drug * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 0.3 MIME_8BIT_HEADER Message header contains 8-bit character * 0.0 SUBJECT_NEEDS_ENCODING SUBJECT_NEEDS_ENCODING Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ibJSys1pG2W for ; Thu, 31 Jan 2008 17:15:43 -0800 (PST) Received: from client-200.121.239.252.speedy.net.pe (unknown [200.121.239.252]) by core3.amsl.com (Postfix) with SMTP id 2A8493A67AB for ; Thu, 31 Jan 2008 17:15:42 -0800 (PST) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 9967 by uid 129); Thu, 31 Jan 2008 08:16:14 +0200 Message-Id: <20080131101614.9969.qmail@client-200.121.239.252.speedy.net.pe> To: Subject: ***SPAM*** 90.962 (5) SALE 73% OFF on =?iso-8859-1?Q?VIAGRA=AE?= From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 31 Jan 2008 17:15:42 -0800 (PST)

From leann6@yahoo.com Thu Jan 31 22:57:20 2008 Return-Path: X-Original-To: ietfarch-discuss-archive@core3.amsl.com Delivered-To: ietfarch-discuss-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1013C3A6840 for ; Thu, 31 Jan 2008 22:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 79.827 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=79.827 tagged_above=-999 required=5 tests=[BANG_GUAR=0.939, BAYES_99=3.5, DATE_IN_FUTURE_12_24=2.189, DOS_OE_TO_MX=2.75, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FB_CIALIS_LEO3=3.899, FORGED_YAHOO_RCVD=2.297, FUZZY_CPILL=0.001, FUZZY_PRICES=1.304, GB_PHARMACY=1, HELO_DYNAMIC_DHCP=1.398, HTML_MESSAGE=1, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_41=0.6, MANGLED_CIALIS=2.5, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_OBFU_PART_ICE=1.666, SUBJECT_DRUG_GAP_C=0.003, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 0.0 SUBJECT_DRUG_GAP_C Subject contains a gappy version of 'cialis' * 2.2 DATE_IN_FUTURE_12_24 Date: is 12 to 24 hours after Received: date * 2.3 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 0.6 J_CHICKENPOX_41 BODY: 4alpha-pock-1alpha * 1.3 FUZZY_PRICES BODY: Attempt to obfuscate words in spam * 2.5 MANGLED_CIALIS BODY: mangled Cialis * 0.6 J_CHICKENPOX_23 BODY: 2alpha-pock-3alpha * 3.9 FB_CIALIS_LEO3 BODY: Uses a mis-spelled version of cialis. * 0.9 BANG_GUAR BODY: Something is emphatically guaranteed * 0.6 J_CHICKENPOX_32 BODY: 3alpha-pock-2alpha * 0.0 FUZZY_CPILL BODY: Attempt to obfuscate words in spam * 1.0 GB_PHARMACY BODY: I smoke two joints at night. * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: travelthus.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: travelthus.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: travelthus.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: travelthus.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [58.182.220.15 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 1.5 DRUGS_ERECTILE_OBFU Obfuscated reference to an erectile drug * 1.0 DRUGS_ERECTILE Refers to an erectile drug * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 1.7 SARE_OBFU_PART_ICE obfusciation of word containing ice * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Yo6Qm9BXS0D for ; Thu, 31 Jan 2008 22:57:19 -0800 (PST) Received: from cm15.kappa220.maxonline.com.sg (cm15.kappa220.maxonline.com.sg [58.182.220.15]) by core3.amsl.com (Postfix) with ESMTP id 3BFAE3A681C for ; Thu, 31 Jan 2008 22:57:16 -0800 (PST) Message-ID: <000a01c86525$02e98733$35dd8aab@hcvscxux> From: "art kerry" To: Subject: ***SPAM*** 79.827 (5) CIA-LIS - Cheapest Pri-ces and 100% Satisfaction Guaranteed! Date: Fri, 01 Feb 2008 21:10:52 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C86525.02E5B175" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C86525.02E5B175 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Taking tadalafil with any of these medications may cause very low blood = pressure, possibly resulting in dizziness, fainting, stroke, or heart = attack. CIAL1S - From a pharmacy that believes in providing excellent services = and the cheapest pr1ces Ind1an cheeap meedss ------=_NextPart_000_0007_01C86525.02E5B175 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Taking tadalafil with any of these medications may cause very low = blood pressure, possibly resulting in dizziness, fainting, stroke, or = heart attack.

CIAL1S - From a = pharmacy that believes in providing excellent services and the cheapest = pr1ces Ind1an cheeap meedss

------=_NextPart_000_0007_01C86525.02E5B175--