From katia@flatrate.dk Fri Feb 1 02:59:59 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD3DC3A68F6 for ; Fri, 1 Feb 2008 02:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 65.796 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=65.796 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SUBJECT_FUZZY_MEDS=3.799, URIBL_BLACK=20, URIBL_JP_SURBL=10, 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] * 1.9 HOST_EQ_PL HOST_EQ_PL * 1.1 HELO_EQ_PL HELO_EQ_PL * 1.1 HELO_EQ_DSL HELO_EQ_DSL * 3.8 SUBJECT_FUZZY_MEDS Attempt to obfuscate words in Subject: * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 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/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: 75.129.160.118] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: 75.129.160.118] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: 75.129.160.118] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [83.7.146.192 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [83.7.146.192 listed in zen.spamhaus.org] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: 75.129.160.118] 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 oXYPJdjcjnVC for ; Fri, 1 Feb 2008 02:59:59 -0800 (PST) Received: from abje192.neoplus.adsl.tpnet.pl (abje192.neoplus.adsl.tpnet.pl [83.7.146.192]) by core3.amsl.com (Postfix) with SMTP id DCB8E3A68FF for ; Fri, 1 Feb 2008 02:59:55 -0800 (PST) Received: from yilbu ([94.210.64.206]) by abje192.neoplus.adsl.tpnet.pl with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Feb 2008 12:01:24 +0100 Message-ID: <47A2FC04.3030600@flatrate.dk> Date: Fri, 1 Feb 2008 12:01:24 +0100 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: ***SPAM*** 65.796 (5) Looking for the best pricein medz? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit PopularED's delivered fast http://75.129.160.118/nuxmej/ From avilchez@mail.pf Fri Feb 1 03:01:12 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0385C3A680F for ; Fri, 1 Feb 2008 03:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 31.997 X-Spam-Level: ******************************* X-Spam-Status: Yes, score=31.997 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.9 HOST_EQ_PL HOST_EQ_PL * 1.1 HELO_EQ_PL HELO_EQ_PL * 1.1 HELO_EQ_DSL HELO_EQ_DSL * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 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/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: 122.36.9.216] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: 122.36.9.216] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [83.7.146.192 listed in zen.spamhaus.org] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [83.7.146.192 listed in dnsbl.sorbs.net] 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 hKd7W6GkvubA for ; Fri, 1 Feb 2008 03:01:11 -0800 (PST) Received: from abje192.neoplus.adsl.tpnet.pl (abje192.neoplus.adsl.tpnet.pl [83.7.146.192]) by core3.amsl.com (Postfix) with SMTP id 8F1BD3A690F for ; Fri, 1 Feb 2008 03:01:08 -0800 (PST) Received: from cxp ([35.64.163.33]) by abje192.neoplus.adsl.tpnet.pl with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Feb 2008 12:02:41 +0100 Message-ID: <47A2FC51.6060103@mail.pf> Date: Fri, 1 Feb 2008 12:02:41 +0100 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: atompub-archive@megatron.ietf.org Subject: ***SPAM*** 31.997 (5) Doctors endorse this miracle formula! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Medical news http://122.36.9.216/lvojqp/ From iscerale@alleninsurance.org Fri Feb 1 04:31:51 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8633A67D0 for ; Fri, 1 Feb 2008 04:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 48.922 X-Spam-Level: ************************************************ X-Spam-Status: Yes, score=48.922 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HTML_MESSAGE=1, J_CHICKENPOX_42=0.6, 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_SORBS_DUL=0.877, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_DYNAMIC HELO_EQ_DYNAMIC * 0.6 HELO_EQ_IT HELO_EQ_IT * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 0.6 J_CHICKENPOX_42 BODY: 4alpha-pock-2alpha * 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: ookbast.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: ookbast.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 * [87.13.81.106 listed in zen.spamhaus.org] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [87.13.81.106 listed in dnsbl.sorbs.net] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 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 ig6qm6N1LZ+e for ; Fri, 1 Feb 2008 04:31:50 -0800 (PST) Received: from host106-81-dynamic.13-87-r.retail.telecomitalia.it (unknown [87.13.81.106]) by core3.amsl.com (Postfix) with ESMTP id DCBAF3A687A for ; Fri, 1 Feb 2008 04:31:49 -0800 (PST) Message-ID: <000b01c864ce$a861ee50$6a510d57@pclorenzo> From: "faron wamback" To: atompub-archive@lists.ietf.org Subject: ***SPAM*** 48.922 (5) Total penetration is now assured with your new huge schl0ng. Date: Fri, 1 Feb 2008 13:33:33 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0007_01C864D7.0A265650" 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 ----------=_NextPart_000_0007_01C864D7.0A265650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Amaze your chick with your new legendary manhood. ----------=_NextPart_000_0007_01C864D7.0A265650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Amaze your chick with your new = legendary=20 manhood. ----------=_NextPart_000_0007_01C864D7.0A265650-- From jqueline@psi.org.kh Fri Feb 1 04:31:55 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7032A3A67D0 for ; Fri, 1 Feb 2008 04:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 103.794 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=103.794 tagged_above=-999 required=5 tests=[BANG_GUAR=0.939, BAYES_99=3.5, FB_PENIS=1.66, FH_RELAY_NODNS=1.451, FRT_PENIS1=3.592, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=1, HTML_SHORT_LINK_IMG_3=0.001, J_CHICKENPOX_31=0.6, MANGLED_ENLARG=2.3, MANGLED_ENLGMN=5, MANGLED_PENIS=2.3, NORMAL_HTTP_TO_IP=0.001, 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_FORGED_WROTE=2.523, RCVD_FORGED_WROTE2=4.325, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_ADLTOBFU=0.68, SARE_HTML_A_BODY=0.742, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 4.3 RCVD_FORGED_WROTE2 RCVD_FORGED_WROTE2 * 2.5 RCVD_FORGED_WROTE Forged 'Received' header found ('wrote:' spam) * 2.3 MANGLED_PENIS BODY: mangled - Penis * 0.7 SARE_ADLTOBFU BODY: Contains OBFU adult material * 0.9 BANG_GUAR BODY: Something is emphatically guaranteed * 3.6 FRT_PENIS1 BODY: ReplaceTags: Penis * 5.0 MANGLED_ENLGMN BODY: mangled enlargement * 1.7 FB_PENIS BODY: FB_PENIS * 2.3 MANGLED_ENLARG BODY: mangled enlarge(r|s) * 0.6 J_CHICKENPOX_31 BODY: 3alpha-pock-1alpha * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 HTML_IMAGE_ONLY_20 BODY: HTML: images with 1600-2000 bytes of words * 1.0 HTML_MESSAGE BODY: HTML included in message * 0.7 SARE_HTML_A_BODY FULL: Message body has very strange HTML sequence * 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] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: khuttjine.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: khuttjine.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: khuttjine.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: khuttjine.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: khuttjine.com] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: khuttjine.com] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [190.172.166.111 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 ] * 0.0 HTML_SHORT_LINK_IMG_3 HTML is very short with a linked image * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 0.6 HELO_MISMATCH_COM HELO_MISMATCH_COM 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 qA3RYCstNBAt for ; Fri, 1 Feb 2008 04:31:54 -0800 (PST) Received: from baan.com (unknown [190.172.166.111]) by core3.amsl.com (Postfix) with SMTP id 473D23A6897 for ; Fri, 1 Feb 2008 04:31:52 -0800 (PST) Received: from 203.189.130.189 (HELO mail.psi.org.kh) by lists.ietf.org with esmtp (TNZJCLWXYLLD SLIJKI) id g7zWFQ-PU2y80-RS for atompub-archive@lists.ietf.org; Fri, 01 Feb 2008 09:33:29 -0300 Message-ID: <7b3c01c864ce$a67dec10$beaca66f@Georgette> From: "Georgette Talbot" To: "Nita Barnhart" Subject: ***SPAM*** 103.794 (5) Herbal science comes to your rescue! Date: Fri, 01 Feb 2008 09:33:29 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_31546_7BA4_01C864B5.8130B410" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2720.3000 This is a multi-part message in MIME format. ------=_NextPart_31546_7BA4_01C864B5.8130B410 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable In just a few short weeks, you`ll watch with amazement=20 as your pen!s grows into the hardest, biggest, ,thickest and most powerfu= l tool=20 you`ve ever imagined - the one you`ve constantly wanted about=20 having! No pen!s en`l@rgement system is faster, easier to use, or=20 more effective than VPXL+ - GUARANTEED}! VPXL+ IS GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR=20 PHALLUS OR YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET=20 VPXL+ AND LIVE LARGE TODAY! CHECK THIS OFFER TO SUBSTANTIALLY IMPROVE YOUR MALE PACKAGE IN THIS YEAR!= http://khuttjine=2Ecom/ Dili, with roads being barricaded and cut off by burningHospital, all die= d after being infected with Klebsiellabut the ball dipped over the crossb= ar and out of play=2E National Guard (GNR) acted, but he was discontented withaccording to hosp= ital reports=2E ------=_NextPart_31546_7BA4_01C864B5.8130B410 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
#1 DOCTOR RECOMMENDED PEN|S EN'L@RGEMENT = FORMULA!

In = just a few short weeks, you`ll watch with amazement as your pen!s
grows into the hardest, biggest, ,thickest and most powerf= ul tool
you`ve ever imagined - the one you`ve constantly wanted about=
having! No pen!s en`l@rgement system is faster, easier to use, or more effective than VPXL+ - GUARANTEED!

VPXL+ IS GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR
PHALLUS OR YOUR MONEY BA= CK - PERIOD! SO WHY WAIT? GET
VPXL+ AND LIVE LARGE TODAY!

CHECK THIS OFFER TO SUBSTANTIALLY IMPROVE YOUR MALE P= ACKAGE IN THIS YEAR!


Approximately 30,000 voters take advantage ofhospital stat= es that although the baby is in a serious
To members of the Islamic St= udents Committee, theDili, with roads being barricaded and cut off by bur= ning
Hospital, all died after being infected with Klebsiellabut the ba= ll dipped over the crossbar and out of play=2E
National Guard (GNR) ac= ted, but he was discontented withaccording to hospital reports=2E<= /FONT> ------=_NextPart_31546_7BA4_01C864B5.8130B410-- From owner-atom-syntax@mail.imc.org Fri Feb 1 07:22:51 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89023A6B5B for ; Fri, 1 Feb 2008 07:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 ku9k3TbzRDPD for ; Fri, 1 Feb 2008 07:22:48 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 510DC28C97A for ; Fri, 1 Feb 2008 07:11:44 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m11EfnWK017636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2008 07:41:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m11Efn0o017635; Fri, 1 Feb 2008 07:41:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m11EfmH5017628 for ; Fri, 1 Feb 2008 07:41:48 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 01 Feb 2008 14:41:46 -0000 Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp046) with SMTP; 01 Feb 2008 15:41:46 +0100 X-Authenticated: #163624 X-Provags-ID: V01U2FsdGVkX19nKtgHEbNnar+6gdxfj7UFsU6UDwJouUCbz6QI69 SeFG69jbmmcOi7 Date: Fri, 1 Feb 2008 15:41:45 +0100 From: Aristotle Pagaltzis To: Atom emailing list Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Message-ID: <20080201144145.GA25553@klangraum> Mail-Followup-To: Atom emailing list References: <200802010502.59500.aleksandersen+atomlist@runbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200802010502.59500.aleksandersen+atomlist@runbox.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Daniel Aleksandersen [2008-02-01 05:15]: > It is not globally unique on a per my feed basis; but it is > globally unique on a per…me…basis. Put the ISSN into a tag: URI instead of using the urn:issn: scheme. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Fri Feb 1 08:51:52 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67C128C169 for ; Fri, 1 Feb 2008 08:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 6uP6gfLpHMCG for ; Fri, 1 Feb 2008 08:51:52 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id EE40628C0EB for ; Fri, 1 Feb 2008 08:51:51 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m11GcHgK026576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2008 09:38:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m11GcHx0026575; Fri, 1 Feb 2008 09:38:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fepv02.charter.net (fepv02.charter.net [209.225.8.201]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m11GcG0b026568 for ; Fri, 1 Feb 2008 09:38:16 -0700 (MST) (envelope-from antone@geckotribe.com) Received: from aacpub01.charter.net ([10.20.200.48]) by fepv02.charter.net (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20080201163801.FZPY14661.fepv02.charter.net@aacpub01.charter.net> for ; Fri, 1 Feb 2008 11:38:01 -0500 Received: from G-Force.local ([71.87.92.92]) by aacpub01.charter.net with ESMTP id <20080201163801.PJNR25501.aacpub01.charter.net@G-Force.local> for ; Fri, 1 Feb 2008 11:38:01 -0500 Message-ID: <47A34AE4.4020804@geckotribe.com> Date: Fri, 01 Feb 2008 10:37:56 -0600 From: Antone Roundy Reply-To: antone@geckotribe.com User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071127) MIME-Version: 1.0 To: atom-syntax Syntax Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness References: <200802010502.59500.aleksandersen+atomlist@runbox.com> In-Reply-To: <200802010502.59500.aleksandersen+atomlist@runbox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Chzlrs: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Aleksandersen wrote: > I atom:id-entify the main feed using an ISSN. (See below for example.) > This number is unique to my publication and I use it one time per feed. > > > urn:issn:1234-567X > > > But when it comes to atom archiving, it gets a little trickier…. Should I > use the same ISSN as for my recent updates feed? Yes, it would be appropriate to use it in both places. The atom:id is associated with a single "feed" which isn't the same thing and a "feed document". In other words, it's possible to have multiple documents that all represent the same "feed", and all of those documents would have the same atom:id. In your case, you've got the recent updates document for the feed and the archive document(s) for the feed -- but both a tied to the same feed. Antone From owner-atom-syntax@mail.imc.org Fri Feb 1 08:56:49 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0201C3A68A9 for ; Fri, 1 Feb 2008 08:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.454 X-Spam-Level: * X-Spam-Status: No, score=1.454 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6] 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 y+qSPI2Q2vxs for ; Fri, 1 Feb 2008 08:56:48 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2F3D23A68A6 for ; Fri, 1 Feb 2008 08:56:48 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m11Gl8GR027354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2008 09:47:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m11Gl8ID027353; Fri, 1 Feb 2008 09:47:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fepv01.charter.net (fepv01.charter.net [209.225.8.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m11Gl75q027345 for ; Fri, 1 Feb 2008 09:47:07 -0700 (MST) (envelope-from antone@geckotribe.com) Received: from aacpub02.charter.net ([10.20.200.49]) by fepv01.charter.net (InterMail vM.7.08.03.00 201-2186-126-20070710) with ESMTP id <20080201164707.CHKO13839.fepv01.charter.net@aacpub02.charter.net> for ; Fri, 1 Feb 2008 11:47:07 -0500 Received: from G-Force.local ([71.87.92.92]) by aacpub02.charter.net with ESMTP id <20080201164707.EKGL24785.aacpub02.charter.net@G-Force.local> for ; Fri, 1 Feb 2008 11:47:07 -0500 Message-ID: <47A34D06.10902@geckotribe.com> Date: Fri, 01 Feb 2008 10:47:02 -0600 From: Antone Roundy Reply-To: antone@geckotribe.com User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071127) MIME-Version: 1.0 To: atom-syntax Syntax Subject: Re: Long list of relations References: <200802010138.00059.aleksandersen+atomlist@runbox.com> <47A270C8.5040507@gmail.com> <200802010248.03849.aleksandersen+atomlist@runbox.com> In-Reply-To: <200802010248.03849.aleksandersen+atomlist@runbox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Chzlrs: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Aleksandersen wrote: > I thought the atom:link were based on the html4:link element? While the thinking behind the atom:link element was of course informed by the html element, RFC 4287 does NOT connect atom:link to html's link. > The HTML 4 > specification says that the rel attribute is a space‐separated list of > relationship values. Why should the Atom element be different from the > HTML element on this attribute? If I recall correctly (and I'm quite certain I do), this question was raised during discussion, and the WG rejected the idea of allowing multiple values inside the rel attribute. I think part of the reason was to avoid having to figure out how different combinations of rel values should interact. Antone From angelasawyergriffith@gmail.com Fri Feb 1 09:27:12 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4BB3A6882; Fri, 1 Feb 2008 09:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 263.833 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=263.833 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE=10.357, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_H_REPLICA=50, GB_REPLICA=50, GB_WATCH_1=50, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, INVALID_MSGID=1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_42=0.6, 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_DOUBLE_IP_SPAM=3.798, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_RECV_IP_FROMIP1=1.666, SARE_SPEC_REPL_OBFU1=1.666, SARE_SUB_PERFECT=0.725, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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] * 1.4 HOST_EQ_USERONOCOM HOST_EQ_USERONOCOM * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 3.5 HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname (Split * IP) * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 0.7 SARE_SUB_PERFECT subject has likely spammer phrase or word * 50 GB_H_REPLICA Misspelled Replica Watch Seller * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 10 FH_FAKE_RCVD_LINE RCVD line looks faked (A) * 1.7 SARE_RECV_IP_FROMIP1 Received line is IP address from IP address * 2.1 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO * 1.7 SARE_SPEC_REPL_OBFU1 BODY: SARE_SPEC_REPL_OBFU1 * 0.6 J_CHICKENPOX_42 BODY: 4alpha-pock-2alpha * 0.6 J_CHICKENPOX_15 BODY: 1alpha-pock-5alpha * 50 GB_REPLICA BODY: Misspelled Replica Watch Seller * 50 GB_WATCH_1 BODY: Misspelled Watch Watch Seller * 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: pofdiekk.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: pofdiekk.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: pofdiekk.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: pofdiekk.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: pofdiekk.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: pofdiekk.com] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [81.172.26.235 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [81.172.26.235 listed in dnsbl.sorbs.net] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 1.0 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org * [] * 1.9 INVALID_MSGID Message-Id is not valid, according to RFC 2822 * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 3.8 RCVD_DOUBLE_IP_SPAM Bulk email fingerprint (double IP) found 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 6qp4ZMcSNGpP; Fri, 1 Feb 2008 09:27:12 -0800 (PST) Received: from 81.172.26.235.dyn.user.ono.com (81.172.26.235.dyn.user.ono.com [81.172.26.235]) by core3.amsl.com (Postfix) with SMTP id 45B2928C19C; Fri, 1 Feb 2008 09:24:40 -0800 (PST) Received: from 204.200.32.50 by 81.172.26.235; Fri, 01 Feb 2008 19:18:17 +0200 Message-ID: From: "Meghan Vera" <7b@megatron.ietf.org> Reply-To: "Meghan Vera" <7b@megatron.ietf.org> To: 7b@megatron.ietf.org Subject: ***SPAM*** 263.833 (5) Repl1ca watch is a perfect gift! Date: Fri, 01 Feb 2008 12:26:17 -0500 MIME-Version: 1.0 New Year is knocking, 0rder precious repl1ca w4tches! Brand new models of w4tches, purses & bags from 2008! http://www.pofdiekk.com/ From owner-atom-syntax@mail.imc.org Fri Feb 1 11:29:57 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A02E3A6875 for ; Fri, 1 Feb 2008 11:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.24 X-Spam-Level: * X-Spam-Status: No, score=1.24 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 XDGbwZPeWCP6 for ; Fri, 1 Feb 2008 11:29:56 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id AAB6F3A6989 for ; Fri, 1 Feb 2008 11:29:56 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m11JL620040465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2008 12:21:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m11JL6Sd040464; Fri, 1 Feb 2008 12:21:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m11JL4YO040457 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 1 Feb 2008 12:21:05 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.162] (helo=pepper.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JL1RQ-0002Jj-KM for atom-syntax@imc.org; Fri, 01 Feb 2008 20:20:48 +0100 Received: from [80.202.178.119] (helo=avernakis.lan) by pepper.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JL1RD-0007tv-EW for atom-syntax@imc.org; Fri, 01 Feb 2008 20:20:35 +0100 From: Daniel Aleksandersen To: Atom emailing list Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Date: Fri, 1 Feb 2008 20:18:52 +0100 User-Agent: KMail/1.9.5 References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <20080201144145.GA25553@klangraum> In-Reply-To: <20080201144145.GA25553@klangraum> Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200802012018.52817.aleksandersen+atomlist@runbox.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m11JL6YN040459 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2008-02-01 15:41, Aristotle Pagaltzis wrote: > * Daniel Aleksandersen [2008-02-01 05:15]: > > It is not globally unique on a per my feed basis; but it is > > globally unique on a per…me…basis. > > Put the ISSN into a tag: URI instead of using the urn:issn: > scheme. What good would that do? To make a short process of this, can I append the archive date range at the end of the URN; as shown below: urn:issn:1234-567X#2008-01 That would create a unique, non‐changing ID for each of the individual feeds. I am not sure whether it violates the URN structure or the urn:issn specification though. -- Daniel Aleksandersen From 88735941964@CVMARK.CL Fri Feb 1 11:42:38 2008 Return-Path: <88735941964@CVMARK.CL> X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201FF3A681F for ; Fri, 1 Feb 2008 11:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 74.768 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=74.768 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FROM_LOCAL_DIGITS=0.001, FROM_LOCAL_HEX=1.399, FROM_STARTS_WITH_NUMS=1.499, HTML_MESSAGE=1, 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_SORBS_WEB=0.619, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, 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] * 0.0 FROM_LOCAL_DIGITS From: localpart has long digit sequence * 1.4 FROM_LOCAL_HEX From: localpart has long hexadecimal sequence * 1.5 FROM_STARTS_WITH_NUMS From: starts with many numbers * 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: lefoursm.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: lefoursm.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: lefoursm.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: lefoursm.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: lefoursm.com] * 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is a abuseable web server * [66.47.82.131 listed in dnsbl.sorbs.net] * 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 Io3LGBxvbvy3 for ; Fri, 1 Feb 2008 11:42:37 -0800 (PST) Received: from user-112ukk3.biz.mindspring.com (user-112ukk3.biz.mindspring.com [66.47.82.131]) by core3.amsl.com (Postfix) with ESMTP id 9F7AF3A681A for ; Fri, 1 Feb 2008 11:42:27 -0800 (PST) Message-ID: <000901c8650a$cdce0b10$83522f42@DirectorPhaseIIA> From: "Mai Gracey" <88735941964@CVMARK.CL> To: atompub-archive@lists.ietf.org Subject: ***SPAM*** 74.768 (5) The end to all your frustration lies here - we have the solution to your woes. Date: Fri, 1 Feb 2008 14:44:05 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0005_01C864E0.E4F80310" 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 ----------=_NextPart_000_0005_01C864E0.E4F80310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The end to all your frustration lies here - we have the solution to your = woes. ----------=_NextPart_000_0005_01C864E0.E4F80310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The end to all your frustration = lies here -=20 we have the solution to your woes. ----------=_NextPart_000_0005_01C864E0.E4F80310-- From owner-atom-syntax@mail.imc.org Fri Feb 1 11:59:14 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9C733A684F for ; Fri, 1 Feb 2008 11:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.183 X-Spam-Level: X-Spam-Status: No, score=0.183 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 E0UrhgYfz5JV for ; Fri, 1 Feb 2008 11:59:13 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 933923A68DC for ; Fri, 1 Feb 2008 11:58:56 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m11JnqO0042618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2008 12:49:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m11JnqKk042617; Fri, 1 Feb 2008 12:49:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m11JnoXY042611 for ; Fri, 1 Feb 2008 12:49:51 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 01 Feb 2008 19:49:49 -0000 Received: from p508F866B.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.134.107] by mail.gmx.net (mp012) with SMTP; 01 Feb 2008 20:49:49 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+HdN8QIDOHYM2a5k4zOTzlmfoJdqOrwGPkqvc1gj g6+k+gGy5a/Bzh Message-ID: <47A377D8.5060604@gmx.de> Date: Fri, 01 Feb 2008 20:49:44 +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: James Holderness CC: Atom emailing list Subject: Re: Status of the wrapper References: <200801302231.09548.aleksandersen+atomlist@runbox.com> <47A1972F.7010705@gmx.de> <47A23182.8020702@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: James Holderness wrote: > ... > It could even be argued that feed readers aren't actually required to > support prefixed xhtml content, so they aren't really broken. RFC4287 > says very little about the expected behaviour of feed readers. Choosing > to only support certain forms of xhtml could well be a deliberate design > decision. Only supporting specific XML serializations is a sign of a clueless programmer, that's it. I really can't think of a more polite way to state this. BR, Julian From owner-atom-syntax@mail.imc.org Fri Feb 1 12:04:53 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4719E28C306 for ; Fri, 1 Feb 2008 12:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.216 X-Spam-Level: X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_50=0.001, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 3BN8AekJD1zR for ; Fri, 1 Feb 2008 12:04:52 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 154BC3A6972 for ; Fri, 1 Feb 2008 12:03:56 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m11JtpEh042969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2008 12:55:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m11JtpxT042967; Fri, 1 Feb 2008 12:55:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m11Jtma7042961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Feb 2008 12:55:51 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.170.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id CE463D05B5 for ; Fri, 1 Feb 2008 14:55:47 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <20080201144145.GA25553@klangraum> <200802012018.52817.aleksandersen+atomlist@runbox.com> Subject: RE: atom:id, urn:issn, feed archiving, and uniqueness Date: Fri, 1 Feb 2008 11:55:44 -0800 Message-ID: <000001c8650c$71af83c0$0301a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200802012018.52817.aleksandersen+atomlist@runbox.com> Thread-Index: AchlB++nhSt+003BQjCndzeWXpbJdwAA98Yg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m11Jtpa6042962 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel wrote: > Aristotle Pagaltzis wrote: > > Put the ISSN into a tag: URI instead of using the urn:issn: > > scheme. > > What good would that do? Does the identifier urn:issn:1234-567 uniquely identify a publication or an entry? It can't identify both, because then it is not a unique identifier. > urn:issn:1234-567X#2008-01 What part of the publication with urn:issn:1234-567 does "2008-01" apply to? The first letter of the 2008th word, perhaps? - Brian From owner-atom-syntax@mail.imc.org Fri Feb 1 13:25:46 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5937A3A68A9 for ; Fri, 1 Feb 2008 13:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.213 X-Spam-Level: X-Spam-Status: No, score=-0.213 tagged_above=-999 required=5 tests=[AWL=1.144, BAYES_05=-1.11, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 4wN7sp5nje+4 for ; Fri, 1 Feb 2008 13:25:45 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 53CAA3A698B for ; Fri, 1 Feb 2008 13:25:45 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m11LG15X051156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2008 14:16:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m11LG1lB051155; Fri, 1 Feb 2008 14:16:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m11LFwII051149 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 1 Feb 2008 14:16:00 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.161] (helo=patch.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JL3Eh-0005Gv-3O; Fri, 01 Feb 2008 22:15:47 +0100 Received: from [80.202.178.119] (helo=avernakis.lan) by patch.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JL3Eg-00047X-62; Fri, 01 Feb 2008 22:15:46 +0100 From: Daniel Aleksandersen To: Brian Smith Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Date: Fri, 1 Feb 2008 22:14:01 +0100 User-Agent: KMail/1.9.5 References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <200802012018.52817.aleksandersen+atomlist@runbox.com> <000001c8650c$71af83c0$0301a8c0@T60> In-Reply-To: <000001c8650c$71af83c0$0301a8c0@T60> Cc: Atom emailing list Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802012214.01566.aleksandersen+atomlist@runbox.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m11LG0IH051150 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2008-02-01 20:55, Brian wrote: > Daniel wrote: > > Aristotle Pagaltzis wrote: > > > Put the ISSN into a tag: URI instead of using the urn:issn: > > > scheme. > > > > What good would that do? > > Does the identifier urn:issn:1234-567 uniquely identify a publication > or an entry? It can't identify both, because then it is not a unique > identifier. > > > urn:issn:1234-567X#2008-01 > > What part of the publication with urn:issn:1234-567 does "2008-01" > apply to? The first letter of the 2008th word, perhaps? No. I use this on the feed, and not entries. urn:issn:1234-567X urn:uuid:example The question was regarding archive feeds. Should these use the same ID as the main feed (issn), or should I append an archive date range as a second identifier (issn#date)? -- Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Sat Feb 2 06:03:24 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D143A6A44 for ; Sat, 2 Feb 2008 06:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.059 X-Spam-Level: X-Spam-Status: No, score=0.059 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_40=-0.185, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 prpXZJ0G2lee for ; Sat, 2 Feb 2008 06:03:24 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id EE5E83A6A40 for ; Sat, 2 Feb 2008 06:03:23 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m12DsEOi013960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Feb 2008 06:54:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m12DsEME013959; Sat, 2 Feb 2008 06:54:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m12DsCKF013952 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 2 Feb 2008 06:54:13 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.161] (helo=patch.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JLIoi-000141-Rh; Sat, 02 Feb 2008 14:54:00 +0100 Received: from [80.202.178.119] (helo=avernakis.lan) by patch.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JLInT-0003Gt-96; Sat, 02 Feb 2008 14:52:45 +0100 From: Daniel Aleksandersen To: Brian Smith Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Date: Sat, 2 Feb 2008 14:50:52 +0100 User-Agent: KMail/1.9.5 References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <200802012018.52817.aleksandersen+atomlist@runbox.com> <000001c8650c$71af83c0$0301a8c0@T60> In-Reply-To: <000001c8650c$71af83c0$0301a8c0@T60> Cc: Atom emailing list Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200802021450.52172.aleksandersen+atomlist@runbox.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m12DsEKE013954 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2008-02-01 20:55, you wrote: > Daniel wrote: > > Aristotle Pagaltzis wrote: > > > Put the ISSN into a tag: URI instead of using the urn:issn: > > > scheme. > > > > What good would that do? > > Does the identifier urn:issn:1234-567 uniquely identify a publication > or an entry? It can't identify both, because then it is not a unique > identifier. > > > urn:issn:1234-567X#2008-01 > > What part of the publication with urn:issn:1234-567 does "2008-01" > apply to? The first letter of the 2008th word, perhaps? It is supposed to identify the date. This is no standard! But the #part would solve my problem with keeping my ISSN in all feeds, but still have the ID be unique. I will try to explain with examples. Here is /latest-entries.atom: urn:issn:1234-567X urn:uuid:123456789X urn:uuid:X987654321 Here is /archive-2008-01.atom (January 2008): urn:issn:1234-567X#2008-01 urn:uuid:123456789X urn:uuid:X987654321 -- Daniel Aleksandersen Open Source Notebook - http://opensourcenotebook.com/ From owner-atom-syntax@mail.imc.org Sat Feb 2 09:15:23 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70DEB28C6C3 for ; Sat, 2 Feb 2008 09:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=1, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6] 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 adtWp6zV-LYv for ; Sat, 2 Feb 2008 09:15:22 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 9A4753A6A4D for ; Sat, 2 Feb 2008 09:14:32 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m12H6m0T029134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Feb 2008 10:06:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m12H6mao029133; Sat, 2 Feb 2008 10:06:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m12H6lws029127 for ; Sat, 2 Feb 2008 10:06:48 -0700 (MST) (envelope-from david@fastolfe.net) Received: by wa-out-1112.google.com with SMTP id l24so1394712waf.22 for ; Sat, 02 Feb 2008 09:06:47 -0800 (PST) Received: by 10.114.200.2 with SMTP id x2mr5280541waf.19.1201972007079; Sat, 02 Feb 2008 09:06:47 -0800 (PST) Received: by 10.114.211.19 with HTTP; Sat, 2 Feb 2008 09:06:47 -0800 (PST) Message-ID: <7fe006b30802020906s3b61f329jfdbdd159a101cbd3@mail.gmail.com> Date: Sat, 2 Feb 2008 09:06:47 -0800 From: "David Nesting" To: "Daniel Aleksandersen" Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Cc: "Brian Smith" , "Atom emailing list" In-Reply-To: <200802021450.52172.aleksandersen+atomlist@runbox.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_768_21045755.1201972007095" References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <200802012018.52817.aleksandersen+atomlist@runbox.com> <000001c8650c$71af83c0$0301a8c0@T60> <200802021450.52172.aleksandersen+atomlist@runbox.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------=_Part_768_21045755.1201972007095 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Feb 2, 2008 5:50 AM, Daniel Aleksandersen < aleksandersen+atomlist@runbox.com> wrote: > > What part of the publication with urn:issn:1234-567 does "2008-01" > > apply to? The first letter of the 2008th word, perhaps? > > It is supposed to identify the date. This is no standard! But the #part > would solve my problem with keeping my ISSN in all feeds, but still have > the ID be unique. Just be aware that applications aware of ISSN URNs may reject this URN as invalid if it contains a fragment. RFC3044 doesn't specify what a fragment means in the context of an ISSN URN, and the URN spec explicitly cautions against its use in URNs generally: 2.3.2 The other reserved characters RFC 1630 [2] reserves the characters "/", "?", and "#" for particular purposes. The URN-WG has not yet debated the applicability and precise semantics of those purposes as applied to URNs. Therefore, these characters are RESERVED for future developments. Namespace developers SHOULD NOT use these characters in unencoded form, but rather use the appropriate %-encoding for each character. This means your Atom IDs (ISSN URNs) may only be readable to humans. Using a tag: URI as Aristotle suggested would let you use it however you wanted (still with no computers understanding its semantics). If your publication has a canonical online presence, perhaps the atom:id could just be the (permanent) URL to that issue online? And this is all assuming you still feel you need distinct atom:ids for the different versions of your feed. I agree with Antone that there's no reason they can't be the same, but do whatever makes the most sense for you. Good luck. David ------=_Part_768_21045755.1201972007095 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On Feb 2, 2008 5:50 AM, Daniel Aleksandersen <aleksandersen+atomlist@runbox.com> wrote:
> What part of the publication with urn:issn:1234-567 does "2008-01"
> apply to? The first letter of the 2008th word, perhaps?

