Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E933A6E8E for ; Tue, 21 Apr 2009 14:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfOZRlnQxEEy for ; Tue, 21 Apr 2009 14:39:56 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 0C1143A6E60 for ; Tue, 21 Apr 2009 14:39:56 -0700 (PDT) Received: from c-75-68-112-157.hsd1.nh.comcast.net ([75.68.112.157] helo=[192.168.45.103]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LwNi9-0005lW-OZ for apps-review@ietf.org; Tue, 21 Apr 2009 14:41:02 -0700 Message-Id: <9D578B62-BE65-4D8C-9A68-9B0CB735AD4B@standardstrack.com> From: Eric Burger To: apps-review@ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-142-49862343; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 21 Apr 2009 17:41:07 -0400 X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [APPS-REVIEW] Updated Status Page X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 21:39:57 -0000 --Apple-Mail-142-49862343 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I have updated the status page, http://www.standardstrack.com/ietf/apps-review/ Please check it for accuracy. In particular, you may note a tick-mark (') under your current Document Being Reviewed. This means that I am waiting for YOU to reply to me directly, letting me know you still want to be on the review team. If I do not hear from you by 8 May 2009, we will drop you from the list. If you know of other people that want to be on the review team, or you want to be on the team but are not on the web page, let me know. Things should pick up, as we plan on reviewing most APPs documents, as well as many RAI and a few SEC documents. Thanks. -- - Eric --Apple-Mail-142-49862343 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA0MjEyMTQxMDdaMCMGCSqGSIb3 DQEJBDEWBBSgaeNqnr1lzCcQK3MJBvA5wPzwSjCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQDBb4rzhzi540jZziwS62Mg/cYf/aYBiDD6ccf7Cmi7Im3y cs0Gevl6Jhy3DELzuX3gOnXrYmHRg6rs1v5U+Tkj0h6Kpoqw7v1XWLAv7FXUI/MhduSuvS4vXj3R Cn8BvHx1jxC68vZ21dbSI/Z3RviuS8HR6qfYuGpS+Rm1w0GZkjxniOMu9Qu0bP1vcjx90pVH9+qn FTBy/ZYItStW2c7YzVQU9a35N/GkU5d1AjN3qLeezAcowh2DKTNuafRBKhfAYg1jOcKSIKyHqzp2 3B/JXQaVz0OBdPtiy+ntZohYZ7tpjBXvfDLgAEYdWLoIvnTC+PPRbq0nxxhuv1sVJ+xWAAAAAAAA --Apple-Mail-142-49862343-- Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2563A6B3D for ; Thu, 16 Apr 2009 02:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfNNr7uzLWhl for ; Thu, 16 Apr 2009 02:16:49 -0700 (PDT) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by core3.amsl.com (Postfix) with ESMTP id CC4243A67AE for ; Thu, 16 Apr 2009 02:16:48 -0700 (PDT) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090416091800.OTXW7670.mtaout03-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Thu, 16 Apr 2009 10:18:00 +0100 Received: from [192.168.1.2] (really [86.12.211.140]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090416091800.WBMO21638.aamtaout02-winn.ispmail.ntl.com@[192.168.1.2]>; Thu, 16 Apr 2009 10:18:00 +0100 Message-ID: <49E6F7EC.5080500@philarcher.org> Date: Thu, 16 Apr 2009 10:18:36 +0100 From: Phil Archer User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: apps-review@ietf.org References: <49D9C099.3060701@philarcher.org> <1926E28C-CA7B-4CB3-AD7D-0DCEE799A2F5@w3.org> In-Reply-To: <1926E28C-CA7B-4CB3-AD7D-0DCEE799A2F5@w3.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.0 c=1 a=SSmOFEACAAAA:8 a=RFp60smDAAAA:8 a=Ebs0h9rcAAAA:8 a=tcGdlNM-4JZXDPdn8AwA:9 a=5qYNHMN5o-sm520rQI4A:7 a=s8k9HM1H02Q_dOtqqvO5-dSSV8IA:4 a=69XIa8IdTDMA:10 a=B5i4q5-H4aEA:10 a=1t38KPnuYoIA:10 a=fv2WYZwdpCgA:10 X-Mailman-Approved-At: Thu, 16 Apr 2009 08:24:58 -0700 Subject: Re: [APPS-REVIEW] Fwd: POWDER 3rd Last Call open X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 09:16:50 -0000 Thanks for sending this, Thomas. I just wanted to add a pointer to a relevant update at http://lists.w3.org/Archives/Public/public-powderwg/2009Apr/0006.html Cheers Phil POWDER WG Thomas Roessler wrote: > Hello, > > since the last call below is relevant to IRI comparison issues, some > review from this community would be really useful, specifically for the > POWDER grouping spec, section 2.1. > > The last call ends on 27 April, and they intend to go to Proposed > Recommendation right away. > > Regards, > -- > Thomas Roessler, W3C > > > > > > > > Begin forwarded message: > >> From: Phil Archer >> Date: 6 April 2009 10:43:05 GMT+02:00 >> To: chairs@w3.org, www-tag@w3.org, Daniel Appelquist >> , jrabin@mtld.mobi, >> team-rif-chairs@w3.org, schreiber@cs.vu.nl, >> baker@sub.uni-goettingen.de, "Ralph R. Swick" , Shadi >> Abou-Zahra , shawn@w3.org, jbrewer@w3.org, dsr@w3.org, >> W3C Pics Interest >> Subject: POWDER 3rd Last Call open >> Archived-At: >> >> Hello Chairs, and the chairs of MWBP, RIF, WAI, SWDWG, UWA, and XML >> Activity, as well as the TAG and PICS IG, >> >> The POWDER Working Group has been developing a suite of documents that >> specify a protocol for publishing descriptions of Web resources. The >> documents have already had wide review and the group has running code. >> However, an internal team review of one document has prompted the >> working group to make a third Last Call announcement, highlighting one >> particular area. >> >> * POWDER: Grouping of Resources >> http://www.w3.org/TR/2009/WD-powder-grouping-20090403/ >> >> includes sections on IRI canonicalization (section 2.1.3 - 2.1.5) and it >> is this that we are keen to ensure is correct. >> >> Two other Recommendations Track documents have undergone editorial >> changes since the previous Last Call (made in November 2008) and no >> substantive changes are expected to be made before the group seeks >> transition to Proposed Recommendation. They are: >> >> * POWDER: Formal Semantics >> http://www.w3.org/TR/2009/WD-powder-formal-20090403/ >> >> * POWDER: Description Resources >> http://www.w3.org/TR/2009/WD-powder-dr-20090403/ >> >> The Working Group has also published two updated Working Drafts that are >> expected to become Working Group Notes: >> >> * POWDER: Primer >> http://www.w3.org/TR/2009/WD-powder-primer-20090403/ >> >> * POWDER: Test Suite >> http://www.w3.org/TR/2009/WD-powder-test-20090403/ >> >> We welcome feedback on these publications through to Monday 27th April >> as well. >> >> >> >> -- >> >> Phil Archer >> http://philarcher.org/www@20/ >> >> i-sieve technologies | W3C Mobile Web Initiative >> Making Sense of the Buzz | www.w3.org/Mobile >> > > -- Phil Archer http://philarcher.org/www@20/ i-sieve technologies | W3C Mobile Web Initiative Making Sense of the Buzz | www.w3.org/Mobile Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD16128C166 for ; Tue, 14 Apr 2009 07:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.644 X-Spam-Level: X-Spam-Status: No, score=-104.644 tagged_above=-999 required=5 tests=[AWL=-2.667, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe+tQ5LbG6aK for ; Tue, 14 Apr 2009 07:50:30 -0700 (PDT) Received: from mail-qy0-f134.google.com (mail-qy0-f134.google.com [209.85.221.134]) by core3.amsl.com (Postfix) with ESMTP id 1F1B93A67D7 for ; Tue, 14 Apr 2009 07:50:30 -0700 (PDT) Received: by qyk40 with SMTP id 40so1138103qyk.29 for ; Tue, 14 Apr 2009 07:51:41 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.229.94.133 with SMTP id z5mr2082907qcm.38.1239720691601; Tue, 14 Apr 2009 07:51:31 -0700 (PDT) In-Reply-To: <49E3AF25.6070004@tibco.com> References: <498B7309.5080006@alvestrand.no> <49C43146.1070100@tibco.com> <49C483AD.2000700@alvestrand.no> <49E3AF25.6070004@tibco.com> Date: Tue, 14 Apr 2009 10:51:31 -0400 X-Google-Sender-Auth: b928b29ffe4c08a8 Message-ID: From: Mark Baker To: "SOAP/JMS (list)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Lisa Dusseault , apps-review@ietf.org Subject: Re: [APPS-REVIEW] Review of draft-merrick-jms-uri-05 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 14:50:30 -0000 On Mon, Apr 13, 2009 at 5:31 PM, Eric Johnson wrote: > As I pointed out in the email to Harald (are you on that mailing list?), > the jms URI, as spec'd, could be global in scope. =A0For example, the > jndiURL parameter could point to a remote, globally accessible JNDI host. But AIUI, even that doesn't provide sufficient context to permit a third party to exchange information with the service, right? Anyhow, even if I'm mistaken about that, the important point is that this property isn't intrinsic to the scheme. > As a few simple counterpoints, the "file", "opaquelocktoken", "cid", and > "mid" URI schemes has a similarly local interpretation, but a global use. I don't see those as analogous. file URIs (even those without host parts) aren't interpreted locally, they're just resolved locally. Their interpretation is global. For example, "file:///etc/passwd" globally identifies the local /etc/passwd file, but of course, dereferences to a different file depending upon where it was resolved. For jms URI, only when a producer and consumer share the same context is an interpretation consistent. It's somewhat akin to defining a file-like scheme that used "foo:///asdfasdfas" to identify the local /etc/group file, where the knowledge of that mapping wasn't part of the scheme definition, or otherwise obtainable by any potential consumer of that URI. Mark. Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591943A6A03 for ; Tue, 14 Apr 2009 01:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPCt+Gg+IKe6 for ; Tue, 14 Apr 2009 01:03:24 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 3731F3A696B for ; Tue, 14 Apr 2009 01:03:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E065539E27E; Tue, 14 Apr 2009 10:04:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wpe9M3+i6EGL; Tue, 14 Apr 2009 10:04:30 +0200 (CEST) Received: from hta-warp.trd.corp.google.com (unknown [195.18.164.170]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 386E539E243; Tue, 14 Apr 2009 10:04:30 +0200 (CEST) Message-ID: <49E4438D.8050303@alvestrand.no> Date: Tue, 14 Apr 2009 10:04:29 +0200 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "SOAP/JMS (list)" References: <498B7309.5080006@alvestrand.no> <49C43146.1070100@tibco.com> <49C483AD.2000700@alvestrand.no> <49E3AF25.6070004@tibco.com> In-Reply-To: <49E3AF25.6070004@tibco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lisa Dusseault , apps-review@ietf.org Subject: Re: [APPS-REVIEW] Review of draft-merrick-jms-uri-05 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 08:03:25 -0000 Just commenting on comparable schemes.... Eric Johnson wrote: > Hi Mark, > > Thanks again for your additional feedback. > > Mark Baker wrote: > >> On Fri, Mar 20, 2009 at 11:05 PM, Harald Alvestrand >> wrote: >> >>> Thanks - those words help. >>> The important point is that use of the URI depends on a shared context, and >>> that context cannot be identified from the URI. Indeed, there may be valid >>> cases where the same URI is resolvable in two different contexts, with two >>> different results. >>> >>> That leaves me sad, because it is exactly opposite to what the "U" in "URI" >>> sometimes stood for, >>> >> Me too 8-( >> > > As I pointed out in the email to Harald (are you on that mailing list?), > the jms URI, as spec'd, could be global in scope. For example, the > jndiURL parameter could point to a remote, globally accessible JNDI host. > > It is certainly hard for us to know whether this current situation is an > accident of the historical adoption of JMS, or whether it generally > isn't useful on the internet global scope. > > Certainly, one of the reasons we're putting this proposal forward is to > facilitate the adoption of SOAP over JMS. This seems relevant to me, > because we currently have an enormous amount of code and effort going > into handling SOAP messages over HTTP in a reliable and secure fashion. > With JMS, you get these characteristics (almost) without having to > define additional layers of specification to handle reliability and > encryption at the payload layer. > > Given an available standard for SOAP over JMS, could that drive a more > global use for JMS itself? Hard to say. > > As a few simple counterpoints, the "file", "opaquelocktoken", "cid", and > "mid" URI schemes has a similarly local interpretation, but a global use. > "cid" and "mid" are defined to be globally unique. They don't have a resolution mechanism, but by definition, they are globally unique. "opaquelocktoken" is based on an UUID (another globally unique item without a lookup mechanism), and its definition says: An opaquelocktoken URI is constructed by concatenating the 'opaquelocktoken' scheme with a UUID, along with an optional extension. Servers can create new UUIDs for each new lock token. If a server wishes to reuse UUIDs, the server MUST add an extension, and the algorithm generating the extension MUST guarantee that the same extension will never be used twice with the associated UUID. I won't attemt to defend "file". Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BD53A6EC9 for ; Mon, 13 Apr 2009 14:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StK0ro7taMbq for ; Mon, 13 Apr 2009 14:29:47 -0700 (PDT) Received: from mx2.tibco.com (mx2.tibco.com [63.100.100.182]) by core3.amsl.com (Postfix) with ESMTP id 0F04E3A6BD7 for ; Mon, 13 Apr 2009 14:29:47 -0700 (PDT) Received: from mx2.tibco.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DBE871F0365; Mon, 13 Apr 2009 14:30:56 -0700 (PDT) Received: from na-pa-fe02.na.tibco.com (tibco-5.tibco.com [63.100.100.5]) by mx2.tibco.com (Postfix) with ESMTP id C7B831F0358; Mon, 13 Apr 2009 14:30:52 -0700 (PDT) Received: from [10.98.36.57] ([10.98.36.57]) by na-pa-fe02.na.tibco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 14:30:52 -0700 Message-ID: <49E3AF25.6070004@tibco.com> Date: Mon, 13 Apr 2009 14:31:17 -0700 From: Eric Johnson User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: Mark Baker References: <498B7309.5080006@alvestrand.no> <49C43146.1070100@tibco.com> <49C483AD.2000700@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2009 21:30:52.0677 (UTC) FILETIME=[1F2E5B50:01C9BC7F] Cc: "SOAP/JMS \(list\)" , Lisa Dusseault , apps-review@ietf.org Subject: Re: [APPS-REVIEW] Review of draft-merrick-jms-uri-05 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "SOAP/JMS \(list\)" List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 21:29:48 -0000 Hi Mark, Thanks again for your additional feedback. Mark Baker wrote: > On Fri, Mar 20, 2009 at 11:05 PM, Harald Alvestrand > wrote: >> Thanks - those words help. >> The important point is that use of the URI depends on a shared context, and >> that context cannot be identified from the URI. Indeed, there may be valid >> cases where the same URI is resolvable in two different contexts, with two >> different results. >> >> That leaves me sad, because it is exactly opposite to what the "U" in "URI" >> sometimes stood for, > > Me too 8-( As I pointed out in the email to Harald (are you on that mailing list?), the jms URI, as spec'd, could be global in scope. For example, the jndiURL parameter could point to a remote, globally accessible JNDI host. It is certainly hard for us to know whether this current situation is an accident of the historical adoption of JMS, or whether it generally isn't useful on the internet global scope. Certainly, one of the reasons we're putting this proposal forward is to facilitate the adoption of SOAP over JMS. This seems relevant to me, because we currently have an enormous amount of code and effort going into handling SOAP messages over HTTP in a reliable and secure fashion. With JMS, you get these characteristics (almost) without having to define additional layers of specification to handle reliability and encryption at the payload layer. Given an available standard for SOAP over JMS, could that drive a more global use for JMS itself? Hard to say. As a few simple counterpoints, the "file", "opaquelocktoken", "cid", and "mid" URI schemes has a similarly local interpretation, but a global use. Question: How is the proposed "jms" scheme different in character from the above? > > IMO this registration should be provisional, not permanent, because it > doesn't meet the requirements of sec 2.1 of RFC 4395; That could be an interesting option. I have to say, I poked around for a while, and was not able formulate any clear understanding of what a "provisional" registration meant, other than that one "should" adhere to the requirements for a URI that one normally "must" adhere to. It doesn't look like it is used much, given the vast difference between: http://esw.w3.org/topic/UriSchemes/ http://en.wikipedia.org/wiki/URI_scheme#Unofficial_but_common_URI_schemes and the provisional list at http://www.iana.org/assignments/uri-schemes.html > > The use and deployment of new URI schemes in the Internet > infrastructure is costly; some parts of URI processing may be > scheme-dependent, and deployed software already processes URIs of > well-known schemes. Introducing a new URI scheme may require > additional software, not only for client software and user agents but > also in additional parts of the network infrastructure (gateways, > proxies, caches) [11]. URI schemes constitute a single, global > namespace; it is desirable to avoid contention over use of short, > mnemonic scheme names. For these reasons, the unbounded registration > of new schemes is harmful. New URI schemes SHOULD have clear utility > to the broad Internet community, beyond that available with already > registered URI schemes. What criteria, here, exactly, do you think we're missing? I don't know of any contention over the use of the "jms" scheme. JMS software is widely deployed, but obviously cannot take advantage of a JMS URI scheme without one being defined. As for clear utility, I'm aware of /two/ specifications that are already using the "jms" scheme as proposed, and would like to see it completed. -Eric. Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23ADE3A6DC7 for ; Mon, 13 Apr 2009 12:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kulketkOzBU4 for ; Mon, 13 Apr 2009 12:00:38 -0700 (PDT) Received: from mx1.tibco.com (mx1.tibco.com [63.100.100.181]) by core3.amsl.com (Postfix) with ESMTP id 958003A691B for ; Mon, 13 Apr 2009 12:00:30 -0700 (PDT) Received: from mx1.tibco.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7E9B14C40A; Mon, 13 Apr 2009 12:01:41 -0700 (PDT) Received: from na-pa-fe02.na.tibco.com (tibco-5.tibco.com [63.100.100.5]) by mx1.tibco.com (Postfix) with ESMTP id 5DB9A4C3E5; Mon, 13 Apr 2009 12:01:38 -0700 (PDT) Received: from [10.98.36.57] ([10.98.36.57]) by na-pa-fe02.na.tibco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 12:01:38 -0700 Message-ID: <49E38C2A.8080104@tibco.com> Date: Mon, 13 Apr 2009 12:02:02 -0700 From: Eric Johnson User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: Harald Alvestrand References: <498B7309.5080006@alvestrand.no> <49C43146.1070100@tibco.com> <49C483AD.2000700@alvestrand.no> In-Reply-To: <49C483AD.2000700@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2009 19:01:38.0052 (UTC) FILETIME=[45CF0440:01C9BC6A] Cc: "SOAP/JMS \(list\)" , Lisa Dusseault , apps-review@ietf.org Subject: Re: [APPS-REVIEW] Review of draft-merrick-jms-uri-05 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "SOAP/JMS \(list\)" List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 19:00:39 -0000 Hi Harald, Further responses, inline below. Harald Alvestrand wrote: > Eric Johnson wrote: >> Hi Harald, >> >> Thank you for your feedback. Sorry for the long delay in responding >> to you. >> >> The SOAP/JMS working group at the W3C has a response to all but one of >> your concerns, I think. Those responses are noted below. >> >> Harald Alvestrand wrote: >> >>> Document: draft-merrick-jms-uri-05 >>> Reviewer: Harald Tveit Alvestrand >>> Type of review: Apps area review >>> Date: February 5, 2009 >>> [snip] >>> >>> I think it a pity that the examples given give the impression that these >>> mechanisms are strictly local in scope - a "jndi name" of REQ_QUEUE, and >>> a "jndiURL" of file:/C:/JMSadmin both give the impression that these >>> URLs won't ever be resolvable outside of a quite local context. >>> I suspect that it is possible to construct JMS URLs that can be shared >>> globally with an expectation of uniform interpretation - if such exist, >>> it would be better for the document if they had been used in examples. >>> >>> >> >> The answer is slightly more subtle - JMS URIs can span the globe, but >> that implies a shared context that also spans the globe. I'm thinking >> that the following additional paragraph in the introduction might help >> to clarify: >> >> As a consequence of building upon an API, rather than a protocol, the >> utility of a "jms" URI depends on the context in which it is used. >> Critical details affecting utility include agreement on the same JMS >> provider or underlying protocol, agreement on the context for looking up >> endpoints, and when using serialized Java object messages, sufficiently >> similiar Java Class environments that the object can be appropriately >> read and written. Uses of this scheme must establish the necessary >> shared context - a context which can span the globe, or merely a small >> local network. With that shared context, this URI scheme enables >> endpoint identification in a uniform way, and the means to connect to >> those endpoints. >> > Thanks - those words help. > The important point is that use of the URI depends on a shared context, > and that context cannot be identified from the URI. Indeed, there may be > valid cases where the same URI is resolvable in two different contexts, > with two different results. > > That leaves me sad, because it is exactly opposite to what the "U" in > "URI" sometimes stood for, but it's a valid specifier choice. The added > paragraph indeed makes it clearer. It is possible, with the current definition, to have a jms URI that points to its JNDI server somewhere "out there." So all is not lost. It just seems like an unlikely case, given how JMS is currently deployed. >>> >>> - in section 4.1, some "shared" parameters are defined, but in section >>> 4, it says that new variants can be defined, whose parameters should >>> begin with the variant name as prefix (without specifying a separator >>> character). Is there an expectation that there will never be a variant >>> called "delivery", "time" or "priority"? If so, should this expectation >>> be documented? (what about the "del" variant? possible or not?) >>> >>> >> >> I've been aware of this this point since we introduced the variants. I >> see variants as so rare that this is essentially a moot issue. In >> practice, I think there is at most one additional variant per vendor, >> and the market pressures are such that there will not be many >> implementations. >> > Is there a reason to claim a registry for variants? >> >> >>> - in section 4.2.1, it seems somewhat bizarre that the JNDI-specific >>> parameters all start with "jndi", while section 4.2.1.4 states that >>> additional JNDI-specific parameters should start wiht "jndi-" (note the >>> additional dash). Why not be uniform? >>> >> >> We're still discussing this in the working group. We've not settled on >> an answer because I think there multiple tensions here, such as between >> brevity and completeness, familiarity vs. convention, and so forth. >> We'll hopefully have a more complete answer soon. >> > Good. Here's the break-down. There are actually three classes of properties being specified in the parameters: 1. Standard properties for identifying JNDI * jndiInitialContextFactory * jndiURL 2. Custom properties for connecting to JNDI - need to spell out the runtime name for these parameters. * Parameters we currently suggest start with "jndi-" 3. JDNI Resources to retrieve once connected\ * jndiConnectionFactoryName We use the hyphen in case #2 to flag that what follows the hyphen is an actual string value for the name of a property to set when constructing the Map for the initial context. We discussed always using the actual Java constants even for case #1, but that would mean that instead of specifying "jndiURL", we'd have to specify: * jndi-java.naming.provider.url (jndiURL) * jndi-java.naming.factory.initial (jndiInitialContextFactory) In this case, we think convention, brevity, and clarity trumps consistency, in that most JMS developers think of the "jndiURL" instead of the "java.naming.provider.url" That does, however, leave the question open - what should we do about the "jndi-" case, where the URI needs to contain the actual name of the property to use? We had chosen the "jndi-" prefix over an alternate prefix of "jndiContextParameter-", because we thought that we didn't lose much in the brevity. Now that we observe that we apparently did lose something in the brevity. In our first encounter outside our working group we got the equivalent of a "huh?" from you. To remedy, we propose switching back to the more verbose prefix of "jndiContextParameter-". Do you think switching prefixes allays your concerns? >> >>> - the fact that the URI needs to be in UTF-8 only surfaces in section 5, >>> long after the definition of the URI, and long after I'd started >>> wondering about it. I think it would be better if this section was moved >>> up after section 3, just after the URI syntax is defined. >>> >> >> There's a trade-off here. We could move the entire section here up to >> be a sub-section of #3. I think there's some value to having an top >> level-"encoding considerations" section called out in the TOC, and I >> don't see how we move that closer to the front. >> > One way would be to place in #3 a note saying "The URIs are > percent-encoded UTF-8. See section 5 for encoding considerations". Excellent. I'll keep this in mind for the next small round of edits. Thanks again for your time. -Eric Johnson. Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B39F3A6B72 for ; Fri, 10 Apr 2009 00:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.589 X-Spam-Level: X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, RCVD_IN_SBL=1.551, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVWYdKU86oq3 for ; Fri, 10 Apr 2009 00:02:09 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 39F053A6845 for ; Fri, 10 Apr 2009 00:02:09 -0700 (PDT) Received: from [92.40.71.134] (92.40.71.134.sub.mbb.three.co.uk [92.40.71.134]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 10 Apr 2009 08:03:16 +0100 Message-ID: <49DEEF1C.3030703@isode.com> Date: Fri, 10 Apr 2009 08:02:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-review@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [APPS-REVIEW] Request for review of draft-ietf-ltru-4645bis-10.txt and draft-ietf-ltru-4646bis-21.txt X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 07:02:10 -0000 Hi, As an AD who needs to review draft-ietf-ltru-4645bis-10.txt and draft-ietf-ltru-4646bis-21.txt I would like to request some additional reviews of these documents from somebody who wasn't involved in LTRU discussions and (ideally) have some ideas about language tags. Thanks, Alexey Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1CA53A6BCA for ; Mon, 6 Apr 2009 01:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59jDvKxHvMUQ for ; Mon, 6 Apr 2009 01:56:50 -0700 (PDT) Received: from homer.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 5B3863A6C0D for ; Mon, 6 Apr 2009 01:56:50 -0700 (PDT) Received: from iCoaster.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id D30084EF77; Mon, 6 Apr 2009 04:57:54 -0400 (EDT) Received: from localhost ([127.0.0.1]) by iCoaster.does-not-exist.org with esmtp (Exim 4.66) (envelope-from ) id KHO8WI-001WIE-BM; Mon, 06 Apr 2009 10:57:54 +0200 Message-Id: <1926E28C-CA7B-4CB3-AD7D-0DCEE799A2F5@w3.org> From: Thomas Roessler To: apps-review@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-67-855552832 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 6 Apr 2009 10:57:54 +0200 References: <49D9C099.3060701@philarcher.org> X-Mailer: Apple Mail (2.930.3) Cc: Phil Archer Subject: [APPS-REVIEW] Fwd: POWDER 3rd Last Call open X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 08:56:52 -0000 --Apple-Mail-67-855552832 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, since the last call below is relevant to IRI comparison issues, some review from this community would be really useful, specifically for the POWDER grouping spec, section 2.1. The last call ends on 27 April, and they intend to go to Proposed Recommendation right away. Regards, -- Thomas Roessler, W3C Begin forwarded message: > From: Phil Archer > Date: 6 April 2009 10:43:05 GMT+02:00 > To: chairs@w3.org, www-tag@w3.org, Daniel Appelquist >, jrabin@mtld.mobi, team-rif-chairs@w3.org, schreiber@cs.vu.nl, baker@sub.uni-goettingen.de > , "Ralph R. Swick" , Shadi Abou-Zahra , shawn@w3.org > , jbrewer@w3.org, dsr@w3.org, W3C Pics Interest interest@w3.org> > Subject: POWDER 3rd Last Call open > Archived-At: > > Hello Chairs, and the chairs of MWBP, RIF, WAI, SWDWG, UWA, and XML > Activity, as well as the TAG and PICS IG, > > The POWDER Working Group has been developing a suite of documents that > specify a protocol for publishing descriptions of Web resources. The > documents have already had wide review and the group has running code. > However, an internal team review of one document has prompted the > working group to make a third Last Call announcement, highlighting one > particular area. > > * POWDER: Grouping of Resources > http://www.w3.org/TR/2009/WD-powder-grouping-20090403/ > > includes sections on IRI canonicalization (section 2.1.3 - 2.1.5) > and it > is this that we are keen to ensure is correct. > > Two other Recommendations Track documents have undergone editorial > changes since the previous Last Call (made in November 2008) and no > substantive changes are expected to be made before the group seeks > transition to Proposed Recommendation. They are: > > * POWDER: Formal Semantics > http://www.w3.org/TR/2009/WD-powder-formal-20090403/ > > * POWDER: Description Resources > http://www.w3.org/TR/2009/WD-powder-dr-20090403/ > > The Working Group has also published two updated Working Drafts that > are > expected to become Working Group Notes: > > * POWDER: Primer > http://www.w3.org/TR/2009/WD-powder-primer-20090403/ > > * POWDER: Test Suite > http://www.w3.org/TR/2009/WD-powder-test-20090403/ > > We welcome feedback on these publications through to Monday 27th April > as well. > > > > -- > > Phil Archer > http://philarcher.org/www@20/ > > i-sieve technologies | W3C Mobile Web Initiative > Making Sense of the Buzz | www.w3.org/Mobile > --Apple-Mail-67-855552832 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello,

since = the last call below is relevant to IRI comparison issues, some review = from this community would be really useful, specifically for the POWDER = grouping spec, section 2.1.

The last call ends = on 27 April, and they intend to go to Proposed Recommendation right = away.

Regards,
--
Thomas Roessler, W3C  <tlr@w3.org>





=

Begin forwarded message:

From: = Phil Archer <phil@philarcher.org>
Date: = 6 April 2009 10:43:05 GMT+02:00
Hello = Chairs, and the chairs of MWBP, RIF, WAI, SWDWG, UWA, and = XML
Activity, as well as the TAG and PICS IG,

The POWDER = Working Group has been developing a suite of documents that
specify a = protocol for publishing descriptions of Web resources. The
documents = have already had wide review and the group has running code.
However, = an internal team review of one document has prompted the
working = group to make a third Last Call announcement, highlighting = one
particular area.

* POWDER: Grouping of Resources
=  http://www= .w3.org/TR/2009/WD-powder-grouping-20090403/

includes = sections on IRI canonicalization (section 2.1.3 - 2.1.5) and it
is = this that we are keen to ensure is correct.

Two other = Recommendations Track documents have undergone editorial
changes = since the previous Last Call (made in November 2008) and = no
substantive changes are expected to be made before the group = seeks
transition to Proposed Recommendation. They are:

* = POWDER: Formal Semantics
 http://www.w= 3.org/TR/2009/WD-powder-formal-20090403/

* POWDER: = Description Resources
 http://www.w3.or= g/TR/2009/WD-powder-dr-20090403/

The Working Group has also = published two updated Working Drafts that are
expected to become = Working Group Notes:

* POWDER: Primer
 http://www.w= 3.org/TR/2009/WD-powder-primer-20090403/

* POWDER: Test = Suite
 http://www.w3.= org/TR/2009/WD-powder-test-20090403/

We welcome feedback on = these publications through to Monday 27th April
as = well.



--

Phil Archer
http://philarcher.org/www@20/
i-sieve technologies =             &n= bsp;  |      W3C Mobile Web = Initiative
Making Sense of the Buzz =            | =      www.w3.org/Mobile


= --Apple-Mail-67-855552832--