It is supposed to identify the date. This is no standard! But the #part
would solve my problem with keeping my ISSN in all feeds, but still have
the ID be unique.

Just be aware that applications aware of ISSN URNs may reject this URN as invalid if it contains a fragment.  RFC3044 doesn't specify what a fragment means in the context of an ISSN URN, and the URN spec explicitly cautions against its use in URNs generally:

2.3.2 The other reserved characters

   RFC 1630 [2] reserves the characters "/", "?", and "#" for particular
   purposes. The URN-WG has not yet debated the applicability and
   precise semantics of those purposes as applied to URNs. Therefore,
   these characters are RESERVED for future developments.  Namespace
   developers SHOULD NOT use these characters in unencoded form, but
   rather use the appropriate %-encoding for each character.

This means your Atom IDs (ISSN URNs) may only be readable to humans.  Using a tag: URI as Aristotle suggested would let you use it however you wanted (still with no computers understanding its semantics).  If your publication has a canonical online presence, perhaps the atom:id could just be the (permanent) URL to that issue online? 

And this is all assuming you still feel you need distinct atom:ids for the different versions of your feed.  I agree with Antone that there's no reason they can't be the same, but do whatever makes the most sense for you.

Good luck.

David
------=_Part_768_21045755.1201972007095-- From owner-atom-syntax@mail.imc.org Sat Feb 2 10:17:35 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7543A6A74 for ; Sat, 2 Feb 2008 10:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.082 X-Spam-Level: X-Spam-Status: No, score=0.082 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6] 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 GCxFhq6DXEhq for ; Sat, 2 Feb 2008 10:17:34 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B92FF3A6A6D for ; Sat, 2 Feb 2008 10:17:34 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m12Hksb0032307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Feb 2008 10:46:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m12HksKE032306; Sat, 2 Feb 2008 10:46:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m12HkqSE032298 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 2 Feb 2008 10:46:53 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.161] (helo=patch.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JLMRz-0006UX-2A; Sat, 02 Feb 2008 18:46:47 +0100 Received: from [80.202.178.119] (helo=avernakis.lan) by patch.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JLMRy-0007C7-8a; Sat, 02 Feb 2008 18:46:46 +0100 From: Daniel Aleksandersen To: David Nesting Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Date: Sat, 2 Feb 2008 18:44:57 +0100 User-Agent: KMail/1.9.5 References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <200802021450.52172.aleksandersen+atomlist@runbox.com> <7fe006b30802020906s3b61f329jfdbdd159a101cbd3@mail.gmail.com> In-Reply-To: <7fe006b30802020906s3b61f329jfdbdd159a101cbd3@mail.gmail.com> Cc: Atom list Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802021844.57353.aleksandersen+atomlist@runbox.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2008-02-02 18:06, David wrote: > > And this is all assuming you still feel you need distinct atom:ids for > the different versions of your feed. I agree with Antone that there's > no reason they can't be the same, but do whatever makes the most sense > for you. So I should use the same ID for the feed, and the archive version of that feed? -- Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Sat Feb 2 13:20:27 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526F13A6A5E for ; Sat, 2 Feb 2008 13:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.534 X-Spam-Level: * X-Spam-Status: No, score=1.534 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6] 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 n76N8d-X-FWe for ; Sat, 2 Feb 2008 13:20:26 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 98ED93A6A6E for ; Sat, 2 Feb 2008 13:20:26 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m12L9jSq045887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Feb 2008 14:09:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m12L9joH045886; Sat, 2 Feb 2008 14:09:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fepv02.charter.net (fepv02.charter.net [209.225.8.201]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m12L9OJM045867 for ; Sat, 2 Feb 2008 14:09:45 -0700 (MST) (envelope-from antone@geckotribe.com) Received: from aacpub02.charter.net ([10.20.200.49]) by fepv02.charter.net (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20080202210924.TFEW14661.fepv02.charter.net@aacpub02.charter.net> for ; Sat, 2 Feb 2008 16:09:24 -0500 Received: from G-Force.local ([71.87.92.92]) by aacpub02.charter.net with ESMTP id <20080202210924.PQMG24785.aacpub02.charter.net@G-Force.local> for ; Sat, 2 Feb 2008 16:09:24 -0500 Message-ID: <47A4DBFF.80805@geckotribe.com> Date: Sat, 02 Feb 2008 15:09:19 -0600 From: Antone Roundy Reply-To: antone@geckotribe.com User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071127) MIME-Version: 1.0 To: atom-syntax Syntax Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <200802021450.52172.aleksandersen+atomlist@runbox.com> <7fe006b30802020906s3b61f329jfdbdd159a101cbd3@mail.gmail.com> <200802021844.57353.aleksandersen+atomlist@runbox.com> In-Reply-To: <200802021844.57353.aleksandersen+atomlist@runbox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Chzlrs: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Aleksandersen wrote: > On 2008-02-02 18:06, David wrote: >> And this is all assuming you still feel you need distinct atom:ids for >> the different versions of your feed. I agree with Antone that there's >> no reason they can't be the same, but do whatever makes the most sense >> for you. > > So I should use the same ID for the feed, and the archive version of that > feed? That's what I would do, and for this reason: if someone finds both your lastest entries document and your archive document, they'll be able to recognize from the atom:id values that that the entries in each are copies of the same data. It could be argued that since the entries' atom:id values are the same (assuming that's what you intended to do...which would be the correct thing to do since they're the same entries no matter what feed they get copied into), you should be able to recognize that the entries are the same from just those. But the combination of the feed's atom:id and the entry's atom:id matching provides greater confidence that someone didn't accidentally duplicate someone else's ID. Antone From owner-atom-syntax@mail.imc.org Sat Feb 2 17:16:33 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175D93A6AE2 for ; Sat, 2 Feb 2008 17:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 8HsCvpUgY72K for ; Sat, 2 Feb 2008 17:16:32 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 66D143A6AD5 for ; Sat, 2 Feb 2008 17:16:32 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m13186rs060572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Feb 2008 18:08:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m13186Nm060571; Sat, 2 Feb 2008 18:08:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc1-s38.bay0.hotmail.com (bay0-omc1-s38.bay0.hotmail.com [65.54.246.110]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1318578060565 for ; Sat, 2 Feb 2008 18:08:06 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.14]) by bay0-omc1-s38.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Feb 2008 17:08:05 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 2 Feb 2008 17:08:05 -0800 Message-ID: Received: from 85.211.247.140 by BAY141-DAV4.phx.gbl with DAV; Sun, 03 Feb 2008 01:08:03 +0000 X-Originating-IP: [85.211.247.140] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom emailing list" References: <200801302231.09548.aleksandersen+atomlist@runbox.com> <47A1972F.7010705@gmx.de> <47A23182.8020702@gmx.de> <47A377D8.5060604@gmx.de> Subject: Re: Status of the wrapper Date: Sun, 3 Feb 2008 01:10:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 03 Feb 2008 01:08:05.0265 (UTC) FILETIME=[3B1A7810:01C86601] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Julian Reschke wrote: > Only supporting specific XML serializations is a sign of a clueless > programmer, that's it. I really can't think of a more polite way to state > this. On the other hand, expending development resources on "features" that your customers neither want nor need, at the expense of features that would be genuinely useful and appreciated, is a sign of a clueless businessman. Given that some of the most popular feed readers in use today only support specific XML serializations, I would suspect this has more to do with good business practice than it has with clueless programming. Regards James From owner-atom-syntax@mail.imc.org Sun Feb 3 04:31:51 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1C73A6C22 for ; Sun, 3 Feb 2008 04:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.161 X-Spam-Level: X-Spam-Status: No, score=-3.161 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 cm725pJg+iHC for ; Sun, 3 Feb 2008 04:31:50 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8BB1E3A67EE for ; Sun, 3 Feb 2008 04:31:50 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m13CHGUu096251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Feb 2008 05:17:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m13CHGrn096250; Sun, 3 Feb 2008 05:17:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m13CHEoG096242 for ; Sun, 3 Feb 2008 05:17:15 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 03 Feb 2008 12:17:13 -0000 Received: from p508F8871.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.136.113] by mail.gmx.net (mp012) with SMTP; 03 Feb 2008 13:17:13 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18ic/Ed/MEizxcTcOkeGo60M7b/CTWIR1/sLvjkYl Ah254cR2cr/Mjk Message-ID: <47A5B0C6.10201@gmx.de> Date: Sun, 03 Feb 2008 13:17:10 +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: James Holderness CC: Atom emailing list Subject: Re: Status of the wrapper References: <200801302231.09548.aleksandersen+atomlist@runbox.com> <47A1972F.7010705@gmx.de> <47A23182.8020702@gmx.de> <47A377D8.5060604@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: James Holderness wrote: > > Julian Reschke wrote: >> Only supporting specific XML serializations is a sign of a clueless >> programmer, that's it. I really can't think of a more polite way to >> state this. > > On the other hand, expending development resources on "features" that > your customers neither want nor need, at the expense of features that > would be genuinely useful and appreciated, is a sign of a clueless > businessman. To get namespace prefixes wrong requires to either use broken tools, or not to understand how XML (+NS) works. You compare the namespace URI and the local name, that's it. Programmers that do not get that are clueless, at least with respect to XML handling. Sorry. This has nothing to do with additional time or resources, just with understanding the technology. > Given that some of the most popular feed readers in use today only > support specific XML serializations, I would suspect this has more to do > with good business practice than it has with clueless programming. Defending bugs as "good business practice"? Sigh. BR, Julian From owner-atom-syntax@mail.imc.org Sun Feb 3 06:09:27 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 728003A6BE4 for ; Sun, 3 Feb 2008 06:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.643 X-Spam-Level: X-Spam-Status: No, score=0.643 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 ROcqgP-2t2+B for ; Sun, 3 Feb 2008 06:09:26 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id BD1BD3A685A for ; Sun, 3 Feb 2008 06:09:26 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m13DxUsY003160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Feb 2008 06:59:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m13DxUu0003159; Sun, 3 Feb 2008 06:59:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m13DxSxu003139 for ; Sun, 3 Feb 2008 06:59:29 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] ([203.30.247.18] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.1904919962 for ; Sun, 03 Feb 2008 05:50:31 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 03 Feb 2008 05:50:32 +1100 Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200802021450.52172.aleksandersen+atomlist@runbox.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/2/08 12:50 AM, "Daniel Aleksandersen" wrote: > urn:issn:1234-567X > urn:issn:1234-567X#2008-01 but aren't these just two different snapshots of the *same* feed? as such, they should have the same feed id. e. From owner-atom-syntax@mail.imc.org Sun Feb 3 07:39:43 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A878F3A6C75 for ; Sun, 3 Feb 2008 07:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6, J_CHICKENPOX_44=0.6] 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 8AxswRI-9wPI for ; Sun, 3 Feb 2008 07:39:43 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E0A593A6C6C for ; Sun, 3 Feb 2008 07:39:42 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m13FSnGV009023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Feb 2008 08:28:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m13FSneH009022; Sun, 3 Feb 2008 08:28:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m13FSnkD009016 for ; Sun, 3 Feb 2008 08:28:49 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.3.166] (83-71-68-136.b-ras1.prp.dublin.eircom.net [83.71.68.136]) by chilco.textdrive.com (Postfix) with ESMTP id 13875DE2A0 for ; Sun, 3 Feb 2008 15:28:47 +0000 (UTC) Message-ID: <47A5DDAD.7000303@dehora.net> Date: Sun, 03 Feb 2008 15:28:45 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Atom emailing list Subject: Re: Status of the wrapper References: <200801302231.09548.aleksandersen+atomlist@runbox.com> <200801310054.01673.aleksandersen+atomlist@runbox.com> In-Reply-To: <200801310054.01673.aleksandersen+atomlist@runbox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Aleksandersen wrote: > On 2008-01-30 23:32, you wrote: >> Hi Daniel, >> >>> I am curious about the status of the required
container when >>> including xhtml in text constructs. Wi[ll] it be changed to become >>> optional instead? >> There's no ongoing effort to revise the Atom syntax format, so assume >> this
will be required in the forseeable future. > > That is a shame. This is the wrong way to think about the div container. Think of it as defensive markup. It's there to help prevent things that consume your feed breaking or mangling your content. In itself, it's not flaw, or a bug; it's not even a wart. > Then maybe I should include an entire XHTML document structure. That would > make more sense than including XHTML fragments contained in a div > element. (That unnecessary div really bugs me, for some reason.) You can check the archives if you have time. I don't know if anyone that worked on Atom likes it, but the div is considered necessary to robustly transfer chunks of XHTML inside Atom. [The problems the div solve aren't specific to Atom btw] >> It's probably not a bad idea to use the HTML namespace as the default >> within your text construct, like so: >> >> >>
>>

>> This is a summary paragraph. >>

>>
>> > > Are there any downsides to defining the namespace in the atom:feed element > instead of repeating it troughout the document? Probably yes. For example, that assumes downstream processors will remember to copy over the namespace from the root element and not just extract whatever is inside the content element. Or someone will paste in prefixed XHTML fragment into a non-prefixed document, and something will output garbage because it doesn't handle namespaces prefixing of XHTML properly. Of course XML+XMLNS aware code isn't supposed to behave like that, but if we had such things as the general case, we wouldn't need the div workaround to encapsulate XHTML names to begin with. Given that you've looked at this, considered it, and come up wanting - a broken content-type workaround - it's probably better for you to assume a lack of robustness in kind from your consumers, and emit what the Atom spec says you must emit, irregardless of how you feel about it. Like I said, it's defensive markup. cheers Bill From owner-atom-syntax@mail.imc.org Sun Feb 3 07:55:14 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC883A6C86 for ; Sun, 3 Feb 2008 07:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.061 X-Spam-Level: * X-Spam-Status: No, score=1.061 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] 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 5eIGt3GiPd+v for ; Sun, 3 Feb 2008 07:55:13 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id AF1293A6BD2 for ; Sun, 3 Feb 2008 07:55:13 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m13FldW3010408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Feb 2008 08:47:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m13Fldhn010407; Sun, 3 Feb 2008 08:47:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m13FlcQF010398 for ; Sun, 3 Feb 2008 08:47:38 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.3.166] (83-71-68-136.b-ras1.prp.dublin.eircom.net [83.71.68.136]) by chilco.textdrive.com (Postfix) with ESMTP id 95A92DE3E0 for ; Sun, 3 Feb 2008 15:47:37 +0000 (UTC) Message-ID: <47A5E217.3070508@dehora.net> Date: Sun, 03 Feb 2008 15:47:35 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Atom emailing list Subject: Re: Status of the wrapper References: <200801302231.09548.aleksandersen+atomlist@runbox.com> <47A1972F.7010705@gmx.de> <47A23182.8020702@gmx.de> <47A377D8.5060604@gmx.de> <47A5B0C6.10201@gmx.de> In-Reply-To: <47A5B0C6.10201@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Julian Reschke wrote: > To get namespace prefixes wrong requires to either use broken tools, or > not to understand how XML (+NS) works. You compare the namespace URI and > the local name, that's it. Programmers that do not get that are > clueless, at least with respect to XML handling. Sorry. This has nothing > to do with additional time or resources, just with understanding the > technology. I could paraphrase what you said earlier - expecting or demanding uniform XMLNS behavior being a sign of a clueless standards advocate. But I can think of a more polite way to state it - XMLNS as written is set up to cause comprehension and implementation problems, and clearly has done so. I think the lesson here is to write better specs, not rail against programmers when they are presented with bad ones. cheers Bill From owner-atom-syntax@mail.imc.org Sun Feb 3 08:24:14 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34E33A6C77 for ; Sun, 3 Feb 2008 08:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.041 X-Spam-Level: * X-Spam-Status: No, score=1.041 tagged_above=-999 required=5 tests=[AWL=-0.713, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6, J_CHICKENPOX_44=0.6] 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 jsocXS22qPcf for ; Sun, 3 Feb 2008 08:24:14 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E8B813A6C6C for ; Sun, 3 Feb 2008 08:24:13 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m13G9e3r011746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Feb 2008 09:09:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m13G9e41011745; Sun, 3 Feb 2008 09:09:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m13G9cv1011737 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 3 Feb 2008 09:09:40 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.160] (helo=penny.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JLhPD-00023j-2F; Sun, 03 Feb 2008 17:09:19 +0100 Received: from [80.202.178.119] (helo=avernakis.lan) by penny.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JLhNr-0007YJ-P7; Sun, 03 Feb 2008 17:07:56 +0100 From: Daniel Aleksandersen To: Bill de hOra Subject: Re: Status of the wrapper Date: Sun, 3 Feb 2008 17:06:12 +0100 User-Agent: KMail/1.9.5 References: <200801302231.09548.aleksandersen+atomlist@runbox.com> <200801310054.01673.aleksandersen+atomlist@runbox.com> <47A5DDAD.7000303@dehora.net> In-Reply-To: <47A5DDAD.7000303@dehora.net> Cc: Atom list Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200802031706.12319.aleksandersen+atomlist@runbox.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m13G9ev0011740 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2008-02-03 16:28, you wrote: > Daniel Aleksandersen wrote: > > On 2008-01-30 23:32, you wrote: > >> Hi Daniel, > >> > >>> I am curious about the status of the required
container when > >>> including xhtml in text constructs. Wi[ll] it be changed to become > >>> optional instead? > >> > >> There's no ongoing effort to revise the Atom syntax format, so > >> assume this
will be required in the forseeable future. > > > > That is a shame. > > This is the wrong way to think about the div container. Think of it as > defensive markup. It's there to help prevent things that consume your > feed breaking or mangling your content. In itself, it's not flaw, or a > bug; it's not even a wart. It’s a «safety net» for people who do not want to read the specifications of what they are creating? > > Then maybe I should include an entire XHTML document structure. That > > would make more sense than including XHTML fragments contained in a > > div element. (That unnecessary div really bugs me, for some reason.) > > You can check the archives if you have time. I don't know if anyone > that worked on Atom likes it, but the div is considered necessary to > robustly transfer chunks of XHTML inside Atom. I tried doing that before posting my question. I could not phrase my search query right. :-/ > [The problems the div solve aren't specific to Atom btw] > > >> It's probably not a bad idea to use the HTML namespace as the > >> default within your text construct, like so: > >> > >> > >>
> >>

> >> This is a summary paragraph. > >>

> >>
> >> > > > > Are there any downsides to defining the namespace in the atom:feed > > element instead of repeating it troughout the document? > > Probably yes. For example, that assumes downstream processors will > remember to copy over the namespace from the root element and not just > extract whatever is inside the content element. Or someone will paste > in prefixed XHTML fragment into a non-prefixed document, and something > will output garbage because it doesn't handle namespaces prefixing of > XHTML properly. Of course XML+XMLNS aware code isn't supposed to behave > like that, but if we had such things as the general case, we wouldn't > need the div workaround to encapsulate XHTML names to begin with. > > Given that you've looked at this, considered it, and come up wanting - > a broken content-type workaround - it's probably better for you to > assume a lack of robustness in kind from your consumers, and emit what > the Atom spec says you must emit, irregardless of how you feel about > it. Like I said, it's defensive markup. What I wanted was to question the standard. To me it appears broken. Flawed, at least. …I should probably use as well? What is the point of xmlns:prefixes="URI" attributes? Really, why make a standard if no one follows it? -- Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Sun Feb 3 11:31:18 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28873A6C1F for ; Sun, 3 Feb 2008 11:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.52 X-Spam-Level: * X-Spam-Status: No, score=1.52 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=1] 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 LK0pctAkyhc5 for ; Sun, 3 Feb 2008 11:31:18 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 025533A6B67 for ; Sun, 3 Feb 2008 11:31:17 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m13J7XKR024836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Feb 2008 12:07:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m13J7XXp024835; Sun, 3 Feb 2008 12:07:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m13J7UTb024828 for ; Sun, 3 Feb 2008 12:07:31 -0700 (MST) (envelope-from david@fastolfe.net) Received: by wa-out-1112.google.com with SMTP id l24so2100565waf.22 for ; Sun, 03 Feb 2008 11:07:29 -0800 (PST) Received: by 10.114.171.1 with SMTP id t1mr498743wae.83.1202065649386; Sun, 03 Feb 2008 11:07:29 -0800 (PST) Received: by 10.114.211.19 with HTTP; Sun, 3 Feb 2008 11:07:29 -0800 (PST) Message-ID: <7fe006b30802031107j3c6cbb4fp4dc1b3a1b515d40d@mail.gmail.com> Date: Sun, 3 Feb 2008 11:07:29 -0800 From: "David Nesting" To: "Daniel Aleksandersen" Subject: Re: Status of the wrapper Cc: "Bill de hOra" , "Atom list" In-Reply-To: <200802031706.12319.aleksandersen+atomlist@runbox.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3900_30227487.1202065649371" References: <200801302231.09548.aleksandersen+atomlist@runbox.com> <200801310054.01673.aleksandersen+atomlist@runbox.com> <47A5DDAD.7000303@dehora.net> <200802031706.12319.aleksandersen+atomlist@runbox.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------=_Part_3900_30227487.1202065649371 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline T24gRmViIDMsIDIwMDggODowNiBBTSwgRGFuaWVsIEFsZWtzYW5kZXJzZW4gPAphbGVrc2FuZGVy c2VuK2F0b21saXN0QHJ1bmJveC5jb20+IHdyb3RlOgoKPgo+IOKApkkgc2hvdWxkIHByb2JhYmx5 IHVzZSA8YXJjaGl2ZQo+IHhtbG5zPSJodHRwOi8vcHVybC5vcmcvc3luZGljYXRpb24vaGlzdG9y eS8xLjAiLz4gYXMgd2VsbD8gV2hhdCBpcyB0aGUKPiBwb2ludCBvZiB4bWxuczpwcmVmaXhlcz0i VVJJIiBhdHRyaWJ1dGVzPyBSZWFsbHksIHdoeSBtYWtlIGEgc3RhbmRhcmQgaWYKPiBubyBvbmUg Zm9sbG93cyBpdD8KPgoKVGhlcmUgYXJlIGJhc2ljYWxseSB0aHJlZSB0eXBlcyBvZiB0b29sczog WE1MK1hNTE5TLWF3YXJlIG9uZXMsIGFuZCBvbmVzCmNvYmJsZWQgdG9nZXRoZXIgYnkgbG9va2lu ZyBhdCBleGFtcGxlcyBhbmQgd3JpdGluZyBzb2Z0d2FyZSB0aGF0IHdvcmtzIHdpdGgKdGhlIGV4 YW1wbGVzIGFyZSB0aGUgYmlnIHR3by4gIEdpdmVuIHRoZSByZWFjaCBvZiBBdG9tIGFuZCBpdHMg ZGlhbGVjdHMsCnRoZXJlIHdpbGwgYmUgYSAqbG90KiBvZiBpbXBsZW1lbnRhdGlvbnMgb3V0IHRo ZXJlIHRoYXQgZG8gdGhpbmdzIHRoZSBXcm9uZwpXYXkuICBZb3UgY2FuIGVpdGhlciBzaW1wbGlm eSB0aGUgc3RhbmRhcmQgYW5kIGxpbWl0IHlvdXIgaW1wbGVtZW50YXRpb25zLApvciBnaXZlIHRo ZSBzdGFuZGFyZCBzb21lIGZsZXhpYmlsaXR5IGFuZCBtYXhpbWl6ZSB5b3VyIGFkb3B0aW9uIHJh dGUuCgpCdXQgSSBzYWlkIHRocmVlIHR5cGVzIG9mIHRvb2xzLCBkaWRuJ3QgST8gIFRoZSB0aGly ZCB3aWxsIGJlIGZlZWQKYWdncmVnYXRvcnMgdGhhdCB3YW50IHRvIG1heGltaXplIHRoZSBudW1i ZXIgb2YgZmVlZHMgdGhleSBjYW4gaGFuZGxlLgpHaXZlbiB0aGUgbnVtYmVyIG9mIGJhZCBmZWVk cyB0aGVyZSBhcmUsIHB1bXBpbmcgdGhlc2UgdGhyb3VnaCBhIHR5cGljYWwgWE1MCnBhcnNlciB3 aWxsIHJlamVjdCBtYW55IGZlZWRzIHRoYXQgdGhleSBzdGlsbCB3YW50IHRvIHByb2Nlc3MuICBU aGVzZQphZ2dyZWdhdG9ycywgY29uc2VxdWVudGx5LCBtYXkgYmVuZWZpdCBmcm9tIGRvaW5nIHRo ZWlyIG93biBwYXJzaW5nLAp0cmVhdGluZyBBdG9tIGxpa2UgdGhleSB0cmVhdCBIVE1MOiB0YWcg c291cC4gIFRoZXNlIGFwcGxpY2F0aW9ucyBtYXkgZmFpbAp0byBwcm9jZXNzIHNvbWUgc3RyaWN0 bHkgc3RhbmRhcmRzLWNvbXBsaWFudCBmZWVkcywgYmVjYXVzZSB0aGV5IGRvIHVuY29tbW9uCnRo aW5ncy4gIFlvdSBtaWdodCBhcmd1ZSB0aGF0IHRoaXMgaXMganVzdCB0aGVtIGRvaW5nIHRoaW5n cyB0aGUgV3JvbmcgV2F5LApidXQgaXQncyBhbiBleHBsaWNpdCwgY29uc2Npb3VzIGRlY2lzaW9u LCBub3QgZHVlIHRvIHRoZWlyIG93biBpbmNvbXBldGVuY2UuCgpEYXZpZAo= ------=_Part_3900_30227487.1202065649371 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZlYiAzLCAyMDA4IDg6MDYgQU0sIERhbmllbCBB bGVrc2FuZGVyc2VuICZsdDs8YSBocmVmPSJtYWlsdG86YWxla3NhbmRlcnNlbithdG9tbGlzdEBy dW5ib3guY29tIj5hbGVrc2FuZGVyc2VuK2F0b21saXN0QHJ1bmJveC5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6 IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7 IHBhZGRpbmctbGVmdDogMWV4OyI+Cjxicj7igKZJIHNob3VsZCBwcm9iYWJseSB1c2UgJmx0O2Fy Y2hpdmU8YnI+eG1sbnM9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL3B1cmwub3JnL3N5bmRpY2F0aW9u L2hpc3RvcnkvMS4wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3B1cmwub3JnL3N5bmRpY2F0aW9u L2hpc3RvcnkvMS4wPC9hPiZxdW90Oy8mZ3Q7IGFzIHdlbGw/IFdoYXQgaXMgdGhlPGJyPnBvaW50 IG9mIHhtbG5zOnByZWZpeGVzPSZxdW90O1VSSSZxdW90OyBhdHRyaWJ1dGVzPyBSZWFsbHksIHdo eSBtYWtlIGEgc3RhbmRhcmQgaWY8YnI+Cm5vIG9uZSBmb2xsb3dzIGl0Pzxicj48L2Jsb2NrcXVv dGU+PC9kaXY+PGJyPlRoZXJlIGFyZSBiYXNpY2FsbHkgdGhyZWUgdHlwZXMgb2YgdG9vbHM6IFhN TCtYTUxOUy1hd2FyZSBvbmVzLCBhbmQgb25lcyBjb2JibGVkIHRvZ2V0aGVyIGJ5IGxvb2tpbmcg YXQgZXhhbXBsZXMgYW5kIHdyaXRpbmcgc29mdHdhcmUgdGhhdCB3b3JrcyB3aXRoIHRoZSBleGFt cGxlcyBhcmUgdGhlIGJpZyB0d28uJm5ic3A7IEdpdmVuIHRoZSByZWFjaCBvZiBBdG9tIGFuZCBp dHMgZGlhbGVjdHMsIHRoZXJlIHdpbGwgYmUgYSA8aT5sb3Q8L2k+IG9mIGltcGxlbWVudGF0aW9u cyBvdXQgdGhlcmUgdGhhdCBkbyB0aGluZ3MgdGhlIFdyb25nIFdheS4mbmJzcDsgWW91IGNhbiBl aXRoZXIgc2ltcGxpZnkgdGhlIHN0YW5kYXJkIGFuZCBsaW1pdCB5b3VyIGltcGxlbWVudGF0aW9u cywgb3IgZ2l2ZSB0aGUgc3RhbmRhcmQgc29tZSBmbGV4aWJpbGl0eSBhbmQgbWF4aW1pemUgeW91 ciBhZG9wdGlvbiByYXRlLjxicj4KPGJyPkJ1dCBJIHNhaWQgdGhyZWUgdHlwZXMgb2YgdG9vbHMs IGRpZG4mIzM5O3QgST8mbmJzcDsgVGhlIHRoaXJkIHdpbGwgYmUgZmVlZCBhZ2dyZWdhdG9ycyB0 aGF0IHdhbnQgdG8gbWF4aW1pemUgdGhlIG51bWJlciBvZiBmZWVkcyB0aGV5IGNhbiBoYW5kbGUu Jm5ic3A7IEdpdmVuIHRoZSBudW1iZXIgb2YgYmFkIGZlZWRzIHRoZXJlIGFyZSwgcHVtcGluZyB0 aGVzZSB0aHJvdWdoIGEgdHlwaWNhbCBYTUwgcGFyc2VyIHdpbGwgcmVqZWN0IG1hbnkgZmVlZHMg dGhhdCB0aGV5IHN0aWxsIHdhbnQgdG8gcHJvY2Vzcy4mbmJzcDsgVGhlc2UgYWdncmVnYXRvcnMs IGNvbnNlcXVlbnRseSwgbWF5IGJlbmVmaXQgZnJvbSBkb2luZyB0aGVpciBvd24gcGFyc2luZywg dHJlYXRpbmcgQXRvbSBsaWtlIHRoZXkgdHJlYXQgSFRNTDogdGFnIHNvdXAuJm5ic3A7IFRoZXNl IGFwcGxpY2F0aW9ucyBtYXkgZmFpbCB0byBwcm9jZXNzIHNvbWUgc3RyaWN0bHkgc3RhbmRhcmRz LWNvbXBsaWFudCBmZWVkcywgYmVjYXVzZSB0aGV5IGRvIHVuY29tbW9uIHRoaW5ncy4mbmJzcDsg WW91IG1pZ2h0IGFyZ3VlIHRoYXQgdGhpcyBpcyBqdXN0IHRoZW0gZG9pbmcgdGhpbmdzIHRoZSBX cm9uZyBXYXksIGJ1dCBpdCYjMzk7cyBhbiBleHBsaWNpdCwgY29uc2Npb3VzIGRlY2lzaW9uLCBu b3QgZHVlIHRvIHRoZWlyIG93biBpbmNvbXBldGVuY2UuPGJyPgo8YnI+RGF2aWQ8YnI+Cg== ------=_Part_3900_30227487.1202065649371-- From owner-atom-syntax@mail.imc.org Mon Feb 4 06:24:47 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6A63A6D2D for ; Mon, 4 Feb 2008 06:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 izPMV4CMIlK8 for ; Mon, 4 Feb 2008 06:24:46 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 07CEF3A6958 for ; Mon, 4 Feb 2008 06:24:45 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14E9YHD098411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 07:09:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m14E9YJE098410; Mon, 4 Feb 2008 07:09:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m14E9XbK098397 for ; Mon, 4 Feb 2008 07:09:33 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 04 Feb 2008 14:09:32 -0000 Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp051) with SMTP; 04 Feb 2008 15:09:32 +0100 X-Authenticated: #163624 X-Provags-ID: V01U2FsdGVkX19ZUWUYK/JZAUW039hE9/Ihr5AA+iW5YEzj/r6KiY u1RSyht14DySdG Date: Mon, 4 Feb 2008 15:09:31 +0100 From: Aristotle Pagaltzis To: Atom emailing list Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Message-ID: <20080204140931.GL25553@klangraum> Mail-Followup-To: Atom emailing list References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <200802012018.52817.aleksandersen+atomlist@runbox.com> <000001c8650c$71af83c0$0301a8c0@T60> <200802012214.01566.aleksandersen+atomlist@runbox.com> <200802010502.59500.aleksandersen+atomlist@runbox.com> <20080201144145.GA25553@klangraum> <200802012018.52817.aleksandersen+atomlist@runbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200802012214.01566.aleksandersen+atomlist@runbox.com> <200802012018.52817.aleksandersen+atomlist@runbox.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Daniel Aleksandersen [2008-02-01 20:30]: > > On 2008-02-01 15:41, Aristotle Pagaltzis wrote: > > * Daniel Aleksandersen [2008-02-01 05:15]: > > > It is not globally unique on a per my feed basis; but it is > > > globally unique on a per…me…basis. > > > > Put the ISSN into a tag: URI instead of using the urn:issn: > > scheme. > > What good would that do? Tag URIs contain your domain, so they provide a globally unique identifier, even if you’re using your ISSNs in them, which are not by themselves globally unique. * Daniel Aleksandersen [2008-02-01 22:30]: > The question was regarding archive feeds. Should these use the > same ID as the main feed (issn), or should I append an archive > date range as a second identifier (issn#date)? The entire point of atom:id is that entries are entities in their own right and may appear in multiple different feeds; so the atom:id for a particular entry should always be the same no matter which feed that entry is in. If you use different IDs for entries in your archive feed, you are effectively asserting that the entries in the archive feed are not the same The feed might even be provided by a search engine such as Icerocket, Bloglines or Google Blog Search; hence the requirement for atom:id to be *globally* unique, not just unique within a feed or even your domain. So urn:issn: URIs are not usable as atom:id values. If you use them and some other publication uses them in *their* feeds as well, then your entries won’t be distinguishable by atom:id from the entries of that other publication when a user goes to a feed search engine and gets entries from both your and the other publication in the result feed. Another issue is that atom:id values are not supposed to be used for any purpose other than identifying an entry, and so are not supposed to be normalised in any way – only compared character- by-character. So in other words, don’t try to put anything meaningful in atom:id – just make sure it is globally unique and never changes. Hence why I said to use tag: URIs. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon Feb 4 07:07:03 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE9D3A6F21 for ; Mon, 4 Feb 2008 07:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 MlKt4vCN3Vh4 for ; Mon, 4 Feb 2008 07:07:02 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 6F7DF3A6F8A for ; Mon, 4 Feb 2008 07:06:11 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14Ew36F002918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 07:58:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m14Ew3wU002917; Mon, 4 Feb 2008 07:58:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14Ew20I002908 for ; Mon, 4 Feb 2008 07:58:02 -0700 (MST) (envelope-from nojorin@gmail.com) Received: by el-out-1112.google.com with SMTP id v27so620312ele.22 for ; Mon, 04 Feb 2008 06:58:01 -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:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=u1jyaUwyNZRQejqtSnv0Er9fXq0GTVZvm+FkDh8e48A=; b=VGh8eTb31KqIscgOhc6Kbl+71hfx8OVVSRNStCKv68aroSPCgdAi4eVqc8a/uChvjbMpJU/7Kiz9N4x/SX9UUHXv1zJiegDB96s/SX0VmkMO6CC7R8PwTq0lcBR77OAHu/MjjTehYutKwBtCZdmzEIIuCuCgROmpW9EdwL8Hh6k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aJ+dOLLyb9zB4k3Q6jQ2Wkx9xOY7olphtOalxcYRqeAl6JTNG6sRZePO4b3n5GZ8Cvtaqz2Prtgh8UOknY323Ckn9O9GJYdGkowFax+6PKPgxnEb0lMrRzRJ1FvpD5Pn0bAc4pgeLZkFOAUOKcoOsRwH1RLXC1kz7XHfBmbFiv4= Received: by 10.143.33.19 with SMTP id l19mr3492301wfj.9.1202137080941; Mon, 04 Feb 2008 06:58:00 -0800 (PST) Received: by 10.142.143.10 with HTTP; Mon, 4 Feb 2008 06:58:00 -0800 (PST) Message-ID: Date: Mon, 4 Feb 2008 23:58:00 +0900 From: "Tatsuya Noyori" To: atom-syntax@imc.org Subject: Re: Updated Tombstones Draft, Take 2 In-Reply-To: <9EA89944-AF8E-460D-A84D-DCB8F8570547@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <477EDC91.6020504@gmail.com> <73ec599d0801050417h7c5cd354h9f5730834c3cf055@mail.gmail.com> <477FFC14.2090604@gmail.com> <000d01c850a2$44b202e0$0301a8c0@T60> <000301c85223$08d5c720$2401a8c0@T60> <00101B2E-1E42-4D3E-9E05-694D70C2058B@mnot.net> <9EA89944-AF8E-460D-A84D-DCB8F8570547@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, How about using atom:category/@scheme instead of Atom Tombstone namespace. The example is as follows: atom:deleted urn:uuid:xxxxxxxxxxxxxxxxxxxxxxxxxxx 2007-01-29T03:12:02Z HogeHoge This format is not disturbing current Atom syndication format. I think this format is good. -- Tatsuya Noyori (^o^)/ From owner-atom-syntax@mail.imc.org Mon Feb 4 07:07:13 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1073A6F70 for ; Mon, 4 Feb 2008 07:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.154 X-Spam-Level: * X-Spam-Status: No, score=1.154 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_48=0.6] 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 0owHTAkQz1Np for ; Mon, 4 Feb 2008 07:07:13 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 402333A6E6F for ; Mon, 4 Feb 2008 07:06:20 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14EvCff002869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 07:57:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m14EvCmO002868; Mon, 4 Feb 2008 07:57:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14Ev917002859 for ; Mon, 4 Feb 2008 07:57:12 -0700 (MST) (envelope-from nojorin@gmail.com) Received: by wr-out-0506.google.com with SMTP id c53so1563245wra.22 for ; Mon, 04 Feb 2008 06:57:09 -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:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wZwNAF/hGX5OxGrTtxUqfaAiGIOvTXQIBKCag4SRi/U=; b=JyhblWlVOrIZe0J2EjXn+9A7ZtpvVYRetJrbxu8CgwOk6QoXgND7iYT71fk24cIqtZYHgDMHQ/DYlGFIbTLJfJNPNOuW0OwWhMb2CPsKW8D23kB3AqzTWtH0yB6bpe8mGJtGFcrgIdAD6mXVp7yo1vAbYc1T19LTyY9PQtr6PmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CQBmHqIAYHKnUAhGwIG6/BGL3Cpply9Dz4PWnhPRn6Dn5+X5LCL5yETqDh1T83YEv+mMlcEt2x/dyinakLbRTLovmQ6/Sr4rPWxCDxlT5vVufVEkLPwJt3nhWFW9mUOJyLFEEyT++Vwv/rHKXRlPME6epsyYobfqIOrN8VFs2j0= Received: by 10.142.180.17 with SMTP id c17mr3484930wff.83.1202137028252; Mon, 04 Feb 2008 06:57:08 -0800 (PST) Received: by 10.142.143.10 with HTTP; Mon, 4 Feb 2008 06:57:08 -0800 (PST) Message-ID: Date: Mon, 4 Feb 2008 23:57:08 +0900 From: "Tatsuya Noyori" To: atom-syntax@imc.org Subject: Re: Atom feed design for a variety of media types In-Reply-To: <47A22CF4.4070303@defuze.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> <479B88CF.3070000@gmail.com> <479BBE7E.1020001@defuze.org> <47A22CF4.4070303@defuze.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m14EvC17002862 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, How about using XHTML:*/@class and relation of atom:category/@term="class:..." and atom:link/@rel="id:...". The example is as follows. --- ...
1234.jpg
Image width: 800
Image height: 600
 This format is using atom:category/@scheme instead of namespace. This format can be extended by using XHTML:*/class and atom:category. The example is as follows: ...
1234.jpg
Image width: 800
Image height: 600
Latitude: 35.658632
Longitude: 139.745411
Altitude: 332.6m
Timestamp: 2008-01-29T03:00:00Z
1235.jpg
Image width: 800
Image height: 600
Latitude: 35.658632
Longitude: 139.745411
Altitude: 332.6m
Timestamp: 2008-01-29T03:01:01Z
 This format is human-readable, machine-readable, extendable and not disturbing current Atom syndication format. So, I think this format is good. -- Tatsuya Noyori (^o^)/ From owner-atom-syntax@mail.imc.org Mon Feb 4 07:11:05 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D890D3A6E6F for ; Mon, 4 Feb 2008 07:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.027 X-Spam-Level: * X-Spam-Status: No, score=1.027 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 OzAfRQUnNh4V for ; Mon, 4 Feb 2008 07:11:00 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 6A5FE3A6EB6 for ; Mon, 4 Feb 2008 07:11:00 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14ExBQq003009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 07:59:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m14ExBka003008; Mon, 4 Feb 2008 07:59:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14Ex9YF003001 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 4 Feb 2008 07:59:11 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.162] (helo=pepper.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JM2mc-0004Xm-Ap for atom-syntax@imc.org; Mon, 04 Feb 2008 15:58:54 +0100 Received: from [80.202.178.119] (helo=avernakis.lan) by pepper.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JM2mb-0003YE-BL for atom-syntax@imc.org; Mon, 04 Feb 2008 15:58:53 +0100 From: Daniel Aleksandersen To: Atom emailing list Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Date: Mon, 4 Feb 2008 15:57:06 +0100 User-Agent: KMail/1.9.5 References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <200802012018.52817.aleksandersen+atomlist@runbox.com> <20080204140931.GL25553@klangraum> In-Reply-To: <20080204140931.GL25553@klangraum> Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200802041557.07194.aleksandersen+atomlist@runbox.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m14ExBYE003003 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2008-02-04 15:09, Aristotle Pagaltzis wrote: > * Daniel Aleksandersen [2008-02-01 20:30]: > > On 2008-02-01 15:41, Aristotle Pagaltzis wrote: > > > * Daniel Aleksandersen [2008-02-01 05:15]: > > > > It is not globally unique on a per my feed basis; but it is > > > > globally unique on a per…me…basis. > > > > > > Put the ISSN into a tag: URI instead of using the urn:issn: > > > scheme. > > > > What good would that do? > > Tag URIs contain your domain, so they provide a globally unique > identifier, even if you’re using your ISSNs in them, which are > not by themselves globally unique. > > * Daniel Aleksandersen [2008-02-01 22:30]: > > The question was regarding archive feeds. Should these use the > > same ID as the main feed (issn), or should I append an archive > > date range as a second identifier (issn#date)? > > The entire point of atom:id is that entries are entities in their > own right and may appear in multiple different feeds; so the > atom:id for a particular entry should always be the same no > matter which feed that entry is in. If you use different IDs for > entries in your archive feed, you are effectively asserting that > the entries in the archive feed are not the same > > The feed might even be provided by a search engine such as > Icerocket, Bloglines or Google Blog Search; hence the requirement > for atom:id to be *globally* unique, not just unique within a > feed or even your domain. So urn:issn: URIs are not usable as > atom:id values. If you use them and some other publication uses > them in *their* feeds as well, then your entries won’t be > distinguishable by atom:id from the entries of that other > publication when a user goes to a feed search engine and gets > entries from both your and the other publication in the result > feed. > > Another issue is that atom:id values are not supposed to be used > for any purpose other than identifying an entry, and so are not > supposed to be normalised in any way – only compared character- > by-character. > > So in other words, don’t try to put anything meaningful in > atom:id – just make sure it is globally unique and never changes. > > Hence why I said to use tag: URIs. Why does so many in this list fail to eralise that I am talking about the element’s element? Not an ’s? I see these messages were people think I am talking about entries all the time. That is wrong. I know that they should uniquely identify the entries in the element. But what about the the element? -- Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Mon Feb 4 13:18:21 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40463A6D79 for ; Mon, 4 Feb 2008 13:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 ct7mbcgHrypV for ; Mon, 4 Feb 2008 13:18:20 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C031A3A6CA9 for ; Mon, 4 Feb 2008 13:18:20 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14L8kUu030879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 14:08:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m14L8kMF030878; Mon, 4 Feb 2008 14:08:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m14L8ijL030872 for ; Mon, 4 Feb 2008 14:08:45 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 04 Feb 2008 21:08:42 -0000 Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp058) with SMTP; 04 Feb 2008 22:08:42 +0100 X-Authenticated: #163624 X-Provags-ID: V01U2FsdGVkX18KSj8ZAfAKQmjuCrIe9ZIrBoIxXnlHg/sJTUu+9F I6NtV/Vo04WSsD Date: Mon, 4 Feb 2008 22:08:42 +0100 From: Aristotle Pagaltzis To: Atom emailing list Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Message-ID: <20080204210842.GB3456@klangraum> Mail-Followup-To: Atom emailing list References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <200802012018.52817.aleksandersen+atomlist@runbox.com> <20080204140931.GL25553@klangraum> <200802041557.07194.aleksandersen+atomlist@runbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200802041557.07194.aleksandersen+atomlist@runbox.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Daniel Aleksandersen [2008-02-04 16:10]: > Why does so many in this list fail to eralise that I am talking > about the element’s element? Ugh, sorry. Well, the point about atom:id being globally unique continues to apply in either case. However, I’m not sure what the feed ID really identifies, nor can I recall any compelling argument about its meaning, so I have no idea when feeds should share an ID. (The fact that everyone thought you were talking about entry IDs is a strong indicator that no one has much use for feed IDs.) In the context of Atompub it is somewhat clear: when two feeds are views onto the same collection, they should probably have the same ID. However, even then it is not necessarily clear when a feed other than the collection feed is a view onto that collection rather than a distinct entity that happens to draw entries from the collection. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Feb 5 10:33:55 2008 Return-Path: X-Original-To: atompub-archive@ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id C80463A8785; Tue, 5 Feb 2008 10:52:55 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by mail.ietf.org (Postfix) with ESMTP id 35AF03A6B6F for ; Mon, 4 Feb 2008 13:59:05 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14LpqI1034328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 14:51:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m14LpqXa034326; Mon, 4 Feb 2008 14:51:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14LpoZj034318 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 4 Feb 2008 14:51:52 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.162] (helo=pepper.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JM9Dy-0007Q2-V1; Mon, 04 Feb 2008 22:51:34 +0100 Received: from [80.202.178.119] (helo=avernakis.lan) by pepper.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JM9Dx-00069h-N6; Mon, 04 Feb 2008 22:51:34 +0100 From: Daniel Aleksandersen To: Aristotle Pagaltzis Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Date: Mon, 4 Feb 2008 22:49:49 +0100 User-Agent: KMail/1.9.5 References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <200802041557.07194.aleksandersen+atomlist@runbox.com> <20080204210842.GB3456@klangraum> In-Reply-To: <20080204210842.GB3456@klangraum> Cc: Atom emailing list Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200802042249.49774.aleksandersen+atomlist@runbox.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m14LpqZi034321 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2008-02-04 22:08, Aristotle Pagaltzis wrote: > * Daniel Aleksandersen [2008-02-04 16:10]: > > Why does so many in this list fail to eralise that I am talking > > about the element’s element? > > Ugh, sorry. > > Well, the point about atom:id being globally unique continues to > apply in either case. > > However, I’m not sure what the feed ID really identifies, nor can > I recall any compelling argument about its meaning, so I have no > idea when feeds should share an ID. (The fact that everyone > thought you were talking about entry IDs is a strong indicator > that no one has much use for feed IDs.) (It is an required child of the feed element. Everybody are required to use it.) I was surprised to not find any mentioning of the feed element’s id element it in urn:ietf:rfc:5005. It was one of the first things I wondered about when I learned of the specification. > In the context of Atompub it is somewhat clear: when two feeds > are views onto the same collection, they should probably have > the same ID. However, even then it is not necessarily clear > when a feed other than the collection feed is a view onto that > collection rather than a distinct entity that happens to draw > entries from the collection. Then the question is whether the feed element’s id element identifies the feed or the collection [of entries]. As of now I am using the same id value for all the feeds. I will continue doing that until someone [in here] tells me otherwise. -- Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Tue Feb 5 10:33:56 2008 Return-Path: X-Original-To: atompub-archive@ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 499DB3A963F; Tue, 5 Feb 2008 10:53:04 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by mail.ietf.org (Postfix) with ESMTP id 061B83A73B9 for ; Mon, 4 Feb 2008 15:00:36 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14MqBEM038769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 15:52:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m14MqBpl038768; Mon, 4 Feb 2008 15:52:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14Mq9AP038759 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 4 Feb 2008 15:52:10 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.161] (helo=patch.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JMAAa-0004Rp-DU; Mon, 04 Feb 2008 23:52:08 +0100 Received: from [80.202.178.119] (helo=avernakis.lan) by patch.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JMA8X-0000Nz-O1; Mon, 04 Feb 2008 23:50:04 +0100 From: Daniel Aleksandersen To: Atom list Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Date: Mon, 4 Feb 2008 23:48:14 +0100 User-Agent: KMail/1.9.5 References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <20080204210842.GB3456@klangraum> <47A78C50.30600@gmail.com> In-Reply-To: <47A78C50.30600@gmail.com> Cc: James M Snell Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200802042348.14552.aleksandersen+atomlist@runbox.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m14MqBAO038763 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2008-02-04 23:06, you wrote: > Aristotle Pagaltzis wrote: > > * Daniel Aleksandersen [2008-02-04 16:10]: > >> Why does so many in this list fail to eralise that I am talking > >> about the element’s element? > > > > Ugh, sorry. > > > > Well, the point about atom:id being globally unique continues to > > apply in either case. > > > > However, I’m not sure what the feed ID really identifies, nor can > > The Feed level atom:id is primarily useful as a logical group > identifier. For instance, suppose you have a collection of Atom feed > documents representing a paged set. Together, all of the entries > comprise a single logical group commonly identified by the atom:feed's > atom:id element. If there was no atom:id element, there'd be no way of > grouping entries from multiple feed documents into a single logical > set. Then why is this not written in any specifications? > > I recall any compelling argument about its meaning, so I have no > > idea when feeds should share an ID. (The fact that everyone > > thought you were talking about entry IDs is a strong indicator > > that no one has much use for feed IDs.) > > > > In the context of Atompub it is somewhat clear: when two feeds > > are views onto the same collection, they should probably have > > the same ID. However, even then it is not necessarily clear > > when a feed other than the collection feed is a view onto that > > collection rather than a distinct entity that happens to draw > > entries from the collection. > > > > Regards, -- Daniel Aleksandersen From dennis_mcwilliams@redmac.net Tue Feb 5 10:33:57 2008 Return-Path: X-Original-To: atompub-archive@lists.ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id D4D543A6F54; Tue, 5 Feb 2008 10:57:46 -0800 (PST) Received: from lgb-static-208.57.64.24.mpowercom.net (lgb-static-208.57.64.24.mpowercom.net [208.57.64.24]) by mail.ietf.org (Postfix) with SMTP id 1772828D851 for ; Tue, 5 Feb 2008 09:29:23 -0800 (PST) Received: from [131.45.161.26] (helo=rfq) by lgb-static-208.57.64.24.mpowercom.net with smtp (Exim 4.62 (FreeBSD)) id 1JMSi-0007Sn-5N; Tue, 5 Feb 2008 09:33:26 -0800 Message-ID: <002501c8681d$27d15670$1aa12d83@rfq> From: To: Subject: Our Journey Date: Tue, 5 Feb 2008 09:33:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original 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 Special Romance http://98.202.86.206/ From oecaa.scott@cocoabeachsurfcamp.com Tue Feb 5 10:34:09 2008 Return-Path: X-Original-To: atompub-archive@megatron.ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 92C403A76CB; Tue, 5 Feb 2008 10:57:46 -0800 (PST) Received: from lgb-static-208.57.64.24.mpowercom.net (lgb-static-208.57.64.24.mpowercom.net [208.57.64.24]) by mail.ietf.org (Postfix) with SMTP id F0AAD28D85F for ; Tue, 5 Feb 2008 09:30:44 -0800 (PST) Received: from [191.145.231.175] (helo=dasl) by lgb-static-208.57.64.24.mpowercom.net with smtp (Exim 4.62 (FreeBSD)) id 1JMSy-0003jS-Ed; Tue, 5 Feb 2008 09:34:44 -0800 Message-ID: <000901c8681d$585561b0$afe791bf@dasl> From: To: Subject: Pages from My Heart Date: Tue, 5 Feb 2008 09:34:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 A Rose http://86.127.14.60/ From owner-atom-syntax@mail.imc.org Tue Feb 5 10:34:21 2008 Return-Path: X-Original-To: atompub-archive@ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id A32573A93EB; Tue, 5 Feb 2008 10:52:47 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by mail.ietf.org (Postfix) with ESMTP id B3AF13A7565 for ; Mon, 4 Feb 2008 15:35:23 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14NKPV9040855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 16:20:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m14NKPJi040854; Mon, 4 Feb 2008 16:20:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mwest.oreilly.com (mwest.oreilly.com [209.204.146.24]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14NKPgS040847 for ; Mon, 4 Feb 2008 16:20:25 -0700 (MST) (envelope-from keith@oreilly.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by mwest.oreilly.com (Postfix) with ESMTP id 34BCE1B88043; Mon, 4 Feb 2008 15:17:03 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at Received: from mwest.oreilly.com ([127.0.0.1]) by localhost (hugo.west.ora.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUvZespq6Zr5; Mon, 4 Feb 2008 15:17:03 -0800 (PST) Received: from MacKeith.local (unknown [172.24.41.11]) by mwest.oreilly.com (Postfix) with ESMTP id D746C1B88029; Mon, 4 Feb 2008 15:17:02 -0800 (PST) Message-ID: <47A79DB6.3090308@oreilly.com> Date: Mon, 04 Feb 2008 15:20:22 -0800 From: Keith Fahlgren User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Daniel Aleksandersen CC: Atom list , James M Snell Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <20080204210842.GB3456@klangraum> <47A78C50.30600@gmail.com> <200802042348.14552.aleksandersen+atomlist@runbox.com> In-Reply-To: <200802042348.14552.aleksandersen+atomlist@runbox.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2/4/08 2:48 PM, Daniel Aleksandersen wrote: > On 2008-02-04 23:06, you wrote: >> Aristotle Pagaltzis wrote: >>> * Daniel Aleksandersen [2008-02-04 > 16:10]: >>>> Why does so many in this list fail to eralise that I am talking >>>> about the element’s element? >>> Ugh, sorry. >>> >>> Well, the point about atom:id being globally unique continues to >>> apply in either case. >>> >>> However, I’m not sure what the feed ID really identifies, nor can >> The Feed level atom:id is primarily useful as a logical group >> identifier. For instance, suppose you have a collection of Atom feed >> documents representing a paged set. Together, all of the entries >> comprise a single logical group commonly identified by the atom:feed's >> atom:id element. If there was no atom:id element, there'd be no way of >> grouping entries from multiple feed documents into a single logical >> set. > > Then why is this not written in any specifications? I had always thought that intent was clear from the specification: http://xml.resource.org/public/rfc/html/rfc4287.html#element.feed """ # atom:feed (The "atom:feed" Element) elements MUST contain exactly one atom:id """ http://xml.resource.org/public/rfc/html/rfc4287.html#element.id """4.2.6. The "atom:id" Element The "atom:id (The "atom:id" Element)" element conveys a permanent, universally unique identifier for an entry or feed. atomId = element atom:id { atomCommonAttributes, (atomUri) } Its content MUST be an IRI, as defined by [RFC3987] (Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs),” January 2005.). Note that the definition of "IRI" excludes relative references. Though the IRI might use a dereferencable scheme, Atom Processors MUST NOT assume it can be dereferenced. When an Atom Document is relocated, migrated, syndicated, republished, exported, or imported, the content of its atom:id (The "atom:id" Element) element MUST NOT change. Put another way, an atom:id (The "atom:id" Element) element pertains to all instantiations of a particular Atom entry or feed; revisions retain the same content in their atom:id (The "atom:id" Element) elements. It is suggested that the atom:id (The "atom:id" Element) element be stored along with the associated resource. The content of an atom:id (The "atom:id" Element) element MUST be created in a way that assures uniqueness. Because of the risk of confusion between IRIs that would be equivalent if they were mapped to URIs and dereferenced, the following normalization strategy SHOULD be applied when generating atom:id (The "atom:id" Element) elements: * Provide the scheme in lowercase characters. * Provide the host, if any, in lowercase characters. * Only perform percent-encoding where it is essential. * Use uppercase A through F characters when percent-encoding. * Prevent dot-segments from appearing in paths. * For schemes that define a default authority, use an empty authority if the default is desired. * For schemes that define an empty path to be equivalent to a path of "/", use "/". * For schemes that define a port, use an empty port if the default is desired. * Preserve empty fragment identifiers and queries. * Ensure that all components of the IRI are appropriately character normalized, e.g., by using NFC or NFKC. """ HTH, Keith From edwina8campbell@hotmail.com Tue Feb 5 10:36:57 2008 Return-Path: X-Original-To: atompub-archive@megatron.ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id BF1363A6B9C; Tue, 5 Feb 2008 10:53:00 -0800 (PST) Received: from e179250209.adsl.alicedsl.de (e179250209.adsl.alicedsl.de [85.179.250.209]) by mail.ietf.org (Postfix) with SMTP id A7E6B28C8D0; Tue, 5 Feb 2008 05:56:15 -0800 (PST) Received: from 144.92.56.152 by 85.179.250.209; Tue, 05 Feb 2008 16:51:41 +0300 Message-ID: From: "Deloris Hawkins" Reply-To: "Deloris Hawkins" To: atompub-archive@megatron.ietf.org Subject: Repl1ca watch is a perfect gift! Date: Tue, 05 Feb 2008 08:58:41 -0500 MIME-Version: 1.0 Newest 2008 repl1ca watch3s collection! 15% off in February and huge choose of repl1cas! http://www.oisoiske.com/ From kjoseph@ms34.hinet.net Tue Feb 5 10:38:33 2008 Return-Path: X-Original-To: atompub-archive@megatron.ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 5FFDB3AA1AC; Tue, 5 Feb 2008 10:52:50 -0800 (PST) Received: from cpe-71-72-2-217.neo.res.rr.com (cpe-71-72-2-217.neo.res.rr.com [71.72.2.217]) by mail.ietf.org (Postfix) with SMTP id 694F23A71E2 for ; Mon, 4 Feb 2008 13:47:20 -0800 (PST) Received: from [71.103.106.200] (helo=fdn) by cpe-71-72-2-217.neo.res.rr.com with smtp (Exim 4.62 (FreeBSD)) id 1JM9FI-0001R0-SG; Mon, 4 Feb 2008 16:52:56 -0500 Message-ID: <47A7884C.5030801@ms34.hinet.net> Date: Mon, 4 Feb 2008 16:49:00 -0500 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: atompub-archive@megatron.ietf.org Subject: Make her tremble with passion! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit She will want to have these nights 4ever! http://iafp.speakpound.com From owner-atom-syntax@mail.imc.org Tue Feb 5 10:44:48 2008 Return-Path: X-Original-To: atompub-archive@ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 5BA583A778F; Tue, 5 Feb 2008 10:47:46 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by mail.ietf.org (Postfix) with ESMTP id 28CCE3A8538 for ; Mon, 4 Feb 2008 21:12:00 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1552f6J063318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 22:02:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1552foB063317; Mon, 4 Feb 2008 22:02:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m1552dZ7063311 for ; Mon, 4 Feb 2008 22:02:40 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 05 Feb 2008 05:02:38 -0000 Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp009) with SMTP; 05 Feb 2008 06:02:38 +0100 X-Authenticated: #163624 X-Provags-ID: V01U2FsdGVkX1+w5DURJSmw0NVMX8zICSQ2OqzPAE4jTZu8gqcojj EdLvdFG33tuZwQ Date: Tue, 5 Feb 2008 06:02:37 +0100 From: Aristotle Pagaltzis To: Atom emailing list Subject: Re: Status of the wrapper Message-ID: <20080205050237.GH3456@klangraum> Mail-Followup-To: Atom emailing list References: <200801302231.09548.aleksandersen+atomlist@runbox.com> <7fe006b30801301601i4350f69aq3ebeb061b07affc6@mail.gmail.com> <200801310108.56551.aleksandersen+atomlist@runbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200801310108.56551.aleksandersen+atomlist@runbox.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Daniel Aleksandersen [2008-01-31 01:20]: > I am trying to understand why XHTML fragments must be contained > within two containers (the atom:summary AND the xht:div > elements). I really disliked the mandatory wrapper when the requirement was added to the spec, but over time I’ve come around somewhat. A major point is that it makes sure the entire content is contained in a single child node of the text construct, itself in the same namespace as the actual content. That guarantee actually allows taking a bunch of small shortcuts when copying the content between documents using the DOM API. So now I don’t mind it so much anymore. It’s kinda annoying, but you get used to it. In the end it really isn’t a big deal worth getting annoyed by. There are feed formats with far more grave imperfections than this one. Regards, -- Aristotle Pagaltzis // From _otrebla0@afterparty.ro Tue Feb 5 10:45:57 2008 Return-Path: <_otrebla0@afterparty.ro> X-Original-To: atompub-archive@lists.ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id CE9643A7DA4; Tue, 5 Feb 2008 10:53:00 -0800 (PST) Received: from pc-91-86-74-200.cm.vtr.net (pc-91-86-74-200.cm.vtr.net [200.74.86.91]) by mail.ietf.org (Postfix) with ESMTP id AF1B828C51B for ; Tue, 5 Feb 2008 05:36:00 -0800 (PST) Message-ID: <000901c867fc$3e483c00$5b564ac8@rebolledoflore> From: "Raimundas timothee" <_otrebla0@afterparty.ro> To: atompub-archive@lists.ietf.org Subject: Take this c0ck enlargement pill only if you want to attract the best women Date: Tue, 5 Feb 2008 10:37:25 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0005_01C867E3.18FB0400" 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 ----------=_NextPart_000_0005_01C867E3.18FB0400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Don't envy others when you can now also increase your manhood the = natural way ----------=_NextPart_000_0005_01C867E3.18FB0400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Don't envy others when you can now = also=20 increase your manhood the natural way ----------=_NextPart_000_0005_01C867E3.18FB0400-- From jquinn@prudentialdoss.com Tue Feb 5 10:50:33 2008 Return-Path: X-Original-To: atompub-archive@lists.ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id BD2883A74A8; Tue, 5 Feb 2008 10:52:57 -0800 (PST) Received: from cogeco.ca (unknown [80.71.242.2]) by mail.ietf.org (Postfix) with SMTP id C907F3A9C6A for ; Tue, 5 Feb 2008 03:50:05 -0800 (PST) Received: from 64.18.5.14 (HELO prudentialdoss.com.s6b2.psmtp.com) by lists.ietf.org with esmtp (ZQEYSMIJZ MRRMS) id C0couL-r9jYmw-7d for atompub-archive@lists.ietf.org; Tue, 05 Feb 2008 14:52:25 +0300 Message-ID: <3cab01c867ed$9302bf40$c0a80103@Celeste> From: "Celeste Blackmon" To: "Frankie Wesley" Subject: Pleasure all women with the size of your instrument. Date: Tue, 05 Feb 2008 14:52:25 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_15529_3D13_01C86806.B84FF740" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 This is a multi-part message in MIME format. ------=_NextPart_15529_3D13_01C86806.B84FF740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In just a few short weeks, you`ll watch with amazement=20 as your pen!s grows into the thickest, biggest, hardest, and most powerfu= l tool=20 you`ve ever imagined - the one you`ve always fantasized about=20 having! No pen!s en`l@rgement system is faster, easier to use, or=20 more effective than VPXL+ - GUARANTEED}! VPXL+ IS GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR=20 PEN|S OR YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET=20 VPXL+ AND LIVE LARGE TODAY! ENTER HERE NOW TO SUBSTANTIALLY IMPROVE YOUR MALE PACKAGE IN THIS YEAR! http://nbnibsee=2Ecom/ to see the moon re-emerge from the Earth's shadow,Cooper said=2E Like Dav= id Rehr, he pointed out theSwitzerland accidentally invades Liechtenstein= after Protests have continued after Manchester United defeatedcampaign, with on= ly seven sacks=2E ------=_NextPart_15529_3D13_01C86806.B84FF740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
VPXL+: THE WORLD'S #1 PEN|S= EN'L@RGEMENT PREPARATION!

In just= a few short weeks,=20 you`ll watch with amazement as your pen!s
grows into the thickest, bi= ggest, hardest, and most powerful tool
you`ve ever imagined - the one you`ve always fantasized about
having!= No pen!s en`l@rgement=20 system is faster, easier to use, or
more effective than VPXL+= - GUARANTEED!

VPXL+ IS=20 GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR
PE= N|S OR=20 YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET
VPXL+ AND LIVE LARG= E TODAY!

ENTER HERE NOW TO SUBSTANTIALLY I= MPROVE YOUR MALE PACKAGE IN THIS YEAR!



rise=2E Internet radio is more popular than ever=2E At this"Homop= hobia exists, but I feel these words are insulting
bomb scare=2E Almost eight years ago the school was theto see the moon re= -emerge from the Earth's shadow,
Cooper said=2E Like David Rehr, he po= inted out theSwitzerland accidentally invades Liechtenstein after
Prot= ests have continued after Manchester United defeatedcampaign, with only s= even sacks=2E ------=_NextPart_15529_3D13_01C86806.B84FF740-- From zoria@ewaksoft.com Tue Feb 5 10:50:58 2008 Return-Path: X-Original-To: atompub-archive@lists.ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id DC2443A7A52; Tue, 5 Feb 2008 10:37:47 -0800 (PST) Received: from cpe-71-72-2-217.neo.res.rr.com (cpe-71-72-2-217.neo.res.rr.com [71.72.2.217]) by mail.ietf.org (Postfix) with SMTP id 939A63A71CC for ; Mon, 4 Feb 2008 13:46:21 -0800 (PST) Received: from [101.59.140.48] (helo=nee) by cpe-71-72-2-217.neo.res.rr.com with smtp (Exim 4.62 (FreeBSD)) id 1JM9E-0003ir-0P; Mon, 4 Feb 2008 16:51:20 -0500 Message-ID: <47A7880E.1010201@ewaksoft.com> Date: Mon, 4 Feb 2008 16:47:58 -0500 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: Your incredible new huge love-stick! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Best prices for blue-pill! http://np.thanpopulate.com From mit_soco@sohu.com Tue Feb 5 10:54:24 2008 Return-Path: X-Original-To: ATOMPUB-ARCHIVE@MEGATRON.IETF.ORG Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id E88873A6832; Tue, 5 Feb 2008 10:43:10 -0800 (PST) Received: from a-net.ne.jp (unknown [124.234.68.45]) by mail.ietf.org (Postfix) with ESMTP id 515B93A856F for ; Mon, 4 Feb 2008 21:17:37 -0800 (PST) Received: from agtzvd3 (unknown [215.150.20.70]) by smtp83 (Coremail) with SMTP id b2CDuUedisy9XjNG.1 for ; Tue, 05 Feb 2008 13:19:06 +0800 (CST) X-Originating-IP: [215.150.20.70] Subject: =?iso-2022-jp?B?GyRCODVxWSQ3JE4lVyVtJCxBKiRzJEAhKhsoQg==?= From: =?shift-jis?B?TmV3cw==?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Message-Id: <20080205051738.515B93A856F@mail.ietf.org> Date: Mon, 4 Feb 2008 21:17:37 -0800 (PST) $B85%5%/%i$N?M$@$+$i$3$=!"K\Ev$K$$$$%5%$%H$,$o$+$k$s$G$9!*(B $B85%5%/%i$,A*$s$@K~B-EY(B4.0$B$N=P2q$$%5%$%H!*(B http://78587.net/k?deaicom=FreePass ------------------------- $B%f!<%6!<$N?I8}%l%S%e!<$r7G:\Cf!*(B $B7G<(HD$d%a!<%k$N3+Iu$,40A4$KL5NA$G!"$7$+$b;H$$J|Bj$H$$$&(B $B$$$^Bg?M5$$NOCBj$N=P2q$$%5%$%H$r96N,!*(B ------------------------- $B("(B $BG[?.Dd;_$O%3%A%i$^$G!#(B $B("(B info@topgear.etowns.net $B("(B $B("!ZG[?.Dd;_$K!VG[?.Dd;_!W$H$*=q$-2<$5$$!#(B $B("7oL>$K!VG[?.Dd;_!W$H5-:\$5$l$F$$$J$$>l9g$O=hM}$,9T$($^$;$s!#(B From owner-atom-syntax@mail.imc.org Tue Feb 5 10:56:18 2008 Return-Path: X-Original-To: atompub-archive@ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 9FCD33A73FB; Tue, 5 Feb 2008 10:43:10 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by mail.ietf.org (Postfix) with ESMTP id 512A53A6CDA for ; Mon, 4 Feb 2008 14:12:57 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14M6FQ9035418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 15:06:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m14M6FXB035417; Mon, 4 Feb 2008 15:06:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m14M6DC5035411 for ; Mon, 4 Feb 2008 15:06:14 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wa-out-1112.google.com with SMTP id l24so2824181waf.22 for ; Mon, 04 Feb 2008 14:06:13 -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:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=/67b3I6PmEHXYNhGJJOodq9AhZr4ekpB7pdwnUdKVqs=; b=lJTKqDaBJ2cXtDZq6PuilLIPmE79xvRNQFt9Xn7saky/zgNXgmXNNTjLFhKAuT5ITzLjgWLFn3egjgRNPOd7X2L8mGQ6/Gx976AekcAfpI7S3LheefS9z3HqcfmPklxsEG6xEeuZJ0MI88WMwucWTNNF63e1w5pEaYeAmMqJwiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=ro5YkquEKc7Lq2X1rUpjuf6izD7oKgQdHOT8m7bgnkqTVKXxeKUoKn/7YZqShhWSyiFtRCKkVJmnQVpTPq30LbaxplHWRGMCLQWiIJ+eea+62VDkUnX/jzhK1m3j2JOzDtefjv44wBZ75zOG2MwQjrSvhvu4JEcUFuP+iMVu3+I= Received: by 10.114.95.1 with SMTP id s1mr1703071wab.99.1202162773222; Mon, 04 Feb 2008 14:06:13 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id i52sm16021879rne.2.2008.02.04.14.06.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 Feb 2008 14:06:12 -0800 (PST) Message-ID: <47A78C50.30600@gmail.com> Date: Mon, 04 Feb 2008 14:06:08 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Atom emailing list Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <200802012018.52817.aleksandersen+atomlist@runbox.com> <20080204140931.GL25553@klangraum> <200802041557.07194.aleksandersen+atomlist@runbox.com> <20080204210842.GB3456@klangraum> In-Reply-To: <20080204210842.GB3456@klangraum> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Aristotle Pagaltzis wrote: > * Daniel Aleksandersen [2008-02-04 16:10]: >> Why does so many in this list fail to eralise that I am talking >> about the element’s element? > > Ugh, sorry. > > Well, the point about atom:id being globally unique continues to > apply in either case. > > However, I’m not sure what the feed ID really identifies, nor can The Feed level atom:id is primarily useful as a logical group identifier. For instance, suppose you have a collection of Atom feed documents representing a paged set. Together, all of the entries comprise a single logical group commonly identified by the atom:feed's atom:id element. If there was no atom:id element, there'd be no way of grouping entries from multiple feed documents into a single logical set. - James > I recall any compelling argument about its meaning, so I have no > idea when feeds should share an ID. (The fact that everyone > thought you were talking about entry IDs is a strong indicator > that no one has much use for feed IDs.) > > In the context of Atompub it is somewhat clear: when two feeds > are views onto the same collection, they should probably have > the same ID. However, even then it is not necessarily clear > when a feed other than the collection feed is a view onto that > collection rather than a distinct entity that happens to draw > entries from the collection. > > Regards, From blended@click3times.com Tue Feb 5 11:04:05 2008 Return-Path: X-Original-To: atompub-archive@lists.ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id B6F313A7B35; Tue, 5 Feb 2008 10:52:55 -0800 (PST) Received: from 221-134-6-123.sify.net (unknown [221.134.6.123]) by mail.ietf.org (Postfix) with ESMTP id 1C58A3A9C4D for ; Tue, 5 Feb 2008 03:48:51 -0800 (PST) Received: from [221.134.6.123] by mx5.biz.mail.yahoo.com; Tue, 5 Feb 2008 17:20:24 +0530 Message-ID: <01c8681b$64867c00$7b0686dd@blended> From: "Phil Porter" To: Subject: 50mgYourHealthWorldwide Date: Tue, 5 Feb 2008 17:20:24 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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 WorldwideShippingPhentriminePhentrimine http://couldarm.com From oeffentlichkeitsarbeit@centurycomputer.ca Tue Feb 5 11:04:08 2008 Return-Path: X-Original-To: atompub-archive@lists.ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 4C7783A6815; Tue, 5 Feb 2008 11:02:46 -0800 (PST) Received: from 125.235.150.43.adsl.viettel.vn (unknown [125.235.150.43]) by mail.ietf.org (Postfix) with SMTP id 60E933A8948 for ; Mon, 4 Feb 2008 22:41:27 -0800 (PST) Received: from [116.238.145.35] (helo=kwx) by 125.235.150.43.adsl.viettel.vn with smtp (Exim 4.62 (FreeBSD)) id 1JMI%-0007Xh-2U; Tue, 5 Feb 2008 13:43:52 +0700 Message-ID: <47A80572.3010406@centurycomputer.ca> Date: Tue, 5 Feb 2008 13:42:58 +0700 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: You're the One Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eternal Love http://76.28.65.94/ From dangerfu@NHi.edu Tue Feb 5 11:04:41 2008 Return-Path: X-Original-To: atompub-archive@lists.ietf.org Delivered-To: ietfarch-atompub-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id B78CC3A8095; Tue, 5 Feb 2008 10:52:47 -0800 (PST) Received: from 82-42-158-134.cable.ubr10.live.blueyonder.co.uk (82-42-158-134.cable.ubr10.live.blueyonder.co.uk [82.42.158.134]) by mail.ietf.org (Postfix) with ESMTP id 261803A7C02 for ; Mon, 4 Feb 2008 18:18:02 -0800 (PST) Message-ID: <000901c8679d$8d377f10$869e2a52@tablet> From: "Nishanthan Forgotten" To: atompub-archive@lists.ietf.org Subject: Blow your lady away with the largest d1ck she has seen in her life. Date: Tue, 5 Feb 2008 02:19:35 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0005_01C8679D.8D377F10" 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 ----------=_NextPart_000_0005_01C8679D.8D377F10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gain several inches on your weener with this new medical discovery. ----------=_NextPart_000_0005_01C8679D.8D377F10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gain several inches on your weener = with this=20 new medical discovery. ----------=_NextPart_000_0005_01C8679D.8D377F10-- From owner-atom-syntax@mail.imc.org Wed Feb 6 03:16:35 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628CD3A6BBD for ; Wed, 6 Feb 2008 03:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=-3.591, BAYES_40=-0.185, HELO_EQ_FR=0.35, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9nzEbNydvfY for ; Wed, 6 Feb 2008 03:16:34 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 6B59D3A6C7C for ; Wed, 6 Feb 2008 03:16:18 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16B6Ht2092291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2008 04:06:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m16B6HGS092290; Wed, 6 Feb 2008 04:06:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16B6F83092282 for ; Wed, 6 Feb 2008 04:06:16 -0700 (MST) (envelope-from bortzmeyer@nic.fr) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 1E4781C00F6 for ; Wed, 6 Feb 2008 12:06:14 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 19EAE1C00F3 for ; Wed, 6 Feb 2008 12:06:14 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 0E0B558EBBE for ; Wed, 6 Feb 2008 12:06:14 +0100 (CET) Date: Wed, 6 Feb 2008 12:06:14 +0100 From: =?iso-8859-1?Q?St=E9phane?= Bortzmeyer To: atom-syntax@imc.org Subject: Google Reader and Namespace Prefixes Message-ID: <20080206110614.GA5643@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [A bit off-topic, I know, but it seems related with the recent thread on "Status of the wrapper".] My blog's Atom feed (http://www.bortzmeyer.org/feed-full.atom, made by a custom program) is awful when seen with Google Reader (for instance http://www.google.com/reader/m/view/feed/http://www.bortzmeyer.org/feed-full.atom?i=-628233248182762503&c=CKe0oJaD_ZAC&n=1) My feeling is that Google is wrong: the feed validates (both locally, with rnv and with http://feedvalidator.org). Also, other feed readers have no problem, for instance the Liferea aggregator (running on Linux) or http://xmlfr.org/actualites/planete/xmlfr/fr/. One of the warnings sent by feedvalidator is: http://feedvalidator.org/docs/warning/AvoidNamespacePrefix.html I do use namespace prefixes. Can anyone confirm / infirm that Google Reader has problems with them? From owner-atom-syntax@mail.imc.org Wed Feb 6 06:36:37 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48EB3A6CC1 for ; Wed, 6 Feb 2008 06:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.668 X-Spam-Level: X-Spam-Status: No, score=0.668 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58kIvTwtgXwm for ; Wed, 6 Feb 2008 06:36:36 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id CFE5D3A6B83 for ; Wed, 6 Feb 2008 06:36:36 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16EQla8006929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2008 07:26:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m16EQlOp006928; Wed, 6 Feb 2008 07:26:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16EQlLS006922 for ; Wed, 6 Feb 2008 07:26:47 -0700 (MST) (envelope-from karl@w3.org) Received: from localhost (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 68EAD4F585; Wed, 6 Feb 2008 09:26:46 -0500 (EST) Cc: atom-syntax@imc.org Message-Id: From: Karl Dubost To: =?ISO-8859-1?Q?St=E9phane_Bortzmeyer?= In-Reply-To: <20080206110614.GA5643@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Google Reader and Namespace Prefixes Date: Wed, 6 Feb 2008 23:26:44 +0900 References: <20080206110614.GA5643@nic.fr> X-Mailer: Apple Mail (2.915) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m16EQlLS006923 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Le 6 févr. 2008 à 20:06, Stéphane Bortzmeyer a écrit : > I do use namespace prefixes. Can anyone confirm / infirm that Google > Reader has problems with them? www.詹姆斯.com/blog/2007/11/atom-namespace-problems known issue, it seems -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool From owner-atom-syntax@mail.imc.org Wed Feb 6 06:37:41 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B564D3A6CF0 for ; Wed, 6 Feb 2008 06:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.761 X-Spam-Level: X-Spam-Status: No, score=0.761 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M81VsmsaLAXt for ; Wed, 6 Feb 2008 06:37:40 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 4253E3A6850 for ; Wed, 6 Feb 2008 06:37:40 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16EOJe2006759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2008 07:24:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m16EOJPt006758; Wed, 6 Feb 2008 07:24:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16EOH84006752 for ; Wed, 6 Feb 2008 07:24:18 -0700 (MST) (envelope-from karl@w3.org) Received: from localhost (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id A2AF44F303; Wed, 6 Feb 2008 09:24:16 -0500 (EST) Cc: atom-syntax@imc.org Message-Id: <1006B633-7160-4B69-B686-6AE1CA607C9E@w3.org> From: Karl Dubost To: =?ISO-8859-1?Q?St=E9phane_Bortzmeyer?= In-Reply-To: <20080206110614.GA5643@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Google Reader and Namespace Prefixes Date: Wed, 6 Feb 2008 23:24:14 +0900 References: <20080206110614.GA5643@nic.fr> X-Mailer: Apple Mail (2.915) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m16EOI84006753 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: salut stphane, Le 6 fvr. 2008 20:06, Stphane Bortzmeyer a crit : > My feeling is that Google is wrong: the feed validates (both locally, > with rnv and with http://feedvalidator.org). not quite :) but I'm not sure it is the source of the issue. http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fwww.bortzmeyer.org%2Ffeed-full.atom -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool From owner-atom-syntax@mail.imc.org Wed Feb 6 07:12:20 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5AC3A6D02 for ; Wed, 6 Feb 2008 07:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.204 X-Spam-Level: X-Spam-Status: No, score=0.204 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBPv-AaqXLIJ for ; Wed, 6 Feb 2008 07:12:18 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 55ED63A6EB6 for ; Wed, 6 Feb 2008 07:12:18 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16F4rMI009791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2008 08:04:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m16F4rOj009790; Wed, 6 Feb 2008 08:04:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16F4n9E009782 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 6 Feb 2008 08:04:51 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.160] (helo=penny.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JMlpD-0004mg-PF; Wed, 06 Feb 2008 16:04:35 +0100 Received: from [80.202.178.119] (helo=daniel.lan) by penny.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JMlmS-0005XD-Fr; Wed, 06 Feb 2008 16:01:45 +0100 From: Daniel Aleksandersen To: Atom list Subject: Re: Google Reader and Namespace Prefixes Date: Wed, 6 Feb 2008 15:59:46 +0100 User-Agent: KMail/1.9.5 References: <20080206110614.GA5643@nic.fr> In-Reply-To: Cc: Karl Dubost Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200802061559.46874.aleksandersen+atomlist@runbox.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m16F4p9D009785 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2008-02-06 15:26, you wrote: > Le 6 févr. 2008 à 20:06, Stéphane Bortzmeyer a écrit : > > I do use namespace prefixes. Can anyone confirm / infirm that Google > > Reader has problems with them? > > www.詹姆斯.com/blog/2007/11/atom-namespace-problems > known issue, it seems That is http://www.xn--8ws00zhy3a.com/blog/2007/11/atom-namespace-problems to the rest of the world. ☺ -- Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Wed Feb 6 07:13:22 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4C223A6E33 for ; Wed, 6 Feb 2008 07:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=-3.235, BAYES_50=0.001, HELO_EQ_FR=0.35, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DKXwbcbu7DD for ; Wed, 6 Feb 2008 07:13:22 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 34F643A6D02 for ; Wed, 6 Feb 2008 07:13:21 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16F2nQe009675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2008 08:02:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m16F2nUX009674; Wed, 6 Feb 2008 08:02:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16F2m8i009667 for ; Wed, 6 Feb 2008 08:02:48 -0700 (MST) (envelope-from bortzmeyer@nic.fr) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id D81311C0135; Wed, 6 Feb 2008 16:02:47 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id D2AC41C012C; Wed, 6 Feb 2008 16:02:47 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id C5F2658EBBE; Wed, 6 Feb 2008 16:02:47 +0100 (CET) Date: Wed, 6 Feb 2008 16:02:47 +0100 From: =?iso-8859-1?Q?St=E9phane?= Bortzmeyer To: Karl Dubost Cc: atom-syntax@imc.org Subject: Re: Google Reader and Namespace Prefixes Message-ID: <20080206150247.GB32206@nic.fr> References: <20080206110614.GA5643@nic.fr> 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) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Feb 06, 2008 at 11:26:44PM +0900, Karl Dubost wrote a message of 19 lines which said: > www.?????????.com/blog/2007/11/atom-namespace-problems > known issue, it seems This page reminds there is a problem but Google is not mentioned. From owner-atom-syntax@mail.imc.org Wed Feb 6 07:17:04 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3499E3A6E55 for ; Wed, 6 Feb 2008 07:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=-2.875, BAYES_50=0.001, HELO_EQ_FR=0.35, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLPVz5r1eUku for ; Wed, 6 Feb 2008 07:17:00 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 728C53A6E33 for ; Wed, 6 Feb 2008 07:17:00 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16F1RsE009601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2008 08:01:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m16F1Rkk009600; Wed, 6 Feb 2008 08:01:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16F1QJ5009594 for ; Wed, 6 Feb 2008 08:01:27 -0700 (MST) (envelope-from bortzmeyer@nic.fr) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 4EED81C012D; Wed, 6 Feb 2008 16:01:26 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 49F791C012C; Wed, 6 Feb 2008 16:01:26 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 3DF1558EBBE; Wed, 6 Feb 2008 16:01:26 +0100 (CET) Date: Wed, 6 Feb 2008 16:01:26 +0100 From: =?iso-8859-1?Q?St=E9phane?= Bortzmeyer To: Karl Dubost Cc: atom-syntax@imc.org Subject: Re: Google Reader and Namespace Prefixes Message-ID: <20080206150126.GA32206@nic.fr> References: <20080206110614.GA5643@nic.fr> <1006B633-7160-4B69-B686-6AE1CA607C9E@w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1006B633-7160-4B69-B686-6AE1CA607C9E@w3.org> 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) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Feb 06, 2008 at 11:24:14PM +0900, Karl Dubost wrote a message of 19 lines which said: > >My feeling is that Google is wrong: the feed validates (both locally, > >with rnv and with http://feedvalidator.org). > > not quite :) It *is* valid, there are just a few known warnings (warnings, not errors). > Be Strict To Be Cool I will :-) From owner-atom-syntax@mail.imc.org Wed Feb 6 07:30:51 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 268F23A6EFE for ; Wed, 6 Feb 2008 07:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.808 X-Spam-Level: X-Spam-Status: No, score=0.808 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YyT3LaMgRmr for ; Wed, 6 Feb 2008 07:30:47 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 384823A6DE6 for ; Wed, 6 Feb 2008 07:30:42 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16FN1Yf011090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2008 08:23:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m16FN1vk011089; Wed, 6 Feb 2008 08:23:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16FN0Eu011082 for ; Wed, 6 Feb 2008 08:23:01 -0700 (MST) (envelope-from karl@w3.org) Received: from localhost (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id A89A34F310; Wed, 6 Feb 2008 10:22:59 -0500 (EST) Cc: atom-syntax@imc.org Message-Id: <51D1F12C-58B9-4C14-A066-D7E4627C0207@w3.org> From: Karl Dubost To: =?ISO-8859-1?Q?St=E9phane_Bortzmeyer?= In-Reply-To: <20080206150247.GB32206@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Google Reader and Namespace Prefixes Date: Thu, 7 Feb 2008 00:22:58 +0900 References: <20080206110614.GA5643@nic.fr> <20080206150247.GB32206@nic.fr> X-Mailer: Apple Mail (2.915) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m16FN1Eu011083 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Le 7 fvr. 2008 00:02, Stphane Bortzmeyer a crit : > This page reminds there is a problem but Google is not mentioned. "More of an issue was the xhtml prefix, which caused problems for nearly two thirds of the aggregators tested. 3" following the "3" "3 Including Google Reader, NewsGator Online, FeedDemon, Thunderbird 1.5.0.13, and RSS Bandit 1.5.0.17." ;) -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool From owner-atom-syntax@mail.imc.org Thu Feb 7 06:47:05 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 266553A6DCC for ; Thu, 7 Feb 2008 06:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.368 X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUA9Ue4U5asH for ; Thu, 7 Feb 2008 06:47:01 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 423703A78EB for ; Thu, 7 Feb 2008 06:46:42 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m17Eamal012094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Feb 2008 07:36:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m17EamqX012093; Thu, 7 Feb 2008 07:36:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m17EakV2012085 for ; Thu, 7 Feb 2008 07:36:47 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 07 Feb 2008 14:36:45 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp051) with SMTP; 07 Feb 2008 15:36:45 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19EDPFKQI9E8Hcy9fv7L8SIhAT9lFW/e7G4Shw3sY DZqxU2uhNR1xUX Message-ID: <47AB177C.3000408@gmx.de> Date: Thu, 07 Feb 2008 15:36:44 +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: Karl Dubost CC: =?ISO-8859-1?Q?St=E9phane_Bortzmeyer?= , atom-syntax@imc.org Subject: Re: Google Reader and Namespace Prefixes References: <20080206110614.GA5643@nic.fr> <20080206150247.GB32206@nic.fr> <51D1F12C-58B9-4C14-A066-D7E4627C0207@w3.org> In-Reply-To: <51D1F12C-58B9-4C14-A066-D7E4627C0207@w3.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Karl Dubost wrote: > > > Le 7 fvr. 2008 00:02, Stphane Bortzmeyer a crit : >> This page reminds there is a problem but Google is not mentioned. > > > "More of an issue was the xhtml prefix, > which caused problems for nearly two thirds > of the aggregators tested. 3" > > following the "3" > > "3 Including Google Reader, NewsGator Online, > FeedDemon, Thunderbird 1.5.0.13, and RSS > Bandit 1.5.0.17." So do we know whether Google is aware of this problem? Hmm. Joe, maybe you? BR, Julian From owner-atom-syntax@mail.imc.org Fri Feb 8 09:05:06 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B6828C37E for ; Fri, 8 Feb 2008 09:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.81 X-Spam-Level: X-Spam-Status: No, score=-96.81 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=1, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoFV-KKM8Z4j for ; Fri, 8 Feb 2008 09:05:05 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D824C28C377 for ; Fri, 8 Feb 2008 09:05:05 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m18GlcEH031977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Feb 2008 09:47:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m18GlcQo031976; Fri, 8 Feb 2008 09:47:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m18GlbVP031969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Feb 2008 09:47:38 -0700 (MST) (envelope-from kmarvin@google.com) Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id m18GlXWb020262 for ; Fri, 8 Feb 2008 08:47:33 -0800 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=k2ukGjExYYHdx70Oad0EPzxQrkJZBnJC1/rggtSqOAk9ays7U8jDXTrmg/eIcoD+f g5ciNGIlzwGmZkwqNE/+w== Received: from wx-out-0506.google.com (wxdh29.prod.google.com [10.70.134.29]) by zps19.corp.google.com with ESMTP id m18GlAvV002190 for ; Fri, 8 Feb 2008 08:47:32 -0800 Received: by wx-out-0506.google.com with SMTP id h29so3334112wxd.13 for ; Fri, 08 Feb 2008 08:47:32 -0800 (PST) Received: by 10.114.168.1 with SMTP id q1mr6781745wae.96.1202489251833; Fri, 08 Feb 2008 08:47:31 -0800 (PST) Received: by 10.114.125.4 with HTTP; Fri, 8 Feb 2008 08:47:31 -0800 (PST) Message-ID: <192fc9640802080847u4f68687s199623734d07fb6d@mail.gmail.com> Date: Fri, 8 Feb 2008 10:47:31 -0600 From: "Kyle Marvin" To: "Daniel Aleksandersen" Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Cc: "Atom emailing list" In-Reply-To: <200802041557.07194.aleksandersen+atomlist@runbox.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3421_17827592.1202489251816" References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <200802012018.52817.aleksandersen+atomlist@runbox.com> <20080204140931.GL25553@klangraum> <200802041557.07194.aleksandersen+atomlist@runbox.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------=_Part_3421_17827592.1202489251816 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Feb 4, 2008 8:57 AM, Daniel Aleksandersen < aleksandersen+atomlist@runbox.com> wrote: > Why does so many in this list fail to eralise that I am talking about the > element's element? Not an 's? I see these messages > were people think I am talking about entries all the time. That is wrong. > I know that they should uniquely identify the entries in the > element. But what about the the element? Hi Daniel, FWIW, in the GData implementation of AtomPub we keep the feed-level atom:id constant across all derived views of a collection/feed, and we support a wide variety of query models (by-date, pagination, by label, etc). Our rationale was consistent with what others have said on this thread, that it's beneficial because it can help to correlate that two different types of queries have the same origin. A related intepretation is the perspective that queries/pagination don't create a new logical feed, which giving them a unique id would imply. We do, however, provide a feed-level self link relation href that contains any query parameters, making it possible to retrieve the same (page, date-range, ...) logical view of the feed again. Thus, it "identifies a resource equivalent to the containing element". Cheers! -- Kyle ------=_Part_3421_17827592.1202489251816 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Feb 4, 2008 8:57 AM, Daniel Aleksandersen <aleksandersen+atomlist@runbox.com> wrote:
Why does so many in this list fail to eralise that I am talking about the
<feed> element's <id> element? Not an <entry>'s? I see these messages
were people think I am talking about entries all the time. That is wrong.
I know that they should uniquely identify the entries in the <entry>
element. But what about the the <feed> element?

Hi Daniel,

FWIW, in the GData implementation of AtomPub we keep the feed-level atom:id constant across all derived views of a collection/feed, and we support a wide variety of query models (by-date, pagination, by label, etc).    Our rationale was consistent with what others have said on this thread, that it's beneficial because it can help to correlate that two different types of queries have the same origin.   A related intepretation is the perspective that queries/pagination don't create a new logical feed, which giving them a unique id would imply.

We do, however, provide a feed-level self link relation href that contains any query parameters, making it possible to retrieve the same (page, date-range, ...) logical view of the feed again.  Thus, it "identifies a resource equivalent to the containing element".

Cheers!

-- Kyle

------=_Part_3421_17827592.1202489251816-- From owner-atom-syntax@mail.imc.org Fri Feb 8 15:09:49 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63D3E28C1DD for ; Fri, 8 Feb 2008 15:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJBfPbM-SF-J for ; Fri, 8 Feb 2008 15:09:48 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B598B28C76D for ; Fri, 8 Feb 2008 15:07:42 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m18Mte5m058166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Feb 2008 15:55:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m18MteLk058165; Fri, 8 Feb 2008 15:55:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m18Mteku058159 for ; Fri, 8 Feb 2008 15:55:40 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.3.166] (83-70-160-209.b-ras1.prp.dublin.eircom.net [83.70.160.209]) by chilco.textdrive.com (Postfix) with ESMTP id 8C4E6DE39F for ; Fri, 8 Feb 2008 22:55:39 +0000 (UTC) Message-ID: <47ACDDE9.4050901@dehora.net> Date: Fri, 08 Feb 2008 22:55:37 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Atom emailing list Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness References: <200802010502.59500.aleksandersen+atomlist@runbox.com> In-Reply-To: <200802010502.59500.aleksandersen+atomlist@runbox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Aleksandersen wrote: > Hi emailing list, > > I think this is a very difficult question. > > I atom:id-entify the main feed using an ISSN. (See below for example.) > This number is unique to my publication and I use it one time per feed. > > > urn:issn:1234-567X > > > But when it comes to atom archiving, it gets a little trickier…. Should I > use the same ISSN as for my recent updates feed? The idea of ISSN is that > it should uniquely identify all issues of a serial publication. So it > would be appropriate to use it in the static feed archives as well as in > the continuously update feed. It is not globally unique on a per my feed > basis; but it is globally unique on a per…me…basis. If that made any > sense to anyone? Yes, it made sense. Give the two feeds different ids. cheers Bill From owner-atom-syntax@mail.imc.org Fri Feb 8 15:09:54 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F327928C707 for ; Fri, 8 Feb 2008 15:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.154 X-Spam-Level: * X-Spam-Status: No, score=1.154 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ohx+e-WxxfD7 for ; Fri, 8 Feb 2008 15:09:53 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id BDC1F28C78C for ; Fri, 8 Feb 2008 15:08:59 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m18MpIXv057776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Feb 2008 15:51:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m18MpIeQ057775; Fri, 8 Feb 2008 15:51:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m18MpHlC057766 for ; Fri, 8 Feb 2008 15:51:17 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.3.166] (83-70-160-209.b-ras1.prp.dublin.eircom.net [83.70.160.209]) by chilco.textdrive.com (Postfix) with ESMTP id D2074DE3A5 for ; Fri, 8 Feb 2008 22:51:14 +0000 (UTC) Message-ID: <47ACDCE0.801@dehora.net> Date: Fri, 08 Feb 2008 22:51:12 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Atom list Subject: Re: Status of the wrapper References: <200801302231.09548.aleksandersen+atomlist@runbox.com> <200801310054.01673.aleksandersen+atomlist@runbox.com> <47A5DDAD.7000303@dehora.net> <200802031706.12319.aleksandersen+atomlist@runbox.com> In-Reply-To: <200802031706.12319.aleksandersen+atomlist@runbox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Aleksandersen wrote: > What I wanted was to question the standard. To me it appears broken. > Flawed, at least. If you want to insist on this line, the flawed standard is XMLNS, and its idea of a default namespace. cheers Bill From owner-atom-syntax@mail.imc.org Fri Feb 8 15:42:05 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08EC228C3CD for ; Fri, 8 Feb 2008 15:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAy5a0dkxCwb for ; Fri, 8 Feb 2008 15:42:04 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 409EB28C69C for ; Fri, 8 Feb 2008 15:42:00 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m18NT7NG060784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Feb 2008 16:29:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m18NT7wr060783; Fri, 8 Feb 2008 16:29:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fepv01.charter.net (fepv01.charter.net [209.225.8.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m18NT6uB060775 for ; Fri, 8 Feb 2008 16:29:06 -0700 (MST) (envelope-from antone@geckotribe.com) Received: from aacpub02.charter.net ([10.20.200.49]) by fepv01.charter.net (InterMail vM.7.08.03.00 201-2186-126-20070710) with ESMTP id <20080208232903.WYMO13839.fepv01.charter.net@aacpub02.charter.net>; Fri, 8 Feb 2008 18:29:03 -0500 Received: from G-Force.local ([71.87.92.92]) by aacpub02.charter.net with ESMTP id <20080208232903.KTQS24785.aacpub02.charter.net@G-Force.local>; Fri, 8 Feb 2008 18:29:03 -0500 Message-ID: <47ACE5BA.8030308@geckotribe.com> Date: Fri, 08 Feb 2008 17:28:58 -0600 From: Antone Roundy Reply-To: antone@geckotribe.com User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071127) MIME-Version: 1.0 To: Bill de hOra , atom-syntax Syntax Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <47ACDDE9.4050901@dehora.net> In-Reply-To: <47ACDDE9.4050901@dehora.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Chzlrs: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill de hOra wrote: > Daniel Aleksandersen wrote: >> But when it comes to atom archiving, it gets a little trickier…. >> Should I use the same ISSN as for my recent updates feed? The idea of >> ISSN is that it should uniquely identify all issues of a serial >> publication. So it would be appropriate to use it in the static feed >> archives as well as in the continuously update feed. It is not >> globally unique on a per my feed basis; but it is globally unique on a >> per…me…basis. If that made any sense to anyone? > > Yes, it made sense. Give the two feeds different ids. But Bill, it's not two different feeds, it's two different views of the same feed -- an archive view, and a "latest entries" (a.k.a. "sliding window") view. Thus the shared atom:id IS "globally unique on a per my feed basis", just not on a per feed DOCUMENT basis. From owner-atom-syntax@mail.imc.org Sat Feb 9 01:13:18 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9ED728C8D6 for ; Sat, 9 Feb 2008 01:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.385 X-Spam-Level: X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[AWL=-1.939, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGVeLYXPm7w3 for ; Sat, 9 Feb 2008 01:13:18 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 328EA28C8F4 for ; Sat, 9 Feb 2008 01:11:47 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m198wlLx091084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Feb 2008 01:58:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m198wliB091083; Sat, 9 Feb 2008 01:58:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m198wj6I091074 for ; Sat, 9 Feb 2008 01:58:46 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 09 Feb 2008 08:58:44 -0000 Received: from p508FA28F.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.162.143] by mail.gmx.net (mp009) with SMTP; 09 Feb 2008 09:58:44 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+aL9Zh8+6aD9VandT0X5QJc6WlsHeafLLZEXp7/v D0VZ7WqsFhFLUW Message-ID: <47AD6B41.30804@gmx.de> Date: Sat, 09 Feb 2008 09:58:41 +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: Bill de hOra CC: Atom list Subject: Re: Status of the wrapper References: <200801302231.09548.aleksandersen+atomlist@runbox.com> <200801310054.01673.aleksandersen+atomlist@runbox.com> <47A5DDAD.7000303@dehora.net> <200802031706.12319.aleksandersen+atomlist@runbox.com> <47ACDCE0.801@dehora.net> In-Reply-To: <47ACDCE0.801@dehora.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill de hOra wrote: > > Daniel Aleksandersen wrote: >> What I wanted was to question the standard. To me it appears broken. >> Flawed, at least. > > If you want to insist on this line, the flawed standard is XMLNS, and > its idea of a default namespace. For the record: I agree that some people have problems understanding how XMLNS works. That's certainly a problem with that spec, but there are countless FAQs that explain it, and the XML parsers *do* get it right. The problem is with people not using XML parsers to consume XML, or not reading the documentation of the API (local-name vs name in DOM, for instance). What we should have done in the spec is make sure that we have multiple examples showing different serializations for the same infoset. What we still can do is publish a document (IETF Informational, web site, whatever) giving and explaining examples. BR, Julian From owner-atom-syntax@mail.imc.org Sat Feb 9 06:18:05 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094FE28C971 for ; Sat, 9 Feb 2008 06:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.454 X-Spam-Level: * X-Spam-Status: No, score=1.454 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDx-aZ08d72q for ; Sat, 9 Feb 2008 06:18:04 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 01CDA28C96C for ; Sat, 9 Feb 2008 06:18:03 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m19E34NH011190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Feb 2008 07:03:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m19E34X4011189; Sat, 9 Feb 2008 07:03:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m19E32Pd011180 for ; Sat, 9 Feb 2008 07:03:03 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.3.166] (83-70-160-209.b-ras1.prp.dublin.eircom.net [83.70.160.209]) by chilco.textdrive.com (Postfix) with ESMTP id 7EC1CDCD7A for ; Sat, 9 Feb 2008 14:02:59 +0000 (UTC) Message-ID: <47ADB291.2080103@dehora.net> Date: Sat, 09 Feb 2008 14:02:57 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-syntax Syntax Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <47ACDDE9.4050901@dehora.net> <47ACE5BA.8030308@geckotribe.com> In-Reply-To: <47ACE5BA.8030308@geckotribe.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Antone Roundy wrote: > Bill de hOra wrote: >> Daniel Aleksandersen wrote: >>> But when it comes to atom archiving, it gets a little trickier…. >>> Should I use the same ISSN as for my recent updates feed? The idea of >>> ISSN is that it should uniquely identify all issues of a serial >>> publication. So it would be appropriate to use it in the static feed >>> archives as well as in the continuously update feed. It is not >>> globally unique on a per my feed basis; but it is globally unique on >>> a per…me…basis. If that made any sense to anyone? >> >> Yes, it made sense. Give the two feeds different ids. > > But Bill, it's not two different feeds, it's two different views of the > same feed -- an archive view, and a "latest entries" (a.k.a. "sliding > window") view. Thus the shared atom:id IS "globally unique on a per my > feed basis", just not on a per feed DOCUMENT basis. What breaks if they have two different ids? Put another way, why are two URLs required, but only one id? Are views (for any definition of "view") really a special case? cheers Bill From owner-atom-syntax@mail.imc.org Sat Feb 9 08:16:57 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC88F28C93C for ; Sat, 9 Feb 2008 08:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.961 X-Spam-Level: * X-Spam-Status: No, score=1.961 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_46=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8lvQ8tsUx+b for ; Sat, 9 Feb 2008 08:16:57 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8BDDA28C9B6 for ; Sat, 9 Feb 2008 08:16:39 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m19G3LGx020420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Feb 2008 09:03:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m19G3Lo7020419; Sat, 9 Feb 2008 09:03:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fepv01.charter.net (fepv01.charter.net [209.225.8.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m19G3KCO020412 for ; Sat, 9 Feb 2008 09:03:21 -0700 (MST) (envelope-from antone@geckotribe.com) Received: from aacpub02.charter.net ([10.20.200.49]) by fepv01.charter.net (InterMail vM.7.08.03.00 201-2186-126-20070710) with ESMTP id <20080209160320.MSI13839.fepv01.charter.net@aacpub02.charter.net> for ; Sat, 9 Feb 2008 11:03:20 -0500 Received: from G-Force.local ([71.87.92.92]) by aacpub02.charter.net with ESMTP id <20080209160320.ZVI24785.aacpub02.charter.net@G-Force.local> for ; Sat, 9 Feb 2008 11:03:20 -0500 Message-ID: <47ADCEC7.809@geckotribe.com> Date: Sat, 09 Feb 2008 10:03:19 -0600 From: Antone Roundy Reply-To: antone@geckotribe.com User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071127) MIME-Version: 1.0 To: atom-syntax Syntax Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <47ACDDE9.4050901@dehora.net> <47ACE5BA.8030308@geckotribe.com> <47ADB291.2080103@dehora.net> In-Reply-To: <47ADB291.2080103@dehora.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Chzlrs: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill de hOra wrote: >> But Bill, it's not two different feeds, it's two different views of >> the same feed -- an archive view, and a "latest entries" (a.k.a. >> "sliding window") view. Thus the shared atom:id IS "globally unique >> on a per my feed basis", just not on a per feed DOCUMENT basis. > > What breaks if they have two different ids? Perhaps nothing "breaks", but it's just a little odd to have the same entries originating from two different feeds. I presume neither document is going to use an atom:source element to show that they're not the originator of the entries, so it looks like you have two feeds and are erroneously using duplicate IDs for their entries. > Put another way, why are two URLs required, but only one id? Are views > (for any definition of "view") really a special case? Two URLs: so that people can choose to get either the archive of or the live end of the feed. One ID: because they're the same feed. And by the way, is the archive document one monolithic document containing everything, or is it going to be split into a chain of archive documents? If it's a chain, surely you wouldn't give each document in the chain it's own ID, right? The reason to use the same ID in both cases is to show that they both represent the same feed -- that the one is the archive of the other. From owner-atom-syntax@mail.imc.org Sun Feb 10 09:19:53 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88AC53A6833 for ; Sun, 10 Feb 2008 09:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.854 X-Spam-Level: * X-Spam-Status: No, score=1.854 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_46=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7i8+5bsgape for ; Sun, 10 Feb 2008 09:19:52 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 850CA3A680F for ; Sun, 10 Feb 2008 09:19:52 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1A11FbJ054698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Feb 2008 18:01:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1A11FYZ054697; Sat, 9 Feb 2008 18:01:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1A11E7O054689 for ; Sat, 9 Feb 2008 18:01:15 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.3.166] (83-70-160-209.b-ras1.prp.dublin.eircom.net [83.70.160.209]) by chilco.textdrive.com (Postfix) with ESMTP id D1375DDDD1 for ; Sun, 10 Feb 2008 01:01:11 +0000 (UTC) Message-ID: <47AE4CD5.6060603@dehora.net> Date: Sun, 10 Feb 2008 01:01:09 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-syntax Syntax Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <47ACDDE9.4050901@dehora.net> <47ACE5BA.8030308@geckotribe.com> <47ADB291.2080103@dehora.net> <47ADCEC7.809@geckotribe.com> In-Reply-To: <47ADCEC7.809@geckotribe.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Antone Roundy wrote: > > Bill de hOra wrote: >>> But Bill, it's not two different feeds, it's two different views of >>> the same feed -- an archive view, and a "latest entries" (a.k.a. >>> "sliding window") view. Thus the shared atom:id IS "globally unique >>> on a per my feed basis", just not on a per feed DOCUMENT basis. >> >> What breaks if they have two different ids? > > Perhaps nothing "breaks", but it's just a little odd to have the same > entries originating from two different feeds. I don't find that odd; whereas I might find the same entry originating from two different authors odd. > I presume neither > document is going to use an atom:source element to show that they're not > the originator of the entries, so it looks like you have two feeds and > are erroneously using duplicate IDs for their entries. If nothing breaks, how can it be an error? > And by the way, is the archive document one monolithic document > containing everything, or is it going to be split into a chain of > archive documents? If it's a chain, surely you wouldn't give each > document in the chain it's own ID, right? Why not? > The reason to use the same ID in both cases is to show that they both > represent the same feed -- that the one is the archive of the other. Try running Atom over XMPP. I think it might change how you view what a feed 'is'. It did for me; I have a hard time explaining how, but it seems that feeds are a workaround for HTTP, which doesn't have containers or iterators. cheers Bill From owner-atom-syntax@mail.imc.org Sun Feb 10 19:54:55 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B303A698D for ; Sun, 10 Feb 2008 19:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.439 X-Spam-Level: * X-Spam-Status: No, score=1.439 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_46=0.6] 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 JS7Yw3Alz6kl for ; Sun, 10 Feb 2008 19:54:54 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 913DC3A6838 for ; Sun, 10 Feb 2008 19:54:54 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1B3fuEn047020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Feb 2008 20:41:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1B3fu1G047019; Sun, 10 Feb 2008 20:41:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1B3fqWK047010 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 10 Feb 2008 20:41:53 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.162] (helo=pepper.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JOPXl-0008CO-Bd; Mon, 11 Feb 2008 04:41:21 +0100 Received: from [80.202.178.119] (helo=daniel.lan) by pepper.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JOPXk-0004IN-Mt; Mon, 11 Feb 2008 04:41:21 +0100 From: Daniel Aleksandersen To: Bill de hOra , Antone Roundy Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Date: Mon, 11 Feb 2008 04:39:25 +0100 User-Agent: KMail/1.9.5 References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <47ADCEC7.809@geckotribe.com> <47AE4CD5.6060603@dehora.net> In-Reply-To: <47AE4CD5.6060603@dehora.net> Cc: Atom list Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802110439.26133.aleksandersen+atomlist@runbox.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2008-02-10 02:01, you wrote: > Antone Roundy wrote: > > Bill de hOra wrote: > >>> But Bill, it's not two different feeds, it's two different views of > >>> the same feed -- an archive view, and a "latest entries" (a.k.a. > >>> "sliding window") view. Thus the shared atom:id IS "globally > >>> unique on a per my feed basis", just not on a per feed DOCUMENT > >>> basis. > >> > >> What breaks if they have two different ids? I am wondering what does break if they have the same ID? > > Perhaps nothing "breaks", but it's just a little odd to have the same > > entries originating from two different feeds. > > I don't find that odd; whereas I might find the same entry originating > from two different authors odd. I agree with Antone. It should be the same ID. If the point of the ID is to identify the source (collection, feed, whatever you want to call it) rather than the document (the feed file). > > I presume neither > > document is going to use an atom:source element to show that they're > > not the originator of the entries, so it looks like you have two > > feeds and are erroneously using duplicate IDs for their entries. > > If nothing breaks, how can it be an error? > > > And by the way, is the archive document one monolithic document > > containing everything, or is it going to be split into a chain of > > archive documents? If it's a chain, surely you wouldn't give each > > document in the chain it's own ID, right? > > Why not? > > > The reason to use the same ID in both cases is to show that they both > > represent the same feed -- that the one is the archive of the other. > > Try running Atom over XMPP. I think it might change how you view what a > feed 'is'. It did for me; I have a hard time explaining how, but it > seems that feeds are a workaround for HTTP, which doesn't have > containers or iterators. -- Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Mon Feb 11 00:22:16 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DD293A6AB0 for ; Mon, 11 Feb 2008 00:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.199 X-Spam-Level: * X-Spam-Status: No, score=1.199 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 dO-vyndd-zkf for ; Mon, 11 Feb 2008 00:22:15 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 7BB433A6AC3 for ; Mon, 11 Feb 2008 00:22:15 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1B8Blkd060114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Feb 2008 01:11:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1B8BlXp060113; Mon, 11 Feb 2008 01:11:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m1B8BjnW060069 for ; Mon, 11 Feb 2008 01:11:46 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.171.193.33] (HELO [10.225.208.19]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.1905064561 for ; Mon, 11 Feb 2008 19:11:10 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 11 Feb 2008 19:11:09 +1100 Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200802110439.26133.aleksandersen+atomlist@runbox.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 11/2/08 2:39 PM, "Daniel Aleksandersen" wrote: > I agree with Antone. It should be the same ID. If the point of the ID is > to identify the source (collection, feed, whatever you want to call it) > rather than the document (the feed file). I'm pretty much in agreement here, although I would posit that there are scenarios when the feed ID might be different, like re-syndication where there is some collation and selection going on. For example: one of my clients is a film industry news outlet and they have their own blog and feeds, but they also re-syndicate selected articles from the mainstream newspapers. In this scenario the one entry may appear in two different feeds, each with their own feed id but retaining the entry ID of course. Similarly if I gather together the "10 best blog posts about Atom" and publish that as a feed then that feed would have a different ID from the source feeds. Well, it'd have to, since if there are multiple source feeds I can only have one feed ID in the document I publish. The line gets blurry however when the re-syndicated feed only draws from one source .. is this a filtered version of the source feed, or a new feed? e. From owner-atom-syntax@mail.imc.org Mon Feb 11 07:01:17 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5BF3A6C43 for ; Mon, 11 Feb 2008 07:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6] 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 47ImR+ifpmuH for ; Mon, 11 Feb 2008 07:01:16 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C283C3A6879 for ; Mon, 11 Feb 2008 07:01:16 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1BEpFHA090051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Feb 2008 07:51:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1BEpF41090050; Mon, 11 Feb 2008 07:51:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1BEpB5U090042 for ; Mon, 11 Feb 2008 07:51:14 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by ug-out-1314.google.com with SMTP id z38so284003ugc.16 for ; Mon, 11 Feb 2008 06:51:11 -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:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=BqU6/gMejqoGJsfkPGvgp4SFCs0r60c6lNXpaFXi0Js=; b=pzqg37hs4uXOpstgsrsuWx7sDovEYUcdK9XNC6qdrMNXh0ktoZ6uuDNHEChWGNFuoyME6+6H6+sP+STjgZptn/m2w8I1GzzJ++rWxeD3BESGYeX9iiYzRETvCeAZ/34B9ssUAwSppAtVOc/AgaCurgPKWEpkQHI/VAa1p1pMCJ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qYAIXaqWXHIpsIGcOxkVzKBQYhtObBYDdvxIVHg9CXN68k3iUJcIbUgqZyxJs66/QDevcR1YNjbr5ovr/bxteo2NiyUtEafJbyzaGt9eXyQabZU3EUIJviJFHGVzsLbaZDy8V8jA4qmafedSNyAyPEihqe4FhWF6ixi9KN1LjRc= Received: by 10.67.116.9 with SMTP id t9mr9129057ugm.77.1202741470820; Mon, 11 Feb 2008 06:51:10 -0800 (PST) Received: by 10.67.101.8 with HTTP; Mon, 11 Feb 2008 06:51:10 -0800 (PST) Message-ID: Date: Mon, 11 Feb 2008 15:51:10 +0100 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200802110439.26133.aleksandersen+atomlist@runbox.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Feb 11, 2008 9:11 AM, Eric Scheid wrote: > > The line gets blurry however when the re-syndicated feed only draws from one > source .. is this a filtered version of the source feed, or a new feed? From RFC4287: 1. Introduction Atom is an XML-based document format that describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata. For example, each entry has a title. I understand it as "if the set/list of entries is different, this is not the same feed", as is the case with a "filtered version". I know this is subject to debate, as later on, the RFC reads: An Atom Feed Document is a representation of an Atom feed, including metadata about the feed, and some or all of the entries associated with it. Its root is the atom:feed element. Given that there's no mandatory way of getting "all of the entries with" a feed, you cannot really compare two feed documents (or two sets of feed documents) to determine whether they represent the same feed or not. My opinion however is that a "filtered version" of a feed is a new feed; and Google should mint new atom:id's for GData's search result feeds. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon Feb 11 18:41:09 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F763A68C9 for ; Mon, 11 Feb 2008 18:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 xNU1LKLEBeBY for ; Mon, 11 Feb 2008 18:41:09 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 1FD6C3A687E for ; Mon, 11 Feb 2008 18:41:08 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1C2Y7dB041453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Feb 2008 19:34:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1C2Y79g041451; Mon, 11 Feb 2008 19:34:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1C2Y3A1041440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Feb 2008 19:34:06 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m1C2Y1aB022608; Mon, 11 Feb 2008 20:34:01 -0600 Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m1B61Kbe025108; Mon, 11 Feb 2008 19:34:00 -0700 Received: from c-24-7-124-162.hsd1.ca.comcast.net by acsmt352.oracle.com with ESMTP id 3568278881202783551; Mon, 11 Feb 2008 18:32:31 -0800 Message-ID: <47B1053D.7070506@oracle.com> Date: Mon, 11 Feb 2008 18:32:29 -0800 From: Nikunj Mehta Organization: Oracle User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: atom-syntax Syntax , atom-protocol Protocol CC: Bill de hOra Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <47ACDDE9.4050901@dehora.net> <47ACE5BA.8030308@geckotribe.com> <47ADB291.2080103@dehora.net> <47ADCEC7.809@geckotribe.com> <47AE4CD5.6060603@dehora.net> In-Reply-To: <47AE4CD5.6060603@dehora.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill de hOra wrote: > > Antone Roundy wrote: > >> And by the way, is the archive document one monolithic document >> containing everything, or is it going to be split into a chain of >> archive documents? If it's a chain, surely you wouldn't give each >> document in the chain it's own ID, right? > > Why not? > >> The reason to use the same ID in both cases is to show that they both >> represent the same feed -- that the one is the archive of the other. > Not that there is an explicitly worded statement, but one would consider using the same ID in different archive documents of one feed. This is how the example in section 4 of RFC 5005 illustrates archive documents. In Antone's words, these form a chain of archive documents corresponding to a large feed. However, neither RFC 5005 nor RFC 5023 specifically state a requirement on the id of the partial lists of a collection, or the pages of a feed. In the absence of such a requirement, there cannot be any expectation that they are all identified identically. Given this, it seems perfectly logical to treat the id of a feed as a container aka feed document identifier, and that different containers aka feed documents (even when used in concert to represent a single feed) are better off using their own identifiers. Also, given that there is no requirement that the various physical views of a feed -- pages, archives, subsets derived through queries, etc -- carry a single id, the atom:id element inside a feed loses any meaning beyond a "container identifier". Applying this I conclude that there is no requirement that the GData query feed have the same atom:id as the one present in the collection feed. > Try running Atom over XMPP. I think it might change how you view what > a feed 'is'. It did for me; I have a hard time explaining how, but it > seems that feeds are a workaround for HTTP, which doesn't have > containers or iterators. Bill seems to suggest that seen in the context of XMPP, a feed document as a container is equivalent to a stream. Therefore, the stream identifier, seen as the session key, does not have any permanence. Not only that, there cannot be correlation between the identifiers of different streams. However, feeds are used for a one-to-many communication whereas XMPP streams are used for one-to-one communication, IMHO. It helps to have the same id be used for different feed documents, even those obtained at different times from the same URL. * Isn't this how feed aggregators seem to track the evolution of a feed's contents over time and to present a historical view of that feed? * If not, is there a standards-based means of tracking this evolution? It would help if the authors of RFC 5005 or 5023 can clarify if there is a reason why these specs do not deal with the issue of atom:id in pages, archive documents, and partial lists. Nikunj From owner-atom-syntax@mail.imc.org Tue Feb 12 03:41:02 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA51928C162 for ; Tue, 12 Feb 2008 03:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.085 X-Spam-Level: X-Spam-Status: No, score=-0.085 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 Whs7Cbcta7Hg for ; Tue, 12 Feb 2008 03:41:01 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D0EF43A6A5B for ; Tue, 12 Feb 2008 03:41:01 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1CBTGrZ075082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2008 04:29:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1CBTGLt075081; Tue, 12 Feb 2008 04:29:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1CBTE7M075068 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 12 Feb 2008 04:29:16 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.160] (helo=penny.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JOtJs-0001Nd-PZ; Tue, 12 Feb 2008 12:29:00 +0100 Received: from [80.202.178.119] (helo=daniel.lan) by penny.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JOtJn-0006sv-If; Tue, 12 Feb 2008 12:28:56 +0100 From: Daniel Aleksandersen To: Nikunj Mehta , Atom emailing list Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Date: Tue, 12 Feb 2008 12:26:58 +0100 User-Agent: KMail/1.9.5 References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <47AE4CD5.6060603@dehora.net> <47B1053D.7070506@oracle.com> In-Reply-To: <47B1053D.7070506@oracle.com> Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200802121226.58627.aleksandersen+atomlist@runbox.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1CBTG7L075076 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2008-02-12 03:32, you wrote: > Bill de hOra wrote: > > Antone Roundy wrote: > >> And by the way, is the archive document one monolithic document > >> containing everything, or is it going to be split into a chain of > >> archive documents? If it's a chain, surely you wouldn't give each > >> document in the chain it's own ID, right? > > > > Why not? > > > >> The reason to use the same ID in both cases is to show that they > >> both represent the same feed -- that the one is the archive of the > >> other. > > Not that there is an explicitly worded statement, but one would > consider using the same ID in different archive documents of one feed. > This is how the example in section 4 of RFC 5005 illustrates archive > documents. In Antone's words, these form a chain of archive documents > corresponding to a large feed. > > However, neither RFC 5005 nor RFC 5023 specifically state a requirement > on the id of the partial lists of a collection, or the pages of a feed. > In the absence of such a requirement, there cannot be any expectation > that they are all identified identically. Given this, it seems > perfectly logical to treat the id of a feed as a container aka feed > document identifier, and that different containers aka feed documents > (even when used in concert to represent a single feed) are better off > using their own identifiers. > > Also, given that there is no requirement that the various physical > views of a feed -- pages, archives, subsets derived through queries, > etc -- carry a single id, the atom:id element inside a feed loses any > meaning beyond a "container identifier". Applying this I conclude that > there is no requirement that the GData query feed have the same atom:id > as the one present in the collection feed. > > > Try running Atom over XMPP. I think it might change how you view what > > a feed 'is'. It did for me; I have a hard time explaining how, but > > it seems that feeds are a workaround for HTTP, which doesn't have > > containers or iterators. > > Bill seems to suggest that seen in the context of XMPP, a feed document > as a container is equivalent to a stream. Therefore, the stream > identifier, seen as the session key, does not have any permanence. Not > only that, there cannot be correlation between the identifiers of > different streams. > > However, feeds are used for a one-to-many communication whereas XMPP > streams are used for one-to-one communication, IMHO. It helps to have > the same id be used for different feed documents, even those obtained > at different times from the same URL. > > * Isn't this how feed aggregators seem to track the evolution of a > feed's contents over time and to present a historical view of > that feed? > * If not, is there a standards-based means of tracking this > evolution? > > It would help if the authors of RFC 5005 or 5023 can clarify if there > is a reason why these specs do not deal with the issue of atom:id in > pages, archive documents, and partial lists. The very first question that came to my mind after reading RFC 5005 was ‘but what about the atom:id?’ I thought it may have been overlooked in the specifications. -- Daniel Aleksandersen http://www.opensourcenotebook.com/ From owner-atom-syntax@mail.imc.org Tue Feb 12 07:09:55 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E234628C25C for ; Tue, 12 Feb 2008 07:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.017 X-Spam-Level: X-Spam-Status: No, score=-98.017 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=1, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, 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 PcKjqrZ5BZS9 for ; Tue, 12 Feb 2008 07:09:54 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B981928C2D5 for ; Tue, 12 Feb 2008 07:09:15 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1CEwqIX090685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2008 07:58:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1CEwqHJ090684; Tue, 12 Feb 2008 07:58:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1CEwnXi090675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Feb 2008 07:58:51 -0700 (MST) (envelope-from kmarvin@google.com) Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id m1CEwcwY000571 for ; Tue, 12 Feb 2008 14:58:39 GMT DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=x5n8lo0Tn8XQ06NqSRsUda3txOdzglQ2x5Pw+d4XY8YwLpDNl3AFQnSid6gPEyNYX OguPsJjr8rTk6K18mLP+w== Received: from rn-out-0910.google.com (rnbv46.prod.google.com [10.38.98.46]) by zps37.corp.google.com with ESMTP id m1CEvUYW020489 for ; Tue, 12 Feb 2008 06:58:37 -0800 Received: by rn-out-0910.google.com with SMTP id v46so2512272rnb.14 for ; Tue, 12 Feb 2008 06:58:37 -0800 (PST) Received: by 10.142.98.18 with SMTP id v18mr1093605wfb.61.1202828317219; Tue, 12 Feb 2008 06:58:37 -0800 (PST) Received: by 10.143.17.20 with HTTP; Tue, 12 Feb 2008 06:58:37 -0800 (PST) Message-ID: <192fc9640802120658m286e30b3g8a28e23901bf4393@mail.gmail.com> Date: Tue, 12 Feb 2008 08:58:37 -0600 From: "Kyle Marvin" To: "Nikunj Mehta" Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness Cc: "atom-syntax Syntax" , "atom-protocol Protocol" , "Bill de hOra" In-Reply-To: <47B1053D.7070506@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_45573_9896885.1202828317205" References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <47ACDDE9.4050901@dehora.net> <47ACE5BA.8030308@geckotribe.com> <47ADB291.2080103@dehora.net> <47ADCEC7.809@geckotribe.com> <47AE4CD5.6060603@dehora.net> <47B1053D.7070506@oracle.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------=_Part_45573_9896885.1202828317205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Feb 11, 2008 8:32 PM, Nikunj Mehta wrote: > > Bill de hOra wrote: > > > > Antone Roundy wrote: > > > >> And by the way, is the archive document one monolithic document > >> containing everything, or is it going to be split into a chain of > >> archive documents? If it's a chain, surely you wouldn't give each > >> document in the chain it's own ID, right? > > > > Why not? > > > >> The reason to use the same ID in both cases is to show that they both > >> represent the same feed -- that the one is the archive of the other. > > > Not that there is an explicitly worded statement, but one would consider > using the same ID in different archive documents of one feed. This is > how the example in section 4 of RFC 5005 illustrates archive documents. > In Antone's words, these form a chain of archive documents corresponding > to a large feed. > > However, neither RFC 5005 nor RFC 5023 specifically state a requirement > on the id of the partial lists of a collection, or the pages of a feed. > In the absence of such a requirement, there cannot be any expectation > that they are all identified identically. I can agree with the "cannot be any expectation" part of this, given the general vagueness of specification around feed-level atom:id; however, I'd observe that "not required to use the same atom:id" due to lack of clarity is distinctly different from "thus should not use the same atom:id". > Given this, it seems perfectly > logical to treat the id of a feed as a container aka feed document > identifier, and that different containers aka feed documents (even when > used in concert to represent a single feed) are better off using their > own identifiers. > I'm not necessarily following the logic. See above statements. A use case for the benefits of sharing an atom:id (being able to tell that all feed documents derive from the same source collection) has been stated, and I suspect was the motivation for the sample usage in RFC5005. If this benefit is perceived to exist in other contexts as well, why would it not be applicable as well? Regarding the argument that "filtering" is somehow different, isn't pagination or archival just filtering of a different type, i.e. by sequential order and/or by time rather than by other attributes of the feed content? I've not yet seen a strong argument for why making them different is beneficial or helpful or why making them the same is harmful, but maybe I'm just being missing something. Finally, I want to be clear that in stating the our implementation, I wasn't try to impose a particular generalized interpretation on feed id usage. I was just sharing experience and rationale as an implementor to inform the discussion. YMMV. Cheers! -- Kyle > Also, given that there is no requirement that the various physical views > of a feed -- pages, archives, subsets derived through queries, etc -- > carry a single id, the atom:id element inside a feed loses any meaning > beyond a "container identifier". Applying this I conclude that there is > no requirement that the GData query feed have the same atom:id as the > one present in the collection feed. See above. Stating that something doesn't have to be done a particular way is not equivalent to saying it should not. > > Try running Atom over XMPP. I think it might change how you view what > > a feed 'is'. It did for me; I have a hard time explaining how, but it > > seems that feeds are a workaround for HTTP, which doesn't have > > containers or iterators. > Bill seems to suggest that seen in the context of XMPP, a feed document > as a container is equivalent to a stream. Therefore, the stream > identifier, seen as the session key, does not have any permanence. Not > only that, there cannot be correlation between the identifiers of > different streams. > Again, I don't see this as an argument against having the same atom:id. It just informs that doing so isn't useful (but is not harmful) in that particular context. > However, feeds are used for a one-to-many communication whereas XMPP > streams are used for one-to-one communication, IMHO. It helps to have > the same id be used for different feed documents, even those obtained at > different times from the same URL. > I think this particular aspect isn't open for debate, at least to me. It certainly seems significantly useful for the same feed retrieved repetitively from the same url to have a constant atom:id. > * Isn't this how feed aggregators seem to track the evolution of a > feed's contents over time and to present a historical view of that > feed? > * If not, is there a standards-based means of tracking this evolution? > > It would help if the authors of RFC 5005 or 5023 can clarify if there is > a reason why these specs do not deal with the issue of atom:id in pages, > archive documents, and partial lists. > > Nikunj > > ------=_Part_45573_9896885.1202828317205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Feb 11, 2008 8:32 PM, Nikunj Mehta <nikunj.mehta@oracle.com> wrote:

Bill de hOra wrote:
>
> Antone Roundy wrote:
>
>> And by the way, is the archive document one monolithic document
>> containing everything, or is it going to be split into a chain of
>> archive documents?  If it's a chain, surely you wouldn't give each
>> document in the chain it's own ID, right?
>
> Why not?
>
>> The reason to use the same ID in both cases is to show that they both
>> represent the same feed -- that the one is the archive of the other.
>
Not that there is an explicitly worded statement, but one would consider
using the same ID in different archive documents of one feed. This is
how the example in section 4 of RFC 5005 illustrates archive documents.
In Antone's words, these form a chain of archive documents corresponding
to a large feed.

However, neither RFC 5005 nor RFC 5023 specifically state a requirement
on the id of the partial lists of a collection, or the pages of a feed.
In the absence of such a requirement, there cannot be any expectation
that they are all identified identically.

I can agree with the "cannot be any expectation" part of this, given the general vagueness of specification around feed-level atom:id;  however, I'd observe that "not required to use the same atom:id"  due to lack of clarity is distinctly different from "thus should not use the same atom:id".
 
Given this, it seems perfectly
logical to treat the id of a feed as a container aka feed document
identifier, and that different containers aka feed documents (even when
used in concert to represent a single feed) are better off using their
own identifiers.

I'm not necessarily following the logic.   See above statements.   A use case for the benefits of sharing an atom:id (being able to tell that all feed documents derive from the same source collection) has been stated, and I suspect was the motivation for the sample usage in RFC5005.    If this benefit is perceived to exist in other contexts as well, why would it not be applicable as well?

Regarding the argument that "filtering" is somehow different, isn't pagination or archival just filtering of a different type, i.e. by sequential order and/or by time rather than by other attributes of the feed content?

I've not yet seen a strong argument for why making them different is beneficial or helpful or why making them the same is harmful, but maybe I'm just being missing something.

Finally, I want to be clear that in stating the our implementation, I wasn't try to impose a particular generalized interpretation on feed id usage.   I was just sharing experience and rationale as an implementor to inform the discussion.    YMMV.

Cheers!

-- Kyle


Also, given that there is no requirement that the various physical views
of a feed -- pages, archives, subsets derived through queries, etc --
carry a single id, the atom:id element inside a feed loses any meaning
beyond a "container identifier". Applying this I conclude that there is
no requirement that the GData query feed have the same atom:id as the
one present in the collection feed.

See above.  Stating that something doesn't have to be done a particular way is not equivalent to saying it should not.


> Try running Atom over XMPP. I think it might change how you view what
> a  feed 'is'. It did for me; I have a hard time explaining how, but it
> seems that feeds are a workaround for HTTP, which doesn't have
> containers or iterators.
Bill seems to suggest that seen in the context of XMPP, a feed document
as a container is equivalent to a stream. Therefore, the stream
identifier, seen as the session key, does not have any permanence. Not
only that, there cannot be correlation between the identifiers of
different streams.

Again, I don't see this as an argument against having the same atom:id.  It just informs that doing so isn't useful (but is not harmful) in that particular context.


However, feeds are used for a one-to-many communication whereas XMPP
streams are used for one-to-one communication, IMHO. It helps to have
the same id be used for different feed documents, even those obtained at
different times from the same URL.

I think this particular aspect isn't open for debate, at least to me.  It certainly seems significantly useful for the same feed retrieved repetitively from the same url to have a constant atom:id.


   * Isn't this how feed aggregators seem to track the evolution of a
     feed's contents over time and to present a historical view of that
     feed?
   * If not, is there a standards-based means of tracking this evolution?

It would help if the authors of RFC 5005 or 5023 can clarify if there is
a reason why these specs do not deal with the issue of atom:id in pages,
archive documents, and partial lists.

Nikunj


------=_Part_45573_9896885.1202828317205-- From owner-atom-syntax@mail.imc.org Tue Feb 12 17:19:33 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD93F28C511 for ; Tue, 12 Feb 2008 17:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 bdf6bYNBMr14 for ; Tue, 12 Feb 2008 17:19:32 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id CE96528C2F8 for ; Tue, 12 Feb 2008 17:19:32 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1D1Bta8039982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2008 18:11:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1D1Btkm039981; Tue, 12 Feb 2008 18:11:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1D1BsRT039967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2008 18:11:54 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m1D1BiYI014926; Tue, 12 Feb 2008 18:11:49 -0700 Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m1CAgC6C002696; Tue, 12 Feb 2008 18:11:43 -0700 Received: from dhcp-1op3-1op4-west-144-25-166-194.us.oracle.com by acsmt350.oracle.com with ESMTP id 3572854641202865042; Tue, 12 Feb 2008 17:10:42 -0800 Message-ID: <47B24390.6050808@oracle.com> Date: Tue, 12 Feb 2008 17:10:40 -0800 From: Nikunj Mehta Organization: Oracle User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Kyle Marvin CC: atom-syntax Syntax , atom-protocol Protocol Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness References: <200802010502.59500.aleksandersen+atomlist@runbox.com> <47ACDDE9.4050901@dehora.net> <47ACE5BA.8030308@geckotribe.com> <47ADB291.2080103@dehora.net> <47ADCEC7.809@geckotribe.com> <47AE4CD5.6060603@dehora.net> <47B1053D.7070506@oracle.com> <192fc9640802120658m286e30b3g8a28e23901bf4393@mail.gmail.com> In-Reply-To: <192fc9640802120658m286e30b3g8a28e23901bf4393@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Kyle Marvin wrote: > On Feb 11, 2008 8:32 PM, Nikunj Mehta > wrote: > > However, neither RFC 5005 nor RFC 5023 specifically state a > requirement > on the id of the partial lists of a collection, or the pages of a > feed. > In the absence of such a requirement, there cannot be any expectation > that they are all identified identically. > > > I can agree with the "cannot be any expectation" part of this, given > the general vagueness of specification around feed-level atom:id; > however, I'd observe that "not required to use the same atom:id" due > to lack of clarity is distinctly different from "thus should not use > the same atom:id". Postel's rule at work here. I am cautioning Atom users in general to not carry an expectation on the atom:id. Since it is not in the spec, it is gratuitous to use the same atom:id. I would do it too, but not sure that a total stranger would be able to use it meaningfully. > > > Given this, it seems perfectly > logical to treat the id of a feed as a container aka feed document > identifier, and that different containers aka feed documents (even > when > used in concert to represent a single feed) are better off using their > own identifiers. > > > I'm not necessarily following the logic. See above statements. A > use case for the benefits of sharing an atom:id (being able to tell > that all feed documents derive from the same source collection) has > been stated, and I suspect was the motivation for the sample usage in > RFC5005. If this benefit is perceived to exist in other contexts as > well, why would it not be applicable as well? I don't doubt the benefits. The question is - is there a way to create a standard that requires such sharing of atom:id across feed views? The converse is - if the sharing of atom:id cannot be standardized, then is there much benefit in reusing the atom:id? > > Regarding the argument that "filtering" is somehow different, isn't > pagination or archival just filtering of a different type, i.e. by > sequential order and/or by time rather than by other attributes of the > feed content? No argument here - I say as much below > I've not yet seen a strong argument for why making them different is > beneficial or helpful or why making them the same is harmful, but > maybe I'm just being missing something. > > Finally, I want to be clear that in stating the our implementation, I > wasn't try to impose a particular generalized interpretation on feed > id usage. I was just sharing experience and rationale as an > implementor to inform the discussion. YMMV. Its great the GData is benefiting from the specialized interpretation of the atom:id and I would like that to be the standard. Your experience is definitely beneficial to this discussion. > > Cheers! > > -- Kyle > > > Also, given that there is no requirement that the various physical > views > of a feed -- pages, archives, subsets derived through queries, etc -- > carry a single id, the atom:id element inside a feed loses any meaning > beyond a "container identifier". Applying this I conclude that > there is > no requirement that the GData query feed have the same atom:id as the > one present in the collection feed. > > > See above. Stating that something doesn't have to be done a > particular way is not equivalent to saying it should not. > > > > Try running Atom over XMPP. I think it might change how you view > what > > a feed 'is'. It did for me; I have a hard time explaining how, > but it > > seems that feeds are a workaround for HTTP, which doesn't have > > containers or iterators. > Bill seems to suggest that seen in the context of XMPP, a feed > document > as a container is equivalent to a stream. Therefore, the stream > identifier, seen as the session key, does not have any permanence. Not > only that, there cannot be correlation between the identifiers of > different streams. > > > Again, I don't see this as an argument against having the same > atom:id. It just informs that doing so isn't useful (but is not > harmful) in that particular context. > > > However, feeds are used for a one-to-many communication whereas XMPP > streams are used for one-to-one communication, IMHO. It helps to have > the same id be used for different feed documents, even those > obtained at > different times from the same URL. > > > I think this particular aspect isn't open for debate, at least to me. > It certainly seems significantly useful for the same feed retrieved > repetitively from the same url to have a constant atom:id. > > > * Isn't this how feed aggregators seem to track the evolution of a > feed's contents over time and to present a historical view of > that > feed? > * If not, is there a standards-based means of tracking this > evolution? > > It would help if the authors of RFC 5005 or 5023 can clarify if > there is > a reason why these specs do not deal with the issue of atom:id in > pages, > archive documents, and partial lists. > > Nikunj > > -- Nikunj Mehta | XML Feeds Architect | +1.650.506.0679 Oracle Database Development 100 Oracle Parkway, Redwood Shores, CA 94065 From owner-atom-syntax@mail.imc.org Sat Feb 16 14:00:02 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80F228C2E8 for ; Sat, 16 Feb 2008 14:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.423 X-Spam-Level: X-Spam-Status: No, score=-3.423 tagged_above=-999 required=5 tests=[AWL=-3.176, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6] 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 YntWod4E1YJV for ; Sat, 16 Feb 2008 14:00:02 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id BF04528C2F6 for ; Sat, 16 Feb 2008 13:59:37 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1GLlibT043628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Feb 2008 14:47:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1GLlijN043627; Sat, 16 Feb 2008 14:47:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1GLlgBK043619 for ; Sat, 16 Feb 2008 14:47:43 -0700 (MST) (envelope-from foolistbar@googlemail.com) Received: by fg-out-1718.google.com with SMTP id 22so833502fge.26 for ; Sat, 16 Feb 2008 13:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; bh=QMAxzhE7IF0MDuezdj7rOpH9VjQqgo9kuBSZjVjP4e8=; b=WBj1oSBciLRmAvO2A3i3LD2T+lXlww5Ly6h4WIDM0g6ZGfZIYNk/ahTOpjP58kMq+Nde6aCzsEXbhLcMjkcfcigpqJzGNql5dt9uWIKNz+o8fPPlua3XvVJ/Cq4keH0NWyZ+qp82nVm+YBoWHc2iHrcwj68KgwrEwLNLQ4cB4Ik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; b=W2Hd9QO+3c3nVUtfT6ApNmFDwxVeCRg818bwNQcw9Hw3LjU7btr7ZFrbhvALr77INLSIwjMYS2K9YFGMk1lQ+uYtxsB4bOKXkU/NSTH/HDCWuwjJylHmLE9D05MyGSZL++LNHHHHytGT1aMlEsC3Ki7JYJ8235tzOMAD8V/M4IQ= Received: by 10.82.172.10 with SMTP id u10mr8135755bue.14.1203198460601; Sat, 16 Feb 2008 13:47:40 -0800 (PST) Received: from ?192.168.0.116? ( [86.151.228.75]) by mx.google.com with ESMTPS id y34sm9107005iky.6.2008.02.16.13.47.38 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Feb 2008 13:47:39 -0800 (PST) Cc: atom-syntax Message-Id: <0924F2A7-509E-4104-9BDF-E40D1BD90C20@googlemail.com> From: Geoffrey Sneddon To: habari-dev@googlegroups.com In-Reply-To: <47B7316F.9030808@gmail.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: [habari-dev] Re: Timestamps Date: Sat, 16 Feb 2008 21:47:36 +0000 References: <2264F4BF-5F26-472F-81BC-1692C22A533B@googlemail.com> <47B7316F.9030808@gmail.com> X-Mailer: Apple Mail (2.919.2) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1GLlhBK043622 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To those on atom-syntax who've got this through being CC'd, Habari currently uses one feed for both end users and the APP collection, and is currently sorted by atom:updated (which is currently any update, but seems to be little opposition to fixing that) the seeming issue is splitting the end user feed and the APP collection up, as several are questioning what the need to actually order by app:edited is. What really is the need for it to be ordered by app:edited? I can see nothing in the archives or on the wiki about the ordering (apart from its introduction). On 16 Feb 2008, at 18:54, Ben Ramsey wrote: > On 2/16/08 6:54 AM, Geoffrey Sneddon wrote: >> The other importance that this change makes more obvious is that the >> Atom Syndication Feed and Atom Publishing Protocol collection need to >> be in separate documents, as they have different sorting >> requirements. > > I see no need for them to be separate documents. > > Section 4.1.1 of RFC 4287 states "this specification assigns no > significance to > the order of atom:entry elements within the feed." So, I don't see > where the > Atom Syndication Format specifies how entries should be ordered. > AtomPub simply > takes this a step farther by actually assigning significance to the > order, > stating in section 10: "Entries in the returned Atom Feed SHOULD be > ordered by > their 'app:edited' property, with the most recently edited Entries > coming first > in the document order." I didn't mean ASF actually required any specific order, I meant that for end users it makes no sense to order the end user feed by app:edited (as nobody cares about a typo from several years ago being corrected, for example); we have no valid reason in our circumstances to order the APP collection (by app:edited) against the "SHOULD" in APP, so in that way they have conflicting needs. This means they need to be separate documents. > To me, this doesn't warrant a distinction between Atom Syndication > Feeds and > Atom Protocol Collections. Section 10 of the protocol also states: "No > distinction is made between Collection Feeds and other kinds of > Feeds." To me, > this means that they should be treated exactly the same. The > Protocol simply > adds a few more rules to Feed. Yeah, sure, it's possible to have them as the same, but to follow what APP actually says you need it ordered by app:edited, which makes no sense in the context of a normal feed that readers subscribe to. -- Geoffrey Sneddon From owner-atom-syntax@mail.imc.org Sat Feb 16 14:35:08 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85E2A28C2B0 for ; Sat, 16 Feb 2008 14:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.246 X-Spam-Level: X-Spam-Status: No, score=-100.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6, 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 wFo1zFj-H6HV for ; Sat, 16 Feb 2008 14:35:07 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5735928C2D0 for ; Sat, 16 Feb 2008 14:34:02 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1GMPYCW046933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Feb 2008 15:25:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1GMPXoi046932; Sat, 16 Feb 2008 15:25:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1GMPWpk046917 for ; Sat, 16 Feb 2008 15:25:33 -0700 (MST) (envelope-from john@johnpanzer.com) Received: by wa-out-1112.google.com with SMTP id l24so2023771waf.22 for ; Sat, 16 Feb 2008 14:25:32 -0800 (PST) Received: by 10.114.103.1 with SMTP id a1mr1077973wac.45.1203200732278; Sat, 16 Feb 2008 14:25:32 -0800 (PST) Received: from ?192.168.1.3? ( [70.231.226.203]) by mx.google.com with ESMTPS id q18sm12250880pog.12.2008.02.16.14.25.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 16 Feb 2008 14:25:31 -0800 (PST) Message-ID: <47B763B8.7070008@acm.org> Date: Sat, 16 Feb 2008 14:29:12 -0800 From: John Panzer Reply-To: jpanzer@acm.org User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Geoffrey Sneddon CC: habari-dev@googlegroups.com, atom-syntax Subject: Re: [habari-dev] Re: Timestamps References: <2264F4BF-5F26-472F-81BC-1692C22A533B@googlemail.com> <47B7316F.9030808@gmail.com> <0924F2A7-509E-4104-9BDF-E40D1BD90C20@googlemail.com> In-Reply-To: <0924F2A7-509E-4104-9BDF-E40D1BD90C20@googlemail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: So the rationale for ordering by app:edited is so that edit-oriented clients can easily synchronize their local copies of the collection with the server side versions. They need to walk back only as far as their last synchronization. This is a different need than read-only syndicators, which usually don't care about missed entries and as you point out don't care about a typo fixed in something from two years ago. So you have two use cases for the same data. You can use the same feed for both, but you'll need to compromise a bit. Or you can have two feeds and tailor each. Blogger, the software I work on, has the same issue of course. John Geoffrey Sneddon wrote: > > To those on atom-syntax who've got this through being CC'd, Habari > currently uses one feed for both end users and the APP collection, and > is currently sorted by atom:updated (which is currently any update, > but seems to be little opposition to fixing that) the seeming issue > is splitting the end user feed and the APP collection up, as several > are questioning what the need to actually order by app:edited is. What > really is the need for it to be ordered by app:edited? I can see > nothing in the archives or on the wiki about the ordering (apart from > its introduction). > > On 16 Feb 2008, at 18:54, Ben Ramsey wrote: > >> On 2/16/08 6:54 AM, Geoffrey Sneddon wrote: >>> The other importance that this change makes more obvious is that the >>> Atom Syndication Feed and Atom Publishing Protocol collection need to >>> be in separate documents, as they have different sorting requirements. >> >> I see no need for them to be separate documents. >> >> Section 4.1.1 of RFC 4287 states "this specification assigns no >> significance to >> the order of atom:entry elements within the feed." So, I don't see >> where the >> Atom Syndication Format specifies how entries should be ordered. >> AtomPub simply >> takes this a step farther by actually assigning significance to the >> order, >> stating in section 10: "Entries in the returned Atom Feed SHOULD be >> ordered by >> their 'app:edited' property, with the most recently edited Entries >> coming first >> in the document order." > > I didn't mean ASF actually required any specific order, I meant that > for end users it makes no sense to order the end user feed by > app:edited (as nobody cares about a typo from several years ago being > corrected, for example); we have no valid reason in our circumstances > to order the APP collection (by app:edited) against the "SHOULD" in > APP, so in that way they have conflicting needs. This means they need > to be separate documents. > >> To me, this doesn't warrant a distinction between Atom Syndication >> Feeds and >> Atom Protocol Collections. Section 10 of the protocol also states: "No >> distinction is made between Collection Feeds and other kinds of >> Feeds." To me, >> this means that they should be treated exactly the same. The Protocol >> simply >> adds a few more rules to Feed. > > Yeah, sure, it's possible to have them as the same, but to follow what > APP actually says you need it ordered by app:edited, which makes no > sense in the context of a normal feed that readers subscribe to. > > > -- > Geoffrey Sneddon > > > From owner-atom-syntax@mail.imc.org Sun Feb 17 14:09:56 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E2A3A6BE5 for ; Sun, 17 Feb 2008 14:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-4.383, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_47=0.6] 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 fPeyIo6-2etI for ; Sun, 17 Feb 2008 14:09:55 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 4D7953A6CB9 for ; Sun, 17 Feb 2008 14:04:44 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1H39X6u065931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Feb 2008 20:09:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1H39XTo065930; Sat, 16 Feb 2008 20:09:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1H39W24065924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 16 Feb 2008 20:09:32 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [70.132.143.199]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 35E7123E4A9; Sat, 16 Feb 2008 22:09:31 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" Cc: References: <2264F4BF-5F26-472F-81BC-1692C22A533B@googlemail.com> <47B7316F.9030808@gmail.com> <0924F2A7-509E-4104-9BDF-E40D1BD90C20@googlemail.com> Subject: RE: [habari-dev] Re: Timestamps Date: Sat, 16 Feb 2008 19:09:33 -0800 Message-ID: <002d01c87112$85d9e9a0$6501a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0924F2A7-509E-4104-9BDF-E40D1BD90C20@googlemail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Achw5eOyol2uugv1TWqYvBsivu2WfQAJuB9A Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1H39X23065925 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Geoffrey Sneddon wrote: > To those on atom-syntax who've got this through being CC'd, > Habari currently uses one feed for both end users and the APP > collection, and is currently sorted by atom:updated (which is > currently any update, but seems to be little opposition to > fixing that) the seeming issue is splitting the end user > feed and the APP collection up, as several are questioning > what the need to actually order by app:edited is. What really > is the need for it to be ordered by app:edited? I can see > nothing in the archives or on the wiki about the ordering > (apart from its introduction). Usually a blogging server will implement app:draft in a way that the collection feed will contain draft entries and the public feed won't. So, you need (at least) two feeds anyway. There have been many discussions on the atom-protocol list about how to efficiently synchronize a client's copy of a collection with the server's copy. Those synchronization mechanisms are based on the premise that a client can page through the feed until it gets to an entry with an app:edited timestamp that is earlier than the last time it synced, and then stop. Unless you sort by app:edited, your server will not interoperate with any client that works like this. When media resources (images, videos) are updated, the media link entry in the collection feed for that media resource should have its app:edited timestamp updated. If you insist on sorting by atom:updated then make sure you update atom:updated in that case. When I implemented an AtomPub server, I also found there to be some performance reasons for implementing a separate collection feed. First, you can combine all the media link entries with the regular entries in the collection feed, but you would never want to do that for your public feed. Also, there is really no reason for a collection feed for a blog to contain anything close to the full content of the entry; if you cut out all the optional bits of the entry (besides the summary, which is sometimes useful for the blog editor), you can fit a lot more entries per KB in the collection feed in your (usually full-content) public feed, and/or you can make the collection feed pages much smaller. I am usually able to fit about 4 blog entries per kilobyte (compressed) in my collection feeds document, whereas the entries in the full-content public feed are usually ten times that size. - Brian From owner-atom-syntax@mail.imc.org Mon Feb 18 22:35:27 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB9B3A69D6 for ; Mon, 18 Feb 2008 22:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.415 X-Spam-Level: X-Spam-Status: No, score=0.415 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, WEIRD_PORT=0.001, WHOIS_NETSOLPR=0.001] 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 X3RhtedYko2m for ; Mon, 18 Feb 2008 22:35:26 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id EC97128C178 for ; Mon, 18 Feb 2008 22:35:22 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1J6NYHs005352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 23:23:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1J6NYo7005351; Mon, 18 Feb 2008 23:23:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1J6NUEG005345 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 18 Feb 2008 23:23:33 -0700 (MST) (envelope-from Pablo.Castro@microsoft.com) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 18 Feb 2008 22:23:30 -0800 Received: from NA-EXMSG-C107.redmond.corp.microsoft.com ([157.54.62.34]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Mon, 18 Feb 2008 22:23:30 -0800 From: Pablo Castro To: "atom-syntax@imc.org" Date: Mon, 18 Feb 2008 22:23:26 -0800 Subject: Related entries and feeds: links and link expansion Thread-Topic: Related entries and feeds: links and link expansion Thread-Index: Achyv++ngIUpnMaRQ5+8LiUrWr01nw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1J6NXEF005346 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: While going through application scenarios for the ADO.NET Data Services Framework (Project Astoria) one of the first things we noticed is that data-centric applications usually want to bring down graphs of related resources in each interaction with the server. For example, if you are retrieving a resource that represents an "Event", you may want to also bring in the set of related Contact resources that are invited or the "Venue" resource where the event will take place. This write up briefly describes how we model associations between resources as Atom links and proposes a usage pattern of the atom:link element to support retrieving resource graphs in a single response. We're looking for feedback on the approach and also to get folks thinking about inlined content and whether it should be considered an extension to Atom. More context on Astoria support for Atom here: http://blogs.msdn.com/astoriateam/archive/2008/02/13/atompub-support-in-the-ado-net-data-services-framework.aspx 1. Links for modeling associations between resources Related resources can be seen at the instance level as "links" in Atom terms. Of course, from the data application development perspective, it's interesting to make this discoverable at the service description (schema) level. In Astoria data services the underlying model is the Entity Data Model (EDM), which describes data in terms of "Entities" (instances of Entity Types) and associations between entities. In the context of the Atom interface, Entities are mapped to entries and Associations to links. So by looking at the service description a developer can discover the links that will be present in an entry of a given type. We model related entries or feeds using a link with a "rel" attribute of "related", and with a "type" of either "application/atom+xml;type=feed" or "application/atom+xml;type=entry" depending on the cardinality of the other end of the association. One tricky aspect is that we need to indicate which association it is. At the model level we have a "navigation property" that identifies the starting "end" of the association (e.g. "Attendees", "Venue"). We currently put that name in the "title" attribute of the link. That solution is not perfect, as we try not to overload constructs that are for human-readable content. However, the alternative is to use a custom attribute, and we've been trying not to introduce custom attributes unless absolutely needed. Another option would be to use different "rel" values to specify the relationship, which feels natural but makes it much less likely that generic processors will be able to do something interesting with it. Do these trade-offs sound reasonable? Is any of the other options more appropriate? Continuing with the Events sample, this is what an entry (/Events(456)) with links looks like: http://localhost:81/EventsSample/Events(456) 2008-02-17T02:52:38Z 456 Big Party It's going to be a great party! 2008-03-05T06:00:00 From the data modification perspective, links pointing to other resources in the service can be specified in the payload of POST and PUT operations, to establish links between the resource being manipulated and other existing resources. 2. Expanding links inline As I summarized at the beginning of this note, we want to enable clients to request whole sub-graphs of data starting at some resource or set of resources. There are two aspects that need to be addressed: how does the client indicate that it wants one or more links expanded and how are the expanded links represented on the response. How link expansion is requested is outside of the atom-syntax problem space, so I'll just briefly state what we currently do in case you have an opinion: data services support the query string option "$expand" to request link expansion. So you could say "/Events?$expand=Attendees " to retrieve all Events and all contacts that are attendees for each of them, or "/Events(456)?$expand=Attendees" to retrieve a single event (with key 456) and its attendees. Expand syntax allows for deep expands such as "Attendees/BestFriend" (expand Attendees, and on the expanded entry(es) expand BestFriend) and wide expands such as "Venue, Attendees/BestFriend" meaning expand two immediate links, and for the Attendees one further expand its BestFriend link. For representing expanded links we put the expanded content inside the link element itself. According to section 4.2.7 of RFC 4287: "The "atom:link" element defines a reference from an entry or feed to a Web resource. This specification assigns no meaning to the content (if any) of this element." So it seems that adding content to the link element is not disallowed and at the same time it does not overlap with any existing semantics given to such construct. Based on that we thought it would be the perfect place for this information, as the link itself already contains the metadata about the link that we needed. When a client indicates that the target of a link should be expanded, the server responds with the Atom representation of the resources pointed at by links wrapped in an element. For example, for "/Events(456)?$expand=Attendees,Venue" the response would be: http://localhost:81/EventsSample/Events(456) 2008-02-17T03:01:18Z http://localhost:81/EventsSample/Venues(789) 2008-02-17T03:01:18Z 789 The Cool Place Great place for parties! 1500 Nightclub Attendees http://localhost:81/EventsSample/Events(456)/Attendees 2008-02-17T03:01:18Z http://localhost:81/EventsSample/Contacts(123) 2008-02-17T03:01:18Z 123 John123 Doe123 jd123@foo.com 123-456-123 1990-04-01T00:00:00 http://localhost:81/EventsSample/Contacts(124) 2008-02-17T03:01:18Z 124 John124 Doe124 jd124@foo.com 123-456-124 1990-05-01T00:00:00 456 Big Party It's going to be a great party! 2008-03-05T06:00:00 I focused on the GET operations above. We think it would be better to stay away from attempting to support full modification operations on expanded graphs. In particular, we do not handle PUT on more than one entry at a time today. We do support POSTing an expanded graph, and we simply create all the nested entries and link them to the parent entry, creating the whole graph in a single operation. Feedback in general about this approach would be greatly appreciated. (also posted this in the Astoria team blog) Thanks -pablo From owner-atom-syntax@mail.imc.org Tue Feb 19 08:36:19 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E5D28C61C for ; Tue, 19 Feb 2008 08:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.034 X-Spam-Level: X-Spam-Status: No, score=-3.034 tagged_above=-999 required=5 tests=[AWL=-0.989, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, WEIRD_PORT=0.001] 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 9AzTV++iCDd6 for ; Tue, 19 Feb 2008 08:36:18 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0D9403A6821 for ; Tue, 19 Feb 2008 08:36:17 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JGNvrY073986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 09:23:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1JGNvrF073985; Tue, 19 Feb 2008 09:23:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JGNsK7073978 for ; Tue, 19 Feb 2008 09:23:56 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so457260anc.44 for ; Tue, 19 Feb 2008 08:23:53 -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:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=uxdO1v0qdtY21M5/izmXF2lwZRSD0DIoaQmAQ+Hfr7A=; b=Vo7vGpTHEiEcX6mqQ8eN48LxNyrvHdJyiC78wcYf1spuZ8DsiB6QSJn5fAZNQ1YJ5WAvegGxwdYhDRYFrJdM7avD8tEGs85AoA4OsNROUhAOBdqBsp9MQKbtf4FQGSYYq0X/9zZ6X0iPI7bHk5FIqLaVYdAi9MLwYcl/Z5pnd8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=nRiqox4Xg59HW7ZgrQ2jMlOzch9zh1YWK/91bUTwXFp5iEw4YPNMKP3lCYpDsMN4eJpuMSxqhQZfKy29bvhbruEAOzkwggXkWqzXI96wR/8xPqRwixGKl6CyMwbpoFYdZ1QREYndWyrC2zg+2jkgWCtlYB5D9WOP+GBv/J8/jWs= Received: by 10.100.107.7 with SMTP id f7mr14597585anc.35.1203438233208; Tue, 19 Feb 2008 08:23:53 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id l31sm2020389hsa.5.2008.02.19.08.23.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 Feb 2008 08:23:46 -0800 (PST) Message-ID: <47BB026F.8000109@gmail.com> Date: Tue, 19 Feb 2008 08:23:11 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Pablo Castro CC: "atom-syntax@imc.org" Subject: Re: Related entries and feeds: links and link expansion References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Pablo, Thanks for the runthrough... comments below.. Pablo Castro wrote: > [snip] > We model related entries or feeds using a link with a "rel" attribute of "related", and with > a "type" of either "application/atom+xml;type=feed" or "application/atom+xml;type=entry" > depending on the cardinality of the other end of the association. > > One tricky aspect is that we need to indicate which association it is. At the model level > we have a "navigation property" that identifies the starting "end" of the association (e.g. > "Attendees", "Venue"). We currently put that name in the "title" attribute of the link. > That solution is not perfect, as we try not to overload constructs that are for human-readable > content. However, the alternative is to use a custom attribute, and we've been trying not to > introduce custom attributes unless absolutely needed. Another option would be to use different > "rel" values to specify the relationship, which feels natural but makes it much less likely > that generic processors will be able to do something interesting with it. > Most generic processors aren't doing much with links yet anyway. Using specific rel attribute values would be better. > Do these trade-offs sound reasonable? Is any of the other options more appropriate? > > Continuing with the Events sample, this is what an entry (/Events(456)) with links looks like: > > xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" > xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" > xmlns="http://www.w3.org/2005/Atom" > m:type="EventsSample.Event"> > http://localhost:81/EventsSample/Events(456) > > 2008-02-17T02:52:38Z > > > > > > I'd much rather see this: > > 456 > Big Party > It's going to be a great party! > 2008-03-05T06:00:00 > > > FWIW, your content element is incorrect. There needs to be a top level element, e.g. ... ... ... ... > [snip] > 2. Expanding links inline > [snip] > How link expansion is requested is outside of the atom-syntax problem space, so > I'll just briefly state what we currently do in case you have an opinion: data services > support the query string option "$expand" to request link expansion. So you could say > "/Events?$expand=Attendees " to retrieve all Events and all contacts that are attendees > for each of them, or "/Events(456)?$expand=Attendees" to retrieve a single event (with > key 456) and its attendees. Expand syntax allows for deep expands such as > "Attendees/BestFriend" (expand Attendees, and on the expanded entry(es) expand BestFriend) > and wide expands such as "Venue, Attendees/BestFriend" meaning expand two immediate links, > and for the Attendees one further expand its BestFriend link. > Works for me :-) > For representing expanded links we put the expanded content inside the link element itself. > According to section 4.2.7 of RFC 4287: > > "The "atom:link" element defines a reference from an entry or feed to a Web resource. > This specification assigns no meaning to the content (if any) of this element." > > So it seems that adding content to the link element is not disallowed and at the same time > it does not overlap with any existing semantics given to such construct. Based on that we > thought it would be the perfect place for this information, as the link itself already > contains the metadata about the link that we needed. > +1. This is an excellent use of the extensibility of Atom. > When a client indicates that the target of a link should be expanded, the server responds > with the Atom representation of the resources pointed at by links wrapped in an > element. For example, for "/Events(456)?$expand=Attendees,Venue" the response would be: > > [snip] > > > > http://localhost:81/EventsSample/Venues(789) > > 2008-02-17T03:01:18Z > > > > > > > 789 > The Cool Place > Great place for parties! > 1500 > Nightclub > > > > > [snip] I like this approach very much. Existing (properly implemented) processors will be able to safely ignore the inline content without loss of function and would still have the ability to extract useful information from the document. > I focused on the GET operations above. We think it would be better to stay away from > attempting to support full modification operations on expanded graphs. In particular, > we do not handle PUT on more than one entry at a time today. We do support POSTing an > expanded graph, and we simply create all the nested entries and link them to the > parent entry, creating the whole graph in a single operation. > Sounds good. PUT would definitely be problematic. - James > Feedback in general about this approach would be greatly appreciated. > > (also posted this in the Astoria team blog) > > Thanks > -pablo > > > From owner-atom-syntax@mail.imc.org Tue Feb 19 16:01:24 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FAFA28C0FE for ; Tue, 19 Feb 2008 16:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.815 X-Spam-Level: X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[AWL=1.230, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, WEIRD_PORT=0.001] 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 W8rq6YSG2pRn for ; Tue, 19 Feb 2008 16:01:22 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id AA58328C3D1 for ; Tue, 19 Feb 2008 16:01:22 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JNn97l025137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 16:49:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1JNn9Yg025136; Tue, 19 Feb 2008 16:49:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JNn81c025127 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 19 Feb 2008 16:49:08 -0700 (MST) (envelope-from Pablo.Castro@microsoft.com) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 19 Feb 2008 15:49:07 -0800 Received: from NA-EXMSG-C107.redmond.corp.microsoft.com ([157.54.62.34]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Tue, 19 Feb 2008 15:49:07 -0800 From: Pablo Castro To: James M Snell CC: "atom-syntax@imc.org" Date: Tue, 19 Feb 2008 15:49:04 -0800 Subject: RE: Related entries and feeds: links and link expansion Thread-Topic: Related entries and feeds: links and link expansion Thread-Index: AchzE9U4owts1k72QTuAG0BIjzwSGAAO/dDg Message-ID: References: <47BB026F.8000109@gmail.com> In-Reply-To: <47BB026F.8000109@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1JNn81b025130 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello James, Thanks for the quick feedback. Good point on the rel values of links, my only concern is what will generic processors do with that, but I like that it captures the data that's for other computers in the "rel" attribute and frees up Title to be used for something readable. >> FWIW, your content element is incorrect. There needs to be a top level element, e.g. I'll claim ignorance on this. Why do we need a wrapping element? Not particularly passionate one way or the other, just curious to hear why is it required... Thanks -pablo -----Original Message----- From: James M Snell [mailto:jasnell@gmail.com] Sent: Tuesday, February 19, 2008 8:23 AM To: Pablo Castro Cc: atom-syntax@imc.org Subject: Re: Related entries and feeds: links and link expansion Hello Pablo, Thanks for the runthrough... comments below.. Pablo Castro wrote: > [snip] > We model related entries or feeds using a link with a "rel" attribute of "related", and with > a "type" of either "application/atom+xml;type=feed" or "application/atom+xml;type=entry" > depending on the cardinality of the other end of the association. > > One tricky aspect is that we need to indicate which association it is. At the model level > we have a "navigation property" that identifies the starting "end" of the association (e.g. > "Attendees", "Venue"). We currently put that name in the "title" attribute of the link. > That solution is not perfect, as we try not to overload constructs that are for human-readable > content. However, the alternative is to use a custom attribute, and we've been trying not to > introduce custom attributes unless absolutely needed. Another option would be to use different > "rel" values to specify the relationship, which feels natural but makes it much less likely > that generic processors will be able to do something interesting with it. > Most generic processors aren't doing much with links yet anyway. Using specific rel attribute values would be better. > Do these trade-offs sound reasonable? Is any of the other options more appropriate? > > Continuing with the Events sample, this is what an entry (/Events(456)) with links looks like: > > xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" > xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" > xmlns="http://www.w3.org/2005/Atom" > m:type="EventsSample.Event"> > http://localhost:81/EventsSample/Events(456) > > 2008-02-17T02:52:38Z > > > > > > I'd much rather see this: > > 456 > Big Party > It's going to be a great party! > 2008-03-05T06:00:00 > > > FWIW, your content element is incorrect. There needs to be a top level element, e.g. ... ... ... ... > [snip] > 2. Expanding links inline > [snip] > How link expansion is requested is outside of the atom-syntax problem space, so > I'll just briefly state what we currently do in case you have an opinion: data services > support the query string option "$expand" to request link expansion. So you could say > "/Events?$expand=Attendees " to retrieve all Events and all contacts that are attendees > for each of them, or "/Events(456)?$expand=Attendees" to retrieve a single event (with > key 456) and its attendees. Expand syntax allows for deep expands such as > "Attendees/BestFriend" (expand Attendees, and on the expanded entry(es) expand BestFriend) > and wide expands such as "Venue, Attendees/BestFriend" meaning expand two immediate links, > and for the Attendees one further expand its BestFriend link. > Works for me :-) > For representing expanded links we put the expanded content inside the link element itself. > According to section 4.2.7 of RFC 4287: > > "The "atom:link" element defines a reference from an entry or feed to a Web resource. > This specification assigns no meaning to the content (if any) of this element." > > So it seems that adding content to the link element is not disallowed and at the same time > it does not overlap with any existing semantics given to such construct. Based on that we > thought it would be the perfect place for this information, as the link itself already > contains the metadata about the link that we needed. > +1. This is an excellent use of the extensibility of Atom. > When a client indicates that the target of a link should be expanded, the server responds > with the Atom representation of the resources pointed at by links wrapped in an > element. For example, for "/Events(456)?$expand=Attendees,Venue" the response would be: > > [snip] > > > > http://localhost:81/EventsSample/Venues(789) > > 2008-02-17T03:01:18Z > > > > > > > 789 > The Cool Place > Great place for parties! > 1500 > Nightclub > > > > > [snip] I like this approach very much. Existing (properly implemented) processors will be able to safely ignore the inline content without loss of function and would still have the ability to extract useful information from the document. > I focused on the GET operations above. We think it would be better to stay away from > attempting to support full modification operations on expanded graphs. In particular, > we do not handle PUT on more than one entry at a time today. We do support POSTing an > expanded graph, and we simply create all the nested entries and link them to the > parent entry, creating the whole graph in a single operation. > Sounds good. PUT would definitely be problematic. - James > Feedback in general about this approach would be greatly appreciated. > > (also posted this in the Astoria team blog) > > Thanks > -pablo > > > From owner-atom-syntax@mail.imc.org Tue Feb 19 16:16:15 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7123228C0FE for ; Tue, 19 Feb 2008 16:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 GbU5fu1bT3HF for ; Tue, 19 Feb 2008 16:16:14 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 99F5728C834 for ; Tue, 19 Feb 2008 16:12:56 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1K01eFU026263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 17:01:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1K01eYt026262; Tue, 19 Feb 2008 17:01:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1K01cjt026254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Feb 2008 17:01:39 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [70.252.165.101]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 10A5723E4CA for ; Tue, 19 Feb 2008 19:01:37 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" Subject: RE: Related entries and feeds: links and link expansion Date: Tue, 19 Feb 2008 16:01:43 -0800 Message-ID: <000e01c87353$c74189a0$6401a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchzE9U4owts1k72QTuAG0BIjzwSGAAO/dDgAADGdyAAADNMgA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Pablo Castro wrote: > >> FWIW, your content element is incorrect. There needs to > be a top level element, e.g. > > I'll claim ignorance on this. Why do we need a wrapping element? Not > particularly passionate one way or the other, just curious to hear why > is it required... Use application/xml if (and only if) the content can be parsed on its own as a well-formed XML document (which can have only one top-level element). If you don't have a single top-level element, you can use application/xml-external-parsed-entity. See RFC 3023. - Brian From owner-atom-syntax@mail.imc.org Tue Feb 19 16:38:49 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53AEA3A68D1 for ; Tue, 19 Feb 2008 16:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_47=0.6] 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 D2StYCKMyc+f for ; Tue, 19 Feb 2008 16:38:48 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 83CC73A68C4 for ; Tue, 19 Feb 2008 16:38:48 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1K0RP6p029102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 17:27:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1K0RPFc029101; Tue, 19 Feb 2008 17:27:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1K0ROUe029095 for ; Tue, 19 Feb 2008 17:27:25 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so493098anc.44 for ; Tue, 19 Feb 2008 16:27:24 -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:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=ChlIF1257RycEDM+Cz1gxEM5UMG890t2HpBK1mo1juY=; b=twC7lCh99IN9KyUXMeOHxn9jW1n0UkFssOro8Ulsdh46EDv4jTFHpDD2ya/h0aHoRVHH2fxWA7u+4xzApy4S52W43IovmFCHwKdv/0r/LNGAyIVCjbqUWJzCjoNGsiRwJ2Ezwd7W032YO/2snBJhtqZrwV2O6hSL1M3F4weAnpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=EGhl/nh5zpkFhydctb7jyemzEE5EpNnN5klnOowbeKQEpB0ycvpwaopK3P5O6olJ9NU0daDBxmglSm63CVR6CuuYEdVpKKhRLlL6DfbhCsqACcX1iD4xafuh+aok/guGmAhc+kmNIz6vgNh+gvMui17QYu7HdpvfMrm0Z5PuW7Q= Received: by 10.100.120.15 with SMTP id s15mr15653808anc.17.1203467244235; Tue, 19 Feb 2008 16:27:24 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id a44sm14310862rne.12.2008.02.19.16.27.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 Feb 2008 16:27:23 -0800 (PST) Message-ID: <47BB73E5.6050608@gmail.com> Date: Tue, 19 Feb 2008 16:27:17 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Brian Smith CC: "'atom-syntax'" Subject: Re: Related entries and feeds: links and link expansion References: <000e01c87353$c74189a0$6401a8c0@T60> In-Reply-To: <000e01c87353$c74189a0$6401a8c0@T60> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Section 4.1.3.3: If the value of "type" is an XML media type [RFC3023] or ends with "+xml" or "/xml" (case insensitive), the content of atom:content MAY include child elements and SHOULD be suitable for handling as the indicated media type. If the "src" attribute is not provided, this would normally mean that the "atom:content" element would contain a single child element that would serve as the root element of the XML document of the indicated type. The key point is the "SHOULD be suitable for handling as the indicated media type". With application/xml, then, you'd need a top-level element in order to be able to handle it as an XML document. While Brian is right with, you'll likely find that clients will be able to handle the single top-level element better. - James Brian Smith wrote: > > Pablo Castro wrote: >>>> FWIW, your content element is incorrect. There needs to >> be a top level element, e.g. >> >> I'll claim ignorance on this. Why do we need a wrapping element? Not >> particularly passionate one way or the other, just curious to hear why > >> is it required... > > Use application/xml if (and only if) the content can be parsed on its > own as a well-formed XML document (which can have only one top-level > element). If you don't have a single top-level element, you can use > application/xml-external-parsed-entity. See RFC 3023. > > - Brian > > From owner-atom-syntax@mail.imc.org Tue Feb 19 21:24:01 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9172B3A6A63 for ; Tue, 19 Feb 2008 21:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, WEIRD_PORT=0.001] 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 14IDTYf3zYVE for ; Tue, 19 Feb 2008 21:24:00 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2D2293A6909 for ; Tue, 19 Feb 2008 21:24:00 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1K5Av5u052562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 22:10:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1K5AvMa052561; Tue, 19 Feb 2008 22:10:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1K5AtlX052553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Feb 2008 22:10:56 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [70.252.165.101]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 2DBDA23E49E for ; Wed, 20 Feb 2008 00:10:52 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: Subject: RE: Related entries and feeds: links and link expansion Date: Tue, 19 Feb 2008 21:10:54 -0800 Message-ID: <000001c8737e$fb0261d0$6401a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Achyv++ngIUpnMaRQ5+8LiUrWr01nwAt+3kg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Pablo Castro wrote: > One tricky aspect is that we need to indicate which > association it is. At the model level we have a "navigation > property" that identifies the starting "end" of the > association (e.g. "Attendees", "Venue"). We currently put > that name in the "title" attribute of the link. That solution > is not perfect, as we try not to overload constructs that are > for human-readable content. However, the alternative is to > use a custom attribute, and we've been trying not to > introduce custom attributes unless absolutely needed. Another > option would be to use different "rel" values to specify the > relationship, which feels natural but makes it much less > likely that generic processors will be able to do something > interesting with it. There is no point in including a link to something totally unrelated to the entry, so it is safe to assume that *any* link references related content. rel="related" provides no useful information except to say that the link is not an alternate link (rel="alternate" is the default). Generic processors are unlikely to do anything with rel="related" that they wouldn't do for some unknown link relation. Instead of *custom* relations, we should develop common vocabularies for different domains. But, that goes against the idea of allowing users to shoehorn their existing ERD models into Atom documents, because it requires them to design with Atom in mind beforehand. > > http://localhost:81/EventsSample/Events(456) > > > > > > type="application/atom+xml;type=entry" > title="Venue" > href="Events(456)/Venue" /> > type="application/atom+xml;type=feed" > title="Attendees" href="Events(456)/Attendees" /> > > 456 > Big Party > It's going to be a great party! > 2008-03-05T06:00:00 > > In this example, most of the elements of the Atom syntax (id, title, author, link/@rel, link/@title, summary) are either unused or misused. If the goal is to interoperate with other Atom implementations, I would expect the entry to look something like this: http://organization.org/events/Events(456) Big Party A useful name It's going to be a great party! 2008-03-05T06:00:00Z If you cannot nicely map the user's domain model into Atom's general purpose data model then that is a really good indication that Atom shouldn't be used. Otherwise, you aren't going to be able to interoperate usefully with anybody except other Astoria users. > 2. Expanding links inline > > As I summarized at the beginning of this note, we want to > enable clients to request whole sub-graphs of data starting > at some resource or set of resources. There are two aspects > that need to be addressed: how does the client indicate that > it wants one or more links expanded and how are the expanded > links represented on the response. > For representing expanded links we put the expanded content > inside the link element itself. According to section 4.2.7 of > RFC 4287: > > "The "atom:link" element defines a reference from an entry or > feed to a Web resource. This specification assigns no > meaning to the content (if any) of this element." > > So it seems that adding content to the link element is not > disallowed and at the same time it does not overlap with any > existing semantics given to such construct. Based on that we > thought it would be the perfect place for this information, > as the link itself already contains the metadata about the > link that we needed. How do you deal with other extensions that also embed information within the content of atom:link elements? How can you distinguish these other extensions from the expanded data? > I focused on the GET operations above. We think it would be > better to stay away from attempting to support full > modification operations on expanded graphs. In particular, we > do not handle PUT on more than one entry at a time today. We > do support POSTing an expanded graph, and we simply create > all the nested entries and link them to the parent entry, > creating the whole graph in a single operation. > > Feedback in general about this approach would be greatly appreciated. Instead of expanding the links within an entry, why not return a feed, where each entry represents one entity in the result set, and make use of link/@rel='alternate' or link/@rel='self'. For example: ... ... ... ... ... ... ... The consumer of the feed can see that the second and third entries are copies of the resources that are being linked to, which avoids the need to hit the server to retrieve them. This is leveraging the pre-defined Atom semantics instead of creating a new mechanism. In other words, treat "$expand" as a request to include supplementary entries in the feed. You might need a way of distinguishing the primary and supplementary entries, but that shouldn't be too hard to come up with. Notice that this scheme also seems to be easy to extend to support batch updates of multiple parts of the subgraph using whatever general batch update mechanisms become popular. - Brian From owner-atom-syntax@mail.imc.org Tue Feb 19 21:27:40 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE9EA3A6A63 for ; Tue, 19 Feb 2008 21:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.727 X-Spam-Level: X-Spam-Status: No, score=0.727 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 yKqjEKKPreDx for ; Tue, 19 Feb 2008 21:27:40 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 004413A688F for ; Tue, 19 Feb 2008 21:27:39 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1K5JXVw053116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 22:19:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1K5JXGu053114; Tue, 19 Feb 2008 22:19:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1K5JWu5053108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Feb 2008 22:19:32 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [70.252.165.101]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 8C93B23E4AB for ; Wed, 20 Feb 2008 00:19:30 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <000001c8737e$fb0261d0$6401a8c0@T60> Subject: RE: Related entries and feeds: links and link expansion Date: Tue, 19 Feb 2008 21:19:36 -0800 Message-ID: <000101c87380$2ffe9240$6401a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000001c8737e$fb0261d0$6401a8c0@T60> Thread-Index: Achyv++ngIUpnMaRQ5+8LiUrWr01nwAt+3kgAAH3bLA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brian Smith wrote: > In this example, most of the elements of the Atom syntax (id, > title, author, link/@rel, link/@title, summary) are either > unused or misused. If the goal is to interoperate with other Atom > implementations, I would expect the entry to look something like this: > > Actually, I would go farther and say that an Atom feed for events should look something like CalAtom (http://robubu.com/CalAtom/CalAtom.html), which embeds iCalendar into Atom. If custom markup is used for everything, there is no way that users would be able to transfer these events between an Atom-enabled calendaring application and the custom application. - Brian From owner-atom-syntax@mail.imc.org Tue Feb 19 23:41:22 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481A928C421 for ; Tue, 19 Feb 2008 23:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, WEIRD_PORT=0.001] 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 HG5-+lIDv-rB for ; Tue, 19 Feb 2008 23:41:20 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D14C928C396 for ; Tue, 19 Feb 2008 23:41:20 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1K7UM8F063742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 00:30:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1K7UMrA063741; Wed, 20 Feb 2008 00:30:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1K7ULVq063735 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 20 Feb 2008 00:30:22 -0700 (MST) (envelope-from Pablo.Castro@microsoft.com) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 19 Feb 2008 23:30:21 -0800 Received: from NA-EXMSG-C107.redmond.corp.microsoft.com ([157.54.62.34]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Tue, 19 Feb 2008 23:30:20 -0800 From: Pablo Castro To: Brian Smith , "'atom-syntax'" Date: Tue, 19 Feb 2008 23:30:17 -0800 Subject: RE: Related entries and feeds: links and link expansion Thread-Topic: Related entries and feeds: links and link expansion Thread-Index: Achyv++ngIUpnMaRQ5+8LiUrWr01nwAt+3kgAAYx/UA= Message-ID: References: <000001c8737e$fb0261d0$6401a8c0@T60> In-Reply-To: <000001c8737e$fb0261d0$6401a8c0@T60> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1K7UMVp063736 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Brian, Thank you for your feedback. Relations: the more we talk about this the more I agree that rel='related' doesn't really mean much. It seems that putting the name of the association in a form that fits the rel attribute is the most natural to do here. The one thing that would be interesting is to allow processors that know about this kind of links but don't know about a particular schema to identify them. May be a common prefix in the URI that acts as the value of 'rel' is what solves that. Once we have something like that in place, if we allow developers to customize the names of the links (rels), they can align them with common vocabularies if they exist for a given domain. Unused elements: I understand the concern about the unused Atom elements. We are thinking of adding more support to map elements of your data model that are a good match for Atom constructs to minimize that effect. That said, it would be good to explore is whether it is interesting to push Atom to somewhat new spaces where it makes a great format because of the fact that is broadly known, even thought for a particular case no all the elements of the Atom format are relevant (this is clearly not new, there are many folks that already explored this space). Feeds instead of nesting: note that the element that contains the expanded data inside the link is in the Astoria namespace, so multiple implementations can clearly tell apart content that's part of their format and content that is not. One unfortunate effect of having $expand result a feed is that it changes the nature of the entity that is sent back to the client. If you say /People('abc') you get an entry, wouldn't be at least weird that if you add $expand as in /People('abc')?$expand=Addresses then the response is now a feed? Thanks -pablo -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Brian Smith Sent: Tuesday, February 19, 2008 9:11 PM To: 'atom-syntax' Subject: RE: Related entries and feeds: links and link expansion Pablo Castro wrote: > One tricky aspect is that we need to indicate which > association it is. At the model level we have a "navigation > property" that identifies the starting "end" of the > association (e.g. "Attendees", "Venue"). We currently put > that name in the "title" attribute of the link. That solution > is not perfect, as we try not to overload constructs that are > for human-readable content. However, the alternative is to > use a custom attribute, and we've been trying not to > introduce custom attributes unless absolutely needed. Another > option would be to use different "rel" values to specify the > relationship, which feels natural but makes it much less > likely that generic processors will be able to do something > interesting with it. There is no point in including a link to something totally unrelated to the entry, so it is safe to assume that *any* link references related content. rel="related" provides no useful information except to say that the link is not an alternate link (rel="alternate" is the default). Generic processors are unlikely to do anything with rel="related" that they wouldn't do for some unknown link relation. Instead of *custom* relations, we should develop common vocabularies for different domains. But, that goes against the idea of allowing users to shoehorn their existing ERD models into Atom documents, because it requires them to design with Atom in mind beforehand. > > http://localhost:81/EventsSample/Events(456) > > > > > > type="application/atom+xml;type=entry" > title="Venue" > href="Events(456)/Venue" /> > type="application/atom+xml;type=feed" > title="Attendees" href="Events(456)/Attendees" /> > > 456 > Big Party > It's going to be a great party! > 2008-03-05T06:00:00 > > In this example, most of the elements of the Atom syntax (id, title, author, link/@rel, link/@title, summary) are either unused or misused. If the goal is to interoperate with other Atom implementations, I would expect the entry to look something like this: http://organization.org/events/Events(456) Big Party A useful name It's going to be a great party! 2008-03-05T06:00:00Z If you cannot nicely map the user's domain model into Atom's general purpose data model then that is a really good indication that Atom shouldn't be used. Otherwise, you aren't going to be able to interoperate usefully with anybody except other Astoria users. > 2. Expanding links inline > > As I summarized at the beginning of this note, we want to > enable clients to request whole sub-graphs of data starting > at some resource or set of resources. There are two aspects > that need to be addressed: how does the client indicate that > it wants one or more links expanded and how are the expanded > links represented on the response. > For representing expanded links we put the expanded content > inside the link element itself. According to section 4.2.7 of > RFC 4287: > > "The "atom:link" element defines a reference from an entry or > feed to a Web resource. This specification assigns no > meaning to the content (if any) of this element." > > So it seems that adding content to the link element is not > disallowed and at the same time it does not overlap with any > existing semantics given to such construct. Based on that we > thought it would be the perfect place for this information, > as the link itself already contains the metadata about the > link that we needed. How do you deal with other extensions that also embed information within the content of atom:link elements? How can you distinguish these other extensions from the expanded data? > I focused on the GET operations above. We think it would be > better to stay away from attempting to support full > modification operations on expanded graphs. In particular, we > do not handle PUT on more than one entry at a time today. We > do support POSTing an expanded graph, and we simply create > all the nested entries and link them to the parent entry, > creating the whole graph in a single operation. > > Feedback in general about this approach would be greatly appreciated. Instead of expanding the links within an entry, why not return a feed, where each entry represents one entity in the result set, and make use of link/@rel='alternate' or link/@rel='self'. For example: ... ... ... ... ... ... ... The consumer of the feed can see that the second and third entries are copies of the resources that are being linked to, which avoids the need to hit the server to retrieve them. This is leveraging the pre-defined Atom semantics instead of creating a new mechanism. In other words, treat "$expand" as a request to include supplementary entries in the feed. You might need a way of distinguishing the primary and supplementary entries, but that shouldn't be too hard to come up with. Notice that this scheme also seems to be easy to extend to support batch updates of multiple parts of the subgraph using whatever general batch update mechanisms become popular. - Brian From owner-atom-syntax@mail.imc.org Wed Feb 20 05:00:58 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E06133A6E47 for ; Wed, 20 Feb 2008 05:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=-3.411, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 zEDhwe3pPl7q for ; Wed, 20 Feb 2008 05:00:58 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 379133A6E42 for ; Wed, 20 Feb 2008 05:00:58 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KCnilY095837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 05:49:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1KCniYb095836; Wed, 20 Feb 2008 05:49:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m1KCng9M095829 for ; Wed, 20 Feb 2008 05:49:43 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 20 Feb 2008 12:49:42 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp030) with SMTP; 20 Feb 2008 13:49:42 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1872S81fQc7FeRDZReBOQ3k+ulel4NIgv5Z2S5ibk +qx9jqS1NJin/l Message-ID: <47BC21DC.904@gmx.de> Date: Wed, 20 Feb 2008 13:49:32 +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: atom-syntax@imc.org Subject: Re: Google Reader and Namespace Prefixes References: <20080206110614.GA5643@nic.fr> <20080206150247.GB32206@nic.fr> <51D1F12C-58B9-4C14-A066-D7E4627C0207@w3.org> <47AB177C.3000408@gmx.de> In-Reply-To: <47AB177C.3000408@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Julian Reschke wrote: > > Karl Dubost wrote: >> >> >> Le 7 fvr. 2008 00:02, Stphane Bortzmeyer a crit : >>> This page reminds there is a problem but Google is not mentioned. >> >> >> "More of an issue was the xhtml prefix, >> which caused problems for nearly two thirds >> of the aggregators tested. 3" >> >> following the "3" >> >> "3 Including Google Reader, NewsGator Online, >> FeedDemon, Thunderbird 1.5.0.13, and RSS >> Bandit 1.5.0.17." > > > So do we know whether Google is aware of this problem? > > Hmm. Joe, maybe you? For the record: I reported the issue over at ten days ago, and got no replies. BR, Julian From owner-atom-syntax@mail.imc.org Wed Feb 20 05:24:48 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DFAD28C12C for ; Wed, 20 Feb 2008 05:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6] 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 ymcvAPgRZ8Ae for ; Wed, 20 Feb 2008 05:24:44 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E439828C780 for ; Wed, 20 Feb 2008 05:24:43 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KDEo28098881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 06:14:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1KDEoHc098880; Wed, 20 Feb 2008 06:14:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KDEn1m098874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Feb 2008 06:14:50 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [70.252.165.101]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id F378123E497 for ; Wed, 20 Feb 2008 08:14:48 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <000001c8737e$fb0261d0$6401a8c0@T60> Subject: RE: Related entries and feeds: links and link expansion Date: Wed, 20 Feb 2008 05:14:50 -0800 Message-ID: <000001c873c2$95c6e9f0$6401a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Achyv++ngIUpnMaRQ5+8LiUrWr01nwAt+3kgAAYx/UAACo02gA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Pablo Castro wrote: > Once we have something like that in place, if we allow > developers to customize the names of the links (rels), they > can align them with common vocabularies if they exist for a > given domain. > Unused elements: I understand the concern about the unused > Atom elements. We are thinking of adding more support to map > elements of your data model that are a good match for Atom > constructs to minimize that effect. That said, it would be > good to explore is whether it is interesting to push Atom to > somewhat new spaces where it makes a great format because of > the fact that is broadly known, even thought for a particular > case no all the elements of the Atom format are relevant > (this is clearly not new, there are many folks that already > explored this space). If you can easily allow your users to map their custom schemas into (pseudo-)standard formats based on Atom, such that the resulting documents can be usefully processed by tools that don't know anything about the database schemas (e.g. importing the events into Outlook), then that is a useful application of Atom. But, I don't see any technical advantage of using Atom if you aren't using its core features. What is the advantage of using Atom over plain-old-XML or SOAP? In particular, what is the advantage of replacing , , and with , , and ? If you need to represent multiple entities in a single document, why not use ? > One unfortunate effect of having $expand result a feed is > that it changes the nature of the entity that is sent back to > the client. If you say /People('abc') you get an entry, > wouldn't be at least weird that if you add $expand as in > /People('abc')?$expand=Addresses then the response is now a feed? It wouldn't be more weird than having entries and feeds nested within atom:link elements. Besides, I don't know how I can tell that "/People('abc')" is going to return one entry or multiple entries just by looking at it. Plus, RESTful software will not attempt to extract information out of the IRIs; instead, it will base its expectation on the format of the result based on the context in which it saw the hyperlink. - Brian From owner-atom-syntax@mail.imc.org Wed Feb 20 21:36:05 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F59B3A6B54 for ; Wed, 20 Feb 2008 21:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.216 X-Spam-Level: X-Spam-Status: No, score=-100.216 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, 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 RGMNC6GFH02M for ; Wed, 20 Feb 2008 21:36:04 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 4C3733A6B07 for ; Wed, 20 Feb 2008 21:36:04 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1L5MSMu090613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 22:22:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1L5MSHI090612; Wed, 20 Feb 2008 22:22:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1L5MRx3090605 for ; Wed, 20 Feb 2008 22:22:27 -0700 (MST) (envelope-from john@johnpanzer.com) Received: by wa-out-1112.google.com with SMTP id l24so4974265waf.22 for ; Wed, 20 Feb 2008 21:22:26 -0800 (PST) Received: by 10.114.202.15 with SMTP id z15mr5652298waf.72.1203571346581; Wed, 20 Feb 2008 21:22:26 -0800 (PST) Received: from ?192.168.1.4? ( [70.231.253.105]) by mx.google.com with ESMTPS id j39sm10981527waf.32.2008.02.20.21.22.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Feb 2008 21:22:25 -0800 (PST) References: <20080206110614.GA5643@nic.fr> <20080206150247.GB32206@nic.fr> <51D1F12C-58B9-4C14-A066-D7E4627C0207@w3.org> <47AB177C.3000408@gmx.de> <47BC21DC.904@gmx.de> Message-Id: <4BD248D0-6070-4B6C-9449-A93EFF3ABED4@acm.org> From: John To: Julian Reschke In-Reply-To: <47BC21DC.904@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes X-Mailer: iPhone Mail (4A93) Mime-Version: 1.0 (iPhone Mail 4A93) Subject: Re: Google Reader and Namespace Prefixes Date: Wed, 20 Feb 2008 21:22:19 -0800 Cc: Atom-Syntax Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1L5MSx3090606 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -John On Feb 20, 2008, at 4:49 AM, Julian Reschke wrote: > > Julian Reschke wrote: >> Karl Dubost wrote: >>> >>> >>> Le 7 févr. 2008 à 00:02, Stéphane Bortzmeyer a écrit : >>>> This page reminds there is a problem but Google is not mentioned. >>> >>> >>> "More of an issue was the xhtml prefix, >>> which caused problems for nearly two thirds >>> of the aggregators tested. 3" >>> >>> following the "3" >>> >>> "3 Including Google Reader, NewsGator Online, >>> FeedDemon, Thunderbird 1.5.0.13, and RSS >>> Bandit 1.5.0.17." >> So do we know whether Google is aware of this problem? >> Hmm. Joe, maybe you? > > For the record: I reported the issue over at > ten days ago, and got no replies. There's a reply now. > > > BR, Julian > From owner-atom-syntax@mail.imc.org Fri Feb 22 04:35:30 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA9128C340 for ; Fri, 22 Feb 2008 04:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.002 X-Spam-Level: X-Spam-Status: No, score=-4.002 tagged_above=-999 required=5 tests=[AWL=-1.956, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 YuWn2JWFfTC9 for ; Fri, 22 Feb 2008 04:35:28 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 19E183A6B23 for ; Fri, 22 Feb 2008 04:35:28 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1MCMcEo076394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 05:22:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1MCMcHj076393; Fri, 22 Feb 2008 05:22:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m1MCMagR076384 for ; Fri, 22 Feb 2008 05:22:37 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 22 Feb 2008 12:22:35 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp016) with SMTP; 22 Feb 2008 13:22:35 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+ttnZMJvSt/vLC25RpgX9hkShotDqjsighWdK2TO y6aKHskJSdxsSL Message-ID: <47BEBE7F.3050505@gmx.de> Date: Fri, 22 Feb 2008 13:22:23 +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: John CC: Atom-Syntax Subject: Re: Google Reader and Namespace Prefixes References: <20080206110614.GA5643@nic.fr> <20080206150247.GB32206@nic.fr> <51D1F12C-58B9-4C14-A066-D7E4627C0207@w3.org> <47AB177C.3000408@gmx.de> <47BC21DC.904@gmx.de> <4BD248D0-6070-4B6C-9449-A93EFF3ABED4@acm.org> In-Reply-To: <4BD248D0-6070-4B6C-9449-A93EFF3ABED4@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John wrote: > ... >> For the record: I reported the issue over at >> >> ten days ago, and got no replies. > There's a reply now. > ... And, as of yesterday, they say it's understood and a fix is being worked on. Maybe it's a bit premature to say this, but anyway...: do not accept namespace-broken software as a given, try to get fixes in. BR, Julian