Daily Advisor Newsletter

Nikunj http://o-micron.blogspot.com Begin forwarded = message: From: IETF I-D Submission Tool <idsubmission@ietf.org>Date: = June 5, 2009 10:06:45 AM PDT To: nikunj.mehta@oracle.com= Cc: colm.divilly@oracle.com= Subject: New Version Notification for = draft-divilly-atom-hierarchy-01 A new = version of I-D, draft-divilly-atom-hierarchy-01.txt has been successfuly = submitted by Nikunj Mehta and posted to the IETF = repository. Filename: = draft-divilly-atom-hierarchy Revision: 01 Title: Inlining = and Hierarchy Extensions for Atom Creation_date: = 2009-06-05 WG ID: Independent = Submission Number_of_pages: 11 Abstract: This specification = defines mechanisms for in-lining representations of linked resources = and for hierarchical navigation among Atom feeds and = entries.Editorial Note To provide feedback on this = Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1]. The IETF = Secretariat. = --Apple-Mail-11--370655255-- From owner-atom-syntax@mail.imc.org Fri Jun 5 11:14:01 2009 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 BD1283A6C96 for ; Fri, 5 Jun 2009 11:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3Lvz08OqOl1 for ; Fri, 5 Jun 2009 11:14:00 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7C4C23A6A00 for ; Fri, 5 Jun 2009 11:14:00 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n55I2hUk045584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 11:02:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n55I2hX6045583; Fri, 5 Jun 2009 11:02:43 -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 rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n55I2WJ6045576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 5 Jun 2009 11:02:42 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n55I28HM032324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Jun 2009 18:02:10 GMT Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n55I3HTu001250; Fri, 5 Jun 2009 18:03:17 GMT Received: from [10.0.1.195] (/24.130.214.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Jun 2009 11:02:14 -0700 Cc: Pablo Castro , Mark Nottingham , Julian Reschke , Atom-Syntax Syntax Message-Id: From: "Nikunj R. Mehta" To: Kyle Marvin In-Reply-To: <192fc9640906051051w6eca1e64w7d1b3e1ad12e6994@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-00 Date: Fri, 5 Jun 2009 11:00:54 -0700 References: <20090520165415.48AAE3A7130@core3.amsl.com> <4A1ABC72.7000306@gmx.de> <9A3EC7B3-B828-4247-836B-4619AD5EE5D3@oracle.com> <4A1D2E46.7060808@gmx.de> <4193B7E3-50F7-4DD6-9DBE-1A115FE66D6B@mnot.net> <86CA6008-8CCC-4DE2-A926-7F2271FCD121@oracle.com> <192fc9640906040429h6b48daf9re2a654367b23a96@mail.gmail.com> <7EEC907F-2C64-40F8-903E-F65A68214581@oracle.com> <192fc9640906051051w6eca1e64w7d1b3e1ad12e6994@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt004.oracle.com [141.146.116.13] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4A295DAB.0179:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Kyle, I am fine with splitting the I-D along those lines, although I have just published a revision that separates the two into independent sections but keeps it in one I-D. Just as an author, I am interested first in better understanding the process by which we can land RFCs for the two parts. Please advise if you can suggest how we move forward from here. For now, I hope you would be interested in reviewing the new I-D revision. I am sure there is a lot of existing implementation experience to apply and look forward to your and others' contributions. Nikunj http://o-micron.blogspot.com On Jun 5, 2009, at 10:51 AM, Kyle Marvin wrote: > It seems unwise to consider two separate I-Ds - one for specifying > new link @rel values and another to deal with in-lining. Will it buy > us anything in the IETF process? > > It would get us a clear model for doing inlining that's valid beyond > the specific use case of hierarchy which would be more useful to us > since we don't have a specific need for the hierarchy I-D; as > someone else stated earlier, we have many types of relations where > inlining would be beneficial so the specifics of the spec is too > narrow to support what we need. > > Would you be interested in seeing this get on the experimental track > so that when it is time to consider a revision of Atom the > experience accumulated by then can be used to propose something > along standards track? > > I'm not opposed but if this is considered to be prior art that will > drive how inlining should be done more generally, then I think the > net effect (read as "the hoops you will have to jump through to get > consensus") are going to be the same whether the inlining > functionality is joined or split off so why not get the general > solution's benefit for the effort. > > It could be there are aspects of this decision I'm missing. I > understand that what I'm asking for is more work for you (or > someone) and I'm sympathetic to that. From owner-atom-syntax@mail.imc.org Fri Jun 5 14:20:26 2009 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 631F03A6765 for ; Fri, 5 Jun 2009 14:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 PrPfd1xyGT4d for ; Fri, 5 Jun 2009 14:20:24 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E48F83A63CB for ; Fri, 5 Jun 2009 14:20:23 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n55L6V96054824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 14:06:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n55L6Vwo054823; Fri, 5 Jun 2009 14:06:31 -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 e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n55L6Li8054810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 5 Jun 2009 14:06:31 -0700 (MST) (envelope-from albertcbrown@us.ibm.com) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n55KxXpd029530 for ; Fri, 5 Jun 2009 14:59:33 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n55L6KSm233268 for ; Fri, 5 Jun 2009 15:06:20 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id n55L6r4s005453 for ; Fri, 5 Jun 2009 15:06:53 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av06.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id n55L6qkw005446; Fri, 5 Jun 2009 15:06:52 -0600 In-Reply-To: References: <20090605170645.A922728C10F@core3.amsl.com> Subject: Re: Fwd: New Version Notification for draft-divilly-atom-hierarchy-01 X-KeepSent: D77552CC:EF05D1F7-882575CC:006E3712; type=4; name=$KeepSent To: "Nikunj R. Mehta" Cc: Atom-Syntax Syntax , owner-atom-syntax@mail.imc.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: Al Brown Date: Fri, 5 Jun 2009 14:06:06 -0700 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Build V851_04282009|April 28, 2009) at 06/05/2009 15:06:19 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBFF5FDFFDB1828f9e8a93df938690918c07BBFF5FDFFDB182" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0__=07BBFF5FDFFDB1828f9e8a93df938690918c07BBFF5FDFFDB182 Content-type: multipart/alternative; Boundary="1__=07BBFF5FDFFDB1828f9e8a93df938690918c07BBFF5FDFFDB182" --1__=07BBFF5FDFFDB1828f9e8a93df938690918c07BBFF5FDFFDB182 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable The 01 draft is a much better. I am concerned the generic mechanism us= ing inlining links is sub-optimal for displaying a hierarchy that this I-D helps navigate via the new link relations. First example: there are two down relations: down and down-tree. It is= important to have both of those link relations on the [standalone] atom= entry that represents a folder so the client can chose a flat (feed) or= tree (expanded feed) representation. If the client chooses the tree representation, then on the atom feed returned the server will inline u= sing the link relation down. down-tree is not expanded with content inline. E.g., ... ... ... ... ... ... ... ... The contents of the down link relation will be what should be included = in the down-tree due to recursion through the atom entries. Having a separ= ate extension element, side-steps this issue of expression. Second example: verbosity This proposal now has: ... ... ... ... ... ... instead of a simpler mechanism: ... ... ... ... ... The I-D introduces a concept of hierarchy through up/up-tree/down-tree/= down relations yet a all-purpose mechanism for inclusion. Most (all?) of th= e information on the feed element is duplicated on the enclosing entry (i= d, uri, etc). Can't we do better for this specific scenario the I-D is addressing? Also, Are there reasons for the statements below? A resource may be involved= in many different independent hierarchies - e.g., folder structure, file p= lan, etc. Most of which we probably cannot imagine right now, but may be us= ed in a year or two. This also conflicts with the current 'up' relation which, as not stated otherwise, allows multiple 'up' link relations in = a single entry or feed. Section 4.1:[1] >An entry MUST NOT contain more than one atom:link element with a rel attribute value of "down" that has the same combination of type and >hreflang attribute values. Section 4.2: >An entry MUST NOT contain more than one atom:link element with a rel attribute value of "down-tree" that has the same combination of type an= d >hreflang attribute values. Section 5.1: >A feed MUST NOT contain more than one atom:link element with a rel attribute value of "up" that has the same combination of type and hrefl= ang >attribute values. Section 5.2: >An entry MUST NOT contain more than one atom:link element with a rel attribute value of "up-tree" that has the same combination of type and >hreflang attribute values. -Al [1] http://www.oracle.com/technology/tech/feeds/spec/draft-divilly-atom-hie= rarchy.html Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of th= e person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please noti= fy the sender. Please also permanently delete all copies of the original message and any attached documentation. = From: "Nikunj R. Mehta" = = To: Atom-Syntax Syntax = = Date: 06/05/2009 11:18 AM = = Subject: Fwd: New Version Notification for draft-divilly-atom-hier= archy-01 = All the feedback on this mailing list has been really useful. We have revised the I-D to reflect the thinking about in-lining inside atom:lin= k using foreign markup. We've also made the use of in-line representation= s independent of the the new link relations. Looking forward to comments = and implementation experience. 01 - Changes include: In-line representations of linked resources are independent= of hierarchy Removed Atom specific language in link relation definitions= Made explicit that this specification re-uses existing 'up'= link relation Changed namespace prefix from ah to ae Removed the ah:count attribute and added the ae:inline elem= ent Text: http://www.ietf.org/internet-drafts/draft-divilly-atom-hierarchy-= 01.txt HTML: http://www.oracle.com/technology/tech/feeds/spec/draft-divilly-at= om-hierarchy.html Nikunj http://o-micron.blogspot.com Begin forwarded message: From: IETF I-D Submission Tool Date: June 5, 2009 10:06:45 AM PDT To: nikunj.mehta@oracle.com Cc: colm.divilly@oracle.com Subject: New Version Notification for draft-divilly-atom-hierarch= y-01 A new version of I-D, draft-divilly-atom-hierarchy-01.txt has bee= n successfuly submitted by Nikunj Mehta and posted to the IETF repository. Filename: draft-divilly-atom-hierarchy Revision: 01 Title: Inlining and Hierarchy Extensions for Atom Creation_date: 2009-06-05 WG ID: Independent Submission Number_of_pages: 11 Abstract: This specification defines mechanisms for in-lining representatio= ns of linked resources and for hierarchical navigation among Atom fe= eds and entries.Editorial Note To provide feedback on this Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1]. The IETF Secretariat. = --1__=07BBFF5FDFFDB1828f9e8a93df938690918c07BBFF5FDFFDB182 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable The 01 draft is a much better. I am concerned the = generic mechanism using inlining links is sub-optimal for displaying a = hierarchy that this I-D helps navigate via the new link relations. First example: there are two down relations: down and = down-tree. It is important to have both of those link relations on the= [standalone] atom entry that represents a folder so the client can cho= se a flat (feed) or tree (expanded feed) representation. If the client= chooses the tree representation, then on the atom feed returned the se= rver will inline using the link relation down. down-tree is not expande= d with content inline. E.g., <atom:entry> ...  = <atom:link rel=3D"down" type=3D= "application/atom+xml;type=3Dfeed" href=3D"/finance/feeds/default/portfolios/1/positions">= ; <ae:inline> <atom:feed>  <atom:entry> ...  <atom:link rel=3D"down" href=3D"/finance/feeds/default/portfolios/1/positions&quo= t;/> ... <ae:inline> <atom:feed>  <atom:entry> ... <atom:link rel=3D"down&qu= ot; href=3D"/finance/feeds/default/portfolios/1/positions/= down">  </atom:link> <atom:link rel=3D"down-tr= ee" href=3D"/finance/feeds-tree/default/portfolios/1/posit= ions/down" /> ... </atom:entry> </atom:feed> </ae:inline> <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> </atom:feed> </ae:inline> </atom:link> <atom:link rel=3D"down-tree" = type=3D"application/atom+xml;type=3Dfeed" href=3D"/finance/feeds-tree/default/portfolios/1/positions&quo= t; /> ... </atom:entry> The contents of the down link relation will be what sh= ould be included in the down-tree due to recursion through the atom ent= ries. Having a separate extension element, side-steps this issue of exp= ression. Second example: verbosity This proposal now has: <atom:entry> ... <atom:link rel=3D"down" type=3D= "application/atom+xml;type=3Dfeed" href=3D"/finance/feeds/default/portfolios/1/positions">= ; <ae:inline> <atom:feed> <atom:link rel=3D"self" href=3D"/finance/feeds/default/portfolios/1/positions&quo= t;/> ... <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> </atom:feed> </ae:inline> </atom:link> ... </atom:entry> instead of a simpler mechanism: <atom:entry> ... <ah:include rel=3D"down"><= br> <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> </ah:include> ... </atom:entry> The I-D introduces a concept of hierarchy th= rough up/up-tree/down-tree/down relations yet a all-purpose mechanism f= or inclusion. Most (all?) of the information on the feed element is du= plicated on the enclosing entry (id, uri, etc). Can't we do better for= this specific scenario the I-D is addressing? Also, Are there reasons for the statements below? = A resource may be involved in many different independent hierarchies -= e.g., folder structure, file plan, etc. Most of which we probably can= not imagine right now, but may be used in a year or two. This also con= flicts with the current 'up' relation which, as not stated otherwise, a= llows multiple 'up' link relations in a single entry or feed. Section 4.1:[1] >An entry MUST NOT contain more than one atom= :link element with a rel attribute value of "down" that has t= he same combination of type and >hreflang attribute values. Section 4.2: >An entry MUST NOT contain more than one atom= :link element with a rel attribute value of "down-tree" that = has the same combination of type and >hreflang attribute values. Section 5.1: >A feed MUST NOT contain more than one atom:l= ink element with a rel attribute value of "up" that has the s= ame combination of type and hreflang >attribute values. Section 5.2: >An entry MUST NOT contain more than one atom= :link element with a rel attribute value of "up-tree" that ha= s the same combination of type and >hreflang attribute values. -Al [1] http:= //www.oracle.com/technology/tech/feeds/spec/draft-divilly-atom-hierarch= y.html Al Brown Emerging Standards and Industry Frameworks CMIS: ht= tps://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. "Niku= nj R. Mehta" ---06/05/2009 11:18:07 AM---All the feedback on this = mailing list has been really useful. We have revised the I-D to reflect= the thinking about in-lining i = From: = "Nikunj R. Mehta" <nikunj.mehta@oracle.co= m> To: Atom-Syntax Syntax <atom-syntax@imc.org><= /td> Date: = 06/05/2009 11:18 AM Subject: Fwd: New Version Notification for draft-divilly-atom-h= ierarchy-01 All the feedback on this mailing list has been really = useful. We have revised the I-D to reflect the thinking about in-lining= inside atom:link using foreign markup. We've also made the use of in-l= ine representations independent of the the new link relations. Looking = forward to comments and implementation experience. 01 - Changes include: In-line representations of linked resources = are independent of hierarchy Removed Atom specific language in link relation = definitions Made explicit that this specification re-uses ex= isting 'up' link relation Changed namespace prefix from ah to ae Removed the ah:count attribute and added the ae:= inline element Text: http://www.ietf.org/internet-drafts/draft-divilly= -atom-hierarchy-01.txt HTML: http://www.oracle.com/technology/tech/= feeds/spec/draft-divilly-atom-hierarchy.html Nikunj http://o-micron.blogspot.com Begin forwarded message: From: IETF I-D Subm= ission Tool <idsubmission@ietf.org> Date: June 5, 2009 10:0= 6:45 AM PDT To: nikunj.mehta@oracle.com Cc: colm.divilly@oracle.com Subject: New Version Notification for draft-divilly= -atom-hierarchy-01 A new version of I-D, draft-divilly-atom-hierarchy-01.txt has been succ= essfuly submitted by Nikunj Mehta and posted to the IETF repository. Filename: draft-divilly-atom-hierarchy Revision: 01 Title: Inlining and Hierarchy Extensions for Atom Creation_date: 2009-06-05 WG ID: Independent Submission Number_of_pages: 11 Abstract: This specification defines mechanisms for in-lining representations = of linked resources and for hierarchical navigation among Atom feeds and entries.Editorial Note To provide feedback on this Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/<= /u>) [1]. The IETF Secretariat. = --1__=07BBFF5FDFFDB1828f9e8a93df938690918c07BBFF5FDFFDB182-- --0__=07BBFF5FDFFDB1828f9e8a93df938690918c07BBFF5FDFFDB182 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBFF5FDFFDB1828f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBFF5FDFFDB1828f9e8a93df938690918c07BBFF5FDFFDB182 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=07BBFF5FDFFDB1828f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBFF5FDFFDB1828f9e8a93df938690918c07BBFF5FDFFDB182-- From owner-atom-syntax@mail.imc.org Fri Jun 5 20:00:47 2009 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 D52B73A6AAC for ; Fri, 5 Jun 2009 20:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.218 X-Spam-Level: X-Spam-Status: No, score=-5.218 tagged_above=-999 required=5 tests=[AWL=-2.819, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1] 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 BLWLY7KOrgu4 for ; Fri, 5 Jun 2009 20:00:46 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 333063A6802 for ; Fri, 5 Jun 2009 20:00:45 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n562m4dV067378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 19:48:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n562m4vO067377; Fri, 5 Jun 2009 19:48: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 mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n562lqGG067368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Jun 2009 19:48:03 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6753723E3E8; Fri, 5 Jun 2009 22:47:48 -0400 (EDT) Cc: Peter Keane , "Nikunj R. Mehta" , Julian Reschke , Atom-Syntax Syntax Message-Id: <415A555A-1EC2-45E7-903B-501628193BA1@mnot.net> From: Mark Nottingham To: Kyle Marvin In-Reply-To: <192fc9640906051032ve21ddb0u3215f92a4b841399@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-00 Date: Sat, 6 Jun 2009 12:47:46 +1000 References: <20090520165415.48AAE3A7130@core3.amsl.com> <4193B7E3-50F7-4DD6-9DBE-1A115FE66D6B@mnot.net> <86CA6008-8CCC-4DE2-A926-7F2271FCD121@oracle.com> <3CD5B7DD-FEB6-4A6F-928D-76D982318DDC@mnot.net> <36D30DB4-58E9-41DD-A8F5-FA96A8A4E9AB@oracle.com> <7CCF9900-A47E-4C0A-8144-6B46BBCE94BD@oracle.com> <94648B62-F0F7-46D0-9496-45F43B0DE5CF@mnot.net> <8158ad750906042110g5128f354i33c339f288be6c5d@mail.gmail.com> <1EF2FFD2-8D31-42D4-B3AB-8F36EEE939F9@mnot.net> <192fc9640906051032ve21ddb0u3215f92a4b841399@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Just checking -- you do realise I'm suggesting it's worth using a new media type for the atom document that contains these extensions, not a new media type in it? Your response was worded in such a way that I'm not sure... Cheers, On 06/06/2009, at 3:32 AM, Kyle Marvin wrote: > On Fri, Jun 5, 2009 at 12:05 AM, Mark Nottingham > wrote: > > > On 05/06/2009, at 2:10 PM, Peter Keane wrote: > > I hope I'm not too far off w/ this, but it seems to me there are a > couple distinct concerns in this thread: First is a need for what is > essentially multiple atom:content elements in an entry. atom:link > seems like a logical home for that content (given that we can assign > an appropriate @rel). > > Peter, I'm not sure I see the need like this; you want more than > multiple content items. What you have here is multiple resources > (some of which might be metadata + content, i.e. an atom entry, or > might not even be Atom at all) with some type of relationship > between them *and* the desire to retrieve these multiple related > resources using a single GET. A key difference between 'content' > and a 'resource' is that the latter is independently dereferencable > whereas the same isn't necessarily true for any atom:content types > other than out-of-line-content. A link has the nice property of > having a rel that describes how it is related to what it is > contained within (i.e. why it might be referenced), a type attribute > that informs how to process it (either when referenced or > potentially inline), and a href that says where to deference it > (i.e. how to reference it independently even if it is inline). All > nice and useful properties within the composite resource that allow > it to be used in a decoupled fashion after the initial GET of the > composite resource. > > > > Well, the most straightforward way to fix that would be to fix Atom > and allow multiple atom:content elements in an entry... > > > I'd agree with Nikunj that this is not so dramatic a change that new > media types need to be considered. It feels more like a tweak to me, > and I do not see much difficulty at all in using my current tools for > parsing or producing such atom documents. > > I think this is valid but an orthogonal concern. The key point is > that you want to nest a resource that itself has a MIME type and can > be processed. Whether these are new or existing MIME types depends > on the use cases and what is the most appropriate MIME type for that > relationship. > > > Ah, maybe that's where the misunderstanding lies. It's not that you > can't parse it with an Atom library, with appropriate code to handle > the extensions; that's obviously possible. > > My concern is that a *generic* Atom processor (e.g., a feed reader) > or more importantly a generic MIME dispatcher (e.g., a browser or an > OS) wouldn't be able to do much that's useful with such a feed, > because -- as I understand the use cases -- most of the information > will be in extensions that the generic processor won't be able to > take advantage of, and because the generic MIME dispatcher won't > know to send this document to a handler that can do something with it. > > It might surprise you but I'd agree that using MIME types more would > be goodness. It's frequently the case (including in GData) that the > lines between what is metadata and what is content are being blurred > since both are found in Atom extensions. This fact does make life > harder for Atom processors, since they have to rely on sideband > signals (a 'kind' or a 'type') that inform them about what > extensions to expect and what they mean and there's not much > standardization happening in this space. > > > > This is the role media types play on the Web (and elsewhere, of > course)... > > I don't know, though, that this is a problem the Atom WG (or a > derivative effort) can solve. In most cases, those MIME types for > nested content are domain-specific representations that are best > standardized by (or at least generally agreed upon) by groups > working in that domain. I don't see a proliferation of vendor- > specific media types as being much better than the status quo other > than that they'd let you write vendor-specific MIME processors; > better structured from an Atom perspective but not really pushing > the Web forward in the right direction from a collaborative > perspective. > > Let me know if you think I'm missing something! > > -- Kyle > > > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Jun 5 22:02:05 2009 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 7B44C3A6A86 for ; Fri, 5 Jun 2009 22:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.476 X-Spam-Level: X-Spam-Status: No, score=-100.476 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=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 vKXPqsn-l-Dm for ; Fri, 5 Jun 2009 22:02:03 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8B8EA3A69F9 for ; Fri, 5 Jun 2009 22:02:02 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n564n9W1071079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 21:49:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n564n9A9071078; Fri, 5 Jun 2009 21: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-out.google.com (smtp-out.google.com [216.239.33.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n564msvj071069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Jun 2009 21:49:06 -0700 (MST) (envelope-from kmarvin@google.com) Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id n564mpub029464 for ; Sat, 6 Jun 2009 05:48:53 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1244263733; bh=FcUFulQcJHcVpamHONrUT1SbyYE=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=O 3jqQ/jqDYLsIS3CEAvzv0dzYPU+2LGAnmGi9ZGH0uAXygPiA4ZPofD5p5yFFmUTeD+B VmyONiF4MQH6fNh6CQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=m56+ynHcddVU+jVUjjTrjUJqOKjvpKQ+ldeG9SqfDlVP/nQMsBVvtBSnm91GkTSEF cII+TUNw0NnR5vpYNqRpQ== Received: from pxi7 (pxi7.prod.google.com [10.243.27.7]) by zps18.corp.google.com with ESMTP id n564moss010653 for ; Fri, 5 Jun 2009 21:48:50 -0700 Received: by pxi7 with SMTP id 7so1530060pxi.10 for ; Fri, 05 Jun 2009 21:48:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.241.15 with SMTP id o15mr1590042wfh.104.1244263729885; Fri, 05 Jun 2009 21:48:49 -0700 (PDT) In-Reply-To: <415A555A-1EC2-45E7-903B-501628193BA1@mnot.net> References: <20090520165415.48AAE3A7130@core3.amsl.com> <3CD5B7DD-FEB6-4A6F-928D-76D982318DDC@mnot.net> <36D30DB4-58E9-41DD-A8F5-FA96A8A4E9AB@oracle.com> <7CCF9900-A47E-4C0A-8144-6B46BBCE94BD@oracle.com> <94648B62-F0F7-46D0-9496-45F43B0DE5CF@mnot.net> <8158ad750906042110g5128f354i33c339f288be6c5d@mail.gmail.com> <1EF2FFD2-8D31-42D4-B3AB-8F36EEE939F9@mnot.net> <192fc9640906051032ve21ddb0u3215f92a4b841399@mail.gmail.com> <415A555A-1EC2-45E7-903B-501628193BA1@mnot.net> Date: Fri, 5 Jun 2009 23:48:49 -0500 Message-ID: <192fc9640906052148v4bb3ba29o5c8e75395618eb13@mail.gmail.com> Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-00 From: Kyle Marvin To: Mark Nottingham Cc: Peter Keane , "Nikunj R. Mehta" , Julian Reschke , Atom-Syntax Syntax Content-Type: multipart/alternative; boundary=000e0cd14690a072ef046ba6b945 X-System-Of-Record: true Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --000e0cd14690a072ef046ba6b945 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Jun 5, 2009 at 9:47 PM, Mark Nottingham wrote: > Just checking -- you do realise I'm suggesting it's worth using a new media > type for the atom document that contains these extensions, not a new media > type in it? Your response was worded in such a way that I'm not sure... Yes, I understand. I think there are issues with media type under-use at both levels (document and content). There are definitely cases where a new MIME type on the Atom document would be helpful to processors and others where more judicious usage of specialized MIME types for atom:content would be helpful. Let me see if I can give you an example and see if you agree or disagree. Take the case of a feed that describes a calendar and contains entries that describe events in the calendar. If this had a MIME type of something like "application/calendar+atom+xml", then it would might inform a client processing it that there are other possible processing options besides regular syndication, like importing to a local calendar. Such a MIME type might explain the set of metadata extensions specific to calendars that are expected (ex timezone info) and possibly even put constraints or expectations on the MIME type of atom:content found within the entries. Of course, the "application/calendar+atom+xml" is fictitious because there's no model for saying that something is an atom feed of a specific type in the same way that "application/atom+xml" says that it's an XML document with Atom syntax constraints. Rooted in this might be Nikunj's concern but there's probably more (see next paragraph). Without a model for defining Atom media subtypes, you'd have to type it as something that is going to cause a generic Atom processor to ignore it even though it could still be processed in useful (albeit less vertical way) to let me know when data/events are available or have changed via a feed reader interface. I don't know, though, that anything in the hierarchy proposal justifies a new MIME type and given that you say it might be worth *considering* I'm not sure you see it that way either. There are definitely cases where you're just adding extensions that are informative and additional metadata and I don't think these alone define a new data format that needs a media type. Media RSS is possibly another example. Consider these the Atom Syntax equivalent of a ""mixin". If such extensions are standardized and/or get enough de facto usage lots of Atom processors are likely to handle them just fine. So the current proposal is perhaps not the best poster child for using media types more but I definitely think it's something that the Atom community should consider to better enable client use cases in addition to reader-based syndication. All this being said, I think the right venue for creating more specialized Atom media types is in communities that would benefit from their existence and the collaboration or processing models that would be enabled by them. Just minting new MIME types because you've extended Atom is not all that helpful in the bigger scheme of things, imo. HTH, -- Kyle > > > Cheers, > > > > On 06/06/2009, at 3:32 AM, Kyle Marvin wrote: > > On Fri, Jun 5, 2009 at 12:05 AM, Mark Nottingham wrote: >> >> >> On 05/06/2009, at 2:10 PM, Peter Keane wrote: >> >> I hope I'm not too far off w/ this, but it seems to me there are a >> couple distinct concerns in this thread: First is a need for what is >> essentially multiple atom:content elements in an entry. atom:link >> seems like a logical home for that content (given that we can assign >> an appropriate @rel). >> >> Peter, I'm not sure I see the need like this; you want more than multiple >> content items. What you have here is multiple resources (some of which >> might be metadata + content, i.e. an atom entry, or might not even be Atom >> at all) with some type of relationship between them *and* the desire to >> retrieve these multiple related resources using a single GET. A key >> difference between 'content' and a 'resource' is that the latter is >> independently dereferencable whereas the same isn't necessarily true for any >> atom:content types other than out-of-line-content. A link has the nice >> property of having a rel that describes how it is related to what it is >> contained within (i.e. why it might be referenced), a type attribute that >> informs how to process it (either when referenced or potentially inline), >> and a href that says where to deference it (i.e. how to reference it >> independently even if it is inline). All nice and useful properties within >> the composite resource that allow it to be used in a decoupled fashion after >> the initial GET of the composite resource. >> >> >> >> Well, the most straightforward way to fix that would be to fix Atom and >> allow multiple atom:content elements in an entry... >> >> >> I'd agree with Nikunj that this is not so dramatic a change that new >> media types need to be considered. It feels more like a tweak to me, >> and I do not see much difficulty at all in using my current tools for >> parsing or producing such atom documents. >> >> I think this is valid but an orthogonal concern. The key point is that >> you want to nest a resource that itself has a MIME type and can be >> processed. Whether these are new or existing MIME types depends on the use >> cases and what is the most appropriate MIME type for that relationship. >> >> >> Ah, maybe that's where the misunderstanding lies. It's not that you can't >> parse it with an Atom library, with appropriate code to handle the >> extensions; that's obviously possible. >> >> My concern is that a *generic* Atom processor (e.g., a feed reader) or >> more importantly a generic MIME dispatcher (e.g., a browser or an OS) >> wouldn't be able to do much that's useful with such a feed, because -- as I >> understand the use cases -- most of the information will be in extensions >> that the generic processor won't be able to take advantage of, and because >> the generic MIME dispatcher won't know to send this document to a handler >> that can do something with it. >> >> It might surprise you but I'd agree that using MIME types more would be >> goodness. It's frequently the case (including in GData) that the lines >> between what is metadata and what is content are being blurred since both >> are found in Atom extensions. This fact does make life harder for Atom >> processors, since they have to rely on sideband signals (a 'kind' or a >> 'type') that inform them about what extensions to expect and what they mean >> and there's not much standardization happening in this space. >> >> >> >> This is the role media types play on the Web (and elsewhere, of course)... >> >> I don't know, though, that this is a problem the Atom WG (or a derivative >> effort) can solve. In most cases, those MIME types for nested content are >> domain-specific representations that are best standardized by (or at least >> generally agreed upon) by groups working in that domain. I don't see a >> proliferation of vendor-specific media types as being much better than the >> status quo other than that they'd let you write vendor-specific MIME >> processors; better structured from an Atom perspective but not really >> pushing the Web forward in the right direction from a collaborative >> perspective. >> >> Let me know if you think I'm missing something! >> >> -- Kyle >> >> >> >> Cheers, >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> > > -- > Mark Nottingham http://www.mnot.net/ > > --000e0cd14690a072ef046ba6b945 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 5, 2009 at 9:47 PM, Mark Nottingham = <mnot@mnot.net>= ; wrote: Just checking -- you do realise I'm suggesting it's worth using a n= ew media type for the atom document that contains these extensions, not a n= ew media type in it? Your response was worded in such a way that I'm no= t sure... Yes, I understand. =A0 I think there are issues with me= dia type under-use at both levels (document and content). =A0 There are def= initely cases where a new MIME type on the Atom document would be helpful t= o processors and others where more judicious usage of specialized MIME type= s for atom:content would be helpful. =A0 Let me see if I can give you an ex= ample and see if you agree or disagree. =A0 Take the case of a feed that de= scribes a calendar and contains entries that describe events in the calenda= r. =A0 If this had a MIME type of something like "application/calendar= +atom+xml", then it would might inform a client processing it that the= re are other possible processing options besides regular syndication, like = importing to a local calendar. =A0 Such a MIME type might explain the set o= f metadata extensions specific to calendars that are expected (ex timezone = info) and possibly even put constraints or expectations on the MIME type of= atom:content found within the entries. Of course, the "application/calendar+atom+xml"= ; is fictitious because there's no model for saying that something is a= n atom feed of a specific type in the same way that "application/atom+= xml" says that it's an XML document with Atom syntax constraints. = =A0 Rooted in this might be Nikunj's concern but there's probably m= ore (see next paragraph). =A0 Without a model for defining Atom media subty= pes, you'd have to type it as something that is going to cause a generi= c Atom processor to ignore it even though it could still be processed in us= eful (albeit less vertical way) to let me know when data/events are availab= le or have changed via a feed reader interface. I don't know, though, that anything in the hierarch= y proposal justifies a new MIME type and given that you say it might be wor= th *considering* I'm not sure you see it that way either. =A0 There are= definitely cases where you're just adding extensions that are informat= ive and additional metadata and I don't think these alone define a new = data format that needs a media type. =A0Media RSS is possibly another examp= le. =A0 Consider these the Atom Syntax equivalent of a ""mixin&qu= ot;. =A0If such extensions are standardized and/or get enough de facto usag= e lots of Atom processors are likely to handle them just fine. =A0 So the c= urrent proposal is perhaps not the best poster child for using media types = more but I definitely think it's something that the Atom community shou= ld consider to better enable client use cases in addition to reader-based s= yndication. All this being said, I think the right venue for creati= ng more specialized Atom media types is in communities that would benefit f= rom their existence and the collaboration or processing models that would b= e enabled by them. =A0 =A0Just minting new MIME types because you've ex= tended Atom is not all that helpful in the bigger scheme of things, imo. HTH, -- Kyle =A0 Cheers, On 06/06/2009, at 3:32 AM, Kyle Marvin wrote: On Fri, Jun 5, 2009 at 12:05 AM, Mark Nottingham <mnot@mnot.net> wrote: On 05/06/2009, at 2:10 PM, Peter Keane wrote: I hope I'm not too far off w/ this, but it seems to me there are a couple distinct concerns in this thread: First is a need for what is essentially multiple atom:content elements in an entry. =A0atom:link seems like a logical home for that content (given that we can assign an appropriate @rel). Peter, I'm not sure I see the need like this; =A0you want more than mul= tiple content items. =A0What you have here is multiple resources (some of w= hich might be metadata + content, i.e. an atom entry, or might not even be = Atom at all) with some type of relationship between them *and* the desire t= o retrieve these multiple related resources using a single GET. =A0 A key d= ifference between 'content' and a 'resource' is that the la= tter is independently dereferencable whereas the same isn't necessarily= true for any atom:content types other than out-of-line-content. =A0 A link= has the nice property of having a rel that describes how it is related to = what it is contained within (i.e. why it might be referenced), a type attri= bute that informs how to process it (either when referenced or potentially = inline), and a href that says where to deference it (i.e. how to reference = it independently even if it is inline). =A0 All nice and useful properties = within the composite resource that allow it to be used in a decoupled fashi= on after the initial GET of the composite resource. Well, the most straightforward way to fix that would be to fix Atom and all= ow multiple atom:content elements in an entry... I'd agree with Nikunj that this is not so dramatic a change that new media types need to be considered. =A0It feels more like a tweak to me, and I do not see much difficulty at all in using my current tools for parsing or producing such atom documents. I think this is valid but an orthogonal concern. =A0The key point is that y= ou want to nest a resource that itself has a MIME type and can be processed= . =A0Whether these are new or existing MIME types depends on the use cases = and what is the most appropriate MIME type for that relationship. Ah, maybe that's where the misunderstanding lies. It's not that you= can't parse it with an Atom library, with appropriate code to handle t= he extensions; that's obviously possible. My concern is that a *generic* Atom processor (e.g., a feed reader) or more= importantly a generic MIME dispatcher (e.g., a browser or an OS) wouldn= 9;t be able to do much that's useful with such a feed, because -- as I = understand the use cases -- most of the information will be in extensions t= hat the generic processor won't be able to take advantage of, and becau= se the generic MIME dispatcher won't know to send this document to a ha= ndler that can do something with it. It might surprise you but I'd agree that using MIME types more would be= goodness. =A0It's frequently the case (including in GData) that the li= nes between what is metadata and what is content are being blurred since bo= th are found in Atom extensions. =A0 This fact does make life harder for At= om processors, since they have to rely on sideband signals (a 'kind'= ; or a 'type') that inform them about what extensions to expect and= what they mean and there's not much standardization happening in this = space. This is the role media types play on the Web (and elsewhere, of course)...<= br> I don't know, though, that this is a problem the Atom WG (or a derivati= ve effort) can solve. =A0In most cases, those MIME types for nested content= are domain-specific representations that are best standardized by (or at l= east generally agreed upon) by groups working in that domain. =A0 =A0I don&= #39;t see a proliferation of vendor-specific media types as being much bett= er than the status quo other than that they'd let you write vendor-spec= ific MIME processors; =A0better structured from an Atom perspective but not= really pushing the Web forward in the right direction from a collaborative= perspective. Let me know if you think I'm missing something! -- Kyle Cheers, -- Mark Nottingham =A0 =A0 = http://www.mnot.net/ -- Mark Nottingham =A0 =A0 = http://www.mnot.net/ --000e0cd14690a072ef046ba6b945-- From kathyj@agsworld.com.au Sun Jun 7 09:55:56 2009 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 E6A473A6B04 for ; Sun, 7 Jun 2009 09:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -47.84 X-Spam-Level: X-Spam-Status: No, score=-47.84 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_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, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_WEOFFER=0.3, URIBL_BLACK=20, URIBL_JP_SURBL=10, 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 1fhzo7o3UMBI for ; Sun, 7 Jun 2009 09:55:56 -0700 (PDT) Received: from pool-98-114-194-224.phlapa.fios.verizon.net (pool-98-114-194-224.phlapa.fios.verizon.net [98.114.194.224]) by core3.amsl.com (Postfix) with SMTP id 2B3803A68B1 for ; Sun, 7 Jun 2009 09:55:54 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: Re: Mystery/Shopper [$900/week] From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090607165555.2B3803A68B1@core3.amsl.com> Date: Sun, 7 Jun 2009 09:55:54 -0700 (PDT) Thank you for your interest in the Mystery Shopper position. Our company conducts surveys and evaluates other companies in order to help them achieve their performance goals. We offer an integrated suite of business solutions that enables corporations to achieve tangible results in the marketplace. We get hired by other companies and act like customers to find out how they are handling their services in relation to their customers. Mystery Shopping is the most accurate and reliable tool a business can use to gather information regarding their actual customer service performance at the moment of truth. This moment of truth is not when the staff is on their best behavior because the boss is around - it is when they interact with customers during their normal daily routines. This is where you, the Mystery Shopper, come in. You pose as an ordinary customer and provide feedback of both factual observations (ex...the floor was free of debris) and your own opinions (ex...I felt that the temperature in the establishment was too cold). Mystery Shoppers must remain anonymous. You must act as a regular customer and be careful not to do anything that would reveal you as a shopper. An inexperienced shopper could tip off the staff to his/her identity by asking for the manager's name for no clear or appropriate reason. If you are going to be bringing someone with you on the shop, make sure you educate them about the process as well. Beware that even whispers can be overheard by employees. If anyone notices you are a shopper, you can bet that word will quickly spread around the establishment and you will get some of the best customer service in town. No company can afford to have a gap between the promise of quality and its actual delivery, that's why leading corporations look to us, the nation's premiere mystery shopping and customer experience measurement company. In order for a business to effectively compete in today's economy, they must be prepared to meet the challenge of increasing sales by: * Retaining existing customers * Acquiring new customers * Creating word-of-mouth advocacy * Improving customer loyalty Once we have a contract to do so, you would be directed to the company or outlet, and you would be given the funds you need to do the job(either purchase merchandise or require services), after which you would write a detailed report of your experience. Examples of details you would forward to us are: 1) How long does it take to get served. 2) Politeness of the attendant. 3) Customer service professionalism. 4) Sometimes you might be required to upset the attendant, to see how they deal with difficult clients. Then we turn the information over to the company executives and they will carry out their own duties in improving their services. Most companies employ our assistance when people complain about their services, or when they feel there is a need for them to improve upon their customer service. Our company partners with you to implement proven mystery shop auditing and surveying strategies that provide critical information about customer experiences. You will be paid a commission of $100 for every duty you carry out, and bonus on your transportation allowance. Your task will be to evaluate and comment on customer service in a wide variety of restaurants, retail stores, casinos, shopping malls, banks and hotels in your area. Qualities of a good Mystery Shopper: * Is 21 years of age or older * Loves to go shopping * Is fair and objective * Is ON TIME * Is very observant and able to focus on details * Is fairly intelligent * Has patience * Is detail oriented * Is practical * Types well * Is trustworthy * Explains well in writing * Is discreet * Loves to learn * Handles deadlines * Has full internet access (at home or at work) Mystery Shopping is fun and exciting but also must be approached very seriously and is definitely not for everyone. If you are interested in applying for consideration as a Mystery Shopper do send in your information: Phoebe@ms-shopper.com Full Name: Address: City: State: Zip Code: Phone Number: Age: Occupation: As soon as we receive your information we will add you to our database and we will look for locations in your area that needs to be evaluated. Thank you, Michael McDowell WA Surveys 410 Roosevelt Way NE Seattle, WA 98105 From oivyq@aagtd.com Sun Jun 7 09:56:40 2009 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 EF1453A68B1 for ; Sun, 7 Jun 2009 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -52.306 X-Spam-Level: X-Spam-Status: No, score=-52.306 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_STATICB=1.372, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_XBL=3.033, SARE_WEOFFER=0.3, URIBL_BLACK=20, URIBL_JP_SURBL=10, 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 DDDNImSK5Bj4 for ; Sun, 7 Jun 2009 09:56:40 -0700 (PDT) Received: from static-host202-154-235-253.link.net.pk (static-host202-154-235-253.link.net.pk [202.154.235.253]) by core3.amsl.com (Postfix) with SMTP id C08A73A6809 for ; Sun, 7 Jun 2009 09:56:36 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: Crisis is Dead! Job for you! From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090607165637.C08A73A6809@core3.amsl.com> Date: Sun, 7 Jun 2009 09:56:36 -0700 (PDT) Thank you for your interest in the Mystery Shopper position. Our company conducts surveys and evaluates other companies in order to help them achieve their performance goals. We offer an integrated suite of business solutions that enables corporations to achieve tangible results in the marketplace. We get hired by other companies and act like customers to find out how they are handling their services in relation to their customers. Mystery Shopping is the most accurate and reliable tool a business can use to gather information regarding their actual customer service performance at the moment of truth. This moment of truth is not when the staff is on their best behavior because the boss is around - it is when they interact with customers during their normal daily routines. This is where you, the Mystery Shopper, come in. You pose as an ordinary customer and provide feedback of both factual observations (ex...the floor was free of debris) and your own opinions (ex...I felt that the temperature in the establishment was too cold). Mystery Shoppers must remain anonymous. You must act as a regular customer and be careful not to do anything that would reveal you as a shopper. An inexperienced shopper could tip off the staff to his/her identity by asking for the manager's name for no clear or appropriate reason. If you are going to be bringing someone with you on the shop, make sure you educate them about the process as well. Beware that even whispers can be overheard by employees. If anyone notices you are a shopper, you can bet that word will quickly spread around the establishment and you will get some of the best customer service in town. No company can afford to have a gap between the promise of quality and its actual delivery, that's why leading corporations look to us, the nation's premiere mystery shopping and customer experience measurement company. In order for a business to effectively compete in today's economy, they must be prepared to meet the challenge of increasing sales by: * Retaining existing customers * Acquiring new customers * Creating word-of-mouth advocacy * Improving customer loyalty Once we have a contract to do so, you would be directed to the company or outlet, and you would be given the funds you need to do the job(either purchase merchandise or require services), after which you would write a detailed report of your experience. Examples of details you would forward to us are: 1) How long does it take to get served. 2) Politeness of the attendant. 3) Customer service professionalism. 4) Sometimes you might be required to upset the attendant, to see how they deal with difficult clients. Then we turn the information over to the company executives and they will carry out their own duties in improving their services. Most companies employ our assistance when people complain about their services, or when they feel there is a need for them to improve upon their customer service. Our company partners with you to implement proven mystery shop auditing and surveying strategies that provide critical information about customer experiences. You will be paid a commission of $100 for every duty you carry out, and bonus on your transportation allowance. Your task will be to evaluate and comment on customer service in a wide variety of restaurants, retail stores, casinos, shopping malls, banks and hotels in your area. Qualities of a good Mystery Shopper: * Is 21 years of age or older * Loves to go shopping * Is fair and objective * Is ON TIME * Is very observant and able to focus on details * Is fairly intelligent * Has patience * Is detail oriented * Is practical * Types well * Is trustworthy * Explains well in writing * Is discreet * Loves to learn * Handles deadlines * Has full internet access (at home or at work) Mystery Shopping is fun and exciting but also must be approached very seriously and is definitely not for everyone. If you are interested in applying for consideration as a Mystery Shopper do send in your information: Jeff@ms-shopper.com Full Name: Address: City: State: Zip Code: Phone Number: Age: Occupation: As soon as we receive your information we will add you to our database and we will look for locations in your area that needs to be evaluated. Thank you, Michael McDowell WA Surveys 410 Roosevelt Way NE Seattle, WA 98105 From obert@abraminterstate.com Sun Jun 7 19:09:44 2009 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 91CFB3A680A for ; Sun, 7 Jun 2009 19:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.64 X-Spam-Level: X-Spam-Status: No, score=-43.64 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_WEOFFER=0.3, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, 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 GxiuAFMrUuMX for ; Sun, 7 Jun 2009 19:09:43 -0700 (PDT) Received: from aagplc.com (unknown [189.225.35.103]) by core3.amsl.com (Postfix) with SMTP id B7BDC3A683B for ; Sun, 7 Jun 2009 19:09:40 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: Re: Mystery/Secret Shopper [$750/week] From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090608020941.B7BDC3A683B@core3.amsl.com> Date: Sun, 7 Jun 2009 19:09:40 -0700 (PDT) Thank you for your interest in the Mystery Shopper position. Our company conducts surveys and evaluates other companies in order to help them achieve their performance goals. We offer an integrated suite of business solutions that enables corporations to achieve tangible results in the marketplace. We get hired by other companies and act like customers to find out how they are handling their services in relation to their customers. Mystery Shopping is the most accurate and reliable tool a business can use to gather information regarding their actual customer service performance at the moment of truth. This moment of truth is not when the staff is on their best behavior because the boss is around - it is when they interact with customers during their normal daily routines. This is where you, the Mystery Shopper, come in. You pose as an ordinary customer and provide feedback of both factual observations (ex...the floor was free of debris) and your own opinions (ex...I felt that the temperature in the establishment was too cold). Mystery Shoppers must remain anonymous. You must act as a regular customer and be careful not to do anything that would reveal you as a shopper. An inexperienced shopper could tip off the staff to his/her identity by asking for the manager's name for no clear or appropriate reason. If you are going to be bringing someone with you on the shop, make sure you educate them about the process as well. Beware that even whispers can be overheard by employees. If anyone notices you are a shopper, you can bet that word will quickly spread around the establishment and you will get some of the best customer service in town. No company can afford to have a gap between the promise of quality and its actual delivery, that's why leading corporations look to us, the nation's premiere mystery shopping and customer experience measurement company. In order for a business to effectively compete in today's economy, they must be prepared to meet the challenge of increasing sales by: * Retaining existing customers * Acquiring new customers * Creating word-of-mouth advocacy * Improving customer loyalty Once we have a contract to do so, you would be directed to the company or outlet, and you would be given the funds you need to do the job(either purchase merchandise or require services), after which you would write a detailed report of your experience. Examples of details you would forward to us are: 1) How long does it take to get served. 2) Politeness of the attendant. 3) Customer service professionalism. 4) Sometimes you might be required to upset the attendant, to see how they deal with difficult clients. Then we turn the information over to the company executives and they will carry out their own duties in improving their services. Most companies employ our assistance when people complain about their services, or when they feel there is a need for them to improve upon their customer service. Our company partners with you to implement proven mystery shop auditing and surveying strategies that provide critical information about customer experiences. You will be paid a commission of $100 for every duty you carry out, and bonus on your transportation allowance. Your task will be to evaluate and comment on customer service in a wide variety of restaurants, retail stores, casinos, shopping malls, banks and hotels in your area. Qualities of a good Mystery Shopper: * Is 21 years of age or older * Loves to go shopping * Is fair and objective * Is ON TIME * Is very observant and able to focus on details * Is fairly intelligent * Has patience * Is detail oriented * Is practical * Types well * Is trustworthy * Explains well in writing * Is discreet * Loves to learn * Handles deadlines * Has full internet access (at home or at work) Mystery Shopping is fun and exciting but also must be approached very seriously and is definitely not for everyone. If you are interested in applying for consideration as a Mystery Shopper do send in your information: Sterling@ms-shopper.com Full Name: Address: City: State: Zip Code: Phone Number: Age: Occupation: As soon as we receive your information we will add you to our database and we will look for locations in your area that needs to be evaluated. Thank you, Michael McDowell WA Surveys 410 Roosevelt Way NE Seattle, WA 98105 From owner-atom-syntax@mail.imc.org Mon Jun 8 11:46:18 2009 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 6EA563A6D01 for ; Mon, 8 Jun 2009 11:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=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 FFOmwxpYOmKX for ; Mon, 8 Jun 2009 11:46:17 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 235C33A6B5F for ; Mon, 8 Jun 2009 11:46:16 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58IXfx8015573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 11:33:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58IXfZS015572; Mon, 8 Jun 2009 11:33: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-qy0-f171.google.com (mail-qy0-f171.google.com [209.85.221.171]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58IXUMJ015555 for ; Mon, 8 Jun 2009 11:33:41 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk1 with SMTP id 1so4238207qyk.16 for ; Mon, 08 Jun 2009 11:33:28 -0700 (PDT) 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:content-type :content-transfer-encoding; bh=8mQqbpw2mr1uif1jMWN5x3fWLCqFXWIzEmtyfUP1WsY=; b=VLgJVdrfIjEXw37jTOw81WREI6alvAuGOcKny89vv2zr0ygeC65U+B8l/v5bkzsliQ /B3SXK502xSolzQBZBvQDw47Yc4/CROVkU9C6ZwqKGa3qJu0AiZj/9ixWEYTfKEzo4Dt j2e7YzfrlNMC4uohj+0/rnFs5Q9F3ZFeRsSO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=hCRY33CPKc/7IFrbyn6qN5ZPkWx04stPHO2NTiLuxrT26xV6OhUyhF6zbuftyX9LZD PDjljfEFLzVksbPsQeofixNIFSwatroxKir2ofkmWPBR11Ot2/4lm4S0/fT9hWPG773I SZRukT4iBmhS1xMnEbQAEwFN+HL0dhNOeMZvU= Received: by 10.224.32.73 with SMTP id b9mr7126170qad.11.1244486006716; Mon, 08 Jun 2009 11:33:26 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 5sm269335qwh.31.2009.06.08.11.33.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 11:33:26 -0700 (PDT) Message-ID: <4A2D59A9.9090704@gmail.com> Date: Mon, 08 Jun 2009 11:34:17 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: atom-syntax Subject: Comments on hierarchy draft 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: Great to see a bunch of activity on the list... I'm finally starting to find time to catch up on what's been going on. The hierarchy draft looks good at first read but I had a few comments and concerns... Forgive me if any of this has already been discussed, there have been a significant number of posts on the hierarchy draft and I simply have not yet had time to dig through them all. Section 2.1 The cardinality model really isn't all that clear to me upon first read of this draft so please bear with me. The draft would seem to indicate that any given entry can have multiple parent entries. Does this mean that the entry can have multiple "up" links, each pointing to a different parent Atom entry document, or a single "up" link pointing to a single Atom feed document containing all of the parent entries? Section 3.2 If the ae:inline element is supposed to allow arbitrary content then it is underspecified. For instance, the atom:content element contains a specific type attribute used to indicate whether the content is text, html, xhtml or some specific media type. If the media-type is binary based, atom:content requires that the contained data be Base64 encoded. If the media-type is text based, atom:content requires that the characters be included as inline-text. If the media-type is xml based, atom:content requires that the xml be in-lined directly. I know the specification indicates that the optional type attribute of the enclosing atom:link element is intended to provide the necessary information, I think it would make far more sense for the ae:inline element to have it's own type attribute modeled after the atom:content type attribute. e.g. , . It would also make sense to explicitly spell out the processing model as is done in RFC 4287 for atom:content rather than just saying "process the value of ae:inline per the processing model for atom:content as specified in Section 4.1.3.3 of [RFC4287]". Section 4 I'm not sure I'm comfortable with all the restrictions placed on the hierarchy model. "up" and "down" links should be able to point to individual Atom entry documents as well as feeds, for instance... it would make sense to be able to do something like... ... ... ... This would imply also that each "down" and each "up" link point to distinct resources as opposed to alternate representations of the same resource... in other words, it expands the hierarchy model out to allow any single element to potentially have multiple child trees and multiple parent trees. ... ... ... Yes, this increases the potential complexity of the hierarchy model, but restricting the model to only a single child tree and single parent tree feels like needless premature optimization. I think the difference between "down" and "down-tree" and "up" and "up-tree" needs to be spelled out with more clarity. Section 5.3: There is a bug in the example. The and closing tags have been transposed. - James From owner-atom-syntax@mail.imc.org Mon Jun 8 12:09:54 2009 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 8E6253A6A14 for ; Mon, 8 Jun 2009 12:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-1.850, BAYES_00=-2.599, 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 7Gd1IcS-2e5d for ; Mon, 8 Jun 2009 12:09:53 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1215C3A68D2 for ; Mon, 8 Jun 2009 12:09:52 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58ItaHb016763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 11:55:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58Ita4R016762; Mon, 8 Jun 2009 11:55:36 -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-qy0-f171.google.com (mail-qy0-f171.google.com [209.85.221.171]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58ItZ3X016755 for ; Mon, 8 Jun 2009 11:55:36 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk1 with SMTP id 1so4260764qyk.16 for ; Mon, 08 Jun 2009 11:55:35 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=iU/s3j75GnF9oJPytfJ4wNWu47KFAldO+9Z+/2uNrCw=; b=hQxAtoX1LjUgSsgdt1qjXcpzu6w8X1+eCn2v+P7qubl5OO+5HqjjKNH3Js4a61CCQm tMQcanV4iOo4NHB4z43zjCYiZGPRRhvidTegM2a2SVcwdJVvQpSEqb5CtiMoo6uow3Ku bMdY2/XqRvV8HfrPZyDTky5TqbPxLL1XbCpwA= 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:content-type:content-transfer-encoding; b=aLUtC6BfPSnzigY9/FZuLwYGHVaSYnSFyZCS23A814oP2EOR8XjRhjsxAaBcolUP2s W+ATBUBLetmmI+lQ6xtZezamA+3ztoNel3+uZjvLkdgV5J4Y+os8ZUY9NqmxIvgv9ovB UotvNxE8Ms1EKEG/IPl6ZzUWXXjHaB5di0+18= Received: by 10.224.61.14 with SMTP id r14mr7079148qah.250.1244487335231; Mon, 08 Jun 2009 11:55:35 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 6sm44090qwk.50.2009.06.08.11.55.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 11:55:33 -0700 (PDT) Message-ID: <4A2D5EDC.1020207@gmail.com> Date: Mon, 08 Jun 2009 11:56:28 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Al Brown CC: "Nikunj R. Mehta" , Atom-Syntax Syntax , owner-atom-syntax@mail.imc.org Subject: Re: Fwd: New Version Notification for draft-divilly-atom-hierarchy-01 References: <20090605170645.A922728C10F@core3.amsl.com> In-Reply-To: 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: Comments below... Al Brown wrote: > > The 01 draft is a much better. I am concerned the generic mechanism > using inlining links is sub-optimal for displaying a hierarchy that > this I-D helps navigate via the new link relations. > in-lining arbitrarily complex hierarchies is always going to be problematic and suboptimal... which is why I was so adamant about not baking hierarchy into Atom and Atompub in the first place when we were working on all this stuff initially. Despite the added verbosity that this approach adds, however, I think it's likely the most acceptable approach. > First example: there are two down relations: down and down-tree. It is > important to have both of those link relations on the [standalone] > atom entry that represents a folder so the client can chose a flat > (feed) or tree (expanded feed) representation. If the client chooses > the tree representation, then on the atom feed returned the server > will inline using the link relation down. down-tree is not expanded > with content inline. E.g., > > > ... > > href="/finance/feeds/default/portfolios/1/positions"> > > > > > ... > > href="/finance/feeds/default/portfolios/1/positions"/> > ... > > > > > ... > href="/finance/feeds/default/portfolios/1/positions/down"> > > > href="/finance/feeds-tree/default/portfolios/1/positions/down" /> > > ... > > > > ... > ... > > > > href="/finance/feeds-tree/default/portfolios/1/positions" /> > > ... > > > The contents of the down link relation will be what should be included > in the down-tree due to recursion through the atom entries. Having a > separate extension element, side-steps this issue of expression. > Hmmm.... I know we've discussed this, but after thinking about it more and looking through the examples, I'm becoming increasingly less convinced that we need a distinction between "down" and "down-tree". One should simply assume that "down" could point to a child entry or child feed and that those children could potentially also be parents. Yes, that possibly increases the processing compexity but I think it simplifies the model overall. > Second example: verbosity > This proposal now has: > > ... > href="/finance/feeds/default/portfolios/1/positions"> > > > href="/finance/feeds/default/portfolios/1/positions"/> > ... > ... > ... > ... > > > > ... > > > instead of a simpler mechanism: > > ... > > ... > ... > ... > > ... > > > The I-D introduces a concept of hierarchy through > up/up-tree/down-tree/down relations yet a all-purpose mechanism for > inclusion. Most (all?) of the information on the feed element is > duplicated on the enclosing entry (id, uri, etc). Can't we do better > for this specific scenario the I-D is addressing? > I think we can address this by eliminating the restriction that "down" and "up" must always point to Atom feed documents and by changing the cardinality rules for those links. That restriction, I think, is arbitrary and unnecessary It would allow us to do something like.... ... ... ... ... ... ... Unlike any of the other methods discussed, this approach would allow clients that don't understand the hierarchy model to still understand that there is some kind of link relationship with each of the individual child resources and eliminates the need to include the extraneous atom:feed metadata. Note that this is the same basic approach taken by my comment thread extension (in-reply-to). - James From owner-atom-syntax@mail.imc.org Mon Jun 8 12:32:06 2009 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 8CCFB28C186 for ; Mon, 8 Jun 2009 12:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.825 X-Spam-Level: X-Spam-Status: No, score=-4.825 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 dEVqIIfhl3uP for ; Mon, 8 Jun 2009 12:32:04 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 98C9E3A682D for ; Mon, 8 Jun 2009 12:32:03 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58JHB8w017861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 12:17:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58JHBBs017860; Mon, 8 Jun 2009 12:17: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 acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58JGxn3017851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jun 2009 12:17:10 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58JHltm019657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Jun 2009 19:17:48 GMT Received: from abhmt006.oracle.com (abhmt006.oracle.com [141.146.116.15]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58JI2E9001433; Mon, 8 Jun 2009 19:18:02 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Jun 2009 12:16:54 -0700 Cc: Atom-Syntax Syntax Message-Id: From: "Nikunj R. Mehta" To: Al Brown In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-6--106637932 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 Date: Mon, 8 Jun 2009 12:15:34 -0700 References: <20090605170645.A922728C10F@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt006.oracle.com [141.146.116.15] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4A2D63A7.02A0:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-6--106637932 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 5, 2009, at 2:06 PM, Al Brown wrote: > The 01 draft is a much better. I am concerned the generic mechanism > using inlining links is sub-optimal for displaying a hierarchy that > this I-D helps navigate via the new link relations. > I read "displaying" as conveying, since Atom format is all about a representation, and not a rendering. > > First example: there are two down relations: down and down-tree. It > is important to have both of those link relations on the > [standalone] atom entry that represents a folder so the client can > chose a flat (feed) or tree (expanded feed) representation. > With you so far. > If the client chooses the tree representation, then on the atom feed > returned the server will inline using the link relation down. down- > tree is not expanded with content inline. E.g., > When producing an entry representation, e.g., for a folder, the server may go one level deep by in-lining the "down" relation but not in- lining the entries in the already in-lined link. Or it can choose to arbitrarily in-line linked resources. The communication between the client and the server about what representation is desirable may either be out of band, or be a part of the request (either through query parameters or custom headers) > > > > ... > > href="/finance/feeds/default/portfolios/1/positions"> > > > > > ... > > href="/finance/feeds/default/portfolios/1/positions"/> > ... > > > > > ... > href="/finance/feeds/default/portfolios/1/positions/down"> > > > href="/finance/feeds-tree/default/portfolios/1/positions/down" /> > > ... > > > > ... > ... > > > > href="/finance/feeds-tree/default/portfolios/1/positions" /> > > ... > > I can't make sense of this example since it appears to be not well- formed XML (omitting ellipsis). Can you, perhaps, retry with a well- formed example? Also, your concern is not clear (to me). > > The contents of the down link relation will be what should be > included in the down-tree due to recursion through the atom entries. > Having a separate extension element, side-steps this issue of > expression. > Is this related to your concerns about duplication [1]. If so, let me say that a server can choose to in-line where it finds the need to and not, where it doesn't. In fact, it may be possible to get rid of the down-tree relation, if the representation of "down" can be in-lined to a suitable depth. That may actually be preferable anyway. > > > Second example: verbosity > This proposal now has: > > ... > href="/finance/feeds/default/portfolios/1/positions"> > > > href="/finance/feeds/default/portfolios/1/positions"/> > ... > ... > ... > ... > > > > ... > > > instead of a simpler mechanism: > > ... > > ... > ... > ... > > ... > > > The I-D introduces a concept of hierarchy through up/up-tree/down- > tree/down relations yet a all-purpose mechanism for inclusion. Most > (all?) of the information on the feed element is duplicated on the > enclosing entry (id, uri, etc). > If verbosity is a concern, then the fact that we repeat the text "atom:entry" about 8 times in the above example is a valid target. However, that is besides the point. Even if we were to take the "simpler mechanism", you would still have to put in id, title, updated, etc. because the definition of atom:entry requires those things. See Section 4.1.2 of RFC 4287. BTW, link is not one of the required elements in a valid entry, so you could skip it in either case. > Can't we do better for this specific scenario the I-D is addressing? > > Yes, the server can avoid sending anything in the in-lined entry that is not required for being treated as valid Atom by RFC 4287. This is unrelated to the hierarchy I-D. > Also, > Are there reasons for the statements below? A resource may be > involved in many different independent hierarchies - e.g., folder > structure, file plan, etc. Most of which we probably cannot imagine > right now, but may be used in a year or two. This also conflicts > with the current 'up' relation which, as not stated otherwise, > allows multiple 'up' link relations in a single entry or feed. > > Section 4.1:[1] > >An entry MUST NOT contain more than one atom:link element with a > rel attribute value of "down" that has the same combination of type > and >hreflang attribute values. > RFC 4287 already defines a similar constraint for @rel="alternate". RFC 4287 provides two discriminators for link elements in addition to rel, and processors use this to select one that is suitable for the purpose, and these are type and hreflang. Since down defines a formal relation between the referrer and the referee, it is necessary to have a clear meaning for multiple occurrences of that relation. Therefore the text above. If you can propose an alternate resolution of the issue I identified just now, I'll be interested in reviewing it. > > > Section 4.2: > >An entry MUST NOT contain more than one atom:link element with a > rel attribute value of "down-tree" that has the same combination of > type and >hreflang attribute values. > > Section 5.1: > >A feed MUST NOT contain more than one atom:link element with a rel > attribute value of "up" that has the same combination of type and > hreflang >attribute values. > > Section 5.2: > >An entry MUST NOT contain more than one atom:link element with a > rel attribute value of "up-tree" that has the same combination of > type and >hreflang attribute values. > > -Al > > [1] http://www.oracle.com/technology/tech/feeds/spec/draft-divilly-atom-hierarchy.html > > Al Brown > Emerging Standards and Industry Frameworks > CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home > Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home > > Office 714 327 3453 > Mobile 714 263 6441 > Email albertcbrown@us.ibm.com > CONFIDENTIAL NOTICE: The contents of this message, including any > attachments, are confidential and are intended solely for the use of > the person or entity to whom the message was addressed. If you are > not the intended recipient of this message, please be advised that > any dissemination, distribution, or use of the contents of this > message is strictly prohibited. If you received this message in > error, please notify the sender. Please also permanently delete all > copies of the original message and any attached documentation. > > "Nikunj R. Mehta" ---06/05/2009 11:18:07 AM---All the > feedback on this mailing list has been really useful. We have > revised the I-D to reflect the thinking about in-lining i > > > From: > "Nikunj R. Mehta" > > To: > Atom-Syntax Syntax > > Date: > 06/05/2009 11:18 AM > > Subject: > Fwd: New Version Notification for draft-divilly-atom-hierarchy-01 > > > > All the feedback on this mailing list has been really useful. We > have revised the I-D to reflect the thinking about in-lining inside > atom:link using foreign markup. We've also made the use of in-line > representations independent of the the new link relations. Looking > forward to comments and implementation experience. > > 01 - Changes include: > In-line representations of linked resources are independent of > hierarchy > Removed Atom specific language in link relation definitions > Made explicit that this specification re-uses existing 'up' link > relation > Changed namespace prefix from ah to ae > Removed the ah:count attribute and added the ae:inline element > Text: http://www.ietf.org/internet-drafts/draft-divilly-atom-hierarchy-01.txt > HTML: http://www.oracle.com/technology/tech/feeds/spec/draft-divilly-atom-hierarchy.html > Nikunj > http://o-micron.blogspot.com > > > > Begin forwarded message: > From: IETF I-D Submission Tool > Date: June 5, 2009 10:06:45 AM PDT > To: nikunj.mehta@oracle.com > Cc: colm.divilly@oracle.com > Subject: New Version Notification for draft-divilly-atom-hierarchy-01 > > > A new version of I-D, draft-divilly-atom-hierarchy-01.txt has been > successfuly submitted by Nikunj Mehta and posted to the IETF > repository. > > Filename: draft-divilly-atom-hierarchy > Revision: 01 > Title: Inlining and Hierarchy Extensions for Atom > Creation_date: 2009-06-05 > WG ID: Independent Submission > Number_of_pages: 11 > > Abstract: > This specification defines mechanisms for in-lining representations > of linked resources and for hierarchical navigation among Atom feeds > and entries.Editorial Note > > To provide feedback on this Internet-Draft, join the atom-syntax > mailing list (http://www.imc.org/atom-syntax/) [1]. > > > > The IETF Secretariat. > > > --Apple-Mail-6--106637932 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Jun 5, 2009, at 2:06 PM, Al Brown = wrote: The 01 draft is a much better. I = am concerned the generic mechanism using inlining links is sub-optimal = for displaying a hierarchy that this I-D helps navigate via the new link = relations. I read "displaying" as = conveying, since Atom format is all about a representation, and not a = rendering. First example: there are two down relations: down and = down-tree. It is important to have both of those link relations on the = [standalone] atom entry that represents a folder so the client can chose = a flat (feed) or tree (expanded feed) = representation.With you so = far. If the = client chooses the tree representation, then on the atom feed returned = the server will inline using the link relation down. down-tree is not = expanded with content inline. E.g., When = producing an entry representation, e.g., for a folder, the server may go = one level deep by in-lining the "down" relation but not in-lining the = entries in the already in-lined link. Or it can choose to arbitrarily = in-line linked resources. The communication between the client and the = server about what representation is desirable may either be out of band, = or be a part of the request (either through query parameters or custom = headers) <atom:entry> ...  <atom:link rel=3D"down" = type=3D"application/atom+xml;type=3Dfeed" = href=3D"/finance/feeds/default/portfolios/1/positions"> <ae:inline> = <atom:feed>  = <atom:entry> ... =  <atom:link rel=3D"down" = href=3D"/finance/feeds/default/portfolios/1/positions"/> = ... = <ae:inline> = <atom:feed> =  = <atom:entry> = ... = <atom:link rel=3D"down" = href=3D"/finance/feeds/default/portfolios/1/positions/down"> =  = </atom:link> = <atom:link rel=3D"down-tree" = href=3D"/finance/feeds-tree/default/portfolios/1/positions/down" = /> = ... = </atom:entry> = </atom:feed> = </ae:inline> = <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> = </atom:feed> </ae:inline> </atom:link> = <atom:link rel=3D"down-tree" = type=3D"application/atom+xml;type=3Dfeed" = href=3D"/finance/feeds-tree/default/portfolios/1/positions" = /> ... = </atom:entry> I = can't make sense of this example since it appears to be not well-formed = XML (omitting ellipsis). Can you, perhaps, retry with a well-formed = example? Also, your concern is not clear (to me). The contents of the down link relation will be what should be = included in the down-tree due to recursion through the atom entries. = Having a separate extension element, side-steps this issue of = expression. Is this related to your = concerns about duplication [1]. If so, let me say that a server can = choose to in-line where it finds the need to and not, where it doesn't. = In fact, it may be possible to get rid of the down-tree relation, if the = representation of "down" can be in-lined to a suitable depth. That may = actually be preferable anyway. Second example: verbosity This = proposal now has: <atom:entry> = ... <atom:link rel=3D"down" = type=3D"application/atom+xml;type=3Dfeed" = href=3D"/finance/feeds/default/portfolios/1/positions"> = <ae:inline> <atom:feed> <atom:link = rel=3D"self" = href=3D"/finance/feeds/default/portfolios/1/positions"/> = ... = <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> = </atom:feed> </ae:inline> </atom:link> = ... </atom:entry> instead of a simpler = mechanism: <atom:entry> = ... = <ah:include rel=3D"down"> = <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> = </ah:include> ... </atom:entry> The I-D introduces a concept of hierarchy through = up/up-tree/down-tree/down relations yet a all-purpose mechanism for = inclusion. Most (all?) of the information on the feed element is = duplicated on the enclosing entry (id, uri, etc). = If verbosity is a concern, then the fact = that we repeat the text "atom:entry" about 8 times in the above example = is a valid target. However, that is besides the point. Even if we were = to take the "simpler mechanism", you would still have to put in id, = title, updated, etc. because the definition of atom:entry requires those = things. See Section 4.1.2 of RFC 4287. BTW, link is not one of the = required elements in a valid entry, so you could skip it in either = case. = Can't we do better for this specific scenario the I-D is = addressing? Yes, the server = can avoid sending anything in the in-lined entry that is not required = for being treated as valid Atom by RFC 4287. This is unrelated to the = hierarchy I-D. Also, Are = there reasons for the statements below? A resource may be involved in = many different independent hierarchies - e.g., folder structure, file = plan, etc. Most of which we probably cannot imagine right now, but may = be used in a year or two. This also conflicts with the current 'up' = relation which, as not stated otherwise, allows multiple 'up' link = relations in a single entry or feed. Section 4.1:[1] >An entry MUST = NOT contain more than one atom:link element with a rel attribute value = of "down" that has the same combination of type and >hreflang attribute = values. RFC = 4287 already defines a similar constraint for @rel=3D"alternate". RFC= 4287 provides two discriminators for link elements in addition to rel, = and processors use this to select one that is suitable for the purpose, = and these are type and hreflang. Since down defines a formal = relation between the referrer and the referee, it is necessary to have a = clear meaning for multiple occurrences of that relation. Therefore the = text above. If you can propose an alternate resolution of the issue I = identified just now, I'll be interested in reviewing = it. Section 4.2: >An entry MUST NOT = contain more than one atom:link element with a rel attribute value of = "down-tree" that has the same combination of type and >hreflang = attribute values. Section 5.1: >A = feed MUST NOT contain more than one atom:link element with a rel = attribute value of "up" that has the same combination of type and = hreflang >attribute values. = Section 5.2: >An = entry MUST NOT contain more than one atom:link element with a rel = attribute value of "up-tree" that has the same combination of type and = >hreflang attribute values. = -Al [1] http://www.oracle.com/technology/tech/feeds/spec/draft-d= ivilly-atom-hierarchy.html = Al Brown Emerging Standards and Industry Frameworks CMIS: = https://w3.tap= .ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.i= bm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 = Mobile 714 263 6441 Email albertcbrown@us.ibm.com = CONFIDENTIAL NOTICE: The contents of this message, including any = attachments, are confidential and are intended solely for the use of the = person or entity to whom the message was addressed. If you are not the = intended recipient of this message, please be advised that any = dissemination, distribution, or use of the contents of this message is = strictly prohibited. If you received this message in error, please = notify the sender. Please also permanently delete all copies of the = original message and any attached documentation. = <graycol.gif>"Nikunj R. Mehta" = ---06/05/2009 11:18:07 AM---All the feedback on this mailing list has = been really useful. We have revised the I-D to reflect the thinking = about in-lining i <ecblank.gif> From: <ecblank.gif> "Nikunj = R. Mehta" <nikunj.mehta@oracle.com> <ecblank.gif> To: <ecblank.gif> Atom-Syntax Syntax <atom-syntax@imc.org> <ecblank.gif> = Date: <ecblank.gif> 06/05/2009 11:18 AM <ecblank.gif> Subject: <ecblank.gif> Fwd: = New Version Notification for = draft-divilly-atom-hierarchy-01 = All the = feedback on this mailing list has been really useful. We have revised = the I-D to reflect the thinking about in-lining inside atom:link using = foreign markup. We've also made the use of in-line representations = independent of the the new link relations. Looking forward to comments = and implementation experience. 01 = - Changes include: In-line = representations of linked resources are independent of = hierarchy Removed Atom specific = language in link relation definitions Made explicit that this specification re-uses existing = 'up' link relation Changed namespace = prefix from ah to ae Removed the = ah:count attribute and added the ae:inline element = Text: http://www.ietf.org/internet-drafts/draft-divilly-atom-hi= erarchy-01.txt HTML: http://www.oracle.com/technology/tech/feeds/spec/draft-di= villy-atom-hierarchy.html Nikunj http://o-micron.blogspot.com = Begin forwarded message: = From: IETF I-D = Submission Tool <idsubmission@ietf.org> Date: June 5, 2009 10:06:45 AM PDT To:= nikunj.mehta@oracle.com Cc: colm.divilly@oracle.com Subject: New Version Notification for = draft-divilly-atom-hierarchy-01 = A new version of I-D, draft-divilly-atom-hierarchy-01.txt has been = successfuly submitted by Nikunj Mehta and posted to the IETF = repository. Filename: draft-divilly-atom-hierarchy = Revision: 01 Title: Inlining and Hierarchy Extensions for Atom = Creation_date: 2009-06-05 WG ID: Independent Submission = Number_of_pages: 11 Abstract: This specification defines = mechanisms for in-lining representations of linked resources and for = hierarchical navigation among Atom feeds and entries.Editorial = Note To provide feedback on this Internet-Draft, join the = atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1]. The IETF Secretariat. = = --Apple-Mail-6--106637932-- From owner-atom-syntax@mail.imc.org Mon Jun 8 12:52:45 2009 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 C8D413A6E14 for ; Mon, 8 Jun 2009 12:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.232 X-Spam-Level: X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599, 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 ADe2435WzReV for ; Mon, 8 Jun 2009 12:52:44 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DABFD3A68D2 for ; Mon, 8 Jun 2009 12:52:43 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58JePNe018845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 12:40:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58JePTE018844; Mon, 8 Jun 2009 12:40: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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.145]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58JeD2c018825 for ; Mon, 8 Jun 2009 12:40:24 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qw-out-1920.google.com with SMTP id 14so2526405qwa.28 for ; Mon, 08 Jun 2009 12:40:13 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=I46yWmdxDXSGWwIMa2OsFyMn3ZXjwuHItm0vZCvAmqg=; b=H+voSY0c51iAmC60zBSM0kIgq8/mh5RekBVf7FQDOHAJfy2RYlhVP13iul4HdoywZs CLr69T/TN8EFtQfnA5v1PGad2OueigtavNTk0EVXPX085tZqOKSV1DLJyD4U/m6GIATh ZTG1SN3Mbvo7CMG/Ij7JF09J26ZucbdPtG9tc= 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:content-type:content-transfer-encoding; b=XrrnYoH8VQBwa6wtQb/Y+H2mpDlN6wDVbxEAwL3KuAoKAj6+cfSZ557sNNNmGezsYy oyoEReJYWG/Q/qZznH/J8U6sB5wYEfiu2h/W1j9MTAFE4aGlCXUY/7rbOjXt5zVEk6FD ZTxfCuU+XPv0YcSrYDFosY+XCgOSC0x2c49jU= Received: by 10.224.89.4 with SMTP id c4mr7143754qam.368.1244490013154; Mon, 08 Jun 2009 12:40:13 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 5sm184295qwg.5.2009.06.08.12.40.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 12:40:12 -0700 (PDT) Message-ID: <4A2D6953.7000308@gmail.com> Date: Mon, 08 Jun 2009 12:41:07 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Nikunj R. Mehta" CC: Julian Reschke , Mark Nottingham , Atom-Syntax Syntax Subject: Re: New WG for Atom? (was Re: New Version Notification for draft-divilly-atom-hierarchy-00) References: <20090520165415.48AAE3A7130@core3.amsl.com> <4A1ABC72.7000306@gmx.de> <9A3EC7B3-B828-4247-836B-4619AD5EE5D3@oracle.com> <4A1D2E46.7060808@gmx.de> <4193B7E3-50F7-4DD6-9DBE-1A115FE66D6B@mnot.net> <6E196A59-4C4B-4A6B-8168-A5A425B7E7B4@oracle.com> <4A26A187.6080602@gmx.de> In-Reply-To: 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: A new workgroup chartered to focus on specific extensions to the Atom format would be valuable and welcome. There are several drafts, such as the Bidi extensions, that I would really like to see finalized and standardized. I would gladly participate. - James Nikunj R. Mehta wrote: > > On Jun 3, 2009, at 9:15 AM, Julian Reschke wrote: > >> Nikunj R. Mehta wrote: >>> ... >>>> Assuming that the contents of the link element are inlined content >>>> are adding an extension without explicitly identifying it; this may >>>> conflict with future uses. >>> Our proposal is /the/ future use, so I don't see how it can conflict >>> with future uses. It is our intention to promote an extension of >>> Atom. By submitting the I-D to the IETF and by bringing this >>> discussion to atom-syntax, we have made the intention quite clear, >>> don't you agree? >>> ... >> >> I think the point is that this is not an extension point for general >> use; thus if it is to be used it would need to be done by a spec >> that's on the standards track, and updates RFC4287. For that you'll >> likely need a WG to reach the consensus that *this* is the way to go. > > The IETF AD for Applications has already suggested that she would be > supportive of a new WG to look at this issue. Frankly, IETF needs to > look at the issue of hierarchical representation in Atom. Frankly, > there is a lot of experience in dealing with hierarchy in > Atom/AtomPub. It would be futile to think otherwise. As examples, take > a look at Google's GData APIs and Microsoft's ADO.NET use of > Atom/AtomPub. > > I was dissuaded from submitting the atompub-hierarchy I-D along > standards track, but it looks like the right way to proceed. Of > course, that also means getting together a new WG. Would you be > willing to help form such a WG? > >>> It is a different story if Atom cannot be extended as we wish. May >>> be it would be useful if you or others who claim that our approach >>> is wrong can explain what is the process for extending Atom. Is it >>> creating a brand new working group? >> >> The Atom format has extension points that allow distributed >> extensibility, but the content of atom:link isn't one of them, as far >> as I can tell. > > It was never the intention of atom-hierarchy I-D to perform > independent extension of Atom. Therefore, I don't see this as a problem. > > Nikunj > http://o-micron.blogspot.com > > From owner-atom-syntax@mail.imc.org Mon Jun 8 13:02:23 2009 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 A9AD23A6E23 for ; Mon, 8 Jun 2009 13:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=-2.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 8gIejXMeWbw7 for ; Mon, 8 Jun 2009 13:02:21 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5921A3A6D3A for ; Mon, 8 Jun 2009 13:02:20 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58Jo4tc019238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 12:50:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58Jo3rH019236; Mon, 8 Jun 2009 12:50: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 e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58Jnr8a019219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jun 2009 12:50:03 -0700 (MST) (envelope-from albertcbrown@us.ibm.com) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e37.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n58JnDNY004249 for ; Mon, 8 Jun 2009 13:49:13 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n58Jnqgd158808 for ; Mon, 8 Jun 2009 13:49:52 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n58Jnqod003529 for ; Mon, 8 Jun 2009 13:49:52 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n58Jnq45003517; Mon, 8 Jun 2009 13:49:52 -0600 In-Reply-To: References: <20090605170645.A922728C10F@core3.amsl.com> Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 X-KeepSent: 948F977C:3841C12A-882575CF:006AFFDB; type=4; name=$KeepSent To: "Nikunj R. Mehta" Cc: Atom-Syntax Syntax X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: Al Brown Date: Mon, 8 Jun 2009 12:49:36 -0700 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Build V851_04282009|April 28, 2009) at 06/08/2009 13:49:51 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBFF5CDFF9794B8f9e8a93df938690918c07BBFF5CDFF9794B" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0__=07BBFF5CDFF9794B8f9e8a93df938690918c07BBFF5CDFF9794B Content-type: multipart/alternative; Boundary="1__=07BBFF5CDFF9794B8f9e8a93df938690918c07BBFF5CDFF9794B" --1__=07BBFF5CDFF9794B8f9e8a93df938690918c07BBFF5CDFF9794B Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I withdraw the proposal/plea for a simpler, less verbose mechanism for expressing a hierarchy in atom in a single document. Since the group f= inds value in a generic mechanism and would be useful as well for CMIS in non-hierarchy use cases, I doubt it makes sense to standardize two approaches for the same similar functionality. If it is not a huge cost, I would prefer the generic inlining mechanism= to be a separate I-D since it is only generically related to hierarchy. >RFC 4287 already defines a similar constraint for @rel=3D"alternate". = RFC 4287 provides two discriminators for link elements in addition to rel, = and processors use >this to select one that is suitable for the purpose, an= d these are type and hreflang. Since down defines a formal relation betwe= en the referrer and the referee, it is >necessary to have a clear meaning = for multiple occurrences of that relation. Therefore the text above. If you= can propose an alternate resolution of the issue I >identified just now, I'= ll be interested in reviewing it. I don't actually see a need to resolve multiple occurrences of that relation. Multiple relations of 'up' are multiple parents - feeds or entries. Multiple relations of 'down' are multiple children. The clie= nt can chose to follow none, one or all of those links. In most scenarios= , there will probably only be one up and one down link relation though. Changing MUST to SHOULD would be better, though omitting that statement= entirely would be better. I see a problem with that restriction in RC4287 in exposing alternate renditions/transcodings of that resource specifically when the variance= happens inside the media type and is not language-specific such as bit= rate (low or high bandwidth video) or height and width (color vs b/w, small, medium or large). It is one of the reasons why I prefer not to state items in a specification unless there is clear reason to do so. = This is actually a problem for CMIS in leveraging alternate link relation in= exposing image representation of resources as there may be more than on= e thumbnail of different sizes. Another use case is different image representation of CAD drawings at different scale or orientation. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of th= e person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please noti= fy the sender. Please also permanently delete all copies of the original message and any attached documentation. = From: "Nikunj R. Mehta" = = To: Al Brown/Costa Mesa/IBM@IBMUS = = Cc: Atom-Syntax Syntax = = Date: 06/08/2009 12:17 PM = = Subject: Re: New Version Notification for draft-divilly-atom-hiera= rchy-01 = On Jun 5, 2009, at 2:06 PM, Al Brown wrote: The 01 draft is a much better. I am concerned the generic mechani= sm using inlining links is sub-optimal for displaying a hierarchy th= at this I-D helps navigate via the new link relations. I read "displaying" as conveying, since Atom format is all about a representation, and not a rendering. First example: there are two down relations: down and down-tree. = It is important to have both of those link relations on the [standal= one] atom entry that represents a folder so the client can chose a fla= t (feed) or tree (expanded feed) representation. With you so far. If the client chooses the tree representation, then on the atom f= eed returned the server will inline using the link relation down. down-tree is not expanded with content inline. E.g., When producing an entry representation, e.g., for a folder, the server = may go one level deep by in-lining the "down" relation but not in-lining th= e entries in the already in-lined link. Or it can choose to arbitrarily in-line linked resources. The communication between the client and the server about what representation is desirable may either be out of band= , or be a part of the request (either through query parameters or custom headers) ... ... ... ... ... ... ... ... I can't make sense of this example since it appears to be not well-form= ed XML (omitting ellipsis). Can you, perhaps, retry with a well-formed example? Also, your concern is not clear (to me). The contents of the down link relation will be what should be included in the down-tree due to recursion through the atom entri= es. Having a separate extension element, side-steps this issue of expression. Is this related to your concerns about duplication [1]. If so, let me s= ay that a server can choose to in-line where it finds the need to and not,= where it doesn't. In fact, it may be possible to get rid of the down-tr= ee relation, if the representation of "down" can be in-lined to a suitable= depth. That may actually be preferable anyway. Second example: verbosity This proposal now has: ... ... ... ... ... ... instead of a simpler mechanism: ... ... ... ... ... The I-D introduces a concept of hierarchy through up/up-tree/down-tree/down relations yet a all-purpose mechanism f= or inclusion. Most (all?) of the information on the feed element is duplicated on the enclosing entry (id, uri, etc). If verbosity is a concern, then the fact that we repeat the text "atom:entry" about 8 times in the above example is a valid target. Howe= ver, that is besides the point. Even if we were to take the "simpler mechani= sm", you would still have to put in id, title, updated, etc. because the definition of atom:entry requires those things. See Section 4.1.2 of RF= C 4287. BTW, link is not one of the required elements in a valid entry, s= o you could skip it in either case. Can't we do better for this specific scenario the I-D is addressi= ng? Yes, the server can avoid sending anything in the in-lined entry that i= s not required for being treated as valid Atom by RFC 4287. This is unrel= ated to the hierarchy I-D. Also, Are there reasons for the statements below? A resource may be involved in many different independent hierarchies - e.g., folder= structure, file plan, etc. Most of which we probably cannot imagi= ne right now, but may be used in a year or two. This also conflicts = with the current 'up' relation which, as not stated otherwise, allows multiple 'up' link relations in a single entry or feed. Section 4.1:[1] >An entry MUST NOT contain more than one atom:link element with a= rel attribute value of "down" that has the same combination of type a= nd >hreflang attribute values. RFC 4287 already defines a similar constraint for @rel=3D"alternate". R= FC 4287 provides two discriminators for link elements in addition to rel, = and processors use this to select one that is suitable for the purpose, and= these are type and hreflang. Since down defines a formal relation betwe= en the referrer and the referee, it is necessary to have a clear meaning f= or multiple occurrences of that relation. Therefore the text above. If you= can propose an alternate resolution of the issue I identified just now, I'l= l be interested in reviewing it. Section 4.2: >An entry MUST NOT contain more than one atom:link element with a= rel attribute value of "down-tree" that has the same combination of t= ype and >hreflang attribute values. Section 5.1: >A feed MUST NOT contain more than one atom:link element with a r= el attribute value of "up" that has the same combination of type and= hreflang >attribute values. Section 5.2: >An entry MUST NOT contain more than one atom:link element with a= rel attribute value of "up-tree" that has the same combination of typ= e and >hreflang attribute values. -Al [1] http://www.oracle.com/technology/tech/feeds/spec/draft-divilly-at= om-hierarchy.html Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/= Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use= of the person or entity to whom the message was addressed. If you ar= e not the intended recipient of this message, please be advised tha= t any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete a= ll copies of the original message and any attached documentation. "Nikunj R. Mehta" ---06/05/2009 11:18:07 AM---All th= e feedback on this mailing list has been really useful. We have rev= ised the I-D to reflect the thinking about in-lining i = = From: "Nikunj R. Mehta" = = = To: Atom-Syntax Syntax = = = Date: 06/05/2009 11:18 AM = = = Subject: Fwd: New Version Notification for = draft-divilly-atom-hierarchy-01 = = All the feedback on this mailing list has been really useful. We = have revised the I-D to reflect the thinking about in-lining inside atom:link using foreign markup. We've also made the use of in-lin= e representations independent of the the new link relations. Lookin= g forward to comments and implementation experience. 01 - Changes include: In-line representations of linked resourc= es are independent of hierarchy Removed Atom specific language in link relation definitions Made explicit that this specification re-= uses existing 'up' link relation Changed namespace prefix from ah to ae Removed the ah:count attribute and added = the ae:inline element Text: http://www.ietf.org/internet-drafts/draft-divilly-ato= m-hierarchy-01.txt HTML: http://www.oracle.com/technology/tech/feeds/spec/draf= t-divilly-atom-hierarchy.html Nikunj http://o-micron.blogspot.com Begin forwarded message: From: IETF I-D Submission Tool Date: June 5, 2009 10:06:45 AM PDT To: nikunj.mehta@oracle.com Cc: colm.divilly@oracle.com Subject: New Version Notification for draft-divilly-atom-hierarchy-01 A new version of I-D, draft-divilly-atom-hierarchy-01= .txt has been successfuly submitted by Nikunj Mehta and po= sted to the IETF repository. Filename: draft-divilly-atom-hierarchy Revision: 01 Title: Inlining and Hierarchy Extensions for Atom Creation_date: 2009-06-05 WG ID: Independent Submission Number_of_pages: 11 Abstract: This specification defines mechanisms for in-lining representations of linked resources and for hierarchical navigation a= mong Atom feeds and entries.Editorial Note To provide feedback on this Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1]. The IETF Secretariat. = --1__=07BBFF5CDFF9794B8f9e8a93df938690918c07BBFF5CDFF9794B Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable I withdraw the proposal/plea for a simpler, less verbose mechanism f= or expressing a hierarchy in atom in a single document. Since the grou= p finds value in a generic mechanism and would be useful as well for CM= IS in non-hierarchy use cases, I doubt it makes sense to standardize tw= o approaches for the same similar functionality. If it is not a huge cost, I would prefer the generic inlining mechanism= to be a separate I-D since it is only generically related to hierarchy= . >RFC 4287 already defines a similar constraint f= or @rel=3D"alternate". RFC 4287 provides two discriminators f= or link elements in addition to rel, and processors use >this to sel= ect one that is suitable for the purpose, and these are type and hrefla= ng. Since down defines a formal relation between the referrer and the r= eferee, it is >necessary to have a clear meaning for multiple occurr= ences of that relation. Therefore the text above. If you can propose an= alternate resolution of the issue I >identified just now, I'll be i= nterested in reviewing it. I don't actually see a need to resolve multiple occurrences of that = relation. Multiple relations of 'up' are multiple parents - feeds or e= ntries. Multiple relations of 'down' are multiple children. The clien= t can chose to follow none, one or all of those links. In most scenari= os, there will probably only be one up and one down link relation thoug= h. Changing MUST to SHOULD would be better, though omitting that state= ment entirely would be better. I see a problem with that restriction in RC4287 in exposing alternat= e renditions/transcodings of that resource specifically when the varian= ce happens inside the media type and is not language-specific such as = bit rate (low or high bandwidth video) or height and width (color vs b/= w, small, medium or large). It is one of the reasons why I prefer not = to state items in a specification unless there is clear reason to do so= . This is actually a problem for CMIS in leveraging alternate link rel= ation in exposing image representation of resources as there may be mor= e than one thumbnail of different sizes. Another use case is different = image representation of CAD drawings at different scale or orientation.= -Al Al Brown Emerging Standards and Industry Frameworks CMIS: ht= tps://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. "Niku= nj R. Mehta" ---06/08/2009 12:17:31 PM---On Jun 5, 2009, at 2:06 P= M, Al Brown wrote: The 01 draft is a much better. I am concerned the ge= neric mechanism using inlining = From: = "Nikunj R. Mehta" <nikunj.mehta@oracle.co= m> To: Al Brown/Costa Mesa/IBM@IBMUS Cc: Atom-Syntax Syntax <atom-syntax@imc.org><= /td> Date: = 06/08/2009 12:17 PM Subject: Re: New Version Notification for draft-divilly-atom-hi= erarchy-01 On Jun 5, 2009, at 2:06 PM, Al Brown wrote: = The 01 draft is a much better. I am concerned the = generic mechanism using inlining links is sub-optimal for displaying a = hierarchy that this I-D helps navigate via the new link relations. I read "displaying" as conveying, since Atom= format is all about a representation, and not a rendering. First example: there are two down relations: down and down-tree. It is = important to have both of those link relations on the [standalone] atom= entry that represents a folder so the client can chose a flat (feed) o= r tree (expanded feed) representation. With you so far. If the client chooses the tree representation, the= n on the atom feed returned the server will inline using the link relat= ion down. down-tree is not expanded with content inline. E.g., <= /ul> When producing an entry representation, e.g., for a fo= lder, the server may go one level deep by in-lining the "down"= ; relation but not in-lining the entries in the already in-lined link. = Or it can choose to arbitrarily in-line linked resources. The communica= tion between the client and the server about what representation is des= irable may either be out of band, or be a part of the request (either t= hrough query parameters or custom headers) <atom:entry> ...  <atom:link rel=3D"down" type=3D"application/atom+xml;= type=3Dfeed" href=3D"/finance/feeds/default/portfolios/1/positions"> <ae:inline> <atom:feed>  <atom:entry> ...  <atom:link rel=3D"down" href=3D"/finance/feeds/default/portfolios/1/positions"/> ... <ae:inline> <atom:feed>  <atom:entry> ... <atom:link rel=3D"down" href=3D"/finance/feeds/default/portfolios/1/positions/down"&g= t;  </atom:link> <atom:link rel=3D"down-tree" href=3D"/finance/feeds-tree/default/portfolios/1/positions/down&qu= ot; /> ... </atom:entry> </atom:feed> </ae:inline> <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> </atom:feed> </ae:inline> </atom:link> <atom:link rel=3D"down-tree" type=3D"application/atom= +xml;type=3Dfeed" href=3D"/finance/feeds-tree/default/portfolios/1/positions" /= > ... </atom:entry> I can't make sense of this example since it appears to= be not well-formed XML (omitting ellipsis). Can you, perhaps, retry wi= th a well-formed example? Also, your concern is not clear (to me). The contents of the down link relation will be what should be included = in the down-tree due to recursion through the atom entries. Having a se= parate extension element, side-steps this issue of expression. Is this related to your concerns about duplication [1]= . If so, let me say that a server can choose to in-line where it finds = the need to and not, where it doesn't. In fact, it may be possible to g= et rid of the down-tree relation, if the representation of "down&q= uot; can be in-lined to a suitable depth. That may actually be preferab= le anyway. Second example: verbosity This proposal now has: = <atom:entry> ... <atom:link rel=3D"down" type=3D"application/atom+xml;= type=3Dfeed" href=3D"/finance/feeds/default/portfolios/1/positions"> <ae:inline> <atom:feed> <atom:link rel=3D"self" href=3D"/finance/feeds/default/portfolios/1/positions"/> ... <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> </atom:feed> </ae:inline> </atom:link> ... </atom:entry> instead of a simpler mechanism: <atom:entry> ... <ah:include rel=3D"down"> <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> </ah:include> ... </atom:entry> The I-D introduces a concept of hierarchy through up/up-tree/down-tree/= down relations yet a all-purpose mechanism for inclusion. Most (all?) o= f the information on the feed element is duplicated on the enclosing en= try (id, uri, etc). If verbosity is a concern, then the fact that we repea= t the text "atom:entry" about 8 times in the above example is= a valid target. However, that is besides the point. Even if we were to= take the "simpler mechanism", you would still have to put in= id, title, updated, etc. because the definition of atom:entry requires= those things. See Section 4.1.2 of RFC 4287. BTW, link is not one of t= he required elements in a valid entry, so you could skip it in either c= ase. Can't we do better for this s= pecific scenario the I-D is addressing? Yes, the server can avoid sending anything in the in-l= ined entry that is not required for being treated as valid Atom by RFC = 4287. This is unrelated to the hierarchy I-D. Also, Are there reasons for the statements below? A resource may be involved = in many different independent hierarchies - e.g., folder structure, fil= e plan, etc. Most of which we probably cannot imagine right now, but ma= y be used in a year or two. This also conflicts with the current 'up' r= elation which, as not stated otherwise, allows multiple 'up' link relat= ions in a single entry or feed. Section 4.1:[1] >An entry MUST NOT contain more than one atom:link element with a re= l attribute value of "down" that has the same combination of = type and >hreflang attribute values. = RFC 4287 already defines a similar constraint for @rel= =3D"alternate". RFC 4287 provides two discriminators for link= elements in addition to rel, and processors use this to select one tha= t is suitable for the purpose, and these are type and hreflang. Since d= own defines a formal relation between the referrer and the referee, it = is necessary to have a clear meaning for multiple occurrences of that r= elation. Therefore the text above. If you can propose an alternate reso= lution of the issue I identified just now, I'll be interested in review= ing it. Section 4.2: >An entry MUST NOT contain more than one atom:link element with a re= l attribute value of "down-tree" that has the same combinatio= n of type and >hreflang attribute values. Section 5.1: >A feed MUST NOT contain more than one atom:link element with a rel = attribute value of "up" that has the same combination of type= and hreflang >attribute values. Section 5.2: >An entry MUST NOT contain more than one atom:link element with a re= l attribute value of "up-tree" that has the same combination = of type and >hreflang attribute values. -Al [1] http://www.oracle.com/technology/tech/feeds/spec/draft-divilly-atom-h= ierarchy.html <= br> Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki0= 7/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.= ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. <graycol.gif>"Niku= nj R. Mehta" ---06/05/2009 11:18:07 AM---All the feedback on this = mailing list has been really useful. We have revised the I-D to reflect= the thinking about in-lining i = <= /tr> <ecblank.gif&g= t; From: <ecblank.gif>= "Nikunj R. Mehta" <nikunj.mehta@oracle.com&g= t; <ecblank.gif&g= t; To: <ecblank.gif> Atom-Syntax Syntax <atom-syntax@imc.org> <ecblank.gif&g= t; Date: <ecblank.gif>= 06/05/2009 11:18 AM <ecblank.gif&g= t; Subject: <ecblank.gif&= gt; Fwd: New Version Notification for draft-divilly-atom-hierarchy-01 <= br> All the feedback on this mailing list has been really useful. We have r= evised the I-D to reflect the thinking about in-lining inside atom:link= using foreign markup. We've also made the use of in-line representatio= ns independent of the the new link relations. Looking forward to commen= ts and implementation experience. 01 - Changes include: In-line representations of linked= resources are independent of hierarchy Removed Atom specific language in link relation definitions Made explicit that this specification re-uses existing 'up' link relati= on Changed namespace prefix from ah to ae Removed the ah:count attribute and added the ae:inline element Text: http://www.ietf.org/interne= t-drafts/draft-divilly-atom-hierarchy-01.txt HTML: http://www.oracle.com/technology/tech/feeds/spec/d= raft-divilly-atom-hierarchy.html Nikunj http://o-micron.blogspot.com Begin forwarded message: From: IETF I-D Subm= ission Tool <idsubmission@ietf.org> Date: June 5, 2009 10:06:45 AM PDT To: nikunj.mehta@oracle.com Cc: colm.divilly@oracle.com Subject: New Version Notification for draft-divilly-atom-hierarchy-01 <= /font> A new version of I-D, draft-divilly-atom-hierarchy-01.txt has been succ= essfuly submitted by Nikunj Mehta and posted to the IETF repository. Filename: draft-divilly-atom-hierarchy Revision: 01 Title: Inlining and Hierarchy Extensions for Atom Creation_date: 2009-06-05 WG ID: Independent Submission Number_of_pages: 11 Abstract: This specification defines mechanisms for in-lining representations = of linked resources and for hierarchical navigation among Atom feeds and entries.Editorial Note To provide feedback on this Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/<= /u>) [1]. The IETF Secretariat. = --1__=07BBFF5CDFF9794B8f9e8a93df938690918c07BBFF5CDFF9794B-- --0__=07BBFF5CDFF9794B8f9e8a93df938690918c07BBFF5CDFF9794B Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBFF5CDFF9794B8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBFF5CDFF9794B8f9e8a93df938690918c07BBFF5CDFF9794B Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=07BBFF5CDFF9794B8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBFF5CDFF9794B8f9e8a93df938690918c07BBFF5CDFF9794B-- From owner-atom-syntax@mail.imc.org Mon Jun 8 13:07:11 2009 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 6ECB53A6A58 for ; Mon, 8 Jun 2009 13:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.176 X-Spam-Level: X-Spam-Status: No, score=-0.176 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_35=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 jixOelWgBKMx for ; Mon, 8 Jun 2009 13:07:10 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1DAC93A6A1E for ; Mon, 8 Jun 2009 13:07:09 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58JtJ3I019474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 12:55:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58JtJXa019473; Mon, 8 Jun 2009 12:55: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 mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58Jt774019453 for ; Mon, 8 Jun 2009 12:55:18 -0700 (MST) (envelope-from hadrien.gardeur@feedbooks.com) Received: by fxm25 with SMTP id 25so3279977fxm.10 for ; Mon, 08 Jun 2009 12:55:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.164.142 with SMTP id t14mr590773hbd.75.1244490906114; Mon, 08 Jun 2009 12:55:06 -0700 (PDT) In-Reply-To: <4A2D5EDC.1020207@gmail.com> References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> From: Hadrien Gardeur Date: Mon, 8 Jun 2009 21:54:46 +0200 Message-ID: <404dcbd20906081254u68cbeda1v233b01bc1593a894@mail.gmail.com> Subject: Re: Fwd: New Version Notification for draft-divilly-atom-hierarchy-01 To: James M Snell Cc: Al Brown , "Nikunj R. Mehta" , Atom-Syntax Syntax , owner-atom-syntax@mail.imc.org Content-Type: multipart/alternative; boundary=001485f62850629b22046bdb9e9d Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001485f62850629b22046bdb9e9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit James, Hmmm.... I know we've discussed this, but after thinking about it more and > looking through the examples, I'm becoming increasingly less convinced that > we need a distinction between "down" and "down-tree". One should simply > assume that "down" could point to a child entry or child feed and that those > children could potentially also be parents. Yes, that possibly increases the > processing compexity but I think it simplifies the model overall. I agree, and I've implemented hierarchy using strictly link@rel="down" instead of "down-tree" for the same reason. > I think we can address this by eliminating the restriction that "down" and > "up" must always point to Atom feed documents and by changing the > cardinality rules for those links. That restriction, I think, is arbitrary > and unnecessary I agree about the type: it could be useful to use a "down" link on something else than a feed. Not sure about cardinality though, moving from a tree model to a graph model really make things more complex (more flexible and powerful too). > Unlike any of the other methods discussed, this approach would allow > clients that don't understand the hierarchy model to still understand that > there is some kind of link relationship with each of the individual child > resources and eliminates the need to include the extraneous atom:feed > metadata. > > Note that this is the same basic approach taken by my comment thread > extension (in-reply-to). > The hierarchy I-D used to have ah:count to indicate the number of entries in the child feed. Now that Nikunj removed ah:count from the draft, do you believe that thr:count from your Atom threading extension could be used on link@type="application/atom+xml;type=feed" for hierarchy ? Hadrien --001485f62850629b22046bdb9e9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable James, Hm= mm.... I know we've discussed this, but after thinking about it more an= d looking through the examples, I'm becoming increasingly less convince= d that we need a distinction between "down" and "down-tree&q= uot;. =C2=A0One should simply assume that "down" could point to a= child entry or child feed and that those children could potentially also b= e parents. Yes, that possibly increases the processing compexity but I thin= k it simplifies the model overall. I agree, and I've implemented hierarchy using stric= tly link@rel=3D"down" instead of "down-tree" for the sa= me reason. =C2=A0=C2=A0 I think we can address this by eliminating the restriction that "down&= quot; and "up" must always point to Atom feed documents and by ch= anging the cardinality rules for those links. That restriction, I think, is= arbitrary and unnecessary I agree about the type: it could be useful to use a &qu= ot;down" link on something else than a feed. Not sure about = cardinality though, moving from a tree model to a graph model really make t= hings more complex (more flexible and powerful too). =C2=A0 Unlike any of the other me= thods discussed, this approach would allow clients that don't understan= d the hierarchy model to still understand that there is some kind of link r= elationship with each of the individual child resources and eliminates the = need to include the extraneous atom:feed metadata. Note that this is the same basic approach taken by my comment thread extens= ion (in-reply-to). The hierarchy I-D used to have ah:= count to indicate the number of entries in the child feed. Now that Nikunj = removed ah:count from the draft, do you believe that thr:count from your At= om threading extension could be used on link@type=3D"application/atom+= xml;type=3Dfeed" for hierarchy ? Hadrien --001485f62850629b22046bdb9e9d-- From owner-atom-syntax@mail.imc.org Mon Jun 8 13:13:06 2009 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 583B53A6A1E for ; Mon, 8 Jun 2009 13:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2I5fNJrG9TJ for ; Mon, 8 Jun 2009 13:12:59 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0A3063A6B5F for ; Mon, 8 Jun 2009 13:12:58 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58JxFp2019635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 12:59:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58JxEcc019634; Mon, 8 Jun 2009 12:59: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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.149]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58Jx3Hg019620 for ; Mon, 8 Jun 2009 12:59:14 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qw-out-1920.google.com with SMTP id 14so2539167qwa.28 for ; Mon, 08 Jun 2009 12:59:03 -0700 (PDT) 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:content-type :content-transfer-encoding; bh=8zo+DB1NZGE6x+Ii5HP/4SNpdeB2JDVkSDkCIyj7cyI=; b=QXPzIH7K/HAMufNg/9O04Am+x2ytHGZoXXUAJxabJsr/PMiYChbq3gkD49ucPSOpYc sw/W9WjbRJobC4sTZ7qziJBRGY12uKhqYqB+cRCznjo5K7SbGD4zKYgNcEVmVIrFkas7 bT90SyN5ZMwFNT/Lz7msc8HdHOV+j22DtHPqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=IhYhvAXU4BB8AIfdSHKolxYFOj96CrnlRBodmjD1PVtw4lT1Js98dlLl8qMZHsyNAU 9K59G0OzD5GtRbDZrc2iY34yBKy20zT1VlFRWGPk4RIdy0fwSd7tgImtOGCy1vPoUJRa tXTfp6NHgOXvSQfAMKnEJ2PgVixMCXKHOvMvk= Received: by 10.224.28.207 with SMTP id n15mr7229722qac.95.1244491143593; Mon, 08 Jun 2009 12:59:03 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 7sm101471qwf.59.2009.06.08.12.59.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 12:59:03 -0700 (PDT) Message-ID: <4A2D6DBE.4000504@gmail.com> Date: Mon, 08 Jun 2009 12:59:58 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: atom-syntax Subject: Atom bidi draft revitalized 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: I just posted an updated version of the Atom Bidi Draft, mainly to get it out of the Expired state. I've changed it to "Informational" from "Experimental" and updated the IPR per the current boilerplate guidelines. I also added an explicit statement indicating that the dir attribute will be treated as unknown foreign markup by existing Atom processors that do not implement support for the dir attribute. I would like to go ahead and get this wrapped up and published as an Informational RFC. Support for the attribute has been implemented in Apache Abdera and the attribute is being used in at least one commercial product (IBM's Lotus Connections Blogs component). Current draft at: http://www.ietf.org/internet-drafts/draft-snell-atompub-bidi-07.txt - James From etz@delta.com Mon Jun 8 13:15:58 2009 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 412D128C12C for ; Mon, 8 Jun 2009 13:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.573 X-Spam-Level: X-Spam-Status: No, score=-8.573 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=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_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_HTML_IMG_ONLY=1.666, SARE_RECV_VIRTUACOMBR=1.193, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 G22TrKWnb-3O for ; Mon, 8 Jun 2009 13:15:51 -0700 (PDT) Received: from c9157ed3.virtua.com.br (c9157ed3.virtua.com.br [201.21.126.211]) by core3.amsl.com (Postfix) with ESMTP id 065D228C152 for ; Mon, 8 Jun 2009 13:15:49 -0700 (PDT) Received: from [192.168.181.90] (port=36741 helo=[127.0.0.1]) by smtp4.delta.com with asmtp id 06fb0df775a for atompub-archive@lists.ietf.org; Mon, 08 Jun 2009 20:15:30 +0000 Message-ID: <474F8E9F.3EF47DF@delta.com> Date: Mon, 08 Jun 2009 20:15:15 +0000 From: Marlon User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: Hello Content-Type: multipart/alternative; boundary="------------040303020804000903746940" X-Spam: Not detected X-Mras: Ok This is a multi-part message in MIME format. --------------040303020804000903746940 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit just answer today please mandy that is it --------------040303020804000903746940 Content-Type: multipart/related; boundary="------------030600040002070905194647" --------------030600040002070905194647 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit just answer today please mandy that is it --------------030600040002070905194647 Content-Type: image/jpeg; name="lio8.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="lio8.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkS Ew8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJ CQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjL/wAARCADqARUDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEA AAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIh MUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6 Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx 8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAV YnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPE xcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDi QFpkm0Cq4mOKikmJFJszK12Qc1mlctV2Uk1HFC0rYAqGy0S20QyK14Ixim2+mHyl PcinKxiYo3UUKSBpovLEuOlSCBfSiG2uZI9wiOMZzV63tgFMkwaQekZGPxbpT50N RkyoIF9BQywRAlyAByfamXt7bWu4g5PZd3H59+9Y4nvJvnht5JpWztCsoVT75NS6 nYpU31N0/ZRKkRmi8xxkR7hu/EdqkaBMdK5ez0DxDBPHeSQhtjbgjSqctnPIz3rr Lme0a1t7m0mysw+eB/vwuOqn/GtVsRLQzrqFQDisK5jGTWxcXAIrKl+Y1m7DTM9Y ctW1YWwOMiqsUXzVs2a4xVRCR9C/DhdngLTF9PN/9GvXU1zHw8/5EXTf+2v/AKNe unqgQUUUUAFFFQPdRI5TduYdVXkj60WuJtLcnoqt9rTdgo/1xUizxscBxk9jwadm CkmS0UlUdQ1a105R5z5kP3Y15J/wrKpVhSjzzdkXGLk7RRformD4nlkb5I441/2s sf6Vbt9cMhG54SfQgp/jXnxzjCSlZS/r8zZ4WqlqjcoqCG5SbjlXxnaf6etTivSh OM1eLMGmtwoooqhBRRRQAUUUUAfH2zioJFq6V4qB1y2M1LRmtSgw9qvWYQKCcZpv kqDk1LtVRnGK55z7HZTpWJVmuIpNo5HUVbtma8uC7RR8YGTUMSgxY25OMirUbFIh swWPPTBzWSd2bSikjRQrBCQxLyj7u7kD3IrP1LWplilhe5FwWGUQIRt9jg9OPbNN laYQlgCSOgJAzVUBX226jcxO6Vv7x/yPyrRGTZRs7dtQunmckgc7SOAc46enoPwr otPihin+UxoxPJLBpOvp27f55pFtYobTI+U889l/xPH+e2FNfzWRZvNLKThTtALf UjtRuxXOo1K8cr9nsUVp0Qu27hYlHc/4d6zUbSf7Pjit5bh7m6bzfMnA4foRkADB 4IHPTOea5lPEFzo+oOcl5Fkw49cZHX+X411Fztu41uhEE8776f3WGM49jkGtm3ax k1FK71MyUHkGohESavTbppWd+WYkk46mnQ2+T0pJGSdiGC3JPStOCDFSQ2+O1X44 cCtoRCUj2v4fDb4G04f9df8A0a9dNXOeAxjwXp4/66f+jGro6b3GtgpDS1mazfC0 hWNX2yS55z0UdT/IfjRGLk7IU5KKuwur0yM0UL7UU4eQdT7L/jVBruKBNiYAHasW 61dI02oQEUYHoBWNcaupwd+QzbcjkZrup4d2PLq4tJnUyaoo/iFQnV/9riuQkv5W LBdo6qpY8lh7elQG4nlXZ5j7iwK7RtOMfyzW6w6OV4uR3P8Awkr20TEYc4wqnsa5 9ppLiZpZXLyOcsx71mxSu5HmDDA8irKeYFUdwfmPWvz3iKrKpi3Rj8MdPna7f6H2 eUQthVUlvL8jQjGasKvFVIJPnK44HOfariuPl6gt0r5icWjuky3a3rwOquxMeePV T6iustLgXEIbI3DhsVxJINbfhuctJLCegUH9f/r17+Q46cayoS2Zw4qknDnXQ6Oi iivtDzAooooAKKKKAPkh8LHk9Kwbi7P2lgDwDWnqJO3bmuek3Fvm/Sok0xwhY3LM SyrlDn1B6itPanklZAAR6dq5m2vmt+jHAq+Lua6Xc/yx+/Ga5ZQZ1xkXEuzllALA cZFS214jdRzxkE1iNM5ZjHJiPsSOtOsmee1aVsnYeD0PWhQtqDlfQ6gXBk49eKdH Cv2veMfdAz14z/OqcEgMoyOpwK2IBgH5eR09cVSdzOSsMu4j5G3blc4OT17c1x2q j/T4LeR8Rs3UjgCvQGAeNlfqfT0rjPEMCNtnZc+RL8w/vL7VpBGbkc1f6fcJdzoI iwiTezLyAueufTmuz0q8S/06J1+8oCOPQgVn2l88EUTgCaCMjDDnbnkAn8OhrSst I8qS2uNL2CF12SxO+N5yTnJ6EfyxWu+g50m1dF1IC3QZxVyCD2q7ZQeVA1wrqUZD Cy7hkORyhGeowfrjNJFjFOFmYSg4ixxACpgMUm4DpShsiuhJGTuezeBf+RNsP+2n /oxq6Kud8C/8ibYf9tP/AEY1dFWL3NlsFcF46upbbU4eoR4MKe2Qxz/Su9rM1zRb bXLE21xlSPmjkXqjeo/wrWhNQmnLYxxNOVSm4x3PJWf7RkggORg7jwR/jT2MbFiz ZUknavHXqKl1bwtq+jOxaEzwDpNEMjHuOoqvpFq17MTKCIk6+9eliMTRoUXWk9F2 /I8OlhK9WqqSWr/q5PDE8zDyIWZugY5OffHTPvU76VqhjwsJ24+6DgV0MDRwxhI1 CqOwqykue9fLyz/ESleKSX3/AI/8MfQxyKhGNptt/d+BxkMF1bSFbi3kj54JFXUe ur3BlwwBB7HmqNxpVvNlo/3T+3T8q+fzGjPFVpV1a76HuYNww9KNHWyMqOUjAJyP Srkc49eelUbm3ms5AkykZ5DDofpUYlPrivDnCUXZ6M7XFSV0ahxsKo+Pc1u+FY2a a4nI+UKEz79T/SuWtVnvLhLe3QvIx4Hp7n2r0XTLFNOsUt1OSOWb+83c17WSYWdX EKs1pH8zz8bJU4cnVlwUUUV9keQFFFFABRRRQB8h6hF3UfpWU9uGyQAT6HitG6vQ ITxkngVVSQuueK5WdWlzK8giTDqeelWTJ5siQkkICOPX61PPEWwVU7hyCDVaQTLk vBz7GhO4muwlzOx1GOGBQY1BRlPRgetbNpiOJYQoCKemPvGsC2km+3R7olUE85OT W6rbCWHqcVM+iHBbs09gAVu2RjFX4MKyo5Ow4BI64rF+0EzQoTwGH5YrWtHzGhPc EkfjUxumOWqNGO4iWQA42k4/CsTxBHE1sGK5Bq7NEOSoOM5+lYF9fM21ApJyRit1 I53E5eSCa2nJhZtn8LKecehqw2u6vHNuNw6zAYL4G78zzWpDZyyzLMDtI54Ga6qO C2uIVE1tDIAAAGQHFWp9GFmtjlIddurpYLKygkYl9zgHO5sEDt755/Gu8KvCTE5y 68MR3PenWNpZWai5MKJsGVTFVpLoPKzn+Ik0SlZJIqC5m2yVnIpBMwFRCUGkLCpV VmnsYs91+H7bvBGnH/rp/wCjGrpa5j4eHPgXTf8Atr/6NeunrVO6uc7VnYKKKKYh K871q4X+3bsAKuHxgDHQV6JXmnjCCSx115cHy5sOD/OvJzhSdFW7/od2At7Rp9hi yuzqocquMkjqfYVYS4dJAnmLj72WHRR159ax4LoMoBAI9D2q2rROrKcjdgHHt04r 5tVbHpygbC3UZQurqwAzwadHdRybNrcsNwU8HHrissr5hYllbew3nodo/hFK00se 5uQWbIBGQFHYH1PpW0a7MnTNdmiliMM6B4j1XuPcehqCw8Kx3d06vqLiMfMiKgBZ fXJ/I8VXWYhBvYE45OMVNbakbWdJFblWyM/r+YrWFSjOadWN0K1SMWqbsdlp2lWe mQ7LWILn7zHlm+pq7SKQVBHelr62EIwjyxVkeLKTk7yd2FFFFUIKKKKACiiigD4t vMYAzwP1pIs4HJFQPJvG7OM9qntpB5J/zmuY3JUlck/NtA71LhTx1P8AM1SMh83J JAHNPFyI4Sw+8eF9qlxKTGyJtlEinoev0q5BMJ49ucHmoBhoVAPb9aruWtnWRfXB FK1x3NOViuGHpWlpd4JGwf4ePwNYIvVkYA8HFEV0bS6WUfd6MKOUTkdcs+JWU9wC Pr/+v+dZt5bxPJvQDB6D0yKrxX67huP0PtU0sgkxtzuHcU1cTEjKxHuPapDdMvKn FN2lxk8mjyeKozuOkvpZcZJ4GKb9oY96QQjNL5YFAJkqXDetOa5IFVzgdKjfpQac +h9G/DFy/wAPNKY9T5v/AKNeuurj/hac/DjST/12/wDRz12FdEdjB6sKKKKYgrL1 zRYNbsjBL8sg5jfH3T/hWpRUThGpFxktGVGTi+ZbnjOp6LqmhysJ4HMIPEqDKn8a qRajjAJr3BlDAhgCD1BFYt54T0O/YtNp8QY9Wjyh/SvEr5Pd3pv7z0qeYraovuPM 01JfXFSDVNo4fH0Ndo3w50Rmyr3iD0WUY/UVPB4B0GFgWhmm9pJT/TFcv9jVr9Pv NXjqPmefPqpZtqAsxPAHJNdJ4e8O6lfXUdzfxNb2iMG2Pw746DHYfWu3sdG03Tv+ POyhhP8AeVBn8+tXq7sPlEYPmqO/kc1XH3VoKwg6UtFFe0eeFFFFABRRRQAUUUUA fH6eC/FJ4bw1rAGf+fGX/wCJqWPwT4nDceHdXAPY2Mn/AMTX13RWfs0XznyDN4K8 UDOPDesEe1jL/wDE1UPgrxYBj/hGtZJJ/wCfCX/4mvsminyC5j49Twh4sBH/ABTO s4/68Jf/AImn3Pg/xS8Py+GdZzu6fYJf/ia+v6KORD52fGsngvxXgMvhjWsnkD7B Lx/47QPB/i5lAPhfWgf+vCX/AOJr7Kop8guY+PY/BvizGP8AhHNaGOmbGX/4mtS2 8J+KFxu8P6sOx/0KT/4mvq6ik4JiufL6eFvEY/5gGq/+Acn+FOPhfxF/0ANU/wDA OT/Cvp6ip9khHy+fC/iT/oAar/4Byf4U0+FvEn/QA1X/AMA5P8K+oqKPZID5bPhT xH/0L+q/+Acn+FNPhTxJ/wBC/qv/AIBSf4V9TUU/ZoDlfhvaXNh4B0y2u7eW3nTz d0UyFGXMrkZB5HBBrqqKKtKyAKKKKYBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFMmlSCGSaVgscalmY9AAMk0+uT8fG4vtHh8PWMpiu9ZmFt5gXd5cQG6 VyO42Aj/AIEOlJuyuXThzyUTO8H+JNZvdZRdZlU2ms2zX2lp5aqYUV8eWSPvHY0b Z5710Gt+M/Dvh26itdW1WG2nkxtjIZiAehIUHaOOpwK43WfDPirR7W01ubxR/aia I63KWaaZHCWjAxIoZTn/AFZYY/8A10eJNQ0vSvEsuq2urX+k3eoQwESvYm5s78YI VcKC27bx1Xt1rLmaWp2ujTqTTjqn2vuvlfbyOh1TxBcf8Jn4OttOvUfTdUW7ebyw rLMEiDIQ2MjBOeCM10Vhqllqn2j7FOJlt5TDI6qdu8dQGxhsd8ZweOteU6na3niG 4+H9sbY+Hbm6t9RURWqhPIHlDG0Y+UMOcdQG9ea7f4e3zTeGU024gS2v9Kc2V1Ci 7QGXowGBwww2RxyaqMm3/XZEV6MY001uv/kpa+fY6G21K0vDdCCYMbWUxTggqUYA HBz7EHPQg1mXXjLw/ZaHb61dalHDYXI3QyOjAyD2TG4/lXNfEGS80VpJ9PU51+Ia UdrYK3LcRSe3ymQEjnhPSl1VLbwf4s0jVL5ZF0C10lrGN0gaRbaUOp3EKCRuUYzj tQ5NEwoRaT77L03X37HTyeLNCj8OP4g/tGNtKTAa4jVnAJYKAQoJzkgYx3q5davY 2eqWGm3E+y8v/M+zR7GPmbF3PyBgYB7kV5brGnXuu+EfHeoabbT/AGDUpbaWygaE oziLZ5sgUjPzbfTnbWpc+ItP8SfEnwRc6YZpLdDfqZZIXjBbyRlRuAJIxzjjmlzv +vUv6rHdX638rRuvxuvkddp3jPw7qtrJc2eqRPBHAbiR2VkCRhiuW3AY5U9fT0pd E8ZeHfEdzLb6TqkNzPHndGAytgdSAwGRyORkVxXhCwsr74Bx297aXVzbyxTtLFZq DM2J3IKA8FhtBH071L4V1433iy0tLS4PiC0jSZXv7mwaG407Cj5GcqA244GAAfXN Cm9L9QnhoLn5b+63+Hy/y8rnX3PjXw3Z6yukXGs2sd8Tt8ot90+hboDz0JBrOvfE c+n/ABHuLK6uvL0a38PtqEqeWDtdZsF8gbj8o6D8s15l5Op2Om3nhnVPFV3b3VxL OraZHoCztdFmJ3JLwG3A7s7htz1GK7vS4Zrb4t2UFxM008fhREkldQrOwnAJIBIB J5wCaSm2XLD06abvfR/8Orpfr6i/DTxTeeLlv7+61iOZhjdpiWmwWWWYL+9/5abg ufb2rstZn+zaHqFx9s+xeVbSP9q8rzPIwpO/Z/FjrjvjFcT8NNXsdI+F/hv7dP5X 2y5ktIPkZt8rzSbV4BxnB5PFdT4y/wCRG8Qf9g25/wDRTVUX7hjXivrDSVle33O3 b+utzifFnj1tLg8N6bb+JEtnvrRbm51hrAyER7PkcQ4x+8YNx/D6CvRbi+g0y2tz f3ABkkSASlCA0jcDOPu5PrxyBXnVn/yGPhJ/2DZ//SRK9F1XTodW0q5sJ8iOeMpu U4KnswPYg4I9xRC7ux11CPJG3e+3drt5Cy6laQanbadJLi7uUeSKMKTlUxuJIGBj cOuM5rLtvG3hq81o6Pb6xbSX4bb5QJwW9A2NpPHQGuT8PnVPFVz4hvZiINRs7A6J HIDlVuVDGV1HYFimO5AGelZc2oW2p+BdN8Gadb3MPiWAWqNEbR1NtJG6F5SxG3Hy sc55pOb3KjhY35Xvpfyv19D1G11exvNUv9Nt5995YeX9pj2MPL3ruTkjByB2JpNK 1mw1zSYtU06fz7OUMUkCMudpKnggHqD2ri4NTg8NfE7xIdQjuA2sLZmwWKB5PPKR srKCAQDn1xxzV34Rf8kv0f8A7b/+jpKpSu7epnUoKNPnX938U2/xR0EXifRptEt9 ZjvkbT7l1jim2thmZ9gGMZHzccjjvUl1r+lWOotYXV7HDcpam8dXyAkIbaXLdAM8 cmvPToD6trmpeCriCRdMtXuNQjlGApE64iGP9l3mI44KLUVtdapq3g3xH4luNFjv NQaCGySzuIlkVvIx5j7TndiRpGA/2B3qedmn1aHR/wBPb8Ltnd6L408O+IryWz0r VYbm4iyWjAZSQOpG4DcPcZFVrX4i+EryWzig1uAyXmfJVlZSfm24OQNpz0zjPauB 0y/t9R+IfhC+tta1PV7VTcxNdXNp5MKO0LAImEUZODkc9BVVI0j/AGZDKihZC4fe Bg7heYzn1wMUvaP+vkaPB000nfVpel7rt5dkd1pHxBsdS+IGreGmmjUwOsNmBG+6 aRVcz5OMDaVwM4zjgnNHiz4g2PhXxTo2mXk0cVtcJJNeStG7NFHtIj2hRzucEd8Y 6DOag0S6isPi54ptLrfFNqaWklmChxMscJDkHGOCe9Hje6i0vxx4M1e83x2Fs93H NOELBGkjVUBwD1PFO75d+v6kKnT9sly6OP3vl6ad/wAfuN/V/Gfh3Qb6Oy1PVoLa 5kwRG2SQD0LYB2j3OK20dJI1kjZXRgCrKcgg9wa85tdZsPCWreI7TxFHO9zqWoPc WpW0eQXMLIoSNSoIyuCuD6V0vgLTr7SvA2k2OpbvtcUOHVuqAklVP0BA/CqjJt2M atGMIKS8vn6ehhaH8QLK0k1qPxJrMMTx65c2dorqAREm3aDtHQZPzN+ddnf6xpum ab/aN7ewQWeARM7jac9MHvntivM/DfiHRtAl8XDU7aZpLvX7yOPy7VpftBGD5QKg 88k4OOv1qvf6H4g0vwX4LklvprM6Y0jXcq2QuWt96nyyY++wHZ7Zz2qFNpHRPDQl Pt+unTT5ddz07RPEGk+I7M3WkX0V1CDhimQVPoVOCPxFadeb/D4T6j4kv9bHiK41 m3ltFga4OlLZxSMHJXByCzL8wPy/xdeMV6RWkHdXOSvTVObiv6/BfkFFFFUYhVHU LG4vfL+z6teWGzO77MkLb846+ZG/THbHU9eKvVm63qr6PYC4i0+7v5XkWNILWPcx J7k9FUd2OAKT2KhdyVit/Yeo/wDQ16x/36tP/jFH9h6j/wBDXrH/AH6tP/jFUPDn jGXV9Zn0XUtKOmapFB9p8kXKXCtHu253pwDkjg881T+I/wDzKX/YyWf/ALPU3Vro 6FCftFCVl8kzb/sPUf8Aoa9Y/wC/Vp/8Yo/sPUf+hr1j/v1af/GKn8TSwQeFNYlu rf7TbpYzNLBvKeagQkruHIyOMjpmsCHxStj4f0C00TQ5bu9u9Ojnt9OjuABDCEX7 0r9hkLk8mh2TJipzV0l9yJbnwZf3+qwXV94r1KaG0cS2kYt7ZWikwQWY+XtbgnHy jFaf9h6j/wBDXrH/AH6tP/jFY998QFsfCWq6vJpUqX2lyRxXWnSyhWRnZQPnAIIw 4IIHNWrDxhcTeI7fSNS0O5037akj2EssyP54QAtlVOUODnBpXiW41mrtKy9Omv63 /Evf2HqP/Q16x/36tP8A4xR/Yeo/9DXrH/fq0/8AjFUfGt1Y23/CO/btO+2+brdt HB+/aPyJTu2y8fexz8p4Oayn+It9s1ia38L3Nxa6Rez293PHdIAscXVwGwSe+0dB 3obSdn+oowqTipRS+5HR/wBh6j/0Nesf9+rT/wCMUf2HqP8A0Nesf9+rT/4xWjBe re6VHf2KiZZ4BNAGbaHDLlcnnGcjnmsSfxfGnhuw1SG1Mk97cRWqWjSbWWVn2uhI B5TDk8fwmqdkQvaS0SXbZFr+w9R/6GvWP+/Vp/8AGKP7D1H/AKGvWP8Av1af/GKz tQ8YXqaldW2jeHrnVobF/LvJ4544xG20MVUMcuwBGQMdalHjO1n1TwxbWUBnttej nkjnL7TEI0D8rg5JzjqMY70rxK5Ktr2X3Ltf8ia48M3V2ipP4n1eRFkSQKYrTG5W DKf9R2IB+oFTf2HqP/Q16x/36tP/AIxWJrfxC/sb/hKv+JX539g/ZP8Al42+f5+P 9k7duffPtXVaZd3N7ama6sWs2LsEjeQOxTPyscdMjnHahcrdkKSqxipSSt8uyf5N FD+w9R/6GvWP+/Vp/wDGKhutA1l7Z1tPGGpxTkfI8trayKD7qIlJ/MVxvhXXNR0u bxTHp/h+61QDxFeSTtFKkYjT5em4/O3H3R+fTPYXPjCzXRtMv9Pt57+XVMCytosK 8h2ljkscLgA5JPGKSaaNJ06kJWST+S/Ht8yLS/B0+kWZt7XxNq6B5GmkIjtTvkY5 ZstCTyT3Jq7/AGHqP/Q16x/36tP/AIxUWi+JnvnurXVdNl0nULSJZ5reWVZF8s5w 6uvDD5SO2MVwnj/xTd658ONVf+wLu20u5SBrS+klQ+aPOQ/MgO5AQMgnr7UNxSug hTq1KnLK2rWunX8/kegf2HqP/Q16x/36tP8A4xR/Yeo/9DXrH/fq0/8AjFbdFXZH P7R+X3L/ACMT+w9R/wChr1j/AL9Wn/xij+w9R/6GvWP+/Vp/8Yrboosg9o/L7l/k Yn9h6j/0Nesf9+rT/wCMUf2HqP8A0Nesf9+rT/4xW3RRZB7R+X3L/IxP7D1H/oa9 Y/79Wn/xij+w9R/6GvWP+/Vp/wDGK26KLIPaPy+5f5GJ/Yeo/wDQ16x/36tP/jFH 9h6j/wBDXrH/AH6tP/jFbdFFkHtH5fcv8jE/sPUf+hr1j/v1af8Axij+w9R/6GvW P+/Vp/8AGK26KLIPaPy+5f5GXZ6Ve210k0viDUrtFzmGaO2CNxjnZErcdeCOlalF FNIhyb3CiiigQVzHjvSdS1jw8kGmqszR3Mc09m0nli8iU5aEt/Du459veunqjqGj aXq/l/2lptne+Vny/tMCybM4zjcDjOB+QpSV1YulPkmpdjh/CvhrVNP8dLrUnh2w 0exm0xrY21nOrmJ/MV8vgDJPIyuegya1/iFpuq6hY6LLo9h9uuLDV4L1oPOWLciB yfmY4HJA79elan/CG+Fv+hb0f/wBi/8AiaP+EN8Lf9C3o/8A4Axf/E1HI7WOh106 iqPp5f8ABuYk954r8QaHrem33hH+zfP02dIJP7Sim8yVl2qmBjGcnknHFVIfD+ua HHoGt6dp0V5qVposemXdjJciIkAK3yvyuQwI9DnrXTf8Ib4W/wChb0f/AMAYv/ia P+EN8Lf9C3o//gDF/wDE0cr6/wBfgCrwWkVZdrf/AGxxeueD9c1Twl4quXs4v7c1 yS2b7HFOCsaQsgVd7YBOAxJ4rptd0i+vPHnhPUreDfZ2H2z7TJvUeXviCpwTk5I7 A1e/4Q3wt/0Lej/+AMX/AMTR/wAIb4W/6FvR/wDwBi/+Jo5AeIT69+ndW79EtCj4 10i+1f8A4R37DB5v2PW7a7n+dV2RJu3NyRnGRwOay9P8OarB4U8dWUlrtuNUvr+W zTzFPmpKgCHOcDJ9cY74rov+EN8Lf9C3o/8A4Axf/E0f8Ib4W/6FvR//AABi/wDi aHG7uKNZRiop/h8+5P4Zs59P8KaPZXSeXcW9jDFKmQdrqgBGRweR2rkV06Wb4t/Z IpC+mWif2tInUR3MimIL7AgF8epJ710//CG+Fv8AoW9H/wDAGL/4moLTwD4SsoPJ i8O6ay7i2ZoFlbJ/2nyce2cCm4t2QRqwi5O7u/Lv8zHWw8S+GNS1WPQtIttRs9Uv HvRLJdiI28jqA24EHcuVyMetU38Gan4d0/wlPo1vHqV1oAuBJbNMIRP5yneVZgQM McjNdX/whvhb/oW9H/8AAGL/AOJo/wCEN8Lf9C3o/wD4Axf/ABNLkKWIS/XTfS2u vZ9LHAa14T8UarZeOnk02IXOrjTzbRxXCFW8sjeoJI+6BjJAzjivWqxP+EN8Lf8A Qt6P/wCAMX/xNH/CG+Fv+hb0f/wBi/8AiacYtEVasaiSb28vJLv5HKaTZ+MvDz68 LHRLW5XUdZubiFpbxY/KR8bZCBncpx93hhjpzxFqnwxRvCfh6wjtodSl0feXtpZ3 hS5EnMgDjlTuww+mK7D/AIQ3wt/0Lej/APgDF/8AE0f8Ib4W/wChb0f/AMAYv/ia XJpZmn1qz5ouz9PK3ft2OU8KeA7eGPU5bjw1b6Et9ZvZeQl9JdS7H++WbdsAOFwA M8de1UNa0Pxpe/D2fwkNHtHW1gghhu47tf8ASlR1wAjY2EKuSWPbAznjuv8AhDfC 3/Qt6P8A+AMX/wATR/whvhb/AKFvR/8AwBi/+Jpez0t/X5D+te/zt31T1Xb/ALeL v2q+/tz7J/Z3/Ev+zeZ9u89f9bux5Xl9fu/Nu6dqvVl2fhnQdPukurLRNNtrhM7J YbSNHXIwcEDI4JH41qVor9Tjly/Z/r8WFFFFMkKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKxPF3iH/hFfC95rX2X7V9m2fuf M2btzqn3sHH3s9O1bdcT8Xf+SX6x/wBsP/R0dTN2i2jWhFTqxjLZtfmanifxPLoU +nWNjpj6nqmos4trVZliDBAGcl24GAfxq5rmv2/h3w5PrWoxSLFAitJHHhmDMQoU djyQM9K4rx34c0rW/iV4Pi1C185LyK7inHmMu9I496DgjGGZjx1zzV74yWcFz8Nb +WZNz2ssMsJyRtcyKmeOvyuw59alya5n2OiNKm3Sj/Nv99u/l/Wy6L/hIf8Aiuf+ Ea+y/wDMN+3/AGjzP+mvl7NuPxzn8K268s/4RHRh8TovD8UEsWkp4cObeO4kG9Td ElS27cQS2cZ/Tis1tV1TTfAurWFgbiaK28Tvpaf6V5bpbbhhfNb7uSQm7tuz2pc7 W43hoztyPtv59d/wPZaK8t8JW+r6P4ys7ZPDh0TT7uGY3FvJraXXmMAGEqoW3ZB4 JH9/npXTfEG5hh0C2hlkvA93ew28MNrOIDcSMTiN5MEqhwSSMHjrVKelzGVC1RQT vf0/RtfidZRXiENpcaBqPivQ0t7ews28L3FybG2vJLhFfJAYl+Q2CeBxgir8Wk2+ g6P8P9dsZLldRvrqwtbiVrh2DwyRnKbSdoA7ADip9p5GrwiX2t9tPK/f/M9goryL XdDC61rOs6okmr2sM8jC/wBO1MpdaWmwHb5WQg2ge5ORkHNXb3U00TU7u5065Zx4 o0yB9PkmJHmXIKxAkY4JWWNjgfwnjinz9yfqt0uV3v8A137anqFFeWaZELnUtF8E TzNM+hahJcTFjgtbxKGtyQMZz50Y9Mo3XHPMo3iDWNOvNefw5cNqcck+3Vm19IBZ lXI2+USFVVwAQfvYz3pOp5FRwd38X5db23a7HvNUdXur6z0ua403Tv7RvE2+Xa+e sPmZYA/O3AwCT+GK4AWS6/8AFSwGrQ7WbwxFPNDHN8vmC4B27lPzAN6cHHcVr/F3 /kl+sf8AbD/0dHVc3utmaoJVIQve9vxfr/kdtRXmfivw/Lqfi66u57ePXrSGOFls ItSaC4sTzl1QEKc/eyxzwcdK7Hwhe2WoeE9OudPu7u7tTGVjnvOZW2kqd5wMkEEZ 9u9NSu7EzoqMFNO/9f10XkLo/iAaheanY3duLK80+XEkbSbg0ZGUlBwPlIz24IIp 3hzXW8RWU1/HaGGyMzJayM+TOgOPMxgbQTnHXI5rlviTYRfatFuYv3U+pXkei3Ui Dl7aYksv1G3j0yat/EK4utD8HWlto1syxPdQWjJBMINkJONofomcKme27Pap5mr3 6GipQmo8u8vw7nbUV5b4St9X0fxlZ2yeHDomn3cMxuLeTW0uvMYAMJVQtuyDwSP7 /PSsoaZb6G7a9rjz3aLcEnxLpWpM7r+94SSI/KBkhSqqwGDR7TTYf1Vc1ub02f5O 3Tu35Hs9FFcp4keLQ/EOl+JJHWK25sL6RiAqxucxux9FkAHsHPvVt21OaEOd2N3U rq+tvsn2HTvtvm3KRz/v1j8iI53S8/exx8o5OavV5Fq0f2yHQPETqRJq/iuzljLd RbrvWEewKjdj1c0a7oYXWtZ1nVEk1e1hnkYX+namUutLTYDt8rIQbQPcnIyDms+d nUsLF2Tf/D/fY9Hv9XuNNu7qS508jSLawe7kv1lBIdScxiP733Ru3dO1W9Lv49V0 mz1GFXWK7gSdFfG4KyhgDjvzXlHipLLWtd1KTc91ayeBmuYpJCVZ9s3mRucY5yFO PzHau5+HekWGk+BtK+wweV9storuf52bfK8abm5JxnA4HHtTjJuViatGMKSl1/rz OporyzT5Eg8D/EwSsEJ1LU+GOPvRgL+faq11oU+taH4UG221W1TQoS+iSX7WzuQq HzU243H+H5iAOPWjn8gWFV9Zaf8AAv3PXKK5nwLc2E+hSw2Et+yWt1JBLFfvvkt5 AQTFu/iVcjByeO9dNVp3VznnHkk4hRRRTICiiigArE8UabNrOltpv9mWeoWc/wDx 8R3N7JbfdZWXBRGJ5HqOg65rbopNXVioycWpI5a6stavNUsNSuNA0d7yw8z7NJ/b Ew8veu1+Bb4OQO4NTX8WvanYzWV7oGiT20y7ZI31WXDD/wAB66Oilyl+12029f8A M4vTPD9/o11BdWHhrR4ZoLT7FG39tXDbYd+/bzAf4jnPX3xUsGjalb2moWieGdDN vqM73F1HJq0zrLI+NxIa3OM4HA4Hauvoo5Ruu27tfi/8zidD8N3XhuSaXSPCmhWs kxy7jVpmY+wLW5wPYcVe1Wz1rXNOl0/UvDuiXNrKPnjbVZR9CCLfIPuOa6iijl0s DrNy5mte93/mcDbeDPsUTR2vg/QYVe2ktHMesTq0kTgBlYiDLZwOTkjsRV+XRtTn sdMspPDmjtb6XLFLZp/bM48p4hhDnyMnA9c575rr6KORDeIk9X+b/wAzg9T8HtrG qDUr/wAHeH57sdZDqsw38Y+YC3w3HqDWpdWWs3k1jLP4d0R3sZPMtj/a0o8tsFeA Lf0PQ8dPSuooo5UDrydrrbzf+ZzEVprcOrXGqR+H9FW9uI1ill/tabLKucDH2fHf +XoKyrzwg2oawurXXg7w9Jeht5kOqzAM3qyi32sfqDXeUUcqYlXcXdL8X/mcsLHW hrn9sjw/o/8AaH2b7J5v9sTf6rdu27fs+Pvc5xmjV7LWte0ubTdS0DR57Obb5kf9 sTLnDBhytuD1A711NFHKL2uqdtvX/M4fW/C8/iO5iudW8JaDczxY2yHVplbA6Alb cZHJ4ORWva/8JDY2sVra6DokMEShY449UkCqB2A+z10NFHL1G6zaUWtF6/5nLalZ a1q/2T7doGjy/Y7lLuD/AInEy7JUztbi3GcZPB4qxdjxBf2ktpd6Boc9vKu2SOTV JCrD3H2euhoo5Re12029f8zidD8N3XhuSaXSPCmhWskxy7jVpmY+wLW5wPYcVA3g 3drR1dvBnh43pbeX/tWbbuznds+z7c55zjNd7RS5EX9Yldvq/N/5nI2em6/Y6/qm rw6PpAm1FIVmX+1pcExhgG5t+uGA4wPlHfJNnUYNe1bTp7C+0HRprWdCkkZ1aYbh 9Rb5H4V0tFPlIdW7vbX59Pmcpe6bq+oQ2EVz4d0Z47CeO4tlGsTKI5E4Q8W4zjPQ 8Vnan4PbWNUGpX/g7w/PdjrIdVmG/jHzAW+G49Qa7yihwT3KjXlH4dPm/wDM5J9K 1STU21F/DeiG6azNiW/tebaYN27Zt+z7cZ9s0ujabq/h+yaz0rw7o1tbmRpPLGsT MNx64zbnH06V1lFHKJ1m1ZrT5/5nC33hKTUtSn1G78IaBJdzxNFJL/a0wLKy7T0t +uON3UdjS6j4Vm1bS7PTr7wnoU1tZxrFbg6xOGjQAAAOIN3QDvzjmu5opciK+sTV vLzf+Zxcvh68m8PPoDeFtCXS3wWt49WmQEhg2crbg9QD1rsYTK0EZnREmKguiOWV WxyASBkZ74H0FPoqkrGc6jlv+v8AmFFFFMzCiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigArlPGmbS68OasFyLTVI0kPokytET+bLXV1g+NNJm1vwfqVhaozXTxb7c K+w+apDJhsjHzKOc1MtjWi0qivt/mcZ44s59e17Uru0O6XwvZR3NsApYfaS4lYEA 8/u41GP9vPpW9qt5FrniTwdFblZLdzJqhYHI2rFhD+co/KrvgzTNQt9JvLrW7YQ6 nqV1LcXMO9XCAnai5XggIq//AK6xPA/hvWdM8Q3MurWzJa6fanT9NlMyv5kPnO+7 aD8p2iMcjOAPeos7+p1OceVq/wAGi87qzt89S/P48mTz7628PXlzoNs0iz6kksYx sOGZYydzKCGyfbvXTX97Jb6NcX9nB9seOBpoog+3zcLkAHBxmvJG+FhsZ30+LwhZ akryP5OqS6pLEsaEkr5kQIJIBx8p5x26169p9nFp+m2tjCirFbwpCirnAVQAAMkn oO5JpwcnuZ4iNGNnT1/y+9/p6HPS+ObKK28NzmFtutlCBu5gVgOWwDxvdE7DLday fEfiSzuNdtdPvNDN1BZa9ZW0Fybox7bl0Z94UDnYCOCcHd7VDZeBdQ+x+IrG5Maw CJ7bRWGMxRl2mU5zkYcoO3+qX2psnhXXJdA8ONPbLJqn/CQxarqe11AQZYtyW52q VXAJ4AxUtyaNYxoRldP8fnf7tGc3/wDPIrtvi7/yS/WP+2H/AKOjrE/4RHXf+fH/ AJnb+1f9an/Hr/z0+9/47972rqPiNpF9r3gPUtN02Dz7ybyvLj3qucSox5YgdAe9 CT5WXOpD21N32f6oWz8XzSeJoNH1DRbnTxerI9hPLKjfaAgBbKg5Q4OcHnHpVWfx 5Mnn31t4evLnQbZpFn1JJYxjYcMyxk7mUENk+3erOu6RfXnjzwnqVvBvs7D7Z9pk 3qPL3xBU4Jyckdga4FvhYbGd9Pi8IWWpK8j+TqkuqSxLGhJK+ZECCSAcfKecdutO TmtjOnDDys5aabfN33a1tb79jodV1RNO+KN7q8aCdLbwhJcqgbaJAsxYDODjOOuK v23xAuXh07ULvw5c22i3kcOdQM6ERySYGCnDbAWxv4z1xg5rK8ReHLrTrrVryG2V NKtvBk2npIrjAdSSEALFvujqc/XNRWOm+IfE/gfRvDtzptrFo0tnZvJqAuss8ShH 2CPGQ3ygZzjv7UryTaL5KUoRk7NaLfp9+/kbf/Ncf+5b/wDbmu2rnf7Kk/4WP/a/ 2Kbyv7I+y/a/tCeXnzt3l+Vjdu77s4xxjNdFWkVucdaSfLbsgoooqjEKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKo6ho2l6v5f8AaWm2d75WfL+0 wLJszjONwOM4H5Cr1FA02ndGJ/whvhb/AKFvR/8AwBi/+Jo/4Q3wt/0Lej/+AMX/ AMTW3RS5V2L9rP8Amf3mJ/whvhb/AKFvR/8AwBi/+Jo/4Q3wt/0Lej/+AMX/AMTW 3RRyrsHtZ/zP7zE/4Q3wt/0Lej/+AMX/AMTR/wAIb4W/6FvR/wDwBi/+Jrboo5V2 D2s/5n95if8ACG+Fv+hb0f8A8AYv/iaP+EN8Lf8AQt6P/wCAMX/xNbdFHKuwe1n/ ADP7zE/4Q3wt/wBC3o//AIAxf/E0f8Ib4W/6FvR//AGL/wCJrboo5V2D2s/5n95g TeCPCk8EkL+HNKCyKVJS0RGAIxwygEH3BBFEPgjwpBBHCnhzSisahQXtEdiAMcsw JJ9ySTW/RRyrsHtqm3M/vMeHwn4ctp454PD+lRTRsHSRLONWRgcgggcEHvWxRRQk kTKUpbsKKKKZIUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//Z --------------030600040002070905194647-- --------------040303020804000903746940-- From owner-atom-syntax@mail.imc.org Mon Jun 8 13:19:57 2009 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 485BD3A6C84 for ; Mon, 8 Jun 2009 13:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkjrVZ8Cu80a for ; Mon, 8 Jun 2009 13:19:56 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 42BCB3A6C7D for ; Mon, 8 Jun 2009 13:19:56 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58K8Zd4020113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 13:08:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58K8ZOu020112; Mon, 8 Jun 2009 13:08:35 -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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.146]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58K8OXN020094 for ; Mon, 8 Jun 2009 13:08:34 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qw-out-1920.google.com with SMTP id 14so2545541qwa.28 for ; Mon, 08 Jun 2009 13:08:23 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=EUjudwPcMdJ60kxeTb/ng+TsI46gLccfxfJ2USwlALw=; b=MbteMKeYmB0Mn0cx80vePlbKkMkxFFRhvXZN3FB4e7T9BOvOSxJ0YkgMoOKBrjzUMd LiTokSqqZYNgw+bMbqNLH8845jKgdhFuQYLm/sxrWPydZvHA3B/ylDO1MNwLli6LjsEt cLZrLuDcc8WmdNw9wxktl6819LiJ3rjkvAxZU= 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:content-type:content-transfer-encoding; b=ZreF4TQqToaBwqOmiuue+py+dS8+OMoj2YI59wlo36/6E8sL2hdUJt1hCHOEGfx9Ba lfdNZ8FxL+bgCb0b6ZF7hT12UBSAVN2bfXyg04HhbUjIJvUHF/lVhxvg4uOkm6pwstKg IUQ1zBeKy22FxXd/wSLtrxDdkvas3rNek1WVs= Received: by 10.224.54.133 with SMTP id q5mr7209911qag.141.1244491703721; Mon, 08 Jun 2009 13:08:23 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 4sm67997qwe.37.2009.06.08.13.08.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 13:08:22 -0700 (PDT) Message-ID: <4A2D6FEC.4050302@gmail.com> Date: Mon, 08 Jun 2009 13:09:16 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Al Brown CC: "Nikunj R. Mehta" , Atom-Syntax Syntax Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 References: <20090605170645.A922728C10F@core3.amsl.com> In-Reply-To: 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: +1 Al Brown wrote: > > [snip] > > If it is not a huge cost, I would prefer the generic inlining > mechanism to be a separate I-D since it is only generically related to > hierarchy. > > [snip] From owner-atom-syntax@mail.imc.org Mon Jun 8 13:22:50 2009 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 859473A6C84 for ; Mon, 8 Jun 2009 13:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=-1.317, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_35=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 rL3jTd+Wp10x for ; Mon, 8 Jun 2009 13:22:49 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4377B3A69DC for ; Mon, 8 Jun 2009 13:22:49 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58KAFME020211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 13:10:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58KAFen020210; Mon, 8 Jun 2009 13:10: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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.145]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58KAEDX020204 for ; Mon, 8 Jun 2009 13:10:15 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qw-out-1920.google.com with SMTP id 14so2546684qwa.28 for ; Mon, 08 Jun 2009 13:10:14 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=YwR2bXFh375LQ4KflPDrHNrz0XKakErC9EtwZWzQbjk=; b=w7DpyRMNchZirSViyDu0MjKb+VF1J30ggIARatMmG00q41RKdOEIgUOGjXIc741aPd nKOQT3csPiJqNfkJ3uQzowurriO0X4MywQ8ia3rmS8Eeu4pxZWzSpjBdfj8LFa8veAYz y98vbVuUgler4aCJo2hT/R5nvjLQtBkpNAcXA= 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:content-type:content-transfer-encoding; b=wCbj7IzoMDMrkNvVDGZORLHOx5CRySloGl09hylllKKdX6gMmLSRrfbyfen2rdyIx3 UgFX6QVGw9lm6OcbLXcw6zSk4Vjp6Z4kSzrZkAECiu0YwsM/CDEbf/RW62/+uhpo6fap E1ejOrOnDIshMglWNVfWi+yMeWdSmBBGcxEzc= Received: by 10.224.67.75 with SMTP id q11mr7191776qai.278.1244491460597; Mon, 08 Jun 2009 13:04:20 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 4sm100805qwe.47.2009.06.08.13.04.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 13:04:19 -0700 (PDT) Message-ID: <4A2D6EFA.7070804@gmail.com> Date: Mon, 08 Jun 2009 13:05:14 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Hadrien Gardeur CC: Al Brown , "Nikunj R. Mehta" , Atom-Syntax Syntax , owner-atom-syntax@mail.imc.org Subject: Re: Fwd: New Version Notification for draft-divilly-atom-hierarchy-01 References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> <404dcbd20906081254u68cbeda1v233b01bc1593a894@mail.gmail.com> In-Reply-To: <404dcbd20906081254u68cbeda1v233b01bc1593a894@mail.gmail.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: Hadrien Gardeur wrote: > James, > > Hmmm.... I know we've discussed this, but after thinking about it > more and looking through the examples, I'm becoming increasingly > less convinced that we need a distinction between "down" and > "down-tree". One should simply assume that "down" could point to > a child entry or child feed and that those children could > potentially also be parents. Yes, that possibly increases the > processing compexity but I think it simplifies the model overall. > > > I agree, and I've implemented hierarchy using strictly link@rel="down" > instead of "down-tree" for the same reason. > > > I think we can address this by eliminating the restriction that > "down" and "up" must always point to Atom feed documents and by > changing the cardinality rules for those links. That restriction, > I think, is arbitrary and unnecessary > > > I agree about the type: it could be useful to use a "down" link on > something else than a feed. > Not sure about cardinality though, moving from a tree model to a graph > model really make things more complex (more flexible and powerful too). Yes, there is the potential for making things a lot more complex but the definition of the "down" and "up" links shouldn't rule it out. Whether or not to use a tree or graph should be up to the application. However, we should be able to use the same link relations for either model. > > > Unlike any of the other methods discussed, this approach would > allow clients that don't understand the hierarchy model to still > understand that there is some kind of link relationship with each > of the individual child resources and eliminates the need to > include the extraneous atom:feed metadata. > > Note that this is the same basic approach taken by my comment > thread extension (in-reply-to). > > > The hierarchy I-D used to have ah:count to indicate the number of > entries in the child feed. Now that Nikunj removed ah:count from the > draft, do you believe that thr:count from your Atom threading > extension could be used on link@type="application/atom+xml;type=feed" > for hierarchy ? > Potentially. I don't see why it couldn't be used for that. - James > Hadrien From owner-atom-syntax@mail.imc.org Mon Jun 8 13:27:13 2009 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 ED5B13A6AE9 for ; Mon, 8 Jun 2009 13:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.078 X-Spam-Level: X-Spam-Status: No, score=-5.078 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 XgqPGB9XaadR for ; Mon, 8 Jun 2009 13:27:12 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 145D43A69C6 for ; Mon, 8 Jun 2009 13:27:11 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58KFEHT020593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 13:15:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58KFEhK020592; Mon, 8 Jun 2009 13:15: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 rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58KF3WE020578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jun 2009 13:15:14 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58KFraE016936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Jun 2009 20:15:55 GMT Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58KG5bf026946; Mon, 8 Jun 2009 20:16:05 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Jun 2009 13:14:58 -0700 Cc: Al Brown , Atom-Syntax Syntax Message-Id: <117E3344-2F66-4B24-B22A-97EDAAF3F5FD@oracle.com> From: "Nikunj R. Mehta" To: James M Snell In-Reply-To: <4A2D5EDC.1020207@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 Date: Mon, 8 Jun 2009 13:13:37 -0700 References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt004.oracle.com [141.146.116.13] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010208.4A2D7142.02AE:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 8, 2009, at 11:56 AM, James M Snell wrote: >> Al Brown wrote: >> >> The I-D introduces a concept of hierarchy through up/up-tree/down- >> tree/down relations yet a all-purpose mechanism for inclusion. Most >> (all?) of the information on the feed element is duplicated on the >> enclosing entry (id, uri, etc). Can't we do better for this >> specific scenario the I-D is addressing? >> > I think we can address this by eliminating the restriction that > "down" and "up" must always point to Atom feed documents and by > changing the cardinality rules for those links. That restriction, I > think, is arbitrary and unnecessary > > It would allow us to do something like.... > > > ... > href="child1"> > > ... > > > href="child2"> > > ... > > > ... > href="childN"> > > ... > > > ... > > > Unlike any of the other methods discussed, this approach would allow > clients that don't understand the hierarchy model to still > understand that there is some kind of link relationship with each of > the individual child resources and eliminates the need to include > the extraneous atom:feed metadata. I don't find this argument quite convincing. For starters, if a client doesn't understand rel="down" it will make no difference whether there are multiple of those or a single one. Secondly, a client that does the most generic thing possible can at least "render" a feed provided in @rel=down in a cogent way. A feed that has rel=down scattered all over the place will be more harmful than beneficial. I can see how there is value in sporting a more flexible (and hence a more complex) model, I fail to see requirements for adding this complexity. Rather than treating the hierarchy I-D approach as arbitrary, I implore the group to identify reasons to expand the cardinality before making this arbitrary choice. > > > Note that this is the same basic approach taken by my comment thread > extension (in-reply-to). The whole processing model for multiple occurrences of @rel="replies" is underwhelming. From RFC 4685, Section 4, Multiple replies links appearing within an atom:entry may reference alternative representations of the same set of responses or may reference entirely distinct resources containing distinct sets of responses. Processors MUST NOT assume that multiple replies links are referencing different representations of the same resource and MUST process each replies link independently of any others. I would be interested in learning about the usage experience with multiple links for replies, especially in consumers of documents using replies links with multiple occurrences. From owner-atom-syntax@mail.imc.org Mon Jun 8 13:30:57 2009 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 2E8693A6D97 for ; Mon, 8 Jun 2009 13:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.958 X-Spam-Level: X-Spam-Status: No, score=-5.958 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 nCKnvIxBBlRE for ; Mon, 8 Jun 2009 13:30:56 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9C2583A6D84 for ; Mon, 8 Jun 2009 13:30:55 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58KHLTe020701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 13:17:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58KHLvP020700; Mon, 8 Jun 2009 13:17: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 rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58KHA3X020690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jun 2009 13:17:20 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58KGmKe022198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Jun 2009 20:16:50 GMT Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58KH5gO018376; Mon, 8 Jun 2009 20:17:05 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Jun 2009 13:16:59 -0700 Cc: James M Snell , Al Brown , Atom-Syntax Syntax Message-Id: <0E4717E2-60E8-48FB-9EE0-020E378FF0F8@oracle.com> From: "Nikunj R. Mehta" To: Hadrien Gardeur In-Reply-To: <404dcbd20906081254u68cbeda1v233b01bc1593a894@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 Date: Mon, 8 Jun 2009 13:15:38 -0700 References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> <404dcbd20906081254u68cbeda1v233b01bc1593a894@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt001.oracle.com [141.146.116.10] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4A2D71BC.01DD:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 8, 2009, at 12:54 PM, Hadrien Gardeur wrote: > I agree, and I've implemented hierarchy using strictly > link@rel="down" instead of "down-tree" for the same reason. > > I think we can address this by eliminating the restriction that > "down" and "up" must always point to Atom feed documents and by > changing the cardinality rules for those links. That restriction, I > think, is arbitrary and unnecessary > I can see how we can add a default of type="application/atom +xml;type=feed" to @rel=down. The I-D already allows the link to be used with other types. From owner-atom-syntax@mail.imc.org Mon Jun 8 13:40:28 2009 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 61BDC3A6B21 for ; Mon, 8 Jun 2009 13:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 sF3uAeG8ou9C for ; Mon, 8 Jun 2009 13:40:27 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 83BB23A6B1B for ; Mon, 8 Jun 2009 13:40:23 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58KS0AY021203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 13:28:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58KS0s3021202; Mon, 8 Jun 2009 13:28:00 -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 acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58KRnK7021194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jun 2009 13:27:59 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58KP1dg000599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Jun 2009 20:25:03 GMT Received: from abhmt009.oracle.com (abhmt009.oracle.com [141.146.116.18]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58KRntC004264; Mon, 8 Jun 2009 20:27:49 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Jun 2009 13:27:43 -0700 Cc: atom-syntax Message-Id: <59BD8EFC-A04D-4F8B-96C7-1F4B60CC9231@oracle.com> From: "Nikunj R. Mehta" To: James M Snell In-Reply-To: <4A2D59A9.9090704@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Comments on hierarchy draft Date: Mon, 8 Jun 2009 13:26:22 -0700 References: <4A2D59A9.9090704@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt009.oracle.com [141.146.116.18] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A01020A.4A2D7440.0125:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 8, 2009, at 11:34 AM, James M Snell wrote: > > Great to see a bunch of activity on the list... I'm finally starting > to find time to catch up on what's been going on. The hierarchy > draft looks good at first read but I had a few comments and > concerns... Good to have you back in active participation on this list. > > Forgive me if any of this has already been discussed, there have > been a significant number of posts on the hierarchy draft and I > simply have not yet had time to dig through them all. > > Section 2.1 > > The cardinality model really isn't all that clear to me upon first > read of this draft so please bear with me. The draft would seem to > indicate that any given entry can have multiple parent entries. Does > this mean that the entry can have multiple "up" links, each pointing > to a different parent Atom entry document, or a single "up" link > pointing to a single Atom feed document containing all of the parent > entries? The cardinality model is defined in Section 4. Section 2 only introduces the meanings of certain relation type and a model for relating entries and feeds. The I-D could have claridfied that a multi-parent relation is expressed through @type="application/atom+xml;type=feed" in combination with @rel=up. > > > Section 3.2 If the ae:inline element is supposed to allow arbitrary > content then it is underspecified. For instance, the atom:content > element contains a specific type attribute used to indicate whether > the content is text, html, xhtml or some specific media type. If the > media-type is binary based, atom:content requires that the contained > data be Base64 encoded. If the media-type is text based, > atom:content requires that the characters be included as inline- > text. If the media-type is xml based, atom:content requires that the > xml be in-lined directly. I know the specification indicates that > the optional type attribute of the enclosing atom:link element is > intended to provide the necessary information, I think it would make > far more sense for the ae:inline element to have it's own type > attribute modeled after the atom:content type attribute. e.g. > , . Wouldn't this merely repeat information from the atom:link element? Why is it a better model? What happens if the atom:link @type and ae:inline @type differ from each other? > > It would also make sense to explicitly spell out the processing > model as is done in RFC 4287 for atom:content rather than just > saying "process the value of ae:inline per the processing model for > atom:content as specified in Section 4.1.3.3 of [RFC4287]". Of course, the full processing model can be specified in the I-D, but we intentionally referred to the atom:content processing model as the archetype. If the best way to specify this behavior is to repeat the text in hierarchy I-D, that can be easily done. > > Section 4 > We are separately discussing this topic, so omitting here > Section 5.3: There is a bug in the example. The and atom:feed> closing tags have been transposed. > Noted. Thanks! From owner-atom-syntax@mail.imc.org Mon Jun 8 13:41:44 2009 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 41CE328C15F for ; Mon, 8 Jun 2009 13:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=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 onDfLQbM9W8A for ; Mon, 8 Jun 2009 13:41:43 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C423B28C148 for ; Mon, 8 Jun 2009 13:41:42 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58KU6Uk021331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 13:30:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58KU6oX021330; Mon, 8 Jun 2009 13:30: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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.146]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58KU5v4021324 for ; Mon, 8 Jun 2009 13:30:06 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qw-out-1920.google.com with SMTP id 14so2559589qwa.28 for ; Mon, 08 Jun 2009 13:30:05 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=SJsBc3ZUO0Dj22FZQgXjyH206uNr6Sh/3IdreNzLt+E=; b=eFpQnLyFqx9BhU1E2XLYRGebyIcmiVZ78XjKHYVmE3v+WPFHbV7aEU17i89Q0rSm0q 6GW1ney8t2xf2LnMd1B03BS7AzVOLS8Wpf522qbNnyVjFNHKDCINHoq/SN563wUf3sXT SvDZMwkjtwSopDceIzXS33iNUfsPt96oh9o9c= 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:content-type:content-transfer-encoding; b=jLihwWtC05vnXUuQiZTwwZ06iDiqM3gF8bFjTbA/vIQtDy7z2xKkI2jGjMh7ETRLPC fbKHWypSAtBRovQTAxzdpd8k5YM1A2aPv+XMlgg6yEfMaP0WgtupO815Gbi7wf03/XK3 uP6zFgBvJBxeNua0dIN+bAuCVWp+tCO1jHR/o= Received: by 10.224.80.134 with SMTP id t6mr7249271qak.173.1244493004087; Mon, 08 Jun 2009 13:30:04 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 6sm280511qwk.0.2009.06.08.13.30.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 13:30:03 -0700 (PDT) Message-ID: <4A2D7502.7000805@gmail.com> Date: Mon, 08 Jun 2009 13:30:58 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Nikunj R. Mehta" CC: Al Brown , Atom-Syntax Syntax Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> <117E3344-2F66-4B24-B22A-97EDAAF3F5FD@oracle.com> In-Reply-To: <117E3344-2F66-4B24-B22A-97EDAAF3F5FD@oracle.com> 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: Nikunj R. Mehta wrote: > On Jun 8, 2009, at 11:56 AM, James M Snell wrote: > > >> >> Unlike any of the other methods discussed, this approach would allow >> clients that don't understand the hierarchy model to still understand >> that there is some kind of link relationship with each of the >> individual child resources and eliminates the need to include the >> extraneous atom:feed metadata. > > I don't find this argument quite convincing. For starters, if a client > doesn't understand rel="down" it will make no difference whether there > are multiple of those or a single one. Secondly, a client that does > the most generic thing possible can at least "render" a feed provided > in @rel=down in a cogent way. A feed that has rel=down scattered all > over the place will be more harmful than beneficial. > A client that does not understand anything about "down" or "up" will not be able to do anything cogent with the linked resource other than say that some kind of relationship exists. The ability to render the linked resource is meaningless if the application is incapable of determining the nature of the relationship. In such cases, the distinction of having multiple rel=downs that point to alternate representations of the same resource or that point to separate distinct resources is meaningless and neither approach is more or less harmful or beneficial than the other. > I can see how there is value in sporting a more flexible (and hence a > more complex) model, I fail to see requirements for adding this > complexity. Rather than treating the hierarchy I-D approach as > arbitrary, I implore the group to identify reasons to expand the > cardinality before making this arbitrary choice. > This is backwards. Cardinality constraints are a restriction. To ensure maximum flexibility, one needs to justify adding the restriction, not justify removing it. All that I'm saying is that the existing cardinality rules impose a restriction on the model that does not appear to be strictly necessary and could potentially be harmful long term. For instance, given the current definition, one would need to invent yet another set of hierarchy rel relations in order to implement a graph model, which, to me at least, seems counterproductive. Define "down" and "up" more generically and move the cardinality constraints to the application where they belong. Note that relaxing the cardinality does not make it any more difficult to achieve the result you are looking for. An application could still use multiple rel=down links to point to alternate language representations of the same logical child feed, for instance, Atom processors would simply treat those alternate language representations as separate child feeds leaving it up to the application to make the appropriate connections. >> >> >> Note that this is the same basic approach taken by my comment thread >> extension (in-reply-to). > > > The whole processing model for multiple occurrences of @rel="replies" > is underwhelming. From RFC 4685, Section 4, > > Multiple replies links appearing within an atom:entry may reference > alternative representations of the same set of responses or may > reference entirely distinct resources containing distinct sets of > responses. Processors MUST NOT assume that multiple replies links are > referencing different representations of the same resource and MUST > process each replies link independently of any others. > > I would be interested in learning about the usage experience with > multiple links for replies, especially in consumers of documents using > replies links with multiple occurrences. I would be interested in learning about the implementation experiences for this as well. I purposefully left that model to be as flexible as possible, with as few constraints as possibly, specifically in order to avoid placing arbitrary and premature restrictions on implementations. If implementation experience shows that specific restrictions would be helpful, then I would be more than happy to work on a BCP describing those restrictions. - James From owner-atom-syntax@mail.imc.org Mon Jun 8 13:55:08 2009 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 DEBEF3A6AC4 for ; Mon, 8 Jun 2009 13:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.981 X-Spam-Level: X-Spam-Status: No, score=-5.981 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 Ag+8UYSuWZK7 for ; Mon, 8 Jun 2009 13:55:08 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id ADA803A69E2 for ; Mon, 8 Jun 2009 13:55:07 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58KhDsh021909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 13:43:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58KhDQD021908; Mon, 8 Jun 2009 13:43:13 -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 acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58KhCXA021896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Jun 2009 13:43:12 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58KhwJl008381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Jun 2009 20:43:59 GMT Received: from abhmt003.oracle.com (abhmt003.oracle.com [141.146.116.12]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58KiDGl017491; Mon, 8 Jun 2009 20:44:13 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Jun 2009 13:43:06 -0700 Message-Id: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> From: "Nikunj R. Mehta" To: atom-syntax Syntax , atom-protocol Protocol Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Exploring a new WG around Atom Date: Mon, 8 Jun 2009 13:41:45 -0700 X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt003.oracle.com [141.146.116.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4A2D77DA.02AA:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Recent discussions on the atom-syntax mailing list has revealed interest in creating a new WG to look at several extensions of Atom. Here are several extensions that have been discussed: 1. Hierarchy operations including meta-publishing 2. In-line representation 3. Bi-directional text Please respond to this email if you are interested in helping to explore a new WG further. Please also identify if you have a specific interest area to consider for a potential new Atom WG. Nikunj http://o-micron.blogspot.com From owner-atom-syntax@mail.imc.org Mon Jun 8 13:57:14 2009 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 8FF9C3A6D84 for ; Mon, 8 Jun 2009 13:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.117 X-Spam-Level: X-Spam-Status: No, score=-5.117 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 Q-43hKFk56ub for ; Mon, 8 Jun 2009 13:57:12 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C95873A69E2 for ; Mon, 8 Jun 2009 13:57:11 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58Kjkbm022026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 13:45:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58Kjk77022025; Mon, 8 Jun 2009 13:45: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 rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58KjiVh022011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Jun 2009 13:45:45 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58KjNNq013071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Jun 2009 20:45:24 GMT Received: from abhmt002.oracle.com (abhmt002.oracle.com [141.146.116.11]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58KkePe021986; Mon, 8 Jun 2009 20:46:40 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Jun 2009 13:45:33 -0700 Cc: Mark Nottingham , Peter Keane , Julian Reschke , atom-syntax Syntax , atom-protocol Protocol Message-Id: <504D03F5-2436-401D-B5DC-A045EA3B3F7C@oracle.com> From: "Nikunj R. Mehta" To: Kyle Marvin In-Reply-To: <192fc9640906052148v4bb3ba29o5c8e75395618eb13@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-12--101320262 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-00 Date: Mon, 8 Jun 2009 13:44:11 -0700 References: <20090520165415.48AAE3A7130@core3.amsl.com> <3CD5B7DD-FEB6-4A6F-928D-76D982318DDC@mnot.net> <36D30DB4-58E9-41DD-A8F5-FA96A8A4E9AB@oracle.com> <7CCF9900-A47E-4C0A-8144-6B46BBCE94BD@oracle.com> <94648B62-F0F7-46D0-9496-45F43B0DE5CF@mnot.net> <8158ad750906042110g5128f354i33c339f288be6c5d@mail.gmail.com> <1EF2FFD2-8D31-42D4-B3AB-8F36EEE939F9@mnot.net> <192fc9640906051032ve21ddb0u3215f92a4b841399@mail.gmail.com> <415A555A-1EC2-45E7-903B-501628193BA1@mnot.net> <192fc9640906052148v4bb3ba29o5c8e75395618eb13@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt002.oracle.com [141.146.116.11] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010203.4A2D786E.0278:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-12--101320262 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 5, 2009, at 9:48 PM, Kyle Marvin wrote: > On Fri, Jun 5, 2009 at 9:47 PM, Mark Nottingham wrote: > Just checking -- you do realise I'm suggesting it's worth using a > new media type for the atom document that contains these extensions, > not a new media type in it? Your response was worded in such a way > that I'm not sure... > > Yes, I understand. I think there are issues with media type under- > use at both levels (document and content). There are definitely > cases where a new MIME type on the Atom document would be helpful to > processors and others where more judicious usage of specialized MIME > types for atom:content would be helpful. Let me see if I can give > you an example and see if you agree or disagree. Take the case of > a feed that describes a calendar and contains entries that describe > events in the calendar. If this had a MIME type of something like > "application/calendar+atom+xml", then it would might inform a client > processing it that there are other possible processing options > besides regular syndication, like importing to a local calendar. > Such a MIME type might explain the set of metadata extensions > specific to calendars that are expected (ex timezone info) and > possibly even put constraints or expectations on the MIME type of > atom:content found within the entries. > > Of course, the "application/calendar+atom+xml" is fictitious because > there's no model for saying that something is an atom feed of a > specific type in the same way that "application/atom+xml" says that > it's an XML document with Atom syntax constraints. Rooted in this > might be Nikunj's concern but there's probably more (see next > paragraph). Without a model for defining Atom media subtypes, > you'd have to type it as something that is going to cause a generic > Atom processor to ignore it even though it could still be processed > in useful (albeit less vertical way) to let me know when data/events > are available or have changed via a feed reader interface. I find Kyle's commentary sympathetic to my previous concern. > > I don't know, though, that anything in the hierarchy proposal > justifies a new MIME type and given that you say it might be worth > *considering* I'm not sure you see it that way either. There are > definitely cases where you're just adding extensions that are > informative and additional metadata and I don't think these alone > define a new data format that needs a media type. Media RSS is > possibly another example. Consider these the Atom Syntax > equivalent of a ""mixin". If such extensions are standardized and/ > or get enough de facto usage lots of Atom processors are likely to > handle them just fine. So the current proposal is perhaps not the > best poster child for using media types more but I definitely think > it's something that the Atom community should consider to better > enable client use cases in addition to reader-based syndication. > > All this being said, I think the right venue for creating more > specialized Atom media types is in communities that would benefit > from their existence and the collaboration or processing models that > would be enabled by them. Just minting new MIME types because > you've extended Atom is not all that helpful in the bigger scheme of > things, imo. > In reviewing an industry specification for content management [1], I came across a situation where additional constraints were placed on a valid/acceptable Atom entry and it just made me think whether a generic client can be warned about this through the app:accept kind of signaling. I recommended that the specification use a media type parameter for Atom that cautions about the server's expectation about acceptable content. Since a number of users of Atom feeds beyond blogging and news frequently require additional markup in Atom documents, there is a latent interoperability problem with and lack of adequate metadata about such interactions. Perhaps, a reasoned approach could be devised to deal with growing use of Atom documents beyond blogs. [1] http://www.oasis-open.org/committees/download.php/32668/Draft%2062a.zip > HTH, > > -- Kyle- > > > > Cheers, > > > > On 06/06/2009, at 3:32 AM, Kyle Marvin wrote: > > On Fri, Jun 5, 2009 at 12:05 AM, Mark Nottingham > wrote: > > > On 05/06/2009, at 2:10 PM, Peter Keane wrote: > > I hope I'm not too far off w/ this, but it seems to me there are a > couple distinct concerns in this thread: First is a need for what is > essentially multiple atom:content elements in an entry. atom:link > seems like a logical home for that content (given that we can assign > an appropriate @rel). > > Peter, I'm not sure I see the need like this; you want more than > multiple content items. What you have here is multiple resources > (some of which might be metadata + content, i.e. an atom entry, or > might not even be Atom at all) with some type of relationship > between them *and* the desire to retrieve these multiple related > resources using a single GET. A key difference between 'content' > and a 'resource' is that the latter is independently dereferencable > whereas the same isn't necessarily true for any atom:content types > other than out-of-line-content. A link has the nice property of > having a rel that describes how it is related to what it is > contained within (i.e. why it might be referenced), a type attribute > that informs how to process it (either when referenced or > potentially inline), and a href that says where to deference it > (i.e. how to reference it independently even if it is inline). All > nice and useful properties within the composite resource that allow > it to be used in a decoupled fashion after the initial GET of the > composite resource. > > > > Well, the most straightforward way to fix that would be to fix Atom > and allow multiple atom:content elements in an entry... > > > I'd agree with Nikunj that this is not so dramatic a change that new > media types need to be considered. It feels more like a tweak to me, > and I do not see much difficulty at all in using my current tools for > parsing or producing such atom documents. > > I think this is valid but an orthogonal concern. The key point is > that you want to nest a resource that itself has a MIME type and can > be processed. Whether these are new or existing MIME types depends > on the use cases and what is the most appropriate MIME type for that > relationship. > > > Ah, maybe that's where the misunderstanding lies. It's not that you > can't parse it with an Atom library, with appropriate code to handle > the extensions; that's obviously possible. > > My concern is that a *generic* Atom processor (e.g., a feed reader) > or more importantly a generic MIME dispatcher (e.g., a browser or an > OS) wouldn't be able to do much that's useful with such a feed, > because -- as I understand the use cases -- most of the information > will be in extensions that the generic processor won't be able to > take advantage of, and because the generic MIME dispatcher won't > know to send this document to a handler that can do something with it. > > It might surprise you but I'd agree that using MIME types more would > be goodness. It's frequently the case (including in GData) that the > lines between what is metadata and what is content are being blurred > since both are found in Atom extensions. This fact does make life > harder for Atom processors, since they have to rely on sideband > signals (a 'kind' or a 'type') that inform them about what > extensions to expect and what they mean and there's not much > standardization happening in this space. > > > > This is the role media types play on the Web (and elsewhere, of > course)... > > I don't know, though, that this is a problem the Atom WG (or a > derivative effort) can solve. In most cases, those MIME types for > nested content are domain-specific representations that are best > standardized by (or at least generally agreed upon) by groups > working in that domain. I don't see a proliferation of vendor- > specific media types as being much better than the status quo other > than that they'd let you write vendor-specific MIME processors; > better structured from an Atom perspective but not really pushing > the Web forward in the right direction from a collaborative > perspective. > > Let me know if you think I'm missing something! > > -- Kyle > > > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > > > -- > Mark Nottingham http://www.mnot.net/ > > --Apple-Mail-12--101320262 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Jun 5, 2009, at 9:48 PM, Kyle Marvin = wrote: On Fri, Jun 5, 2009 at 9:47 PM, Mark Nottingham = <mnot@mnot.net> = wrote: Just checking -- you = do realise I'm suggesting it's worth using a new media type for the atom = document that contains these extensions, not a new media type in it? = Your response was worded in such a way that I'm not sure... = Yes, I understand. I think there are issues = with media type under-use at both levels (document and content). = There are definitely cases where a new MIME type on the Atom document = would be helpful to processors and others where more judicious usage of = specialized MIME types for atom:content would be helpful. Let me = see if I can give you an example and see if you agree or disagree. = Take the case of a feed that describes a calendar and contains = entries that describe events in the calendar. If this had a MIME = type of something like "application/calendar+atom+xml", then it would = might inform a client processing it that there are other possible = processing options besides regular syndication, like importing to a = local calendar. Such a MIME type might explain the set of = metadata extensions specific to calendars that are expected (ex timezone = info) and possibly even put constraints or expectations on the MIME type = of atom:content found within the entries. Of = course, the "application/calendar+atom+xml" is fictitious because = there's no model for saying that something is an atom feed of a specific = type in the same way that "application/atom+xml" says that it's an XML = document with Atom syntax constraints. Rooted in this might be = Nikunj's concern but there's probably more (see next paragraph). = Without a model for defining Atom media subtypes, you'd have to type it = as something that is going to cause a generic Atom processor to ignore = it even though it could still be processed in useful (albeit less = vertical way) to let me know when data/events are available or have = changed via a feed reader = interface. I find Kyle's = commentary sympathetic to my previous = concern. I don't know, though, that = anything in the hierarchy proposal justifies a new MIME type and given = that you say it might be worth *considering* I'm not sure you see it = that way either. There are definitely cases where you're just = adding extensions that are informative and additional metadata and I = don't think these alone define a new data format that needs a media = type. Media RSS is possibly another example. Consider these = the Atom Syntax equivalent of a ""mixin". If such extensions are = standardized and/or get enough de facto usage lots of Atom processors = are likely to handle them just fine. So the current proposal is = perhaps not the best poster child for using media types more but I = definitely think it's something that the Atom community should consider = to better enable client use cases in addition to reader-based = syndication. All this being said, I think the = right venue for creating more specialized Atom media types is in = communities that would benefit from their existence and the = collaboration or processing models that would be enabled by them. = Just minting new MIME types because you've extended Atom is not = all that helpful in the bigger scheme of things, imo. = In reviewing an = industry specification for content management [1], I came across a = situation where additional constraints were placed on a valid/acceptable = Atom entry and it just made me think whether a generic client can be = warned about this through the app:accept kind of signaling. I = recommended that the specification use a media type parameter for Atom = that cautions about the server's expectation about acceptable content. = Since a number of users of Atom feeds beyond blogging and news = frequently require additional markup in Atom documents, there is a = latent interoperability problem with and lack of adequate metadata about = such interactions. Perhaps, a reasoned approach could be devised to deal = with growing use of Atom documents beyond = blogs. [1] http://www.oasis-open.org/committees/download.php/32668/Draft%2062a= .zip HTH, -- = Kyle- Cheers, On 06/06/2009, at 3:32 AM, Kyle Marvin = wrote: On Fri, Jun 5, 2009 = at 12:05 AM, Mark Nottingham <mnot@mnot.net> wrote: On 05/06/2009, = at 2:10 PM, Peter Keane wrote: I hope I'm not too far off w/ = this, but it seems to me there are a couple distinct concerns in = this thread: First is a need for what is essentially multiple = atom:content elements in an entry. atom:link seems like a = logical home for that content (given that we can assign an = appropriate @rel). Peter, I'm not sure I see the need like = this; you want more than multiple content items. What you = have here is multiple resources (some of which might be metadata + = content, i.e. an atom entry, or might not even be Atom at all) with some = type of relationship between them *and* the desire to retrieve these = multiple related resources using a single GET. A key difference = between 'content' and a 'resource' is that the latter is independently = dereferencable whereas the same isn't necessarily true for any = atom:content types other than out-of-line-content. A link has the = nice property of having a rel that describes how it is related to what = it is contained within (i.e. why it might be referenced), a type = attribute that informs how to process it (either when referenced or = potentially inline), and a href that says where to deference it (i.e. = how to reference it independently even if it is inline). All nice = and useful properties within the composite resource that allow it to be = used in a decoupled fashion after the initial GET of the composite = resource. Well, the most straightforward way to fix = that would be to fix Atom and allow multiple atom:content elements in an = entry... I'd agree with Nikunj that this is not so = dramatic a change that new media types need to be considered. = It feels more like a tweak to me, and I do not see much = difficulty at all in using my current tools for parsing or producing = such atom documents. I think this is valid but an orthogonal = concern. The key point is that you want to nest a resource that = itself has a MIME type and can be processed. Whether these are new = or existing MIME types depends on the use cases and what is the most = appropriate MIME type for that relationship. Ah, maybe = that's where the misunderstanding lies. It's not that you can't parse it = with an Atom library, with appropriate code to handle the extensions; = that's obviously possible. My concern is that a *generic* Atom = processor (e.g., a feed reader) or more importantly a generic MIME = dispatcher (e.g., a browser or an OS) wouldn't be able to do much that's = useful with such a feed, because -- as I understand the use cases -- = most of the information will be in extensions that the generic processor = won't be able to take advantage of, and because the generic MIME = dispatcher won't know to send this document to a handler that can do = something with it. It might surprise you but I'd agree that = using MIME types more would be goodness. It's frequently the case = (including in GData) that the lines between what is metadata and what is = content are being blurred since both are found in Atom extensions. = This fact does make life harder for Atom processors, since they = have to rely on sideband signals (a 'kind' or a 'type') that inform them = about what extensions to expect and what they mean and there's not much = standardization happening in this space. This is the = role media types play on the Web (and elsewhere, of course)... = I don't know, though, that this is a problem the Atom WG (or a = derivative effort) can solve. In most cases, those MIME types for = nested content are domain-specific representations that are best = standardized by (or at least generally agreed upon) by groups working in = that domain. I don't see a proliferation of vendor-specific = media types as being much better than the status quo other than that = they'd let you write vendor-specific MIME processors; better = structured from an Atom perspective but not really pushing the Web = forward in the right direction from a collaborative perspective. = Let me know if you think I'm missing something! -- = Kyle Cheers, -- Mark Nottingham = http://www.mnot.net/ = -- Mark Nottingham http://www.mnot.net/ = = --Apple-Mail-12--101320262-- From owner-atom-syntax@mail.imc.org Mon Jun 8 14:00:22 2009 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 1987E3A6AC4 for ; Mon, 8 Jun 2009 14:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=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 NsFhsSK8IfLL for ; Mon, 8 Jun 2009 14:00:21 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8A1DD3A69AF for ; Mon, 8 Jun 2009 14:00:20 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58KnFN5022213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 13:49:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58KnFg3022212; Mon, 8 Jun 2009 13:49: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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58Kn4Y7022198 for ; Mon, 8 Jun 2009 13:49:14 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qw-out-1920.google.com with SMTP id 14so2572779qwa.28 for ; Mon, 08 Jun 2009 13:49:03 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=3EpkLW3H0TQrQLM8rkdjM4/wOrNn4c2X9/92m51yM4g=; b=inP54FFRtAr0lv8jfB87qNuWmp+sTGXrPL/N9ZG5/NSFK54IkMutAT7WZEW02MW8IJ UwkKYjPSRzqlT9c6hVosJUcad5MxWtMhjFwL/hRZZnYrx3upZBpbxSe+nzbdoyIcgqBR /+46PgXRjD5eA0bShHlYc9Y5+cI28iS9yWNlg= 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:content-type:content-transfer-encoding; b=IZ7/NtAV4eyjC6uZatn5gsDXeqM8/Wt3eQ4JI2YHa/2bgfKSnkgsBoAFsrV7vATVR0 2sbRHtJL34ZNd9M3b47wcg7Xsqwz1qro8cBR7Cl24fxKwTZvapHx6HQrKSRz9tkdFOtR xPrumCClF7J1Fsbc3yQ1tXcpZsyxjcVSmy6eQ= Received: by 10.224.36.202 with SMTP id u10mr7282883qad.83.1244493778977; Mon, 08 Jun 2009 13:42:58 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 2sm67930qwi.3.2009.06.08.13.42.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 13:42:57 -0700 (PDT) Message-ID: <4A2D7808.7070003@gmail.com> Date: Mon, 08 Jun 2009 13:43:52 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Nikunj R. Mehta" CC: atom-syntax Subject: Re: Comments on hierarchy draft References: <4A2D59A9.9090704@gmail.com> <59BD8EFC-A04D-4F8B-96C7-1F4B60CC9231@oracle.com> In-Reply-To: <59BD8EFC-A04D-4F8B-96C7-1F4B60CC9231@oracle.com> 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: Nikunj R. Mehta wrote: > On Jun 8, 2009, at 11:34 AM, James M Snell wrote: > >> >> Great to see a bunch of activity on the list... I'm finally starting >> to find time to catch up on what's been going on. The hierarchy draft >> looks good at first read but I had a few comments and concerns... > > Good to have you back in active participation on this list. > Good to actually have the time to do so ;-) >> >> Forgive me if any of this has already been discussed, there have been >> a significant number of posts on the hierarchy draft and I simply >> have not yet had time to dig through them all. >> >> Section 2.1 >> >> The cardinality model really isn't all that clear to me upon first >> read of this draft so please bear with me. The draft would seem to >> indicate that any given entry can have multiple parent entries. Does >> this mean that the entry can have multiple "up" links, each pointing >> to a different parent Atom entry document, or a single "up" link >> pointing to a single Atom feed document containing all of the parent >> entries? > > The cardinality model is defined in Section 4. Section 2 only > introduces the meanings of certain relation type and a model for > relating entries and feeds. > > The I-D could have claridfied that a multi-parent relation is > expressed through @type="application/atom+xml;type=feed" in > combination with @rel=up. > Ok... >> >> >> Section 3.2 If the ae:inline element is supposed to allow arbitrary >> content then it is underspecified. For instance, the atom:content >> element contains a specific type attribute used to indicate whether >> the content is text, html, xhtml or some specific media type. If the >> media-type is binary based, atom:content requires that the contained >> data be Base64 encoded. If the media-type is text based, >> atom:content requires that the characters be included as inline-text. >> If the media-type is xml based, atom:content requires that the xml be >> in-lined directly. I know the specification indicates that the >> optional type attribute of the enclosing atom:link element is >> intended to provide the necessary information, I think it would make >> far more sense for the ae:inline element to have it's own type >> attribute modeled after the atom:content type attribute. e.g. >> , > type="application/atom+xml;type=entry">. > > Wouldn't this merely repeat information from the atom:link element? > Why is it a better model? What happens if the atom:link @type and > ae:inline @type differ from each other? > Yes and no. The sematics of the atom:link type attribute currently only apply to the media type of the linked resource and is intended only as a hint. It is possible that the linked resource is a completely different media type than that specified by the type attribute. Further, the type attribute does not utilize the special "text", "html" and "xhtml" values used in atom:content. Therefore, if the link uses type="text/html", should the content of the ae:inline element be processed using the rules for atom:content/@type="html" or atom:content/@type="text/html"? There are subtle yet important differences between the two. The differences become even more pronounced when dealing with type="xhtml" vs. type="application/xhtml+xml". I think that if you're going to point to the atom:content processing model as the rule for ae:inline, then you need ae:inline to have it's own type attribute and not rely on the link elements type attribute. If the two are mismatched, then you treat it no differently than if the value of the atom:link/@type does not match the actual content type of the linked resource. >> >> It would also make sense to explicitly spell out the processing model >> as is done in RFC 4287 for atom:content rather than just saying >> "process the value of ae:inline per the processing model for >> atom:content as specified in Section 4.1.3.3 of [RFC4287]". > > Of course, the full processing model can be specified in the I-D, but > we intentionally referred to the atom:content processing model as the > archetype. If the best way to specify this behavior is to repeat the > text in hierarchy I-D, that can be easily done. > In the past, I've used both approaches in drafts I've authored. The feedback I've received from others has consistently favored repeating the text in order to make the requirements absolutely clear. - James >> >> Section 4 >> > > > We are separately discussing this topic, so omitting here > >> Section 5.3: There is a bug in the example. The and >> closing tags have been transposed. >> > Noted. Thanks! > > From owner-atom-syntax@mail.imc.org Mon Jun 8 14:21:58 2009 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 3B47428C12A for ; Mon, 8 Jun 2009 14:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq+CCByJW4x8 for ; Mon, 8 Jun 2009 14:21:57 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EDF253A682D for ; Mon, 8 Jun 2009 14:21:56 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58L8e1G023126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 14:08:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58L8eDv023124; Mon, 8 Jun 2009 14:08: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 mailhost.dizzyd.com (dizzyd.com [207.210.219.225] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58L8S4D023112; Mon, 8 Jun 2009 14:08:39 -0700 (MST) (envelope-from stpeter@stpeter.im) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by mailhost.dizzyd.com (Postfix) with ESMTPSA id 5B77240CEE; Mon, 8 Jun 2009 15:08:28 -0600 (MDT) Message-ID: <4A2D7DCB.8050603@stpeter.im> Date: Mon, 08 Jun 2009 15:08:27 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Nikunj R. Mehta" CC: atom-syntax@imc.org, atom-protocol@imc.org Subject: Re: Exploring a new WG around Atom References: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> In-Reply-To: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/8/09 2:41 PM, Nikunj R. Mehta wrote: > > Recent discussions on the atom-syntax mailing list has revealed interest > in creating a new WG to look at several extensions of Atom. Here are > several extensions that have been discussed: > > 1. Hierarchy operations including meta-publishing > 2. In-line representation > 3. Bi-directional text > > Please respond to this email if you are interested in helping to explore > a new WG further. I'm interested in helping with this at the IETF. Perhaps at BOF at the Stockholm IETF meeting is in order? The official BOF deadline is today, but we could at least hold a Bar BOF. > Please also identify if you have a specific interest > area to consider for a potential new Atom WG. I do not have specific interests at this time. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkotfcsACgkQNL8k5A2w/vwipwCg7aelhxWuIeRiQHr8YTJIZaNd IrAAn05rytsKqRP6U9SH4Fwzi/zQMjVQ =qjqD -----END PGP SIGNATURE----- From owner-atom-syntax@mail.imc.org Mon Jun 8 14:22:53 2009 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 7FC983A6D06 for ; Mon, 8 Jun 2009 14:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 qbykfxRreh+R for ; Mon, 8 Jun 2009 14:22:52 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B3F0A3A682D for ; Mon, 8 Jun 2009 14:22:51 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58Kmoeh022187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 13:48:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58KmoRt022186; Mon, 8 Jun 2009 13:48: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 acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58Kmm8w022180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jun 2009 13:48:49 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58Kk1ZS001448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Jun 2009 20:46:02 GMT Received: from abhmt010.oracle.com (abhmt010.oracle.com [141.146.116.19]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58KnoOO027774; Mon, 8 Jun 2009 20:49:51 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Jun 2009 13:48:43 -0700 Cc: atom-syntax Message-Id: <8C2CB1CB-16F2-479C-9BAD-5F306F03DC57@oracle.com> From: "Nikunj R. Mehta" To: James M Snell In-Reply-To: <4A2D7808.7070003@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Comments on hierarchy draft Date: Mon, 8 Jun 2009 13:47:22 -0700 References: <4A2D59A9.9090704@gmail.com> <59BD8EFC-A04D-4F8B-96C7-1F4B60CC9231@oracle.com> <4A2D7808.7070003@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt010.oracle.com [141.146.116.19] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010202.4A2D792C.01DC:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All this makes sense. Will incorporate in a new atom-inline I-D soon. :-) Nikunj http://o-micron.blogspot.com On Jun 8, 2009, at 1:43 PM, James M Snell wrote: > > > Nikunj R. Mehta wrote: >> On Jun 8, 2009, at 11:34 AM, James M Snell wrote: >> >>> >>> Great to see a bunch of activity on the list... I'm finally >>> starting to find time to catch up on what's been going on. The >>> hierarchy draft looks good at first read but I had a few comments >>> and concerns... >> >> Good to have you back in active participation on this list. >> > Good to actually have the time to do so ;-) >>> >>> Forgive me if any of this has already been discussed, there have >>> been a significant number of posts on the hierarchy draft and I >>> simply have not yet had time to dig through them all. >>> >>> Section 2.1 >>> >>> The cardinality model really isn't all that clear to me upon first >>> read of this draft so please bear with me. The draft would seem to >>> indicate that any given entry can have multiple parent entries. >>> Does this mean that the entry can have multiple "up" links, each >>> pointing to a different parent Atom entry document, or a single >>> "up" link pointing to a single Atom feed document containing all >>> of the parent entries? >> >> The cardinality model is defined in Section 4. Section 2 only >> introduces the meanings of certain relation type and a model for >> relating entries and feeds. >> >> The I-D could have claridfied that a multi-parent relation is >> expressed through @type="application/atom+xml;type=feed" in >> combination with @rel=up. >> > Ok... >>> >>> >>> Section 3.2 If the ae:inline element is supposed to allow >>> arbitrary content then it is underspecified. For instance, the >>> atom:content element contains a specific type attribute used to >>> indicate whether the content is text, html, xhtml or some specific >>> media type. If the media-type is binary based, atom:content >>> requires that the contained data be Base64 encoded. If the media- >>> type is text based, atom:content requires that the characters be >>> included as inline-text. If the media-type is xml based, >>> atom:content requires that the xml be in-lined directly. I know >>> the specification indicates that the optional type attribute of >>> the enclosing atom:link element is intended to provide the >>> necessary information, I think it would make far more sense for >>> the ae:inline element to have it's own type attribute modeled >>> after the atom:content type attribute. e.g. >> type="text">, . >> >> Wouldn't this merely repeat information from the atom:link element? >> Why is it a better model? What happens if the atom:link @type and >> ae:inline @type differ from each other? >> > Yes and no. The sematics of the atom:link type attribute currently > only apply to the media type of the linked resource and is intended > only as a hint. It is possible that the linked resource is a > completely different media type than that specified by the type > attribute. Further, the type attribute does not utilize the special > "text", "html" and "xhtml" values used in atom:content. Therefore, > if the link uses type="text/html", should the content of the > ae:inline element be processed using the rules for atom:content/ > @type="html" or atom:content/@type="text/html"? There are subtle yet > important differences between the two. The differences become even > more pronounced when dealing with type="xhtml" vs. type="application/ > xhtml+xml". I think that if you're going to point to the > atom:content processing model as the rule for ae:inline, then you > need ae:inline to have it's own type attribute and not rely on the > link elements type attribute. If the two are mismatched, then you > treat it no differently than if the value of the atom:link/@type > does not match the actual content type of the linked resource. >>> >>> It would also make sense to explicitly spell out the processing >>> model as is done in RFC 4287 for atom:content rather than just >>> saying "process the value of ae:inline per the processing model >>> for atom:content as specified in Section 4.1.3.3 of [RFC4287]". >> >> Of course, the full processing model can be specified in the I-D, >> but we intentionally referred to the atom:content processing model >> as the archetype. If the best way to specify this behavior is to >> repeat the text in hierarchy I-D, that can be easily done. >> > In the past, I've used both approaches in drafts I've authored. The > feedback I've received from others has consistently favored > repeating the text in order to make the requirements absolutely clear. > > - James >>> >>> Section 4 >>> >> >> >> We are separately discussing this topic, so omitting here >> >>> Section 5.3: There is a bug in the example. The and >> atom:feed> closing tags have been transposed. >>> >> Noted. Thanks! >> >> From owner-atom-syntax@mail.imc.org Mon Jun 8 15:24:10 2009 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 078843A67E3 for ; Mon, 8 Jun 2009 15:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.107 X-Spam-Level: X-Spam-Status: No, score=-3.107 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 qX5rYGqGnZFW for ; Mon, 8 Jun 2009 15:24:07 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C00F33A63CB for ; Mon, 8 Jun 2009 15:24:05 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MBfC2025776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 15:11:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58MBfcY025774; Mon, 8 Jun 2009 15:11: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 e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MBU2d025755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Jun 2009 15:11:41 -0700 (MST) (envelope-from albertcbrown@us.ibm.com) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n58M9VrZ019616; Mon, 8 Jun 2009 16:09:31 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n58MBTku044164; Mon, 8 Jun 2009 16:11:29 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n58MBSNE016819; Mon, 8 Jun 2009 16:11:29 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n58MBQqr016775; Mon, 8 Jun 2009 16:11:26 -0600 In-Reply-To: <4A2D5EDC.1020207@gmail.com> References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> Subject: Re: Fwd: New Version Notification for draft-divilly-atom-hierarchy-01 X-KeepSent: 0E5CEE35:559023E6-882575CF:0077F470; type=4; name=$KeepSent To: James M Snell Cc: Atom-Syntax Syntax , "Nikunj R. Mehta" , owner-atom-syntax@mail.imc.org, atom-protocol Protocol X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: Al Brown Date: Mon, 8 Jun 2009 15:11:10 -0700 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Build V851_04282009|April 28, 2009) at 06/08/2009 16:11:26 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBFF5CDFE472E08f9e8a93df938690918c07BBFF5CDFE472E0" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0__=07BBFF5CDFE472E08f9e8a93df938690918c07BBFF5CDFE472E0 Content-type: multipart/alternative; Boundary="1__=07BBFF5CDFE472E08f9e8a93df938690918c07BBFF5CDFE472E0" --1__=07BBFF5CDFE472E08f9e8a93df938690918c07BBFF5CDFE472E0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable James wrote: >Hmmm.... I know we've discussed this, but after thinking about it more= >and looking through the examples, I'm becoming increasingly less >convinced that we need a distinction between "down" and "down-tree". >One should simply assume that "down" could point to a child entry or >child feed and that those children could potentially also be parents. >Yes, that possibly increases the processing compexity but I think it >simplifies the model overall. We've discussed this today on the phone. For me this is a difference o= f protocol/hypermedia vs. syntax. For syntax, "down" and "up" are sufficient. A flat model can modeled with feed and a tree can be model= ed using generic inlining in a feed or entry. A client requests an atom document - entry or feed. How does the serve= r advertise to the client, via what is in the atom document, here are two= links to representations (flat vs. tree) of a resource, e.g. the folder= 's children: one link returns a flat list (no inlining) and one link retu= rns a tree (inlined). Both are the same document just with or without inli= ning of linked resources of a particular link relation. Since the resources= are crossing the wire, the first resource (e.g., folder) needs to convey ho= w access a hierarchical resource (e.g., items in a folder) in either a fl= at mode (feed) or tree (feed with inlined resources). The options I see are: a. append -tree to link relations that may inline (e.g., down-tree, up-tree). Not so nice, but works. b. add a new attribute to link that specifies if they are inlined (down) (down-tree) This adds complexity if there are cardinality constraints on link= relations such as alternate and clients not aware of I-D may think they= are the same. c. leverage link templates rather than link relations d. use out of band communication - append a uri argument such as includeLinkRel=3Ddown to the URI of the resource; could also be HTTP he= ader. Not very RESTful but works. If the model is not sufficient to convey to the client here's a flat mo= de vs. here's a tree mode, CMIS will have to find another alternative as i= t is currently required by the CMIS domain model. I see the options for CMIS as: 1. Leverage the model specified by the I-D if exists (best) 2. Move down-tree to CMIS namespace. This does not solve the protocol/hypermedia problem for anybody else. 3. Specify in the CMIS specification an URI argument to enable inlining= of 'down'. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of th= e person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please noti= fy the sender. Please also permanently delete all copies of the original message and any attached documentation. = From: James M Snell = = To: Al Brown/Costa Mesa/IBM@IBMUS = = Cc: "Nikunj R. Mehta" , Atom-Syntax = Syntax , owner-atom-syntax@mail.imc.org = = Date: 06/08/2009 11:55 AM = = Subject: Re: Fwd: New Version Notification for draft-divilly-atom-= hierarchy-01 = Comments below... Al Brown wrote: > > The 01 draft is a much better. I am concerned the generic mechanism > using inlining links is sub-optimal for displaying a hierarchy that > this I-D helps navigate via the new link relations. > in-lining arbitrarily complex hierarchies is always going to be problematic and suboptimal... which is why I was so adamant about not baking hierarchy into Atom and Atompub in the first place when we were working on all this stuff initially. Despite the added verbosity that this approach adds, however, I think it's likely the most acceptable approach. > First example: there are two down relations: down and down-tree. It i= s > important to have both of those link relations on the [standalone] > atom entry that represents a folder so the client can chose a flat > (feed) or tree (expanded feed) representation. If the client chooses > the tree representation, then on the atom feed returned the server > will inline using the link relation down. down-tree is not expanded > with content inline. E.g., > > > ... > > href=3D"/finance/feeds/default/portfolios/1/positions"> > > > > > ... > > href=3D"/finance/feeds/default/portfolios/1/positions"/> > ... > > > > > ... > href=3D"/finance/feeds/default/portfolios/1/positions/down"> > > > href=3D"/finance/feeds-tree/default/portfolios/1/positions/down" /> > > ... > > > > ... > ... > > > > href=3D"/finance/feeds-tree/default/portfolios/1/positions" /> > > ... > > > The contents of the down link relation will be what should be include= d > in the down-tree due to recursion through the atom entries. Having a > separate extension element, side-steps this issue of expression. > Hmmm.... I know we've discussed this, but after thinking about it more and looking through the examples, I'm becoming increasingly less convinced that we need a distinction between "down" and "down-tree". One should simply assume that "down" could point to a child entry or child feed and that those children could potentially also be parents. Yes, that possibly increases the processing compexity but I think it simplifies the model overall. > Second example: verbosity > This proposal now has: > > ... > href=3D"/finance/feeds/default/portfolios/1/positions"> > > > href=3D"/finance/feeds/default/portfolios/1/positions"/> > ... > ... > ... > ... > > > > ... > > > instead of a simpler mechanism: > > ... > > ... > ... > ... > > ... > > > The I-D introduces a concept of hierarchy through > up/up-tree/down-tree/down relations yet a all-purpose mechanism for > inclusion. Most (all?) of the information on the feed element is > duplicated on the enclosing entry (id, uri, etc). Can't we do better > for this specific scenario the I-D is addressing? > I think we can address this by eliminating the restriction that "down" and "up" must always point to Atom feed documents and by changing the cardinality rules for those links. That restriction, I think, is arbitrary and unnecessary It would allow us to do something like.... ... ... ... ... ... ... Unlike any of the other methods discussed, this approach would allow clients that don't understand the hierarchy model to still understand that there is some kind of link relationship with each of the individua= l child resources and eliminates the need to include the extraneous atom:feed metadata. Note that this is the same basic approach taken by my comment thread extension (in-reply-to). - James = --1__=07BBFF5CDFE472E08f9e8a93df938690918c07BBFF5CDFE472E0 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable James wrote: >Hmmm.... I know we've discussed this, but after thinking about = it more >and looking through the examples, I'm becoming increasingly less >convinced that we need a distinction between "down" and &= quot;down-tree". >One should simply assume that "down" could point to a chi= ld entry or >child feed and that those children could potentially also be parent= s. >Yes, that possibly increases the processing compexity but I think i= t >simplifies the model overall. We've discussed this today on the phone. For me this is a dif= ference of protocol/hypermedia vs. syntax. For syntax, "down= " and "up" are sufficient. A flat model can modele= d with feed and a tree can be modeled using generic inlining in a feed = or entry. A client requests an atom document - entry or feed. How does = the server advertise to the client, via what is in the atom document, h= ere are two links to representations (flat vs. tree) of a resource, e.g= . the folder's children: one link returns a flat list (no inlinin= g) and one link returns a tree (inlined). Both are the same docum= ent just with or without inlining of linked resources of a particular l= ink relation. Since the resources are crossing the wire, the firs= t resource (e.g., folder) needs to convey how access a hierarchical res= ource (e.g., items in a folder) in either a flat mode (feed) or tree (f= eed with inlined resources). The options I see are: a. append -tree to link relations that may inline (e.g., down-tree, up-= tree). Not so nice, but works. b. add a new attribute to link that specifies if they are inlined (down) <link rel=3D"down" href=3D"http://www.example= .com/foo/down" /> (down-tree) <link rel=3D"down" ah:inlined=3D"true&qu= ot; href=3D"http://www.example.com/foo/down/inlined" /> This adds complexity if there are cardinality constraints on link rela= tions such as alternate and clients not aware of I-D may think they are= the same. c. leverage link templates rather than link relations d. use out of band communication - append a uri argument such as includ= eLinkRel=3Ddown to the URI of the resource; could also be HTTP header. = Not very RESTful but works. If the model is not sufficient to convey to the client here's a flat mo= de vs. here's a tree mode, CMIS will have to find another alternative a= s it is currently required by the CMIS domain model. I see the options for CMIS as: 1. Leverage the model specified by the I-D if exists (best) 2. Move down-tree to CMIS namespace. This does not solve the protocol/= hypermedia problem for anybody else. 3. Specify in the CMIS specification an URI argument to enable inlining= of 'down'. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: ht= tps://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. James M Snell ---06/08/2009 11:55:37 AM---Comments below... = From: = James M Snell <jasnell@gmail.com> To: Al Brown/Costa Mesa/IBM@IBMUS Cc: "Nikunj R. Mehta" <nikunj.mehta@oracle.co= m>, Atom-Syntax Syntax <atom-syntax@imc.org>, owner-atom-synta= x@mail.imc.org Date: = 06/08/2009 11:55 AM Subject: Re: Fwd: New Version Notification for draft-divilly-at= om-hierarchy-01 Comments below... Al Brown wrote: > > The 01 draft is a much better. I am concerned the generic mechanis= m > using inlining links is sub-optimal for displaying a hierarchy tha= t > this I-D helps navigate via the new link relations. > in-lining arbitrarily complex hierarchies is always going to be problematic and suboptimal... which is why I was so adamant about not <= br> baking hierarchy into Atom and Atompub in the first place when we were = working on all this stuff initially. Despite the added verbosity = that this approach adds, however, I think it's likely the most acceptable approach. > First example: there are two down relations: down and down-tree. I= t is > important to have both of those link relations on the [standalone]= > atom entry that represents a folder so the client can chose a flat= > (feed) or tree (expanded feed) representation. If the client choos= es > the tree representation, then on the atom feed returned the server= > will inline using the link relation down. down-tree is not expande= d > with content inline. E.g., > > <atom:entry> > ... >  > <atom:link rel=3D"down" type=3D"application/atom= +xml;type=3Dfeed" > href=3D"/finance/feeds/default/portfolios/1/positions"&g= t; > <ae:inline> > <atom:feed> >  > <atom:entry> > ... >  > <atom:link rel=3D"down" > href=3D"/finance/feeds/default/portfolios/1/positions"/&= gt; > ... > <ae:inline> > <atom:feed> >  > <atom:entry> > ... > <atom:link rel=3D"down" > href=3D"/finance/feeds/default/portfolios/1/positions/down&qu= ot;> >  > </atom:link> > <atom:link rel=3D"down-tree" > href=3D"/finance/feeds-tree/default/portfolios/1/positions/do= wn" /> > > ... > </atom:entry> > </atom:feed> > </ae:inline> > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > </atom:feed> > </ae:inline> > </atom:link> > <atom:link rel=3D"down-tree" type=3D"application= /atom+xml;type=3Dfeed" > href=3D"/finance/feeds-tree/default/portfolios/1/positions&qu= ot; /> > > ... > </atom:entry> > > The contents of the down link relation will be what should be incl= uded > in the down-tree due to recursion through the atom entries. Having= a > separate extension element, side-steps this issue of expression. > Hmmm.... I know we've discussed this, but after thinking about it more = and looking through the examples, I'm becoming increasingly less convinced that we need a distinction between "down" and "= ;down-tree". One should simply assume that "down" could point to a child e= ntry or child feed and that those children could potentially also be parents. <= br> Yes, that possibly increases the processing compexity but I think it simplifies the model overall. > Second example: verbosity > This proposal now has: > <atom:entry> > ... > <atom:link rel=3D"down" type=3D"application/atom= +xml;type=3Dfeed" > href=3D"/finance/feeds/default/portfolios/1/positions"&g= t; > <ae:inline> > <atom:feed> > <atom:link rel=3D"self" > href=3D"/finance/feeds/default/portfolios/1/positions"/&= gt; > ... > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > </atom:feed> > </ae:inline> > </atom:link> > ... > </atom:entry> > > instead of a simpler mechanism: > <atom:entry> > ... > <ah:include rel=3D"down"> > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > </ah:include> > ... > </atom:entry> > > The I-D introduces a concept of hierarchy through > up/up-tree/down-tree/down relations yet a all-purpose mechanism fo= r > inclusion. Most (all?) of the information on the feed element is <= br> > duplicated on the enclosing entry (id, uri, etc). Can't we do bett= er > for this specific scenario the I-D is addressing? > I think we can address this by eliminating the restriction that "d= own" and "up" must always point to Atom feed documents and by chan= ging the cardinality rules for those links. That restriction, I think, is arbitrary and unnecessary It would allow us to do something like.... <atom:entry> ... <atom:link rel=3D"down" type=3D"application/atom+xml;= type=3Dentry" href=3D"child1"> <ae:inline> <atom:entry>...</atom:entry> </ae:inline> </atom:link> <atom:link rel=3D"down" type=3D"application/atom+xml;= type=3Dentry" href=3D"child2"> <ae:inline> <atom:entry>...</atom:entry> </ae:inline> </atom:link> ... <atom:link rel=3D"down" type=3D"application/atom+xml;= type=3Dentry" href=3D"childN"> <ae:inline> <atom:entry>...</atom:entry> </ae:inline> </atom:link> ... </atom:entry> Unlike any of the other methods discussed, this approach would allow clients that don't understand the hierarchy model to still understand <= br> that there is some kind of link relationship with each of the individua= l child resources and eliminates the need to include the extraneous atom:feed metadata. Note that this is the same basic approach taken by my comment thread extension (in-reply-to). - James = --1__=07BBFF5CDFE472E08f9e8a93df938690918c07BBFF5CDFE472E0-- --0__=07BBFF5CDFE472E08f9e8a93df938690918c07BBFF5CDFE472E0 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBFF5CDFE472E08f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBFF5CDFE472E08f9e8a93df938690918c07BBFF5CDFE472E0 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=07BBFF5CDFE472E08f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBFF5CDFE472E08f9e8a93df938690918c07BBFF5CDFE472E0-- From owner-atom-syntax@mail.imc.org Mon Jun 8 15:27:21 2009 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 290793A67E3 for ; Mon, 8 Jun 2009 15:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.281 X-Spam-Level: X-Spam-Status: No, score=-3.281 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgSHY6CJndy2 for ; Mon, 8 Jun 2009 15:27:19 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 73B6B3A63CB for ; Mon, 8 Jun 2009 15:27:19 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58ME5Bq025950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 15:14:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58ME5Fe025949; Mon, 8 Jun 2009 15:14:05 -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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.145]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58ME3TI025942 for ; Mon, 8 Jun 2009 15:14:04 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qw-out-1920.google.com with SMTP id 14so2628400qwa.28 for ; Mon, 08 Jun 2009 15:14:03 -0700 (PDT) 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:content-type :content-transfer-encoding; bh=tMQlr66+JRAzaTGRh/D8cVMaGKxaLbb/GYbXg22rcFw=; b=IonSSzMrioUD5lzwyUe+uKFC8a7wZTjY9ZXp33BtzmIzyyUg92NidYeRpZv0lcggun FKUbEdOk9u0op8bsbBuE3iLLJ1T5n5tRpnVCpbs4UaSx1/t1FLyhkyFpm1pnNuT+pJCd C9fPuHMqJiAbvJoU4Re0UniOkz/jNCjMWr21E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=eEPBwuIGvn2tomVx1ePRbQiC5x5pIxJ9Ugch41kurOzP7/5jTyDBWZ2lRDy/u3H2UP /kEQsFlCmQNeV81F2I0r+AjaWzNlR4M8cW1NIg/M+QKT3k541TwzZlIZB7k0OdRWWSEk TAB3aUflbYjAcpNbl0uILYqBkvPsFdRPYmfq4= Received: by 10.224.80.145 with SMTP id t17mr7321638qak.351.1244499243683; Mon, 08 Jun 2009 15:14:03 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 2sm382519qwi.23.2009.06.08.15.14.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 15:14:02 -0700 (PDT) Message-ID: <4A2D8D62.60007@gmail.com> Date: Mon, 08 Jun 2009 15:14:58 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: atom-syntax Subject: Atompub Features Draft Dead for Good? 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: Ok, so we'd made quite a bit of progress on the Atom features draft a while back and then I decided to sit and watch to see if there was a strong enough need for the extensions. At this point, I have not seen anyone jumping up and down demanding the functionality provided by the Features draft so I'm wondering if I should just consider it Dead for Good. Thoughts? From owner-atom-syntax@mail.imc.org Mon Jun 8 15:41:57 2009 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 17C6C3A63CB for ; Mon, 8 Jun 2009 15:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.084 X-Spam-Level: X-Spam-Status: No, score=-5.084 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 cWMlgWE38yGQ for ; Mon, 8 Jun 2009 15:41:55 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BD4DF28C156 for ; Mon, 8 Jun 2009 15:41:53 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MVWUN026762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 15:31:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58MVWRS026761; Mon, 8 Jun 2009 15:31:32 -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 rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MVVIi026755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jun 2009 15:31:31 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58MVE8x027655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Jun 2009 22:31:15 GMT Received: from abhmt009.oracle.com (abhmt009.oracle.com [141.146.116.18]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58MVUV7019669; Mon, 8 Jun 2009 22:31:31 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Jun 2009 15:31:24 -0700 Cc: James M Snell , atom-syntax Syntax Message-Id: <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com> From: "Nikunj R. Mehta" To: Al Brown In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2--94967829 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 Date: Mon, 8 Jun 2009 15:30:04 -0700 References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt009.oracle.com [141.146.116.18] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4A2D913E.00AA:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2--94967829 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit As I see it, whether there is a @rel=down-tree or not, you would have to communicate certain information out-of-band, e.g., depth of the tree or the level of completeness in every in-lined entry. Atom does not provide any means of advertising URIs for retrieving representation variants. This could be a source of your dissatisfaction but it applies equally well regardless of hierarchy or in-lining. On Jun 8, 2009, at 3:11 PM, Al Brown wrote: > James wrote: > >Hmmm.... I know we've discussed this, but after thinking about it > more > >and looking through the examples, I'm becoming increasingly less > >convinced that we need a distinction between "down" and "down-tree". > >One should simply assume that "down" could point to a child entry or > >child feed and that those children could potentially also be parents. > >Yes, that possibly increases the processing compexity but I think it > >simplifies the model overall. > > We've discussed this today on the phone. For me this is a > difference of protocol/hypermedia vs. syntax. For syntax, "down" > and "up" are sufficient. A flat model can modeled with feed and a > tree can be modeled using generic inlining in a feed or entry. > > A client requests an atom document - entry or feed. How does the > server advertise to the client, via what is in the atom document, > here are two links to representations (flat vs. tree) of a resource, > e.g. the folder's children: one link returns a flat list (no > inlining) and one link returns a tree (inlined). > It is no different from seeing an HTML vs. a PDF representation of the same blog entry. One gives you a lot of context such as comments, related posts, advertisements and the like, and the other may be limited. This problem, AFAICT, exists regardless of CMIS or hierarchy. > Both are the same document just with or without inlining of linked > resources of a particular link relation. > For all practical purposes, they are different documents, i.e., different representations of a single resource. > Since the resources are crossing the wire, the first resource (e.g., > folder) needs to convey how access a hierarchical resource (e.g., > items in a folder) in either a flat mode (feed) or tree (feed with > inlined resources). > > The options I see are: > a. append -tree to link relations that may inline (e.g., down-tree, > up-tree). Not so nice, but works. > It may not be specific enough anyway to say this is a tree link because it says nothing about depth > b. add a new attribute to link that specifies if they are inlined > (down) > (down-tree) > This adds complexity if there are cardinality constraints on link > relations such as alternate and clients not aware of I-D may think > they are the same. > IMHO, ah:inlined does nothing because the presence of ae:inline makes it plenty clear. If you were trying to say that there is a certain level of depth in the tree, may be an attribute would help, but even then you don't know what things the server may have elided from every entry. So, bottom line is, there is not much value to an attribute to describe the thing that is in-lined. You are best off using what you have received as an approximation and then get the exact representation if you care so much in a separate network call. Of course, out-of-band communication or specialized mark-up may provide enough information for you to avoid such round-trips. > c. leverage link templates rather than link relations > I am not aware of "link templates". If you are referring to draft- gregorio-uri-templates, then too there is no notion of templates baked in to the link element yet. > d. use out of band communication - append a uri argument such as > includeLinkRel=down to the URI of the resource; could also be HTTP > header. Not very RESTful but works. > > If the model is not sufficient to convey to the client here's a flat > mode vs. here's a tree mode, CMIS will have to find another > alternative as it is currently required by the CMIS domain model. > > I see the options for CMIS as: > 1. Leverage the model specified by the I-D if exists (best) > 2. Move down-tree to CMIS namespace. This does not solve the > protocol/hypermedia problem for anybody else. > 3. Specify in the CMIS specification an URI argument to enable > inlining of 'down'. > > -Al > > Al Brown > Emerging Standards and Industry Frameworks > CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home > Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home > > Office 714 327 3453 > Mobile 714 263 6441 > Email albertcbrown@us.ibm.com > CONFIDENTIAL NOTICE: The contents of this message, including any > attachments, are confidential and are intended solely for the use of > the person or entity to whom the message was addressed. If you are > not the intended recipient of this message, please be advised that > any dissemination, distribution, or use of the contents of this > message is strictly prohibited. If you received this message in > error, please notify the sender. Please also permanently delete all > copies of the original message and any attached documentation. > > James M Snell ---06/08/2009 11:55:37 AM---Comments > below... > > > From: > James M Snell > > To: > Al Brown/Costa Mesa/IBM@IBMUS > > Cc: > "Nikunj R. Mehta" , Atom-Syntax Syntax >, owner-atom-syntax@mail.imc.org > > Date: > 06/08/2009 11:55 AM > > Subject: > Re: Fwd: New Version Notification for draft-divilly-atom-hierarchy-01 > > > > Comments below... > > Al Brown wrote: > > > > The 01 draft is a much better. I am concerned the generic mechanism > > using inlining links is sub-optimal for displaying a hierarchy that > > this I-D helps navigate via the new link relations. > > > in-lining arbitrarily complex hierarchies is always going to be > problematic and suboptimal... which is why I was so adamant about not > baking hierarchy into Atom and Atompub in the first place when we were > working on all this stuff initially. Despite the added verbosity that > this approach adds, however, I think it's likely the most acceptable > approach. > > > First example: there are two down relations: down and down-tree. > It is > > important to have both of those link relations on the [standalone] > > atom entry that represents a folder so the client can chose a flat > > (feed) or tree (expanded feed) representation. If the client chooses > > the tree representation, then on the atom feed returned the server > > will inline using the link relation down. down-tree is not expanded > > with content inline. E.g., > > > > > > ... > > > > > href="/finance/feeds/default/portfolios/1/positions"> > > > > > > > > > > ... > > > > > href="/finance/feeds/default/portfolios/1/positions"/> > > ... > > > > > > > > > > ... > > > href="/finance/feeds/default/portfolios/1/positions/down"> > > > > > > > href="/finance/feeds-tree/default/portfolios/1/positions/down" /> > > > > ... > > > > > > > > ... > > ... > > > > > > > > > href="/finance/feeds-tree/default/portfolios/1/positions" /> > > > > ... > > > > > > The contents of the down link relation will be what should be > included > > in the down-tree due to recursion through the atom entries. Having a > > separate extension element, side-steps this issue of expression. > > > Hmmm.... I know we've discussed this, but after thinking about it more > and looking through the examples, I'm becoming increasingly less > convinced that we need a distinction between "down" and "down-tree". > One should simply assume that "down" could point to a child entry or > child feed and that those children could potentially also be parents. > Yes, that possibly increases the processing compexity but I think it > simplifies the model overall. > > > Second example: verbosity > > This proposal now has: > > > > ... > > > href="/finance/feeds/default/portfolios/1/positions"> > > > > > > > href="/finance/feeds/default/portfolios/1/positions"/> > > ... > > ... > > ... > > ... > > > > > > > > ... > > > > > > instead of a simpler mechanism: > > > > ... > > > > ... > > ... > > ... > > > > ... > > > > > > The I-D introduces a concept of hierarchy through > > up/up-tree/down-tree/down relations yet a all-purpose mechanism for > > inclusion. Most (all?) of the information on the feed element is > > duplicated on the enclosing entry (id, uri, etc). Can't we do better > > for this specific scenario the I-D is addressing? > > > I think we can address this by eliminating the restriction that "down" > and "up" must always point to Atom feed documents and by changing the > cardinality rules for those links. That restriction, I think, is > arbitrary and unnecessary > > It would allow us to do something like.... > > > ... > href="child1"> > > ... > > > href="child2"> > > ... > > > ... > href="childN"> > > ... > > > ... > > > Unlike any of the other methods discussed, this approach would allow > clients that don't understand the hierarchy model to still understand > that there is some kind of link relationship with each of the > individual > child resources and eliminates the need to include the extraneous > atom:feed metadata. > > Note that this is the same basic approach taken by my comment thread > extension (in-reply-to). > > - James > > --Apple-Mail-2--94967829 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable As I see it, whether there is a = @rel=3Ddown-tree or not, you would have to communicate certain = information = out-of-band, e.g., depth of the tree or = ;the level of completeness in every in-lined= entry. Atom does not provide any means of = advertising URIs for retrieving representation variants. This could be a = source of your dissatisfaction but it applies equally well regardless of = hierarchy or in-lining. On Jun 8, 2009, at = 3:11 PM, Al Brown wrote: James wrote: >Hmmm.... I know we've = discussed this, but after thinking about it more >and looking = through the examples, I'm becoming increasingly less >convinced = that we need a distinction between "down" and "down-tree". = >One should simply assume that "down" could point to a child entry or = >child feed and that those children could potentially also be = parents. >Yes, that possibly increases the processing compexity = but I think it >simplifies the model overall. = We've discussed this today on the phone. For me this is a = difference of protocol/hypermedia vs. syntax. For syntax, "down" = and "up" are sufficient. A flat model can modeled with feed and a = tree can be modeled using generic inlining in a feed or entry. = A client requests an atom document - entry or feed. How = does the server advertise to the client, via what is in the atom = document, here are two links to representations (flat vs. tree) of a = resource, e.g. the folder's children: one link returns a flat list = (no inlining) and one link returns a tree (inlined). = It is no different from seeing an HTML = vs. a PDF representation of the same blog entry. One gives you a lot of = context such as comments, related posts, advertisements and the like, = and the other may be limited. This problem, AFAICT, exists regardless of = CMIS or hierarchy. Both are the = same document just with or without inlining of linked resources of a = particular link relation. For all = practical purposes, they are different documents, i.e., different = representations of a single resource. Since the resources are crossing the wire, the = first resource (e.g., folder) needs to convey how access a hierarchical = resource (e.g., items in a folder) in either a flat mode (feed) or tree = (feed with inlined resources). The options I see = are: a. append -tree to link relations that may inline (e.g., = down-tree, up-tree). Not so nice, but = works. It may not be specific enough anyway to = say this is a tree link because it says nothing about = depth b. add a new attribute to = link that specifies if they are inlined (down) <link = rel=3D"down" href=3D"http://www.example.com/foo/down" /> (down-tree) <link rel=3D"down" ah:inlined=3D"true" = href=3D"http://www.example.com/fo= o/down/inlined" /> This adds complexity if there are = cardinality constraints on link relations such as alternate and clients = not aware of I-D may think they are the = same. IMHO, ah:inlined does nothing because = the presence of ae:inline makes it plenty clear. If you were trying to = say that there is a certain level of depth in the tree, may be an = attribute would help, but even then you don't know what things the = server may have elided from every entry. So, bottom line is, there is = not much value to an attribute to describe the thing that is in-lined. = You are best off using what you have received as an approximation and = then get the exact representation if you care so much in a separate = network call. Of course, out-of-band communication or specialized = mark-up may provide enough information for you to avoid such = round-trips. c. leverage link = templates rather than link relations I am not = aware of "link templates". If you are referring to = draft-gregorio-uri-templates, then too there is no notion of templates = baked in to the link element yet. = d. use out of band communication - append a uri argument such as = includeLinkRel=3Ddown to the URI of the resource; could also be HTTP = header. Not very RESTful but works. If the model is not = sufficient to convey to the client here's a flat mode vs. here's a tree = mode, CMIS will have to find another alternative as it is currently = required by the CMIS domain model. I see the options for CMIS = as: 1. Leverage the model specified by the I-D if exists (best) = 2. Move down-tree to CMIS namespace. This does not solve the = protocol/hypermedia problem for anybody else. 3. Specify in the CMIS = specification an URI argument to enable inlining of 'down'. = -Al Al Brown Emerging Standards and Industry Frameworks = CMIS: https://w3.tap= .ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.i= bm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 = Mobile 714 263 6441 Email albertcbrown@us.ibm.com = CONFIDENTIAL NOTICE: The contents of this message, including any = attachments, are confidential and are intended solely for the use of the = person or entity to whom the message was addressed. If you are not the = intended recipient of this message, please be advised that any = dissemination, distribution, or use of the contents of this message is = strictly prohibited. If you received this message in error, please = notify the sender. Please also permanently delete all copies of the = original message and any attached documentation. = <graycol.gif>James M Snell = ---06/08/2009 11:55:37 AM---Comments below... = <ecblank.gif> From: <ecblank.gif> James= M Snell <jasnell@gmail.com> <ecblank.gif> To: <ecblank.gif> Al = Brown/Costa Mesa/IBM@IBMUS <ecblank.gif> Cc: <ecblank.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.com>, = Atom-Syntax Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.= org <ecblank.gif> Date: <ecblank.gif> 06/08/2009 11:55 AM <ecblank.gif> Subject: <ecblank.gif> Re: = Fwd: New Version Notification for = draft-divilly-atom-hierarchy-01 = Comments below... = Al Brown wrote: > > The 01 draft is a much better. I am = concerned the generic mechanism > using inlining links is = sub-optimal for displaying a hierarchy that > this I-D helps = navigate via the new link relations. > in-lining arbitrarily = complex hierarchies is always going to be problematic and = suboptimal... which is why I was so adamant about not baking = hierarchy into Atom and Atompub in the first place when we were = working on all this stuff initially. Despite the added verbosity = that this approach adds, however, I think it's likely the most = acceptable approach. > First example: there are two = down relations: down and down-tree. It is > important to have = both of those link relations on the [standalone] > atom entry = that represents a folder so the client can chose a flat > (feed) = or tree (expanded feed) representation. If the client chooses > = the tree representation, then on the atom feed returned the server = > will inline using the link relation down. down-tree is not expanded = > with content inline. E.g., > > = <atom:entry> > ... >  > <atom:link rel=3D"down" = type=3D"application/atom+xml;type=3Dfeed" > = href=3D"/finance/feeds/default/portfolios/1/positions"> > = <ae:inline> > <atom:feed> >  > <atom:entry> > ... >  > <atom:link rel=3D"down" = > href=3D"/finance/feeds/default/portfolios/1/positions"/> = > ... > <ae:inline> > <atom:feed> > =  > <atom:entry> > ... = > <atom:link rel=3D"down" > = href=3D"/finance/feeds/default/portfolios/1/positions/down"> > =  > </atom:link> > = <atom:link rel=3D"down-tree" > = href=3D"/finance/feeds-tree/default/portfolios/1/positions/down" = /> > > ... > </atom:entry> > = </atom:feed> > </ae:inline> > = <atom:entry>...</atom:entry> > = <atom:entry>...</atom:entry> > </atom:feed> = > </ae:inline> > </atom:link> > = <atom:link rel=3D"down-tree" = type=3D"application/atom+xml;type=3Dfeed" > = href=3D"/finance/feeds-tree/default/portfolios/1/positions" /> = > > ... > </atom:entry> > > The = contents of the down link relation will be what should be included = > in the down-tree due to recursion through the atom entries. Having = a > separate extension element, side-steps this issue of = expression. > Hmmm.... I know we've discussed this, but after = thinking about it more and looking through the examples, I'm = becoming increasingly less convinced that we need a distinction = between "down" and "down-tree". One should simply assume that = "down" could point to a child entry or child feed and that those = children could potentially also be parents. Yes, that possibly = increases the processing compexity but I think it simplifies the = model overall. > Second example: verbosity > This = proposal now has: > <atom:entry> > ... > = <atom:link rel=3D"down" type=3D"application/atom+xml;type=3Dfeed" = > href=3D"/finance/feeds/default/portfolios/1/positions"> > = <ae:inline> > <atom:feed> > <atom:link = rel=3D"self" > = href=3D"/finance/feeds/default/portfolios/1/positions"/> > = ... > <atom:entry>...</atom:entry> > = <atom:entry>...</atom:entry> > = <atom:entry>...</atom:entry> > </atom:feed> = > </ae:inline> > </atom:link> > ... = > </atom:entry> > > instead of a simpler = mechanism: > <atom:entry> > ... > = <ah:include rel=3D"down"> > = <atom:entry>...</atom:entry> > = <atom:entry>...</atom:entry> > = <atom:entry>...</atom:entry> > = </ah:include> > ... > </atom:entry> = > > The I-D introduces a concept of hierarchy through = > up/up-tree/down-tree/down relations yet a all-purpose mechanism for = > inclusion. Most (all?) of the information on the feed element = is > duplicated on the enclosing entry (id, uri, etc). Can't we = do better > for this specific scenario the I-D is = addressing? > I think we can address this by eliminating the = restriction that "down" and "up" must always point to Atom feed = documents and by changing the cardinality rules for those links. = That restriction, I think, is arbitrary and unnecessary It = would allow us to do something like.... <atom:entry> = ... <atom:link rel=3D"down" = type=3D"application/atom+xml;type=3Dentry" href=3D"child1"> = <ae:inline> <atom:entry>...</atom:entry> = </ae:inline> </atom:link> <atom:link rel=3D"down" = type=3D"application/atom+xml;type=3Dentry" href=3D"child2"> = <ae:inline> <atom:entry>...</atom:entry> = </ae:inline> </atom:link> ... <atom:link = rel=3D"down" type=3D"application/atom+xml;type=3Dentry" = href=3D"childN"> <ae:inline> = <atom:entry>...</atom:entry> </ae:inline> = </atom:link> ... </atom:entry> Unlike any = of the other methods discussed, this approach would allow clients = that don't understand the hierarchy model to still understand that = there is some kind of link relationship with each of the individual = child resources and eliminates the need to include the extraneous = atom:feed metadata. Note that this is the same basic approach = taken by my comment thread extension (in-reply-to). - = James = = --Apple-Mail-2--94967829-- From owner-atom-syntax@mail.imc.org Mon Jun 8 15:50:04 2009 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 192A03A6894 for ; Mon, 8 Jun 2009 15:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=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 mLwTQhnOvWwP for ; Mon, 8 Jun 2009 15:50:03 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 071613A6886 for ; Mon, 8 Jun 2009 15:50:02 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58McuXv027017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 15:38:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58Mcut3027016; Mon, 8 Jun 2009 15:38: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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.148]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58Mcjnj026993 for ; Mon, 8 Jun 2009 15:38:55 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qw-out-1920.google.com with SMTP id 14so2642095qwa.28 for ; Mon, 08 Jun 2009 15:38:45 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=uMNJYe/BHq7ZSSjHJG0DvE/fsj6BJFgIXi/xHtMjWiM=; b=DTc+aD2lgKzCuifwN43acChPNEenLq6p4h6PDotBNxy512TcOnLrbk8iU/fImL5JCr LlkQ5Ism5ve41lr6Mtgv6ij2lXQWFhGMYWjnQqD4VRYVO7AJZ28m1rkgwFhNi9l++SQu stdrv5rxUwfZhz8NUtGO+kBl3qbjhEWEJH5Bk= 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:content-type:content-transfer-encoding; b=qpEuAq/vRuqmsNizpj2GuhaXbPz1hCh9kLFBoSop6I/oSa1iZQejhGgWr/a/6cteCQ NNjh3SQUtrdrOSPVHAS8duYuBizHUSySn0BHpgK3KZJ8TBHHPuXYrC0jrLmcxgC3TROr th9pU0Bc4DtFt/D44LqKnrxaGIKwMlZlZbuYM= Received: by 10.224.89.3 with SMTP id c3mr7346607qam.373.1244500724946; Mon, 08 Jun 2009 15:38:44 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 5sm300241qwg.35.2009.06.08.15.38.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 15:38:44 -0700 (PDT) Message-ID: <4A2D932B.2040400@gmail.com> Date: Mon, 08 Jun 2009 15:39:39 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Nikunj R. Mehta" CC: Al Brown , atom-syntax Syntax Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com> In-Reply-To: <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com> 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: Nikunj R. Mehta wrote: > As I see it, whether there is a @rel=down-tree or not, you would have > to communicate certain information > out-of-band, e.g., depth of the tree or the level of completeness in every in-lined entry. > > Right, which is why I'm not sure if the distinction between down and down-tree is meaningful enough. You're still going to have to look at the out-of-band info to figure out what you need to do with it. > > IMHO, ah:inlined does nothing because the presence of ae:inline makes > it plenty clear. If you were trying to say that there is a certain > level of depth in the tree, may be an attribute would help, but even > then you don't know what things the server may have elided from every > entry. So, bottom line is, there is not much value to an attribute to > describe the thing that is in-lined. You are best off using what you > have received as an approximation and then get the exact > representation if you care so much in a separate network call. Of > course, out-of-band communication or specialized mark-up may provide > enough information for you to avoid such round-trips. +1 >> >> c. leverage link templates rather than link relations >> > I am not aware of "link templates". If you are referring to > draft-gregorio-uri-templates, then too there is no notion of templates > baked in to the link element yet. This came from a discussion Al and I were having offline. Basically, I've worked up some ideas on how to use Joe G.'s URI templates within an Atom entry as a form of link-template. I need to get that fully documented. - James From owner-atom-syntax@mail.imc.org Mon Jun 8 15:51:36 2009 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 693173A6BC6 for ; Mon, 8 Jun 2009 15:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.13 X-Spam-Level: X-Spam-Status: No, score=-3.13 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ejm56HYZbshC for ; Mon, 8 Jun 2009 15:51:35 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id CF4683A6980 for ; Mon, 8 Jun 2009 15:51:34 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MecX6027143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 15:40:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58MecK6027142; Mon, 8 Jun 2009 15:40: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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.146]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MebNd027136 for ; Mon, 8 Jun 2009 15:40:38 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qw-out-1920.google.com with SMTP id 14so2643037qwa.28 for ; Mon, 08 Jun 2009 15:40:37 -0700 (PDT) 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:content-type :content-transfer-encoding; bh=1pFa2zKMWyNYsLrHDTOsZ8C2COYoQdvhMRkRYHcepmw=; b=D4wRkMf8KuxA4jQqBcwSG4NHjsSkDPLQQNZCPvYEfIglmRMz8x4FuFCgXmu7WldIlW 92za6UxWOj3OxDKCnnefHV7Hs3FyTc0GDv+DKnJ4x6FeYgp7Vu4Jat5afNV19bJv399q 1XqbLOZ0BgqN9WbeY1JLwqnWigKdzEi/6vI/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=hZ34/SxmWDTX1Zo/s86nm68DQB6kTB68Jlb12yvGmyChnHiX4U+Re35LAh4iiptRFC jcBdUFTe3SGvLZiHxmtu+wxrgCbh8lsZeLK0SnVr6FAs8Tzix6r/vYopAJBliQPgjMaY JyOFPXq2wi+n/XHFxCEMsTB1TDAcKQn22eVRM= Received: by 10.224.11.136 with SMTP id t8mr7353836qat.305.1244500837017; Mon, 08 Jun 2009 15:40:37 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 5sm24041qwg.5.2009.06.08.15.40.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 15:40:36 -0700 (PDT) Message-ID: <4A2D939C.9040609@gmail.com> Date: Mon, 08 Jun 2009 15:41:32 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: atom-syntax Subject: Atom Tombstones Draft Revitalized 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: As requested, the Atom Tombstones draft has been revitalized. http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-06.txt Changed this from Experimental to Informational and updated the IPR boilerplate. - James From owner-atom-syntax@mail.imc.org Mon Jun 8 15:56:25 2009 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 DA02F28C116 for ; Mon, 8 Jun 2009 15:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, SARE_OBFU_SPLIT_HR2=0.183, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 egS7ktMn3geX for ; Mon, 8 Jun 2009 15:56:23 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B637E3A6BC6 for ; Mon, 8 Jun 2009 15:56:22 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MjCSI027278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 15:45:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58MjCKl027277; Mon, 8 Jun 2009 15:45: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 e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MjCPJ027271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jun 2009 15:45:12 -0700 (MST) (envelope-from albertcbrown@us.ibm.com) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e31.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n58MeuYW016286 for ; Mon, 8 Jun 2009 16:40:56 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n58MjBaZ258714 for ; Mon, 8 Jun 2009 16:45:11 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id n58Mjj8Z017395 for ; Mon, 8 Jun 2009 16:45:45 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av06.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id n58Mjj7C017390; Mon, 8 Jun 2009 16:45:45 -0600 In-Reply-To: <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com> References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com> Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 X-KeepSent: F6C94627:F2D911AC-882575CF:007C33F4; type=4; name=$KeepSent To: "Nikunj R. Mehta" Cc: atom-syntax Syntax , James M Snell X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: Al Brown Date: Mon, 8 Jun 2009 15:44:55 -0700 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Build V851_04282009|April 28, 2009) at 06/08/2009 16:45:10 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBFF5CDFEFB5648f9e8a93df938690918c07BBFF5CDFEFB564" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0__=07BBFF5CDFEFB5648f9e8a93df938690918c07BBFF5CDFEFB564 Content-type: multipart/alternative; Boundary="1__=07BBFF5CDFEFB5648f9e8a93df938690918c07BBFF5CDFEFB564" --1__=07BBFF5CDFEFB5648f9e8a93df938690918c07BBFF5CDFEFB564 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Nikunj wrote: > Al Brown wrote: b. add a new attribute to link that specifies if they are inlined= (down) (down-tree) This adds complexity if there are cardinality constraints on link= relations such as alternate and clients not aware of I-D may thin= k they are the same. >IMHO, ah:inlined does nothing because the presence of ae:inline makes = it plenty clear. If you were trying to say that there is a certain level o= f depth in the tree, may >be an attribute would help, but even then you d= on't know what things the server may have elided from every entry. So, botto= m line is, there is not much value to an >attribute to describe the thing= that is in-lined. You are best off using what you have received as an approximation and then get the exact representation if you care so >muc= h in a separate network call. Of course, out-of-band communication or specialized mark-up may provide enough information for you to avoid suc= h round-trips. Maybe I did not explain clearly enough - this is a protocol/hypermedia issue. How does the client say (follow the right link relation) I want= an inlined representation of this resource specified by a link relation? E.g., Client (C) navigates to this atom entry (A) somehow. A wants to advert= ise to the client that A has references to two to representations for resou= rce B. One version of B is flat (ala a feed). One version of B is the sam= e flat feed with its link relations inlined (ala tree). How can resource A provide the client C with information there are two choices available for B (flat vs tree)? -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of th= e person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please noti= fy the sender. Please also permanently delete all copies of the original message and any attached documentation. = From: "Nikunj R. Mehta" = = To: Al Brown/Costa Mesa/IBM@IBMUS = = Cc: James M Snell , atom-syntax Syntax = Date: 06/08/2009 03:33 PM = = Subject: Re: New Version Notification for draft-divilly-atom-hiera= rchy-01 = As I see it, whether there is a @rel=3Ddown-tree or not, you would have= to communicate certain information out-of-band, e.g., depth of the tree or= the level of completeness in every in-lined entry. Atom does not provide any means of advertising URIs for retrieving representation variants. This could be a source of your dissatisfaction= but it applies equally well regardless of hierarchy or in-lining. On Jun 8, 2009, at 3:11 PM, Al Brown wrote: James wrote: >Hmmm.... I know we've discussed this, but after thinking about i= t more >and looking through the examples, I'm becoming increasingly less= >convinced that we need a distinction between "down" and "down-tr= ee". >One should simply assume that "down" could point to a child entr= y or >child feed and that those children could potentially also be parents. >Yes, that possibly increases the processing compexity but I thin= k it >simplifies the model overall. We've discussed this today on the phone. For me this is a differ= ence of protocol/hypermedia vs. syntax. For syntax, "down" and "up" a= re sufficient. A flat model can modeled with feed and a tree can be= modeled using generic inlining in a feed or entry. A client requests an atom document - entry or feed. How does the= server advertise to the client, via what is in the atom document,= here are two links to representations (flat vs. tree) of a resour= ce, e.g. the folder's children: one link returns a flat list (no inlining) and one link returns a tree (inlined). It is no different from seeing an HTML vs. a PDF representation of the = same blog entry. One gives you a lot of context such as comments, related po= sts, advertisements and the like, and the other may be limited. This problem= , AFAICT, exists regardless of CMIS or hierarchy. Both are the same document just with or without inlining of linke= d resources of a particular link relation. For all practical purposes, they are different documents, i.e., differe= nt representations of a single resource. Since the resources are crossing the wire, the first resource (e.= g., folder) needs to convey how access a hierarchical resource (e.g.,= items in a folder) in either a flat mode (feed) or tree (feed wit= h inlined resources). The options I see are: a. append -tree to link relations that may inline (e.g., down-tre= e, up-tree). Not so nice, but works. It may not be specific enough anyway to say this is a tree link because= it says nothing about depth b. add a new attribute to link that specifies if they are inlined= (down) (down-tree) This adds complexity if there are cardinality constraints on link= relations such as alternate and clients not aware of I-D may thin= k they are the same. IMHO, ah:inlined does nothing because the presence of ae:inline makes i= t plenty clear. If you were trying to say that there is a certain level o= f depth in the tree, may be an attribute would help, but even then you do= n't know what things the server may have elided from every entry. So, botto= m line is, there is not much value to an attribute to describe the thing = that is in-lined. You are best off using what you have received as an approximation and then get the exact representation if you care so much= in a separate network call. Of course, out-of-band communication or specialized mark-up may provide enough information for you to avoid suc= h round-trips. c. leverage link templates rather than link relations I am not aware of "link templates". If you are referring to draft-gregorio-uri-templates, then too there is no notion of templates baked in to the link element yet. d. use out of band communication - append a uri argument such as includeLinkRel=3Ddown to the URI of the resource; could also be H= TTP header. Not very RESTful but works. If the model is not sufficient to convey to the client here's a f= lat mode vs. here's a tree mode, CMIS will have to find another alternative as it is currently required by the CMIS domain model.= I see the options for CMIS as: 1. Leverage the model specified by the I-D if exists (best) 2. Move down-tree to CMIS namespace. This does not solve the protocol/hypermedia problem for anybody else. 3. Specify in the CMIS specification an URI argument to enable inlining of 'down'. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/= Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use= of the person or entity to whom the message was addressed. If you ar= e not the intended recipient of this message, please be advised tha= t any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete a= ll copies of the original message and any attached documentation. James M Snell ---06/08/2009 11:55:37 AM---Comments below... = = k.gif> James M Snell = From: = = = k.gif> Al Brown/Costa Mesa/IBM@IBMUS = To: = = = k.gif> "Nikunj R. Mehta" , Atom-Syntax Synta= x < Cc: atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org = = = k.gif> 06/08/2009 11:55 AM = Date: = = = k.gif> Re: Fwd: New Version Notification for = Subject draft-divilly-atom-hierarchy-01 = : = = Comments below... Al Brown wrote: > > The 01 draft is a much better. I am concerned the generic mecha= nism > using inlining links is sub-optimal for displaying a hierarchy = that > this I-D helps navigate via the new link relations. > in-lining arbitrarily complex hierarchies is always going to be problematic and suboptimal... which is why I was so adamant about= not baking hierarchy into Atom and Atompub in the first place when we= were working on all this stuff initially. Despite the added verbosity= that this approach adds, however, I think it's likely the most accepta= ble approach. > First example: there are two down relations: down and down-tree= . It is > important to have both of those link relations on the [standalo= ne] > atom entry that represents a folder so the client can chose a f= lat > (feed) or tree (expanded feed) representation. If the client chooses > the tree representation, then on the atom feed returned the ser= ver > will inline using the link relation down. down-tree is not expa= nded > with content inline. E.g., > > > ... > > href=3D"/finance/feeds/default/portfolios/1/positions"> > > > > > ... > > href=3D"/finance/feeds/default/portfolios/1/positions"/> > ... > > > > > ... > href=3D"/finance/feeds/default/portfolios/1/positions/down"> > > > href=3D"/finance/feeds-tree/default/portfolios/1/positions/down= " /> > > ... > > > > ... > ... > > > > href=3D"/finance/feeds-tree/default/portfolios/1/positions" /> > > ... > > > The contents of the down link relation will be what should be included > in the down-tree due to recursion through the atom entries. Hav= ing a > separate extension element, side-steps this issue of expression= . > Hmmm.... I know we've discussed this, but after thinking about it= more and looking through the examples, I'm becoming increasingly less convinced that we need a distinction between "down" and "down-tre= e". One should simply assume that "down" could point to a child entry= or child feed and that those children could potentially also be pare= nts. Yes, that possibly increases the processing compexity but I think= it simplifies the model overall. > Second example: verbosity > This proposal now has: > > ... > href=3D"/finance/feeds/default/portfolios/1/positions"> > > > href=3D"/finance/feeds/default/portfolios/1/positions"/> > ... > ... > ... > ... > > > > ... > > > instead of a simpler mechanism: > > ... > > ... > ... > ... > > ... > > > The I-D introduces a concept of hierarchy through > up/up-tree/down-tree/down relations yet a all-purpose mechanism= for > inclusion. Most (all?) of the information on the feed element i= s > duplicated on the enclosing entry (id, uri, etc). Can't we do better > for this specific scenario the I-D is addressing? > I think we can address this by eliminating the restriction that "down" and "up" must always point to Atom feed documents and by changing= the cardinality rules for those links. That restriction, I think, is arbitrary and unnecessary It would allow us to do something like.... ... ... ... ... ... ... Unlike any of the other methods discussed, this approach would al= low clients that don't understand the hierarchy model to still unders= tand that there is some kind of link relationship with each of the individual child resources and eliminates the need to include the extraneous= atom:feed metadata. Note that this is the same basic approach taken by my comment thr= ead extension (in-reply-to). - James = --1__=07BBFF5CDFEFB5648f9e8a93df938690918c07BBFF5CDFEFB564 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable Nikunj wrote: > Al Brown wrote: b. add a new attribute to link that specifies if t= hey are inlined (down) <link rel=3D"down" href=3D"h= ttp://www.example.com/foo/down" /&= gt; (down-tree) <link rel=3D"down" ah:inlined=3D"true&quo= t; href=3D"http://www.example.com/foo/do= wn/inlined" /> This adds complexity if there are cardinality constraints on link relat= ions such as alternate and clients not aware of I-D may think they are = the same. >IMHO, ah:inlined does nothing because the presence= of ae:inline makes it plenty clear. If you were trying to say that the= re is a certain level of depth in the tree, may >be an attribute wou= ld help, but even then you don't know what things the server may have e= lided from every entry. So, bottom line is, there is not much value to = an >attribute to describe the thing that is in-lined. You are best o= ff using what you have received as an approximation and then get the ex= act representation if you care so >much in a separate network call. = Of course, out-of-band communication or specialized mark-up may provide= enough information for you to avoid such round-trips. Maybe I did not explain clearly enough - this is a protocol/hypermed= ia issue. How does the client say (follow the right link relation) I = want an inlined representation of this resource specified by a link rel= ation? E.g., Client (C) navigates to this atom entry (A) somehow. A wants to adv= ertise to the client that A has references to two to representations fo= r resource B. One version of B is flat (ala a feed). One version of B= is the same flat feed with its link relations inlined (ala tree). How can resource A provide the client C with information there are t= wo choices available for B (flat vs tree)? -Al Al Brown Emerging Standards and Industry Frameworks CMIS: ht= tps://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. "Ni= kunj R. Mehta" ---06/08/2009 03:33:06 PM---As I see it, whether th= ere is a @rel=3Ddown-tree or not, you would have to communicate certain= information out-of-band, e.g., dep = From: = "Nikunj R. Mehta" <nikunj.mehta@oracle.co= m> To: Al Brown/Costa Mesa/IBM@IBMUS Cc: James M Snell <jasnell@gmail.com>, atom-syntax S= yntax <atom-syntax@imc.org> Date: = 06/08/2009 03:33 PM Subject: Re: New Version Notification for draft-divilly-atom-hi= erarchy-01 As I see it, whether there is a @rel=3Ddown-tree or no= t, you would have to communicate certain information out-of-band, e.g.,= depth of the tree or the level of completeness in every in-lined entry= . Atom does not provide any means of advertising URIs fo= r retrieving representation variants. This could be a source of your di= ssatisfaction but it applies equally well regardless of hierarchy or in= -lining. On Jun 8, 2009, at 3:11 PM, Al Brown wrote: = James wrote: >Hmmm.... I know we've discussed this, but after thinking about it m= ore >and looking through the examples, I'm becoming increasingly less >convinced that we need a distinction between "down" and &= quot;down-tree". >One should simply assume that "down" could point to a chi= ld entry or >child feed and that those children could potentially also be parent= s. >Yes, that possibly increases the processing compexity but I think i= t >simplifies the model overall. We've discussed this today on the phone. For me this is a differe= nce of protocol/hypermedia vs. syntax. For syntax, "down&quo= t; and "up" are sufficient. A flat model can modeled wi= th feed and a tree can be modeled using generic inlining in a feed or e= ntry. A client requests an atom document - entry or feed. How does the = server advertise to the client, via what is in the atom document, here = are two links to representations (flat vs. tree) of a resource, e.g. th= e folder's children: one link returns a flat list (no inlining) a= nd one link returns a tree (inlined). It is no different from seeing an HTML vs. a PDF repre= sentation of the same blog entry. One gives you a lot of context such a= s comments, related posts, advertisements and the like, and the other m= ay be limited. This problem, AFAICT, exists regardless of CMIS or hiera= rchy. Both are the same document just with or withou= t inlining of linked resources of a particular link relation. For all practical purposes, they are different documen= ts, i.e., different representations of a single resource. Since the resources are crossing the wire, the= first resource (e.g., folder) needs to convey how access a hierarchica= l resource (e.g., items in a folder) in either a flat mode (feed) or tr= ee (feed with inlined resources). The options I see are: a. append -tree to link relations that may inline (e.g., down-tree, up-= tree). Not so nice, but works. It may not be specific enough anyway to say this is a = tree link because it says nothing about depth b. add a new attribute to link that specifies if t= hey are inlined (down) <link rel=3D"down" href=3D"h= ttp://www.example.com/foo/down" /&= gt; (down-tree) <link rel=3D"down" ah:inlined=3D"true&quo= t; href=3D"http://www.example.com/foo/do= wn/inlined" /> This adds complexity if there are cardinality constraints on link relat= ions such as alternate and clients not aware of I-D may think they are = the same. IMHO, ah:inlined does nothing because the presence of = ae:inline makes it plenty clear. If you were trying to say that there i= s a certain level of depth in the tree, may be an attribute would help,= but even then you don't know what things the server may have elided fr= om every entry. So, bottom line is, there is not much value to an attri= bute to describe the thing that is in-lined. You are best off using wha= t you have received as an approximation and then get the exact represen= tation if you care so much in a separate network call. Of course, out-o= f-band communication or specialized mark-up may provide enough informat= ion for you to avoid such round-trips. c. leverage link templates rather than link relati= ons I am not aware of "link templates". If you a= re referring to draft-gregorio-uri-templates, then too there is no noti= on of templates baked in to the link element yet. d. use out of band communication - append a uri ar= gument such as includeLinkRel=3Ddown to the URI of the resource; could = also be HTTP header. Not very RESTful but works. If the model is not sufficient to convey to the client here's a flat mo= de vs. here's a tree mode, CMIS will have to find another alternative a= s it is currently required by the CMIS domain model. I see the options for CMIS as: 1. Leverage the model specified by the I-D if exists (best) 2. Move down-tree to CMIS namespace. This does not solve the protocol/h= ypermedia problem for anybody else. 3. Specify in the CMIS specification an URI argument to enable inlining= of 'down'. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki0= 7/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.= ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. <graycol.gif>James M Sn= ell ---06/08/2009 11:55:37 AM---Comments below... = <ecblank.gif&g= t; From: <ecblank.gif>= James M Snell <jasnell@gmail.com> <ecblank.gif&g= t; To: <ecblank.gif> Al Brown/Costa Mesa/IBM@IBMUS <ecblank.gif&g= t; Cc: <= ;ecblank.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.com&g= t;, Atom-Syntax Syntax <atom-syntax@imc.org>, owne= r-atom-syntax@mail.imc.org <ecblank.gif&g= t; Date: <ecblank.gif>= 06/08/2009 11:55 AM <ecblank.gif&g= t; Subject: <ecblank.gif&= gt; Re: Fwd: New Version Notification for draft-divilly-atom-hierarchy-01 <= br> Comments below... Al Brown wrote: > > The 01 draft is a much better. I am concerned the generic mechanis= m > using inlining links is sub-optimal for displaying a hierarchy tha= t > this I-D helps navigate via the new link relations. > in-lining arbitrarily complex hierarchies is always going to be problematic and suboptimal... which is why I was so adamant about not <= br> baking hierarchy into Atom and Atompub in the first place when we were = working on all this stuff initially. Despite the added verbosity = that this approach adds, however, I think it's likely the most acceptable approach. > First example: there are two down relations: down and down-tree. I= t is > important to have both of those link relations on the [standalone]= > atom entry that represents a folder so the client can chose a flat= > (feed) or tree (expanded feed) representation. If the client choos= es > the tree representation, then on the atom feed returned the server= > will inline using the link relation down. down-tree is not expande= d > with content inline. E.g., > > <atom:entry> > ... >  > <atom:link rel=3D"down" type=3D"application/atom= +xml;type=3Dfeed" > href=3D"/finance/feeds/default/portfolios/1/positions"&g= t; > <ae:inline> > <atom:feed> >  > <atom:entry> > ... >  > <atom:link rel=3D"down" > href=3D"/finance/feeds/default/portfolios/1/positions"/&= gt; > ... > <ae:inline> > <atom:feed> >  > <atom:entry> > ... > <atom:link rel=3D"down" > href=3D"/finance/feeds/default/portfolios/1/positions/down&qu= ot;> >  > </atom:link> > <atom:link rel=3D"down-tree" > href=3D"/finance/feeds-tree/default/portfolios/1/positions/do= wn" /> > > ... > </atom:entry> > </atom:feed> > </ae:inline> > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > </atom:feed> > </ae:inline> > </atom:link> > <atom:link rel=3D"down-tree" type=3D"application= /atom+xml;type=3Dfeed" > href=3D"/finance/feeds-tree/default/portfolios/1/positions&qu= ot; /> > > ... > </atom:entry> > > The contents of the down link relation will be what should be incl= uded > in the down-tree due to recursion through the atom entries. Having= a > separate extension element, side-steps this issue of expression. > Hmmm.... I know we've discussed this, but after thinking about it more = and looking through the examples, I'm becoming increasingly less convinced that we need a distinction between "down" and "= ;down-tree". One should simply assume that "down" could point to a child e= ntry or child feed and that those children could potentially also be parents. <= br> Yes, that possibly increases the processing compexity but I think it simplifies the model overall. > Second example: verbosity > This proposal now has: > <atom:entry> > ... > <atom:link rel=3D"down" type=3D"application/atom= +xml;type=3Dfeed" > href=3D"/finance/feeds/default/portfolios/1/positions"&g= t; > <ae:inline> > <atom:feed> > <atom:link rel=3D"self" > href=3D"/finance/feeds/default/portfolios/1/positions"/&= gt; > ... > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > </atom:feed> > </ae:inline> > </atom:link> > ... > </atom:entry> > > instead of a simpler mechanism: > <atom:entry> > ... > <ah:include rel=3D"down"> > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > </ah:include> > ... > </atom:entry> > > The I-D introduces a concept of hierarchy through > up/up-tree/down-tree/down relations yet a all-purpose mechanism fo= r > inclusion. Most (all?) of the information on the feed element is <= br> > duplicated on the enclosing entry (id, uri, etc). Can't we do bett= er > for this specific scenario the I-D is addressing? > I think we can address this by eliminating the restriction that "d= own" and "up" must always point to Atom feed documents and by chan= ging the cardinality rules for those links. That restriction, I think, is arbitrary and unnecessary It would allow us to do something like.... <atom:entry> ... <atom:link rel=3D"down" type=3D"application/atom+xml;= type=3Dentry" href=3D"child1"> <ae:inline> <atom:entry>...</atom:entry> </ae:inline> </atom:link> <atom:link rel=3D"down" type=3D"application/atom+xml;= type=3Dentry" href=3D"child2"> <ae:inline> <atom:entry>...</atom:entry> </ae:inline> </atom:link> ... <atom:link rel=3D"down" type=3D"application/atom+xml;= type=3Dentry" href=3D"childN"> <ae:inline> <atom:entry>...</atom:entry> </ae:inline> </atom:link> ... </atom:entry> Unlike any of the other methods discussed, this approach would allow clients that don't understand the hierarchy model to still understand <= br> that there is some kind of link relationship with each of the individua= l child resources and eliminates the need to include the extraneous atom:feed metadata. Note that this is the same basic approach taken by my comment thread extension (in-reply-to). - James = --1__=07BBFF5CDFEFB5648f9e8a93df938690918c07BBFF5CDFEFB564-- --0__=07BBFF5CDFEFB5648f9e8a93df938690918c07BBFF5CDFEFB564 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBFF5CDFEFB5648f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBFF5CDFEFB5648f9e8a93df938690918c07BBFF5CDFEFB564 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=07BBFF5CDFEFB5648f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBFF5CDFEFB5648f9e8a93df938690918c07BBFF5CDFEFB564-- From owner-atom-syntax@mail.imc.org Mon Jun 8 16:02:29 2009 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 3BEC628C15A for ; Mon, 8 Jun 2009 16:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=-1.393, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=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 e2Ne8u8Um8C8 for ; Mon, 8 Jun 2009 16:02:27 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8826A28C133 for ; Mon, 8 Jun 2009 16:02:26 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MoVG0027510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 15:50:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58MoVag027509; Mon, 8 Jun 2009 15:50:31 -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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.148]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MoUCu027502 for ; Mon, 8 Jun 2009 15:50:30 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qw-out-1920.google.com with SMTP id 14so2648320qwa.28 for ; Mon, 08 Jun 2009 15:50:30 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=0A4FatSzPwlFa9GYgDvcmeO/eclRdXyaAXoXbCp+MUY=; b=hjJW6hCwqVgsiJR1y0n3CQD/W6k/9oDOCHrSycIVeGlLdEoTjVaK5HOpiFy8DHCrcE SFRs5xheANe02r/v8fJITUtmC+d/i6NF4J6hlZaYYhD4W7O7ct81v0iZSMlmHLK9McXY S2VVwhjTur+OeN7YQJztwaVEkjnBqijMkBY6c= 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:content-type:content-transfer-encoding; b=H+0JTSQni1igMwAW6MtVVd5EkMQZlT6G/Ts2jAoZbYAxIRdzrCceQaA9wFrvGVVj0u 7NGTUAMc0X8s1kdfrKnki2m4iar1pmdUDkgPIFB/0XfOjQWYwMDVMpRQaSPfSOEpwxkS ckyKG0tjF0JPNSL5ONoEt2uJqM2/KW05Ai1BU= Received: by 10.224.6.74 with SMTP id 10mr7384562qay.242.1244501429856; Mon, 08 Jun 2009 15:50:29 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 6sm56021qwd.22.2009.06.08.15.50.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 15:50:29 -0700 (PDT) Message-ID: <4A2D95EC.2010308@gmail.com> Date: Mon, 08 Jun 2009 15:51:24 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Al Brown CC: "Nikunj R. Mehta" , atom-syntax Syntax Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com> In-Reply-To: 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: Al Brown wrote: > > Nikunj wrote: > > Al Brown wrote: > > b. add a new attribute to link that specifies if they are > inlined > (down) href="_http://www.example.com/foo/down_" /> > (down-tree) href="_http://www.example.com/foo/down/inlined_" /> > This adds complexity if there are cardinality constraints > on link relations such as alternate and clients not aware > of I-D may think they are the same. > > >IMHO, ah:inlined does nothing because the presence of ae:inline makes > it plenty clear. If you were trying to say that there is a certain > level of depth in the tree, may >be an attribute would help, but even > then you don't know what things the server may have elided from every > entry. So, bottom line is, there is not much value to an >attribute to > describe the thing that is in-lined. You are best off using what you > have received as an approximation and then get the exact > representation if you care so >much in a separate network call. Of > course, out-of-band communication or specialized mark-up may provide > enough information for you to avoid such round-trips. > > Maybe I did not explain clearly enough - this is a protocol/hypermedia > issue. How does the client say (follow the right link relation) I want > an inlined representation of this resource specified by a link > relation? E.g., > > Client (C) navigates to this atom entry (A) somehow. A wants to > advertise to the client that A has references to two to > representations for resource B. One version of B is flat (ala a feed). > One version of B is the same flat feed with its link relations inlined > (ala tree). > > How can resource A provide the client C with information there are two > choices available for B (flat vs tree)? > Such distinctions are usually made by looking at the content-type of the linked resource. Again, forgive me if this has already been discussed elsewhere in this thread, but I would think that some kind of variation on the link type attribute would be appropriate. Perhaps something like the profile media type parameter that has been kicked around before? e.g. (just a strawman) - James > > -Al > > > Al Brown > Emerging Standards and Industry Frameworks > CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home > Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home > > Office 714 327 3453 > Mobile 714 263 6441 > Email albertcbrown@us.ibm.com > CONFIDENTIAL NOTICE: The contents of this message, including any > attachments, are confidential and are intended solely for the use of > the person or entity to whom the message was addressed. If you are not > the intended recipient of this message, please be advised that any > dissemination, distribution, or use of the contents of this message is > strictly prohibited. If you received this message in error, please > notify the sender. Please also permanently delete all copies of the > original message and any attached documentation. > > Inactive hide details for "Nikunj R. Mehta" ---06/08/2009 03:33:06 > PM---As I see it, whether there is a @rel=down-tree or not, "Nikunj R. > Mehta" ---06/08/2009 03:33:06 PM---As I see it, whether there is a > @rel=down-tree or not, you would have to communicate certain > information out-of-band, e.g., dep > > > From: > "Nikunj R. Mehta" > > To: > Al Brown/Costa Mesa/IBM@IBMUS > > Cc: > James M Snell , atom-syntax Syntax > > > Date: > 06/08/2009 03:33 PM > > Subject: > Re: New Version Notification for draft-divilly-atom-hierarchy-01 > > ------------------------------------------------------------------------ > > > > As I see it, whether there is a @rel=down-tree or not, you would have > to communicate certain information out-of-band, e.g., depth of the > tree or the level of completeness in every in-lined entry. > > Atom does not provide any means of advertising URIs for retrieving > representation variants. This could be a source of your > dissatisfaction but it applies equally well regardless of hierarchy or > in-lining. > > On Jun 8, 2009, at 3:11 PM, Al Brown wrote: > > James wrote: > >Hmmm.... I know we've discussed this, but after thinking > about it more > >and looking through the examples, I'm becoming > increasingly less > >convinced that we need a distinction between "down" and > "down-tree". > >One should simply assume that "down" could point to a > child entry or > >child feed and that those children could potentially also > be parents. > >Yes, that possibly increases the processing compexity but > I think it > >simplifies the model overall. > > We've discussed this today on the phone. For me this is a > difference of protocol/hypermedia vs. syntax. For syntax, > "down" and "up" are sufficient. A flat model can modeled > with feed and a tree can be modeled using generic inlining > in a feed or entry. > > A client requests an atom document - entry or feed. How > does the server advertise to the client, via what is in > the atom document, here are two links to representations > (flat vs. tree) of a resource, e.g. the folder's children: > one link returns a flat list (no inlining) and one link > returns a tree (inlined). > > It is no different from seeing an HTML vs. a PDF representation of the > same blog entry. One gives you a lot of context such as comments, > related posts, advertisements and the like, and the other may be > limited. This problem, AFAICT, exists regardless of CMIS or hierarchy. > > Both are the same document just with or without inlining > of linked resources of a particular link relation. > > For all practical purposes, they are different documents, i.e., > different representations of a single resource. > > Since the resources are crossing the wire, the first > resource (e.g., folder) needs to convey how access a > hierarchical resource (e.g., items in a folder) in either > a flat mode (feed) or tree (feed with inlined resources). > > The options I see are: > a. append -tree to link relations that may inline (e.g., > down-tree, up-tree). Not so nice, but works. > > It may not be specific enough anyway to say this is a tree link > because it says nothing about depth > > b. add a new attribute to link that specifies if they are > inlined > (down) href="_http://www.example.com/foo/down_" /> > (down-tree) href="_http://www.example.com/foo/down/inlined_" /> > This adds complexity if there are cardinality constraints > on link relations such as alternate and clients not aware > of I-D may think they are the same. > > IMHO, ah:inlined does nothing because the presence of ae:inline makes > it plenty clear. If you were trying to say that there is a certain > level of depth in the tree, may be an attribute would help, but even > then you don't know what things the server may have elided from every > entry. So, bottom line is, there is not much value to an attribute to > describe the thing that is in-lined. You are best off using what you > have received as an approximation and then get the exact > representation if you care so much in a separate network call. Of > course, out-of-band communication or specialized mark-up may provide > enough information for you to avoid such round-trips. > > c. leverage link templates rather than link relations > > I am not aware of "link templates". If you are referring to > draft-gregorio-uri-templates, then too there is no notion of templates > baked in to the link element yet. > > d. use out of band communication - append a uri argument > such as includeLinkRel=down to the URI of the resource; > could also be HTTP header. Not very RESTful but works. > > If the model is not sufficient to convey to the client > here's a flat mode vs. here's a tree mode, CMIS will have > to find another alternative as it is currently required by > the CMIS domain model. > > I see the options for CMIS as: > 1. Leverage the model specified by the I-D if exists (best) > 2. Move down-tree to CMIS namespace. This does not solve > the protocol/hypermedia problem for anybody else. > 3. Specify in the CMIS specification an URI argument to > enable inlining of 'down'. > > -Al > > Al Brown > Emerging Standards and Industry Frameworks > CMIS: _https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home_ > Industry Frameworks: > _https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home_ > > Office 714 327 3453 > Mobile 714 263 6441 > Email _albertcbrown@us.ibm.com_ > > CONFIDENTIAL NOTICE: The contents of this message, > including any attachments, are confidential and are > intended solely for the use of the person or entity to > whom the message was addressed. If you are not the > intended recipient of this message, please be advised that > any dissemination, distribution, or use of the contents of > this message is strictly prohibited. If you received this > message in error, please notify the sender. Please also > permanently delete all copies of the original message and > any attached documentation. > > James M Snell ---06/08/2009 11:55:37 > AM---Comments below... > > From: > James M Snell <_jasnell@gmail.com_ > > > > To: > Al Brown/Costa Mesa/IBM@IBMUS > > Cc: > "Nikunj R. Mehta" <_nikunj.mehta@oracle.com_ > >, Atom-Syntax Syntax > <_atom-syntax@imc.org_ >, > _owner-atom-syntax@mail.imc.org_ > > > Date: > 06/08/2009 11:55 AM > > Subject: > Re: Fwd: New Version Notification for > draft-divilly-atom-hierarchy-01 > > ------------------------------------------------------------------------ > > > > Comments below... > > Al Brown wrote: > > > > The 01 draft is a much better. I am concerned the > generic mechanism > > using inlining links is sub-optimal for displaying a > hierarchy that > > this I-D helps navigate via the new link relations. > > > in-lining arbitrarily complex hierarchies is always going > to be > problematic and suboptimal... which is why I was so > adamant about not > baking hierarchy into Atom and Atompub in the first place > when we were > working on all this stuff initially. Despite the added > verbosity that > this approach adds, however, I think it's likely the most > acceptable > approach. > > > First example: there are two down relations: down and > down-tree. It is > > important to have both of those link relations on the > [standalone] > > atom entry that represents a folder so the client can > chose a flat > > (feed) or tree (expanded feed) representation. If the > client chooses > > the tree representation, then on the atom feed returned > the server > > will inline using the link relation down. down-tree is > not expanded > > with content inline. E.g., > > > > > > ... > > > > > href="/finance/feeds/default/portfolios/1/positions"> > > > > > > > > > > ... > > > > > href="/finance/feeds/default/portfolios/1/positions"/> > > ... > > > > > > > > > > ... > > > href="/finance/feeds/default/portfolios/1/positions/down"> > > > > > > > > href="/finance/feeds-tree/default/portfolios/1/positions/down" > /> > > > > ... > > > > > > > > ... > > ... > > > > > > > > type="application/atom+xml;type=feed" > > href="/finance/feeds-tree/default/portfolios/1/positions" /> > > > > ... > > > > > > The contents of the down link relation will be what > should be included > > in the down-tree due to recursion through the atom > entries. Having a > > separate extension element, side-steps this issue of > expression. > > > Hmmm.... I know we've discussed this, but after thinking > about it more > and looking through the examples, I'm becoming > increasingly less > convinced that we need a distinction between "down" and > "down-tree". > One should simply assume that "down" could point to a > child entry or > child feed and that those children could potentially also > be parents. > Yes, that possibly increases the processing compexity but > I think it > simplifies the model overall. > > > Second example: verbosity > > This proposal now has: > > > > ... > > > href="/finance/feeds/default/portfolios/1/positions"> > > > > > > > href="/finance/feeds/default/portfolios/1/positions"/> > > ... > > ... > > ... > > ... > > > > > > > > ... > > > > > > instead of a simpler mechanism: > > > > ... > > > > ... > > ... > > ... > > > > ... > > > > > > The I-D introduces a concept of hierarchy through > > up/up-tree/down-tree/down relations yet a all-purpose > mechanism for > > inclusion. Most (all?) of the information on the feed > element is > > duplicated on the enclosing entry (id, uri, etc). Can't > we do better > > for this specific scenario the I-D is addressing? > > > I think we can address this by eliminating the restriction > that "down" > and "up" must always point to Atom feed documents and by > changing the > cardinality rules for those links. That restriction, I > think, is > arbitrary and unnecessary > > It would allow us to do something like.... > > > ... > type="application/atom+xml;type=entry" href="child1"> > > ... > > > type="application/atom+xml;type=entry" href="child2"> > > ... > > > ... > type="application/atom+xml;type=entry" href="childN"> > > ... > > > ... > > > Unlike any of the other methods discussed, this approach > would allow > clients that don't understand the hierarchy model to still > understand > that there is some kind of link relationship with each of > the individual > child resources and eliminates the need to include the > extraneous > atom:feed metadata. > > Note that this is the same basic approach taken by my > comment thread > extension (in-reply-to). > > - James > > > From owner-atom-syntax@mail.imc.org Mon Jun 8 16:04:13 2009 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 9BF6A3A63CB for ; Mon, 8 Jun 2009 16:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.97 X-Spam-Level: X-Spam-Status: No, score=-5.97 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 33ML9MRIl0c3 for ; Mon, 8 Jun 2009 16:04:13 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 873F03A685B for ; Mon, 8 Jun 2009 16:04:12 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58Mr6Uk027598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 15:53:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58Mr5hY027597; Mon, 8 Jun 2009 15:53:05 -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 rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58Mr5Mp027590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jun 2009 15:53:05 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58Mqniu026064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Jun 2009 22:52:50 GMT Received: from abhmt003.oracle.com (abhmt003.oracle.com [141.146.116.12]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58Mr5Fa018542; Mon, 8 Jun 2009 22:53:06 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Jun 2009 15:53:00 -0700 Cc: Al Brown , atom-syntax Syntax Message-Id: <0F6549DC-DB2E-4DBA-8F6A-0C0FABBBB8D8@oracle.com> From: "Nikunj R. Mehta" To: James M Snell In-Reply-To: <4A2D95EC.2010308@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 Date: Mon, 8 Jun 2009 15:51:40 -0700 References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com> <4A2D95EC.2010308@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt003.oracle.com [141.146.116.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4A2D964C.030A:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 8, 2009, at 3:51 PM, James M Snell wrote: > href="..." /> > href="..." /> Just a nit, media type parameters are ',' separated, correct?. From owner-atom-syntax@mail.imc.org Mon Jun 8 16:06:18 2009 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 CA9BD3A6894 for ; Mon, 8 Jun 2009 16:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+KX9de6l+jE for ; Mon, 8 Jun 2009 16:06:18 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id CB8383A685B for ; Mon, 8 Jun 2009 16:06:17 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MsmNe027655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 15:54:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58MsmIo027654; Mon, 8 Jun 2009 15:54: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-qy0-f171.google.com (mail-qy0-f171.google.com [209.85.221.171]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58Msb41027647 for ; Mon, 8 Jun 2009 15:54:47 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk1 with SMTP id 1so4498073qyk.16 for ; Mon, 08 Jun 2009 15:54:37 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=C2/KGcMlgfGODnLHdSIlNT8lpeVQgP/DUQ9Utqw988k=; b=xD07nImIJQL77Nm0p2Se9RbZQuCy0dFdeS1j8ctz9sPXe/dqCBIbz07RDsyw3Etwhe 6LWfTHQu/l4mU75cSxfysZ9wtL/IslimzzS1i8zTNWO0WLLwDfps8Dm29atQeLgSNrtw sRtg9R0n9lx5GQasjqBhH3EKlQ9wPvNYmYlFY= 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:content-type:content-transfer-encoding; b=ZcSDxzIMZxcBM58eoIgWesFEzVI6Z5ypcv/LgnOdnAAKzHmpKsAs6oMpeMEzKalKeQ JaJ9Rs9wXE1TEM/6RZ7WYsnA7ccGgwFt2Zjklyhxm6kbIhkV7fOK+loVqb8tWAM0CTkH EEo5nTH/oljYKAddcUofvpouBCkp8mZ6VIzMQ= Received: by 10.224.74.16 with SMTP id s16mr7356247qaj.320.1244501676700; Mon, 08 Jun 2009 15:54:36 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 7sm132898qwb.6.2009.06.08.15.54.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 15:54:36 -0700 (PDT) Message-ID: <4A2D96E3.2080206@gmail.com> Date: Mon, 08 Jun 2009 15:55:31 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Nikunj R. Mehta" CC: Al Brown , atom-syntax Syntax Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com> <4A2D95EC.2010308@gmail.com> <0F6549DC-DB2E-4DBA-8F6A-0C0FABBBB8D8@oracle.com> In-Reply-To: <0F6549DC-DB2E-4DBA-8F6A-0C0FABBBB8D8@oracle.com> 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: Heh, I think so ;-) Nikunj R. Mehta wrote: > On Jun 8, 2009, at 3:51 PM, James M Snell wrote: > >> > href="..." /> >> > href="..." /> > > > Just a nit, media type parameters are ',' separated, correct?. > From owner-atom-syntax@mail.imc.org Mon Jun 8 16:16:45 2009 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 0E9933A6A84 for ; Mon, 8 Jun 2009 16:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KQyN6jsSzvS for ; Mon, 8 Jun 2009 16:16:43 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 683A33A67ED for ; Mon, 8 Jun 2009 16:16:43 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58N6bff028114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 16:06:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58N6bZN028113; Mon, 8 Jun 2009 16:06:37 -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.14.2/8.14.2) with SMTP id n58N6PIu028104 for ; Mon, 8 Jun 2009 16:06:36 -0700 (MST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 08 Jun 2009 23:06:24 -0000 Received: from dslb-094-223-150-155.pools.arcor-ip.net (EHLO hive) [94.223.150.155] by mail.gmx.net (mp026) with SMTP; 09 Jun 2009 01:06:24 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+f9a5sD+SfgWvkXuE6scTPd9g10uFfKr4WnVW0ha PDUS1shnQsTJav From: Bjoern Hoehrmann To: "Nikunj R. Mehta" Cc: atom-syntax Syntax Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 Date: Tue, 09 Jun 2009 01:06:30 +0200 Message-ID: <5a6r25hl9d27gbpoqb31vjua17komr1vtt@hive.bjoern.hoehrmann.de> References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com> <4A2D95EC.2010308@gmail.com> <0F6549DC-DB2E-4DBA-8F6A-0C0FABBBB8D8@oracle.com> In-Reply-To: <0F6549DC-DB2E-4DBA-8F6A-0C0FABBBB8D8@oracle.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Nikunj R. Mehta wrote: > >On Jun 8, 2009, at 3:51 PM, James M Snell wrote: > >> > href="..." /> >> > href="..." /> > >Just a nit, media type parameters are ',' separated, correct?. No, by ";", see e.g. RFC 2045. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From owner-atom-syntax@mail.imc.org Mon Jun 8 16:16:58 2009 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 7474A3A6A83 for ; Mon, 8 Jun 2009 16:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 xdfnc7Lz5nZ1 for ; Mon, 8 Jun 2009 16:16:57 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2E4DF3A67ED for ; Mon, 8 Jun 2009 16:16:55 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58N5Jo9028083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 16:05:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58N5JrM028082; Mon, 8 Jun 2009 16:05: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 e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58N57P9028069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jun 2009 16:05:18 -0700 (MST) (envelope-from albertcbrown@us.ibm.com) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e39.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n58N17NM008565 for ; Mon, 8 Jun 2009 17:01:07 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n58N578Q092042 for ; Mon, 8 Jun 2009 17:05:07 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n58N56cw020882 for ; Mon, 8 Jun 2009 17:05:07 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n58N56Za020876; Mon, 8 Jun 2009 17:05:06 -0600 In-Reply-To: <4A2D8D62.60007@gmail.com> References: <4A2D8D62.60007@gmail.com> Subject: Re: Atompub Features Draft Dead for Good? X-KeepSent: 343DFFED:81B76A8C-882575CF:007E5C82; type=4; name=$KeepSent To: James M Snell Cc: atom-syntax , owner-atom-syntax@mail.imc.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: Al Brown Date: Mon, 8 Jun 2009 16:04:50 -0700 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Build V851_04282009|April 28, 2009) at 06/08/2009 17:05:06 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBFF5CDFEDDA128f9e8a93df938690918c07BBFF5CDFEDDA12" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0__=07BBFF5CDFEDDA128f9e8a93df938690918c07BBFF5CDFEDDA12 Content-type: multipart/alternative; Boundary="1__=07BBFF5CDFEDDA128f9e8a93df938690918c07BBFF5CDFEDDA12" --1__=07BBFF5CDFEDDA128f9e8a93df938690918c07BBFF5CDFEDDA12 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable CMIS adds CMIS element to the workspace element in the atompub service document. I am not aware of requirements from CMIS for representing features at the collection level. FYI - Here's an example of the features/capabilities CMIS advertises in= the atompub workspace element: repid1 Repository1 self CMIS Repository Description CMIS Vendor 1 CMIS Prototype for VendorX 0.61 rootfolder true true true true true true bothcombined= innerandouter all document folder true 0.61 -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of th= e person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please noti= fy the sender. Please also permanently delete all copies of the original message and any attached documentation. = From: James M Snell = = To: atom-syntax = = Date: 06/08/2009 03:36 PM = = Subject: Atompub Features Draft Dead for Good? = = Ok, so we'd made quite a bit of progress on the Atom features draft a while back and then I decided to sit and watch to see if there was a strong enough need for the extensions. At this point, I have not seen anyone jumping up and down demanding the functionality provided by the Features draft so I'm wondering if I should just consider it Dead for Good. Thoughts? = --1__=07BBFF5CDFEDDA128f9e8a93df938690918c07BBFF5CDFEDDA12 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable CMIS adds CMIS element to the workspace element in the atompub servi= ce document. I am not aware of requirements from CMIS for representing= features at the collection level. FYI - Here's an example of the features/capabilities CMIS advertises in= the atompub workspace element: <n= s5:repositoryInfo&g= t; <ns1:repositoryIdrepid1</ns1:repositoryId> <ns1:repositoryName>Repository1</ns1:repositoryName> <ns1:repositoryRelationship>self</ns1:repositoryRelationship> <ns1:repositoryDescription>CMIS Repository Descri= ption</ns1:repositoryDescription> <ns1:vendorName= >CMIS Vendor 1</ns1:vendorName> <ns1:productName>CMIS Prototype for VendorX</ns1:productName> <ns1:productVersion>0.61</ns1:productVersion> <ns1:rootFolderIdrootfolder</ns1:rootFolderId> <ns1:capabilities <ns1:capabilityMultifiling>true</ns1:capabilityMultifiling> <ns1:capabilityUnfiling>true</ns1:capabilityUnfiling> <ns1:capabilityVersionSpecificFiling>true</ns1:capabilityVersionSpecificFiling> <ns1:capabilityPWCUpdateable>true</ns1:capabilityPWCUpdateable> <ns1:capabilityPWCSearchable>true</ns1:capabilityPWCSearchable> <ns1:capabilityAllVersionsSearchable>true</ns1:capabilityAllVersionsSearchable> <ns1:capabilityQuery>bothcombined</ns1:capabilityQuery> <ns1:capabilityJoin>innerandouter</ns1:capabilityJoin> <ns1:capabilityChanges>all</ns1:capabilityChanges> <ns1:capabilityChangesOnType>document<= font color=3D"#008080" face=3D"Courier New"></ns1:capabilityChangesOnType> <ns1:capabilityChangesOnType>folder</ns1:capabilityChangesOnType> <ns1:changesIncomplete>true</ns1:changesIncomplete> </ns1:capabilities> <ns1:cmisVersionSupported>0.61</ns1:cmisVersionSupported> </= ns5:repositoryInfo&= gt; -Al Al Brown Emerging Standards and Industry Frameworks CMIS: ht= tps://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. James M Snell ---06/= 08/2009 03:36:36 PM---Ok, so we'd made quite a bit of progress on the A= tom features draft a = = From: = James M Snell <jasnell@gmail.com> To: atom-syntax <atom-syntax@imc.org> Date: = 06/08/2009 03:36 PM Subject: Atompub Features Draft Dead for Good? Ok, so we'd made quite a bit of progress on the Atom features draft a <= br> while back and then I decided to sit and watch to see if there was a strong enough need for the extensions. At this point, I have not seen <= br> anyone jumping up and down demanding the functionality provided by the = Features draft so I'm wondering if I should just consider it Dead for <= br> Good. Thoughts? = --1__=07BBFF5CDFEDDA128f9e8a93df938690918c07BBFF5CDFEDDA12-- --0__=07BBFF5CDFEDDA128f9e8a93df938690918c07BBFF5CDFEDDA12 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBFF5CDFEDDA128f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBFF5CDFEDDA128f9e8a93df938690918c07BBFF5CDFEDDA12 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=07BBFF5CDFEDDA128f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBFF5CDFEDDA128f9e8a93df938690918c07BBFF5CDFEDDA12-- From owner-atom-syntax@mail.imc.org Mon Jun 8 16:24:27 2009 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 027513A67ED for ; Mon, 8 Jun 2009 16:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=1.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 T43s-PTFIGnN for ; Mon, 8 Jun 2009 16:24:26 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 44EEB3A63CB for ; Mon, 8 Jun 2009 16:24:25 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58NAfwR028293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 16:10:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58NAfi4028292; Mon, 8 Jun 2009 16:10: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 e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58NAUpL028275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jun 2009 16:10:40 -0700 (MST) (envelope-from albertcbrown@us.ibm.com) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n58N3bYJ001309 for ; Mon, 8 Jun 2009 17:03:37 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n58NATtH226716 for ; Mon, 8 Jun 2009 17:10:29 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id n58NB3q0017367 for ; Mon, 8 Jun 2009 17:11:03 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av06.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id n58NB2YS017362; Mon, 8 Jun 2009 17:11:03 -0600 In-Reply-To: <4A2D96E3.2080206@gmail.com> References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com> <4A2D95EC.2010308@gmail.com> <0F6549DC-DB2E-4DBA-8F6A-0C0FABBBB8D8@oracle.com> <4A2D96E3.2080206@gmail.com> Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 X-KeepSent: 17CBCBC8:EAA8394A-882575CF:007F1F1F; type=4; name=$KeepSent To: James M Snell Cc: atom-syntax Syntax , "Nikunj R. Mehta" X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: Al Brown Date: Mon, 8 Jun 2009 16:10:13 -0700 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Build V851_04282009|April 28, 2009) at 06/08/2009 17:10:28 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBFF5CDFEC998F8f9e8a93df938690918c07BBFF5CDFEC998F" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0__=07BBFF5CDFEC998F8f9e8a93df938690918c07BBFF5CDFEC998F Content-type: multipart/alternative; Boundary="1__=07BBFF5CDFEC998F8f9e8a93df938690918c07BBFF5CDFEC998F" --1__=07BBFF5CDFEC998F8f9e8a93df938690918c07BBFF5CDFEC998F Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable > On Jun 8, 2009, at 3:51 PM, James M Snell wrote: > >> > href=3D"..." /> >> > href=3D"..." /> This works for me. I would like to see the extension to the media type= in the I-D instead of "down-tree" and "up-tree". -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of th= e person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please noti= fy the sender. Please also permanently delete all copies of the original message and any attached documentation. = From: James M Snell = = To: "Nikunj R. Mehta" = = Cc: Al Brown/Costa Mesa/IBM@IBMUS, atom-syntax Syntax = Date: 06/08/2009 03:54 PM = = Subject: Re: New Version Notification for draft-divilly-atom-hiera= rchy-01 = Heh, I think so ;-) Nikunj R. Mehta wrote: > On Jun 8, 2009, at 3:51 PM, James M Snell wrote: > >> > href=3D"..." /> >> > href=3D"..." /> > > > Just a nit, media type parameters are ',' separated, correct?. > = --1__=07BBFF5CDFEC998F8f9e8a93df938690918c07BBFF5CDFEC998F Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable > On Jun 8, 2009, at 3:51 PM, James M Snell wrote: > >> <link rel=3D"down" type=3D"application/atom+= xml;type=3Dfeed;profile=3Dtree" >> href=3D"..." /> >> <link rel=3D"down" type=3D"application/atom+= xml;type=3Dfeed;profile=3Dflat" >> href=3D"..." /> This works for me. I would like to see the extension to the media type= in the I-D instead of "down-tree" and "up-tree". -Al Al Brown Emerging Standards and Industry Frameworks CMIS: ht= tps://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. James M Snell ---06/08/2009 03:54:38 PM---Heh, I think so ;-)= = From: = James M Snell <jasnell@gmail.com> To: "Nikunj R. Mehta" <nikunj.mehta@oracle.co= m> Cc: Al Brown/Costa Mesa/IBM@IBMUS, atom-syntax Syntax <= atom-syntax@imc.org> Date: = 06/08/2009 03:54 PM Subject: Re: New Version Notification for draft-divilly-atom-hi= erarchy-01 Heh, I think so ;-) Nikunj R. Mehta wrote: > On Jun 8, 2009, at 3:51 PM, James M Snell wrote: > >> <link rel=3D"down" type=3D"application/atom+= xml;type=3Dfeed;profile=3Dtree" >> href=3D"..." /> >> <link rel=3D"down" type=3D"application/atom+= xml;type=3Dfeed;profile=3Dflat" >> href=3D"..." /> > > > Just a nit, media type parameters are ',' separated, correct?. = > = --1__=07BBFF5CDFEC998F8f9e8a93df938690918c07BBFF5CDFEC998F-- --0__=07BBFF5CDFEC998F8f9e8a93df938690918c07BBFF5CDFEC998F Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBFF5CDFEC998F8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBFF5CDFEC998F8f9e8a93df938690918c07BBFF5CDFEC998F Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=07BBFF5CDFEC998F8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBFF5CDFEC998F8f9e8a93df938690918c07BBFF5CDFEC998F-- From owner-atom-syntax@mail.imc.org Mon Jun 8 16:27:36 2009 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 D6D843A6894 for ; Mon, 8 Jun 2009 16:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.118 X-Spam-Level: ** X-Spam-Status: No, score=2.118 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 cs82DxrGc3hs for ; Mon, 8 Jun 2009 16:27:32 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4CC113A63CB for ; Mon, 8 Jun 2009 16:27:30 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58NEDgJ028523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 16:14:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58NEDEg028522; Mon, 8 Jun 2009 16:14:13 -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-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58NDtcY028502 for ; Mon, 8 Jun 2009 16:14:11 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by gxk3 with SMTP id 3so547198gxk.10 for ; Mon, 08 Jun 2009 16:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-rim-org-msg-ref-id :return-receipt-to:message-id:reply-to:x-priority:references :in-reply-to:sensitivity:importance:to:cc:subject:from:date :content-type:mime-version; bh=+Pc02uhlffNIYbGH+G2v2NVL5lwy0va908CGggtYzT4=; b=kqtadhiuvuDuhVO0r+tzZNGBpsjFFP96YsjHyxohjF2/q3TX+atmmB7/kz7X4RrmvV Hf8M7txfXm1AmTsZ/efrJEBAeRIr3I56rgiXUtFXnt5Ui3GEINrSqlJZbyLiYbfPJpON yz1RQQ7ouax0CNRUSOZtIw4lSvu4cIg56qF2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-rim-org-msg-ref-id:return-receipt-to:message-id:reply-to :x-priority:references:in-reply-to:sensitivity:importance:to:cc :subject:from:date:content-type:mime-version; b=rvMsIp3VDv0dVWUtQIR0yBFe8PN66D4zM0YiLypm9P9grO8bkH1t9artFumXFBBO5g VTx013b3bM92tXubQgWTAb3q3hYNaeGwuYDDBWA99lFz0Pri8QyCFO3TQVXuPVVv78ft xU7qCsZkezNxoHJoPrYosomqHesqI6ABG8blc= Received: by 10.90.70.6 with SMTP id s6mr2768149aga.118.1244502832747; Mon, 08 Jun 2009 16:13:52 -0700 (PDT) Received: from bda703.bisx.prod.on.blackberry (e703.bda.bis.na.blackberry.com [67.223.79.112]) by mx.google.com with ESMTPS id 5sm954758agc.15.2009.06.08.16.13.51 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 16:13:52 -0700 (PDT) X-rim-org-msg-ref-id:1191335719 Message-ID:<1191335719-1244502830-cardhu_decombobulator_blackberry.rim.net-151986016-@bxe1007.bisx.prod.on.blackberry> Reply-To: jasnell@gmail.com X-Priority: Normal References: <4A2D8D62.60007@gmail.com> In-Reply-To: Sensitivity: Normal Importance: Normal To: "Al Brown" Cc: "atom-syntax" , owner-atom-syntax@mail.imc.org Subject: Re: Atompub Features Draft Dead for Good? From: jasnell@gmail.com Date: Mon, 8 Jun 2009 23:13:52 +0000 Content-Type: multipart/related; type="multipart/alternative"; boundary="part46832-boundary-678742132-1571858873" MIME-Version: 1.0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --part46832-boundary-678742132-1571858873 Content-Type: multipart/alternative; boundary="part46833-boundary-678742132-1571858873" --part46833-boundary-678742132-1571858873 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="Windows-1252" T2sgdGhpcyBpcyBnb29kIHRvIHNlZS4gVGhlIG1haW4gcXVlc3Rpb24gaXMgd2hldGhlciB0aGVy ZSBpcyBzdWZmaWNpZW50IHJlYXNvbiB0byBkZWZpbmUgYSBnZW5lcmljIGZlYXR1cmVzL2NhcGFi aWxpdGllcyBleHRlbnNpb24uIFRoZXJlIGNlcnRhaW5seSBhcmUgZ29vZCBhcmd1bWVudHMgaW4g ZmF2b3IuIElmIGEgZ2VuZXJpYyBleHQgd2FzIGF2YWlsYWJsZSB3b3VsZCBjbWlzIHVzZSBpdD8N Cg0KU2VudCBmcm9tIG15IFZlcml6b24gV2lyZWxlc3MgQmxhY2tCZXJyeQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWwgQnJvd24gPGFsYmVydGNicm93bkB1cy5pYm0uY29t Pg0KDQpEYXRlOiBNb24sIDggSnVuIDIwMDkgMTY6MDQ6NTAgDQpUbzogSmFtZXMgTSBTbmVsbDxq YXNuZWxsQGdtYWlsLmNvbT4NCkNjOiBhdG9tLXN5bnRheDxhdG9tLXN5bnRheEBpbWMub3JnPjsg PG93bmVyLWF0b20tc3ludGF4QG1haWwuaW1jLm9yZz4NClN1YmplY3Q6IFJlOiBBdG9tcHViIEZl YXR1cmVzIERyYWZ0IERlYWQgZm9yIEdvb2Q/DQoNCg0KDQpDTUlTIGFkZHMgQ01JUyBlbGVtZW50 IHRvIHRoZSB3b3Jrc3BhY2UgZWxlbWVudCBpbiB0aGUgYXRvbXB1YiBzZXJ2aWNlDQpkb2N1bWVu dC4gIEkgYW0gbm90IGF3YXJlIG9mIHJlcXVpcmVtZW50cyBmcm9tIENNSVMgZm9yIHJlcHJlc2Vu dGluZw0KZmVhdHVyZXMgYXQgdGhlIGNvbGxlY3Rpb24gbGV2ZWwuDQoNCkZZSSAtIEhlcmUncyBh biBleGFtcGxlIG9mIHRoZSBmZWF0dXJlcy9jYXBhYmlsaXRpZXMgQ01JUyBhZHZlcnRpc2VzIGlu IHRoZQ0KYXRvbXB1YiB3b3Jrc3BhY2UgZWxlbWVudDoNCg0KICAgICAgICA8bnM1OnJlcG9zaXRv cnlJbmZvPg0KICAgICAgICAgICAgPG5zMTpyZXBvc2l0b3J5SWQ+cmVwaWQxPC9uczE6cmVwb3Np dG9yeUlkPg0KICAgICAgICAgICAgPG5zMTpyZXBvc2l0b3J5TmFtZT5SZXBvc2l0b3J5MTwvbnMx OnJlcG9zaXRvcnlOYW1lPg0KICAgICAgICAgICAgPG5zMTpyZXBvc2l0b3J5UmVsYXRpb25zaGlw PnNlbGY8L25zMTpyZXBvc2l0b3J5UmVsYXRpb25zaGlwPg0KICAgICAgICAgICAgPG5zMTpyZXBv c2l0b3J5RGVzY3JpcHRpb24+Q01JUyBSZXBvc2l0b3J5IERlc2NyaXB0aW9uPC8NCm5zMTpyZXBv c2l0b3J5RGVzY3JpcHRpb24+DQogICAgICAgICAgICA8bnMxOnZlbmRvck5hbWU+Q01JUyBWZW5k b3IgMTwvbnMxOnZlbmRvck5hbWU+DQogICAgICAgICAgICA8bnMxOnByb2R1Y3ROYW1lPkNNSVMg UHJvdG90eXBlIGZvciBWZW5kb3JYPC9uczE6cHJvZHVjdE5hbWU+DQogICAgICAgICAgICA8bnMx OnByb2R1Y3RWZXJzaW9uPjAuNjE8L25zMTpwcm9kdWN0VmVyc2lvbj4NCiAgICAgICAgICAgIDxu czE6cm9vdEZvbGRlcklkPnJvb3Rmb2xkZXI8L25zMTpyb290Rm9sZGVySWQ+DQogICAgICAgICAg ICA8bnMxOmNhcGFiaWxpdGllcz4NCiAgICAgICAgICAgICAgICA8bnMxOmNhcGFiaWxpdHlNdWx0 aWZpbGluZz50cnVlPC9uczE6Y2FwYWJpbGl0eU11bHRpZmlsaW5nPg0KICAgICAgICAgICAgICAg IDxuczE6Y2FwYWJpbGl0eVVuZmlsaW5nPnRydWU8L25zMTpjYXBhYmlsaXR5VW5maWxpbmc+DQog ICAgICAgICAgICAgICAgPG5zMTpjYXBhYmlsaXR5VmVyc2lvblNwZWNpZmljRmlsaW5nPnRydWU8 Lw0KbnMxOmNhcGFiaWxpdHlWZXJzaW9uU3BlY2lmaWNGaWxpbmc+DQogICAgICAgICAgICAgICAg PG5zMTpjYXBhYmlsaXR5UFdDVXBkYXRlYWJsZT50cnVlPC8NCm5zMTpjYXBhYmlsaXR5UFdDVXBk YXRlYWJsZT4NCiAgICAgICAgICAgICAgICA8bnMxOmNhcGFiaWxpdHlQV0NTZWFyY2hhYmxlPnRy dWU8Lw0KbnMxOmNhcGFiaWxpdHlQV0NTZWFyY2hhYmxlPg0KICAgICAgICAgICAgICAgIDxuczE6 Y2FwYWJpbGl0eUFsbFZlcnNpb25zU2VhcmNoYWJsZT50cnVlPC8NCm5zMTpjYXBhYmlsaXR5QWxs VmVyc2lvbnNTZWFyY2hhYmxlPg0KICAgICAgICAgICAgICAgIDxuczE6Y2FwYWJpbGl0eVF1ZXJ5 PmJvdGhjb21iaW5lZDwvbnMxOmNhcGFiaWxpdHlRdWVyeT4NCiAgICAgICAgICAgICAgICA8bnMx OmNhcGFiaWxpdHlKb2luPmlubmVyYW5kb3V0ZXI8L25zMTpjYXBhYmlsaXR5Sm9pbj4NCiAgICAg ICAgICAgICAgICA8bnMxOmNhcGFiaWxpdHlDaGFuZ2VzPmFsbDwvbnMxOmNhcGFiaWxpdHlDaGFu Z2VzPg0KICAgICAgICAgICAgICAgIDxuczE6Y2FwYWJpbGl0eUNoYW5nZXNPblR5cGU+ZG9jdW1l bnQ8Lw0KbnMxOmNhcGFiaWxpdHlDaGFuZ2VzT25UeXBlPg0KICAgICAgICAgICAgICAgIDxuczE6 Y2FwYWJpbGl0eUNoYW5nZXNPblR5cGU+Zm9sZGVyPC8NCm5zMTpjYXBhYmlsaXR5Q2hhbmdlc09u VHlwZT4NCiAgICAgICAgICAgICAgICA8bnMxOmNoYW5nZXNJbmNvbXBsZXRlPnRydWU8L25zMTpj aGFuZ2VzSW5jb21wbGV0ZT4NCiAgICAgICAgICAgIDwvbnMxOmNhcGFiaWxpdGllcz4NCiAgICAg ICAgICAgIDxuczE6Y21pc1ZlcnNpb25TdXBwb3J0ZWQ+MC42MTwvbnMxOmNtaXNWZXJzaW9uU3Vw cG9ydGVkPg0KICAgICAgICA8L25zNTpyZXBvc2l0b3J5SW5mbz4NCg0KLUFsDQoNCkFsIEJyb3du DQpFbWVyZ2luZyBTdGFuZGFyZHMgYW5kIEluZHVzdHJ5IEZyYW1ld29ya3MNCkNNSVM6IGh0dHBz Oi8vdzMudGFwLmlibS5jb20vdzNraTA3L2Rpc3BsYXkvRUNNQ01JUy9Ib21lDQpJbmR1c3RyeSBG cmFtZXdvcmtzOiBodHRwczovL3czLnRhcC5pYm0uY29tL3cza2kwNy9kaXNwbGF5L0VDTUlGL0hv bWUNCg0KT2ZmaWNlIDcxNCAzMjcgMzQ1Mw0KTW9iaWxlIDcxNCAyNjMgNjQ0MQ0KRW1haWwgIGFs YmVydGNicm93bkB1cy5pYm0uY29tDQpDT05GSURFTlRJQUwgTk9USUNFOiBUaGUgY29udGVudHMg b2YgdGhpcyBtZXNzYWdlLCBpbmNsdWRpbmcgYW55DQphdHRhY2htZW50cywgYXJlIGNvbmZpZGVu dGlhbCBhbmQgYXJlIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUNCnBlcnNvbiBv ciBlbnRpdHkgdG8gd2hvbSB0aGUgbWVzc2FnZSB3YXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUNCmludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIG1lc3NhZ2UsIHBsZWFzZSBiZSBhZHZp c2VkIHRoYXQgYW55DQpkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHVzZSBvZiB0aGUg Y29udGVudHMgb2YgdGhpcyBtZXNzYWdlIGlzDQpzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3Ug cmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5DQp0aGUgc2VuZGVy LiBQbGVhc2UgYWxzbyBwZXJtYW5lbnRseSBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2lu YWwNCm1lc3NhZ2UgYW5kIGFueSBhdHRhY2hlZCBkb2N1bWVudGF0aW9uLg0KDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQogIEZyb206ICAgICAgIEphbWVzIE0gU25lbGwgPGphc25lbGxAZ21haWwuY29tPiAg ICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgVG86ICAgICAgICAgYXRv bS1zeW50YXggPGF0b20tc3ludGF4QGltYy5vcmc+ICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KICBEYXRlOiAgICAgICAwNi8wOC8yMDA5IDAzOjM2IFBNICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogIFN1YmplY3Q6 ICAgIEF0b21wdWIgRmVhdHVyZXMgRHJhZnQgRGVhZCBmb3IgR29vZD8gICAgICAgICAgICAgICAg ICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQoNCg0KDQoNCk9rLCBzbyB3ZSdkIG1hZGUgcXVpdGUg YSBiaXQgb2YgcHJvZ3Jlc3Mgb24gdGhlIEF0b20gZmVhdHVyZXMgZHJhZnQgYQ0Kd2hpbGUgYmFj ayBhbmQgdGhlbiBJIGRlY2lkZWQgdG8gc2l0IGFuZCB3YXRjaCB0byBzZWUgaWYgdGhlcmUgd2Fz IGENCnN0cm9uZyBlbm91Z2ggbmVlZCBmb3IgdGhlIGV4dGVuc2lvbnMuIEF0IHRoaXMgcG9pbnQs IEkgaGF2ZSBub3Qgc2Vlbg0KYW55b25lIGp1bXBpbmcgdXAgYW5kIGRvd24gZGVtYW5kaW5nIHRo ZSBmdW5jdGlvbmFsaXR5IHByb3ZpZGVkIGJ5IHRoZQ0KRmVhdHVyZXMgZHJhZnQgc28gSSdtIHdv bmRlcmluZyBpZiBJIHNob3VsZCBqdXN0IGNvbnNpZGVyIGl0IERlYWQgZm9yDQpHb29kLiBUaG91 Z2h0cz8NCg0KDQoNCg== --part46833-boundary-678742132-1571858873 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="Windows-1252" PGh0bWw+PGJvZHk+T2sgdGhpcyBpcyBnb29kIHRvIHNlZS4gVGhlIG1haW4gcXVlc3Rpb24gaXMg d2hldGhlciB0aGVyZSBpcyBzdWZmaWNpZW50IHJlYXNvbiB0byBkZWZpbmUgYSBnZW5lcmljIGZl YXR1cmVzL2NhcGFiaWxpdGllcyBleHRlbnNpb24uIFRoZXJlIGNlcnRhaW5seSBhcmUgZ29vZCBh cmd1bWVudHMgaW4gZmF2b3IuIElmIGEgZ2VuZXJpYyBleHQgd2FzIGF2YWlsYWJsZSB3b3VsZCBj bWlzIHVzZSBpdD88YnIvPjxwPlNlbnQgZnJvbSBteSBWZXJpem9uIFdpcmVsZXNzIEJsYWNrQmVy cnk8L3A+PHA+PGhyIHNpemU9MiB3aWR0aD0xMDAlIGFsaWduPWNlbnRlciB0YWJpbmRleD0tMT48 Yj5Gcm9tPC9iPjogIEFsIEJyb3duIDxhbGJlcnRjYnJvd25AdXMuaWJtLmNvbT48YnI+PGI+RGF0 ZTwvYj46IE1vbiwgOCBKdW4gMjAwOSAxNjowNDo1MCAtMDcwMDxicj48Yj5UbzwvYj46IEphbWVz IE0gU25lbGwmbHQ7amFzbmVsbEBnbWFpbC5jb20mZ3Q7PGJyPjxiPlN1YmplY3Q8L2I+OiBSZTog QXRvbXB1YiBGZWF0dXJlcyBEcmFmdCBEZWFkIGZvciBHb29kPzxicj48L2ZvbnQ+PC9wPjxwPkNN SVMgYWRkcyBDTUlTIGVsZW1lbnQgdG8gdGhlIHdvcmtzcGFjZSBlbGVtZW50IGluIHRoZSBhdG9t cHViIHNlcnZpY2UgZG9jdW1lbnQuICBJIGFtIG5vdCBhd2FyZSBvZiByZXF1aXJlbWVudHMgZnJv bSBDTUlTIGZvciByZXByZXNlbnRpbmcgZmVhdHVyZXMgYXQgdGhlIGNvbGxlY3Rpb24gbGV2ZWwu PGJyPjxicj4gRllJIC0gSGVyZSdzIGFuIGV4YW1wbGUgb2YgdGhlIGZlYXR1cmVzL2NhcGFiaWxp dGllcyBDTUlTIGFkdmVydGlzZXMgaW4gdGhlIGF0b21wdWIgd29ya3NwYWNlIGVsZW1lbnQ6PGJy Pjxicj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+ICAgICAgICA8L2ZvbnQ+PGZvbnQgY29sb3I9 IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbHQ7PC9mb250Pjxmb250IGNvbG9yPSIjM0Y4 MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnM1OnJlcG9zaXRvcnlJbmZvPC9mb250Pjxmb250IGNv bG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OzwvZm9udD48YnI+PGZvbnQgZmFj ZT0iQ291cmllciBOZXciPiAgICAgICAgICAgIDwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4MCIg ZmFjZT0iQ291cmllciBOZXciPiZsdDs8L2ZvbnQ+PGZvbnQgY29sb3I9IiMzRjgwODAiIGZhY2U9 IkNvdXJpZXIgTmV3Ij5uczE6cmVwb3NpdG9yeUlkPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgw IiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OzwvZm9udD48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+ cmVwaWQxPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmx0 Oy88L2ZvbnQ+PGZvbnQgY29sb3I9IiMzRjgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij5uczE6cmVw b3NpdG9yeUlkPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OzwvZm9udD48YnI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiAgICAgICAgICAgIDwvZm9u dD48Zm9udCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZsdDs8L2ZvbnQ+PGZv bnQgY29sb3I9IiMzRjgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij5uczE6cmVwb3NpdG9yeU5hbWU8 L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7PC9mb250 Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij5SZXBvc2l0b3J5MTwvZm9udD48Zm9udCBjb2xvcj0i IzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZsdDsvPC9mb250Pjxmb250IGNvbG9yPSIjM0Y4 MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOnJlcG9zaXRvcnlOYW1lPC9mb250Pjxmb250IGNv bG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OzwvZm9udD48YnI+PGZvbnQgZmFj ZT0iQ291cmllciBOZXciPiAgICAgICAgICAgIDwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4MCIg ZmFjZT0iQ291cmllciBOZXciPiZsdDs8L2ZvbnQ+PGZvbnQgY29sb3I9IiMzRjgwODAiIGZhY2U9 IkNvdXJpZXIgTmV3Ij5uczE6cmVwb3NpdG9yeVJlbGF0aW9uc2hpcDwvZm9udD48Zm9udCBjb2xv cj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZndDs8L2ZvbnQ+PGZvbnQgZmFjZT0iQ291 cmllciBOZXciPnNlbGY8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIg TmV3Ij4mbHQ7LzwvZm9udD48Zm9udCBjb2xvcj0iIzNGODA4MCIgZmFjZT0iQ291cmllciBOZXci Pm5zMTpyZXBvc2l0b3J5UmVsYXRpb25zaGlwPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OzwvZm9udD48YnI+PGZvbnQgZmFjZT0iQ291cmllciBOZXci PiAgICAgICAgICAgIDwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBO ZXciPiZsdDs8L2ZvbnQ+PGZvbnQgY29sb3I9IiMzRjgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij5u czE6cmVwb3NpdG9yeURlc2NyaXB0aW9uPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OzwvZm9udD48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+Q01JUyBS ZXBvc2l0b3J5IERlc2NyaXB0aW9uPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJD b3VyaWVyIE5ldyI+Jmx0Oy88L2ZvbnQ+PGZvbnQgY29sb3I9IiMzRjgwODAiIGZhY2U9IkNvdXJp ZXIgTmV3Ij5uczE6cmVwb3NpdG9yeURlc2NyaXB0aW9uPC9mb250Pjxmb250IGNvbG9yPSIjMDA4 MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OzwvZm9udD48YnI+PGZvbnQgZmFjZT0iQ291cmll ciBOZXciPiAgICAgICAgICAgIDwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291 cmllciBOZXciPiZsdDs8L2ZvbnQ+PGZvbnQgY29sb3I9IiMzRjgwODAiIGZhY2U9IkNvdXJpZXIg TmV3Ij5uczE6dmVuZG9yTmFtZTwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291 cmllciBOZXciPiZndDs8L2ZvbnQ+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPkNNSVMgVmVuZG9y IDE8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbHQ7Lzwv Zm9udD48Zm9udCBjb2xvcj0iIzNGODA4MCIgZmFjZT0iQ291cmllciBOZXciPm5zMTp2ZW5kb3JO YW1lPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0Ozwv Zm9udD48YnI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiAgICAgICAgICAgIDwvZm9udD48Zm9u dCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZsdDs8L2ZvbnQ+PGZvbnQgY29s b3I9IiMzRjgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij5uczE6cHJvZHVjdE5hbWU8L2ZvbnQ+PGZv bnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7PC9mb250Pjxmb250IGZh Y2U9IkNvdXJpZXIgTmV3Ij5DTUlTIFByb3RvdHlwZSBmb3IgVmVuZG9yWDwvZm9udD48Zm9udCBj b2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZsdDsvPC9mb250Pjxmb250IGNvbG9y PSIjM0Y4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOnByb2R1Y3ROYW1lPC9mb250Pjxmb250 IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OzwvZm9udD48YnI+PGZvbnQg ZmFjZT0iQ291cmllciBOZXciPiAgICAgICAgICAgIDwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4 MCIgZmFjZT0iQ291cmllciBOZXciPiZsdDs8L2ZvbnQ+PGZvbnQgY29sb3I9IiMzRjgwODAiIGZh Y2U9IkNvdXJpZXIgTmV3Ij5uczE6cHJvZHVjdFZlcnNpb248L2ZvbnQ+PGZvbnQgY29sb3I9IiMw MDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7PC9mb250Pjxmb250IGZhY2U9IkNvdXJpZXIg TmV3Ij4wLjYxPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmx0Oy88L2ZvbnQ+PGZvbnQgY29sb3I9IiMzRjgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij5uczE6 cHJvZHVjdFZlcnNpb248L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7PC9mb250Pjxicj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+ICAgICAgICAgICAg PC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmx0OzwvZm9u dD48Zm9udCBjb2xvcj0iIzNGODA4MCIgZmFjZT0iQ291cmllciBOZXciPm5zMTpyb290Rm9sZGVy SWQ8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7PC9m b250Pjx1Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij5yb290Zm9sZGVyPC9mb250PjwvdT48Zm9u dCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZsdDsvPC9mb250Pjxmb250IGNv bG9yPSIjM0Y4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOnJvb3RGb2xkZXJJZDwvZm9udD48 Zm9udCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZndDs8L2ZvbnQ+PGJyPjxm b250IGZhY2U9IkNvdXJpZXIgTmV3Ij4gICAgICAgICAgICA8L2ZvbnQ+PGZvbnQgY29sb3I9IiMw MDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbHQ7PC9mb250Pjxmb250IGNvbG9yPSIjM0Y4MDgw IiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOmNhcGFiaWxpdGllczwvZm9udD48Zm9udCBjb2xvcj0i IzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZndDs8L2ZvbnQ+PGJyPjxmb250IGZhY2U9IkNv dXJpZXIgTmV3Ij4gICAgICAgICAgICAgICAgPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBm YWNlPSJDb3VyaWVyIE5ldyI+Jmx0OzwvZm9udD48Zm9udCBjb2xvcj0iIzNGODA4MCIgZmFjZT0i Q291cmllciBOZXciPm5zMTpjYXBhYmlsaXR5TXVsdGlmaWxpbmc8L2ZvbnQ+PGZvbnQgY29sb3I9 IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7PC9mb250Pjxmb250IGZhY2U9IkNvdXJp ZXIgTmV3Ij50cnVlPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5l dyI+Jmx0Oy88L2ZvbnQ+PGZvbnQgY29sb3I9IiMzRjgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij5u czE6Y2FwYWJpbGl0eU11bHRpZmlsaW5nPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OzwvZm9udD48YnI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiAg ICAgICAgICAgICAgICA8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIg TmV3Ij4mbHQ7PC9mb250Pjxmb250IGNvbG9yPSIjM0Y4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+ bnMxOmNhcGFiaWxpdHlVbmZpbGluZzwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4MCIgZmFjZT0i Q291cmllciBOZXciPiZndDs8L2ZvbnQ+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPnRydWU8L2Zv bnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbHQ7LzwvZm9udD48 Zm9udCBjb2xvcj0iIzNGODA4MCIgZmFjZT0iQ291cmllciBOZXciPm5zMTpjYXBhYmlsaXR5VW5m aWxpbmc8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7 PC9mb250Pjxicj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+ICAgICAgICAgICAgICAgIDwvZm9u dD48Zm9udCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZsdDs8L2ZvbnQ+PGZv bnQgY29sb3I9IiMzRjgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij5uczE6Y2FwYWJpbGl0eVZlcnNp b25TcGVjaWZpY0ZpbGluZzwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmll ciBOZXciPiZndDs8L2ZvbnQ+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPnRydWU8L2ZvbnQ+PGZv bnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbHQ7LzwvZm9udD48Zm9udCBj b2xvcj0iIzNGODA4MCIgZmFjZT0iQ291cmllciBOZXciPm5zMTpjYXBhYmlsaXR5VmVyc2lvblNw ZWNpZmljRmlsaW5nPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5l dyI+Jmd0OzwvZm9udD48YnI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiAgICAgICAgICAgICAg ICA8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbHQ7PC9m b250Pjxmb250IGNvbG9yPSIjM0Y4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOmNhcGFiaWxp dHlQV0NVcGRhdGVhYmxlPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVy IE5ldyI+Jmd0OzwvZm9udD48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+dHJ1ZTwvZm9udD48Zm9u dCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZsdDsvPC9mb250Pjxmb250IGNv bG9yPSIjM0Y4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOmNhcGFiaWxpdHlQV0NVcGRhdGVh YmxlPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0Ozwv Zm9udD48YnI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiAgICAgICAgICAgICAgICA8L2ZvbnQ+ PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbHQ7PC9mb250Pjxmb250 IGNvbG9yPSIjM0Y4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOmNhcGFiaWxpdHlQV0NTZWFy Y2hhYmxlPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0 OzwvZm9udD48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+dHJ1ZTwvZm9udD48Zm9udCBjb2xvcj0i IzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZsdDsvPC9mb250Pjxmb250IGNvbG9yPSIjM0Y4 MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOmNhcGFiaWxpdHlQV0NTZWFyY2hhYmxlPC9mb250 Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OzwvZm9udD48YnI+ PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiAgICAgICAgICAgICAgICA8L2ZvbnQ+PGZvbnQgY29s b3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbHQ7PC9mb250Pjxmb250IGNvbG9yPSIj M0Y4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOmNhcGFiaWxpdHlBbGxWZXJzaW9uc1NlYXJj aGFibGU8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7 PC9mb250Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij50cnVlPC9mb250Pjxmb250IGNvbG9yPSIj MDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmx0Oy88L2ZvbnQ+PGZvbnQgY29sb3I9IiMzRjgw ODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij5uczE6Y2FwYWJpbGl0eUFsbFZlcnNpb25zU2VhcmNoYWJs ZTwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZndDs8L2Zv bnQ+PGJyPjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij4gICAgICAgICAgICAgICAgPC9mb250Pjxm b250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmx0OzwvZm9udD48Zm9udCBj b2xvcj0iIzNGODA4MCIgZmFjZT0iQ291cmllciBOZXciPm5zMTpjYXBhYmlsaXR5UXVlcnk8L2Zv bnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7PC9mb250Pjx1 Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij5ib3RoY29tYmluZWQ8L2ZvbnQ+PC91Pjxmb250IGNv bG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmx0Oy88L2ZvbnQ+PGZvbnQgY29sb3I9 IiMzRjgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij5uczE6Y2FwYWJpbGl0eVF1ZXJ5PC9mb250Pjxm b250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OzwvZm9udD48YnI+PGZv bnQgZmFjZT0iQ291cmllciBOZXciPiAgICAgICAgICAgICAgICA8L2ZvbnQ+PGZvbnQgY29sb3I9 IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbHQ7PC9mb250Pjxmb250IGNvbG9yPSIjM0Y4 MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOmNhcGFiaWxpdHlKb2luPC9mb250Pjxmb250IGNv bG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OzwvZm9udD48dT48Zm9udCBmYWNl PSJDb3VyaWVyIE5ldyI+aW5uZXJhbmRvdXRlcjwvZm9udD48L3U+PGZvbnQgY29sb3I9IiMwMDgw ODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbHQ7LzwvZm9udD48Zm9udCBjb2xvcj0iIzNGODA4MCIg ZmFjZT0iQ291cmllciBOZXciPm5zMTpjYXBhYmlsaXR5Sm9pbjwvZm9udD48Zm9udCBjb2xvcj0i IzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZndDs8L2ZvbnQ+PGJyPjxmb250IGZhY2U9IkNv dXJpZXIgTmV3Ij4gICAgICAgICAgICAgICAgPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBm YWNlPSJDb3VyaWVyIE5ldyI+Jmx0OzwvZm9udD48Zm9udCBjb2xvcj0iIzNGODA4MCIgZmFjZT0i Q291cmllciBOZXciPm5zMTpjYXBhYmlsaXR5Q2hhbmdlczwvZm9udD48Zm9udCBjb2xvcj0iIzAw ODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZndDs8L2ZvbnQ+PGZvbnQgZmFjZT0iQ291cmllciBO ZXciPmFsbDwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZs dDsvPC9mb250Pjxmb250IGNvbG9yPSIjM0Y4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOmNh cGFiaWxpdHlDaGFuZ2VzPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVy IE5ldyI+Jmd0OzwvZm9udD48YnI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiAgICAgICAgICAg ICAgICA8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbHQ7 PC9mb250Pjxmb250IGNvbG9yPSIjM0Y4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOmNhcGFi aWxpdHlDaGFuZ2VzT25UeXBlPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3Vy aWVyIE5ldyI+Jmd0OzwvZm9udD48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+ZG9jdW1lbnQ8L2Zv bnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbHQ7LzwvZm9udD48 Zm9udCBjb2xvcj0iIzNGODA4MCIgZmFjZT0iQ291cmllciBOZXciPm5zMTpjYXBhYmlsaXR5Q2hh bmdlc09uVHlwZTwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBOZXci PiZndDs8L2ZvbnQ+PGJyPjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij4gICAgICAgICAgICAgICAg PC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmx0OzwvZm9u dD48Zm9udCBjb2xvcj0iIzNGODA4MCIgZmFjZT0iQ291cmllciBOZXciPm5zMTpjYXBhYmlsaXR5 Q2hhbmdlc09uVHlwZTwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBO ZXciPiZndDs8L2ZvbnQ+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPmZvbGRlcjwvZm9udD48Zm9u dCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZsdDsvPC9mb250Pjxmb250IGNv bG9yPSIjM0Y4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOmNhcGFiaWxpdHlDaGFuZ2VzT25U eXBlPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0Ozwv Zm9udD48YnI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiAgICAgICAgICAgICAgICA8L2ZvbnQ+ PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbHQ7PC9mb250Pjxmb250 IGNvbG9yPSIjM0Y4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOmNoYW5nZXNJbmNvbXBsZXRl PC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OzwvZm9u dD48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+dHJ1ZTwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4 MCIgZmFjZT0iQ291cmllciBOZXciPiZsdDsvPC9mb250Pjxmb250IGNvbG9yPSIjM0Y4MDgwIiBm YWNlPSJDb3VyaWVyIE5ldyI+bnMxOmNoYW5nZXNJbmNvbXBsZXRlPC9mb250Pjxmb250IGNvbG9y PSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OzwvZm9udD48YnI+PGZvbnQgZmFjZT0i Q291cmllciBOZXciPiAgICAgICAgICAgIDwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4MCIgZmFj ZT0iQ291cmllciBOZXciPiZsdDsvPC9mb250Pjxmb250IGNvbG9yPSIjM0Y4MDgwIiBmYWNlPSJD b3VyaWVyIE5ldyI+bnMxOmNhcGFiaWxpdGllczwvZm9udD48Zm9udCBjb2xvcj0iIzAwODA4MCIg ZmFjZT0iQ291cmllciBOZXciPiZndDs8L2ZvbnQ+PGJyPjxmb250IGZhY2U9IkNvdXJpZXIgTmV3 Ij4gICAgICAgICAgICA8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIg TmV3Ij4mbHQ7PC9mb250Pjxmb250IGNvbG9yPSIjM0Y4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+ bnMxOmNtaXNWZXJzaW9uU3VwcG9ydGVkPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OzwvZm9udD48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+MC42MTwv Zm9udD48Zm9udCBjb2xvcj0iIzAwODA4MCIgZmFjZT0iQ291cmllciBOZXciPiZsdDsvPC9mb250 Pjxmb250IGNvbG9yPSIjM0Y4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+bnMxOmNtaXNWZXJzaW9u U3VwcG9ydGVkPC9mb250Pjxmb250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OzwvZm9udD48YnI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiAgICAgICAgPC9mb250Pjxm b250IGNvbG9yPSIjMDA4MDgwIiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmx0Oy88L2ZvbnQ+PGZvbnQg Y29sb3I9IiMzRjgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij5uczU6cmVwb3NpdG9yeUluZm88L2Zv bnQ+PGZvbnQgY29sb3I9IiMwMDgwODAiIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7PC9mb250Pjxi cj48YnI+IC1BbDxicj48YnI+IEFsIEJyb3duPGJyPiBFbWVyZ2luZyBTdGFuZGFyZHMgYW5kIElu ZHVzdHJ5IEZyYW1ld29ya3M8YnI+IENNSVM6IDxhIGhyZWY9Imh0dHBzOi8vdzMudGFwLmlibS5j b20vdzNraTA3L2Rpc3BsYXkvRUNNQ01JUy9Ib21lIj5odHRwczovL3czLnRhcC5pYm0uY29tL3cz a2kwNy9kaXNwbGF5L0VDTUNNSVMvSG9tZTwvYT4gPGJyPiBJbmR1c3RyeSBGcmFtZXdvcmtzOiA8 YSBocmVmPSJodHRwczovL3czLnRhcC5pYm0uY29tL3cza2kwNy9kaXNwbGF5L0VDTUlGL0hvbWUi Pmh0dHBzOi8vdzMudGFwLmlibS5jb20vdzNraTA3L2Rpc3BsYXkvRUNNSUYvSG9tZTwvYT48YnI+ PGJyPiBPZmZpY2UgNzE0IDMyNyAzNDUzPGJyPiBNb2JpbGUgNzE0IDI2MyA2NDQxPGJyPiBFbWFp bCAgYWxiZXJ0Y2Jyb3duQHVzLmlibS5jb208YnI+IENPTkZJREVOVElBTCBOT1RJQ0U6IFRoZSBj b250ZW50cyBvZiB0aGlzIG1lc3NhZ2UsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMsIGFyZSBj b25maWRlbnRpYWwgYW5kIGFyZSBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIHBl cnNvbiBvciBlbnRpdHkgdG8gd2hvbSB0aGUgbWVzc2FnZSB3YXMgYWRkcmVzc2VkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgbWVzc2FnZSwgcGxlYXNlIGJl IGFkdmlzZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciB1c2Ugb2Yg dGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5 b3UgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIuIFBsZWFzZSBhbHNvIHBlcm1hbmVudGx5IGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoZSBvcmln aW5hbCBtZXNzYWdlIGFuZCBhbnkgYXR0YWNoZWQgZG9jdW1lbnRhdGlvbi4gPGJyPjxicj48aW1n IHdpZHRoPSIxNiIgaGVpZ2h0PSIxNiIgc3JjPSJjaWQ6MV9fPTA3QkJGRjVDREZFRERBMTI4Zjll OGE5M2RmOTM4QHVzLmlibS5jb20iIGJvcmRlcj0iMCIgYWx0PSJJbmFjdGl2ZSBoaWRlIGRldGFp bHMgZm9yIEphbWVzIE0gU25lbGwgLS0tMDYvMDgvMjAwOSAwMzozNjozNiBQTS0tLU9rLCBzbyB3 ZSdkIG1hZGUgcXVpdGUgYSBiaXQgb2YgcHJvZ3Jlc3Mgb24gdGhlIEF0b20gZmVhdHVyIj48Zm9u dCBjb2xvcj0iIzQyNDI4MiI+SmFtZXMgTSBTbmVsbCAtLS0wNi8wOC8yMDA5IDAzOjM2OjM2IFBN LS0tT2ssIHNvIHdlJ2QgbWFkZSBxdWl0ZSBhIGJpdCBvZiBwcm9ncmVzcyBvbiB0aGUgQXRvbSBm ZWF0dXJlcyBkcmFmdCBhPC9mb250Pjxicj48YnI+IDx0YWJsZSB3aWR0aD0iMTAwJSIgYm9yZGVy PSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPjx0ciB2YWxpZ249InRvcCI+PHRk IHdpZHRoPSIxJSI+PGltZyB3aWR0aD0iOTYiIGhlaWdodD0iMSIgc3JjPSJjaWQ6Ml9fPTA3QkJG RjVDREZFRERBMTI4ZjllOGE5M2RmOTM4QHVzLmlibS5jb20iIGJvcmRlcj0iMCIgYWx0PSIiPjxi cj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzVGNUY1RiI+RnJvbTo8L2ZvbnQ+PC90ZD48dGQgd2lk dGg9IjEwMCUiPjxpbWcgd2lkdGg9IjEiIGhlaWdodD0iMSIgc3JjPSJjaWQ6Ml9fPTA3QkJGRjVD REZFRERBMTI4ZjllOGE5M2RmOTM4QHVzLmlibS5jb20iIGJvcmRlcj0iMCIgYWx0PSIiPjxicj48 Zm9udCBzaXplPSIyIj5KYW1lcyBNIFNuZWxsICZsdDtqYXNuZWxsQGdtYWlsLmNvbSZndDs8L2Zv bnQ+PC90ZD48L3RyPiA8dHIgdmFsaWduPSJ0b3AiPjx0ZCB3aWR0aD0iMSUiPjxpbWcgd2lkdGg9 Ijk2IiBoZWlnaHQ9IjEiIHNyYz0iY2lkOjJfXz0wN0JCRkY1Q0RGRUREQTEyOGY5ZThhOTNkZjkz OEB1cy5pYm0uY29tIiBib3JkZXI9IjAiIGFsdD0iIj48YnI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiM1RjVGNUYiPlRvOjwvZm9udD48L3RkPjx0ZCB3aWR0aD0iMTAwJSI+PGltZyB3aWR0aD0iMSIg aGVpZ2h0PSIxIiBzcmM9ImNpZDoyX189MDdCQkZGNUNERkVEREExMjhmOWU4YTkzZGY5MzhAdXMu aWJtLmNvbSIgYm9yZGVyPSIwIiBhbHQ9IiI+PGJyPjxmb250IHNpemU9IjIiPmF0b20tc3ludGF4 ICZsdDthdG9tLXN5bnRheEBpbWMub3JnJmd0OzwvZm9udD48L3RkPjwvdHI+IDx0ciB2YWxpZ249 InRvcCI+PHRkIHdpZHRoPSIxJSI+PGltZyB3aWR0aD0iOTYiIGhlaWdodD0iMSIgc3JjPSJjaWQ6 Ml9fPTA3QkJGRjVDREZFRERBMTI4ZjllOGE5M2RmOTM4QHVzLmlibS5jb20iIGJvcmRlcj0iMCIg YWx0PSIiPjxicj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzVGNUY1RiI+RGF0ZTo8L2ZvbnQ+PC90 ZD48dGQgd2lkdGg9IjEwMCUiPjxpbWcgd2lkdGg9IjEiIGhlaWdodD0iMSIgc3JjPSJjaWQ6Ml9f PTA3QkJGRjVDREZFRERBMTI4ZjllOGE5M2RmOTM4QHVzLmlibS5jb20iIGJvcmRlcj0iMCIgYWx0 PSIiPjxicj48Zm9udCBzaXplPSIyIj4wNi8wOC8yMDA5IDAzOjM2IFBNPC9mb250PjwvdGQ+PC90 cj4gPHRyIHZhbGlnbj0idG9wIj48dGQgd2lkdGg9IjElIj48aW1nIHdpZHRoPSI5NiIgaGVpZ2h0 PSIxIiBzcmM9ImNpZDoyX189MDdCQkZGNUNERkVEREExMjhmOWU4YTkzZGY5MzhAdXMuaWJtLmNv bSIgYm9yZGVyPSIwIiBhbHQ9IiI+PGJyPjxmb250IHNpemU9IjIiIGNvbG9yPSIjNUY1RjVGIj5T dWJqZWN0OjwvZm9udD48L3RkPjx0ZCB3aWR0aD0iMTAwJSI+PGltZyB3aWR0aD0iMSIgaGVpZ2h0 PSIxIiBzcmM9ImNpZDoyX189MDdCQkZGNUNERkVEREExMjhmOWU4YTkzZGY5MzhAdXMuaWJtLmNv bSIgYm9yZGVyPSIwIiBhbHQ9IiI+PGJyPjxmb250IHNpemU9IjIiPkF0b21wdWIgRmVhdHVyZXMg RHJhZnQgRGVhZCBmb3IgR29vZD88L2ZvbnQ+PC90ZD48L3RyPjwvdGFibGU+PGhyIHdpZHRoPSIx MDAlIiBzaXplPSIyIiBhbGlnbj0ibGVmdCIgbm9zaGFkZSBzdHlsZT0iY29sb3I6IzgwOTFBNTsg Ij48YnI+PGJyPjxicj48dHQ+PGJyPiBPaywgc28gd2UnZCBtYWRlIHF1aXRlIGEgYml0IG9mIHBy b2dyZXNzIG9uIHRoZSBBdG9tIGZlYXR1cmVzIGRyYWZ0IGEgPGJyPiB3aGlsZSBiYWNrIGFuZCB0 aGVuIEkgZGVjaWRlZCB0byBzaXQgYW5kIHdhdGNoIHRvIHNlZSBpZiB0aGVyZSB3YXMgYSA8YnI+ IHN0cm9uZyBlbm91Z2ggbmVlZCBmb3IgdGhlIGV4dGVuc2lvbnMuIEF0IHRoaXMgcG9pbnQsIEkg aGF2ZSBub3Qgc2VlbiA8YnI+IGFueW9uZSBqdW1waW5nIHVwIGFuZCBkb3duIGRlbWFuZGluZyB0 aGUgZnVuY3Rpb25hbGl0eSBwcm92aWRlZCBieSB0aGUgPGJyPiBGZWF0dXJlcyBkcmFmdCBzbyBJ J20gd29uZGVyaW5nIGlmIEkgc2hvdWxkIGp1c3QgY29uc2lkZXIgaXQgRGVhZCBmb3IgPGJyPiBH b29kLiBUaG91Z2h0cz88YnI+PGJyPjwvdHQ+PGJyPjxicj48L2JvZHk+PC9odG1sPiAg --part46833-boundary-678742132-1571858873-- --part46832-boundary-678742132-1571858873 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBFF5CDFEDDA128f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --part46832-boundary-678742132-1571858873 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=07BBFF5CDFEDDA128f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --part46832-boundary-678742132-1571858873-- From owner-atom-syntax@mail.imc.org Mon Jun 8 16:27:49 2009 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 DD51A3A6894 for ; Mon, 8 Jun 2009 16:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 qPyarAJbTyfv for ; Mon, 8 Jun 2009 16:27:47 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0B3733A63CB for ; Mon, 8 Jun 2009 16:27:44 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58NGaf5028636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 16:16:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58NGaEQ028635; Mon, 8 Jun 2009 16:16:36 -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 acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58NGPYQ028626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jun 2009 16:16:35 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58NHCPd005763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Jun 2009 23:17:13 GMT Received: from abhmt003.oracle.com (abhmt003.oracle.com [141.146.116.12]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58NHR79022952; Mon, 8 Jun 2009 23:17:27 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Jun 2009 16:16:19 -0700 Cc: James M Snell , atom-syntax Syntax Message-Id: From: "Nikunj R. Mehta" To: Al Brown In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-6--92272918 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 Date: Mon, 8 Jun 2009 16:14:59 -0700 References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com> <4A2D95EC.2010308@gmail.com> <0F6549DC-DB2E-4DBA-8F6A-0C0FABBBB8D8@oracle.com> <4A2D96E3.2080206@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt003.oracle.com [141.146.116.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4A2D9BC4.01B5:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-6--92272918 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I am not sure if a media type parameter for Atom would be within the scope of an inline extension for Atom. Nikunj http://o-micron.blogspot.com On Jun 8, 2009, at 4:10 PM, Al Brown wrote: > > On Jun 8, 2009, at 3:51 PM, James M Snell wrote: > > > >> >> href="..." /> > >> >> href="..." /> > > This works for me. I would like to see the extension to the media > type in the I-D instead of "down-tree" and "up-tree". > > -Al > > Al Brown > Emerging Standards and Industry Frameworks > CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home > Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home > > Office 714 327 3453 > Mobile 714 263 6441 > Email albertcbrown@us.ibm.com > CONFIDENTIAL NOTICE: The contents of this message, including any > attachments, are confidential and are intended solely for the use of > the person or entity to whom the message was addressed. If you are > not the intended recipient of this message, please be advised that > any dissemination, distribution, or use of the contents of this > message is strictly prohibited. If you received this message in > error, please notify the sender. Please also permanently delete all > copies of the original message and any attached documentation. > > James M Snell ---06/08/2009 03:54:38 PM---Heh, I think > so ;-) > > > From: > James M Snell > > To: > "Nikunj R. Mehta" > > Cc: > Al Brown/Costa Mesa/IBM@IBMUS, atom-syntax Syntax syntax@imc.org> > > Date: > 06/08/2009 03:54 PM > > Subject: > Re: New Version Notification for draft-divilly-atom-hierarchy-01 > > > > Heh, I think so ;-) > > Nikunj R. Mehta wrote: > > On Jun 8, 2009, at 3:51 PM, James M Snell wrote: > > > >> >> href="..." /> > >> >> href="..." /> > > > > > > Just a nit, media type parameters are ',' separated, correct?. > > > > --Apple-Mail-6--92272918 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I am not sure if a media = type parameter for Atom would be within the scope of an inline extension = for Atom.

Nikunj http://o-micron.blogspot.com On Jun 8, 2009, = at 4:10 PM, Al Brown wrote: > On Jun 8, 2009, at 3:51 PM, James M Snell = wrote: > >> <link rel=3D"down" = type=3D"application/atom+xml;type=3Dfeed;profile=3Dtree" >> = href=3D"..." /> >> <link rel=3D"down" = type=3D"application/atom+xml;type=3Dfeed;profile=3Dflat" >> = href=3D"..." /> This works for me. I would like to see = the extension to the media type in the I-D instead of "down-tree" and = "up-tree". -Al Al Brown Emerging Standards and = Industry Frameworks CMIS: https://w3.tap= .ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.i= bm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 = Mobile 714 263 6441 Email albertcbrown@us.ibm.com = CONFIDENTIAL NOTICE: The contents of this message, including any = attachments, are confidential and are intended solely for the use of the = person or entity to whom the message was addressed. If you are not the = intended recipient of this message, please be advised that any = dissemination, distribution, or use of the contents of this message is = strictly prohibited. If you received this message in error, please = notify the sender. Please also permanently delete all copies of the = original message and any attached documentation. = <graycol.gif>James M Snell = ---06/08/2009 03:54:38 PM---Heh, I think so ;-) = <ecblank.gif> From: <ecblank.gif> James= M Snell <jasnell@gmail.com> <ecblank.gif> To: <ecblank.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.com> <ecblank.gif> Cc: <ecblank.gif> Al= Brown/Costa Mesa/IBM@IBMUS, atom-syntax Syntax <atom-syntax@imc.org> <ecblank.gif> Date: <ecblank.gif> 06/08/2009 03:54 PM <ecblank.gif> Subject: <ecblank.gif> Re: = New Version Notification for = draft-divilly-atom-hierarchy-01 = Heh, I think so ;-) = Nikunj R. Mehta wrote: > On Jun 8, 2009, at 3:51 PM, James M = Snell wrote: > >> <link rel=3D"down" = type=3D"application/atom+xml;type=3Dfeed;profile=3Dtree" >> = href=3D"..." /> >> <link rel=3D"down" = type=3D"application/atom+xml;type=3Dfeed;profile=3Dflat" >> = href=3D"..." /> > > > Just a nit, media type = parameters are ',' separated, correct?. > = = --Apple-Mail-6--92272918-- From owner-atom-syntax@mail.imc.org Mon Jun 8 16:34:35 2009 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 1341B3A6A65 for ; Mon, 8 Jun 2009 16:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.636 X-Spam-Level: X-Spam-Status: No, score=0.636 tagged_above=-999 required=5 tests=[AWL=1.482, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 1-gq4WEGsRgb for ; Mon, 8 Jun 2009 16:34:34 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1D3A93A63CB for ; Mon, 8 Jun 2009 16:34:32 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58NMZlB028908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 16:22:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58NMZxi028907; Mon, 8 Jun 2009 16:22:35 -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-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58NMYYn028901 for ; Mon, 8 Jun 2009 16:22:34 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by gxk3 with SMTP id 3so573414gxk.10 for ; Mon, 08 Jun 2009 16:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-rim-org-msg-ref-id :return-receipt-to:message-id:reply-to:x-priority:references :in-reply-to:sensitivity:importance:to:cc:subject:from:date :content-type:mime-version; bh=2dLvRfinZQNuqBYT/fGmTlMTue2aXuuPoqkd/Y/ER/c=; b=rWzsaoyLgoG4QSUFw3suICVEyEGLfV2FCd4wniolEgYDJ8HakpazC+yH2KtxONp1IS MBZHjhZIU5WJ85+kK7VFuZOrd06UK/PVS4kOonPJnhzG5ru2AWEkpBD3POTp5vrwRUiV HkoTrVKGh955HuByK5pJvd1m43WbYQJgFXa3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-rim-org-msg-ref-id:return-receipt-to:message-id:reply-to :x-priority:references:in-reply-to:sensitivity:importance:to:cc :subject:from:date:content-type:mime-version; b=Sa9EYveWNfsgwVbpBM1vos53tTLXbDPd3AotDBfYcb1MWSkdUalqduAdfINMClQ/+L ttEG1Ql0MCMUFSQVCja9TRAbWmxoRhXK8CXpXYiviaVL9i86dZ0P3fQXNjFOZ3KWpYHJ 3sbahB8F63QDxuviyoVumyYwhzjHJucotMM10= Received: by 10.90.101.17 with SMTP id y17mr2970346agb.31.1244503353738; Mon, 08 Jun 2009 16:22:33 -0700 (PDT) Received: from bda703.bisx.prod.on.blackberry (c703.bda.bis.na.blackberry.com [67.223.71.112]) by mx.google.com with ESMTPS id 4sm616478aga.56.2009.06.08.16.22.32 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 16:22:33 -0700 (PDT) X-rim-org-msg-ref-id:1536263901 Message-ID:<1536263901-1244503351-cardhu_decombobulator_blackberry.rim.net-1403812264-@bxe1007.bisx.prod.on.blackberry> Reply-To: jasnell@gmail.com X-Priority: Normal References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com> <4A2D95EC.2010308@gmail.com> <0F6549DC-DB2E-4DBA-8F6A-0C0FABBBB8D8@oracle.com> <4A2D96E3.2080206@gmail.com> In-Reply-To: Sensitivity: Normal Importance: Normal To: "Nikunj R. Mehta" , "Al Brown" Cc: "atom-syntax Syntax" Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 From: jasnell@gmail.com Date: Mon, 8 Jun 2009 23:22:34 +0000 Content-Type: multipart/alternative; boundary="part47127-boundary-1143295663-966394595" MIME-Version: 1.0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --part47127-boundary-1143295663-966394595 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="Windows-1252" U3VyZSBpdCB3b3VsZC4gTm9uZXRoZWxlc3MsIHRoZSBwcm9maWxlIG1lZGlhIHR5cGUgZXh0ZW5z aW9uIHNob3VsZCBiZSBkZWZpbmVkIHNlcGFyYXRlbHkgaW4gaXRzIG93biBJLUQuIEkgY2FuIHdy aXRlIHRoYXQgdXAuIEJlZW4gbWVhbmluZyB0byBkbyBzbyBmb3IgYSB3aGlsZS4gDQoNClNlbnQg ZnJvbSBteSBWZXJpem9uIFdpcmVsZXNzIEJsYWNrQmVycnkNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206ICJOaWt1bmogUi4gTWVodGEiIDxuaWt1bmoubWVodGFAb3JhY2xlLmNv bT4NCg0KRGF0ZTogTW9uLCA4IEp1biAyMDA5IDE2OjE0OjU5IA0KVG86IEFsIEJyb3duPGFsYmVy dGNicm93bkB1cy5pYm0uY29tPg0KQ2M6IEphbWVzIE0gU25lbGw8amFzbmVsbEBnbWFpbC5jb20+ OyBhdG9tLXN5bnRheCBTeW50YXg8YXRvbS1zeW50YXhAaW1jLm9yZz4NClN1YmplY3Q6IFJlOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRpdmlsbHktYXRvbS1oaWVyYXJjaHkt MDENCg0KDQpJIGFtIG5vdCBzdXJlIGlmIGEgbWVkaWEgdHlwZSBwYXJhbWV0ZXIgZm9yIEF0b20g d291bGQgYmUgd2l0aGluIHRoZSAgDQpzY29wZSBvZiBhbiBpbmxpbmUgZXh0ZW5zaW9uIGZvciBB dG9tLg0KDQpOaWt1bmoNCmh0dHA6Ly9vLW1pY3Jvbi5ibG9nc3BvdC5jb20NCg0KDQoNCk9uIEp1 biA4LCAyMDA5LCBhdCA0OjEwIFBNLCBBbCBCcm93biB3cm90ZToNCg0KPiA+IE9uIEp1biA4LCAy MDA5LCBhdCAzOjUxIFBNLCBKYW1lcyBNIFNuZWxsIHdyb3RlOg0KPiA+DQo+ID4+IDxsaW5rIHJl bD0iZG93biIgdHlwZT0iYXBwbGljYXRpb24vYXRvbSt4bWw7dHlwZT1mZWVkO3Byb2ZpbGU9dHJl ZSINCj4gPj4gaHJlZj0iLi4uIiAvPg0KPiA+PiA8bGluayByZWw9ImRvd24iIHR5cGU9ImFwcGxp Y2F0aW9uL2F0b20reG1sO3R5cGU9ZmVlZDtwcm9maWxlPWZsYXQiDQo+ID4+IGhyZWY9Ii4uLiIg Lz4NCj4NCj4gVGhpcyB3b3JrcyBmb3IgbWUuIEkgd291bGQgbGlrZSB0byBzZWUgdGhlIGV4dGVu c2lvbiB0byB0aGUgbWVkaWEgIA0KPiB0eXBlIGluIHRoZSBJLUQgaW5zdGVhZCBvZiAiZG93bi10 cmVlIiBhbmQgInVwLXRyZWUiLg0KPg0KPiAtQWwNCj4NCj4gQWwgQnJvd24NCj4gRW1lcmdpbmcg U3RhbmRhcmRzIGFuZCBJbmR1c3RyeSBGcmFtZXdvcmtzDQo+IENNSVM6IGh0dHBzOi8vdzMudGFw LmlibS5jb20vdzNraTA3L2Rpc3BsYXkvRUNNQ01JUy9Ib21lDQo+IEluZHVzdHJ5IEZyYW1ld29y a3M6IGh0dHBzOi8vdzMudGFwLmlibS5jb20vdzNraTA3L2Rpc3BsYXkvRUNNSUYvSG9tZQ0KPg0K PiBPZmZpY2UgNzE0IDMyNyAzNDUzDQo+IE1vYmlsZSA3MTQgMjYzIDY0NDENCj4gRW1haWwgYWxi ZXJ0Y2Jyb3duQHVzLmlibS5jb20NCj4gQ09ORklERU5USUFMIE5PVElDRTogVGhlIGNvbnRlbnRz IG9mIHRoaXMgbWVzc2FnZSwgaW5jbHVkaW5nIGFueSAgDQo+IGF0dGFjaG1lbnRzLCBhcmUgY29u ZmlkZW50aWFsIGFuZCBhcmUgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mICANCj4gdGhl IHBlcnNvbiBvciBlbnRpdHkgdG8gd2hvbSB0aGUgbWVzc2FnZSB3YXMgYWRkcmVzc2VkLiBJZiB5 b3UgYXJlICANCj4gbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBtZXNzYWdlLCBw bGVhc2UgYmUgYWR2aXNlZCB0aGF0ICANCj4gYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlv biwgb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzICANCj4gbWVzc2FnZSBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluICANCj4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlci4gUGxlYXNlIGFsc28gcGVybWFuZW50bHkgZGVsZXRl IGFsbCAgDQo+IGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZSBhbmQgYW55IGF0dGFjaGVk IGRvY3VtZW50YXRpb24uDQo+DQo+IDxncmF5Y29sLmdpZj5KYW1lcyBNIFNuZWxsIC0tLTA2LzA4 LzIwMDkgMDM6NTQ6MzggUE0tLS1IZWgsIEkgdGhpbmsgIA0KPiBzbyA7LSkNCj4NCj4gPGVjYmxh bmsuZ2lmPg0KPiBGcm9tOgk8ZWNibGFuay5naWY+DQo+IEphbWVzIE0gU25lbGwgPGphc25lbGxA Z21haWwuY29tPg0KPiA8ZWNibGFuay5naWY+DQo+IFRvOgk8ZWNibGFuay5naWY+DQo+ICJOaWt1 bmogUi4gTWVodGEiIDxuaWt1bmoubWVodGFAb3JhY2xlLmNvbT4NCj4gPGVjYmxhbmsuZ2lmPg0K PiBDYzoJPGVjYmxhbmsuZ2lmPg0KPiBBbCBCcm93bi9Db3N0YSBNZXNhL0lCTUBJQk1VUywgYXRv bS1zeW50YXggU3ludGF4IDxhdG9tLSANCj4gc3ludGF4QGltYy5vcmc+DQo+IDxlY2JsYW5rLmdp Zj4NCj4gRGF0ZToJPGVjYmxhbmsuZ2lmPg0KPiAwNi8wOC8yMDA5IDAzOjU0IFBNDQo+IDxlY2Js YW5rLmdpZj4NCj4gU3ViamVjdDoJPGVjYmxhbmsuZ2lmPg0KPiBSZTogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1kaXZpbGx5LWF0b20taGllcmFyY2h5LTAxDQo+DQo+DQo+DQo+ IEhlaCwgSSB0aGluayBzbyA7LSkNCj4NCj4gTmlrdW5qIFIuIE1laHRhIHdyb3RlOg0KPiA+IE9u IEp1biA4LCAyMDA5LCBhdCAzOjUxIFBNLCBKYW1lcyBNIFNuZWxsIHdyb3RlOg0KPiA+DQo+ID4+ IDxsaW5rIHJlbD0iZG93biIgdHlwZT0iYXBwbGljYXRpb24vYXRvbSt4bWw7dHlwZT1mZWVkO3By b2ZpbGU9dHJlZSINCj4gPj4gaHJlZj0iLi4uIiAvPg0KPiA+PiA8bGluayByZWw9ImRvd24iIHR5 cGU9ImFwcGxpY2F0aW9uL2F0b20reG1sO3R5cGU9ZmVlZDtwcm9maWxlPWZsYXQiDQo+ID4+IGhy ZWY9Ii4uLiIgLz4NCj4gPg0KPiA+DQo+ID4gSnVzdCBhIG5pdCwgbWVkaWEgdHlwZSBwYXJhbWV0 ZXJzIGFyZSAnLCcgc2VwYXJhdGVkLCBjb3JyZWN0Py4NCj4gPg0KPg0KPg0KDQoNCg== --part47127-boundary-1143295663-966394595 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="Windows-1252" PGh0bWw+PGJvZHkgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPlN1cmUg aXQgd291bGQuIE5vbmV0aGVsZXNzLCB0aGUgcHJvZmlsZSBtZWRpYSB0eXBlIGV4dGVuc2lvbiBz aG91bGQgYmUgZGVmaW5lZCBzZXBhcmF0ZWx5IGluIGl0cyBvd24gSS1ELiBJIGNhbiB3cml0ZSB0 aGF0IHVwLiBCZWVuIG1lYW5pbmcgdG8gZG8gc28gZm9yIGEgd2hpbGUuIDxici8+PHA+U2VudCBm cm9tIG15IFZlcml6b24gV2lyZWxlc3MgQmxhY2tCZXJyeTwvcD48cD48aHIgc2l6ZT0yIHdpZHRo PTEwMCUgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPjxiPkZyb208L2I+OiAgIk5pa3VuaiBSLiBN ZWh0YSIgPG5pa3Vuai5tZWh0YUBvcmFjbGUuY29tPjxicj48Yj5EYXRlPC9iPjogTW9uLCA4IEp1 biAyMDA5IDE2OjE0OjU5IC0wNzAwPGJyPjxiPlRvPC9iPjogQWwgQnJvd24mbHQ7YWxiZXJ0Y2Jy b3duQHVzLmlibS5jb20mZ3Q7PGJyPjxiPlN1YmplY3Q8L2I+OiBSZTogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1kaXZpbGx5LWF0b20taGllcmFyY2h5LTAxPGJyPjwvZm9udD48 L3A+PGRpdj5JIGFtIG5vdCBzdXJlIGlmIGEgbWVkaWEgdHlwZSBwYXJhbWV0ZXIgZm9yIEF0b20g d291bGQgYmUgd2l0aGluIHRoZSBzY29wZSBvZiBhbiBpbmxpbmUgZXh0ZW5zaW9uIGZvciBBdG9t LjwvZGl2PjxkaXY+PGJyPjxkaXYgYXBwbGUtY29udGVudC1lZGl0ZWQ9InRydWUiPiA8c3BhbiBj bGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg b3JwaGFuczogMjsgdGV4dC1hbGlnbjogYXV0bzsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3BhY2luZzogMHB4OyAtd2Via2l0LWJv cmRlci12ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1pbi1l ZmZlY3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMDsgIj48ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xs YXBzZTogc2VwYXJhdGU7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3BhY2luZzogMHB4OyAtd2Via2l0LWJvcmRl ci12ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1pbi1lZmZl Y3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyAiPjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyAiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iYm9yZGVyLWNvbGxh cHNlOiBzZXBhcmF0ZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhl aWdodDogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtYm9yZGVy LXZlcnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRlY29yYXRpb25zLWluLWVmZmVj dDogbm9uZTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7ICI+PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7ICI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29sbGFw c2U6IHNlcGFyYXRlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXIt dmVydGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0 OiBub25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgIj48ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsgIj48ZGl2Pk5pa3VuajwvZGl2PjxkaXY+PGEgaHJlZj0iaHR0cDovL28tbWljcm9uLmJsb2dz cG90LmNvbSI+aHR0cDovL28tbWljcm9uLmJsb2dzcG90LmNvbTwvYT48L2Rpdj48ZGl2Pjxicj48 L2Rpdj48L2Rpdj48L3NwYW4+PC9kaXY+PC9zcGFuPjwvZGl2Pjwvc3Bhbj48L2Rpdj48L3NwYW4+ PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4gPC9kaXY+PGJyPjxkaXY+PGRp dj5PbiBKdW4gOCwgMjAwOSwgYXQgNDoxMCBQTSwgQWwgQnJvd24gd3JvdGU6PC9kaXY+PGJyIGNs YXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 ZGl2PjxwPjx0dD4mZ3Q7IE9uIEp1biA4LCAyMDA5LCBhdCAzOjUxIFBNLCBKYW1lcyBNIFNuZWxs IHdyb3RlOjxicj4gJmd0Ozxicj4gJmd0OyZndDsgJmx0O2xpbmsgcmVsPSJkb3duIiB0eXBlPSJh cHBsaWNhdGlvbi9hdG9tK3htbDt0eXBlPWZlZWQ7cHJvZmlsZT10cmVlIiA8YnI+ICZndDsmZ3Q7 IGhyZWY9Ii4uLiIgLyZndDs8YnI+ICZndDsmZ3Q7ICZsdDtsaW5rIHJlbD0iZG93biIgdHlwZT0i YXBwbGljYXRpb24vYXRvbSt4bWw7dHlwZT1mZWVkO3Byb2ZpbGU9ZmxhdCIgPGJyPiAmZ3Q7Jmd0 OyBocmVmPSIuLi4iIC8mZ3Q7PGJyPiA8L3R0Pjxicj4gVGhpcyB3b3JrcyBmb3IgbWUuICBJIHdv dWxkIGxpa2UgdG8gc2VlIHRoZSBleHRlbnNpb24gdG8gdGhlIG1lZGlhIHR5cGUgaW4gdGhlIEkt RCBpbnN0ZWFkIG9mICJkb3duLXRyZWUiIGFuZCAidXAtdHJlZSIuPGJyPiA8YnI+IC1BbDxicj4g PGJyPiBBbCBCcm93bjxicj4gRW1lcmdpbmcgU3RhbmRhcmRzIGFuZCBJbmR1c3RyeSBGcmFtZXdv cmtzPGJyPiBDTUlTOiA8YSBocmVmPSJodHRwczovL3czLnRhcC5pYm0uY29tL3cza2kwNy9kaXNw bGF5L0VDTUNNSVMvSG9tZSI+aHR0cHM6Ly93My50YXAuaWJtLmNvbS93M2tpMDcvZGlzcGxheS9F Q01DTUlTL0hvbWU8L2E+IDxicj4gSW5kdXN0cnkgRnJhbWV3b3JrczogPGEgaHJlZj0iaHR0cHM6 Ly93My50YXAuaWJtLmNvbS93M2tpMDcvZGlzcGxheS9FQ01JRi9Ib21lIj5odHRwczovL3czLnRh cC5pYm0uY29tL3cza2kwNy9kaXNwbGF5L0VDTUlGL0hvbWU8L2E+PGJyPiA8YnI+IE9mZmljZSA3 MTQgMzI3IDM0NTM8YnI+IE1vYmlsZSA3MTQgMjYzIDY0NDE8YnI+IEVtYWlsICA8YSBocmVmPSJt YWlsdG86YWxiZXJ0Y2Jyb3duQHVzLmlibS5jb20iPmFsYmVydGNicm93bkB1cy5pYm0uY29tPC9h Pjxicj4gQ09ORklERU5USUFMIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZSwg aW5jbHVkaW5nIGFueSBhdHRhY2htZW50cywgYXJlIGNvbmZpZGVudGlhbCBhbmQgYXJlIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgcGVyc29uIG9yIGVudGl0eSB0byB3aG9tIHRo ZSBtZXNzYWdlIHdhcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQgb2YgdGhpcyBtZXNzYWdlLCBwbGVhc2UgYmUgYWR2aXNlZCB0aGF0IGFueSBkaXNzZW1p bmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNz YWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0aGlzIG1lc3NhZ2Ug aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlci4gUGxlYXNlIGFsc28gcGVybWFuZW50 bHkgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgYW5kIGFueSBhdHRh Y2hlZCBkb2N1bWVudGF0aW9uLiA8YnI+IDxicj4gPHNwYW4+Jmx0O2dyYXljb2wuZ2lmJmd0Ozwv c3Bhbj48Zm9udCBjb2xvcj0iIzQyNDI4MiI+SmFtZXMgTSBTbmVsbCAtLS0wNi8wOC8yMDA5IDAz OjU0OjM4IFBNLS0tSGVoLCBJIHRoaW5rIHNvIDstKTwvZm9udD48YnI+IDxicj4gPHRhYmxlIHdp ZHRoPSIxMDAlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+IDx0 Ym9keT48dHIgdmFsaWduPSJ0b3AiPjx0ZCB3aWR0aD0iMSUiPjxzcGFuPiZsdDtlY2JsYW5rLmdp ZiZndDs8L3NwYW4+PGJyPiA8Zm9udCBzaXplPSIyIiBjb2xvcj0iIzVGNUY1RiI+RnJvbTo8L2Zv bnQ+PC90ZD48dGQgd2lkdGg9IjEwMCUiPjxzcGFuPiZsdDtlY2JsYW5rLmdpZiZndDs8L3NwYW4+ PGJyPiA8Zm9udCBzaXplPSIyIj5KYW1lcyBNIFNuZWxsICZsdDs8YSBocmVmPSJtYWlsdG86amFz bmVsbEBnbWFpbC5jb20iPmphc25lbGxAZ21haWwuY29tPC9hPiZndDs8L2ZvbnQ+PC90ZD48L3Ry PiA8dHIgdmFsaWduPSJ0b3AiPjx0ZCB3aWR0aD0iMSUiPjxzcGFuPiZsdDtlY2JsYW5rLmdpZiZn dDs8L3NwYW4+PGJyPiA8Zm9udCBzaXplPSIyIiBjb2xvcj0iIzVGNUY1RiI+VG86PC9mb250Pjwv dGQ+PHRkIHdpZHRoPSIxMDAlIj48c3Bhbj4mbHQ7ZWNibGFuay5naWYmZ3Q7PC9zcGFuPjxicj4g PGZvbnQgc2l6ZT0iMiI+Ik5pa3VuaiBSLiBNZWh0YSIgJmx0OzxhIGhyZWY9Im1haWx0bzpuaWt1 bmoubWVodGFAb3JhY2xlLmNvbSI+bmlrdW5qLm1laHRhQG9yYWNsZS5jb208L2E+Jmd0OzwvZm9u dD48L3RkPjwvdHI+IDx0ciB2YWxpZ249InRvcCI+PHRkIHdpZHRoPSIxJSI+PHNwYW4+Jmx0O2Vj YmxhbmsuZ2lmJmd0Ozwvc3Bhbj48YnI+IDxmb250IHNpemU9IjIiIGNvbG9yPSIjNUY1RjVGIj5D Yzo8L2ZvbnQ+PC90ZD48dGQgd2lkdGg9IjEwMCUiIHZhbGlnbj0ibWlkZGxlIj48c3Bhbj4mbHQ7 ZWNibGFuay5naWYmZ3Q7PC9zcGFuPjxicj4gPGZvbnQgc2l6ZT0iMiI+QWwgQnJvd24vQ29zdGEg TWVzYS9JQk1ASUJNVVMsIGF0b20tc3ludGF4IFN5bnRheCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmF0 b20tc3ludGF4QGltYy5vcmciPmF0b20tc3ludGF4QGltYy5vcmc8L2E+Jmd0OzwvZm9udD48L3Rk PjwvdHI+IDx0ciB2YWxpZ249InRvcCI+PHRkIHdpZHRoPSIxJSI+PHNwYW4+Jmx0O2VjYmxhbmsu Z2lmJmd0Ozwvc3Bhbj48YnI+IDxmb250IHNpemU9IjIiIGNvbG9yPSIjNUY1RjVGIj5EYXRlOjwv Zm9udD48L3RkPjx0ZCB3aWR0aD0iMTAwJSI+PHNwYW4+Jmx0O2VjYmxhbmsuZ2lmJmd0Ozwvc3Bh bj48YnI+IDxmb250IHNpemU9IjIiPjA2LzA4LzIwMDkgMDM6NTQgUE08L2ZvbnQ+PC90ZD48L3Ry PiA8dHIgdmFsaWduPSJ0b3AiPjx0ZCB3aWR0aD0iMSUiPjxzcGFuPiZsdDtlY2JsYW5rLmdpZiZn dDs8L3NwYW4+PGJyPiA8Zm9udCBzaXplPSIyIiBjb2xvcj0iIzVGNUY1RiI+U3ViamVjdDo8L2Zv bnQ+PC90ZD48dGQgd2lkdGg9IjEwMCUiPjxzcGFuPiZsdDtlY2JsYW5rLmdpZiZndDs8L3NwYW4+ PGJyPiA8Zm9udCBzaXplPSIyIj5SZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1kaXZpbGx5LWF0b20taGllcmFyY2h5LTAxPC9mb250PjwvdGQ+PC90cj4gPC90Ym9keT48L3Rh YmxlPiA8L3A+PGhyIHdpZHRoPSIxMDAlIiBzaXplPSIyIiBhbGlnbj0ibGVmdCIgbm9zaGFkZT0i IiBzdHlsZT0iY29sb3I6IzgwOTFBNTsgIj48YnI+IDxicj4gPGJyPiA8dHQ+SGVoLCBJIHRoaW5r IHNvIDstKTxicj4gPGJyPiBOaWt1bmogUi4gTWVodGEgd3JvdGU6PGJyPiAmZ3Q7IE9uIEp1biA4 LCAyMDA5LCBhdCAzOjUxIFBNLCBKYW1lcyBNIFNuZWxsIHdyb3RlOjxicj4gJmd0Ozxicj4gJmd0 OyZndDsgJmx0O2xpbmsgcmVsPSJkb3duIiB0eXBlPSJhcHBsaWNhdGlvbi9hdG9tK3htbDt0eXBl PWZlZWQ7cHJvZmlsZT10cmVlIiA8YnI+ICZndDsmZ3Q7IGhyZWY9Ii4uLiIgLyZndDs8YnI+ICZn dDsmZ3Q7ICZsdDtsaW5rIHJlbD0iZG93biIgdHlwZT0iYXBwbGljYXRpb24vYXRvbSt4bWw7dHlw ZT1mZWVkO3Byb2ZpbGU9ZmxhdCIgPGJyPiAmZ3Q7Jmd0OyBocmVmPSIuLi4iIC8mZ3Q7PGJyPiAm Z3Q7PGJyPiAmZ3Q7PGJyPiAmZ3Q7IEp1c3QgYSBuaXQsIG1lZGlhIHR5cGUgcGFyYW1ldGVycyBh cmUgJywnIHNlcGFyYXRlZCwgY29ycmVjdD8uPGJyPiAmZ3Q7PGJyPiA8L3R0Pjxicj4gPGJyPiA8 L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvYm9keT48L2h0bWw+IA== --part47127-boundary-1143295663-966394595-- From owner-atom-syntax@mail.imc.org Mon Jun 8 16:37:12 2009 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 EC86728C0E2 for ; Mon, 8 Jun 2009 16:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.126 X-Spam-Level: X-Spam-Status: No, score=-5.126 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 nt8vksmLFPLB for ; Mon, 8 Jun 2009 16:37:09 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D893C3A6A88 for ; Mon, 8 Jun 2009 16:37:07 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MoxdJ027527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 15:50:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58MoxkR027526; Mon, 8 Jun 2009 15:50:59 -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 rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58Mow5v027519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jun 2009 15:50:58 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58MpnaI018844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Jun 2009 22:51:50 GMT Received: from abhmt006.oracle.com (abhmt006.oracle.com [141.146.116.15]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n58MopCv015480; Mon, 8 Jun 2009 22:50:58 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Jun 2009 15:50:45 -0700 Cc: atom-syntax Syntax , James M Snell Message-Id: <3BC8BA86-58FF-4CC8-ADBF-B411927A7A30@oracle.com> From: "Nikunj R. Mehta" To: Al Brown In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-3--93807316 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 Date: Mon, 8 Jun 2009 15:49:24 -0700 References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt006.oracle.com [141.146.116.15] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4A2D95CE.001E:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-3--93807316 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 8, 2009, at 3:44 PM, Al Brown wrote: > Nikunj wrote: > > Al Brown wrote: > > b. add a new attribute to link that specifies if they are inlined > (down) > (down-tree) > This adds complexity if there are cardinality constraints on link > relations such as alternate and clients not aware of I-D may think > they are the same. > >IMHO, ah:inlined does nothing because the presence of ae:inline > makes it plenty clear. If you were trying to say that there is a > certain level of depth in the tree, may >be an attribute would help, > but even then you don't know what things the server may have elided > from every entry. So, bottom line is, there is not much value to an > >attribute to describe the thing that is in-lined. You are best off > using what you have received as an approximation and then get the > exact representation if you care so >much in a separate network > call. Of course, out-of-band communication or specialized mark-up > may provide enough information for you to avoid such round-trips. > Maybe I did not explain clearly enough - this is a protocol/ > hypermedia issue. How does the client say (follow the right link > relation) I want an inlined representation of this resource > specified by a link relation? E.g., > The question is clearly phrased this time and I understand the intention. However, as I said in the previous message, modulo hreflang and type, Atom does not provide any means of advertising URIs for retrieving representation variants. This could be a source of your dissatisfaction but it applies equally well regardless of hierarchy or in-lining. > Client (C) navigates to this atom entry (A) somehow. A wants to > advertise to the client that A has references to two to > representations for resource B. One version of B is flat (ala a > feed). One version of B is the same flat feed with its link > relations inlined (ala tree). > > How can resource A provide the client C with information there are > two choices available for B (flat vs tree)? > Perhaps James Snell's template idea may be worth considering. I don't know yet. > -Al > > > Al Brown > Emerging Standards and Industry Frameworks > CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home > Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home > > Office 714 327 3453 > Mobile 714 263 6441 > Email albertcbrown@us.ibm.com > CONFIDENTIAL NOTICE: The contents of this message, including any > attachments, are confidential and are intended solely for the use of > the person or entity to whom the message was addressed. If you are > not the intended recipient of this message, please be advised that > any dissemination, distribution, or use of the contents of this > message is strictly prohibited. If you received this message in > error, please notify the sender. Please also permanently delete all > copies of the original message and any attached documentation. > > "Nikunj R. Mehta" ---06/08/2009 03:33:06 PM---As I see > it, whether there is a @rel=down-tree or not, you would have to > communicate certain information out-of-band, e.g., dep > > > From: > "Nikunj R. Mehta" > > To: > Al Brown/Costa Mesa/IBM@IBMUS > > Cc: > James M Snell , atom-syntax Syntax > > > Date: > 06/08/2009 03:33 PM > > Subject: > Re: New Version Notification for draft-divilly-atom-hierarchy-01 > > > > As I see it, whether there is a @rel=down-tree or not, you would > have to communicate certain information out-of-band, e.g., depth of > the tree or the level of completeness in every in-lined entry. > > Atom does not provide any means of advertising URIs for retrieving > representation variants. This could be a source of your > dissatisfaction but it applies equally well regardless of hierarchy > or in-lining. > > On Jun 8, 2009, at 3:11 PM, Al Brown wrote: > James wrote: > >Hmmm.... I know we've discussed this, but after thinking about it > more > >and looking through the examples, I'm becoming increasingly less > >convinced that we need a distinction between "down" and "down-tree". > >One should simply assume that "down" could point to a child entry or > >child feed and that those children could potentially also be parents. > >Yes, that possibly increases the processing compexity but I think it > >simplifies the model overall. > > We've discussed this today on the phone. For me this is a > difference of protocol/hypermedia vs. syntax. For syntax, "down" > and "up" are sufficient. A flat model can modeled with feed and a > tree can be modeled using generic inlining in a feed or entry. > > A client requests an atom document - entry or feed. How does the > server advertise to the client, via what is in the atom document, > here are two links to representations (flat vs. tree) of a resource, > e.g. the folder's children: one link returns a flat list (no > inlining) and one link returns a tree (inlined). > It is no different from seeing an HTML vs. a PDF representation of > the same blog entry. One gives you a lot of context such as > comments, related posts, advertisements and the like, and the other > may be limited. This problem, AFAICT, exists regardless of CMIS or > hierarchy. > Both are the same document just with or without inlining of linked > resources of a particular link relation. > For all practical purposes, they are different documents, i.e., > different representations of a single resource. > Since the resources are crossing the wire, the first resource (e.g., > folder) needs to convey how access a hierarchical resource (e.g., > items in a folder) in either a flat mode (feed) or tree (feed with > inlined resources). > > The options I see are: > a. append -tree to link relations that may inline (e.g., down-tree, > up-tree). Not so nice, but works. > It may not be specific enough anyway to say this is a tree link > because it says nothing about depth > b. add a new attribute to link that specifies if they are inlined > (down) > (down-tree) > This adds complexity if there are cardinality constraints on link > relations such as alternate and clients not aware of I-D may think > they are the same. > IMHO, ah:inlined does nothing because the presence of ae:inline > makes it plenty clear. If you were trying to say that there is a > certain level of depth in the tree, may be an attribute would help, > but even then you don't know what things the server may have elided > from every entry. So, bottom line is, there is not much value to an > attribute to describe the thing that is in-lined. You are best off > using what you have received as an approximation and then get the > exact representation if you care so much in a separate network call. > Of course, out-of-band communication or specialized mark-up may > provide enough information for you to avoid such round-trips. > c. leverage link templates rather than link relations > I am not aware of "link templates". If you are referring to draft- > gregorio-uri-templates, then too there is no notion of templates > baked in to the link element yet. > d. use out of band communication - append a uri argument such as > includeLinkRel=down to the URI of the resource; could also be HTTP > header. Not very RESTful but works. > > If the model is not sufficient to convey to the client here's a flat > mode vs. here's a tree mode, CMIS will have to find another > alternative as it is currently required by the CMIS domain model. > > I see the options for CMIS as: > 1. Leverage the model specified by the I-D if exists (best) > 2. Move down-tree to CMIS namespace. This does not solve the > protocol/hypermedia problem for anybody else. > 3. Specify in the CMIS specification an URI argument to enable > inlining of 'down'. > > -Al > > Al Brown > Emerging Standards and Industry Frameworks > CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home > Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home > > Office 714 327 3453 > Mobile 714 263 6441 > Email albertcbrown@us.ibm.com > CONFIDENTIAL NOTICE: The contents of this message, including any > attachments, are confidential and are intended solely for the use of > the person or entity to whom the message was addressed. If you are > not the intended recipient of this message, please be advised that > any dissemination, distribution, or use of the contents of this > message is strictly prohibited. If you received this message in > error, please notify the sender. Please also permanently delete all > copies of the original message and any attached documentation. > > James M Snell ---06/08/2009 11:55:37 AM---Comments > below... > > From: > James M Snell > > To: > Al Brown/Costa Mesa/IBM@IBMUS > > Cc: > "Nikunj R. Mehta" , Atom-Syntax Syntax >, owner-atom-syntax@mail.imc.org > > Date: > 06/08/2009 11:55 AM > > Subject: > Re: Fwd: New Version Notification for draft-divilly-atom-hierarchy-01 > > > > Comments below... > > Al Brown wrote: > > > > The 01 draft is a much better. I am concerned the generic mechanism > > using inlining links is sub-optimal for displaying a hierarchy that > > this I-D helps navigate via the new link relations. > > > in-lining arbitrarily complex hierarchies is always going to be > problematic and suboptimal... which is why I was so adamant about not > baking hierarchy into Atom and Atompub in the first place when we were > working on all this stuff initially. Despite the added verbosity that > this approach adds, however, I think it's likely the most acceptable > approach. > > > First example: there are two down relations: down and down-tree. > It is > > important to have both of those link relations on the [standalone] > > atom entry that represents a folder so the client can chose a flat > > (feed) or tree (expanded feed) representation. If the client chooses > > the tree representation, then on the atom feed returned the server > > will inline using the link relation down. down-tree is not expanded > > with content inline. E.g., > > > > > > ... > > > > > href="/finance/feeds/default/portfolios/1/positions"> > > > > > > > > > > ... > > > > > href="/finance/feeds/default/portfolios/1/positions"/> > > ... > > > > > > > > > > ... > > > href="/finance/feeds/default/portfolios/1/positions/down"> > > > > > > > href="/finance/feeds-tree/default/portfolios/1/positions/down" /> > > > > ... > > > > > > > > ... > > ... > > > > > > > > > href="/finance/feeds-tree/default/portfolios/1/positions" /> > > > > ... > > > > > > The contents of the down link relation will be what should be > included > > in the down-tree due to recursion through the atom entries. Having a > > separate extension element, side-steps this issue of expression. > > > Hmmm.... I know we've discussed this, but after thinking about it more > and looking through the examples, I'm becoming increasingly less > convinced that we need a distinction between "down" and "down-tree". > One should simply assume that "down" could point to a child entry or > child feed and that those children could potentially also be parents. > Yes, that possibly increases the processing compexity but I think it > simplifies the model overall. > > > Second example: verbosity > > This proposal now has: > > > > ... > > > href="/finance/feeds/default/portfolios/1/positions"> > > > > > > > href="/finance/feeds/default/portfolios/1/positions"/> > > ... > > ... > > ... > > ... > > > > > > > > ... > > > > > > instead of a simpler mechanism: > > > > ... > > > > ... > > ... > > ... > > > > ... > > > > > > The I-D introduces a concept of hierarchy through > > up/up-tree/down-tree/down relations yet a all-purpose mechanism for > > inclusion. Most (all?) of the information on the feed element is > > duplicated on the enclosing entry (id, uri, etc). Can't we do better > > for this specific scenario the I-D is addressing? > > > I think we can address this by eliminating the restriction that "down" > and "up" must always point to Atom feed documents and by changing the > cardinality rules for those links. That restriction, I think, is > arbitrary and unnecessary > > It would allow us to do something like.... > > > ... > href="child1"> > > ... > > > href="child2"> > > ... > > > ... > href="childN"> > > ... > > > ... > > > Unlike any of the other methods discussed, this approach would allow > clients that don't understand the hierarchy model to still understand > that there is some kind of link relationship with each of the > individual > child resources and eliminates the need to include the extraneous > atom:feed metadata. > > Note that this is the same basic approach taken by my comment thread > extension (in-reply-to). > > - James > > > --Apple-Mail-3--93807316 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Jun 8, 2009, at = 3:44 PM, Al Brown wrote: Nikunj wrote: > Al Brown wrote: b. = add a new attribute to link that specifies if they are inlined = (down) <link rel=3D"down" href=3D"http://www.example.com/foo/down" /> (down-tree) <link rel=3D"down" = ah:inlined=3D"true" href=3D"http://www.example.com/foo/down/inlined" /> This adds complexity if there are cardinality = constraints on link relations such as alternate and clients not aware of = I-D may think they are the same. >IMHO, ah:inlined does nothing because the presence of = ae:inline makes it plenty clear. If you were trying to say that there is = a certain level of depth in the tree, may >be an attribute would = help, but even then you don't know what things the server may have = elided from every entry. So, bottom line is, there is not much value to = an >attribute to describe the thing that is in-lined. You are best = off using what you have received as an approximation and then get the = exact representation if you care so >much in a separate network call. = Of course, out-of-band communication or specialized mark-up may provide = enough information for you to avoid such round-trips.Maybe I = did not explain clearly enough - this is a protocol/hypermedia issue. = How does the client say (follow the right link relation) I want an = inlined representation of this resource specified by a link relation? = E.g., The question is clearly phrased this = time and I understand the intention. However, as I said in the previous = message, modulo hreflang and type, Atom does not provide any means of advertising URIs for = retrieving representation variants. This could be a source of your = dissatisfaction but it applies equally well regardless of hierarchy or = in-lining. Client (C) navigates to this atom entry (A) = somehow. A wants to advertise to the client that A has references to = two to representations for resource B. One version of B is flat (ala a = feed). One version of B is the same flat feed with its link relations = inlined (ala tree). How can resource A provide the client C with = information there are two choices available for B (flat vs tree)? = Perhaps James Snell's template idea may be = worth considering. I don't know yet.-Al Al Brown Emerging Standards = and Industry Frameworks CMIS: https://w3.tap= .ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.i= bm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 = Mobile 714 263 6441 Email albertcbrown@us.ibm.com = CONFIDENTIAL NOTICE: The contents of this message, including any = attachments, are confidential and are intended solely for the use of the = person or entity to whom the message was addressed. If you are not the = intended recipient of this message, please be advised that any = dissemination, distribution, or use of the contents of this message is = strictly prohibited. If you received this message in error, please = notify the sender. Please also permanently delete all copies of the = original message and any attached documentation. = <graycol.gif>"Nikunj R. = Mehta" ---06/08/2009 03:33:06 PM---As I see it, whether there is a = @rel=3Ddown-tree or not, you would have to communicate certain = information out-of-band, e.g., dep <ecblank.gif> = From: <ecblank.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.com> <ecblank.gif> To: <ecblank.gif> Al = Brown/Costa Mesa/IBM@IBMUS <ecblank.gif> Cc: <ecblank.gif> James M Snell <jasnell@gmail.com>, atom-syntax = Syntax <atom-syntax@imc.org> <ecblank.gif> Date: <ecblank.gif> 06/08/2009 03:33 PM <ecblank.gif> Subject: <ecblank.gif> Re: = New Version Notification for = draft-divilly-atom-hierarchy-01 = As I see it, = whether there is a @rel=3Ddown-tree or not, you would have to = communicate certain information out-of-band, e.g., depth of the tree or = the level of completeness in every in-lined entry. = Atom does not provide any means of advertising URIs for = retrieving representation variants. This could be a source of your = dissatisfaction but it applies equally well regardless of hierarchy or = in-lining. On Jun 8, 2009, at 3:11 PM, = Al Brown wrote: James = wrote: >Hmmm.... I know we've = discussed this, but after thinking about it more >and looking = through the examples, I'm becoming increasingly less >convinced = that we need a distinction between "down" and "down-tree". = >One should simply assume that "down" could point to a child entry or = >child feed and that those children could potentially also be = parents. >Yes, that possibly increases the processing compexity = but I think it >simplifies the model overall. We've discussed this = today on the phone. For me this is a difference of = protocol/hypermedia vs. syntax. For syntax, "down" and "up" are = sufficient. A flat model can modeled with feed and a tree can be = modeled using generic inlining in a feed or entry. A client requests an = atom document - entry or feed. How does the server advertise to = the client, via what is in the atom document, here are two links to = representations (flat vs. tree) of a resource, e.g. the folder's = children: one link returns a flat list (no inlining) and one link = returns a tree (inlined). It is no different from seeing an HTML vs. a PDF = representation of the same blog entry. One gives you a lot of context = such as comments, related posts, advertisements and the like, and the = other may be limited. This problem, AFAICT, exists regardless of CMIS or = hierarchy. Both are the same = document just with or without inlining of linked resources of a = particular link relation. For all practical purposes, they are different documents, = i.e., different representations of a single resource. = Since the resources are crossing the wire, the = first resource (e.g., folder) needs to convey how access a hierarchical = resource (e.g., items in a folder) in either a flat mode (feed) or tree = (feed with inlined resources). The = options I see are: a. append -tree to link relations that may inline = (e.g., down-tree, up-tree). Not so nice, but works. = It may not be specific enough anyway to say this is a = tree link because it says nothing about depth b. add a new attribute to link that specifies if they are = inlined (down) <link rel=3D"down" href=3D"http://www.example.com/foo/down" /> (down-tree) <link rel=3D"down" = ah:inlined=3D"true" href=3D"http://www.example.com/foo/down/inlined" /> This adds complexity if there are cardinality = constraints on link relations such as alternate and clients not aware of = I-D may think they are the same. IMHO, = ah:inlined does nothing because the presence of ae:inline makes it = plenty clear. If you were trying to say that there is a certain level of = depth in the tree, may be an attribute would help, but even then you = don't know what things the server may have elided from every entry. So, = bottom line is, there is not much value to an attribute to describe the = thing that is in-lined. You are best off using what you have received as = an approximation and then get the exact representation if you care so = much in a separate network call. Of course, out-of-band communication or = specialized mark-up may provide enough information for you to avoid such = round-trips. c. leverage link templates = rather than link relations I am not = aware of "link templates". If you are referring to = draft-gregorio-uri-templates, then too there is no notion of templates = baked in to the link element yet. d. = use out of band communication - append a uri argument such as = includeLinkRel=3Ddown to the URI of the resource; could also be HTTP = header. Not very RESTful but works. If the model is not = sufficient to convey to the client here's a flat mode vs. here's a tree = mode, CMIS will have to find another alternative as it is currently = required by the CMIS domain model. I see the options for CMIS = as: 1. Leverage the model specified by the I-D if exists (best) = 2. Move down-tree to CMIS namespace. This does not solve the = protocol/hypermedia problem for anybody else. 3. Specify in the CMIS = specification an URI argument to enable inlining of 'down'. = -Al Al Brown Emerging Standards and Industry Frameworks = CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home<= /u> Office 714 327 3453 Mobile 714 263 = 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, = including any attachments, are confidential and are intended solely for = the use of the person or entity to whom the message was addressed. If = you are not the intended recipient of this message, please be advised = that any dissemination, distribution, or use of the contents of this = message is strictly prohibited. If you received this message in error, = please notify the sender. Please also permanently delete all copies of = the original message and any attached documentation. = <graycol.gif>James M = Snell ---06/08/2009 11:55:37 AM---Comments below... = = = <ecblank.gif> From: <ecblank.gif> James M Snell <jasnell@gmail.com> <ecblank.gif> = To: <ecblank.gif> Al Brown/Costa = Mesa/IBM@IBMUS <ecblank.gif> = Cc: <ecblank.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.com>, = Atom-Syntax Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org <ecblank.gif> = Date: <ecblank.gif> 06/08/2009 11:55 AM <ecblank.gif> = Subject: <ecblank.gif> Re: Fwd: New Version = Notification for draft-divilly-atom-hierarchy-01 = Comments below... Al Brown wrote: > > The 01 = draft is a much better. I am concerned the generic mechanism > = using inlining links is sub-optimal for displaying a hierarchy that = > this I-D helps navigate via the new link relations. > = in-lining arbitrarily complex hierarchies is always going to be = problematic and suboptimal... which is why I was so adamant about not = baking hierarchy into Atom and Atompub in the first place when we = were working on all this stuff initially. Despite the added = verbosity that this approach adds, however, I think it's likely the = most acceptable approach. > First example: there are = two down relations: down and down-tree. It is > important to = have both of those link relations on the [standalone] > atom = entry that represents a folder so the client can chose a flat > = (feed) or tree (expanded feed) representation. If the client chooses = > the tree representation, then on the atom feed returned the = server > will inline using the link relation down. down-tree is = not expanded > with content inline. E.g., > > = <atom:entry> > ... >  > <atom:link rel=3D"down" = type=3D"application/atom+xml;type=3Dfeed" > = href=3D"/finance/feeds/default/portfolios/1/positions"> > = <ae:inline> > <atom:feed> >  > <atom:entry> > ... >  > <atom:link rel=3D"down" = > href=3D"/finance/feeds/default/portfolios/1/positions"/> = > ... > <ae:inline> > <atom:feed> > =  > <atom:entry> > ... = > <atom:link rel=3D"down" > = href=3D"/finance/feeds/default/portfolios/1/positions/down"> > =  > </atom:link> > = <atom:link rel=3D"down-tree" > = href=3D"/finance/feeds-tree/default/portfolios/1/positions/down" = /> > > ... > </atom:entry> > = </atom:feed> > </ae:inline> > = <atom:entry>...</atom:entry> > = <atom:entry>...</atom:entry> > </atom:feed> = > </ae:inline> > </atom:link> > = <atom:link rel=3D"down-tree" = type=3D"application/atom+xml;type=3Dfeed" > = href=3D"/finance/feeds-tree/default/portfolios/1/positions" /> = > > ... > </atom:entry> > > The = contents of the down link relation will be what should be included = > in the down-tree due to recursion through the atom entries. Having = a > separate extension element, side-steps this issue of = expression. > Hmmm.... I know we've discussed this, but after = thinking about it more and looking through the examples, I'm = becoming increasingly less convinced that we need a distinction = between "down" and "down-tree". One should simply assume that = "down" could point to a child entry or child feed and that those = children could potentially also be parents. Yes, that possibly = increases the processing compexity but I think it simplifies the = model overall. > Second example: verbosity > This = proposal now has: > <atom:entry> > ... > = <atom:link rel=3D"down" type=3D"application/atom+xml;type=3Dfeed" = > href=3D"/finance/feeds/default/portfolios/1/positions"> > = <ae:inline> > <atom:feed> > <atom:link = rel=3D"self" > = href=3D"/finance/feeds/default/portfolios/1/positions"/> > = ... > <atom:entry>...</atom:entry> > = <atom:entry>...</atom:entry> > = <atom:entry>...</atom:entry> > </atom:feed> = > </ae:inline> > </atom:link> > ... = > </atom:entry> > > instead of a simpler = mechanism: > <atom:entry> > ... > = <ah:include rel=3D"down"> > = <atom:entry>...</atom:entry> > = <atom:entry>...</atom:entry> > = <atom:entry>...</atom:entry> > = </ah:include> > ... > </atom:entry> = > > The I-D introduces a concept of hierarchy through = > up/up-tree/down-tree/down relations yet a all-purpose mechanism for = > inclusion. Most (all?) of the information on the feed element = is > duplicated on the enclosing entry (id, uri, etc). Can't we = do better > for this specific scenario the I-D is = addressing? > I think we can address this by eliminating the = restriction that "down" and "up" must always point to Atom feed = documents and by changing the cardinality rules for those links. = That restriction, I think, is arbitrary and unnecessary It = would allow us to do something like.... <atom:entry> = ... <atom:link rel=3D"down" = type=3D"application/atom+xml;type=3Dentry" href=3D"child1"> = <ae:inline> <atom:entry>...</atom:entry> = </ae:inline> </atom:link> <atom:link rel=3D"down" = type=3D"application/atom+xml;type=3Dentry" href=3D"child2"> = <ae:inline> <atom:entry>...</atom:entry> = </ae:inline> </atom:link> ... <atom:link = rel=3D"down" type=3D"application/atom+xml;type=3Dentry" = href=3D"childN"> <ae:inline> = <atom:entry>...</atom:entry> </ae:inline> = </atom:link> ... </atom:entry> Unlike any = of the other methods discussed, this approach would allow clients = that don't understand the hierarchy model to still understand that = there is some kind of link relationship with each of the individual = child resources and eliminates the need to include the extraneous = atom:feed metadata. Note that this is the same basic approach = taken by my comment thread extension (in-reply-to). - = James = = --Apple-Mail-3--93807316-- From owner-atom-syntax@mail.imc.org Mon Jun 8 19:36:29 2009 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 516D93A6B30 for ; Mon, 8 Jun 2009 19:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9wGEaIXLoKK for ; Mon, 8 Jun 2009 19:36:25 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id F0A643A67E7 for ; Mon, 8 Jun 2009 19:36:24 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n592OS17035680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 19:24:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n592OS1i035678; Mon, 8 Jun 2009 19:24: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 smtp.ischool.berkeley.edu (bliss.ISchool.Berkeley.EDU [128.32.78.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n592OGLG035666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 19:24:27 -0700 (MST) (envelope-from dret@berkeley.edu) Received: from [128.32.226.188] (dhcp188.ISchool.Berkeley.EDU [128.32.226.188]) (authenticated bits=0) by smtp.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id n592OGQb019356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Jun 2009 19:24:16 -0700 Message-ID: <4A2DC7CF.7030305@berkeley.edu> Date: Mon, 08 Jun 2009 19:24:15 -0700 From: Erik Wilde User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Nikunj R. Mehta" CC: atom-syntax Syntax , atom-protocol Protocol Subject: Re: Exploring a new WG around Atom References: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> In-Reply-To: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 128.32.78.13 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hello nikunj. > Recent discussions on the atom-syntax mailing list has revealed interest > in creating a new WG to look at several extensions of Atom. Here are > several extensions that have been discussed: > 1. Hierarchy operations including meta-publishing > 2. In-line representation > 3. Bi-directional text > Please respond to this email if you are interested in helping to explore > a new WG further. Please also identify if you have a specific interest > area to consider for a potential new Atom WG. i'd be interested in exploring the idea of a new WG. i think that more and more people are exploring Atom outside of its national habitat of blogging and newsfeeds, and it's essential for the continuing success of Atom to try to find a good balance of an increasingly diverse user base, and some consensus to avoid a partly overlapping and inconsistent set of extensions. my specific areas of interest are geolocation, and how to make feeds queryable. both of these issues are currently more research areas than immediate specification goals (and GeoRSS for location is good enough for the moment, although some clarification or best practices document for it might be a good idea). cheers, erik wilde tel:+1-510-6432253 - fax:+1-510-6425814 dret@berkeley.edu - http://dret.net/netdret UC Berkeley - School of Information (ISchool) From owner-atom-syntax@mail.imc.org Mon Jun 8 21:17:12 2009 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 1F1553A68F4 for ; Mon, 8 Jun 2009 21:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 D2LR1-A5agLG for ; Mon, 8 Jun 2009 21:17:11 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 176543A6850 for ; Mon, 8 Jun 2009 21:17:10 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5944fVb039391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 21:04:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5944fW5039390; Mon, 8 Jun 2009 21:04: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-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5944TOa039374; Mon, 8 Jun 2009 21:04:39 -0700 (MST) (envelope-from pjkeane@gmail.com) Received: by gxk3 with SMTP id 3so1410286gxk.10 for ; Mon, 08 Jun 2009 21:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=wIHyq0rSwlIkAsbi5tgPCg+7qoxeHPw3m2OxFgvZdu0=; b=NMVSyLIBCXlCxg31LDHOw88syF7H94IEMOp+sXI2YdvLcb7aglljgBlmU5Kf7P26dx yZ97GpqCDfqhXi+73I7HRJaR3MXESfUYw4q/SJrcUalYEDmIHdUadbpAdEE1bLD4tFS5 fKBPknOWtWYRTtSAgRNUYPKSuFkRcJOjjX8/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=xq99c1qRiNU6um0kI+i1yIOtPTHrONJZvTlVgfjbmYhTsSiFiAw/yr9sA3JXAMdyBS ivoKx5j+ckacKUfXfCB5hGzM3PsyH7XiAY0pmcXLVQTv1t3DYnzGDmNimDvQdQC0J2MV xmHmaqTxv0UVTaM+E+ETJWcF5qi4Zf0Wf7ItE= MIME-Version: 1.0 Received: by 10.151.121.11 with SMTP id y11mr14223121ybm.154.1244520267096; Mon, 08 Jun 2009 21:04:27 -0700 (PDT) In-Reply-To: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> References: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> Date: Mon, 8 Jun 2009 23:04:27 -0500 X-Google-Sender-Auth: 22d7f1dd90965cf1 Message-ID: <8158ad750906082104g5cbc1255xd49552d8b92f6dd@mail.gmail.com> Subject: Re: Exploring a new WG around Atom From: Peter Keane To: "Nikunj R. Mehta" Cc: atom-syntax Syntax , atom-protocol Protocol Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I am definitely interested. Particular areas of interest are querying operations, hierarchy, link extensions, feature discovery (atompub). I am also quite interested in link and categories as first-class addressable resources (although that's fairly off the map at this point). --peter On Mon, Jun 8, 2009 at 3:41 PM, Nikunj R. Mehta wrote: > > Recent discussions on the atom-syntax mailing list has revealed interest in > creating a new WG to look at several extensions of Atom. Here are several > extensions that have been discussed: > > 1. Hierarchy operations including meta-publishing > 2. In-line representation > 3. Bi-directional text > > Please respond to this email if you are interested in helping to explore a > new WG further. Please also identify if you have a specific interest area to > consider for a potential new Atom WG. > > Nikunj > http://o-micron.blogspot.com > > From owner-atom-syntax@mail.imc.org Mon Jun 8 21:34:28 2009 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 3D1E43A6AEB for ; Mon, 8 Jun 2009 21:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohjxiB2BohpT for ; Mon, 8 Jun 2009 21:34:27 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0E9383A6AC6 for ; Mon, 8 Jun 2009 21:34:26 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n594OCQ3040199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 21:24:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n594OCCm040197; Mon, 8 Jun 2009 21:24: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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.146]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n594O0Aw040181; Mon, 8 Jun 2009 21:24:11 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qw-out-1920.google.com with SMTP id 14so2775476qwa.28 for ; Mon, 08 Jun 2009 21:24:00 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=fYC4pg1CvAIEe84n2URCATqWp4Qsc2gLw/mBN/CUID4=; b=wmDZKX5WZlr4zXFUe1CEeswx1Jg5zY6Gccs2wzMbOnDn6EeGlR/4TmDWScVjPSZa3K 5LCXECBZqanNHTehZiRLtjHZ18CJQwemRH9p8T+QuOvO82zn/v4dF32VLDO+LDBpgc/l gxgft+LBxOI+Bw6kFnge2OUnpeuoPgX91DWjc= 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:content-type:content-transfer-encoding; b=QWRzQXD5UtEAg8AppvIA3GVfrHjESg3MpNXWf2v6d6eyu/eusF7tZQCHlNmBUfARq3 AaiYU5sXr25UD+AIpvqZvol8/V4XrWijLtZvxF/6aX+WziS/FM8Y+9yhoY18rd/zUrqU XlEAM94/MLuZVqI9mrB2CcAgA108WJJAzjGMI= Received: by 10.224.37.149 with SMTP id x21mr7635202qad.28.1244521440127; Mon, 08 Jun 2009 21:24:00 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 8sm875697qwj.4.2009.06.08.21.23.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 21:23:59 -0700 (PDT) Message-ID: <4A2DE417.4050508@gmail.com> Date: Mon, 08 Jun 2009 21:24:55 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Nikunj R. Mehta" CC: atom-syntax Syntax , atom-protocol Protocol Subject: Re: Exploring a new WG around Atom References: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> In-Reply-To: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> 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: I think it's obvious at this point that I would be interested ;-) The Atom feature, bidi, hierarchy and link extension mechanisms are of particular interest, as is the possible definition of a new profile media type parameter. - James Nikunj R. Mehta wrote: > > Recent discussions on the atom-syntax mailing list has revealed > interest in creating a new WG to look at several extensions of Atom. > Here are several extensions that have been discussed: > > 1. Hierarchy operations including meta-publishing > 2. In-line representation > 3. Bi-directional text > > Please respond to this email if you are interested in helping to > explore a new WG further. Please also identify if you have a specific > interest area to consider for a potential new Atom WG. > > Nikunj > http://o-micron.blogspot.com > > From owner-atom-syntax@mail.imc.org Mon Jun 8 22:13:24 2009 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 E65423A6B58 for ; Mon, 8 Jun 2009 22:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=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 V52xlqyRunI8 for ; Mon, 8 Jun 2009 22:13:24 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A3E9C3A6A9C for ; Mon, 8 Jun 2009 22:13:23 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5952HsF041558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 22:02:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5952HRv041557; Mon, 8 Jun 2009 22:02: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 mail-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5952FDf041550 for ; Mon, 8 Jun 2009 22:02:16 -0700 (MST) (envelope-from pjkeane@gmail.com) Received: by gxk3 with SMTP id 3so1566433gxk.10 for ; Mon, 08 Jun 2009 22:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=5jjqrFIUZP0nKqXYb+H8ZH0SUzeZ4t2mcKm+CSJb2kQ=; b=ZYSRkel/f3SMr8bzyA3nvHIscPzmviKfu77gI20hV6pdaqgvFX/2UpKEt18EgCjS38 TQDrtb4MzJwKjxdm3rLWrWPePvxjwpq9rdFxFO/kRfJJC86bN0pQtxG4L9PKE+r6mJNf nQ+HgTUdoU5P1ewIQN8uZLjKwxfh0HtxaMlXg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=h7QAPVBimkfRs6ZwI8fATIkYcZRX1puOQLhQ0GeTNfpsFRBGyS3bfPLCCcCfne3x7y NZRrPQL0k2fP7QHZ1bAmdkXoY2Akx8/CkAZPWFGd1vlPXiRbsZsQKaLfwKfcTzUvjpij JBzNgV9JqgYrSlKdUqjbmjbnLzWjvS+7ghJY8= MIME-Version: 1.0 Received: by 10.150.218.21 with SMTP id q21mr14256838ybg.43.1244523735687; Mon, 08 Jun 2009 22:02:15 -0700 (PDT) In-Reply-To: <4A2D7502.7000805@gmail.com> References: <20090605170645.A922728C10F@core3.amsl.com> <4A2D5EDC.1020207@gmail.com> <117E3344-2F66-4B24-B22A-97EDAAF3F5FD@oracle.com> <4A2D7502.7000805@gmail.com> Date: Tue, 9 Jun 2009 00:02:15 -0500 X-Google-Sender-Auth: cb6f1666ee5f39bd Message-ID: <8158ad750906082202q669c6f42h255ce27104e568db@mail.gmail.com> Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 From: Peter Keane To: James M Snell Cc: "Nikunj R. Mehta" , Al Brown , Atom-Syntax Syntax Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Jun 8, 2009 at 3:30 PM, James M Snell wrote: > > > Nikunj R. Mehta wrote: >> [snip] >> >> I can see how there is value in sporting a more flexible (and hence a mo= re >> complex) model, I fail to see requirements for adding this complexity. >> Rather than treating the hierarchy I-D approach as arbitrary, I implore = the >> group to identify reasons to expand the cardinality before making this >> arbitrary choice. >> > This is backwards. Cardinality constraints are a restriction. To ensure > maximum flexibility, one needs to justify adding the restriction, not > justify removing it. All that I'm saying is that the existing cardinality > rules impose a restriction on the model that does not appear to be strict= ly > necessary and could potentially be harmful long term. For instance, given > the current definition, one would need to invent yet another set of > hierarchy rel relations in order to implement a graph model, which, to me= at > least, seems counterproductive. Define "down" and "up" more generically a= nd > move the cardinality constraints to the application where they belong. = =C2=A0Note > that relaxing the cardinality does not make it any more difficult to achi= eve > the result you are looking for. =C2=A0An application could still use mult= iple > rel=3Ddown links to point to alternate language representations of the sa= me > logical child feed, for instance, Atom processors would simply treat thos= e > alternate language representations as separate child feeds leaving it up = to > the application to make the appropriate connections. I am definitely in agreement w/ James here. I'd like/need to be able to have multiple 'up' and 'down' links of the same type and let the application sort 'em out. 0:1 is a constraint I'd need to figure a way around. --peter >>> >>> >>> Note that this is the same basic approach taken by my comment thread >>> extension (in-reply-to). From owner-atom-syntax@mail.imc.org Tue Jun 9 06:50:15 2009 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 2149D3A6819 for ; Tue, 9 Jun 2009 06:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dmYNQDlFs32 for ; Tue, 9 Jun 2009 06:50:13 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 839F63A6806 for ; Tue, 9 Jun 2009 06:50:13 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59DbBrB068735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 06:37:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59DbBQs068733; Tue, 9 Jun 2009 06:37: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 ctcipmx01.ap.org (mega-demo.hosted.ap.org [165.1.59.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59DaxcT068712; Tue, 9 Jun 2009 06:37:10 -0700 (MST) (envelope-from prvs=4046d3bb3=SMyles@ap.org) DomainKey-Signature: s=DKONE; d=ap.org; c=nofws; q=dns; h=Received:Received:X-MimeOLE:Content-class:MIME-Version: Subject:Date:Message-ID:In-Reply-To:X-MS-Has-Attach: X-MS-TNEF-Correlator:Thread-Topic:thread-index:References: From:To:Return-Path:X-OriginalArrivalTime: Content-Transfer-Encoding:Content-Type; b=kV2ClCdiN+kCKp65U+DxsUMQtgbCdYegp9VPfVcMf0gdFTBeXX1Odmaj EXPt1GdOtzZm9uG9gZZoQ4/P3m/5Mrphg3pgRWaVzzjf+bQCdQpw+vzLy 5HRy4ZROW+xPeqFLNV3seFLwCt3rxE4Kgu5s2+Fec+U6mJ1Q6YmWaEBpb I=; Received: from ctcxfe04.ap.org ([10.1.30.84]) by ctcipdx01.ap.org with ESMTP; 09 Jun 2009 09:36:58 -0400 Received: from NYCXMB01.ap.org ([10.5.243.20]) by ctcxfe04.ap.org with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 09:36:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Exploring a new WG around Atom Date: Tue, 9 Jun 2009 09:36:57 -0400 Message-ID: <1B66071016731C4B913D744EA766779B0CF39ABB@NYCXMB01.ap.org> In-Reply-To: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Exploring a new WG around Atom thread-index: AcnoefhgIDCSqEs8R9y9vsgY+vvmxgAjPR6Q References: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> From: "Myles, Stuart" To: "Nikunj R. Mehta" , "atom-syntax Syntax" , "atom-protocol Protocol" X-OriginalArrivalTime: 09 Jun 2009 13:36:59.0263 (UTC) FILETIME=[5D1770F0:01C9E907] Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I'd be interested in participating in the proposed new WG. My interest areas would include hierarchy and metapublishing and in-line representation. But it would also extend to areas such as retracting and expiring previously published items (e.g. using ATOM to keep distributed databases in synch). Regards, Stuart -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Nikunj R. Mehta Sent: Monday, June 08, 2009 4:42 PM To: atom-syntax Syntax; atom-protocol Protocol Subject: Exploring a new WG around Atom Recent discussions on the atom-syntax mailing list has revealed =20 interest in creating a new WG to look at several extensions of Atom. =20 Here are several extensions that have been discussed: 1. Hierarchy operations including meta-publishing 2. In-line representation 3. Bi-directional text Please respond to this email if you are interested in helping to =20 explore a new WG further. Please also identify if you have a specific =20 interest area to consider for a potential new Atom WG. Nikunj http://o-micron.blogspot.com The information contained in this communication is intended for the use of the designated recipients named above. If the reader of this=20 communication is not the intended recipient, you are hereby notified that you have received this communication in error, and that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please=20 notify The Associated Press immediately by telephone at +1-212-621-1898=20 and delete this e-mail. Thank you. [IP_US_DISC] msk dccc60c6d2c3a6438f0cf467d9a4938 From owner-atom-syntax@mail.imc.org Tue Jun 9 11:19:30 2009 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 CDFB93A68C1 for ; Tue, 9 Jun 2009 11:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, MISSING_HEADERS=1.292, URI_HEX=0.368, 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 isd-ats-t408 for ; Tue, 9 Jun 2009 11:19:29 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8BAD93A6D3D for ; Tue, 9 Jun 2009 11:19:29 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59I5InX084473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 11:05:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59I5Ijq084472; Tue, 9 Jun 2009 11:05: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 wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59I57TM084456; Tue, 9 Jun 2009 11:05:17 -0700 (MST) (envelope-from mart@degeneration.co.uk) Received: by wf-out-1314.google.com with SMTP id 28so70744wfc.28 for ; Tue, 09 Jun 2009 11:05:06 -0700 (PDT) Received: by 10.142.218.4 with SMTP id q4mr133621wfg.225.1244570706784; Tue, 09 Jun 2009 11:05:06 -0700 (PDT) Received: from ?192.168.64.79? ([204.9.180.30]) by mx.google.com with ESMTPS id 31sm2426023wff.4.2009.06.09.11.05.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Jun 2009 11:05:06 -0700 (PDT) Message-ID: <4A2EA450.2050507@degeneration.co.uk> Date: Tue, 09 Jun 2009 11:05:04 -0700 From: Martin Atkins User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 CC: atom-syntax Syntax , atom-protocol Protocol Subject: Re: Exploring a new WG around Atom References: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> In-Reply-To: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> 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: Nikunj R. Mehta wrote: > > Recent discussions on the atom-syntax mailing list has revealed interest > in creating a new WG to look at several extensions of Atom. Here are > several extensions that have been discussed: > > 1. Hierarchy operations including meta-publishing > 2. In-line representation > 3. Bi-directional text > > Please respond to this email if you are interested in helping to explore > a new WG further. Please also identify if you have a specific interest > area to consider for a potential new Atom WG. > I am particularly interested in the in-line representation part of this. I'm currently working with a small group on an Atom extension for describing activity streams[1], and frequently we've received feedback from implementors that they want the pertinent content to be inline in the feed to avoid additional fetches. ----------------- We were in fact discussing recently the use of inlining atom:link content to refer to external resources without necessarily requiring an additional fetch. I think this model is similar to atom:source in that it provides some non-authoritative metadata that may be sufficient for display purposes while providing a mechanism for processors to retrieve the authoritative metadata when necessary. The model we were considering was as follows: tag:example.com,2009:123545 Some Related Entry ... To my mind, the model here would be that if type="application/atom+xml" then the link element MAY contain exactly one atom:entry or atom:feed element which provides a subset of the information from the target document, much as atom:source does. Other extension elements may be added as siblings of the nested atom:entry element to allow extension specifications to still add additional elements here without altering the meaning of the inlining. (the rel="related" here is arbitrary; this would ideally apply to all links of type application/atom+xml, regardless of which rel keyword is used.) [1] http://activitystrea.ms/ From owner-atom-syntax@mail.imc.org Tue Jun 9 14:12:13 2009 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 9E3BC28C20D for ; Tue, 9 Jun 2009 14:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.714 X-Spam-Level: X-Spam-Status: No, score=-4.714 tagged_above=-999 required=5 tests=[AWL=-0.713, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 yLxUEntfV9lb for ; Tue, 9 Jun 2009 14:12:07 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BA06A28C209 for ; Tue, 9 Jun 2009 14:12:06 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59KxBrv094182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 13:59:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59KxBLh094181; Tue, 9 Jun 2009 13: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 acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59Kx01n094156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 9 Jun 2009 13:59:10 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n59KtZl3027034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 9 Jun 2009 20:55:37 GMT Received: from abhmt010.oracle.com (abhmt010.oracle.com [141.146.116.19]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n59L03UC030895 for ; Tue, 9 Jun 2009 21:00:04 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Jun 2009 13:58:54 -0700 Message-Id: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> From: "Nikunj R. Mehta" To: atom-syntax Syntax Content-Type: multipart/alternative; boundary=Apple-Mail-15--14120397 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Sub-typing Atom documents Date: Tue, 9 Jun 2009 13:57:31 -0700 X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt010.oracle.com [141.146.116.19] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A09020B.4A2ECD10.020C:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-15--14120397 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Several recent discussions suggest the need for sub-typing Atom documents. There are two major requirements for sub-typing Atom documents: 1. In Atom Publishing Protocol, signaling the requirement for an Atom extension (whether blessed by IETF or not) to be present in accepted content [1]. To illustrate the requirement by example, one would see: application/atom+xml;type=entry;extension=token 2. Establishing an expectation on an Atom processor for the media type of a linked resource, e.g., whether the representation in-lines a complete hierarchy of Atom entries and feeds [2]. Once again to illustrate the requirement by example, one would see: Of these cases, a really strong case can be made for the first requirement to use a media type parameter, since it has to happen in the absence of the actual Atom document. There is only one must- understand signaling mechanism in AtomPub and that is app:accept. If a media type parameter is used in app:accept that cannot be understood by its receiver, the receiver has no choice but to cease communications with the server. Since almost every AtomPub-style "API" introduces its own set of requirements for what constitutes an entry the server is willing to accept. For example, Google Finance API in its protocol reference states that an entry posted as a new portfolio must include a "gf:portfolioData" element inside an atom:entry [3]. CMIS servers may require the presence of a type identifier as extended entry metadata in order to accept an entry posted to a collection [4]. It seems quite reasonable to establish a single media type parameter and allow every such API to define their own acceptable values for this purpose. This approach provides fair warning and enables AtomPub niches to legally exist, and even interoperate. The second case can probably benefit from a media type parameter, but it is not clear what the semantics of that parameter would be. Specifically: Do Atom processors fail if, when processing Content-Type header, they encounter a media type parameter they don't know about or a value in a known media type parameter that they don't understand. Does introduction of media type parameters for application/atom+xml require standards track RFC? Nikunj http://o-micron.blogspot.com [1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html [3] http://code.google.com/apis/finance/developers_guide_protocol.html#CreatingPortfolios [4] http://www.oasis-open.org/committees/download.php/32668 --Apple-Mail-15--14120397 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Several recent discussions = suggest the need for sub-typing Atom documents. There are two major = requirements for sub-typing Atom = documents: 1. In Atom Publishing Protocol, = signaling the requirement for an Atom extension (whether blessed by = IETF or not) to be present in accepted content [1]. To illustrate = the requirement by example, one would = see: <app:accept>application/atom+xml;type=3D= entry;extension=3Dtoken</app:accept> 2= . Establishing an expectation on an Atom processor for the media type of = a linked resource, e.g., whether the representation in-lines a complete = hierarchy of Atom entries and feeds [2]. Once again to illustrate = the requirement by example, one would = see: <atom:link rel=3D"down" = type=3D"application/atom+xml;type=3Dfeed;inline-depth=3D1" = href=3D"children"/> Of these cases, a = really strong case can be made for the first requirement to use a media = type parameter, since it has to happen in the absence of the actual Atom = document. There is only one must-understand signaling mechanism in = AtomPub and that is app:accept. If a media type parameter is used in = app:accept that cannot be understood by its receiver, the receiver has = no choice but to cease communications with the server. Since almost = every AtomPub-style "API" introduces its own set of requirements for = what constitutes an entry the server is willing to = accept. For example, Google Finance API in its = protocol reference states that an entry posted as a new portfolio must = include a "gf:portfolioData" element inside an atom:entry [3]. CMIS = servers may require the presence of a type identifier as extended entry = metadata in order to accept an entry posted to a collection = [4]. It seems quite reasonable to establish a = single media type parameter and allow every such API to define their own = acceptable values for this purpose. This approach provides fair = warning and enables AtomPub niches to legally exist, and even = interoperate. The second case can probably = benefit from a media type parameter, but it is not clear what the = semantics of that parameter would be. = Specifically: Do Atom = processors fail if, when processing Content-Type header, they encounter = a media type parameter they don't know about or a value in a known media = type parameter that they don't understand. Does introduction of = media type parameters for application/atom+xml require standards track = RFC?

Nikunj http://o-micron.blogspot.com [1] http:= //www.imc.org/atom-protocol/mail-archive/msg11398.html[2] <= a = href=3D"http://www.imc.org/atom-syntax/mail-archive/msg21114.html">http://= www.imc.org/atom-syntax/mail-archive/msg21114.html[3] http://code.google.com/apis/finance/developers_guide_= protocol.html#CreatingPortfolios [4] http://ww= w.oasis-open.org/committees/download.php/32668= --Apple-Mail-15--14120397-- From owner-atom-syntax@mail.imc.org Tue Jun 9 14:49:26 2009 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 F1DC93A68F5 for ; Tue, 9 Jun 2009 14:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=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 5m79kd-bU5lR for ; Tue, 9 Jun 2009 14:49:26 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E30133A6874 for ; Tue, 9 Jun 2009 14:49:25 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59Lcn8u096290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 14:38:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59LcnVd096289; Tue, 9 Jun 2009 14:38: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 mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59LccuY096279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Jun 2009 14:38:49 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.0.10] (localhost.localdomain [127.0.0.1]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id n59LcVIE004909; Tue, 9 Jun 2009 16:38:32 -0500 Message-ID: <4A2ED657.3060309@defuze.org> Date: Tue, 09 Jun 2009 23:38:31 +0200 From: Sylvain Hellegouarch User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Nikunj R. Mehta" CC: atom-syntax Syntax Subject: Re: Sub-typing Atom documents References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> In-Reply-To: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> 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: > There is only one must-understand signaling mechanism in AtomPub and > that is app:accept. I don't remember seeing that "must-understand", could you reference it please? > If a media type parameter is used in app:accept that cannot be > understood by its receiver, the receiver has no choice but to cease > communications with the server. What does that mean? What does "cease communication" actually mean in HTTP? > Since almost every AtomPub-style "API" introduces its own set of > requirements for what constitutes an entry the server is willing to > accept. > > For example, Google Finance API in its protocol reference states that > an entry posted as a new portfolio must include a "gf:portfolioData" > element inside an atom:entry [3]. CMIS servers may require the > presence of a type identifier as extended entry metadata in order to > accept an entry posted to a collection [4]. Yes, those are foreign elements which is accepted by the spec. I don't follow your point. > > It seems quite reasonable to establish a single media type parameter > and allow every such API to define their own acceptable values for > this purpose. This approach provides fair warning and enables AtomPub > niches to legally exist, and even interoperate. How do they interoperate if they aren't known by others? > > The second case can probably benefit from a media type parameter, but > it is not clear what the semantics of that parameter would be. > Specifically: > > 1. Do Atom processors fail if, when processing Content-Type header, > they encounter a media type parameter they don't know about or a > value in a known media type parameter that they don't understand. > Client side or server side? - Sylvain From owner-atom-syntax@mail.imc.org Tue Jun 9 14:52:28 2009 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 9A5A128C1F0 for ; Tue, 9 Jun 2009 14:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.281 X-Spam-Level: X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, URI_HEX=0.368, 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 NDAlpHUx1ePK for ; Tue, 9 Jun 2009 14:52:27 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 72B613A68F5 for ; Tue, 9 Jun 2009 14:52:27 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59Lf1PD096361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 14:41:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59Lf0wH096359; Tue, 9 Jun 2009 14:41:00 -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 mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59LexfZ096346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 14:40:59 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.0.10] (localhost.localdomain [127.0.0.1]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id n59LeukR005489; Tue, 9 Jun 2009 16:40:57 -0500 Message-ID: <4A2ED6E8.9020607@defuze.org> Date: Tue, 09 Jun 2009 23:40:56 +0200 From: Sylvain Hellegouarch User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Martin Atkins CC: atom-syntax Syntax , atom-protocol Protocol Subject: Re: Exploring a new WG around Atom References: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> <4A2EA450.2050507@degeneration.co.uk> In-Reply-To: <4A2EA450.2050507@degeneration.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Martin Atkins a écrit : > > Nikunj R. Mehta wrote: >> >> Recent discussions on the atom-syntax mailing list has revealed >> interest in creating a new WG to look at several extensions of Atom. >> Here are several extensions that have been discussed: >> >> 1. Hierarchy operations including meta-publishing >> 2. In-line representation >> 3. Bi-directional text >> >> Please respond to this email if you are interested in helping to >> explore a new WG further. Please also identify if you have a specific >> interest area to consider for a potential new Atom WG. >> > > I am particularly interested in the in-line representation part of > this. I'm currently working with a small group on an Atom extension > for describing activity streams[1], and frequently we've received > feedback from implementors that they want the pertinent content to be > inline in the feed to avoid additional fetches. > > ----------------- > > We were in fact discussing recently the use of inlining atom:link > content to refer to external resources without necessarily requiring > an additional fetch. I think this model is similar to atom:source in > that it provides some non-authoritative metadata that may be > sufficient for display purposes while providing a mechanism for > processors to retrieve the authoritative metadata when necessary. > > The model we were considering was as follows: > > > > tag:example.com,2009:123545 > Some Related Entry > ... > > > > To my mind, the model here would be that if > type="application/atom+xml" then the link element MAY contain exactly > one atom:entry or atom:feed element which provides a subset of the > information from the target document, much as atom:source does. Why not using atom:content for that? The inlining you're presenting really looks like it defeats the point of the atom:link element in the first place. - Sylvain From owner-atom-syntax@mail.imc.org Tue Jun 9 15:01:54 2009 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 8A57C3A6887 for ; Tue, 9 Jun 2009 15:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.383 X-Spam-Level: X-Spam-Status: No, score=-5.383 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 ytDUx2x+aMxK for ; Tue, 9 Jun 2009 15:01:53 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id F29E33A63EC for ; Tue, 9 Jun 2009 15:01:52 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59LoGED096844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 14:50:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59LoGcN096843; Tue, 9 Jun 2009 14:50: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 rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59Lo4av096835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 9 Jun 2009 14:50:15 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n59Lor5Q011847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Jun 2009 21:50:54 GMT Received: from abhmt007.oracle.com (abhmt007.oracle.com [141.146.116.16]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n59Lo1w6031779; Tue, 9 Jun 2009 21:50:02 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Jun 2009 14:49:55 -0700 Cc: atom-syntax Syntax Message-Id: <188A2682-3E2A-4443-8749-B58AD531C721@oracle.com> From: "Nikunj R. Mehta" To: Sylvain Hellegouarch In-Reply-To: <4A2ED657.3060309@defuze.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Sub-typing Atom documents Date: Tue, 9 Jun 2009 14:48:33 -0700 References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2ED657.3060309@defuze.org> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt007.oracle.com [141.146.116.16] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4A2ED905.0016:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 9, 2009, at 2:38 PM, Sylvain Hellegouarch wrote: > >> There is only one must-understand signaling mechanism in AtomPub =20 >> and that is app:accept. > I don't remember seeing that "must-understand", could you reference =20= > it please? =A7 8.3.4 of RFC 5023 states [[ The media range specifies a type of representation that can be POSTed to a Collection. The app:accept element is similar to the HTTP Accept request-header [RFC2616]. Media type parameters are allowed within app:accept ]] I interpret this to mean that app:accept is a kind of must-understand. =20= However, a client may still attempt to POST however unsuccessfully. Of =20= course, there is no hard "must-understand" in AtomPub. > >> If a media type parameter is used in app:accept that cannot be =20 >> understood by its receiver, the receiver has no choice but to cease =20= >> communications with the server. > > What does that mean? What does "cease communication" actually mean =20 > in HTTP? IIUC, AtomPub clients will not POST to a server entries that don't =20 conform to one of the acceptable content types for the collection, as =20= advertised in an app:collection element through app:accept. This is =20 what I meant. Of course, anything is possible in HTTP, but my =20 commentary was limited to conforming AtomPub clients. > >> Since almost every AtomPub-style "API" introduces its own set of =20 >> requirements for what constitutes an entry the server is willing to =20= >> accept. >> >> For example, Google Finance API in its protocol reference states =20 >> that an entry posted as a new portfolio must include a =20 >> "gf:portfolioData" element inside an atom:entry [3]. CMIS servers =20 >> may require the presence of a type identifier as extended entry =20 >> metadata in order to accept an entry posted to a collection [4]. > > Yes, those are foreign elements which is accepted by the spec. I =20 > don't follow your point. Point being that if you were to submit a valid Atom entry which did =20 not have the foreign markup, the server would simply decline the =20 request, even though it may advertise application/atom+xml;type=3Dentry We had a pretty detailed discussion of this topic on atom-protocol, =20 which you may wish to review [1] >> >> It seems quite reasonable to establish a single media type =20 >> parameter and allow every such API to define their own acceptable =20 >> values for this purpose. This approach provides fair warning and =20 >> enables AtomPub niches to legally exist, and even interoperate. > How do they interoperate if they aren't known by others? Can you specify "they"? Interoperation is only possible because the =20 parties to it understand the meaning of the value of a special Atom =20 media type parameter. >> >> The second case can probably benefit from a media type parameter, =20 >> but it is not clear what the semantics of that parameter would be. =20= >> Specifically: >> >> 1. Do Atom processors fail if, when processing Content-Type header, >> they encounter a media type parameter they don't know about or a >> value in a known media type parameter that they don't =20 >> understand. >> > Client side or server side? Why should it matter? This question is addressed to atom-syntax and =20 intends to question what RFC4287 calls Atom Processors. Nikunj http://o-micron.blogspot.com [1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html= From owner-atom-syntax@mail.imc.org Tue Jun 9 15:04:17 2009 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 CD9B43A6BDA for ; Tue, 9 Jun 2009 15:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, MISSING_HEADERS=1.292, URI_HEX=0.368, 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 ZvvYzjnEbyOZ for ; Tue, 9 Jun 2009 15:04:17 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BA0AC3A6887 for ; Tue, 9 Jun 2009 15:04:16 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59LrcQb097083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 14:53:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59LrcbA097082; Tue, 9 Jun 2009 14:53: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-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59LrRV1097067; Tue, 9 Jun 2009 14:53:37 -0700 (MST) (envelope-from mart@degeneration.co.uk) Received: by pzk35 with SMTP id 35so294049pzk.16 for ; Tue, 09 Jun 2009 14:53:26 -0700 (PDT) Received: by 10.142.213.5 with SMTP id l5mr294531wfg.91.1244584406149; Tue, 09 Jun 2009 14:53:26 -0700 (PDT) Received: from ?192.168.64.79? ([204.9.180.30]) by mx.google.com with ESMTPS id 32sm589974wfa.33.2009.06.09.14.53.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Jun 2009 14:53:25 -0700 (PDT) Message-ID: <4A2ED9D3.1070100@degeneration.co.uk> Date: Tue, 09 Jun 2009 14:53:23 -0700 From: Martin Atkins Reply-To: atom-syntax Syntax User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 CC: atom-syntax Syntax , atom-protocol Protocol Subject: Inlining link target content (was: Exploring a new WG around Atom) References: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> <4A2EA450.2050507@degeneration.co.uk> <4A2ED6E8.9020607@defuze.org> In-Reply-To: <4A2ED6E8.9020607@defuze.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sylvain Hellegouarch wrote: > Martin Atkins a écrit : >> >> The model we were considering was as follows: >> >> >> >> tag:example.com,2009:123545 >> Some Related Entry >> ... >> >> >> > Why not using atom:content for that? The inlining you're presenting > really looks like it defeats the point of the atom:link element in the > first place. > atom:content includes the content of the entry. In my example, atom:link points at some other entry that is related to this entry. The purpose of atom:link here is to create a relationship between one entry and another; a non-authoritative subset of the target entry is included to allow consumers to avoid dereferencing the URL given in the href attribute if it is appropriate to do so. Again, this is achieving a similar purpose to the child elements of atom:source, though in this case the href attribute of the containing link serves the purpose that a child link rel="self" does in atom:source. (As an aside, had this been in the spec originally, atom:source could in theory have been specified as: Martin's Blog ... ) (Reply-to is set to be only the atom-syntax list, since this discussion seems off-topic for atom-protocol; in retrospect, I should not have cross-posted in the first place.) From owner-atom-syntax@mail.imc.org Tue Jun 9 15:25:47 2009 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 DB9473A698B for ; Tue, 9 Jun 2009 15:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.683 X-Spam-Level: X-Spam-Status: No, score=-5.683 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 QlrVOZA3uf7q for ; Tue, 9 Jun 2009 15:25:46 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4023C3A694A for ; Tue, 9 Jun 2009 15:25:46 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59MEdmi098098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 15:14:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59MEdlr098097; Tue, 9 Jun 2009 15:14: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 rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59MESBn098090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 9 Jun 2009 15:14:38 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n59MECrR003102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 9 Jun 2009 22:14:13 GMT Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n59MFWZ6015234 for ; Tue, 9 Jun 2009 22:15:32 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Jun 2009 15:14:23 -0700 Message-Id: <70599A4A-7B1E-48BB-98B4-79A879D914C6@oracle.com> From: "Nikunj R. Mehta" To: atom-syntax Syntax In-Reply-To: <4A2ED9D3.1070100@degeneration.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Inlining link target content (was: Exploring a new WG around Atom) Date: Tue, 9 Jun 2009 15:13:01 -0700 References: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> <4A2EA450.2050507@degeneration.co.uk> <4A2ED6E8.9020607@defuze.org> <4A2ED9D3.1070100@degeneration.co.uk> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt001.oracle.com [141.146.116.10] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4A2EDEC0.0111:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 9, 2009, at 2:53 PM, Martin Atkins wrote: > (As an aside, had this been in the spec originally, atom:source > could in > theory have been specified as: > > > Martin's Blog > ... > > > ) This is similar to the realization that and along with @style and @class could do a lot of things that required a dozen or more pieces of markup in HTML. From owner-atom-syntax@mail.imc.org Tue Jun 9 15:36:13 2009 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 163F43A699D for ; Tue, 9 Jun 2009 15:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=-0.953, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=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 CSy0diNrKHO9 for ; Tue, 9 Jun 2009 15:36:12 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B4B9D3A6856 for ; Tue, 9 Jun 2009 15:36:11 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59MOiDv098529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 15:24:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59MOiro098528; Tue, 9 Jun 2009 15:24: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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59MOXlG098474 for ; Tue, 9 Jun 2009 15:24:44 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qw-out-1920.google.com with SMTP id 14so308424qwa.28 for ; Tue, 09 Jun 2009 15:24:32 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=JCoXHlH5ehjkPCrpaotMStfdxgneXkncz/w9vncd1W0=; b=a0bWbYXMQsypqMuWDDBHmtxTBrXCVfFmHlN6s32/OFEIRXdfWgfnyeUYR/rVxIRCVn ZyBafmWANS4YCeOmDMbJuYisFTCJYCUOasZoIe3QerbR9HwupEmMCgoV32gJ3+drbQgZ 7pny15cIOTg6fINsK9VITbNDWAYaW20UAXyss= 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:content-type:content-transfer-encoding; b=Zcw4uohnBK8AdgniBqatKCyV8/lUdxci8DwSBWXaKq65JjnzJXU8tzGFgZIbDZ3E1I Dqqa20uPZ91m9hcKv55Urkd35donVVROuVZiryk05yLa+bSrLO13EF7YQswi6qGTQm9J Zd9w//krmN5WgDl0yx8Ix9P5Hcmn4ouWXvBWY= Received: by 10.224.60.140 with SMTP id p12mr801787qah.108.1244586272803; Tue, 09 Jun 2009 15:24:32 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 8sm340613qwj.14.2009.06.09.15.24.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Jun 2009 15:24:32 -0700 (PDT) Message-ID: <4A2EE11F.2080809@gmail.com> Date: Tue, 09 Jun 2009 15:24:31 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Nikunj R. Mehta" CC: atom-syntax Syntax Subject: Re: Sub-typing Atom documents References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> In-Reply-To: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> 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: I've already started working up an I-D for a new profile media type parameter. I should be able to get it published by tomorrow end-of-day Example: application/atom+xml;profile="http://example.org/profile/foo" The profile parameter value is a URI that identifies a logical profile to which the Atom document conforms. Only a single profile value is allowed for now. - James Nikunj R. Mehta wrote: > Several recent discussions suggest the need for sub-typing Atom > documents. There are two major requirements for sub-typing Atom documents: > > 1. In Atom Publishing Protocol, signaling the requirement for an Atom > extension (whether blessed by IETF or not) to be present in accepted > content [1]. To illustrate the requirement by example, one would see: > > application/atom+xml;type=entry;extension=token > > 2. Establishing an expectation on an Atom processor for the media type > of a linked resource, e.g., whether the representation in-lines a > complete hierarchy of Atom entries and feeds [2]. Once again to > illustrate the requirement by example, one would see: > > type="application/atom+xml;type=feed;inline-depth=1" href="children"/> > > Of these cases, a really strong case can be made for the first > requirement to use a media type parameter, since it has to happen in > the absence of the actual Atom document. There is only one > must-understand signaling mechanism in AtomPub and that is app:accept. > If a media type parameter is used in app:accept that cannot be > understood by its receiver, the receiver has no choice but to cease > communications with the server. Since almost every AtomPub-style "API" > introduces its own set of requirements for what constitutes an entry > the server is willing to accept. > > For example, Google Finance API in its protocol reference states that > an entry posted as a new portfolio must include a "gf:portfolioData" > element inside an atom:entry [3]. CMIS servers may require the > presence of a type identifier as extended entry metadata in order to > accept an entry posted to a collection [4]. > > It seems quite reasonable to establish a single media type parameter > and allow every such API to define their own acceptable values for > this purpose. This approach provides fair warning and enables AtomPub > niches to legally exist, and even interoperate. > > The second case can probably benefit from a media type parameter, but > it is not clear what the semantics of that parameter would be. > Specifically: > > 1. Do Atom processors fail if, when processing Content-Type header, > they encounter a media type parameter they don't know about or a > value in a known media type parameter that they don't understand. > 2. Does introduction of media type parameters for > application/atom+xml require standards track RFC? > > > Nikunj > http://o-micron.blogspot.com > > [1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html > [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html > [3] http://code.google.com/apis/finance/developers_guide_protocol.html#CreatingPortfolios > [4] http://www.oasis-open.org/committees/download.php/32668 From owner-atom-syntax@mail.imc.org Tue Jun 9 15:53:30 2009 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 2194C3A6B3C for ; Tue, 9 Jun 2009 15:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_47=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 DSeTQFPnuwqx for ; Tue, 9 Jun 2009 15:53:29 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 15F033A6912 for ; Tue, 9 Jun 2009 15:53:28 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59MgMUp099503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 15:42:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59MgMqZ099502; Tue, 9 Jun 2009 15:42: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 mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59MgAii099452 for ; Tue, 9 Jun 2009 15:42:21 -0700 (MST) (envelope-from peter.krantz@gmail.com) Received: by fxm25 with SMTP id 25so366225fxm.10 for ; Tue, 09 Jun 2009 15:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=XyQBw3k8DR2Q9grMQAC0GMYVwWE3PzSKxrkJPxVRp2Y=; b=A7qVpvy3KLFUFrx4Bp/nUYyHQVwV6GFKwU2N24P8AyD1RUTZNKdmfkgFRpoqxRRYKJ /7zWJnxNja6XxQ/8nNMiRw0VnQjVocNttm7I+Bh9DjNgEV0oNeIdc2B0xDD0QXAHIsCp 0F5xoVfmgg91sci0z4THWa9E50YMrZIYYS7hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=vldGh2E7TxipMd/TSz16vuVn4X/PHZVgWIHgIe+Eoz6Uuhu7pOk7FWOWEzJ4tcnTE7 f2smzDCN715wAYaAD81McavRc/MmhyTO8UYkGM7gZOqYk0O0rYki9x5ZSzjD+EGw6L2c 4nWjmg8OuzHND6yOa0kDfRGgT832n8ZHNYXLo= MIME-Version: 1.0 Received: by 10.103.242.14 with SMTP id u14mr416849mur.106.1244587329487; Tue, 09 Jun 2009 15:42:09 -0700 (PDT) Date: Wed, 10 Jun 2009 00:42:09 +0200 Message-ID: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> Subject: Tools not supporting atom:content with @src ? From: Peter Krantz To: atom-syntax@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi! We are using Atom to get notifications about PDF documents added to collections at various government agencies. This works well since we are consuming the feeds programatically. A typical entry looks like this (please note the atom:content element): tag:example.com,2009:1 2009-05-13T18:30:02Z 2009-05-13T18:30:02Z A title A summary It would be nice if the same feeds could be used in popular feedreaders too. I have tried feeds with entries like the one above in IE8, Firefox 3.5b4, Google Reader and Safari 4 but none of them make it possible to access the PDF specified in the atom:content element. Is this a misunderstanding on my part or is it just a rare enough example that hasn't been implemented in client software? Regards, Peter Krantz From owner-atom-syntax@mail.imc.org Tue Jun 9 16:00:08 2009 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 D4E023A6912 for ; Tue, 9 Jun 2009 16:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 tnEGk3kuUjpw for ; Tue, 9 Jun 2009 16:00:07 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5BF3E3A67DF for ; Tue, 9 Jun 2009 16:00:07 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59MRMjT098690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 15:27:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59MRMJt098689; Tue, 9 Jun 2009 15:27: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 rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59MRLZU098683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 9 Jun 2009 15:27:21 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n59MSD1f008747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Jun 2009 22:28:14 GMT Received: from abhmt006.oracle.com (abhmt006.oracle.com [141.146.116.15]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n59MSO9N003375; Tue, 9 Jun 2009 22:28:25 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Jun 2009 15:27:16 -0700 Cc: atom-syntax Syntax Message-Id: <7E46D2FD-39A3-4D6C-A273-10CDB56508B2@oracle.com> From: "Nikunj R. Mehta" To: James M Snell In-Reply-To: <4A2EE11F.2080809@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Sub-typing Atom documents Date: Tue, 9 Jun 2009 15:25:53 -0700 References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2EE11F.2080809@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt006.oracle.com [141.146.116.15] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010208.4A2EE1C5.0024:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It would help if you can clarify which of these two requirements you wish to address by introducing a new media type parameter and its consequences. In short, we would benefit if the I-D addresses my questions below. Nikunj http://o-micron.blogspot.com On Jun 9, 2009, at 3:24 PM, James M Snell wrote: > I've already started working up an I-D for a new profile media type > parameter. I should be able to get it published by tomorrow end-of-day > > Example: > > application/atom+xml;profile="http://example.org/profile/foo" > > The profile parameter value is a URI that identifies a logical > profile to which the Atom document conforms. Only a single profile > value is allowed for now. > > - James > > Nikunj R. Mehta wrote: >> Several recent discussions suggest the need for sub-typing Atom >> documents. There are two major requirements for sub-typing Atom >> documents: >> >> 1. In Atom Publishing Protocol, signaling the requirement for an >> Atom extension (whether blessed by IETF or not) to be present in >> accepted content [1]. To illustrate the requirement by example, one >> would see: >> >> application/atom+xml;type=entry;extension=token> app:accept> >> >> 2. Establishing an expectation on an Atom processor for the media >> type of a linked resource, e.g., whether the representation in- >> lines a complete hierarchy of Atom entries and feeds [2]. Once >> again to illustrate the requirement by example, one would see: >> >> >> >> Of these cases, a really strong case can be made for the first >> requirement to use a media type parameter, since it has to happen >> in the absence of the actual Atom document. There is only one must- >> understand signaling mechanism in AtomPub and that is app:accept. >> If a media type parameter is used in app:accept that cannot be >> understood by its receiver, the receiver has no choice but to cease >> communications with the server. Since almost every AtomPub-style >> "API" introduces its own set of requirements for what constitutes >> an entry the server is willing to accept. >> >> For example, Google Finance API in its protocol reference states >> that an entry posted as a new portfolio must include a >> "gf:portfolioData" element inside an atom:entry [3]. CMIS servers >> may require the presence of a type identifier as extended entry >> metadata in order to accept an entry posted to a collection [4]. >> >> It seems quite reasonable to establish a single media type >> parameter and allow every such API to define their own acceptable >> values for this purpose. This approach provides fair warning and >> enables AtomPub niches to legally exist, and even interoperate. >> >> The second case can probably benefit from a media type parameter, >> but it is not clear what the semantics of that parameter would be. >> Specifically: >> >> 1. Do Atom processors fail if, when processing Content-Type header, >> they encounter a media type parameter they don't know about or a >> value in a known media type parameter that they don't >> understand. >> 2. Does introduction of media type parameters for >> application/atom+xml require standards track RFC? >> >> >> Nikunj >> http://o-micron.blogspot.com >> >> [1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html >> [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html >> [3] http://code.google.com/apis/finance/developers_guide_protocol.html#CreatingPortfolios >> [4] http://www.oasis-open.org/committees/download.php/32668 From owner-atom-syntax@mail.imc.org Tue Jun 9 16:05:35 2009 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 5FE043A67DF for ; Tue, 9 Jun 2009 16:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlHjJzrIG-+B for ; Tue, 9 Jun 2009 16:05:34 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4E9FD3A6781 for ; Tue, 9 Jun 2009 16:05:34 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59MsFxC099968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 15:54:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59MsFuD099967; Tue, 9 Jun 2009 15:54: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 smtp.ischool.berkeley.edu (bliss.ISchool.Berkeley.EDU [128.32.78.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59Ms4qr099955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Jun 2009 15:54:15 -0700 (MST) (envelope-from dret@berkeley.edu) Received: from [128.32.226.188] (dhcp188.ISchool.Berkeley.EDU [128.32.226.188]) (authenticated bits=0) by smtp.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id n59Ms4xW021423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 9 Jun 2009 15:54:04 -0700 Message-ID: <4A2EE80A.1090007@berkeley.edu> Date: Tue, 09 Jun 2009 15:54:02 -0700 From: Erik Wilde User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Tools not supporting atom:content with @src ? References: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> In-Reply-To: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 128.32.78.13 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hello peter. Peter Krantz wrote: > Is this a misunderstanding on my part or is it just a rare enough > example that hasn't been implemented in client software? i guess your example is perfectly ok, but none of the major feed readers really excel at implementing every possible combination of atom elements and features. for exmaple, another thing that bothers me in the browser implementations is that in firefox, if there is a summary, you will not see the content at all, which is pretty annoying. in safari, if there is summary and content, you won't see the summary... generally speaking, making assumptions about how exactly feed readers are going to display something is kind of risky, so the safe thing to do would be to have a short content with HTML linking to the PDF for humans, and to also have an entry/link pointing to the PDF as a rel="alternate" representation. i think this is the way that is most likely to work in feed readers. cheers, dret. From owner-atom-syntax@mail.imc.org Tue Jun 9 17:03:12 2009 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 D9A4E28C168 for ; Tue, 9 Jun 2009 17:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 1pjZM9mTdkoa for ; Tue, 9 Jun 2009 17:03:06 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 670C728C104 for ; Tue, 9 Jun 2009 17:03:06 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59NoVbi002596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 16:50:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59NoVMr002594; Tue, 9 Jun 2009 16:50:31 -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 acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59NoTQ0002587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 9 Jun 2009 16:50:30 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n59Nl1rq009424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Jun 2009 23:47:03 GMT Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n59NoUVX021958; Tue, 9 Jun 2009 23:50:30 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Jun 2009 16:50:24 -0700 Cc: atom-syntax Syntax Message-Id: <0A962BD4-72FB-4953-A0A3-8035362E2B7F@oracle.com> From: "Nikunj R. Mehta" To: James M Snell In-Reply-To: <4A2EE11F.2080809@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Sub-typing Atom documents Date: Tue, 9 Jun 2009 16:49:01 -0700 References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2EE11F.2080809@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt001.oracle.com [141.146.116.10] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A01020A.4A2EF541.0084:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 9, 2009, at 3:24 PM, James M Snell wrote: > > I've already started working up an I-D for a new profile media type > parameter. I should be able to get it published by tomorrow end-of-day > > Example: > > application/atom+xml;profile="http://example.org/profile/foo" > > The profile parameter value is a URI that identifies a logical > profile to which the Atom document conforms. Only a single profile > value is allowed for now. > A single profile value could be a problem since it doesn't allow mixin whereas Atom's extensibility model does. > - James > > Nikunj R. Mehta wrote: >> Several recent discussions suggest the need for sub-typing Atom >> documents. There are two major requirements for sub-typing Atom >> documents: >> >> 1. In Atom Publishing Protocol, signaling the requirement for an >> Atom extension (whether blessed by IETF or not) to be present in >> accepted content [1]. To illustrate the requirement by example, one >> would see: >> >> application/atom+xml;type=entry;extension=token> app:accept> >> >> 2. Establishing an expectation on an Atom processor for the media >> type of a linked resource, e.g., whether the representation in- >> lines a complete hierarchy of Atom entries and feeds [2]. Once >> again to illustrate the requirement by example, one would see: >> >> >> >> Of these cases, a really strong case can be made for the first >> requirement to use a media type parameter, since it has to happen >> in the absence of the actual Atom document. There is only one must- >> understand signaling mechanism in AtomPub and that is app:accept. >> If a media type parameter is used in app:accept that cannot be >> understood by its receiver, the receiver has no choice but to cease >> communications with the server. Since almost every AtomPub-style >> "API" introduces its own set of requirements for what constitutes >> an entry the server is willing to accept. >> >> For example, Google Finance API in its protocol reference states >> that an entry posted as a new portfolio must include a >> "gf:portfolioData" element inside an atom:entry [3]. CMIS servers >> may require the presence of a type identifier as extended entry >> metadata in order to accept an entry posted to a collection [4]. >> >> It seems quite reasonable to establish a single media type >> parameter and allow every such API to define their own acceptable >> values for this purpose. This approach provides fair warning and >> enables AtomPub niches to legally exist, and even interoperate. >> >> The second case can probably benefit from a media type parameter, >> but it is not clear what the semantics of that parameter would be. >> Specifically: >> >> 1. Do Atom processors fail if, when processing Content-Type header, >> they encounter a media type parameter they don't know about or a >> value in a known media type parameter that they don't >> understand. >> 2. Does introduction of media type parameters for >> application/atom+xml require standards track RFC? >> >> >> Nikunj >> http://o-micron.blogspot.com >> >> [1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html >> [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html >> [3] http://code.google.com/apis/finance/developers_guide_protocol.html#CreatingPortfolios >> [4] http://www.oasis-open.org/committees/download.php/32668 > From owner-atom-syntax@mail.imc.org Tue Jun 9 17:51:17 2009 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 4DCC13A6B40 for ; Tue, 9 Jun 2009 17:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.568 X-Spam-Level: X-Spam-Status: No, score=-0.568 tagged_above=-999 required=5 tests=[AWL=1.430, BAYES_00=-2.599, J_CHICKENPOX_47=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 rJQqR+DtcMvE for ; Tue, 9 Jun 2009 17:51:16 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3900A3A6AF9 for ; Tue, 9 Jun 2009 17:51:16 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5A0dVwZ005133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 17:39:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5A0dVbU005132; Tue, 9 Jun 2009 17:39:31 -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-px0-f188.google.com (mail-px0-f188.google.com [209.85.216.188]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5A0dKtL005119 for ; Tue, 9 Jun 2009 17:39:31 -0700 (MST) (envelope-from mart@degeneration.co.uk) Received: by pxi26 with SMTP id 26so355257pxi.16 for ; Tue, 09 Jun 2009 17:39:20 -0700 (PDT) Received: by 10.142.194.1 with SMTP id r1mr299650wff.122.1244594360396; Tue, 09 Jun 2009 17:39:20 -0700 (PDT) Received: from ?192.168.64.79? ([204.9.180.30]) by mx.google.com with ESMTPS id 32sm1122113wfa.33.2009.06.09.17.39.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Jun 2009 17:39:19 -0700 (PDT) Message-ID: <4A2F00B6.7020504@degeneration.co.uk> Date: Tue, 09 Jun 2009 17:39:18 -0700 From: Martin Atkins User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Tools not supporting atom:content with @src ? References: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> In-Reply-To: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> 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: Peter Krantz wrote: > > > tag:example.com,2009:1 > 2009-05-13T18:30:02Z > 2009-05-13T18:30:02Z > A title > A summary > > > > It would be nice if the same feeds could be used in popular > feedreaders too. I have tried feeds with entries like the one above in > IE8, Firefox 3.5b4, Google Reader and Safari 4 but none of them make > it possible to access the PDF specified in the atom:content element. > > Is this a misunderstanding on my part or is it just a rare enough > example that hasn't been implemented in client software? > I believe that this is valid, but in practice your average feed reader only implements the featureset of RSS, ignoring the more esoteric features of Atom. This is often because the parsing code started off as an RSS parser and had Atom bolted on, so there was no room in the API for some of Atom's unique features. In practice, you're probably better off with something like the following: tag:example.com,2009:1 2009-05-13T18:30:02Z 2009-05-13T18:30:02Z A title A summary <a href="/docs/example.pdf">Download PDF</a> The link in the content will provide an access method for the most basic clients and the enclosure may provide additional functionality such as automatic download for clients with support for enclosures. From owner-atom-syntax@mail.imc.org Tue Jun 9 18:03:36 2009 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 95A073A698F for ; Tue, 9 Jun 2009 18:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnWvJdH2g+ke for ; Tue, 9 Jun 2009 18:03:35 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 74F5D3A6A15 for ; Tue, 9 Jun 2009 18:03:35 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5A0op3p005650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 17:50:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5A0opXv005649; Tue, 9 Jun 2009 17:50: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 smtp.ischool.berkeley.edu (bliss.ISchool.Berkeley.EDU [128.32.78.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5A0oo5A005643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Jun 2009 17:50:51 -0700 (MST) (envelope-from dret@berkeley.edu) Received: from [128.32.226.188] (dhcp188.ISchool.Berkeley.EDU [128.32.226.188]) (authenticated bits=0) by smtp.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id n5A0oovT002680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 9 Jun 2009 17:50:50 -0700 Message-ID: <4A2F0368.7060309@berkeley.edu> Date: Tue, 09 Jun 2009 17:50:48 -0700 From: Erik Wilde User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Tools not supporting atom:content with @src ? References: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> <4A2F00B6.7020504@degeneration.co.uk> In-Reply-To: <4A2F00B6.7020504@degeneration.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 128.32.78.13 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hello martin and peter. Martin Atkins wrote: > Peter Krantz wrote: >> >> >> >> Is this a misunderstanding on my part or is it just a rare enough >> example that hasn't been implemented in client software? > > href="/docs/example.pdf" > type="application/pdf" /> > > The link in the content will provide an access method for the most basic > clients and the enclosure may provide additional functionality such as > automatic download for clients with support for enclosures. now that you say it, it may be the case than "enclosure" is the better way to go in this case. however, "enclosure" (i think) implies that the enclosure *is* the actual content. "alternate" says (i think) that the linked resource is an alternate version. and since you're publishing PDF, which is not the pinnacle of accessibility anyway, you might consider publishing all or some of the contents in HTML, in which case "alternate" might become more appropriate. this is what we did in our example for the stimulus feeds (which are currently distributed as excel files): we suggested to publish them as XML; and to make it even easier for humans to understand what's going on, we also publish them as HTML in the feed, and link to the XML from the feed via entry/link *and* from the embedded HTML. here is an example: http://isd.ischool.berkeley.edu/stimulus/feeds/weekly-site.atom it was my understanding that "alternate" would be the more appropriate relationship in this case, because the HTML and the XML are essentially the same, but the definitions of the relationships in atom leave some room for interpretation, i suppose. cheers, dret. From owner-atom-syntax@mail.imc.org Wed Jun 10 00:53:13 2009 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 666413A6AAD for ; Wed, 10 Jun 2009 00:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 e9Ow3Gxh8HRy for ; Wed, 10 Jun 2009 00:53:12 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 6EE683A6AA7 for ; Wed, 10 Jun 2009 00:53:11 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5A7e9Os025287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 00:40:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5A7e9Be025286; Wed, 10 Jun 2009 00:40: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 mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5A7dvVb025266 for ; Wed, 10 Jun 2009 00:40:09 -0700 (MST) (envelope-from peter.krantz@gmail.com) Received: by fxm25 with SMTP id 25so532681fxm.10 for ; Wed, 10 Jun 2009 00:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cIihhkNqz9V287+anmEwdH/wu5gMjuktYw3SBLyNFvU=; b=eNqyuhKr03azERh/TTIUp3f/EmN5PMLES8sm5InU0PkZG6KylREAWZpYR4gL99a4XH /mi5IkOAypSNTOa1YmXaQ+t105whozcOAj9XDoTghrYgxnVDKNDqRJ53oeX1E2PLSRtw GSfTYFcsN0ma6jlUL1xOT0oTVNLU0oNvxg4Qk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IZNaUo5vCknYx/KrC2z98WZnguvbnA0bS/25cZwEmWKAgPCG81qf5+x9eaPcKuy5+k RQB1CLci4H7462rdxZZ3JFWPJZYq7xopBVOMWxV9E/6mrtxRX5rLzFTqn3IH3x4C7nEy ksg0IVDXKEaCE3LQOMOJJNzBhGhA1UINEMayA= MIME-Version: 1.0 Received: by 10.103.242.14 with SMTP id u14mr588471mur.106.1244619597209; Wed, 10 Jun 2009 00:39:57 -0700 (PDT) In-Reply-To: <4A2F00B6.7020504@degeneration.co.uk> References: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> <4A2F00B6.7020504@degeneration.co.uk> Date: Wed, 10 Jun 2009 09:39:57 +0200 Message-ID: <7b9ad66d0906100039y65db0273l5f060744fa373dbe@mail.gmail.com> Subject: Re: Tools not supporting atom:content with @src ? From: Peter Krantz To: Martin Atkins Cc: atom-syntax@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jun 10, 2009 at 02:39, Martin Atkins wrot= e: > > [...] > =A0 =A0 > =A0 =A0 =A0 =A0<a href=3D"/docs/example.pdf">Download PDF</a> > =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0href=3D"/docs/example.pdf" > =A0 =A0 =A0 =A0 =A0type=3D"application/pdf" /> > But this implies that the actual content is " 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 254BA28C157 for ; Wed, 10 Jun 2009 10:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 jwNsBq98nksy for ; Wed, 10 Jun 2009 10:09:45 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 87B7028C239 for ; Wed, 10 Jun 2009 10:09:44 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AGvDSP054636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 09:57:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AGvDdL054635; Wed, 10 Jun 2009 09:57:13 -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 rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AGv3YZ054617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 09:57:13 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AGvuvd008494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 10 Jun 2009 16:57:57 GMT Received: from abhmt009.oracle.com (abhmt009.oracle.com [141.146.116.18]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AGv49g024485 for ; Wed, 10 Jun 2009 16:57:04 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Jun 2009 09:56:58 -0700 Message-Id: <6B1A1BB7-5698-4852-8DE6-F2A06691624B@oracle.com> From: "Nikunj R. Mehta" To: atom-syntax Syntax Content-Type: multipart/alternative; boundary=Apple-Mail-35-57765405 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Fwd: New Version Notification for draft-mehta-atom-inline-00 Date: Wed, 10 Jun 2009 09:55:37 -0700 References: <20090609233744.9A64B3A6A48@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt009.oracle.com [141.146.116.18] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010208.4A2FE5DB.016C:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-35-57765405 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Based on feedback, I have split out the in-lining spec in to its own I- D. HTML: http://tools.ietf.org/html/draft-mehta-atom-inline-00 Text: http://tools.ietf.org/id/draft-mehta-atom-inline-00.txt I am also tracking open issues about this I-D publicly at http://code.google.com/p/atom-ext/issues/list . The source for this I-D is also available, if you are interested. Looking forward to comments on the I-D. Nikunj http://o-micron.blogspot.com Begin forwarded message: > From: IETF I-D Submission Tool > Date: June 9, 2009 4:37:44 PM PDT > To: nikunj.mehta@oracle.com > Subject: New Version Notification for draft-mehta-atom-inline-00 > > > A new version of I-D, draft-mehta-atom-inline-00.txt has been > successfuly submitted by Nikunj Mehta and posted to the IETF > repository. > > Filename: draft-mehta-atom-inline > Revision: 00 > Title: In-lining Extensions for Atom > Creation_date: 2009-06-09 > WG ID: Independent Submission > Number_of_pages: 9 > > Abstract: > This specification defines mechanisms for in-lining representations > of linked resources in Atom documents.Editorial Note > > To provide feedback on this Internet-Draft, join the atom-syntax > mailing list (http://www.imc.org/atom-syntax/) [1]. > > > > The IETF Secretariat. > > --Apple-Mail-35-57765405 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Based on feedback, I have split = out the in-lining spec in to its own = I-D. HTML: http://tool= s.ietf.org/html/draft-mehta-atom-inline-00 Text: http://to= ols.ietf.org/id/draft-mehta-atom-inline-00.txt I = am also tracking open issues about this = ;I-D publicly at http://code.google.= com/p/atom-ext/issues/list. The source for this I-D is also = available, if you are interested.

Looking = forward to comments on the I-D. Nikunj http://o-micron.blogspot.com Begin forwarded message: From: = IETF I-D Submission Tool <idsubmission@ietf.org>= Date: June 9, 2009 4:37:44 PM = PDT To: nikunj.mehta@oracle.com= Subject: New Version Notification for = draft-mehta-atom-inline-00 A new = version of I-D, draft-mehta-atom-inline-00.txt has been successfuly = submitted by Nikunj Mehta and posted to the IETF = repository. Filename: = draft-mehta-atom-inline Revision: 00 Title: = In-lining Extensions for Atom Creation_date: = 2009-06-09 WG ID: Independent = Submission Number_of_pages: 9 Abstract: This specification = defines mechanisms for in-lining representations of linked resources = in Atom documents.Editorial Note To provide feedback on this = Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1]. The IETF = Secretariat. = --Apple-Mail-35-57765405-- From owner-atom-syntax@mail.imc.org Wed Jun 10 10:11:11 2009 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 E8BE628C239 for ; Wed, 10 Jun 2009 10:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.016 X-Spam-Level: X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 gQBna7LpH-Vh for ; Wed, 10 Jun 2009 10:11:10 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 211B228C157 for ; Wed, 10 Jun 2009 10:11:09 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AGxrZh054735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 09:59:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AGxrsK054734; Wed, 10 Jun 2009 09:59: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 rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AGxg6E054720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 09:59:52 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AGxPe7032592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 10 Jun 2009 16:59:27 GMT Received: from abhmt009.oracle.com (abhmt009.oracle.com [141.146.116.18]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AH0l41014566 for ; Wed, 10 Jun 2009 17:00:47 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Jun 2009 09:59:37 -0700 Message-Id: <7D3F8024-3112-4D6B-B0C8-79A7654CB7B7@oracle.com> From: "Nikunj R. Mehta" To: atom-syntax Syntax Content-Type: multipart/alternative; boundary=Apple-Mail-36-57923754 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Fwd: New Version Notification for draft-divilly-atom-hierarchy-02 Date: Wed, 10 Jun 2009 09:58:15 -0700 References: <20090610003357.59F6B3A6916@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt009.oracle.com [141.146.116.18] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4A2FE67A.0027:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-36-57923754 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Based on feedback, I have simplified the I-D to: In-line extensions moved to draft-mehta-atom-inline Removed down-tree and up-tree relations Removed cardinality restrictions on up and down links HTML: http://tools.ietf.org/html/draft-divilly-atom-hierarchy-02 Text: http://tools.ietf.org/id/draft-divilly-atom-hierarchy-02.txt Diff: http://tools.ietf.org/rfcdiff?url2=draft-divilly-atom-hierarchy-02.txt I am also tracking open issues about this I-D publicly at http://code.google.com/p/atom-ext/issues/list . The source for this I-D is also available, if you are interested. Looking forward to comments on the I-D. Nikunj http://o-micron.blogspot.com Begin forwarded message: > From: IETF I-D Submission Tool > Date: June 9, 2009 5:33:57 PM PDT > To: nikunj.mehta@oracle.com > Cc: colm.divilly@oracle.com > Subject: New Version Notification for draft-divilly-atom-hierarchy-02 > > > A new version of I-D, draft-divilly-atom-hierarchy-02.txt has been > successfuly submitted by Nikunj Mehta and posted to the IETF > repository. > > Filename: draft-divilly-atom-hierarchy > Revision: 02 > Title: Hierarchy Relations for Atom > Creation_date: 2009-06-09 > WG ID: Independent Submission > Number_of_pages: 7 > > Abstract: > This specification defines link relations for hierarchical navigation > among Atom feeds and entries.Editorial Note > > To provide feedback on this Internet-Draft, join the atom-syntax > mailing list (http://www.imc.org/atom-syntax/) [1]. > > > > The IETF Secretariat. > > --Apple-Mail-36-57923754 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Based on = feedback, I have simplified the I-D to:

In-line = extensions moved to draft-mehta-atom-inline = Removed down-tree and up-tree = relations Removed cardinality = restrictions on up and down links HTML: http:/= /tools.ietf.org/html/draft-divilly-atom-hierarchy-02 T= ext: http://to= ols.ietf.org/id/draft-divilly-atom-hierarchy-02.txt Diff:&nb= sp;http://tools.ietf.org/rfcdiff?url2=3Ddraft-divilly-atom-hierarchy-= 02.txt I = am also tracking open issues about this = ;I-D publicly at http://code.google.= com/p/atom-ext/issues/list. The source for this I-D is also = available, if you are interested.

Looking = forward to comments on the I-D. Nikunj http://o-micron.blogspot.com Begin forwarded message: From: = IETF I-D Submission Tool <idsubmission@ietf.org>= Date: June 9, 2009 5:33:57 PM = PDT To: nikunj.mehta@oracle.com= Cc: colm.divilly@oracle.com= Subject: New Version Notification for = draft-divilly-atom-hierarchy-02 A new = version of I-D, draft-divilly-atom-hierarchy-02.txt has been successfuly = submitted by Nikunj Mehta and posted to the IETF = repository. Filename: = draft-divilly-atom-hierarchy Revision: 02 Title: = Hierarchy Relations for Atom Creation_date: = 2009-06-09 WG ID: Independent = Submission Number_of_pages: 7 Abstract: This specification = defines link relations for hierarchical navigation among Atom feeds = and entries.Editorial Note To provide feedback on this = Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1]. The IETF = Secretariat. = --Apple-Mail-36-57923754-- From owner-atom-syntax@mail.imc.org Wed Jun 10 10:44:08 2009 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 94AD03A6A49 for ; Wed, 10 Jun 2009 10:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0U1HKbMUq9i for ; Wed, 10 Jun 2009 10:44:03 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id F2AFC3A6B61 for ; Wed, 10 Jun 2009 10:44:02 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AHXUHT056699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 10:33:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AHXUeT056698; Wed, 10 Jun 2009 10:33: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 acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AHXJsh056688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 10:33:30 -0700 (MST) (envelope-from colm.divilly@oracle.com) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AHY9aZ014508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 10 Jun 2009 17:34:10 GMT Received: from abhmt005.oracle.com (abhmt005.oracle.com [141.146.116.14]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AHXLJU010088 for ; Wed, 10 Jun 2009 17:33:21 GMT Received: from [10.169.115.231] (/10.169.115.231) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Jun 2009 10:33:15 -0700 Message-ID: <4A2FEE63.5010009@oracle.com> Date: Wed, 10 Jun 2009 18:33:23 +0100 From: Colm Divilly Organization: Oracle Corporation User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Linking Atom Entries to 'Category Feeds' Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: abhmt005.oracle.com [141.146.116.14] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4A2FEE5B.02F3:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm trying to design a mechanism for annotating an Atom Entry with links to 'category feeds' (a feed that lists all other entries having the same category term), one link per element included in the entry. I can think of two ways to do this: 1. ... ... 2. ... ... The goal is to enable clients to navigate the 'category space' discovering entries that are similarly categorized. I see Option 1. as more likely to be broadly understood, e.g. a generic feed reader would be able to understand and make available the 'related' link to the user, but I find it lacking because it does not directly relate the link to the category to which it applies. Therefore I favour Option 2. but I expect that not to be understood by anything other than my own application client. I'm guessing others have tried modeling something similar, anyone have any thoughts on the above proposals, or alternative approaches? Regards, Colm Divilly From mimicmk21@renzl.com Wed Jun 10 10:46:30 2009 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 7FFEF3A6A1F; Wed, 10 Jun 2009 10:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_52=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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_URI_LET_DIG_PIC=1.157, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, 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 ebNa2E64X2pl; Wed, 10 Jun 2009 10:46:29 -0700 (PDT) Received: from 201.86.251.238.dynamic.adsl.gvt.net.br (201.86.251.238.dynamic.adsl.gvt.net.br [201.86.251.238]) by core3.amsl.com (Postfix) with ESMTP id 997873A67EB; Wed, 10 Jun 2009 10:46:24 -0700 (PDT) Message-ID: <000d01c9e9f3$52784bf0$6400a8c0@mimicmk21> From: atompub-archive@megatron.ietf.org To: Subject: tip top good looks will attract positive attention, try it free Date: Wed, 10 Jun 2009 14:46:02 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9E9F3.52784BF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9E9F3.52784BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 Having problems viewing=20 this email? Click=20 here. =20 =20 =20 =20 =20 =20 =20 =20 =20 =A0 =20 =20 =20 =20 =20 Know=20 someone else? Forward This=20 Email!We hope you enjoy receiving emails=20 from Kuxqnyza. If you do not wish to receive them, please= click=20 here.Copyright ¿2000-2009 Ilql, Inc.=20 Jrisjnj, Inc. 8309 Helyf Avenue, WK 95443Privacy=20 Policy=A0=A0|=A0=A0Terms of=20 Use=A0=A0|=A0=A0Customer=20 Service=A0=A0|=A0=A0Site=20 Map =A0 =A0 ------=_NextPart_000_0007_01C9E9F3.52784BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =A0 ------=_NextPart_000_0007_01C9E9F3.52784BF0-- From owner-atom-syntax@mail.imc.org Wed Jun 10 10:54:26 2009 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 2B8E33A68B9 for ; Wed, 10 Jun 2009 10:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 MbWyA9STA5Ub for ; Wed, 10 Jun 2009 10:54:25 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BA69E3A6B61 for ; Wed, 10 Jun 2009 10:54:24 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AHgBHZ057181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 10:42:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AHgBDk057180; Wed, 10 Jun 2009 10:42: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 mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AHfxjh057164 for ; Wed, 10 Jun 2009 10:42:10 -0700 (MST) (envelope-from lindstream@gmail.com) Received: by bwz22 with SMTP id 22so946998bwz.10 for ; Wed, 10 Jun 2009 10:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QuVxTD4bgfrgDYO6up/zdBmnk0lui0LE8Znp7Zo7VOI=; b=bLNxMNZO64O+hrnLtQFcbYe2QMlJsrwrfKsO8YqiqR9dYLH+ebnnexvLMNPglOEUQj A/Nl7JV0/6Wrer3UK8DvdUcIwQincwI80kmV5J65JROWYms4nEcrsU35TPFWLrKkyCje Guq2I3wmGysdMG4ju/OT98gIyd+zuXXcBPYAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=d60iTKT2Ewdc0DG+SuKFwZSlC3T1R1B38BWz2GVdj1/eMw6oyhDef2yGYCeQwUB+wT dTpCBzeAPgYnuX6zUzf/+CTtD5ohx3ldSrSBgdkmO+D5TcF0IG3FfwWLJlOACxqnuMgA na6zlwcTva87OlLY22e79CPM/WsMnbPDr+1hM= MIME-Version: 1.0 Received: by 10.204.55.142 with SMTP id u14mr1528934bkg.121.1244655718861; Wed, 10 Jun 2009 10:41:58 -0700 (PDT) In-Reply-To: <4A2D939C.9040609@gmail.com> References: <4A2D939C.9040609@gmail.com> Date: Wed, 10 Jun 2009 19:41:58 +0200 Message-ID: Subject: Re: Atom Tombstones Draft Revitalized From: =?ISO-8859-1?Q?Niklas_Lindstr=F6m?= To: James M Snell Cc: atom-syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi James, that's great to hear! Is it thus likely that this will become an Informational RFC in a foreseeable future? And if so, will the current namespace be the final one (and e.g. redirect to the RFC)? Best regards, Niklas On Tue, Jun 9, 2009 at 12:41 AM, James M Snell wrote: > > As requested, the Atom Tombstones draft has been revitalized. > > =A0http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-06.= txt > > Changed this from Experimental to Informational and updated the IPR > boilerplate. > > - James > > From owner-atom-syntax@mail.imc.org Wed Jun 10 11:06:49 2009 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 69F713A68B9 for ; Wed, 10 Jun 2009 11:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=-1.395, BAYES_00=-2.599, J_CHICKENPOX_42=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 rA4AW+bQ3GFg for ; Wed, 10 Jun 2009 11:06:48 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 30FEF3A67EB for ; Wed, 10 Jun 2009 11:06:47 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AHtHlW057908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 10:55:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AHtHE2057907; Wed, 10 Jun 2009 10:55: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 mail-qy0-f171.google.com (mail-qy0-f171.google.com [209.85.221.171]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AHt6jQ057874 for ; Wed, 10 Jun 2009 10:55:17 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk1 with SMTP id 1so1321571qyk.16 for ; Wed, 10 Jun 2009 10:55:05 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=BldhK2AN/blkcYN9V7+A6QSjS5sjCVKvv/LIp3l9z5M=; b=S4TG700ZhCJdcUVtSpolL2TScend6GFOwnrD8GNyPwQCw4s3448HkUGay0Pjv/YrGH 0akeMyrfcU8NlGL6CjXZx9YR6zIKMZo4+5WHQWJywuj7KJuVx5Q558h2kvWSDLkfuzdZ 3Np8RuvCFfEzMOREA/hRKLbb4bGsVfyIcQACQ= 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:content-type:content-transfer-encoding; b=hrwwexEc3khWy6PzxeghO+TsdJN6/ZvdNgUidc/9GoHCs+K9Cc8krXooEr+kYtXSD7 zbXhB8CzWzWWz+1R9AMK1bWtEFfYkZKDgF+MOcLXLmiErCuzkPHYS3a8hcARPB9DZBBc /YoTvr+lYpmwq+ahJvfR+gcSwn1Vn2sWKUOu4= Received: by 10.224.54.3 with SMTP id o3mr2114237qag.127.1244656505471; Wed, 10 Jun 2009 10:55:05 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 7sm344810qwb.16.2009.06.10.10.55.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 10:55:04 -0700 (PDT) Message-ID: <4A2FF3AF.3070803@gmail.com> Date: Wed, 10 Jun 2009 10:55:59 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Nikunj R. Mehta" CC: atom-syntax Syntax Subject: Re: Fwd: New Version Notification for draft-divilly-atom-hierarchy-02 References: <20090610003357.59F6B3A6916@core3.amsl.com> <7D3F8024-3112-4D6B-B0C8-79A7654CB7B7@oracle.com> In-Reply-To: <7D3F8024-3112-4D6B-B0C8-79A7654CB7B7@oracle.com> 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: Thank you for the changes. Another issue that needs to be looked at (which existing in the previous version of the draft as well) is how a processor can reconstruct the logical set of children for an entry... that is, for instance, if the set of child entries contains multiple atom:entry elements with the same atom:id value, are those viewed as separate children or is only the entry with the most recent atom:updated value included in the set of children? Further, if multiple "down" links are specified, each pointing to separate Atom feeds with separate entries with distinct atom:id values, is that to be viewed as two separate child collections or a single logical combined collection? I would recommend the latter. Nikunj R. Mehta wrote: > Based on feedback, I have simplified the I-D to: > In-line extensions moved to draft-mehta-atom-inline > Removed down-tree and up-tree relations > Removed cardinality restrictions on up and down links > > HTML: http://tools.ietf.org/html/draft-divilly-atom-hierarchy-02 > Text: http://tools.ietf.org/id/draft-divilly-atom-hierarchy-02.txt > > Diff: http://tools.ietf.org/rfcdiff?url2=draft-divilly-atom-hierarchy-02.txt > > I > am also tracking open issues about this I-D publicly at http://code.google.com/p/atom-ext/issues/list. > The source for this I-D is also available, if you are interested. > > Looking forward to comments on the I-D. > > Nikunj > http://o-micron.blogspot.com > > > Begin forwarded message: > >> *From: *IETF I-D Submission Tool > > >> *Date: *June 9, 2009 5:33:57 PM PDT >> *To: *nikunj.mehta@oracle.com >> *Cc: *colm.divilly@oracle.com >> *Subject: **New Version Notification for >> draft-divilly-atom-hierarchy-02 * >> >> >> A new version of I-D, draft-divilly-atom-hierarchy-02.txt has been >> successfuly submitted by Nikunj Mehta and posted to the IETF repository. >> >> Filename: draft-divilly-atom-hierarchy >> Revision: 02 >> Title: Hierarchy Relations for Atom >> Creation_date: 2009-06-09 >> WG ID: Independent Submission >> Number_of_pages: 7 >> >> Abstract: >> This specification defines link relations for hierarchical navigation >> among Atom feeds and entries.Editorial Note >> >> To provide feedback on this Internet-Draft, join the atom-syntax >> mailing list (http://www.imc.org/atom-syntax/) [1]. >> >> >> >> The IETF Secretariat. >> >> > From owner-atom-syntax@mail.imc.org Wed Jun 10 11:08:34 2009 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 530A13A683A for ; Wed, 10 Jun 2009 11:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 BK3UzOK5GGIv for ; Wed, 10 Jun 2009 11:08:33 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 47BD73A67EB for ; Wed, 10 Jun 2009 11:08:33 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AHulRl058026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 10:56:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AHulFv058025; Wed, 10 Jun 2009 10:56: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-qy0-f171.google.com (mail-qy0-f171.google.com [209.85.221.171]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AHulBA058019 for ; Wed, 10 Jun 2009 10:56:47 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk1 with SMTP id 1so1323223qyk.16 for ; Wed, 10 Jun 2009 10:56:46 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=U3omOXnaKdX3MoKhNa1FYP3bD2ZdA+P9F3MPpK2WHpo=; b=U1YsHaU5mUBxQbrdBVZq+CPZTnp6ZHcen3V4fSEippXtxSud3EyDvi+3XwswzbHNbQ 9vxpMLlVHlNjmX1z6UA3yqzWFiL/ImzpGT06VTVTX2m92T7R3Vq04aVnxVJ13LgcNm0n EBsfWXkD29gMyDBXO1zlcoqPSAi/DqgAPDrWI= 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:content-type:content-transfer-encoding; b=RqzqOlCt8hW98LS/qcfdpAidFbEyCLFIQ3GmElllfdq1AYBZClsazH+HipACm54H3t d92HP9Pj58Ei4VuqnE4NArNgbWZ+A2mebMwPIyCdXjoP7p15QEPXntFPd7LK04BBDhdh SFXi0zyM2hrbwUfc/wldjaOZSrunfoODAWX+Y= Received: by 10.224.61.14 with SMTP id r14mr2102938qah.253.1244656606399; Wed, 10 Jun 2009 10:56:46 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 8sm337988qwj.4.2009.06.10.10.56.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 10:56:45 -0700 (PDT) Message-ID: <4A2FF414.8060904@gmail.com> Date: Wed, 10 Jun 2009 10:57:40 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niklas_Lindstr=F6m?= CC: atom-syntax Subject: Re: Atom Tombstones Draft Revitalized References: <4A2D939C.9040609@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Niklas Lindström wrote: > Hi James, > > that's great to hear! Is it thus likely that this will become an > Informational RFC in a foreseeable future? > > That's the goal. > And if so, will the current namespace > be the final one (and e.g. > redirect to the RFC)? > > Yes. > Best regards, > Niklas > > > On Tue, Jun 9, 2009 at 12:41 AM, James M Snell wrote: > >> As requested, the Atom Tombstones draft has been revitalized. >> >> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-06.txt >> >> Changed this from Experimental to Informational and updated the IPR >> boilerplate. >> >> - James >> >> >> > > From owner-atom-syntax@mail.imc.org Wed Jun 10 11:13:50 2009 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 580363A68A1 for ; Wed, 10 Jun 2009 11:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 rQLc5QzOyc2e for ; Wed, 10 Jun 2009 11:13:43 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1EBB23A683A for ; Wed, 10 Jun 2009 11:13:42 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AI0TkI058312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 11:00:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AI0TQE058311; Wed, 10 Jun 2009 11:00:29 -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 e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AI0IMl058253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 11:00:29 -0700 (MST) (envelope-from albertcbrown@us.ibm.com) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5AHu0e5015166 for ; Wed, 10 Jun 2009 11:56:00 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5AI04pR139790 for ; Wed, 10 Jun 2009 12:00:05 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5AI02vK007646 for ; Wed, 10 Jun 2009 12:00:03 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n5AI02aQ007632; Wed, 10 Jun 2009 12:00:02 -0600 In-Reply-To: <4A2EE11F.2080809@gmail.com> References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2EE11F.2080809@gmail.com> Subject: Re: Sub-typing Atom documents X-KeepSent: B90A3FE0:8097892C-882575D1:006260AE; type=4; name=$KeepSent To: James M Snell Cc: atom-syntax Syntax , "Nikunj R. Mehta" , owner-atom-syntax@mail.imc.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: Al Brown Date: Wed, 10 Jun 2009 10:59:51 -0700 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Build V851_04282009|April 28, 2009) at 06/10/2009 12:00:02 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBFF42DFF1E63E8f9e8a93df938690918c07BBFF42DFF1E63E" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0__=07BBFF42DFF1E63E8f9e8a93df938690918c07BBFF42DFF1E63E Content-type: multipart/alternative; Boundary="1__=07BBFF42DFF1E63E8f9e8a93df938690918c07BBFF42DFF1E63E" --1__=07BBFF42DFF1E63E8f9e8a93df938690918c07BBFF42DFF1E63E Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable It would be useful to have more than one profile such that cmis + inlin= e may be specified. Also, will you include initial values for the profil= e type or should that be part of CMIS and the inline I-D? Can we have specify language similar to how link relations are specifie= d? Ie, there is a registry of names in a default namespace. Extensions ar= e then free to register their name or use a fully-qualified URI. One add= ed benefit of this is there will be a central registry of atom extensions,= at least the ones that took the time to register them. I also thought the media type parameter inline-depth as useful and that= would be nice to have specified as part of the inline I-D. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of th= e person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please noti= fy the sender. Please also permanently delete all copies of the original message and any attached documentation. = From: James M Snell = = To: "Nikunj R. Mehta" = = Cc: atom-syntax Syntax = = Date: 06/09/2009 03:46 PM = = Subject: Re: Sub-typing Atom documents = = I've already started working up an I-D for a new profile media type parameter. I should be able to get it published by tomorrow end-of-day Example: application/atom+xml;profile=3D"http://example.org/profile/foo" The profile parameter value is a URI that identifies a logical profile to which the Atom document conforms. Only a single profile value is allowed for now. - James Nikunj R. Mehta wrote: > Several recent discussions suggest the need for sub-typing Atom > documents. There are two major requirements for sub-typing Atom documents: > > 1. In Atom Publishing Protocol, signaling the requirement for an Atom= > extension (whether blessed by IETF or not) to be present in accepted > content [1]. To illustrate the requirement by example, one would see:= > > application/atom+xml;type=3Dentry;extension=3Dtoken > > 2. Establishing an expectation on an Atom processor for the media typ= e > of a linked resource, e.g., whether the representation in-lines a > complete hierarchy of Atom entries and feeds [2]. Once again to > illustrate the requirement by example, one would see: > > type=3D"application/atom+xml;type=3Dfeed;inline-depth=3D1" href=3D"ch= ildren"/> > > Of these cases, a really strong case can be made for the first > requirement to use a media type parameter, since it has to happen in > the absence of the actual Atom document. There is only one > must-understand signaling mechanism in AtomPub and that is app:accept= . > If a media type parameter is used in app:accept that cannot be > understood by its receiver, the receiver has no choice but to cease > communications with the server. Since almost every AtomPub-style "API= " > introduces its own set of requirements for what constitutes an entry > the server is willing to accept. > > For example, Google Finance API in its protocol reference states that= > an entry posted as a new portfolio must include a "gf:portfolioData" > element inside an atom:entry [3]. CMIS servers may require the > presence of a type identifier as extended entry metadata in order to > accept an entry posted to a collection [4]. > > It seems quite reasonable to establish a single media type parameter > and allow every such API to define their own acceptable values for > this purpose. This approach provides fair warning and enables AtomPu= b > niches to legally exist, and even interoperate. > > The second case can probably benefit from a media type parameter, but= > it is not clear what the semantics of that parameter would be. > Specifically: > > 1. Do Atom processors fail if, when processing Content-Type header= , > they encounter a media type parameter they don't know about or = a > value in a known media type parameter that they don't understan= d. > 2. Does introduction of media type parameters for > application/atom+xml require standards track RFC? > > > Nikunj > http://o-micron.blogspot.com > > [1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html > [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html > [3] http://code.google.com/apis/finance/developers_guide_protocol.html#Crea= tingPortfolios > [4] http://www.oasis-open.org/committees/download.php/32668 = --1__=07BBFF42DFF1E63E8f9e8a93df938690918c07BBFF42DFF1E63E Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable It would be useful to have more than one profile such that cmis + in= line may be specified. Also, will you include initial values for the p= rofile type or should that be part of CMIS and the inline I-D? Can we have specify language similar to how link relations are specifie= d? Ie, there is a registry of names in a default namespace. Extension= s are then free to register their name or use a fully-qualified URI. O= ne added benefit of this is there will be a central registry of atom ex= tensions, at least the ones that took the time to register them. I also thought the media type parameter inline-depth as useful and that= would be nice to have specified as part of the inline I-D. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: ht= tps://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. James M Snell ---06/= 09/2009 03:46:22 PM---I've already started working up an I-D for a new = profile media type Having problems= viewing=20 this email? Click=20 here. =A0 Know=20 someone else? Forward This=20 Email! We hope you enjoy receiving emai= ls=20 from Kuxqnyza. If you do not wish to receive them, please= click=20 here. Copyright ¿2000-2009 Ilql, I= nc.=20 Jrisjnj, Inc. 8309 Helyf Avenue, WK 95443 P= rivacy=20 Policy=A0=A0|=A0=A0T= erms of=20 Use=A0=A0|=A0=A0Customer=20 Service=A0=A0|=A0=A0S= ite=20 Map =A0 = From: = James M Snell <jasnell@gmail.com> To: "Nikunj R. Mehta" <nikunj.mehta@oracle.co= m> Cc: atom-syntax Syntax <atom-syntax@imc.org><= /td> Date: = 06/09/2009 03:46 PM Subject: Re: Sub-typing Atom documents I've already started working up an I-D for a new profile media type parameter. I should be able to get it published by tomorrow end-of-day<= br> Example: application/atom+xml;profile=3D"http://example.org/profile/foo&qu= ot; The profile parameter value is a URI that identifies a logical profile = to which the Atom document conforms. Only a single profile value is allowed for now. - James Nikunj R. Mehta wrote: > Several recent discussions suggest the need for sub-typing Atom > documents. There are two major requirements for sub-typing Atom do= cuments: > > 1. In Atom Publishing Protocol, signaling the requirement for an A= tom > extension (whether blessed by IETF or not) to be present in accept= ed > content [1]. To illustrate the requirement by example, one would s= ee: > > <app:accept>application/atom+xml;type=3Dentry;extension=3Dto= ken</app:accept> > > 2. Establishing an expectation on an Atom processor for the media = type > of a linked resource, e.g., whether the representation in-lines a = > complete hierarchy of Atom entries and feeds [2]. Once again to > illustrate the requirement by example, one would see: > > <atom:link rel=3D"down" > type=3D"application/atom+xml;type=3Dfeed;inline-depth=3D1&quo= t; href=3D"children"/> > > Of these cases, a really strong case can be made for the first > requirement to use a media type parameter, since it has to happen = in > the absence of the actual Atom document. There is only one > must-understand signaling mechanism in AtomPub and that is app:acc= ept. > If a media type parameter is used in app:accept that cannot be > understood by its receiver, the receiver has no choice but to ceas= e > communications with the server. Since almost every AtomPub-style &= quot;API" > introduces its own set of requirements for what constitutes an ent= ry > the server is willing to accept. > > For example, Google Finance API in its protocol reference states t= hat > an entry posted as a new portfolio must include a "gf:portfol= ioData" > element inside an atom:entry [3]. CMIS servers may require the > presence of a type identifier as extended entry metadata in order = to > accept an entry posted to a collection [4]. > > It seems quite reasonable to establish a single media type paramet= er > and allow every such API to define their own acceptable values for= > this purpose. This approach provides fair warning and enable= s AtomPub > niches to legally exist, and even interoperate. > > The second case can probably benefit from a media type parameter, = but > it is not clear what the semantics of that parameter would be. > Specifically: > > 1. Do Atom processors fail if, when processing Conten= t-Type header, > they encounter a media type parameter they do= n't know about or a > value in a known media type parameter that th= ey don't understand. > 2. Does introduction of media type parameters for = > application/atom+xml require standards track = RFC? > > > Nikunj > http://o-micron.= blogspot.com > > [1] http://www.imc.org/atom-protocol/mail-archive/msg113= 98.html > [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.h= tml > [3] http://code.google.com/api= s/finance/developers_guide_protocol.html#CreatingPortfolios > [4] http://www.oasis-open.org/committees/download.php/32668<= /a> = --1__=07BBFF42DFF1E63E8f9e8a93df938690918c07BBFF42DFF1E63E-- --0__=07BBFF42DFF1E63E8f9e8a93df938690918c07BBFF42DFF1E63E Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBFF42DFF1E63E8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBFF42DFF1E63E8f9e8a93df938690918c07BBFF42DFF1E63E Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=07BBFF42DFF1E63E8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBFF42DFF1E63E8f9e8a93df938690918c07BBFF42DFF1E63E-- From owner-atom-syntax@mail.imc.org Wed Jun 10 11:22:11 2009 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 EAC043A67A7 for ; Wed, 10 Jun 2009 11:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.084 X-Spam-Level: X-Spam-Status: No, score=-0.084 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] 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 RcezuLwy18ll for ; Wed, 10 Jun 2009 11:22:11 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B62713A680F for ; Wed, 10 Jun 2009 11:22:10 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIAVPE058931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 11:10:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AIAVck058930; Wed, 10 Jun 2009 11:10:31 -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-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AI9cc9058838 for ; Wed, 10 Jun 2009 11:10:09 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by yxe34 with SMTP id 34so19022yxe.16 for ; Wed, 10 Jun 2009 11:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-rim-org-msg-ref-id :return-receipt-to:message-id:content-transfer-encoding:reply-to :x-priority:sensitivity:importance:to:subject:from:date:content-type :mime-version; bh=4PIgB90jbkfG0qH71qmgLIEXGQ81YmMHNQekPapANYw=; b=KKTKlTfKGVJ7Cb0OXn/IYfTiYv2wHXTStrwuEbsUhhmzkWjToQ6hmMld8H24TgAF6u SIHH1ltkhMSIWxETJqQKHxYVK5GXYwu5etOQxHaTQHyO6FsN4OV9HygfUHnDG7o84Jtd PeBoRNfVQjIry86FdaJAv4TT0tyhPAduGNJ/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-rim-org-msg-ref-id:return-receipt-to:message-id :content-transfer-encoding:reply-to:x-priority:sensitivity :importance:to:subject:from:date:content-type:mime-version; b=d3p9Juq83SVd2CxEH1USBEJQp9EgbHEnuYNFLHzRfa7pdjTHKUTH1WmqFX4dwwoev0 D/NCN6XS+dj336cDDaoszOJHsTeKrcw0jplweI082+012mOLiCRizmm4c1IZlz4G7BHc ncaSEVi1kFVhRiD/8zjxXAER1qXUIC77oUQr4= Received: by 10.100.144.14 with SMTP id r14mr1649337and.120.1244656938430; Wed, 10 Jun 2009 11:02:18 -0700 (PDT) Received: from bda703.bisx.prod.on.blackberry (e703.bda.bis.na.blackberry.com [67.223.79.112]) by mx.google.com with ESMTPS id 1sm516228agb.8.2009.06.10.11.02.17 (version=SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 11:02:17 -0700 (PDT) X-rim-org-msg-ref-id:1593955225 Message-ID:<1593955225-1244656936-cardhu_decombobulator_blackberry.rim.net-768071802-@bxe1007.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 Reply-To: jasnell@gmail.com X-Priority: Normal Sensitivity: Normal Importance: Normal To: "Colm Divilly" , atom-syntax@imc.org Subject: Re: Linking Atom Entries to 'Category Feeds' From: jasnell@gmail.com Date: Wed, 10 Jun 2009 18:02:16 +0000 Content-Type: text/plain MIME-Version: 1.0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: SSd2ZSB1c2VkIG9wdGlvbiAxIGZvciB0aGlzIGluIHRoZSBwYXN0LiBTZWVtcyB0byBiZSBnb29k IGVub3VnaC4gDQoNCi0tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLS0NCkZyb206IENvbG0gRGl2 aWxseQ0KU2VuZGVyOiBvd25lci1hdG9tLXN5bnRheEBtYWlsLmltYy5vcmcNClRvOiBhdG9tLXN5 bnRheEBpbWMub3JnDQpTdWJqZWN0OiBMaW5raW5nIEF0b20gRW50cmllcyB0byAnQ2F0ZWdvcnkg RmVlZHMnDQpTZW50OiBKdW4gMTAsIDIwMDkgMTA6MzMgQU0NCg0KDQpJJ20gdHJ5aW5nIHRvIGRl c2lnbiBhIG1lY2hhbmlzbSBmb3IgYW5ub3RhdGluZyBhbiBBdG9tIEVudHJ5IHdpdGggbGlua3Mg DQp0byAnY2F0ZWdvcnkgZmVlZHMnIChhIGZlZWQgdGhhdCBsaXN0cyBhbGwgb3RoZXIgZW50cmll cyBoYXZpbmcgdGhlIHNhbWUgDQpjYXRlZ29yeSB0ZXJtKSwgb25lIGxpbmsgcGVyIDxhdG9tOmNh dGVnb3J5PiBlbGVtZW50IGluY2x1ZGVkIGluIHRoZSANCmVudHJ5LiBJIGNhbiB0aGluayBvZiB0 d28gd2F5cyB0byBkbyB0aGlzOg0KDQoxLg0KDQo8ZW50cnkgeG1sbnM9Imh0dHA6Ly93d3cudzMu b3JnLzIwMDUvQXRvbSI+DQogLi4uDQogPGxpbmsgcmVsPSJyZWxhdGVkIiB0eXBlPSJhcHBsaWNh dGlvbi9hdG9tK3htbDt0eXBlPWZlZWQiIA0KaHJlZj0iaHR0cDovL2V4YW1wbGUub3JnL2NhdGVn b3JpZXMvcm9ib3RzLyIvPg0KIDxjYXRlZ29yeSBzY2hlbWU9InVybjp1dWlkOjA0NGQwMzk4LTJm ZDAtNGVkYS1hODg0LThkMjJhNmFjM2I4ZSIgDQp0ZXJtPSJyb2JvdHMiLz4NCiAuLi4NCjwvZW50 cnk+DQoNCjIuDQoNCjxlbnRyeSB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwNS9BdG9tIj4N CiAuLi4NCiA8Y2F0ZWdvcnkgc2NoZW1lPSJ1cm46dXVpZDowNDRkMDM5OC0yZmQwLTRlZGEtYTg4 NC04ZDIyYTZhYzNiOGUiIA0KdGVybT0icm9ib3RzIj4NCiAgPGxpbmsgdHlwZT0iYXBwbGljYXRp b24vYXRvbSt4bWw7dHlwZT1mZWVkIiANCmhyZWY9Imh0dHA6Ly9leGFtcGxlLm9yZy9jYXRlZ29y aWVzL3JvYm90cy8iLz4NCiA8L2NhdGVnb3J5Pg0KIC4uLg0KPC9lbnRyeT4NCg0KVGhlIGdvYWwg aXMgdG8gZW5hYmxlIGNsaWVudHMgdG8gbmF2aWdhdGUgdGhlICdjYXRlZ29yeSBzcGFjZScgDQpk aXNjb3ZlcmluZyBlbnRyaWVzIHRoYXQgYXJlIHNpbWlsYXJseSBjYXRlZ29yaXplZC4gSSBzZWUg T3B0aW9uIDEuIGFzIA0KbW9yZSBsaWtlbHkgdG8gYmUgYnJvYWRseSB1bmRlcnN0b29kLCBlLmcu IGEgZ2VuZXJpYyBmZWVkIHJlYWRlciB3b3VsZCANCmJlIGFibGUgdG8gdW5kZXJzdGFuZCBhbmQg bWFrZSBhdmFpbGFibGUgdGhlICdyZWxhdGVkJyBsaW5rIHRvIHRoZSB1c2VyLCANCmJ1dCBJIGZp bmQgaXQgbGFja2luZyBiZWNhdXNlIGl0IGRvZXMgbm90IGRpcmVjdGx5IHJlbGF0ZSB0aGUgbGlu ayB0byANCnRoZSBjYXRlZ29yeSB0byB3aGljaCBpdCBhcHBsaWVzLiBUaGVyZWZvcmUgSSBmYXZv dXIgT3B0aW9uIDIuIGJ1dCBJIA0KZXhwZWN0IHRoYXQgbm90IHRvIGJlIHVuZGVyc3Rvb2QgYnkg YW55dGhpbmcgb3RoZXIgdGhhbiBteSBvd24gDQphcHBsaWNhdGlvbiBjbGllbnQuDQoNCkknbSBn dWVzc2luZyBvdGhlcnMgaGF2ZSB0cmllZCBtb2RlbGluZyBzb21ldGhpbmcgc2ltaWxhciwgYW55 b25lIGhhdmUgDQphbnkgdGhvdWdodHMgb24gdGhlIGFib3ZlIHByb3Bvc2Fscywgb3IgYWx0ZXJu YXRpdmUgYXBwcm9hY2hlcz8NCg0KUmVnYXJkcywNCkNvbG0gRGl2aWxseQ0KDQoNCg0KU2VudCBm cm9tIG15IFZlcml6b24gV2lyZWxlc3MgQmxhY2tCZXJyeQ== From owner-atom-syntax@mail.imc.org Wed Jun 10 11:27:17 2009 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 5BD7E3A6959 for ; Wed, 10 Jun 2009 11:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.836 X-Spam-Level: X-Spam-Status: No, score=-4.836 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 Nyaop2PDL7px for ; Wed, 10 Jun 2009 11:27:11 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B9B7B3A688B for ; Wed, 10 Jun 2009 11:27:10 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIGZTX059457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 11:16:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AIGZfL059456; Wed, 10 Jun 2009 11:16:35 -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 acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIGY4p059450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 11:16:34 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AIHJMY017832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Jun 2009 18:17:21 GMT Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AIHZm2013120; Wed, 10 Jun 2009 18:17:35 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Jun 2009 11:16:25 -0700 Cc: atom-syntax Syntax Message-Id: From: "Nikunj R. Mehta" To: James M Snell In-Reply-To: <4A2FF3AF.3070803@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-02 Date: Wed, 10 Jun 2009 11:15:04 -0700 References: <20090610003357.59F6B3A6916@core3.amsl.com> <7D3F8024-3112-4D6B-B0C8-79A7654CB7B7@oracle.com> <4A2FF3AF.3070803@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt004.oracle.com [141.146.116.13] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4A2FF87A.01FF:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 10, 2009, at 10:55 AM, James M Snell wrote: > Thank you for the changes. Another issue that needs to be looked at =20= > (which existing in the previous version of the draft as well) This issue did not exist in the previous draft since only one link =20 with @rel value down and @type application/atom+xml was possible. > is how a processor can reconstruct the logical set of children for =20 > an entry... that is, for instance, if the set of child entries =20 > contains multiple atom:entry elements with the same atom:id value, =20 > are those viewed as separate children or is only the entry with the =20= > most recent atom:updated value included in the set of children? We have two choices - either constrain cardinality and obtain an =20 unambiguous logical set of children or remove the cardinality =20 constraint and leave it to applications to interpret multiple sets or =20= subsets. I don;t see how we can get a third option. BTW, the threading =20= extension uses the second approach and =A72.2 as well as =A72.3 of =20 hierarchy I-D explain what an Atom processor does with multiple =20 occurrences of the down and up link, respectively. > Further, if multiple "down" links are specified, each pointing to =20 > separate Atom feeds with separate entries with distinct atom:id =20 > values, is that to be viewed as two separate child collections or a =20= > single logical combined collection? I would recommend the latter. As I explain above, this choice is infeasible. How is one to reconcile =20= an HTML linked resource with an entry with a feed and an image all =20 through @rel=3Ddown? I would be interested in learning of a proposal to =20= handle this kind of a situation. > > Nikunj R. Mehta wrote: >> Based on feedback, I have simplified the I-D to: >> In-line extensions moved to draft-mehta-atom-inline >> Removed down-tree and up-tree relations >> Removed cardinality restrictions on up and down links >> >> HTML: http://tools.ietf.org/html/draft-divilly-atom-hierarchy-02 >> Text: http://tools.ietf.org/id/draft-divilly-atom-hierarchy-02.txt = > > >> Diff: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-divilly-atom-hierarchy-02.txt >> >> I am also tracking open issues about this I-D publicly at = http://code.google.com/p/atom-ext/issues/list=20 >> . The source for this I-D is also available, if you are interested. >> >> Looking forward to comments on the I-D. >> >> Nikunj >> http://o-micron.blogspot.com >> >> >> Begin forwarded message: >> >>> *From: *IETF I-D Submission Tool >> >> >>> *Date: *June 9, 2009 5:33:57 PM PDT >>> *To: *nikunj.mehta@oracle.com >>> *Cc: *colm.divilly@oracle.com >>> *Subject: **New Version Notification for draft-divilly-atom-=20 >>> hierarchy-02 * >>> >>> >>> A new version of I-D, draft-divilly-atom-hierarchy-02.txt has been =20= >>> successfuly submitted by Nikunj Mehta and posted to the IETF =20 >>> repository. >>> >>> Filename: draft-divilly-atom-hierarchy >>> Revision: 02 >>> Title: Hierarchy Relations for Atom >>> Creation_date: 2009-06-09 >>> WG ID: Independent Submission >>> Number_of_pages: 7 >>> >>> Abstract: >>> This specification defines link relations for hierarchical =20 >>> navigation >>> among Atom feeds and entries.Editorial Note >>> >>> To provide feedback on this Internet-Draft, join the atom-syntax >>> mailing list (http://www.imc.org/atom-syntax/) [1]. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >> From owner-atom-syntax@mail.imc.org Wed Jun 10 11:28:55 2009 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 C06143A6999 for ; Wed, 10 Jun 2009 11:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 jDJ29V4-J5BV for ; Wed, 10 Jun 2009 11:28:49 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 655413A688D for ; Wed, 10 Jun 2009 11:28:49 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIHS0w059496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 11:17:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AIHSwU059495; Wed, 10 Jun 2009 11:17: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 yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.158]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIHGpa059480 for ; Wed, 10 Jun 2009 11:17:27 -0700 (MST) (envelope-from pjkeane@gmail.com) Received: by yw-out-1718.google.com with SMTP id 6so467943ywa.4 for ; Wed, 10 Jun 2009 11:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=GS8aHutnr9zpCdPumyj/g1cex8tgAShnBHU+U+YsbN4=; b=vRSB0SCHSgtwFQLiCMXjllQ7K8kJHgQq6Hunj1FOrM3TqzZBfFP630Rmz4HgFfEcSU OBJFbj+Kg0Cbq89yAuKvX8+8ZUZ2whb63MA05YKpb4EFnlEKpi5EBMXpVbW6TcoR8Sf4 6qvOMsAnlgObyeY8nynD5b5QAf+UvkSgEapNM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=xFv5zOh3fi+dy75sfjmZ14I4WQfiLF9UUq+/j46DDxpKZqxoe4+XBfQTwV6OYdcM/y sMNDktWMgy7CDMovzk14Zj/XGYq/BVo2e7b/Yi4NnvIcB8QoPZEe24jsnvZktU1w3iiW NXXPncUN3m+NNpRrlhJbXroi0XZhu2A1y0qvY= MIME-Version: 1.0 Received: by 10.151.45.5 with SMTP id x5mr3070670ybj.339.1244657836596; Wed, 10 Jun 2009 11:17:16 -0700 (PDT) In-Reply-To: References: <4A2D939C.9040609@gmail.com> Date: Wed, 10 Jun 2009 13:17:16 -0500 X-Google-Sender-Auth: 6be4ceb0776ed20f Message-ID: <8158ad750906101117y7cc540d9ld9525524c6b457e6@mail.gmail.com> Subject: Re: Atom Tombstones Draft Revitalized From: Peter Keane To: =?UTF-8?Q?Niklas_Lindstr=C3=B6m?= Cc: James M Snell , atom-syntax Content-Type: multipart/alternative; boundary=0015174c3712379f57046c027c8e Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0015174c3712379f57046c027c8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For what it's worth, on the slim chance that someone reads my (negative) comments on this draft on atom-syntax back when it was first proposed -- I now think those objections were ill-considered. This looks v. good. --peter keane 2009/6/10 Niklas Lindstr=C3=B6m > > Hi James, > > that's great to hear! Is it thus likely that this will become an > Informational RFC in a foreseeable future? > > And if so, will the current namespace > be the final one (and e.g. > redirect to the RFC)? > > Best regards, > Niklas > > > On Tue, Jun 9, 2009 at 12:41 AM, James M Snell wrote: > > > > As requested, the Atom Tombstones draft has been revitalize > > > > > http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-06.txt > > > > Changed this from Experimental to Informational and updated the IPR > > boilerplate. > > > > - James > > > > > > --0015174c3712379f57046c027c8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For what it's worth, on the slim chance that someone reads my (negative= ) comments on this draft on atom-syntax back when it was first proposed -- = I now think those objections were ill-considered. =C2=A0 This looks v. good= . --peter keane 2009/6/10 Niklas Li= ndstr=C3=B6m <= lindstream@gmail.com> Hi James, that's great to hear! Is it thus likely that this will become an Informational RFC in a foreseeable future? And if so, will the current namespace <ht= tp://purl.org/atompub/tombstones/1.0> be the final one (and e.g. redirect to the RFC)? Best regards, Niklas On Tue, Jun 9, 2009 at 12:41 AM, James M Snell <jasnell@gmail.com> wrote: > > As requested, the Atom Tombstones draft has been revitalize > > =C2=A0http://www.ietf.org/internet-drafts= /draft-snell-atompub-tombstones-06.txt > > Changed this from Experimental to Informational and updated the IPR > boilerplate. > > - James > > --0015174c3712379f57046c027c8e-- From owner-atom-syntax@mail.imc.org Wed Jun 10 11:42:53 2009 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 7E10E3A6C6F for ; Wed, 10 Jun 2009 11:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=1.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 K-ZgULL0MfpB for ; Wed, 10 Jun 2009 11:42:52 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E67843A6C4C for ; Wed, 10 Jun 2009 11:42:51 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIUKLQ060250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 11:30:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AIUKba060249; Wed, 10 Jun 2009 11:30:20 -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 yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.156]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIU97m060239 for ; Wed, 10 Jun 2009 11:30:20 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by yw-out-1718.google.com with SMTP id 6so472077ywa.4 for ; Wed, 10 Jun 2009 11:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-rim-org-msg-ref-id :return-receipt-to:message-id:reply-to:x-priority:references :in-reply-to:sensitivity:importance:to:cc:subject:from:date :content-type:mime-version; bh=fe9deOWAyw5TI/I0Y6OLeqqh80RVZ1nOQkS2oyCZdP8=; b=WxCbhQ52mKiKbN39wqGCgtyBbBGbkEb3LhPqwjTCA6VE6bzRIvWsXhcAJdaEBtBR9c ur61AFemIAvEHN6qTrixFVmyBi8BKZGN5F6wU2AwzgE13PeGbOfSjXtr9kCBDlFR5fla cqOM64dBJ2t1fb51FahbErO2k0RmSIS0sltwI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-rim-org-msg-ref-id:return-receipt-to:message-id:reply-to :x-priority:references:in-reply-to:sensitivity:importance:to:cc :subject:from:date:content-type:mime-version; b=V+qv+IVzs+Cs6YKvo5fE/K3RBQBP+2f8brs6STXR4iniwPy2UPbMmmK/hyvazZ7Cbe CWoPUxa7hTOgZlkhp6W5l8f0zV+QgN5ei9iIfxGFtDEoGuWOvzeifygnyACte477qXHz gavC9rfk2zrLojjv37m3vUC96N40bSwHEFhwc= Received: by 10.90.73.17 with SMTP id v17mr1354154aga.24.1244658609323; Wed, 10 Jun 2009 11:30:09 -0700 (PDT) Received: from bda703.bisx.prod.on.blackberry (c703.bda.bis.na.blackberry.com [67.223.71.112]) by mx.google.com with ESMTPS id 7sm281660agb.2.2009.06.10.11.30.08 (version=SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 11:30:08 -0700 (PDT) X-rim-org-msg-ref-id:1933823056 Message-ID:<1933823056-1244658606-cardhu_decombobulator_blackberry.rim.net-760899814-@bxe1007.bisx.prod.on.blackberry> Reply-To: jasnell@gmail.com X-Priority: Normal References: <4A2D939C.9040609@gmail.com> <8158ad750906101117y7cc540d9ld9525524c6b457e6@mail.gmail.com> In-Reply-To: <8158ad750906101117y7cc540d9ld9525524c6b457e6@mail.gmail.com> Sensitivity: Normal Importance: Normal To: "Peter Keane" , pjkeane@gmail.com, "=?Windows-1252?B?TmlrbGFzIExpbmRzdHL2bQ==?=" Cc: "atom-syntax" Subject: Re: Atom Tombstones Draft Revitalized From: jasnell@gmail.com Date: Wed, 10 Jun 2009 18:30:05 +0000 Content-Type: multipart/alternative; boundary="part123547-boundary-226804680-1490391199" MIME-Version: 1.0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --part123547-boundary-226804680-1490391199 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" RXhjZWxsZW50LCBnbGFkIHRvIGhlYXIgaXQuIA0KDQpTZW50IGZyb20gbXkgVmVyaXpvbiBXaXJl bGVzcyBCbGFja0JlcnJ5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQZXRl ciBLZWFuZSA8cGtlYW5lQG1haWwudXRleGFzLmVkdT4NCg0KRGF0ZTogV2VkLCAxMCBKdW4gMjAw OSAxMzoxNzoxNiANClRvOiBOaWtsYXMgTGluZHN0csO2bTxsaW5kc3RyZWFtQGdtYWlsLmNvbT4N CkNjOiBKYW1lcyBNIFNuZWxsPGphc25lbGxAZ21haWwuY29tPjsgYXRvbS1zeW50YXg8YXRvbS1z eW50YXhAaW1jLm9yZz4NClN1YmplY3Q6IFJlOiBBdG9tIFRvbWJzdG9uZXMgRHJhZnQgUmV2aXRh bGl6ZWQNCg0KDQpGb3Igd2hhdCBpdCdzIHdvcnRoLCBvbiB0aGUgc2xpbSBjaGFuY2UgdGhhdCBz b21lb25lIHJlYWRzIG15IChuZWdhdGl2ZSkNCmNvbW1lbnRzIG9uIHRoaXMgZHJhZnQgb24gYXRv bS1zeW50YXggYmFjayB3aGVuIGl0IHdhcyBmaXJzdCBwcm9wb3NlZCAtLSBJDQpub3cgdGhpbmsg dGhvc2Ugb2JqZWN0aW9ucyB3ZXJlIGlsbC1jb25zaWRlcmVkLiAgIFRoaXMgbG9va3Mgdi4gZ29v ZC4NCg0KLS1wZXRlciBrZWFuZQ0KDQoNCjIwMDkvNi8xMCBOaWtsYXMgTGluZHN0csO2bSA8bGlu ZHN0cmVhbUBnbWFpbC5jb20+DQoNCj4NCj4gSGkgSmFtZXMsDQo+DQo+IHRoYXQncyBncmVhdCB0 byBoZWFyISBJcyBpdCB0aHVzIGxpa2VseSB0aGF0IHRoaXMgd2lsbCBiZWNvbWUgYW4NCj4gSW5m b3JtYXRpb25hbCBSRkMgaW4gYSBmb3Jlc2VlYWJsZSBmdXR1cmU/DQo+DQo+IEFuZCBpZiBzbywg d2lsbCB0aGUgY3VycmVudCBuYW1lc3BhY2UNCj4gPGh0dHA6Ly9wdXJsLm9yZy9hdG9tcHViL3Rv bWJzdG9uZXMvMS4wPiBiZSB0aGUgZmluYWwgb25lIChhbmQgZS5nLg0KPiByZWRpcmVjdCB0byB0 aGUgUkZDKT8NCj4NCj4gQmVzdCByZWdhcmRzLA0KPiBOaWtsYXMNCj4NCj4NCj4gT24gVHVlLCBK dW4gOSwgMjAwOSBhdCAxMjo0MSBBTSwgSmFtZXMgTSBTbmVsbCA8amFzbmVsbEBnbWFpbC5jb20+ IHdyb3RlOg0KPiA+DQo+ID4gQXMgcmVxdWVzdGVkLCB0aGUgQXRvbSBUb21ic3RvbmVzIGRyYWZ0 IGhhcyBiZWVuIHJldml0YWxpemUNCj4gPg0KPiA+DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LXNuZWxsLWF0b21wdWItdG9tYnN0b25lcy0wNi50eHQNCj4gPg0K PiA+IENoYW5nZWQgdGhpcyBmcm9tIEV4cGVyaW1lbnRhbCB0byBJbmZvcm1hdGlvbmFsIGFuZCB1 cGRhdGVkIHRoZSBJUFINCj4gPiBib2lsZXJwbGF0ZS4NCj4gPg0KPiA+IC0gSmFtZXMNCj4gPg0K PiA+DQo+DQo+DQoNCg== --part123547-boundary-226804680-1490391199 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4gPEhUTUw+PEhFQUQ+IDxNRVRBIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4gPC9IRUFEPkV4Y2VsbGVudCwgZ2xhZCB0byBo ZWFyIGl0LiA8YnIvPjxwPlNlbnQgZnJvbSBteSBWZXJpem9uIFdpcmVsZXNzIEJsYWNrQmVycnk8 L3A+PHA+PGhyIHNpemU9MiB3aWR0aD0xMDAlIGFsaWduPWNlbnRlciB0YWJpbmRleD0tMT48Yj5G cm9tPC9iPjogIFBldGVyIEtlYW5lIDxwa2VhbmVAbWFpbC51dGV4YXMuZWR1Pjxicj48Yj5EYXRl PC9iPjogV2VkLCAxMCBKdW4gMjAwOSAxMzoxNzoxNiAtMDUwMDxicj48Yj5UbzwvYj46IE5pa2xh cyBMaW5kc3Ryw7ZtJmx0O2xpbmRzdHJlYW1AZ21haWwuY29tJmd0Ozxicj48Yj5TdWJqZWN0PC9i PjogUmU6IEF0b20gVG9tYnN0b25lcyBEcmFmdCBSZXZpdGFsaXplZDxicj48L2ZvbnQ+PC9wPkZv ciB3aGF0IGl0JiMzOTtzIHdvcnRoLCBvbiB0aGUgc2xpbSBjaGFuY2UgdGhhdCBzb21lb25lIHJl YWRzIG15IChuZWdhdGl2ZSkgY29tbWVudHMgb24gdGhpcyBkcmFmdCBvbiBhdG9tLXN5bnRheCBi YWNrIHdoZW4gaXQgd2FzIGZpcnN0IHByb3Bvc2VkIC0tIEkgbm93IHRoaW5rIHRob3NlIG9iamVj dGlvbnMgd2VyZSBpbGwtY29uc2lkZXJlZC4gwqAgVGhpcyBsb29rcyB2LiBnb29kLjxicj48YnI+ LS1wZXRlciBrZWFuZTxicj48YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDA5LzYv MTAgTmlrbGFzIExpbmRzdHLDtm0gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86 bGluZHN0cmVhbUBnbWFpbC5jb20iPmxpbmRzdHJlYW1AZ21haWwuY29tPC9hPiZndDs8L3NwYW4+ PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAx cHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBw YWRkaW5nLWxlZnQ6IDFleDsiPjxicj4gSGkgSmFtZXMsPGJyPjxicj4gdGhhdCYjMzk7cyBncmVh dCB0byBoZWFyISBJcyBpdCB0aHVzIGxpa2VseSB0aGF0IHRoaXMgd2lsbCBiZWNvbWUgYW48YnI+ IEluZm9ybWF0aW9uYWwgUkZDIGluIGEgZm9yZXNlZWFibGUgZnV0dXJlPzxicj48YnI+IEFuZCBp ZiBzbywgd2lsbCB0aGUgY3VycmVudCBuYW1lc3BhY2U8YnI+ICZsdDs8YSBocmVmPSJodHRwOi8v cHVybC5vcmcvYXRvbXB1Yi90b21ic3RvbmVzLzEuMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9w dXJsLm9yZy9hdG9tcHViL3RvbWJzdG9uZXMvMS4wPC9hPiZndDsgYmUgdGhlIGZpbmFsIG9uZSAo YW5kIGUuZy48YnI+IHJlZGlyZWN0IHRvIHRoZSBSRkMpPzxicj48YnI+IEJlc3QgcmVnYXJkcyw8 YnI+PGZvbnQgY29sb3I9IiM4ODg4ODgiPk5pa2xhczxicj48L2ZvbnQ+PGRpdj48ZGl2PjwvZGl2 PjxkaXYgY2xhc3M9Img1Ij48YnI+PGJyPiBPbiBUdWUsIEp1biA5LCAyMDA5IGF0IDEyOjQxIEFN LCBKYW1lcyBNIFNuZWxsICZsdDs8YSBocmVmPSJtYWlsdG86amFzbmVsbEBnbWFpbC5jb20iPmph c25lbGxAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPiAmZ3Q7PGJyPiAmZ3Q7IEFzIHJlcXVl c3RlZCwgdGhlIEF0b20gVG9tYnN0b25lcyBkcmFmdCBoYXMgYmVlbiByZXZpdGFsaXplPGJyPiAm Z3Q7PGJyPiAmZ3Q7IMKgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtc25lbGwtYXRvbXB1Yi10b21ic3RvbmVzLTA2LnR4dCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNuZWxsLWF0b21wdWIt dG9tYnN0b25lcy0wNi50eHQ8L2E+PGJyPiAmZ3Q7PGJyPiAmZ3Q7IENoYW5nZWQgdGhpcyBmcm9t IEV4cGVyaW1lbnRhbCB0byBJbmZvcm1hdGlvbmFsIGFuZCB1cGRhdGVkIHRoZSBJUFI8YnI+ICZn dDsgYm9pbGVycGxhdGUuPGJyPiAmZ3Q7PGJyPiAmZ3Q7IC0gSmFtZXM8YnI+ICZndDs8YnI+ICZn dDs8YnI+PGJyPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+ICAtLTAwMTUxNzRj MzcxMjM3OWY1NzA0NmMwMjdjOGUtLTwvaHRtbD4= --part123547-boundary-226804680-1490391199-- From owner-atom-syntax@mail.imc.org Wed Jun 10 11:43:56 2009 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 223C03A6C4C for ; Wed, 10 Jun 2009 11:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.415 X-Spam-Level: X-Spam-Status: No, score=-5.415 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 OV6LbskxTJub for ; Wed, 10 Jun 2009 11:43:54 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A9B7A3A6CA8 for ; Wed, 10 Jun 2009 11:43:41 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIKO7h059661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 11:20:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AIKO38059660; Wed, 10 Jun 2009 11:20:24 -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 acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIKCA1059648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 11:20:23 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AIGOqV029325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Jun 2009 18:16:25 GMT Received: from abhmt006.oracle.com (abhmt006.oracle.com [141.146.116.15]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AILGdR022226; Wed, 10 Jun 2009 18:21:16 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Jun 2009 11:20:06 -0700 Cc: James M Snell , atom-syntax Syntax Message-Id: <62E5FD4C-D6D7-4A7A-8918-0DDA48D10495@oracle.com> From: "Nikunj R. Mehta" To: Al Brown In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-40-62752512 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Sub-typing Atom documents Date: Wed, 10 Jun 2009 11:18:44 -0700 References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2EE11F.2080809@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt006.oracle.com [141.146.116.15] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4A2FF957.0078:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-40-62752512 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I find it difficult to incorporate the specification of a media type parameter to specify inline depth in the absence of a specific proposal for how to construct deeply nested hierarchy in the face of up and down links as well as multi-parents. It only makes sense to specify the media type parameter once a specific meaning or a value space can be defined. I am not sure a viable proposal exists (partly because of questions such as those raised in [1]), but I'd be happy to work with anyone's proposal that addresses this concern. Nikunj http://o-micron.blogspot.com [1] http://tools.oasis-open.org/issues/browse/CMIS-259 On Jun 10, 2009, at 10:59 AM, Al Brown wrote: > It would be useful to have more than one profile such that cmis + > inline may be specified. Also, will you include initial values for > the profile type or should that be part of CMIS and the inline I-D? > > Can we have specify language similar to how link relations are > specified? Ie, there is a registry of names in a default namespace. > Extensions are then free to register their name or use a fully- > qualified URI. One added benefit of this is there will be a central > registry of atom extensions, at least the ones that took the time to > register them. > > I also thought the media type parameter inline-depth as useful and > that would be nice to have specified as part of the inline I-D. > > -Al > > Al Brown > Emerging Standards and Industry Frameworks > CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home > Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home > > Office 714 327 3453 > Mobile 714 263 6441 > Email albertcbrown@us.ibm.com > CONFIDENTIAL NOTICE: The contents of this message, including any > attachments, are confidential and are intended solely for the use of > the person or entity to whom the message was addressed. If you are > not the intended recipient of this message, please be advised that > any dissemination, distribution, or use of the contents of this > message is strictly prohibited. If you received this message in > error, please notify the sender. Please also permanently delete all > copies of the original message and any attached documentation. > > James M Snell ---06/09/2009 03:46:22 PM---I've already > started working up an I-D for a new profile media type > > > From: > James M Snell > > To: > "Nikunj R. Mehta" > > Cc: > atom-syntax Syntax > > Date: > 06/09/2009 03:46 PM > > Subject: > Re: Sub-typing Atom documents > > > > > I've already started working up an I-D for a new profile media type > parameter. I should be able to get it published by tomorrow end-of-day > > Example: > > application/atom+xml;profile="http://example.org/profile/foo" > > The profile parameter value is a URI that identifies a logical profile > to which the Atom document conforms. Only a single profile value is > allowed for now. > > - James > > Nikunj R. Mehta wrote: > > Several recent discussions suggest the need for sub-typing Atom > > documents. There are two major requirements for sub-typing Atom > documents: > > > > 1. In Atom Publishing Protocol, signaling the requirement for an > Atom > > extension (whether blessed by IETF or not) to be present in accepted > > content [1]. To illustrate the requirement by example, one would > see: > > > > application/atom+xml;type=entry;extension=token app:accept> > > > > 2. Establishing an expectation on an Atom processor for the media > type > > of a linked resource, e.g., whether the representation in-lines a > > complete hierarchy of Atom entries and feeds [2]. Once again to > > illustrate the requirement by example, one would see: > > > > > type="application/atom+xml;type=feed;inline-depth=1" > href="children"/> > > > > Of these cases, a really strong case can be made for the first > > requirement to use a media type parameter, since it has to happen in > > the absence of the actual Atom document. There is only one > > must-understand signaling mechanism in AtomPub and that is > app:accept. > > If a media type parameter is used in app:accept that cannot be > > understood by its receiver, the receiver has no choice but to cease > > communications with the server. Since almost every AtomPub-style > "API" > > introduces its own set of requirements for what constitutes an entry > > the server is willing to accept. > > > > For example, Google Finance API in its protocol reference states > that > > an entry posted as a new portfolio must include a "gf:portfolioData" > > element inside an atom:entry [3]. CMIS servers may require the > > presence of a type identifier as extended entry metadata in order to > > accept an entry posted to a collection [4]. > > > > It seems quite reasonable to establish a single media type parameter > > and allow every such API to define their own acceptable values for > > this purpose. This approach provides fair warning and enables > AtomPub > > niches to legally exist, and even interoperate. > > > > The second case can probably benefit from a media type parameter, > but > > it is not clear what the semantics of that parameter would be. > > Specifically: > > > > 1. Do Atom processors fail if, when processing Content-Type > header, > > they encounter a media type parameter they don't know about > or a > > value in a known media type parameter that they don't > understand. > > 2. Does introduction of media type parameters for > > application/atom+xml require standards track RFC? > > > > > > Nikunj > > http://o-micron.blogspot.com > > > > [1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html > > [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html > > [3] http://code.google.com/apis/finance/developers_guide_protocol.html#CreatingPortfolios > > [4] http://www.oasis-open.org/committees/download.php/32668 > > > --Apple-Mail-40-62752512 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I find it difficult to = incorporate the specification of a media type parameter to specify = inline depth in the absence of a specific proposal for how to construct = deeply nested hierarchy in the face of up and down links as well as = multi-parents. It only makes sense to specify = the media type parameter once a specific meaning or a value space can be = defined. I am not sure a viable proposal exists (partly because of = questions such as those raised in [1]), but I'd be happy to work with = anyone's proposal that addresses this concern. Nikunj http://o-micron.blogspot.com [1]&n= bsp;http://tools.o= asis-open.org/issues/browse/CMIS-259 On Jun 10, = 2009, at 10:59 AM, Al Brown wrote: It = would be useful to have more than one profile such that cmis + inline = may be specified. Also, will you include initial values for the profile = type or should that be part of CMIS and the inline I-D? Can we = have specify language similar to how link relations are specified? Ie, = there is a registry of names in a default namespace. Extensions are = then free to register their name or use a fully-qualified URI. One = added benefit of this is there will be a central registry of atom = extensions, at least the ones that took the time to register them. = I also thought the media type parameter inline-depth as useful and = that would be nice to have specified as part of the inline I-D. = -Al Al Brown Emerging Standards and Industry Frameworks = CMIS: https://w3.tap= .ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.i= bm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 = Mobile 714 263 6441 Email albertcbrown@us.ibm.com = CONFIDENTIAL NOTICE: The contents of this message, including any = attachments, are confidential and are intended solely for the use of the = person or entity to whom the message was addressed. If you are not the = intended recipient of this message, please be advised that any = dissemination, distribution, or use of the contents of this message is = strictly prohibited. If you received this message in error, please = notify the sender. Please also permanently delete all copies of the = original message and any attached documentation. = <graycol.gif>James M Snell = ---06/09/2009 03:46:22 PM---I've already started working up an I-D for a = new profile media type <ecblank.gif> From: <ecblank.gif> James= M Snell <jasnell@gmail.com> <ecblank.gif> To: <ecblank.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.com> <ecblank.gif> Cc: <ecblank.gif> atom-syntax Syntax <atom-syntax@imc.org> <ecblank.gif> Date: <ecblank.gif> 06/09/2009 03:46 PM <ecblank.gif> Subject: <ecblank.gif> Re: = Sub-typing Atom documents I've already started = working up an I-D for a new profile media type parameter. I should = be able to get it published by tomorrow end-of-day Example: = application/atom+xml;profile=3D"http://example.org/profile/foo= " The profile parameter value is a URI that identifies = a logical profile to which the Atom document conforms. Only a = single profile value is allowed for now. - James = Nikunj R. Mehta wrote: > Several recent discussions suggest the = need for sub-typing Atom > documents. There are two major = requirements for sub-typing Atom documents: > > 1. In Atom = Publishing Protocol, signaling the requirement for an Atom > = extension (whether blessed by IETF or not) to be present in accepted = > content [1]. To illustrate the requirement by example, one = would see: > > = <app:accept>application/atom+xml;type=3Dentry;extension=3Dtoken</= app:accept> > > 2. Establishing an expectation on an = Atom processor for the media type > of a linked resource, e.g., = whether the representation in-lines a > complete hierarchy of = Atom entries and feeds [2]. Once again to > illustrate the = requirement by example, one would see: > > <atom:link = rel=3D"down" > = type=3D"application/atom+xml;type=3Dfeed;inline-depth=3D1" = href=3D"children"/> > > Of these cases, a really strong = case can be made for the first > requirement to use a media type = parameter, since it has to happen in > the absence of the actual = Atom document. There is only one > must-understand signaling = mechanism in AtomPub and that is app:accept. > If a media type = parameter is used in app:accept that cannot be > understood by = its receiver, the receiver has no choice but to cease > = communications with the server. Since almost every AtomPub-style "API" = > introduces its own set of requirements for what constitutes an = entry > the server is willing to accept. > > For = example, Google Finance API in its protocol reference states that = > an entry posted as a new portfolio must include a = "gf:portfolioData" > element inside an atom:entry [3]. CMIS = servers may require the > presence of a type identifier as = extended entry metadata in order to > accept an entry posted to = a collection [4]. > > It seems quite reasonable to = establish a single media type parameter > and allow every such = API to define their own acceptable values for > this purpose. = This approach provides fair warning and enables AtomPub > = niches to legally exist, and even interoperate. > > The = second case can probably benefit from a media type parameter, but = > it is not clear what the semantics of that parameter would be. = > Specifically: > > 1. Do Atom processors = fail if, when processing Content-Type header, > = they encounter a media type parameter they don't know about or = a > value in a known media type parameter = that they don't understand. > 2. Does introduction = of media type parameters for > = application/atom+xml require standards track RFC? > > = > Nikunj > http://o-micron.blogspot.com > > [1] http:= //www.imc.org/atom-protocol/mail-archive/msg11398.html = > [2] http://= www.imc.org/atom-syntax/mail-archive/msg21114.html > = [3] http://code.google.com/apis/finance/developers_guide_= protocol.html#CreatingPortfolios > [4] http://ww= w.oasis-open.org/committees/download.php/32668 = = --Apple-Mail-40-62752512-- From owner-atom-syntax@mail.imc.org Wed Jun 10 11:49:47 2009 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 B60603A6A1F for ; Wed, 10 Jun 2009 11:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=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 QOlUVCsKBCSD for ; Wed, 10 Jun 2009 11:49:46 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id F04473A6824 for ; Wed, 10 Jun 2009 11:49:45 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIc7W7060589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 11:38:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AIc7wF060588; Wed, 10 Jun 2009 11:38: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 mail-ew0-f217.google.com (mail-ew0-f217.google.com [209.85.219.217]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIbsLW060570 for ; Wed, 10 Jun 2009 11:38:05 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by ewy17 with SMTP id 17so1060539ewy.10 for ; Wed, 10 Jun 2009 11:37:54 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=SbJ7W6wZpSAsLnUZ1gcSggGRYq+TDTca7zfD2//FkcY=; b=kFsFBFjaOGJnC4IqaCpBjqaX4k8IsFVVVYl53s0399RGIqs1QZRTc/ThK8DhTqf/6p NOcsogjYK0lhIfIJ+mj6asxdKOjNhtC5gIAOjaBsHXPqUTC4wXoOZLol26Qoy9DUneE/ tbBEEF/QNhkmHCLUHmmL0nHz+Anob5kHhS5Rk= 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:content-type:content-transfer-encoding; b=CHNCDR1WktkqEyuOMQhw6LS8ZFQMhbdYYnrN6upL7yhPGIT58LBGlONKeuEQwmuH7H UGQAyvK6tcLPfYTexHXrEBI66TJpg7MWyjUj8ZS/kvRRx43V7qZHaxhGdV7/r2pC6ORc 2D++cne/tdMfmNppt5+NW3f4og/82bqNaIGEM= Received: by 10.216.28.15 with SMTP id f15mr630367wea.30.1244659074005; Wed, 10 Jun 2009 11:37:54 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id x6sm14818863gvf.24.2009.06.10.11.37.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 11:37:46 -0700 (PDT) Message-ID: <4A2FFDAF.2070404@gmail.com> Date: Wed, 10 Jun 2009 11:38:39 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Al Brown CC: atom-syntax Syntax , "Nikunj R. Mehta" , owner-atom-syntax@mail.imc.org Subject: Re: Sub-typing Atom documents References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2EE11F.2080809@gmail.com> In-Reply-To: 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: Al Brown wrote: > > It would be useful to have more than one profile such that cmis + > inline may be specified. Also, will you include initial values for the > profile type or should that be part of CMIS and the inline I-D? > More than one profile value is definitely possible. > > Can we have specify language similar to how link relations are > specified? Ie, there is a registry of names in a default namespace. > Extensions are then free to register their name or use a > fully-qualified URI. One added benefit of this is there will be a > central registry of atom extensions, at least the ones that took the > time to register them. > Again, also a strong possibility if and only if there is consensus that a central registry would be beneficial. > > I also thought the media type parameter inline-depth as useful and > that would be nice to have specified as part of the inline I-D. > -1... incorporating something like inline-depth=1 into the media type would not be a good thing. The media type is intended to describe the kind of document that's being passed around and not specific details about the documents construction. When I say something like "application/atom+xml;type=entry;profile=tree", what I'm saying is that the document is potentially a hierarchical Atom entry but in order to determine anything more about the document I have to retrieve and examine it directly. > > -Al > > Al Brown > Emerging Standards and Industry Frameworks > CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home > Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home > > Office 714 327 3453 > Mobile 714 263 6441 > Email albertcbrown@us.ibm.com > CONFIDENTIAL NOTICE: The contents of this message, including any > attachments, are confidential and are intended solely for the use of > the person or entity to whom the message was addressed. If you are not > the intended recipient of this message, please be advised that any > dissemination, distribution, or use of the contents of this message is > strictly prohibited. If you received this message in error, please > notify the sender. Please also permanently delete all copies of the > original message and any attached documentation. > > Inactive hide details for James M Snell ---06/09/2009 03:46:22 > PM---I've already started working up an I-D for a new profile meJames > M Snell ---06/09/2009 03:46:22 PM---I've already started working up an > I-D for a new profile media type > > > From: > James M Snell > > To: > "Nikunj R. Mehta" > > Cc: > atom-syntax Syntax > > Date: > 06/09/2009 03:46 PM > > Subject: > Re: Sub-typing Atom documents > > ------------------------------------------------------------------------ > > > > > I've already started working up an I-D for a new profile media type > parameter. I should be able to get it published by tomorrow end-of-day > > Example: > > application/atom+xml;profile="http://example.org/profile/foo" > > The profile parameter value is a URI that identifies a logical profile > to which the Atom document conforms. Only a single profile value is > allowed for now. > > - James > > Nikunj R. Mehta wrote: > > Several recent discussions suggest the need for sub-typing Atom > > documents. There are two major requirements for sub-typing Atom > documents: > > > > 1. In Atom Publishing Protocol, signaling the requirement for an Atom > > extension (whether blessed by IETF or not) to be present in accepted > > content [1]. To illustrate the requirement by example, one would see: > > > > application/atom+xml;type=entry;extension=token > > > > 2. Establishing an expectation on an Atom processor for the media type > > of a linked resource, e.g., whether the representation in-lines a > > complete hierarchy of Atom entries and feeds [2]. Once again to > > illustrate the requirement by example, one would see: > > > > > type="application/atom+xml;type=feed;inline-depth=1" href="children"/> > > > > Of these cases, a really strong case can be made for the first > > requirement to use a media type parameter, since it has to happen in > > the absence of the actual Atom document. There is only one > > must-understand signaling mechanism in AtomPub and that is app:accept. > > If a media type parameter is used in app:accept that cannot be > > understood by its receiver, the receiver has no choice but to cease > > communications with the server. Since almost every AtomPub-style "API" > > introduces its own set of requirements for what constitutes an entry > > the server is willing to accept. > > > > For example, Google Finance API in its protocol reference states that > > an entry posted as a new portfolio must include a "gf:portfolioData" > > element inside an atom:entry [3]. CMIS servers may require the > > presence of a type identifier as extended entry metadata in order to > > accept an entry posted to a collection [4]. > > > > It seems quite reasonable to establish a single media type parameter > > and allow every such API to define their own acceptable values for > > this purpose. This approach provides fair warning and enables AtomPub > > niches to legally exist, and even interoperate. > > > > The second case can probably benefit from a media type parameter, but > > it is not clear what the semantics of that parameter would be. > > Specifically: > > > > 1. Do Atom processors fail if, when processing Content-Type header, > > they encounter a media type parameter they don't know about or a > > value in a known media type parameter that they don't understand. > > 2. Does introduction of media type parameters for > > application/atom+xml require standards track RFC? > > > > > > Nikunj > > http://o-micron.blogspot.com > > > > [1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html > > [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html > > [3] > http://code.google.com/apis/finance/developers_guide_protocol.html#CreatingPortfolios > > [4] http://www.oasis-open.org/committees/download.php/32668 > > > From owner-atom-syntax@mail.imc.org Wed Jun 10 11:51:25 2009 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 73A063A69A1 for ; Wed, 10 Jun 2009 11:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 IOMa3n1+Ea1d for ; Wed, 10 Jun 2009 11:51:19 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 107E63A6824 for ; Wed, 10 Jun 2009 11:51:18 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AITYQJ060207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 11:29:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AITYBO060206; Wed, 10 Jun 2009 11:29: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 e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AITNCs060184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 11:29:33 -0700 (MST) (envelope-from albertcbrown@us.ibm.com) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e34.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5AIQNVU008294 for ; Wed, 10 Jun 2009 12:26:23 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5AITLDK183848 for ; Wed, 10 Jun 2009 12:29:21 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5AITLkC024139 for ; Wed, 10 Jun 2009 12:29:21 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n5AITKqM024134; Wed, 10 Jun 2009 12:29:20 -0600 In-Reply-To: <1191335719-1244502830-cardhu_decombobulator_blackberry.rim.net-151986016-@bxe1007.bisx.prod.on.blackberry> References: <4A2D8D62.60007@gmail.com> <1191335719-1244502830-cardhu_decombobulator_blackberry.rim.net-151986016-@bxe1007.bisx.prod.on.blackberry> Subject: Re: Atompub Features Draft Dead for Good? X-KeepSent: 7740DC55:4F1B3DC6-882575D1:0064D9B8; type=4; name=$KeepSent To: jasnell@gmail.com Cc: "atom-syntax" , owner-atom-syntax@mail.imc.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: Al Brown Date: Wed, 10 Jun 2009 11:29:10 -0700 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Build V851_04282009|April 28, 2009) at 06/10/2009 12:29:20 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBFF42DFF75F288f9e8a93df938690918c07BBFF42DFF75F28" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0__=07BBFF42DFF75F288f9e8a93df938690918c07BBFF42DFF75F28 Content-type: multipart/alternative; Boundary="1__=07BBFF42DFF75F288f9e8a93df938690918c07BBFF42DFF75F28" --1__=07BBFF42DFF75F288f9e8a93df938690918c07BBFF42DFF75F28 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable If it made sense for CMIS to use it, then yes. Especially if it become= s the best practice to advertise an atom extension. It would be helpful if the feature markup included a way to specify an = URI to get the feature-specific info such as the block below. That would h= elp make the service document easier to produce and the client can request = the feature-specific block if desired. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of th= e person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please noti= fy the sender. Please also permanently delete all copies of the original message and any attached documentation. = From: jasnell@gmail.com = = To: Al Brown/Costa Mesa/IBM@IBMUS = = Cc: "atom-syntax" , owner-atom-syntax@ma= il.imc.org = Date: 06/08/2009 04:36 PM = = Subject: Re: Atompub Features Draft Dead for Good? = = Ok this is good to see. The main question is whether there is sufficien= t reason to define a generic features/capabilities extension. There certa= inly are good arguments in favor. If a generic ext was available would cmis = use it? Sent from my Verizon Wireless BlackBerry From: Al Brown Date: Mon, 8 Jun 2009 16:04:50 -0700 To: James M Snell Subject: Re: Atompub Features Draft Dead for Good? CMIS adds CMIS element to the workspace element in the atompub service document. I am not aware of requirements from CMIS for representing features at the collection level. FYI - Here's an example of the features/capabilities CMIS advertises in= the atompub workspace element: repid1 Repository1 self CMIS Repository Description CMIS Vendor 1 CMIS Prototype for VendorX 0.61 rootfolder true true true true true true bothcombined innerandouter all document folder true 0.61 -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of th= e person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please noti= fy the sender. Please also permanently delete all copies of the original message and any attached documentation. Inactive hide details for James M Snell ---06/08/2009 03:36:36 PM---Ok,= so we'd made quite a bit of progress on the Atom featurJames M Snell ---06/08/2009 03:36:36 PM---Ok, so we'd made quite a bit of progress on= the Atom features draft a = = From: James M Snell = = = To: atom-syntax = = = Date: 06/08/2009 03:36 PM = = = Subject: Atompub Features Draft Dead for Good? = = Ok, so we'd made quite a bit of progress on the Atom features draft a while back and then I decided to sit and watch to see if there was a strong enough need for the extensions. At this point, I have not seen anyone jumping up and down demanding the functionality provided by the Features draft so I'm wondering if I should just consider it Dead for Good. Thoughts? = --1__=07BBFF42DFF75F288f9e8a93df938690918c07BBFF42DFF75F28 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable If it made sense for CMIS to use it, then yes. Especially if it bec= omes the best practice to advertise an atom extension. It would be helpful if the feature markup included a way to specify an = URI to get the feature-specific info such as the block below. That wou= ld help make the service document easier to produce and the client can = request the feature-specific block if desired. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: ht= tps://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. jasnell---06/08/2009= 04:36:36 PM---Ok this is good to see. The main question is whether the= re is sufficient reason to define a generic features/capabilities exten= = <= /tr> From: = jasnell@gmail.com To: Al Brown/Costa Mesa/IBM@IBMUS Cc: "atom-syntax" <atom-syntax@imc.org>, o= wner-atom-syntax@mail.imc.org Date: = 06/08/2009 04:36 PM Subject: Re: Atompub Features Draft Dead for Good? Ok this is good to see. The main question is whether t= here is sufficient reason to define a generic features/capabilities ext= ension. There certainly are good arguments in favor. If a generic ext w= as available would cmis use it? Sent from my Verizon Wireless BlackBerry Fro= m: Al Brown = Date: Mon, 8 Jun 2009 16:04:50 -0700= To: James M Snell<jasnell@gmail.com><= /font> Subject: Re: Atompub Features Draft Dead fo= r Good? CMIS adds CMIS element to the workspace element in = the atompub service document. I am not aware of requirements from CMIS = for representing features at the collection level. FYI - Here's an example of the features/capabilities CMIS advertises in= the atompub workspace element: <ns5:= repositoryInfo> <ns1:= repositoryId>repid1</ns1:repositoryId= > <ns1:= repositoryName>Repository1</<= font size=3D"4" color=3D"#3F8080" face=3D"Courier New">ns1:repositoryNa= me> <ns1:= repositoryRelationship>self</= ns1:repositoryR= elationship> <ns1:= repositoryDescription>CMIS Repo= sitory Description</ns1:repositoryDescription> <ns1:= vendorNameCMIS Vendor 1= </ns1:vendorName> <ns1:= productName>CMIS Prototype for = VendorX&= lt;/ns1:= productName> <ns1:= productVersion>0.61</ns1:productVersion> <ns1:= rootFolderId>rootfolder</ns1:rootFold= erId>= <ns1:= capabilities> <ns1:= capabilityMultifiling>true</<= font size=3D"4" color=3D"#3F8080" face=3D"Courier New">ns1:capabilityMu= ltifiling> <ns1:= capabilityUnfiling>true<= font size=3D"4" color=3D"#008080" face=3D"Courier New"></ns1:capabilityUnfil= ing><= br> <ns1:= capabilityVersionSpecificFiling>true<= ;/ns1:ca= pabilityVersionSpecificFiling> <ns1:= capabilityPWCUpdateable>true</= ns1:capabilityP= WCUpdateable> <ns1:= capabilityPWCSearchable>true</= ns1:capabilityP= WCSearchable> <ns1:= capabilityAllVersionsSearchable>true<= ;/ns1:ca= pabilityAllVersionsSearchable> <ns1:= capabilityQuery>bothcombined= <= /ns1:cap= abilityQuery> <ns1:= capabilityJoin>innerandouter= <= /ns1:cap= abilityJoin> <ns1:= capabilityChanges>all</ns1:capabilityChanges= > = <ns1:= capabilityChangesOnType>document= </ns1:capabil= ityChangesOnType> <ns1:= capabilityChangesOnType>folder</ns1:capabilit= yChangesOnType> <ns1:= changesIncomplete>true</ns1:changesIncomplet= e> </ns1= :capabilities> <ns1:= cmisVersionSupported>0.61</ns1:cmisVersionSu= pported&= gt; </ns5= :repositoryInfo> -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki0= 7/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.= ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. James M Snell -= --06/08/2009 03:36:36 PM---Ok, so we'd made quite a bit of progress on = the Atom features draft a = From: James M Snell <jasnell@gmail.com> To: atom-syntax <atom-syntax@imc.org> Date: 06/08/2009 03:36 PM Subject: Atompub Features Draft Dead for Good? <= br> Ok, so we'd made quite a bit of progress on the Atom features draft a <= br> while back and then I decided to sit and watch to see if there was a strong enough need for the extensions. At this point, I have not seen <= br> anyone jumping up and down demanding the functionality provided by the = Features draft so I'm wondering if I should just consider it Dead for <= br> Good. Thoughts? = --1__=07BBFF42DFF75F288f9e8a93df938690918c07BBFF42DFF75F28-- --0__=07BBFF42DFF75F288f9e8a93df938690918c07BBFF42DFF75F28 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBFF42DFF75F288f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBFF42DFF75F288f9e8a93df938690918c07BBFF42DFF75F28 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=07BBFF42DFF75F288f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBFF42DFF75F288f9e8a93df938690918c07BBFF42DFF75F28-- From owner-atom-syntax@mail.imc.org Wed Jun 10 12:02:13 2009 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 6F7283A691A for ; Wed, 10 Jun 2009 12:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 FiujfkiaQp1G for ; Wed, 10 Jun 2009 12:02:08 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 492363A6B22 for ; Wed, 10 Jun 2009 12:02:01 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIm6OU061223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 11:48:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AIm6qp061222; Wed, 10 Jun 2009 11:48: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 rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIm5dV061216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 11:48:05 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AImvZa011649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Jun 2009 18:48:58 GMT Received: from abhmt002.oracle.com (abhmt002.oracle.com [141.146.116.11]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AIn9qE021768; Wed, 10 Jun 2009 18:49:09 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Jun 2009 11:47:59 -0700 Cc: Al Brown , atom-syntax Syntax Message-Id: <24F022A7-2BBA-4C00-846C-34AECADABB87@oracle.com> From: "Nikunj R. Mehta" To: James M Snell In-Reply-To: <4A2FFDAF.2070404@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Sub-typing Atom documents Date: Wed, 10 Jun 2009 11:46:38 -0700 References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2EE11F.2080809@gmail.com> <4A2FFDAF.2070404@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt002.oracle.com [141.146.116.11] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4A2FFFE0.0001:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 10, 2009, at 11:38 AM, James M Snell wrote: >> >> I also thought the media type parameter inline-depth as useful and >> that would be nice to have specified as part of the inline I-D. >> > -1... incorporating something like inline-depth=1 into the media > type would not be a good thing. The media type is intended to > describe the kind of document that's being passed around and not > specific details about the documents construction. This reasoning is not very useful really. > When I say something like "application/atom > +xml;type=entry;profile=tree", what I'm saying is that the document > is potentially a hierarchical Atom entry but in order to determine > anything more about the document I have to retrieve and examine it > directly. > Just like type=entry says that the document contains a single Atom entry element, and profile=cmis1.0 says that the element has certain extensions, inline-depth=1 could say that the extension uses link in- lining to a certain depth. The problem really is that the meaning of inline-depth is not well- defined. From owner-atom-syntax@mail.imc.org Wed Jun 10 12:04:42 2009 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 3495B3A692C for ; Wed, 10 Jun 2009 12:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=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 ehGURL7Ji1aB for ; Wed, 10 Jun 2009 12:04:41 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1FB593A691A for ; Wed, 10 Jun 2009 12:04:40 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIqTSG061439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 11:52:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AIqTNO061438; Wed, 10 Jun 2009 11:52:29 -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-px0-f188.google.com (mail-px0-f188.google.com [209.85.216.188]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIqIY8061429 for ; Wed, 10 Jun 2009 11:52:28 -0700 (MST) (envelope-from mart@degeneration.co.uk) Received: by pxi26 with SMTP id 26so877998pxi.16 for ; Wed, 10 Jun 2009 11:52:17 -0700 (PDT) Received: by 10.114.124.1 with SMTP id w1mr2498631wac.136.1244659937686; Wed, 10 Jun 2009 11:52:17 -0700 (PDT) Received: from ?192.168.64.79? ([204.9.180.30]) by mx.google.com with ESMTPS id l28sm9604822waf.19.2009.06.10.11.52.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 11:52:16 -0700 (PDT) Message-ID: <4A3000DF.9050604@degeneration.co.uk> Date: Wed, 10 Jun 2009 11:52:15 -0700 From: Martin Atkins Reply-To: atom-syntax Syntax User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: atom-syntax Syntax Subject: Re: Fwd: New Version Notification for draft-mehta-atom-inline-00 References: <20090609233744.9A64B3A6A48@core3.amsl.com> <6B1A1BB7-5698-4852-8DE6-F2A06691624B@oracle.com> In-Reply-To: <6B1A1BB7-5698-4852-8DE6-F2A06691624B@oracle.com> 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: Nikunj R. Mehta wrote: > Based on feedback, I have split out the in-lining spec in to its own I-D. > > HTML: http://tools.ietf.org/html/draft-mehta-atom-inline-00 > Text: http://tools.ietf.org/id/draft-mehta-atom-inline-00.txt > > I > am also tracking open issues about this I-D publicly at http://code.google.com/p/atom-ext/issues/list. > The source for this I-D is also available, if you are interested. > > Looking forward to comments on the I-D. > Is it actually necessary to support inlining of resources other than atom feeds and entries? It seems like this adds considerable complexity where I'm not sure that there are compelling use-cases. Given how little success there has been with the complex content model of the atom:content element in practice, it'd be my preference to avoid over-thinking this and address only the specific use-case of referencing other items that are themselves expressed as Atom. In particular, I'm unsure as to what the meaning would be of the following: Blah blah blah Is the text inside considered to be an alternate representation of this resource? Should the content actually be the entity-encoded XML? Is this invalid? The current draft seems to have no comment on the matter. Restricting the problem to only inline feeds and entries also theoretically allows the ah:inline element to be removed and the atom:feed or atom:entry element given as a direct child of atom:link, with the name of the element telling the processor whether it's a feed or entry without the redundancy inherent in the ah:inline type attribute. From owner-atom-syntax@mail.imc.org Wed Jun 10 12:07:10 2009 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 833A63A6855 for ; Wed, 10 Jun 2009 12:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.038 X-Spam-Level: X-Spam-Status: No, score=-3.038 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 Tk+PgUkJvD0x for ; Wed, 10 Jun 2009 12:07:03 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E52523A68C3 for ; Wed, 10 Jun 2009 12:07:02 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIsg4w061512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 11:54:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AIsgkk061511; Wed, 10 Jun 2009 11:54:42 -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 e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIsfEm061505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 11:54:41 -0700 (MST) (envelope-from albertcbrown@us.ibm.com) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5AIrHLP029979 for ; Wed, 10 Jun 2009 12:53:17 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5AIscfO257316 for ; Wed, 10 Jun 2009 12:54:39 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5AIsbS1019455 for ; Wed, 10 Jun 2009 12:54:37 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n5AIsbNd019441; Wed, 10 Jun 2009 12:54:37 -0600 In-Reply-To: <62E5FD4C-D6D7-4A7A-8918-0DDA48D10495@oracle.com> References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2EE11F.2080809@gmail.com> <62E5FD4C-D6D7-4A7A-8918-0DDA48D10495@oracle.com> Subject: Re: Sub-typing Atom documents X-KeepSent: D4A242C0:D5BD005A-882575D1:00668922; type=4; name=$KeepSent To: "Nikunj R. Mehta" Cc: atom-syntax Syntax , James M Snell X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: Al Brown Date: Wed, 10 Jun 2009 11:54:26 -0700 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Build V851_04282009|April 28, 2009) at 06/10/2009 12:54:36 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBFF42DFF50FB28f9e8a93df938690918c07BBFF42DFF50FB2" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0__=07BBFF42DFF50FB28f9e8a93df938690918c07BBFF42DFF50FB2 Content-type: multipart/alternative; Boundary="1__=07BBFF42DFF50FB28f9e8a93df938690918c07BBFF42DFF50FB2" --1__=07BBFF42DFF50FB28f9e8a93df938690918c07BBFF42DFF50FB2 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Great reference. That's an issue oracle filed recently. The first bul= let in #259 is precisely the reason why we need to have either a media type= parameter (media type signals tree or flat) or down-tree link relation.= I do not believe those questions need to be answered to signal that the= atom document referenced by a link element contains inline (hierarchy) = or not.. If the inline I-D does not address that bullet in some way, I would pre= fer not to have the inline I-D so CMIS can provide a extension-specific solution until the new atom wg (if formed) comes up with a new specification that addresses hierarchy. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of th= e person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please noti= fy the sender. Please also permanently delete all copies of the original message and any attached documentation. = From: "Nikunj R. Mehta" = = To: Al Brown/Costa Mesa/IBM@IBMUS = = Cc: James M Snell , atom-syntax Syntax = Date: 06/10/2009 11:20 AM = = Subject: Re: Sub-typing Atom documents = = I find it difficult to incorporate the specification of a media type parameter to specify inline depth in the absence of a specific proposal= for how to construct deeply nested hierarchy in the face of up and down lin= ks as well as multi-parents. It only makes sense to specify the media type parameter once a specific= meaning or a value space can be defined. I am not sure a viable proposa= l exists (partly because of questions such as those raised in [1]), but I= 'd be happy to work with anyone's proposal that addresses this concern. Nikunj http://o-micron.blogspot.com [1] http://tools.oasis-open.org/issues/browse/CMIS-259 On Jun 10, 2009, at 10:59 AM, Al Brown wrote: It would be useful to have more than one profile such that cmis += inline may be specified. Also, will you include initial values fo= r the profile type or should that be part of CMIS and the inline I-= D? Can we have specify language similar to how link relations are specified? Ie, there is a registry of names in a default namespac= e. Extensions are then free to register their name or use a fully-qualified URI. One added benefit of this is there will be a= central registry of atom extensions, at least the ones that took = the time to register them. I also thought the media type parameter inline-depth as useful an= d that would be nice to have specified as part of the inline I-D. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/= Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use= of the person or entity to whom the message was addressed. If you ar= e not the intended recipient of this message, please be advised tha= t any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete a= ll copies of the original message and any attached documentation. James M Snell ---06/09/2009 03:46:22 PM---I've alrea= dy started working up an I-D for a new profile media type = = From: James M Snell = = = To: "Nikunj R. Mehta" = = = Cc: atom-syntax Syntax = = = Date: 06/09/2009 03:46 PM = = = Subject: Re: Sub-typing Atom documents = = I've already started working up an I-D for a new profile media ty= pe parameter. I should be able to get it published by tomorrow end-of-day Example: application/atom+xml;profile=3D"http://example.org/profile/foo" The profile parameter value is a URI that identifies a logical profile to which the Atom document conforms. Only a single profile value = is allowed for now. - James Nikunj R. Mehta wrote: > Several recent discussions suggest the need for sub-typing Atom= > documents. There are two major requirements for sub-typing Atom= documents: > > 1. In Atom Publishing Protocol, signaling the requirement for a= n Atom > extension (whether blessed by IETF or not) to be present in accepted > content [1]. To illustrate the requirement by example, one woul= d see: > > application/atom +xml;type=3Dentry;extension=3Dtoken > > 2. Establishing an expectation on an Atom processor for the med= ia type > of a linked resource, e.g., whether the representation in-lines= a > complete hierarchy of Atom entries and feeds [2]. Once again to= > illustrate the requirement by example, one would see: > > type=3D"application/atom+xml;type=3Dfeed;inline-depth=3D1" href=3D"children"/> > > Of these cases, a really strong case can be made for the first > requirement to use a media type parameter, since it has to happ= en in > the absence of the actual Atom document. There is only one > must-understand signaling mechanism in AtomPub and that is app:accept. > If a media type parameter is used in app:accept that cannot be > understood by its receiver, the receiver has no choice but to c= ease > communications with the server. Since almost every AtomPub-styl= e "API" > introduces its own set of requirements for what constitutes an entry > the server is willing to accept. > > For example, Google Finance API in its protocol reference state= s that > an entry posted as a new portfolio must include a "gf:portfolioData" > element inside an atom:entry [3]. CMIS servers may require the > presence of a type identifier as extended entry metadata in ord= er to > accept an entry posted to a collection [4]. > > It seems quite reasonable to establish a single media type parameter > and allow every such API to define their own acceptable values = for > this purpose. This approach provides fair warning and enables AtomPub > niches to legally exist, and even interoperate. > > The second case can probably benefit from a media type paramete= r, but > it is not clear what the semantics of that parameter would be. > Specifically: > > 1. Do Atom processors fail if, when processing Content-Type header, > they encounter a media type parameter they don't know abo= ut or a > value in a known media type parameter that they don't understand. > 2. Does introduction of media type parameters for > application/atom+xml require standards track RFC? > > > Nikunj > http://o-micron.blogspot.com > > [1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html= > [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html > [3] http://code.google.com/apis/finance/developers_guide_protocol.htm= l#CreatingPortfolios > [4] http://www.oasis-open.org/committees/download.php/32668 = --1__=07BBFF42DFF50FB28f9e8a93df938690918c07BBFF42DFF50FB2 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable Great reference. That's an issue oracle filed recently. The first = bullet in #259 is precisely the reason why we need to have either a med= ia type parameter (media type signals tree or flat) or down-tree link r= elation. I do not believe those questions need to be answered to signal that the= atom document referenced by a link element contains inline (hierarchy)= or not.. If the inline I-D does not address that bullet in some way, I would pre= fer not to have the inline I-D so CMIS can provide a extension-specific= solution until the new atom wg (if formed) comes up with a new specifi= cation that addresses hierarchy. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: ht= tps://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. "Niku= nj R. Mehta" ---06/10/2009 11:20:26 AM---I find it difficult to in= corporate the specification of a media type parameter to specify inline= depth in the absence of a spec = From: = "Nikunj R. Mehta" <nikunj.mehta@oracle.co= m> To: Al Brown/Costa Mesa/IBM@IBMUS Cc: James M Snell <jasnell@gmail.com>, atom-syntax S= yntax <atom-syntax@imc.org> Date: = 06/10/2009 11:20 AM Subject: Re: Sub-typing Atom documents I find it difficult to incorporate the specification o= f a media type parameter to specify inline depth in the absence of a sp= ecific proposal for how to construct deeply nested hierarchy in the fac= e of up and down links as well as multi-parents. It only makes sense to specify the media type paramete= r once a specific meaning or a value space can be defined. I am not sur= e a viable proposal exists (partly because of questions such as those r= aised in [1]), but I'd be happy to work with anyone's proposal that add= resses this concern. Nikunj http://o-micron.blogspot.com [1] http://tools.= oasis-open.org/issues/browse/CMIS-259 <= /font> On Jun 10, 2009, at 10:59 AM, Al Brown wrote: It would be useful to have more than one profile s= uch that cmis + inline may be specified. Also, will you include initial= values for the profile type or should that be part of CMIS and the inl= ine I-D? Can we have specify language similar to how link relations are specifie= d? Ie, there is a registry of names in a default namespace. Extensions = are then free to register their name or use a fully-qualified URI. One = added benefit of this is there will be a central registry of atom exten= sions, at least the ones that took the time to register them. I also thought the media type parameter inline-depth as useful and that= would be nice to have specified as part of the inline I-D. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki0= 7/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.= ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. <graycol.gif>James M Sn= ell ---06/09/2009 03:46:22 PM---I've already started working up an I-D = for a new profile media type = <ecblank.gif&g= t; From: <ecblank.gif>= James M Snell <jasnell@gmail.com> <ecblank.gif&g= t; To: <ecblank.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.com&g= t; <ecblank.gif&g= t; Cc: <= ;ecblank.gif> atom-syntax Syntax <atom-syntax@imc.org> <ecblank.gif&g= t; Date: <ecblank.gif>= 06/09/2009 03:46 PM <ecblank.gif&g= t; Subject: <ecblank.gif&= gt; Re: Sub-typing Atom documents <= br> I've already started working up an I-D for a new profile media type parameter. I should be able to get it published by tomorrow end-of-day<= br> Example: application/atom+xml;profile=3D"http://= example.org/profile/foo"<= br> The profile parameter value is a URI that identifies a logical profile = to which the Atom document conforms. Only a single profile value is allowed for now. - James Nikunj R. Mehta wrote: > Several recent discussions suggest the need for sub-typing Atom > documents. There are two major requirements for sub-typing Atom do= cuments: > > 1. In Atom Publishing Protocol, signaling the requirement for an A= tom > extension (whether blessed by IETF or not) to be present in accept= ed > content [1]. To illustrate the requirement by example, one would s= ee: > > <app:accept>application/atom+xml;type=3Dentry;extension=3Dto= ken</app:accept> > > 2. Establishing an expectation on an Atom processor for the media = type > of a linked resource, e.g., whether the representation in-lines a = > complete hierarchy of Atom entries and feeds [2]. Once again to > illustrate the requirement by example, one would see: > > <atom:link rel=3D"down" > type=3D"application/atom+xml;type=3Dfeed;inline-depth=3D1&quo= t; href=3D"children"/> > > Of these cases, a really strong case can be made for the first > requirement to use a media type parameter, since it has to happen = in > the absence of the actual Atom document. There is only one > must-understand signaling mechanism in AtomPub and that is app:acc= ept. > If a media type parameter is used in app:accept that cannot be > understood by its receiver, the receiver has no choice but to ceas= e > communications with the server. Since almost every AtomPub-style &= quot;API" > introduces its own set of requirements for what constitutes an ent= ry > the server is willing to accept. > > For example, Google Finance API in its protocol reference states t= hat > an entry posted as a new portfolio must include a "gf:portfol= ioData" > element inside an atom:entry [3]. CMIS servers may require the > presence of a type identifier as extended entry metadata in order = to > accept an entry posted to a collection [4]. > > It seems quite reasonable to establish a single media type paramet= er > and allow every such API to define their own acceptable values for= > this purpose. This approach provides fair warning and enable= s AtomPub > niches to legally exist, and even interoperate. > > The second case can probably benefit from a media type parameter, = but > it is not clear what the semantics of that parameter would be. > Specifically: > > 1. Do Atom processors fail if, when processing Conten= t-Type header, > they encounter a media type parameter they do= n't know about or a > value in a known media type parameter that th= ey don't understand. > 2. Does introduction of media type parameters for = > application/atom+xml require standards track = RFC? > > > Nikunj > http://o-micron.blogspot.com > > [1] http://= www.imc.org/atom-protocol/mail-archive/msg11398.html > [2] http://ww= w.imc.org/atom-syntax/mail-archive/msg21114.html > [3] http://code.google.com/apis/finance/developers_guide= _protocol.html#CreatingPortfolios > [4] http://www.= oasis-open.org/committees/download.php/32668 = --1__=07BBFF42DFF50FB28f9e8a93df938690918c07BBFF42DFF50FB2-- --0__=07BBFF42DFF50FB28f9e8a93df938690918c07BBFF42DFF50FB2 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBFF42DFF50FB28f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBFF42DFF50FB28f9e8a93df938690918c07BBFF42DFF50FB2 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=07BBFF42DFF50FB28f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBFF42DFF50FB28f9e8a93df938690918c07BBFF42DFF50FB2-- From owner-atom-syntax@mail.imc.org Wed Jun 10 12:12:37 2009 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 F29743A6B26 for ; Wed, 10 Jun 2009 12:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.063 X-Spam-Level: X-Spam-Status: No, score=-3.063 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 FV5pyk-bk0ks for ; Wed, 10 Jun 2009 12:12:31 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D44ED3A6B22 for ; Wed, 10 Jun 2009 12:12:29 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIwOYt061778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 11:58:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AIwObb061777; Wed, 10 Jun 2009 11:58:24 -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 e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AIwDBZ061760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 11:58:23 -0700 (MST) (envelope-from albertcbrown@us.ibm.com) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e38.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5AItFKY001678 for ; Wed, 10 Jun 2009 12:55:15 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5AIwDUp216324 for ; Wed, 10 Jun 2009 12:58:13 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id n5AIwl1A011726 for ; Wed, 10 Jun 2009 12:58:47 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av06.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id n5AIwlbV011720; Wed, 10 Jun 2009 12:58:47 -0600 In-Reply-To: <4A2FFDAF.2070404@gmail.com> References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2EE11F.2080809@gmail.com> <4A2FFDAF.2070404@gmail.com> Subject: Re: Sub-typing Atom documents X-KeepSent: 123CE68B:8A237759-882575D1:00681A13; type=4; name=$KeepSent To: James M Snell Cc: atom-syntax Syntax , "Nikunj R. Mehta" , owner-atom-syntax@mail.imc.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: Al Brown Date: Wed, 10 Jun 2009 11:58:02 -0700 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Build V851_04282009|April 28, 2009) at 06/10/2009 12:58:12 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBFF42DFFB9C838f9e8a93df938690918c07BBFF42DFFB9C83" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0__=07BBFF42DFFB9C838f9e8a93df938690918c07BBFF42DFFB9C83 Content-type: multipart/alternative; Boundary="1__=07BBFF42DFFB9C838f9e8a93df938690918c07BBFF42DFFB9C83" --1__=07BBFF42DFFB9C838f9e8a93df938690918c07BBFF42DFFB9C83 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable >-1... incorporating something like inline-depth=3D1 into the media typ= e >would not be a good thing. The media type is intended to describe the >kind of document that's being passed around and not specific details >about the documents construction. When I say something like >"application/atom+xml;type=3Dentry;profile=3Dtree", what I'm saying is= that >the document is potentially a hierarchical Atom entry but in order to >determine anything more about the document I have to retrieve and >examine it directly. It would be useful to convey depth. However, signaling the linked reso= urce contains inline markup is sufficient. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of th= e person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please noti= fy the sender. Please also permanently delete all copies of the original message and any attached documentation. = From: James M Snell = = To: Al Brown/Costa Mesa/IBM@IBMUS = = Cc: atom-syntax Syntax , "Nikunj R. Meht= a" , owner-atom-syntax@mail.imc.org = = Date: 06/10/2009 11:40 AM = = Subject: Re: Sub-typing Atom documents = = Al Brown wrote: > > It would be useful to have more than one profile such that cmis + > inline may be specified. Also, will you include initial values for th= e > profile type or should that be part of CMIS and the inline I-D? > More than one profile value is definitely possible. > > Can we have specify language similar to how link relations are > specified? Ie, there is a registry of names in a default namespace. > Extensions are then free to register their name or use a > fully-qualified URI. One added benefit of this is there will be a > central registry of atom extensions, at least the ones that took the > time to register them. > Again, also a strong possibility if and only if there is consensus that= a central registry would be beneficial. > > I also thought the media type parameter inline-depth as useful and > that would be nice to have specified as part of the inline I-D. > -1... incorporating something like inline-depth=3D1 into the media type= would not be a good thing. The media type is intended to describe the kind of document that's being passed around and not specific details about the documents construction. When I say something like "application/atom+xml;type=3Dentry;profile=3Dtree", what I'm saying is = that the document is potentially a hierarchical Atom entry but in order to determine anything more about the document I have to retrieve and examine it directly. > > -Al > > Al Brown > Emerging Standards and Industry Frameworks > CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home > Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home= > > Office 714 327 3453 > Mobile 714 263 6441 > Email albertcbrown@us.ibm.com > CONFIDENTIAL NOTICE: The contents of this message, including any > attachments, are confidential and are intended solely for the use of > the person or entity to whom the message was addressed. If you are no= t > the intended recipient of this message, please be advised that any > dissemination, distribution, or use of the contents of this message i= s > strictly prohibited. If you received this message in error, please > notify the sender. Please also permanently delete all copies of the > original message and any attached documentation. > > Inactive hide details for James M Snell ---06/09/2009 03:46:22 > PM---I've already started working up an I-D for a new profile meJames= > M Snell ---06/09/2009 03:46:22 PM---I've already started working up a= n > I-D for a new profile media type > > > From: > James M Snell > > To: > "Nikunj R. Mehta" > > Cc: > atom-syntax Syntax > > Date: > 06/09/2009 03:46 PM > > Subject: > Re: Sub-typing Atom documents > > ---------------------------------------------------------------------= --- > > > > > I've already started working up an I-D for a new profile media type > parameter. I should be able to get it published by tomorrow end-of-da= y > > Example: > > application/atom+xml;profile=3D"http://example.org/profile/foo" > > The profile parameter value is a URI that identifies a logical profil= e > to which the Atom document conforms. Only a single profile value is > allowed for now. > > - James > > Nikunj R. Mehta wrote: > > Several recent discussions suggest the need for sub-typing Atom > > documents. There are two major requirements for sub-typing Atom > documents: > > > > 1. In Atom Publishing Protocol, signaling the requirement for an At= om > > extension (whether blessed by IETF or not) to be present in accepte= d > > content [1]. To illustrate the requirement by example, one would se= e: > > > > application/atom +xml;type=3Dentry;extension=3Dtoken > > > > 2. Establishing an expectation on an Atom processor for the media t= ype > > of a linked resource, e.g., whether the representation in-lines a > > complete hierarchy of Atom entries and feeds [2]. Once again to > > illustrate the requirement by example, one would see: > > > > > type=3D"application/atom+xml;type=3Dfeed;inline-depth=3D1" href=3D"= children"/> > > > > Of these cases, a really strong case can be made for the first > > requirement to use a media type parameter, since it has to happen i= n > > the absence of the actual Atom document. There is only one > > must-understand signaling mechanism in AtomPub and that is app:acce= pt. > > If a media type parameter is used in app:accept that cannot be > > understood by its receiver, the receiver has no choice but to cease= > > communications with the server. Since almost every AtomPub-style "A= PI" > > introduces its own set of requirements for what constitutes an entr= y > > the server is willing to accept. > > > > For example, Google Finance API in its protocol reference states th= at > > an entry posted as a new portfolio must include a "gf:portfolioData= " > > element inside an atom:entry [3]. CMIS servers may require the > > presence of a type identifier as extended entry metadata in order t= o > > accept an entry posted to a collection [4]. > > > > It seems quite reasonable to establish a single media type paramete= r > > and allow every such API to define their own acceptable values for > > this purpose. This approach provides fair warning and enables Atom= Pub > > niches to legally exist, and even interoperate. > > > > The second case can probably benefit from a media type parameter, b= ut > > it is not clear what the semantics of that parameter would be. > > Specifically: > > > > 1. Do Atom processors fail if, when processing Content-Type head= er, > > they encounter a media type parameter they don't know about o= r a > > value in a known media type parameter that they don't underst= and. > > 2. Does introduction of media type parameters for > > application/atom+xml require standards track RFC? > > > > > > Nikunj > > http://o-micron.blogspot.com > > > > [1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html > > [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html > > [3] > http://code.google.com/apis/finance/developers_guide_protocol.html#Crea= tingPortfolios > > [4] http://www.oasis-open.org/committees/download.php/32668 > > > = --1__=07BBFF42DFFB9C838f9e8a93df938690918c07BBFF42DFFB9C83 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable >-1... incorporating something like inline-depth=3D1 into the= media type >would not be a good thing. The media type is intended to describe t= he >kind of document that's being passed around and not specific detail= s >about the documents construction. When I say something like >"application/atom+xml;type=3Dentry;profile=3Dtree", what = I'm saying is that >the document is potentially a hierarchical Atom entry but in order = to >determine anything more about the document I have to retrieve and <= br> >examine it directly. It would be useful to convey depth. However, signaling the linked reso= urce contains inline markup is sufficient. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: ht= tps://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. James M Snell ---06/10/2009 11:40:40 AM---Al Brown wrote:= = From: = James M Snell <jasnell@gmail.com> To: Al Brown/Costa Mesa/IBM@IBMUS Cc: atom-syntax Syntax <atom-syntax@imc.org>, "= Nikunj R. Mehta" <nikunj.mehta@oracle.com>, owner-atom-synta= x@mail.imc.org Date: = 06/10/2009 11:40 AM Subject: Re: Sub-typing Atom documents Al Brown wrote: > > It would be useful to have more than one profile such that cmis + = > inline may be specified. Also, will you include initial values for= the > profile type or should that be part of CMIS and the inline I-D? > More than one profile value is definitely possible. > > Can we have specify language similar to how link relations are > specified? Ie, there is a registry of names in a default namespace= . > Extensions are then free to register their name or use a > fully-qualified URI. One added benefit of this is there will be a = > central registry of atom extensions, at least the ones that took t= he > time to register them. > Again, also a strong possibility if and only if there is consensus that= a central registry would be beneficial. > > I also thought the media type parameter inline-depth as useful and= > that would be nice to have specified as part of the inline I-D. > -1... incorporating something like inline-depth=3D1 into the media type= would not be a good thing. The media type is intended to describe the <= br> kind of document that's being passed around and not specific details about the documents construction. When I say something like "application/atom+xml;type=3Dentry;profile=3Dtree", what I'm = saying is that the document is potentially a hierarchical Atom entry but in order to <= br> determine anything more about the document I have to retrieve and examine it directly. > > -Al > > Al Brown > Emerging Standards and Industry Frameworks > CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home= > Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Ho= me > > Office 714 327 3453 > Mobile 714 263 6441 > Email albertcbrown@us.ibm.com > CONFIDENTIAL NOTICE: The contents of this message, including any <= br> > attachments, are confidential and are intended solely for the use = of > the person or entity to whom the message was addressed. If you are= not > the intended recipient of this message, please be advised that any= > dissemination, distribution, or use of the contents of this messag= e is > strictly prohibited. If you received this message in error, please= > notify the sender. Please also permanently delete all copies of th= e > original message and any attached documentation. > > Inactive hide details for James M Snell ---06/09/2009 03:46:22 > PM---I've already started working up an I-D for a new profile meJa= mes > M Snell ---06/09/2009 03:46:22 PM---I've already started working u= p an > I-D for a new profile media type > > > From: > James M Snell <jasnell@gmail.com> > > To: > "Nikunj R. Mehta" <nikunj.mehta@oracle.com> > > Cc: > atom-syntax Syntax <atom-syntax@imc.org> > > Date: > 06/09/2009 03:46 PM > > Subject: > Re: Sub-typing Atom documents > > ------------------------------------------------------------------= ------ > > > > > I've already started working up an I-D for a new profile media typ= e > parameter. I should be able to get it published by tomorrow end-of= -day > > Example: > > application/atom+xml;profile=3D"http://example.org/profile/foo" > > The profile parameter value is a URI that identifies a logical pro= file > to which the Atom document conforms. Only a single profile value i= s > allowed for now. > > - James > > Nikunj R. Mehta wrote: > > Several recent discussions suggest the need for sub-typing At= om > > documents. There are two major requirements for sub-typing At= om > documents: > > > > 1. In Atom Publishing Protocol, signaling the requirement for= an Atom > > extension (whether blessed by IETF or not) to be present in a= ccepted > > content [1]. To illustrate the requirement by example, one wo= uld see: > > > > <app:accept>application/atom+xml;type=3Dentry;extension= =3Dtoken</app:accept> > > > > 2. Establishing an expectation on an Atom processor for the m= edia type > > of a linked resource, e.g., whether the representation in-lin= es a > > complete hierarchy of Atom entries and feeds [2]. Once again = to > > illustrate the requirement by example, one would see: > > > > <atom:link rel=3D"down" > > type=3D"application/atom+xml;type=3Dfeed;inline-depth=3D= 1" href=3D"children"/> > > > > Of these cases, a really strong case can be made for the firs= t > > requirement to use a media type parameter, since it has to ha= ppen in > > the absence of the actual Atom document. There is only one > > must-understand signaling mechanism in AtomPub and that is ap= p:accept. > > If a media type parameter is used in app:accept that cannot b= e > > understood by its receiver, the receiver has no choice but to= cease > > communications with the server. Since almost every AtomPub-st= yle "API" > > introduces its own set of requirements for what constitutes a= n entry > > the server is willing to accept. > > > > For example, Google Finance API in its protocol reference sta= tes that > > an entry posted as a new portfolio must include a "gf:po= rtfolioData" > > element inside an atom:entry [3]. CMIS servers may require th= e > > presence of a type identifier as extended entry metadata in o= rder to > > accept an entry posted to a collection [4]. > > > > It seems quite reasonable to establish a single media type pa= rameter > > and allow every such API to define their own acceptable value= s for > > this purpose. This approach provides fair warning and e= nables AtomPub > > niches to legally exist, and even interoperate. > > > > The second case can probably benefit from a media type parame= ter, but > > it is not clear what the semantics of that parameter would be= . > > Specifically: > > > > 1. Do Atom processors fail if, when processing C= ontent-Type header, > > they encounter a media type parameter th= ey don't know about or a > > value in a known media type parameter th= at they don't understand. > > 2. Does introduction of media type parameters fo= r > > application/atom+xml require standards t= rack RFC? > > > > > > Nikunj > > http://o-mi= cron.blogspot.com > > > > [1] http://www.imc.org/atom-protocol/mail-archive/m= sg11398.html > > [2] http://www.imc.org/atom-syntax/mail-archive/msg21= 114.html > > [3] > http://code.google.com/apis/fi= nance/developers_guide_protocol.html#CreatingPortfolios > > [4] http://www.oasis-open.org/committees/download.php/3= 2668 > > > = --1__=07BBFF42DFFB9C838f9e8a93df938690918c07BBFF42DFFB9C83-- --0__=07BBFF42DFFB9C838f9e8a93df938690918c07BBFF42DFFB9C83 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBFF42DFFB9C838f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBFF42DFFB9C838f9e8a93df938690918c07BBFF42DFFB9C83 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=07BBFF42DFFB9C838f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBFF42DFFB9C838f9e8a93df938690918c07BBFF42DFFB9C83-- From owner-atom-syntax@mail.imc.org Wed Jun 10 12:21:12 2009 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 143F33A68D4 for ; Wed, 10 Jun 2009 12:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.432 X-Spam-Level: X-Spam-Status: No, score=-5.432 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 VoaE8lX5g77m for ; Wed, 10 Jun 2009 12:21:10 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EBA4F3A67B2 for ; Wed, 10 Jun 2009 12:21:08 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AJ6uqG062388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 12:06:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AJ6uSI062387; Wed, 10 Jun 2009 12:06: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 rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AJ6sur062373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 12:06:55 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AJ6Y12016198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Jun 2009 19:06:35 GMT Received: from abhmt009.oracle.com (abhmt009.oracle.com [141.146.116.18]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AJ7tq7000597; Wed, 10 Jun 2009 19:07:55 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Jun 2009 12:06:45 -0700 Cc: atom-syntax Syntax , James M Snell Message-Id: <58999F91-AC03-45CC-B4ED-E84995846C28@oracle.com> From: "Nikunj R. Mehta" To: Al Brown In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-41-65550968 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Sub-typing Atom documents Date: Wed, 10 Jun 2009 12:05:23 -0700 References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2EE11F.2080809@gmail.com> <62E5FD4C-D6D7-4A7A-8918-0DDA48D10495@oracle.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt009.oracle.com [141.146.116.18] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4A300446.0061:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-41-65550968 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 10, 2009, at 11:54 AM, Al Brown wrote: > Great reference. That's an issue oracle filed recently. The first > bullet in #259 is precisely the reason why we need to have either a > media type parameter (media type signals tree or flat) or down-tree > link relation. > > I do not believe those questions need to be answered to signal that > the atom document referenced by a link element contains inline > (hierarchy) or not.. > Signaling the use of in-lining extensions in Content-Type, atom:link@type, and app:accept could be done quite easily with James' proposed I-D. > > If the inline I-D does not address that bullet in some way, I would > prefer not to have the inline I-D so CMIS can provide a extension- > specific solution until the new atom wg (if formed) comes up with a > new specification that addresses hierarchy. > > -Al > > Al Brown > Emerging Standards and Industry Frameworks > CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home > Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home > > Office 714 327 3453 > Mobile 714 263 6441 > Email albertcbrown@us.ibm.com > CONFIDENTIAL NOTICE: The contents of this message, including any > attachments, are confidential and are intended solely for the use of > the person or entity to whom the message was addressed. If you are > not the intended recipient of this message, please be advised that > any dissemination, distribution, or use of the contents of this > message is strictly prohibited. If you received this message in > error, please notify the sender. Please also permanently delete all > copies of the original message and any attached documentation. > > "Nikunj R. Mehta" ---06/10/2009 11:20:26 AM---I find it > difficult to incorporate the specification of a media type parameter > to specify inline depth in the absence of a spec > > > From: > "Nikunj R. Mehta" > > To: > Al Brown/Costa Mesa/IBM@IBMUS > > Cc: > James M Snell , atom-syntax Syntax > > > Date: > 06/10/2009 11:20 AM > > Subject: > Re: Sub-typing Atom documents > > > > I find it difficult to incorporate the specification of a media type > parameter to specify inline depth in the absence of a specific > proposal for how to construct deeply nested hierarchy in the face of > up and down links as well as multi-parents. > > It only makes sense to specify the media type parameter once a > specific meaning or a value space can be defined. I am not sure a > viable proposal exists (partly because of questions such as those > raised in [1]), but I'd be happy to work with anyone's proposal that > addresses this concern. > > Nikunj > http://o-micron.blogspot.com > > [1] http://tools.oasis-open.org/issues/browse/CMIS-259 > > On Jun 10, 2009, at 10:59 AM, Al Brown wrote: > It would be useful to have more than one profile such that cmis + > inline may be specified. Also, will you include initial values for > the profile type or should that be part of CMIS and the inline I-D? > > Can we have specify language similar to how link relations are > specified? Ie, there is a registry of names in a default namespace. > Extensions are then free to register their name or use a fully- > qualified URI. One added benefit of this is there will be a central > registry of atom extensions, at least the ones that took the time to > register them. > > I also thought the media type parameter inline-depth as useful and > that would be nice to have specified as part of the inline I-D. > > -Al > > Al Brown > Emerging Standards and Industry Frameworks > CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home > Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home > > Office 714 327 3453 > Mobile 714 263 6441 > Email albertcbrown@us.ibm.com > CONFIDENTIAL NOTICE: The contents of this message, including any > attachments, are confidential and are intended solely for the use of > the person or entity to whom the message was addressed. If you are > not the intended recipient of this message, please be advised that > any dissemination, distribution, or use of the contents of this > message is strictly prohibited. If you received this message in > error, please notify the sender. Please also permanently delete all > copies of the original message and any attached documentation. > > James M Snell ---06/09/2009 03:46:22 PM---I've already > started working up an I-D for a new profile media type > > From: > James M Snell > > To: > "Nikunj R. Mehta" > > Cc: > atom-syntax Syntax > > Date: > 06/09/2009 03:46 PM > > Subject: > Re: Sub-typing Atom documents > > > > > I've already started working up an I-D for a new profile media type > parameter. I should be able to get it published by tomorrow end-of-day > > Example: > > application/atom+xml;profile="http://example.org/profile/foo" > > The profile parameter value is a URI that identifies a logical profile > to which the Atom document conforms. Only a single profile value is > allowed for now. > > - James > > Nikunj R. Mehta wrote: > > Several recent discussions suggest the need for sub-typing Atom > > documents. There are two major requirements for sub-typing Atom > documents: > > > > 1. In Atom Publishing Protocol, signaling the requirement for an > Atom > > extension (whether blessed by IETF or not) to be present in accepted > > content [1]. To illustrate the requirement by example, one would > see: > > > > application/atom+xml;type=entry;extension=token app:accept> > > > > 2. Establishing an expectation on an Atom processor for the media > type > > of a linked resource, e.g., whether the representation in-lines a > > complete hierarchy of Atom entries and feeds [2]. Once again to > > illustrate the requirement by example, one would see: > > > > > type="application/atom+xml;type=feed;inline-depth=1" > href="children"/> > > > > Of these cases, a really strong case can be made for the first > > requirement to use a media type parameter, since it has to happen in > > the absence of the actual Atom document. There is only one > > must-understand signaling mechanism in AtomPub and that is > app:accept. > > If a media type parameter is used in app:accept that cannot be > > understood by its receiver, the receiver has no choice but to cease > > communications with the server. Since almost every AtomPub-style > "API" > > introduces its own set of requirements for what constitutes an entry > > the server is willing to accept. > > > > For example, Google Finance API in its protocol reference states > that > > an entry posted as a new portfolio must include a "gf:portfolioData" > > element inside an atom:entry [3]. CMIS servers may require the > > presence of a type identifier as extended entry metadata in order to > > accept an entry posted to a collection [4]. > > > > It seems quite reasonable to establish a single media type parameter > > and allow every such API to define their own acceptable values for > > this purpose. This approach provides fair warning and enables > AtomPub > > niches to legally exist, and even interoperate. > > > > The second case can probably benefit from a media type parameter, > but > > it is not clear what the semantics of that parameter would be. > > Specifically: > > > > 1. Do Atom processors fail if, when processing Content-Type > header, > > they encounter a media type parameter they don't know about > or a > > value in a known media type parameter that they don't > understand. > > 2. Does introduction of media type parameters for > > application/atom+xml require standards track RFC? > > > > > > Nikunj > > http://o-micron.blogspot.com > > > > [1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html > > [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html > > [3] http://code.google.com/apis/finance/developers_guide_protocol.html#CreatingPortfolios > > [4] http://www.oasis-open.org/committees/download.php/32668 > > > > --Apple-Mail-41-65550968 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Jun 10, 2009, at = 11:54 AM, Al Brown wrote: Great reference. That's an issue oracle filed = recently. The first bullet in #259 is precisely the reason why we need = to have either a media type parameter (media type signals tree or flat) = or down-tree link relation. I do not believe those questions = need to be answered to signal that the atom document referenced by a = link element contains inline (hierarchy) or = not.. Signaling the use of in-lining = extensions in Content-Type, atom:link@type, and app:accept could be done = quite easily with James' proposed I-D. If the inline I-D does not address that = bullet in some way, I would prefer not to have the inline I-D so CMIS = can provide a extension-specific solution until the new atom wg (if = formed) comes up with a new specification that addresses hierarchy. = -Al Al Brown Emerging Standards and Industry = Frameworks CMIS: https://w3.tap= .ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.i= bm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 = Mobile 714 263 6441 Email albertcbrown@us.ibm.com = CONFIDENTIAL NOTICE: The contents of this message, including any = attachments, are confidential and are intended solely for the use of the = person or entity to whom the message was addressed. If you are not the = intended recipient of this message, please be advised that any = dissemination, distribution, or use of the contents of this message is = strictly prohibited. If you received this message in error, please = notify the sender. Please also permanently delete all copies of the = original message and any attached documentation. = <graycol.gif>"Nikunj R. = Mehta" ---06/10/2009 11:20:26 AM---I find it difficult to incorporate = the specification of a media type parameter to specify inline depth in = the absence of a spec <ecblank.gif> From: <ecblank.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.com> <ecblank.gif> To: <ecblank.gif> Al = Brown/Costa Mesa/IBM@IBMUS <ecblank.gif> Cc: <ecblank.gif> James M Snell <jasnell@gmail.com>, atom-syntax = Syntax <atom-syntax@imc.org> <ecblank.gif> Date: <ecblank.gif> 06/10/2009 11:20 AM <ecblank.gif> Subject: <ecblank.gif> Re: = Sub-typing Atom documents I find it = difficult to incorporate the specification of a media type parameter to = specify inline depth in the absence of a specific proposal for how to = construct deeply nested hierarchy in the face of up and down links as = well as multi-parents. It only makes = sense to specify the media type parameter once a specific meaning or a = value space can be defined. I am not sure a viable proposal exists = (partly because of questions such as those raised in [1]), but I'd be = happy to work with anyone's proposal that addresses this = concern. Nikunj http://o-micron.blogspot.com = [1] http://tools.oasis-open.org/issues/browse/CMIS-259 On Jun 10, = 2009, at 10:59 AM, Al Brown wrote: It= would be useful to have more than one profile such that cmis + inline = may be specified. Also, will you include initial values for the profile = type or should that be part of CMIS and the inline I-D? Can we = have specify language similar to how link relations are specified? Ie, = there is a registry of names in a default namespace. Extensions are then = free to register their name or use a fully-qualified URI. One added = benefit of this is there will be a central registry of atom extensions, = at least the ones that took the time to register them. I also = thought the media type parameter inline-depth as useful and that would = be nice to have specified as part of the inline I-D. -Al = Al Brown Emerging Standards and Industry Frameworks CMIS: = https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home<= /u> Office 714 327 3453 Mobile 714 263 = 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, = including any attachments, are confidential and are intended solely for = the use of the person or entity to whom the message was addressed. If = you are not the intended recipient of this message, please be advised = that any dissemination, distribution, or use of the contents of this = message is strictly prohibited. If you received this message in error, = please notify the sender. Please also permanently delete all copies of = the original message and any attached documentation. = <graycol.gif>James M = Snell ---06/09/2009 03:46:22 PM---I've already started working up an I-D = for a new profile media type = = = <ecblank.gif> = From: <ecblank.gif> James M Snell <jasnell@gmail.com> <ecblank.gif> = To: <ecblank.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.com> <ecblank.gif> = Cc: <ecblank.gif> atom-syntax Syntax <atom-syntax@imc.org> <ecblank.gif> = Date: <ecblank.gif> 06/09/2009 03:46 PM <ecblank.gif> = Subject: <ecblank.gif> Re: Sub-typing Atom = documents I've already started working up an I-D for a new = profile media type parameter. I should be able to get it published = by tomorrow end-of-day Example: = application/atom+xml;profile=3D"http://example.org/profile/foo" The profile parameter value is a URI that = identifies a logical profile to which the Atom document conforms. = Only a single profile value is allowed for now. - = James Nikunj R. Mehta wrote: > Several recent = discussions suggest the need for sub-typing Atom > documents. = There are two major requirements for sub-typing Atom documents: = > > 1. In Atom Publishing Protocol, signaling the requirement = for an Atom > extension (whether blessed by IETF or not) to be = present in accepted > content [1]. To illustrate the requirement = by example, one would see: > > = <app:accept>application/atom+xml;type=3Dentry;extension=3Dtoken</= app:accept> > > 2. Establishing an expectation on an = Atom processor for the media type > of a linked resource, e.g., = whether the representation in-lines a > complete hierarchy of = Atom entries and feeds [2]. Once again to > illustrate the = requirement by example, one would see: > > <atom:link = rel=3D"down" > = type=3D"application/atom+xml;type=3Dfeed;inline-depth=3D1" = href=3D"children"/> > > Of these cases, a really strong = case can be made for the first > requirement to use a media type = parameter, since it has to happen in > the absence of the actual = Atom document. There is only one > must-understand signaling = mechanism in AtomPub and that is app:accept. > If a media type = parameter is used in app:accept that cannot be > understood by = its receiver, the receiver has no choice but to cease > = communications with the server. Since almost every AtomPub-style "API" = > introduces its own set of requirements for what constitutes an = entry > the server is willing to accept. > > For = example, Google Finance API in its protocol reference states that = > an entry posted as a new portfolio must include a = "gf:portfolioData" > element inside an atom:entry [3]. CMIS = servers may require the > presence of a type identifier as = extended entry metadata in order to > accept an entry posted to = a collection [4]. > > It seems quite reasonable to = establish a single media type parameter > and allow every such = API to define their own acceptable values for > this purpose. = This approach provides fair warning and enables AtomPub > = niches to legally exist, and even interoperate. > > The = second case can probably benefit from a media type parameter, but = > it is not clear what the semantics of that parameter would be. = > Specifically: > > 1. Do Atom processors = fail if, when processing Content-Type header, > = they encounter a media type parameter they don't know about or = a > value in a known media type parameter = that they don't understand. > 2. Does introduction = of media type parameters for > = application/atom+xml require standards track RFC? > > = > Nikunj > http://o-micron.blogspot.com > > [1] <= u>http://www.imc.org/atom-protocol/mail-archive/msg11398.h= tml > [2] = http://www.imc.org/atom-syntax/mail-archive/msg21114.htm= l > [3] http://code.google.com/apis/finance/developers_guide_pro= tocol.html#CreatingPortfolios = > [4] http://www.oasis-open.org/committees/download.php/32668<= /font> = = --Apple-Mail-41-65550968-- From owner-atom-syntax@mail.imc.org Wed Jun 10 12:31:08 2009 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 0FDA53A68D4 for ; Wed, 10 Jun 2009 12:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.026 X-Spam-Level: X-Spam-Status: No, score=-0.026 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001, URI_HEX=0.368, 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 8KUezPCb8yt1 for ; Wed, 10 Jun 2009 12:31:07 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C535F3A6855 for ; Wed, 10 Jun 2009 12:31:06 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AJIVSu063207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 12:18:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AJIVwu063205; Wed, 10 Jun 2009 12:18:31 -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 asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AJIKlT063180; Wed, 10 Jun 2009 12:18:31 -0700 (MST) (envelope-from algermissen1971@mac.com) MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Received: from spool001.mac.com ([10.150.69.51]) by asmtp025.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0KL1001SHEYBVY50@asmtp025.mac.com>; Wed, 10 Jun 2009 12:18:20 -0700 (PDT) Received: from webmail042 ([10.13.128.42]) by spool001.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0KL100LSVEXR3RA0@spool001.mac.com>; Wed, 10 Jun 2009 12:17:52 -0700 (PDT) Date: Wed, 10 Jun 2009 21:17:51 +0200 From: Jan Algermissen To: atom-syntax Syntax , atom-protocol Protocol Message-id: <84628901153205122334226847147114128557-Webmail@me.com> Subject: Re: Exploring a new WG around Atom Content-transfer-encoding: quoted-printable Received: from [198.185.18.34] from webmail.me.com with HTTP; Wed, 10 Jun 2009 21:17:51 +0200 Received: from [ 209.18.42.7] from webmail.me.com with HTTP; Wed, 10 Jun 2009 21:17:51 +0200 X-Originating-IP: 198.185.18.34, 209.18.42.7 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I'd also be interested in participating in a new WG. Of particular interest to me is the use of Atom and AtomPub in the non-blog= ging (enterprise) context. In addition to the list provided earlier, I have these on my list of intere= st: - using feeds for search results - adding a element Jan On Tuesday, June 09, 2009, at 11:40PM, "Sylvain Hellegouarch" wrote: > >Martin Atkins a =E9crit : >> >> Nikunj R. Mehta wrote: >>> >>> Recent discussions on the atom-syntax mailing list has revealed=20 >>> interest in creating a new WG to look at several extensions of Atom.=20 >>> Here are several extensions that have been discussed: >>> >>> 1. Hierarchy operations including meta-publishing >>> 2. In-line representation >>> 3. Bi-directional text >>> >>> Please respond to this email if you are interested in helping to=20 >>> explore a new WG further. Please also identify if you have a specific= =20 >>> interest area to consider for a potential new Atom WG. >>> >> >> I am particularly interested in the in-line representation part of=20 >> this. I'm currently working with a small group on an Atom extension=20 >> for describing activity streams[1], and frequently we've received=20 >> feedback from implementors that they want the pertinent content to be=20 >> inline in the feed to avoid additional fetches. >> >> ----------------- >> >> We were in fact discussing recently the use of inlining atom:link=20 >> content to refer to external resources without necessarily requiring=20 >> an additional fetch. I think this model is similar to atom:source in=20 >> that it provides some non-authoritative metadata that may be=20 >> sufficient for display purposes while providing a mechanism for=20 >> processors to retrieve the authoritative metadata when necessary. >> >> The model we were considering was as follows: >> >> >> >> tag:example.com,2009:123545 >> Some Related Entry >> ... >> >> >> >> To my mind, the model here would be that if=20 >> type=3D"application/atom+xml" then the link element MAY contain exactly= =20 >> one atom:entry or atom:feed element which provides a subset of the=20 >> information from the target document, much as atom:source does.=20 > >Why not using atom:content for that? The inlining you're presenting=20 >really looks like it defeats the point of the atom:link element in the=20 >first place. > >- Sylvain > > > From owner-atom-syntax@mail.imc.org Wed Jun 10 12:36:26 2009 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 8B3433A6B3D for ; Wed, 10 Jun 2009 12:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.569 X-Spam-Level: X-Spam-Status: No, score=0.569 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] 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 Eoud7m+oLuRB for ; Wed, 10 Jun 2009 12:36:25 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 032DB3A67B2 for ; Wed, 10 Jun 2009 12:36:24 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AITRDW060193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 11:29:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AITRAm060192; Wed, 10 Jun 2009 11:29: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 mail-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AITGSR060178 for ; Wed, 10 Jun 2009 11:29:26 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by gxk3 with SMTP id 3so3556854gxk.10 for ; Wed, 10 Jun 2009 11:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-rim-org-msg-ref-id :return-receipt-to:message-id:content-transfer-encoding:reply-to :x-priority:references:in-reply-to:sensitivity:importance:to:cc :subject:from:date:content-type:mime-version; bh=xfTSYp2vYihRpBARDlROOEew0A0I1NaZTj6NtNVjgew=; b=mEIlv7ao3VxJftuV6uqEC9myyTyPyxKsHOInHczHWV8x3GSAoB/wgxnw1bCGg5Hu0t 4Cmpl2xAOjO8RemgZw/VsfSUbd7HN5bo0SoT5i/LTrxcrSRgd03udlnIeHA2CM0qOXUa /KhAElRdqWPOgwE/6EZwUJAqkqv0wSXtpImv4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-rim-org-msg-ref-id:return-receipt-to:message-id :content-transfer-encoding:reply-to:x-priority:references :in-reply-to:sensitivity:importance:to:cc:subject:from:date :content-type:mime-version; b=JDtHY5/W8vJWJkf5G5xXJP6cpMBFpkTo3Z8Hl2gK7gotZfi7wAQZ4HE6g4jD4mzNgg I51e2TlRJ7DmrD7WQ+V3elmu0ryDMMDnnmFrhVndrTGFziHUUt9WIPH87w1wmG/PJ4Sq zvnHlORRza6eowe5O9vc/4yRTQ2fu92r4CJbM= Received: by 10.90.33.15 with SMTP id g15mr1317458agg.121.1244658555811; Wed, 10 Jun 2009 11:29:15 -0700 (PDT) Received: from bda703.bisx.prod.on.blackberry (c703.bda.bis.na.blackberry.com [67.223.71.112]) by mx.google.com with ESMTPS id 1sm563938agb.8.2009.06.10.11.29.14 (version=SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 11:29:14 -0700 (PDT) X-rim-org-msg-ref-id:477525907 Message-ID:<477525907-1244658553-cardhu_decombobulator_blackberry.rim.net-228592719-@bxe1007.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 Reply-To: jasnell@gmail.com X-Priority: Normal References: <20090610003357.59F6B3A6916@core3.amsl.com> <7D3F8024-3112-4D6B-B0C8-79A7654CB7B7@oracle.com> <4A2FF3AF.3070803@gmail.com> In-Reply-To: Sensitivity: Normal Importance: Normal To: "Nikunj R. Mehta" Cc: "atom-syntax Syntax" Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-02 From: jasnell@gmail.com Date: Wed, 10 Jun 2009 18:29:13 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: WWVzLCB0aGUgaXNzdWUgZGlkIGV4aXN0IGJlZm9yZSBnaXZlbiB0aGF0IHRoZSBsaW5rZWQgYXRv bSBmZWVkIGNvdWxkIGVhc2lseSBoYXZlIG11bHRpcGxlIGF0b206ZW50cnkgZWxlbWVudHMgd2l0 aCB0aGUgc2FtZSBhdG9tOmlkIHZhbHVlIGFzIGFsbG93ZWQgYnkgcmZjNDI4Ny4gSXQgaXMgYSBz aW1wbGUgbWF0dGVyIHRvIGFuc3dlciB3aGV0aGVyIHRoZXJlIGNhbiBiZSBtdWx0aXBsZSBkaXN0 aWN0IGNoaWxkIHNldHMgb3IgYSBzaW5nbGUgbG9naWNhbCBjaGlsZCBzZXQgYW5kIHRvIGFuc3dl ciB3aGV0aGVyIG1lbWJlcnNoaXAgaW4gdGhhdCBzZXQgaXMgYmFzZWQgb24gaW5zdGFuY2Ugb3Ig aWRlbnRpdHkuIA0KDQotIEphbWVzICANClNlbnQgZnJvbSBteSBWZXJpem9uIFdpcmVsZXNzIEJs YWNrQmVycnkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206ICJOaWt1bmogUi4g TWVodGEiIDxuaWt1bmoubWVodGFAb3JhY2xlLmNvbT4NCg0KRGF0ZTogV2VkLCAxMCBKdW4gMjAw OSAxMToxNTowNCANClRvOiBKYW1lcyBNIFNuZWxsPGphc25lbGxAZ21haWwuY29tPg0KQ2M6IGF0 b20tc3ludGF4IFN5bnRheDxhdG9tLXN5bnRheEBpbWMub3JnPg0KU3ViamVjdDogUmU6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZGl2aWxseS1hdG9tLWhpZXJhcmNoeS0wMg0K DQoNCk9uIEp1biAxMCwgMjAwOSwgYXQgMTA6NTUgQU0sIEphbWVzIE0gU25lbGwgd3JvdGU6DQoN Cj4gVGhhbmsgeW91IGZvciB0aGUgY2hhbmdlcy4gQW5vdGhlciBpc3N1ZSB0aGF0IG5lZWRzIHRv IGJlIGxvb2tlZCBhdCAgDQo+ICh3aGljaCBleGlzdGluZyBpbiB0aGUgcHJldmlvdXMgdmVyc2lv biBvZiB0aGUgZHJhZnQgYXMgd2VsbCkNCg0KVGhpcyBpc3N1ZSBkaWQgbm90IGV4aXN0IGluIHRo ZSBwcmV2aW91cyBkcmFmdCBzaW5jZSBvbmx5IG9uZSBsaW5rICANCndpdGggQHJlbCB2YWx1ZSBk b3duIGFuZCBAdHlwZSBhcHBsaWNhdGlvbi9hdG9tK3htbCB3YXMgcG9zc2libGUuDQoNCj4gaXMg aG93IGEgcHJvY2Vzc29yIGNhbiByZWNvbnN0cnVjdCB0aGUgbG9naWNhbCBzZXQgb2YgY2hpbGRy ZW4gZm9yICANCj4gYW4gZW50cnkuLi4gdGhhdCBpcywgZm9yIGluc3RhbmNlLCBpZiB0aGUgc2V0 IG9mIGNoaWxkIGVudHJpZXMgIA0KPiBjb250YWlucyBtdWx0aXBsZSBhdG9tOmVudHJ5IGVsZW1l bnRzIHdpdGggdGhlIHNhbWUgYXRvbTppZCB2YWx1ZSwgIA0KPiBhcmUgdGhvc2Ugdmlld2VkIGFz IHNlcGFyYXRlIGNoaWxkcmVuIG9yIGlzIG9ubHkgdGhlIGVudHJ5IHdpdGggdGhlICANCj4gbW9z dCByZWNlbnQgYXRvbTp1cGRhdGVkIHZhbHVlIGluY2x1ZGVkIGluIHRoZSBzZXQgb2YgY2hpbGRy ZW4/DQoNCldlIGhhdmUgdHdvIGNob2ljZXMgLSBlaXRoZXIgY29uc3RyYWluIGNhcmRpbmFsaXR5 IGFuZCBvYnRhaW4gYW4gIA0KdW5hbWJpZ3VvdXMgbG9naWNhbCBzZXQgb2YgY2hpbGRyZW4gb3Ig cmVtb3ZlIHRoZSBjYXJkaW5hbGl0eSAgDQpjb25zdHJhaW50IGFuZCBsZWF2ZSBpdCB0byBhcHBs aWNhdGlvbnMgdG8gaW50ZXJwcmV0IG11bHRpcGxlIHNldHMgb3IgIA0Kc3Vic2V0cy4gSSBkb247 dCBzZWUgaG93IHdlIGNhbiBnZXQgYSB0aGlyZCBvcHRpb24uIEJUVywgdGhlIHRocmVhZGluZyAg DQpleHRlbnNpb24gdXNlcyB0aGUgc2Vjb25kIGFwcHJvYWNoIGFuZCCnMi4yIGFzIHdlbGwgYXMg pzIuMyBvZiAgDQpoaWVyYXJjaHkgSS1EIGV4cGxhaW4gd2hhdCBhbiBBdG9tIHByb2Nlc3NvciBk b2VzIHdpdGggbXVsdGlwbGUgIA0Kb2NjdXJyZW5jZXMgb2YgdGhlIGRvd24gYW5kIHVwIGxpbmss IHJlc3BlY3RpdmVseS4NCg0KPiBGdXJ0aGVyLCBpZiBtdWx0aXBsZSAiZG93biIgbGlua3MgYXJl IHNwZWNpZmllZCwgZWFjaCBwb2ludGluZyB0byAgDQo+IHNlcGFyYXRlIEF0b20gZmVlZHMgd2l0 aCBzZXBhcmF0ZSBlbnRyaWVzIHdpdGggZGlzdGluY3QgYXRvbTppZCAgDQo+IHZhbHVlcywgaXMg dGhhdCB0byBiZSB2aWV3ZWQgYXMgdHdvIHNlcGFyYXRlIGNoaWxkIGNvbGxlY3Rpb25zIG9yIGEg IA0KPiBzaW5nbGUgbG9naWNhbCBjb21iaW5lZCBjb2xsZWN0aW9uPyBJIHdvdWxkIHJlY29tbWVu ZCB0aGUgbGF0dGVyLg0KDQpBcyBJIGV4cGxhaW4gYWJvdmUsIHRoaXMgY2hvaWNlIGlzIGluZmVh c2libGUuIEhvdyBpcyBvbmUgdG8gcmVjb25jaWxlICANCmFuIEhUTUwgbGlua2VkIHJlc291cmNl IHdpdGggYW4gZW50cnkgd2l0aCBhIGZlZWQgYW5kIGFuIGltYWdlIGFsbCAgDQp0aHJvdWdoIEBy ZWw9ZG93bj8gSSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIGxlYXJuaW5nIG9mIGEgcHJvcG9zYWwg dG8gIA0KaGFuZGxlIHRoaXMga2luZCBvZiBhIHNpdHVhdGlvbi4NCg0KPg0KPiBOaWt1bmogUi4g TWVodGEgd3JvdGU6DQo+PiBCYXNlZCBvbiBmZWVkYmFjaywgSSBoYXZlIHNpbXBsaWZpZWQgdGhl IEktRCB0bzoNCj4+IEluLWxpbmUgZXh0ZW5zaW9ucyBtb3ZlZCB0byBkcmFmdC1tZWh0YS1hdG9t LWlubGluZQ0KPj4gICAgICBSZW1vdmVkIGRvd24tdHJlZSBhbmQgdXAtdHJlZSByZWxhdGlvbnMN Cj4+ICAgICAgUmVtb3ZlZCBjYXJkaW5hbGl0eSByZXN0cmljdGlvbnMgb24gdXAgYW5kIGRvd24g bGlua3MNCj4+DQo+PiBIVE1MOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kaXZp bGx5LWF0b20taGllcmFyY2h5LTAyDQo+PiBUZXh0OiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQv ZHJhZnQtZGl2aWxseS1hdG9tLWhpZXJhcmNoeS0wMi50eHQgPGh0dHA6Ly90b29scy5pZXRmLm9y Zy9pZC9kcmFmdC1tZWh0YS1hdG9tLWlubGluZS0wMC50eHQgDQo+PiA+DQo+PiBEaWZmOiBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWRpdmlsbHktYXRvbS1oaWVyYXJj aHktMDIudHh0DQo+Pg0KPj4gSSBhbSBhbHNvIHRyYWNraW5nIG9wZW4gaXNzdWVzIGFib3V0IHRo aXMgSS1EIHB1YmxpY2x5IGF0IGh0dHA6Ly9jb2RlLmdvb2dsZS5jb20vcC9hdG9tLWV4dC9pc3N1 ZXMvbGlzdCANCj4+IC4gVGhlIHNvdXJjZSBmb3IgdGhpcyBJLUQgaXMgYWxzbyBhdmFpbGFibGUs IGlmIHlvdSBhcmUgaW50ZXJlc3RlZC4NCj4+DQo+PiBMb29raW5nIGZvcndhcmQgdG8gY29tbWVu dHMgb24gdGhlIEktRC4NCj4+DQo+PiBOaWt1bmoNCj4+IGh0dHA6Ly9vLW1pY3Jvbi5ibG9nc3Bv dC5jb20gPGh0dHA6Ly9vLW1pY3Jvbi5ibG9nc3BvdC5jb20vPg0KPj4NCj4+DQo+PiBCZWdpbiBm b3J3YXJkZWQgbWVzc2FnZToNCj4+DQo+Pj4gKkZyb206ICpJRVRGIEktRCBTdWJtaXNzaW9uIFRv b2wgPGlkc3VibWlzc2lvbkBpZXRmLm9yZyA8bWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZyAN Cj4+PiA+Pg0KPj4+ICpEYXRlOiAqSnVuZSA5LCAyMDA5IDU6MzM6NTcgUE0gUERUDQo+Pj4gKlRv OiAqbmlrdW5qLm1laHRhQG9yYWNsZS5jb20gPG1haWx0bzpuaWt1bmoubWVodGFAb3JhY2xlLmNv bT4NCj4+PiAqQ2M6ICpjb2xtLmRpdmlsbHlAb3JhY2xlLmNvbSA8bWFpbHRvOmNvbG0uZGl2aWxs eUBvcmFjbGUuY29tPg0KPj4+ICpTdWJqZWN0OiAqKk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtZGl2aWxseS1hdG9tLSANCj4+PiBoaWVyYXJjaHktMDIgKg0KPj4+DQo+Pj4NCj4+ PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZGl2aWxseS1hdG9tLWhpZXJhcmNoeS0wMi50 eHQgaGFzIGJlZW4gIA0KPj4+IHN1Y2Nlc3NmdWx5IHN1Ym1pdHRlZCBieSBOaWt1bmogTWVodGEg YW5kIHBvc3RlZCB0byB0aGUgSUVURiAgDQo+Pj4gcmVwb3NpdG9yeS4NCj4+Pg0KPj4+IEZpbGVu YW1lOiBkcmFmdC1kaXZpbGx5LWF0b20taGllcmFyY2h5DQo+Pj4gUmV2aXNpb246IDAyDQo+Pj4g VGl0bGU6IEhpZXJhcmNoeSBSZWxhdGlvbnMgZm9yIEF0b20NCj4+PiBDcmVhdGlvbl9kYXRlOiAy MDA5LTA2LTA5DQo+Pj4gV0cgSUQ6IEluZGVwZW5kZW50IFN1Ym1pc3Npb24NCj4+PiBOdW1iZXJf b2ZfcGFnZXM6IDcNCj4+Pg0KPj4+IEFic3RyYWN0Og0KPj4+IFRoaXMgc3BlY2lmaWNhdGlvbiBk ZWZpbmVzIGxpbmsgcmVsYXRpb25zIGZvciBoaWVyYXJjaGljYWwgIA0KPj4+IG5hdmlnYXRpb24N Cj4+PiBhbW9uZyBBdG9tIGZlZWRzIGFuZCBlbnRyaWVzLkVkaXRvcmlhbCBOb3RlDQo+Pj4NCj4+ PiBUbyBwcm92aWRlIGZlZWRiYWNrIG9uIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGpvaW4gdGhlIGF0 b20tc3ludGF4DQo+Pj4gbWFpbGluZyBsaXN0IChodHRwOi8vd3d3LmltYy5vcmcvYXRvbS1zeW50 YXgvKSBbMV0uDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gVGhlIElFVEYgU2VjcmV0YXJpYXQuDQo+Pj4N Cj4+Pg0KPj4NCg0K From owner-atom-syntax@mail.imc.org Wed Jun 10 12:58:22 2009 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 C46993A6BFA for ; Wed, 10 Jun 2009 12:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.831 X-Spam-Level: X-Spam-Status: No, score=-4.831 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 GIXsvw5ctZrB for ; Wed, 10 Jun 2009 12:58:21 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 54BE13A6B4E for ; Wed, 10 Jun 2009 12:58:21 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AJlK5b064843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 12:47:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AJlKba064842; Wed, 10 Jun 2009 12:47:20 -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 acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AJlJGl064836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 12:47:20 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AJhVAe027717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 10 Jun 2009 19:43:32 GMT Received: from abhmt002.oracle.com (abhmt002.oracle.com [141.146.116.11]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AJmOLf026981 for ; Wed, 10 Jun 2009 19:48:25 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Jun 2009 12:47:14 -0700 Message-Id: From: "Nikunj R. Mehta" To: atom-syntax Syntax In-Reply-To: <4A3000DF.9050604@degeneration.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-mehta-atom-inline-00 Date: Wed, 10 Jun 2009 12:45:52 -0700 References: <20090609233744.9A64B3A6A48@core3.amsl.com> <6B1A1BB7-5698-4852-8DE6-F2A06691624B@oracle.com> <4A3000DF.9050604@degeneration.co.uk> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt002.oracle.com [141.146.116.11] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4A300DC4.006E:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 10, 2009, at 11:52 AM, Martin Atkins wrote: > > Nikunj R. Mehta wrote: >> Based on feedback, I have split out the in-lining spec in to its >> own I-D. HTML: http://tools.ietf.org/html/draft-mehta-atom-inline-00 >> Text: http://tools.ietf.org/id/draft-mehta-atom-inline-00.txt >> I am also tracking open issues about this I-D publicly at http://code.google.com/p/atom-ext/issues/list >> . The source for this I-D is also available, if you are interested. >> Looking forward to comments on the I-D. > > Is it actually necessary to support inlining of resources other than > atom feeds and entries? It seems like this adds considerable > complexity where I'm not sure that there are compelling use-cases. I am glad you are speaking up about this. The original proposal for in- lining as expressed in draft-divilly-atom-hierarchy-01 was rather modest and supported a rather simple use case. However, per Mark Nottingham et al [1], the use of the ae:inline is held up as the right way of extending Atom. Plus, per James Snell [2], the inline content's media type is better gleaned from ae:inline@type attribute. Also, per Al Brown et al. [3] [4] [5], it was more important to ensure maximum flexibility than demonstrate specific use cases. > > Given how little success there has been with the complex content > model of the atom:content element in practice, it'd be my preference > to avoid over-thinking this and address only the specific use-case > of referencing other items that are themselves expressed as Atom. I agree that the current model is super flexible, perhaps to the point of complicating even basic behavior. However, we need some consensus on the level of flexibility and cost we can agree to. > > In particular, I'm unsure as to what the meaning would be of the > following: > > > Blah blah blah > > > Is the text inside considered to be an alternate representation of > this resource? Should the content actually be the entity-encoded > XML? Is this invalid? The current draft seems to have no comment on > the matter. > > Restricting the problem to only inline feeds and entries also > theoretically allows the ah:inline element to be removed and the > atom:feed or atom:entry element given as a direct child of > atom:link, with the name of the element telling the processor > whether it's a feed or entry without the redundancy inherent in the > ah:inline type attribute. > > [1] http://www.imc.org/atom-syntax/mail-archive/msg21053.html [2] http://www.imc.org/atom-syntax/mail-archive/msg21084.html [3] http://www.imc.org/atom-syntax/mail-archive/msg21088.html [4] http://www.imc.org/atom-syntax/mail-archive/msg21096.html [5] http://www.imc.org/atom-syntax/mail-archive/msg21121.html From owner-atom-syntax@mail.imc.org Wed Jun 10 13:17:55 2009 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 ADBEE3A6C00 for ; Wed, 10 Jun 2009 13:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.085 X-Spam-Level: X-Spam-Status: No, score=-3.085 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 Gc7kdpZ8+r9U for ; Wed, 10 Jun 2009 13:17:48 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B3F903A6A31 for ; Wed, 10 Jun 2009 13:17:46 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AK6J7H066010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 13:06:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AK6JAH066009; Wed, 10 Jun 2009 13:06: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 e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AK68rQ065990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 13:06:18 -0700 (MST) (envelope-from albertcbrown@us.ibm.com) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e32.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5AK2O9d017436 for ; Wed, 10 Jun 2009 14:02:24 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5AK5x4P123080 for ; Wed, 10 Jun 2009 14:05:59 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5AK5wU3032624 for ; Wed, 10 Jun 2009 14:05:58 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n5AK5vMe032559; Wed, 10 Jun 2009 14:05:57 -0600 In-Reply-To: <58999F91-AC03-45CC-B4ED-E84995846C28@oracle.com> References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2EE11F.2080809@gmail.com> <62E5FD4C-D6D7-4A7A-8918-0DDA48D10495@oracle.com> <58999F91-AC03-45CC-B4ED-E84995846C28@oracle.com> Subject: Re: Sub-typing Atom documents X-KeepSent: 276F8A7A:E5D7B85D-882575D1:006E1B36; type=4; name=$KeepSent To: "Nikunj R. Mehta" Cc: atom-syntax Syntax , James M Snell X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: Al Brown Date: Wed, 10 Jun 2009 13:05:46 -0700 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Build V851_04282009|April 28, 2009) at 06/10/2009 14:05:56 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBFF42DFFD9DA68f9e8a93df938690918c07BBFF42DFFD9DA6" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0__=07BBFF42DFFD9DA68f9e8a93df938690918c07BBFF42DFFD9DA6 Content-type: multipart/alternative; Boundary="1__=07BBFF42DFFD9DA68f9e8a93df938690918c07BBFF42DFFD9DA6" --1__=07BBFF42DFFD9DA68f9e8a93df938690918c07BBFF42DFFD9DA6 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable >Signaling the use of in-lining extensions in Content-Type, atom:link@t= ype, and app:accept could be done quite easily with James' proposed I-D. Yes, provided either the inline I-D or profile I-D specified the value = to be used for the profile media type argument for atom documents with the= inline markup. *shrug* Guess we have to wait to resolve this till the profile I-D draft is available. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of th= e person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please noti= fy the sender. Please also permanently delete all copies of the original message and any attached documentation. = From: "Nikunj R. Mehta" = = To: Al Brown/Costa Mesa/IBM@IBMUS = = Cc: atom-syntax Syntax , James M Snell <= jasnell@gmail.com> = Date: 06/10/2009 12:07 PM = = Subject: Re: Sub-typing Atom documents = = On Jun 10, 2009, at 11:54 AM, Al Brown wrote: Great reference. That's an issue oracle filed recently. The first= bullet in #259 is precisely the reason why we need to have either= a media type parameter (media type signals tree or flat) or down-tr= ee link relation. I do not believe those questions need to be answered to signal th= at the atom document referenced by a link element contains inline (hierarchy) or not.. Signaling the use of in-lining extensions in Content-Type, atom:link@ty= pe, and app:accept could be done quite easily with James' proposed I-D. If the inline I-D does not address that bullet in some way, I wou= ld prefer not to have the inline I-D so CMIS can provide a extension-specific solution until the new atom wg (if formed) com= es up with a new specification that addresses hierarchy. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/= Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use= of the person or entity to whom the message was addressed. If you ar= e not the intended recipient of this message, please be advised tha= t any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete a= ll copies of the original message and any attached documentation. "Nikunj R. Mehta" ---06/10/2009 11:20:26 AM---I find= it difficult to incorporate the specification of a media type parame= ter to specify inline depth in the absence of a spec = = f> "Nikunj R. Mehta" = From: = = = f> Al Brown/Costa Mesa/IBM@IBMUS = To: = = = f> James M Snell , atom-syntax Syntax < = Cc: atom-syntax@imc.org> = = = f> 06/10/2009 11:20 AM = Date: = = = f> Re: Sub-typing Atom documents = Subject: = = I find it difficult to incorporate the specification of a media t= ype parameter to specify inline depth in the absence of a specific proposal for how to construct deeply nested hierarchy in the face= of up and down links as well as multi-parents. It only makes sense to specify the media type parameter once a specific meaning or a value space can be defined. I am not sure a= viable proposal exists (partly because of questions such as those= raised in [1]), but I'd be happy to work with anyone's proposal t= hat addresses this concern. Nikunj http://o-micron.blogspot.com [1] http://tools.oasis-open.org/issues/browse/CMIS-259 On Jun 10, 2009, at 10:59 AM, Al Brown wrote: It would be useful to have more than one profile such= that cmis + inline may be specified. Also, will you include initial values for the profile type or should= that be part of CMIS and the inline I-D? Can we have specify language similar to how link relations are specified? Ie, there is a registry of n= ames in a default namespace. Extensions are then free to register their name or use a fully-qualified URI. One= added benefit of this is there will be a central regi= stry of atom extensions, at least the ones that took the t= ime to register them. I also thought the media type parameter inline-depth = as useful and that would be nice to have specified as pa= rt of the inline I-D. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/H= ome Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity t= o whom the message was addressed. If you are not the intended recipient of this message, please be advised= that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If y= ou received this message in error, please notify the sen= der. Please also permanently delete all copies of the orig= inal message and any attached documentation. James M Snell ---06/09/2009 03:46:22 PM---I've already started working up an I-D for a new= profile media type = = From: James M Snell = = = To: "Nikunj R. Mehta" = = = Cc: atom-syntax Syntax = = = Date: 06/09/2009 03:46 PM = = = Subject: Re: Sub-typing Atom documents = = I've already started working up an I-D for a new prof= ile media type parameter. I should be able to get it published by tomorrow end-of-day Example: application/atom+xml;profile=3D" http://example.org/profile/foo" The profile parameter value is a URI that identifies = a logical profile to which the Atom document conforms. Only a single profile value is allowed for now. - James Nikunj R. Mehta wrote: > Several recent discussions suggest the need for sub-typing Atom > documents. There are two major requirements for sub-typing Atom documents: > > 1. In Atom Publishing Protocol, signaling the requirement for an Atom > extension (whether blessed by IETF or not) to be present in accepted > content [1]. To illustrate the requirement by examp= le, one would see: > > application/atom +xml;type=3Dentry;extension=3Dtoken > > 2. Establishing an expectation on an Atom processor= for the media type > of a linked resource, e.g., whether the representat= ion in-lines a > complete hierarchy of Atom entries and feeds [2]. O= nce again to > illustrate the requirement by example, one would se= e: > > type=3D"application/atom+xml;type=3Dfeed;inline-dep= th=3D1" href=3D"children"/> > > Of these cases, a really strong case can be made fo= r the first > requirement to use a media type parameter, since it= has to happen in > the absence of the actual Atom document. There is o= nly one > must-understand signaling mechanism in AtomPub and = that is app:accept. > If a media type parameter is used in app:accept tha= t cannot be > understood by its receiver, the receiver has no cho= ice but to cease > communications with the server. Since almost every AtomPub-style "API" > introduces its own set of requirements for what constitutes an entry > the server is willing to accept. > > For example, Google Finance API in its protocol reference states that > an entry posted as a new portfolio must include a "gf:portfolioData" > element inside an atom:entry [3]. CMIS servers may require the > presence of a type identifier as extended entry metadata in order to > accept an entry posted to a collection [4]. > > It seems quite reasonable to establish a single med= ia type parameter > and allow every such API to define their own accept= able values for > this purpose. This approach provides fair warning = and enables AtomPub > niches to legally exist, and even interoperate. > > The second case can probably benefit from a media t= ype parameter, but > it is not clear what the semantics of that paramete= r would be. > Specifically: > > 1. Do Atom processors fail if, when processing Content-Type header, > they encounter a media type parameter they do= n't know about or a > value in a known media type parameter that th= ey don't understand. > 2. Does introduction of media type parameters fo= r > application/atom+xml require standards track = RFC? > > > Nikunj > http://o-micron.blogspot.com > > [1] http://www.imc.org/atom-protocol/mail-archive/msg1139= 8.html > [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.= html > [3] http://code.google.com/apis/finance/developers_guide_= protocol.html#CreatingPortfolios > [4] http://www.oasis-open.org/committees/download.php/326= 68 = --1__=07BBFF42DFFD9DA68f9e8a93df938690918c07BBFF42DFFD9DA6 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable >Signaling the use of in-lining extensions in Co= ntent-Type, atom:link@type, and app:accept could be done quite easily w= ith James' proposed I-D.=A0 Yes, provided either the inline I-D or profile I-D spe= cified the value to be used for the profile media type argument for ato= m documents with the inline markup. *shrug* Guess we have to wait to r= esolve this till the profile I-D draft is available. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: ht= tps://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. "Niku= nj R. Mehta" ---06/10/2009 12:07:07 PM---On Jun 10, 2009, at 11:54= AM, Al Brown wrote: Great reference. That's an issue oracle filed rece= ntly. The first bullet in #259 = From: = "Nikunj R. Mehta" <nikunj.mehta@oracle.co= m> To: Al Brown/Costa Mesa/IBM@IBMUS Cc: atom-syntax Syntax <atom-syntax@imc.org>, James = M Snell <jasnell@gmail.com> Date: = 06/10/2009 12:07 PM Subject: Re: Sub-typing Atom documents On Jun 10, 2009, at 11:54 AM, Al Brown wrote: Great reference. That's an issue oracle filed rece= ntly. The first bullet in #259 is precisely the reason why we need to h= ave either a media type parameter (media type signals tree or flat) or = down-tree link relation. I do not believe those questions need to be answered to signal that the= atom document referenced by a link element contains inline (hierarchy)= or not.. Signaling the use of in-lining extensions in Content-T= ype, atom:link@type, and app:accept could be done quite easily with Jam= es' proposed I-D. If the inline I-D does not address that bullet in some way, I would pre= fer not to have the inline I-D so CMIS can provide a extension-specific= solution until the new atom wg (if formed) comes up with a new specifi= cation that addresses hierarchy. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki0= 7/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.= ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. <graycol.gif>"Niku= nj R. Mehta" ---06/10/2009 11:20:26 AM---I find it difficult to in= corporate the specification of a media type parameter to specify inline= depth in the absence of a spec = <ecblank.gif&g= t; From: <ecblank.gif>= "Nikunj R. Mehta" <nikunj.mehta@oracle.com&g= t; <ecblank.gif&g= t; To: <ecblank.gif> Al Brown/Costa Mesa/IBM@IBMUS <ecblank.gif&g= t; Cc: <= ;ecblank.gif> James M Snell <jasnell@gmail.com>, atom-syntax Syntax <= atom-= syntax@imc.org> <ecblank.gif&g= t; Date: <ecblank.gif>= 06/10/2009 11:20 AM <ecblank.gif&g= t; Subject: <ecblank.gif&= gt; Re: Sub-typing Atom documents <= br> I find it difficult to incorporate the specification of a media type pa= rameter to specify inline depth in the absence of a specific proposal f= or how to construct deeply nested hierarchy in the face of up and down = links as well as multi-parents. It only makes sense to specify the media type parameter once a specific= meaning or a value space can be defined. I am not sure a viable propos= al exists (partly because of questions such as those raised in [1]), bu= t I'd be happy to work with anyone's proposal that addresses this conce= rn. Nikunj http://o-micron.blogspot.com [1] http://tools.oasis-open.org/is= sues/browse/CMIS-259 On Jun 10, 2009, at 10:59 AM, Al Brown wrote: It would be useful to have more than one profile s= uch that cmis + inline may be specified. Also, will you include initial= values for the profile type or should that be part of CMIS and the inl= ine I-D? Can we have specify language similar to how link relations are specifie= d? Ie, there is a registry of names in a default namespace. Extensions = are then free to register their name or use a fully-qualified URI. One = added benefit of this is there will be a central registry of atom exten= sions, at least the ones that took the time to register them. I also thought the media type parameter inline-depth as useful and that= would be nice to have specified as part of the inline I-D. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki0= 7/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.= ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attach= ments, are confidential and are intended solely for the use of the pers= on or entity to whom the message was addressed. If you are not the inte= nded recipient of this message, please be advised that any disseminatio= n, distribution, or use of the contents of this message is strictly pro= hibited. If you received this message in error, please notify the sende= r. Please also permanently delete all copies of the original message an= d any attached documentation. <graycol.gif>James M Sn= ell ---06/09/2009 03:46:22 PM---I've already started working up an I-D = for a new profile media type = <ecblank.gif&g= t; From: <ecblank.gif>= James M Snell <jasnell@gmail.com> <ecblank.gif&g= t; To: <ecblank.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.co= m> <ecblank.gif&g= t; Cc: <= ;ecblank.gif> atom-syntax Syntax <atom-syntax@imc.org<= font size=3D"4">> <ecblank.gif&g= t; Date: <ecblank.gif>= 06/09/2009 03:46 PM <ecblank.gif&g= t; Subject: <ecblank.gif&= gt; Re: Sub-typing Atom documents <= br> I've already started working up an I-D for a new profile media type parameter. I should be able to get it published by tomorrow end-of-day<= br> Example: application/atom+xml;profile=3D"http://e= xample.org/profile/foo" The profile parameter value is a URI that identifies a logical profile = to which the Atom document conforms. Only a single profile value is allowed for now. - James Nikunj R. Mehta wrote: > Several recent discussions suggest the need for sub-typing Atom > documents. There are two major requirements for sub-typing Atom do= cuments: > > 1. In Atom Publishing Protocol, signaling the requirement for an A= tom > extension (whether blessed by IETF or not) to be present in accept= ed > content [1]. To illustrate the requirement by example, one would s= ee: > > <app:accept>application/atom+xml;type=3Dentry;extension=3Dto= ken</app:accept> > > 2. Establishing an expectation on an Atom processor for the media = type > of a linked resource, e.g., whether the representation in-lines a = > complete hierarchy of Atom entries and feeds [2]. Once again to > illustrate the requirement by example, one would see: > > <atom:link rel=3D"down" > type=3D"application/atom+xml;type=3Dfeed;inline-depth=3D1&quo= t; href=3D"children"/> > > Of these cases, a really strong case can be made for the first > requirement to use a media type parameter, since it has to happen = in > the absence of the actual Atom document. There is only one > must-understand signaling mechanism in AtomPub and that is app:acc= ept. > If a media type parameter is used in app:accept that cannot be > understood by its receiver, the receiver has no choice but to ceas= e > communications with the server. Since almost every AtomPub-style &= quot;API" > introduces its own set of requirements for what constitutes an ent= ry > the server is willing to accept. > > For example, Google Finance API in its protocol reference states t= hat > an entry posted as a new portfolio must include a "gf:portfol= ioData" > element inside an atom:entry [3]. CMIS servers may require the > presence of a type identifier as extended entry metadata in order = to > accept an entry posted to a collection [4]. > > It seems quite reasonable to establish a single media type paramet= er > and allow every such API to define their own acceptable values for= > this purpose. This approach provides fair warning and enable= s AtomPub > niches to legally exist, and even interoperate. > > The second case can probably benefit from a media type parameter, = but > it is not clear what the semantics of that parameter would be. > Specifically: > > 1. Do Atom processors fail if, when processing Conten= t-Type header, > they encounter a media type parameter they do= n't know about or a > value in a known media type parameter that th= ey don't understand. > 2. Does introduction of media type parameters for = > application/atom+xml require standards track = RFC? > > > Nikunj > http://o-micron.blogspot.com > > [1] http://= www.imc.org/atom-protocol/mail-archive/msg11398.html > [2] http://ww= w.imc.org/atom-syntax/mail-archive/msg21114.html > [3] http://code.google.com/apis/finance/developers_guide= _protocol.html#CreatingPortfolios > [4] http://www.= oasis-open.org/committees/download.php/32668 = --1__=07BBFF42DFFD9DA68f9e8a93df938690918c07BBFF42DFFD9DA6-- --0__=07BBFF42DFFD9DA68f9e8a93df938690918c07BBFF42DFFD9DA6 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBFF42DFFD9DA68f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBFF42DFFD9DA68f9e8a93df938690918c07BBFF42DFFD9DA6 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=07BBFF42DFFD9DA68f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBFF42DFFD9DA68f9e8a93df938690918c07BBFF42DFFD9DA6-- From owner-atom-syntax@mail.imc.org Wed Jun 10 13:23:20 2009 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 EF2383A6C00 for ; Wed, 10 Jun 2009 13:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-1.252, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=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 rJDAAOwhAKzu for ; Wed, 10 Jun 2009 13:23:20 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9AF4C3A6A31 for ; Wed, 10 Jun 2009 13:23:19 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AKAsTm066277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 13:10:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AKAsWQ066276; Wed, 10 Jun 2009 13:10: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 mail-ew0-f217.google.com (mail-ew0-f217.google.com [209.85.219.217]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AKAqxR066270 for ; Wed, 10 Jun 2009 13:10:53 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by ewy17 with SMTP id 17so1125750ewy.10 for ; Wed, 10 Jun 2009 13:10:51 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=OX1u9OJm8ZY6zYMkiMkVw3ImpS4zvaXWL8sF51yRag0=; b=dsXqwdiH76Acq3iykyWx9kHUAwgD6vgbI9aa5+zpf65HOrO1sQ172jeOFtdiYBqZOo P9LnkN2imWguzSUp1sRbCqLGO1dOA/lkKt9Q8RCUXrujMmc2+HAvrZq+03RSCLFxOAGL Ui+9SUvp/rFlpf86Zv1VLiFeACpOM0CLOBb6I= 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:content-type:content-transfer-encoding; b=vgz5uMo04O5ZO4Yn3S+vtO7SOidlvbW6fOHqcxWn5nLf8LIhXR5IdnQcGesoFik9Rz BAkmKydCf3EE2g8vvlGRztZYI/Do6WgRxJuWviODRHSA12RHry74HaFwxNFbKOr86Ci1 bFz7MpcXF3WY5F3SRzZG2zvay7YiPHFs3ij10= Received: by 10.210.102.9 with SMTP id z9mr2129279ebb.69.1244664651877; Wed, 10 Jun 2009 13:10:51 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 10sm88476eyz.11.2009.06.10.13.10.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 13:10:51 -0700 (PDT) Message-ID: <4A30137F.5020906@gmail.com> Date: Wed, 10 Jun 2009 13:11:43 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Nikunj R. Mehta" CC: atom-syntax Syntax Subject: Re: New Version Notification for draft-mehta-atom-inline-00 References: <20090609233744.9A64B3A6A48@core3.amsl.com> <6B1A1BB7-5698-4852-8DE6-F2A06691624B@oracle.com> <4A3000DF.9050604@degeneration.co.uk> In-Reply-To: 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: Nikunj R. Mehta wrote: > > On Jun 10, 2009, at 11:52 AM, Martin Atkins wrote: > >> >> Nikunj R. Mehta wrote: >>> Based on feedback, I have split out the in-lining spec in to its own >>> I-D. HTML: http://tools.ietf.org/html/draft-mehta-atom-inline-00 >>> Text: http://tools.ietf.org/id/draft-mehta-atom-inline-00.txt >>> I am also tracking open issues about this I-D publicly at >>> http://code.google.com/p/atom-ext/issues/list. The source for this >>> I-D is also available, if you are interested. >>> Looking forward to comments on the I-D. >> >> Is it actually necessary to support inlining of resources other than >> atom feeds and entries? It seems like this adds considerable >> complexity where I'm not sure that there are compelling use-cases. > > I am glad you are speaking up about this. The original proposal for > in-lining as expressed in draft-divilly-atom-hierarchy-01 was rather > modest and supported a rather simple use case. > > However, per Mark Nottingham et al [1], the use of the ae:inline is > held up as the right way of extending Atom. Plus, per James Snell [2], > the inline content's media type is better gleaned from ae:inline@type > attribute. Also, per Al Brown et al. [3] [4] [5], it was more > important to ensure maximum flexibility than demonstrate specific use > cases. > To be clear, what I was suggesting was that if you were going to be pointing to the atom:content rules as the model for processing ae:inline then it would better for ae:inline to have its own type attribute distinct from the atom:link elements type attribute. How to handle things if there is a mismatch between the atom:link/@type and the ae:inline/@type (or the atom:link/@type and the actual content type of the linked resource after performing an HTTP GET) is a separate issue altogether. Further, it is possible to define the "up" and "down" links generically, but to define -- separately -- some set of rules that limit their use to construct an Atom-only hierarchy. In a theoretical Atom-only hierarchy, "up" and "down" links that point to anything other than Atom documents would simply be ignored by a processor. Defining that Atom-only hierarchy, however, should not restrict the use of those link relations to build other kinds of hierarchies. - James > From owner-atom-syntax@mail.imc.org Wed Jun 10 13:27:37 2009 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 9B1DC3A6C0A for ; Wed, 10 Jun 2009 13:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.113 X-Spam-Level: X-Spam-Status: No, score=-5.113 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 lpGUFWsxa8rW for ; Wed, 10 Jun 2009 13:27:35 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B0A133A6C0E for ; Wed, 10 Jun 2009 13:27:34 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AKGN27066925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 13:16:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AKGNEJ066924; Wed, 10 Jun 2009 13:16:23 -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 acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AKGHG9066917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 13:16:23 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AKH6Vs001933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Jun 2009 20:17:08 GMT Received: from abhmt007.oracle.com (abhmt007.oracle.com [141.146.116.16]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AKHMUJ026001; Wed, 10 Jun 2009 20:17:22 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Jun 2009 13:16:12 -0700 Cc: atom-syntax Syntax Message-Id: <62A113B4-2085-45E8-BE8C-2D2B9C2DA41F@oracle.com> From: "Nikunj R. Mehta" To: James M Snell In-Reply-To: <4A30137F.5020906@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-mehta-atom-inline-00 Date: Wed, 10 Jun 2009 13:14:49 -0700 References: <20090609233744.9A64B3A6A48@core3.amsl.com> <6B1A1BB7-5698-4852-8DE6-F2A06691624B@oracle.com> <4A3000DF.9050604@degeneration.co.uk> <4A30137F.5020906@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt007.oracle.com [141.146.116.16] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A09020A.4A30148D.018D:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Nikunj http://o-micron.blogspot.com On Jun 10, 2009, at 1:11 PM, James M Snell wrote: > > Nikunj R. Mehta wrote: >> >> On Jun 10, 2009, at 11:52 AM, Martin Atkins wrote: >> >>> >>> Nikunj R. Mehta wrote: >>>> Based on feedback, I have split out the in-lining spec in to its >>>> own I-D. HTML: http://tools.ietf.org/html/draft-mehta-atom-inline-00 >>>> Text: http://tools.ietf.org/id/draft-mehta-atom-inline-00.txt >>>> I am also tracking open issues about this I-D publicly at http://code.google.com/p/atom-ext/issues/list >>>> . The source for this I-D is also available, if you are interested. >>>> Looking forward to comments on the I-D. >>> >>> Is it actually necessary to support inlining of resources other >>> than atom feeds and entries? It seems like this adds considerable >>> complexity where I'm not sure that there are compelling use-cases. >> >> I am glad you are speaking up about this. The original proposal for >> in-lining as expressed in draft-divilly-atom-hierarchy-01 was >> rather modest and supported a rather simple use case. >> >> However, per Mark Nottingham et al [1], the use of the ae:inline is >> held up as the right way of extending Atom. Plus, per James Snell >> [2], the inline content's media type is better gleaned from >> ae:inline@type attribute. Also, per Al Brown et al. [3] [4] [5], it >> was more important to ensure maximum flexibility than demonstrate >> specific use cases. >> > To be clear, what I was suggesting was that if you were going to be > pointing to the atom:content rules as the model for processing > ae:inline then it would better for ae:inline to have its own type > attribute distinct from the atom:link elements type attribute. How > to handle things if there is a mismatch between the atom:link/@type > and the ae:inline/@type (or the atom:link/@type and the actual > content type of the linked resource after performing an HTTP GET) is > a separate issue altogether. Do you find the current I-D text satisfactory or do you agree it is more complex than it needs to be? > > Further, it is possible to define the "up" and "down" links > generically, but to define -- separately -- some set of rules that > limit their use to construct an Atom-only hierarchy. In a > theoretical Atom-only hierarchy, "up" and "down" links that point to > anything other than Atom documents would simply be ignored by a > processor. Defining that Atom-only hierarchy, however, should not > restrict the use of those link relations to build other kinds of > hierarchies. I don't think in-lining is restricted to only "up" and "down" anymore. > > - James >> From owner-atom-syntax@mail.imc.org Wed Jun 10 13:33:12 2009 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 525F23A6C16 for ; Wed, 10 Jun 2009 13:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=-1.198, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=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 zjO9LX8fRDjD for ; Wed, 10 Jun 2009 13:33:11 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 361883A6AFE for ; Wed, 10 Jun 2009 13:33:10 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AKM2lr067315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 13:22:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AKM2RP067314; Wed, 10 Jun 2009 13:22:02 -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.156]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AKLpBb067276 for ; Wed, 10 Jun 2009 13:22:02 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by fg-out-1718.google.com with SMTP id e21so376921fga.3 for ; Wed, 10 Jun 2009 13:21:50 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=p3YfAnzdCGB1T/im34G3cdvoLA6e5lcLSEKyeIqlY9A=; b=Ny6lh9/N8HMW3Txei5CJSNrM5ys/KPMKZJwYYUIHqgnQQ1xEl6IJYrR/Zu9V2ZNe5R jpxY33OVbtVw6qbIese/65t0Tw/5V34Yrdk762gqvSumftuT9TERbJQIttB7PAINg9Wl OsZrWibju2orFHMGjCjyRsy2zf5gGyYlAzwNA= 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:content-type:content-transfer-encoding; b=iKCnHrH33KJQ9PtCFicsZ7OY1fBBcYif1UE00DZWv5NM/Z7qsgpgg2bPhtYxbdIU5+ 1xvdPavduVTI/IQ+7/SlWQeGxGunkcpYhykUYWwn42robFhbcIPwUrx5sFOajyvYqHzA NiKizArworgfxb1WRzod8lAEOKPbGyb91FGP0= Received: by 10.216.11.7 with SMTP id 7mr628736wew.125.1244665310054; Wed, 10 Jun 2009 13:21:50 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id q9sm8159095gve.17.2009.06.10.13.21.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 13:21:49 -0700 (PDT) Message-ID: <4A301611.7050603@gmail.com> Date: Wed, 10 Jun 2009 13:22:41 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Nikunj R. Mehta" CC: atom-syntax Syntax Subject: Re: New Version Notification for draft-mehta-atom-inline-00 References: <20090609233744.9A64B3A6A48@core3.amsl.com> <6B1A1BB7-5698-4852-8DE6-F2A06691624B@oracle.com> <4A3000DF.9050604@degeneration.co.uk> <4A30137F.5020906@gmail.com> <62A113B4-2085-45E8-BE8C-2D2B9C2DA41F@oracle.com> In-Reply-To: <62A113B4-2085-45E8-BE8C-2D2B9C2DA41F@oracle.com> 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: Nikunj R. Mehta wrote: > >>> >>> I am glad you are speaking up about this. The original proposal for >>> in-lining as expressed in draft-divilly-atom-hierarchy-01 was rather >>> modest and supported a rather simple use case. >>> >>> However, per Mark Nottingham et al [1], the use of the ae:inline is >>> held up as the right way of extending Atom. Plus, per James Snell >>> [2], the inline content's media type is better gleaned from >>> ae:inline@type attribute. Also, per Al Brown et al. [3] [4] [5], it >>> was more important to ensure maximum flexibility than demonstrate >>> specific use cases. >>> >> To be clear, what I was suggesting was that if you were going to be >> pointing to the atom:content rules as the model for processing >> ae:inline then it would better for ae:inline to have its own type >> attribute distinct from the atom:link elements type attribute. How >> to handle things if there is a mismatch between the atom:link/@type >> and the ae:inline/@type (or the atom:link/@type and the actual >> content type of the linked resource after performing an HTTP GET) is >> a separate issue altogether. > > Do you find the current I-D text satisfactory or do you agree it is > more complex than it needs to be? > For the "up" and "down" links yes, I think it's much better. As for ae:inline, I like that it has been separated out into a separate I-D but I am still definitely on the fence about whether in-lining is even something that should be done. I've never liked the idea of making the Atom syntax hierarchical and I haven't seen anything yet that has convinced me otherwise. - James From owner-atom-syntax@mail.imc.org Wed Jun 10 13:37:15 2009 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 AA6243A67BD for ; Wed, 10 Jun 2009 13:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.104 X-Spam-Level: X-Spam-Status: No, score=-5.104 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 xuAbXwJJxTWf for ; Wed, 10 Jun 2009 13:37:14 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 793BC3A6C14 for ; Wed, 10 Jun 2009 13:37:14 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AKPpGE067512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 13:25:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AKPpQg067511; Wed, 10 Jun 2009 13:25: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 acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AKPjVF067500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 13:25:50 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AKQYRu021162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Jun 2009 20:26:35 GMT Received: from abhmt003.oracle.com (abhmt003.oracle.com [141.146.116.12]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5AKQoNV013063; Wed, 10 Jun 2009 20:26:50 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Jun 2009 13:25:40 -0700 Cc: atom-syntax Syntax Message-Id: <0380ACEE-F9E8-4A04-BA6B-5F5D12C89527@oracle.com> From: "Nikunj R. Mehta" To: James M Snell In-Reply-To: <4A301611.7050603@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-mehta-atom-inline-00 Date: Wed, 10 Jun 2009 13:24:17 -0700 References: <20090609233744.9A64B3A6A48@core3.amsl.com> <6B1A1BB7-5698-4852-8DE6-F2A06691624B@oracle.com> <4A3000DF.9050604@degeneration.co.uk> <4A30137F.5020906@gmail.com> <62A113B4-2085-45E8-BE8C-2D2B9C2DA41F@oracle.com> <4A301611.7050603@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt003.oracle.com [141.146.116.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4A3016C4.031B:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Nikunj http://o-micron.blogspot.com On Jun 10, 2009, at 1:22 PM, James M Snell wrote: > > > Nikunj R. Mehta wrote: >> >>>> >>>> I am glad you are speaking up about this. The original proposal >>>> for in-lining as expressed in draft-divilly-atom-hierarchy-01 was >>>> rather modest and supported a rather simple use case. >>>> >>>> However, per Mark Nottingham et al [1], the use of the ae:inline >>>> is held up as the right way of extending Atom. Plus, per James >>>> Snell [2], the inline content's media type is better gleaned from >>>> ae:inline@type attribute. Also, per Al Brown et al. [3] [4] [5], >>>> it was more important to ensure maximum flexibility than >>>> demonstrate specific use cases. >>>> >>> To be clear, what I was suggesting was that if you were going to >>> be pointing to the atom:content rules as the model for processing >>> ae:inline then it would better for ae:inline to have its own type >>> attribute distinct from the atom:link elements type attribute. >>> How to handle things if there is a mismatch between the atom:link/ >>> @type and the ae:inline/@type (or the atom:link/@type and the >>> actual content type of the linked resource after performing an >>> HTTP GET) is a separate issue altogether. >> >> Do you find the current I-D text satisfactory or do you agree it is >> more complex than it needs to be? >> > For the "up" and "down" links yes, I think it's much better. "up" and "down" links are not defined in atom-inline. This thread is actually seeking feedback on atom-inline only. That leads me to think that you are in favor of the current complexity in the in-line content model. > As for ae:inline, I like that it has been separated out into a > separate I-D but I am still definitely on the fence about whether in- > lining is even something that should be done. I've never liked the > idea of making the Atom syntax hierarchical and I haven't seen > anything yet that has convinced me otherwise. > This is an experimental I-D that seeks to formalize and harmonize what has already been offered commercially. It would be useful to know about your concerns so that we can experimentally validate them. From owner-atom-syntax@mail.imc.org Wed Jun 10 13:49:33 2009 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 544E63A6A59 for ; Wed, 10 Jun 2009 13:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.476 X-Spam-Level: X-Spam-Status: No, score=-0.476 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_35=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 K71M+82waYKL for ; Wed, 10 Jun 2009 13:49:32 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3CB3A3A69B0 for ; Wed, 10 Jun 2009 13:49:32 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AKamIF068035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 13:36:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5AKamjp068034; Wed, 10 Jun 2009 13: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-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AKaaFh068020 for ; Wed, 10 Jun 2009 13:36:47 -0700 (MST) (envelope-from hadrien.gardeur@feedbooks.com) Received: by fxm25 with SMTP id 25so1076061fxm.10 for ; Wed, 10 Jun 2009 13:36:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.123.129 with SMTP id p1mr1689334far.0.1244666196143; Wed, 10 Jun 2009 13:36:36 -0700 (PDT) In-Reply-To: <7D3F8024-3112-4D6B-B0C8-79A7654CB7B7@oracle.com> References: <20090610003357.59F6B3A6916@core3.amsl.com> <7D3F8024-3112-4D6B-B0C8-79A7654CB7B7@oracle.com> From: Hadrien Gardeur Date: Wed, 10 Jun 2009 22:36:15 +0200 Message-ID: <404dcbd20906101336r7eca4b0bwecf3f0c7c33dafff@mail.gmail.com> Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-02 To: "Nikunj R. Mehta" Cc: atom-syntax Syntax Content-Type: multipart/alternative; boundary=001636c5a9ff7c309e046c046eaf Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636c5a9ff7c309e046c046eaf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I'd like to see some recommendations concerning thr:count, now that ah:count isn't in the I-D anymore. Maybe something like: "A link@rel="down" MAY indicate the number of child elements through thr:count [RFC4685]. Atom clients can use this information to decide if they need to GET the entry." And remind this too: http://tools.ietf.org/html/rfc4685#section-6 Hadrien --001636c5a9ff7c309e046c046eaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd like to see some recommendations concerning thr:count, now that ah:= count isn't in the I-D anymore. Maybe something like= : "A link@rel=3D"down" MAY indicate the number of = child elements through thr:count [RFC4685]. Atom clients can use this infor= mation to decide if they need to GET the entry." And remind this too:=C2=A0http://tools.ietf.org/html/rfc4685#section-6 Ha= drien --001636c5a9ff7c309e046c046eaf-- From owner-atom-syntax@mail.imc.org Wed Jun 10 17:45:51 2009 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 0C4D43A68AF for ; Wed, 10 Jun 2009 17:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 l+ZANLKSqwrd for ; Wed, 10 Jun 2009 17:45:50 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id F11B43A68AC for ; Wed, 10 Jun 2009 17:45:49 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5B0XClm079735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 17:33:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5B0XCPq079734; Wed, 10 Jun 2009 17:33: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 ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5B0X0lB079713 for ; Wed, 10 Jun 2009 17:33:10 -0700 (MST) (envelope-from rossfsinger@gmail.com) Received: by ey-out-2122.google.com with SMTP id 25so2716eya.39 for ; Wed, 10 Jun 2009 17:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IoYAgRZ3Pab25tnLIY/AytxQcXH4hYevz514SCS7eKE=; b=jODNzMgWCiQA/EtM27rwh1ToKJrxrA03AMLu4HD99lotsLYpuDq2o7x1YrhuYmLaPf jAAgVcz82Y5v1G1zwx69GVqVeRnghlu6CPQ/GN09ANoSZKZoEhet8CFIDjM22V66H152 2CBopsgfmjod+btYqBDwcHsVFuVxSe09kff50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fC+2BnSnBtYD7NUOKwA9Ggxgs8GBGDrbzxZjjuFsVjSESnlQmwodtGmHE2beKkfT3G gD3CBFhrf7ezzEL0q7tvJX95gKWNTCBQbgW4fvPb0tzkBTnvxcDLX6az2QkPIayV1yLw sP7boIwLUbxfvx/eJGh5SM/4NSkzIYLHFOUz0= MIME-Version: 1.0 Received: by 10.216.8.65 with SMTP id 43mr713421weq.168.1244680379080; Wed, 10 Jun 2009 17:32:59 -0700 (PDT) In-Reply-To: <7b9ad66d0906100039y65db0273l5f060744fa373dbe@mail.gmail.com> References: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> <4A2F00B6.7020504@degeneration.co.uk> <7b9ad66d0906100039y65db0273l5f060744fa373dbe@mail.gmail.com> Date: Wed, 10 Jun 2009 20:32:59 -0400 Message-ID: <23b83f160906101732gd1b0759i32795a75c689ffd7@mail.gmail.com> Subject: Re: Tools not supporting atom:content with @src ? From: Ross Singer To: Peter Krantz Cc: Martin Atkins , atom-syntax@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Out of curiosity, why isn't your entry/id the http URI of your PDF document= ? It seems like you could then have some description in your summary (or anything, really) and pretty much any feed reader would make the title linkable to the PDF. That seems like the fewest hoops to jump through for maximum feed reader support. -Ross. On Wed, Jun 10, 2009 at 3:39 AM, Peter Krantz wrote= : > > On Wed, Jun 10, 2009 at 02:39, Martin Atkins wr= ote: >> >> [...] >> =A0 =A0 >> =A0 =A0 =A0 =A0<a href=3D"/docs/example.pdf">Download PDF</a>= ; >> =A0 =A0 >> =A0 =A0> =A0 =A0 =A0 =A0 =A0href=3D"/docs/example.pdf" >> =A0 =A0 =A0 =A0 =A0type=3D"application/pdf" /> >> > > But this implies that the actual content is " > Oh well. Maybe there could be an appendix some day with > recommendations on how to present Atom in user agents? > > Regards, > > Peter > > From owner-atom-syntax@mail.imc.org Wed Jun 10 19:33:44 2009 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 99C613A6A5B for ; Wed, 10 Jun 2009 19:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.474 X-Spam-Level: X-Spam-Status: No, score=0.474 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] 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 HE19MG6WJJAj for ; Wed, 10 Jun 2009 19:33:43 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 6A67B3A6999 for ; Wed, 10 Jun 2009 19:33:43 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5B2Lm2m085134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 19:21:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5B2LmoW085133; Wed, 10 Jun 2009 19:21: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-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5B2Lbdr085076 for ; Wed, 10 Jun 2009 19:21:48 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by gxk3 with SMTP id 3so4665317gxk.10 for ; Wed, 10 Jun 2009 19:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-rim-org-msg-ref-id :return-receipt-to:message-id:content-transfer-encoding:reply-to :x-priority:sensitivity:importance:to:cc:subject:from:date :content-type:mime-version; bh=KaQvo1/cTPFG9o3Yie8rkV3u4tLoswGrR39kdONDHNk=; b=p3Mu3CCgLmPI4Hges1fpzy22TCach/nHokzYIaBULKiX8b8AURaTAsdZhts1wsQrBm Vis5h3XuHQCYTaI59W0k6tHtTsX8kLE2o5sTULkrMItKGUlJ59raLl2s7Gu1ghskhxC+ eCI88iQOEexYeKsnhp3Mis6Edfi/AWrRDOPu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-rim-org-msg-ref-id:return-receipt-to:message-id :content-transfer-encoding:reply-to:x-priority:sensitivity :importance:to:cc:subject:from:date:content-type:mime-version; b=dnGrbyOgupPz6gJWIwrXOB9+ivYlUSVnvLFjN4jusrWijnuQJrdUKcLuQyL2VX6CGf QZKstsdXN5/WDxxoFVib7QZJCY3M4wsdLo1044Gvtzyx1UtBlN2WOfEIsmvjIaMe1FT/ iYiCb3/pfGPqEk6DfkNAY5iGsalCS+aD0UAc8= Received: by 10.90.88.16 with SMTP id l16mr1657673agb.112.1244686897070; Wed, 10 Jun 2009 19:21:37 -0700 (PDT) Received: from bda703.bisx.prod.on.blackberry (e703.bda.bis.na.blackberry.com [67.223.79.112]) by mx.google.com with ESMTPS id 10sm2769864agb.36.2009.06.10.19.21.35 (version=SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 19:21:36 -0700 (PDT) X-rim-org-msg-ref-id:679883653 Message-ID:<679883653-1244686894-cardhu_decombobulator_blackberry.rim.net-1920381544-@bxe1007.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 Reply-To: jasnell@gmail.com X-Priority: Normal Sensitivity: Normal Importance: Normal To: "Nikunj R. Mehta" Cc: "atom-syntax Syntax" Subject: Re: New Version Notification for draft-mehta-atom-inline-00 From: jasnell@gmail.com Date: Thu, 11 Jun 2009 02:21:34 +0000 Content-Type: text/plain MIME-Version: 1.0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: V2hhdCBJIHNhaWQgd2FzIHZlcnkgY2xlYXIuLi4gSXQgaXMgc2ltcGx5IHRoaXM6IElGIHlvdSBh cmUgZ29pbmcgdG8gZGVmaW5lIGFlOmlubGluZSBpbiB0ZXJtcyBvZiBhdG9tOmNvbnRlbnQgdGhl biB5b3UgbXVzdCBhY2NlcHQgdGhlIGFkZGVkIGNvbXBsZXhpdHkgdGhhdCByZXF1aXJlcy4gSG93 ZXZlciwgcGVyc29uYWxseSBJJ20gbm90IGNvbnZpbmNlZCB0aGF0IGFlOmlubGluZSBpcyBhIGdv b2QgaWRlYSBpbiBhbnkgZm9ybSBvciB3aXRoIGFueSBsZXZlbCBvZiBjb21wbGV4aXR5LiBUaGUg bm9uLXRoZW9yZXRpY2FsIGJlbmVmaXRzIG9mIGEgZ2VuZXJpYyBhZTppbmxpbmUgb3Igb2YgYSBo aWVyYXJjaGljYWwgYXRvbSBzeW50YXggaGF2ZSBlc2NhcGVkIG1lIHRodXMgZmFyLiAKCi0gSmFt ZXMKCi0tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLS0KRnJvbTogTmlrdW5qIFIuIE1laHRhClRv OiBKYW1lcyBNIFNuZWxsCkNjOiBhdG9tLXN5bnRheCBTeW50YXgKU3ViamVjdDogUmU6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWVodGEtYXRvbS1pbmxpbmUtMDAKU2VudDog SnVuIDEwLCAyMDA5IDE6MjQgUE0KCgpOaWt1bmoKaHR0cDovL28tbWljcm9uLmJsb2dzcG90LmNv bQoKCgpPbiBKdW4gMTAsIDIwMDksIGF0IDE6MjIgUE0sIEphbWVzIE0gU25lbGwgd3JvdGU6Cgo+ Cj4KPiBOaWt1bmogUi4gTWVodGEgd3JvdGU6Cj4+IDxzbmlwPgo+Pj4+Cj4+Pj4gSSBhbSBnbGFk IHlvdSBhcmUgc3BlYWtpbmcgdXAgYWJvdXQgdGhpcy4gVGhlIG9yaWdpbmFsIHByb3Bvc2FsICAK Pj4+PiBmb3IgaW4tbGluaW5nIGFzIGV4cHJlc3NlZCBpbiBkcmFmdC1kaXZpbGx5LWF0b20taGll cmFyY2h5LTAxIHdhcyAgCj4+Pj4gcmF0aGVyIG1vZGVzdCBhbmQgc3VwcG9ydGVkIGEgcmF0aGVy IHNpbXBsZSB1c2UgY2FzZS4KPj4+Pgo+Pj4+IEhvd2V2ZXIsIHBlciBNYXJrIE5vdHRpbmdoYW0g ZXQgYWwgWzFdLCB0aGUgdXNlIG9mIHRoZSBhZTppbmxpbmUgIAo+Pj4+IGlzIGhlbGQgdXAgYXMg dGhlIHJpZ2h0IHdheSBvZiBleHRlbmRpbmcgQXRvbS4gUGx1cywgcGVyIEphbWVzICAKPj4+PiBT bmVsbCBbMl0sIHRoZSBpbmxpbmUgY29udGVudCdzIG1lZGlhIHR5cGUgaXMgYmV0dGVyIGdsZWFu ZWQgZnJvbSAgCj4+Pj4gYWU6aW5saW5lQHR5cGUgYXR0cmlidXRlLiBBbHNvLCBwZXIgQWwgQnJv d24gZXQgYWwuIFszXSBbNF0gWzVdLCAgCj4+Pj4gaXQgd2FzIG1vcmUgaW1wb3J0YW50IHRvIGVu c3VyZSBtYXhpbXVtIGZsZXhpYmlsaXR5IHRoYW4gIAo+Pj4+IGRlbW9uc3RyYXRlIHNwZWNpZmlj IHVzZSBjYXNlcy4KPj4+Pgo+Pj4gVG8gYmUgY2xlYXIsIHdoYXQgSSB3YXMgc3VnZ2VzdGluZyB3 YXMgdGhhdCBpZiB5b3Ugd2VyZSBnb2luZyB0byAgCj4+PiBiZSBwb2ludGluZyB0byB0aGUgYXRv bTpjb250ZW50IHJ1bGVzIGFzIHRoZSBtb2RlbCBmb3IgcHJvY2Vzc2luZyAgCj4+PiBhZTppbmxp bmUgdGhlbiBpdCB3b3VsZCBiZXR0ZXIgZm9yIGFlOmlubGluZSB0byBoYXZlIGl0cyBvd24gdHlw ZSAgCj4+PiBhdHRyaWJ1dGUgZGlzdGluY3QgZnJvbSB0aGUgYXRvbTpsaW5rIGVsZW1lbnRzIHR5 cGUgYXR0cmlidXRlLiAgIAo+Pj4gSG93IHRvIGhhbmRsZSB0aGluZ3MgaWYgdGhlcmUgaXMgYSBt aXNtYXRjaCBiZXR3ZWVuIHRoZSBhdG9tOmxpbmsvIAo+Pj4gQHR5cGUgYW5kIHRoZSBhZTppbmxp bmUvQHR5cGUgKG9yIHRoZSBhdG9tOmxpbmsvQHR5cGUgYW5kIHRoZSAgCj4+PiBhY3R1YWwgY29u dGVudCB0eXBlIG9mIHRoZSBsaW5rZWQgcmVzb3VyY2UgYWZ0ZXIgcGVyZm9ybWluZyBhbiAgCj4+ PiBIVFRQIEdFVCkgaXMgYSBzZXBhcmF0ZSBpc3N1ZSBhbHRvZ2V0aGVyLgo+Pgo+PiBEbyB5b3Ug ZmluZCB0aGUgY3VycmVudCBJLUQgdGV4dCBzYXRpc2ZhY3Rvcnkgb3IgZG8geW91IGFncmVlIGl0 IGlzICAKPj4gbW9yZSBjb21wbGV4IHRoYW4gaXQgbmVlZHMgdG8gYmU/Cj4+Cj4gRm9yIHRoZSAi dXAiIGFuZCAiZG93biIgbGlua3MgeWVzLCBJIHRoaW5rIGl0J3MgbXVjaCBiZXR0ZXIuCgoidXAi IGFuZCAiZG93biIgbGlua3MgYXJlIG5vdCBkZWZpbmVkIGluIGF0b20taW5saW5lLiBUaGlzIHRo cmVhZCBpcyAgCmFjdHVhbGx5IHNlZWtpbmcgZmVlZGJhY2sgb24gYXRvbS1pbmxpbmUgb25seS4g VGhhdCBsZWFkcyBtZSB0byB0aGluayAgCnRoYXQgeW91IGFyZSBpbiBmYXZvciBvZiB0aGUgY3Vy cmVudCBjb21wbGV4aXR5IGluIHRoZSBpbi1saW5lIGNvbnRlbnQgIAptb2RlbC4KCj4gQXMgZm9y IGFlOmlubGluZSwgSSBsaWtlIHRoYXQgaXQgaGFzIGJlZW4gc2VwYXJhdGVkIG91dCBpbnRvIGEg IAo+IHNlcGFyYXRlIEktRCBidXQgSSBhbSBzdGlsbCBkZWZpbml0ZWx5IG9uIHRoZSBmZW5jZSBh Ym91dCB3aGV0aGVyIGluLSAKPiBsaW5pbmcgaXMgZXZlbiBzb21ldGhpbmcgdGhhdCBzaG91bGQg YmUgZG9uZS4gSSd2ZSBuZXZlciBsaWtlZCB0aGUgIAo+IGlkZWEgb2YgbWFraW5nIHRoZSBBdG9t IHN5bnRheCBoaWVyYXJjaGljYWwgYW5kIEkgaGF2ZW4ndCBzZWVuICAKPiBhbnl0aGluZyB5ZXQg dGhhdCBoYXMgY29udmluY2VkIG1lIG90aGVyd2lzZS4KPgoKVGhpcyBpcyBhbiBleHBlcmltZW50 YWwgSS1EIHRoYXQgc2Vla3MgdG8gZm9ybWFsaXplIGFuZCBoYXJtb25pemUgd2hhdCAgCmhhcyBh bHJlYWR5IGJlZW4gb2ZmZXJlZCBjb21tZXJjaWFsbHkuIEl0IHdvdWxkIGJlIHVzZWZ1bCB0byBr bm93ICAKYWJvdXQgeW91ciBjb25jZXJucyBzbyB0aGF0IHdlIGNhbiBleHBlcmltZW50YWxseSB2 YWxpZGF0ZSB0aGVtLgoKCg0KU2VudCBmcm9tIG15IFZlcml6b24gV2lyZWxlc3MgQmxhY2tCZXJy eQ== From owner-atom-syntax@mail.imc.org Wed Jun 10 22:06:53 2009 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 89CA23A6A5C for ; Wed, 10 Jun 2009 22:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSY0yzHayJJj for ; Wed, 10 Jun 2009 22:06:46 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D0F783A67A7 for ; Wed, 10 Jun 2009 22:06:44 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5B4sxHV091566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 21:54:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5B4sxNa091565; Wed, 10 Jun 2009 21:54:59 -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 mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5B4sko2091556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Jun 2009 21:54:57 -0700 (MST) (envelope-from Davis_Cornelia@emc.com) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n5B4sj8u011090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 00:54:45 -0400 (EDT) From: Davis_Cornelia@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Thu, 11 Jun 2009 00:54:33 -0400 Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n5B4sXtP028389; Thu, 11 Jun 2009 00:54:33 -0400 Received: from CORPUSMX20B.corp.emc.com ([128.221.62.12]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 00:54:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EA4F.BBC43E8E" Subject: RE: New Version Notification for draft-divilly-atom-hierarchy-02 Date: Thu, 11 Jun 2009 00:47:32 -0400 Message-ID: <7AAE36EDD1ECFA4494AA25ADA2338C8501A1DFBE@CORPUSMX20B.corp.emc.com> In-Reply-To: <7D3F8024-3112-4D6B-B0C8-79A7654CB7B7@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-divilly-atom-hierarchy-02 Thread-Index: Acnp7aZb+d7x3rTeRBWFfxrxabxIpgAWsAVw References: <20090610003357.59F6B3A6916@core3.amsl.com> <7D3F8024-3112-4D6B-B0C8-79A7654CB7B7@oracle.com> To: , X-OriginalArrivalTime: 11 Jun 2009 04:54:32.0892 (UTC) FILETIME=[B6064FC0:01C9EA50] X-EMM-EM: Active Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EA4F.BBC43E8E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I ask your forgiveness for rehashing an old (a few days old) topic - the suggestion that James Snell made for using a media-type profile to distinguish between an entry's children and an entry's descendants. I think I get it but want to run this by the group for confirmation. =20 In the following (from James): =20 > = =20 a value of profile=3Dflat is used to indicate that we want the children = to be represented without any expansion and a value of profile=3Dtree is = used to indicate that we want the children to be represented with a potential expansion. I confess that initially I thought that this wasn't a mimetype issue, that we were talking about two different resources - the set of children and the set of descendants. But what is proposed here is far more elegant, and is nicely cast as a mime-type choice. The key is that the link relation "down" only ever returns a child (as application/atom+xml;type=3Dentry) or a feed containing _only children_ (as application/atom+xml;type=3Dfeed) - what differs is the = representation format of that child (expanded or not). =20 Sound right? =20 And yes, I understand that the mime types and profile designators are most definitely outside the scope of this I-D. =20 Thanks, Cornelia =20 Cornelia Davis Senior Technologist EMC Corporation, Office of the CTO davis_cornelia@emc.com p: 805.560.9039 m: 805.452.8941 f: 805.880.0390 ________________________________ From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Nikunj R. Mehta Sent: Wednesday, June 10, 2009 9:58 AM To: atom-syntax Syntax Subject: Fwd: New Version Notification for draft-divilly-atom-hierarchy-02=20 =20 Based on feedback, I have simplified the I-D to: In-line extensions moved to draft-mehta-atom-inline Removed down-tree and up-tree relations Removed cardinality restrictions on up and down links =20 HTML: http://tools.ietf.org/html/draft-divilly-atom-hierarchy-02 Text: http://tools.ietf.org/id/draft-divilly-atom-hierarchy-02.txt =20 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-divilly-atom-hierarchy-02.txt =20 I am also tracking open issues about this I-D publicly at http://code.google.com/p/atom-ext/issues/list. The source for this I-D is also available, if you are interested. =20 Looking forward to comments on the I-D. =20 Nikunj http://o-micron.blogspot.com =20 =20 =20 Begin forwarded message: From: IETF I-D Submission Tool Date: June 9, 2009 5:33:57 PM PDT To: nikunj.mehta@oracle.com Cc: colm.divilly@oracle.com Subject: New Version Notification for draft-divilly-atom-hierarchy-02=20 =20 A new version of I-D, draft-divilly-atom-hierarchy-02.txt has been successfuly submitted by Nikunj Mehta and posted to the IETF repository. Filename: draft-divilly-atom-hierarchy Revision: 02 Title: Hierarchy Relations for Atom Creation_date: 2009-06-09 WG ID: Independent Submission Number_of_pages: 7 Abstract: This specification defines link relations for hierarchical navigation among Atom feeds and entries.Editorial Note To provide feedback on this Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1]. The IETF Secretariat. =20 ------_=_NextPart_001_01C9EA4F.BBC43E8E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I ask your forgiveness for = rehashing an old (a few days old) topic – the suggestion that James Snell made = for using a media-type profile to distinguish between an entry’s = children and an entry’s descendants. I think I get it but want to run = this by the group for confirmation. In the following (from = James): > <link = rel=3D"down" type=3D"application/atom+xml;type=3Dfeed;profile=3Dtree" href=3D"..." /> <link rel=3D"down" type=3D"application/atom+xml;type=3Dfeed;profile=3Dflat" href=3D"..." /> a value of profile=3Dflat is used = to indicate that we want the children to be represented without any = expansion and a value of profile=3Dtree is used to indicate that we want the children = to be represented with a potential expansion. I confess that initially I thought that this wasn’t a mimetype issue, that we were talking = about two different resources – the set of children and the set of = descendants. But what is proposed here is far more elegant, and is nicely cast = as a mime-type choice. The key is that the link relation = “down” only ever returns a child (as application/atom+xml;type=3Dentry) or a feed containing _only children_ (as application/atom+xml;type=3Dfeed= ) – what differs is the representation format of that = child (expanded or not). Sound = right? And yes, I understand that the mime = types and profile designators are most definitely outside the scope of this = I-D. Thanks,= Cornelia = Cornelia Davis Senior Technologist EMC Corporation, Office of the CTO davis_cornelia@emc.com= p: 805.560.9039 m: 805.452.8941 f: 805.880.0390 From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] = On Behalf Of Nikunj R. Mehta Sent: Wednesday, June 10, = 2009 9:58 AM To: atom-syntax = Syntax Subject: Fwd: New Version Notification for draft-divilly-atom-hierarchy-02 = Based on = feedback, I have simplified the I-D to: In-line extensions moved to = draft-mehta-atom-inline Removed down-tree and up-tree = relations Removed cardinality restrictions on up = and down links HTML: http:= //tools.ietf.org/html/draft-divilly-atom-hierarchy-02 Text: http://t= ools.ietf.org/id/draft-divilly-atom-hierarchy-02.txt Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-divilly-atom-hierarch= y-02.txt I am also tracking open issues about this&nbs= p;I-D publicly at http://code.google= .com/p/atom-ext/issues/list. The source for this I-D is also available, if you are = interested. Looking forward to comments on the = I-D. Nikunj http://o-micron.blogspot.com Begin forwarded message: From: IETF I-D Submission Tool <idsubmission@ietf.org> Date: June 9, 2009 5:33:57 PM = PDT To: nikunj.mehta@oracle.com Cc: colm.divilly@oracle.com Subject: New Version Notification for draft-divilly-atom-hierarchy-02 <= /p> A new version of I-D, draft-divilly-atom-hierarchy-02.txt has been = successfuly submitted by Nikunj Mehta and posted to the IETF repository. Filename: &n= bsp; draft-divilly-atom-hierarchy Revision: &n= bsp; 02 Title: &n= bsp; Hierarchy Relations for Atom Creation_date: 2009-06-09 WG ID: &n= bsp; &nb= sp; Independent Submission Number_of_pages: 7 Abstract: This specification defines link relations for hierarchical = navigation among Atom feeds and entries.Editorial Note To provide feedback on this Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/<= /a>) [1]. The IETF Secretariat. ------_=_NextPart_001_01C9EA4F.BBC43E8E-- From owner-atom-syntax@mail.imc.org Thu Jun 11 01:01:11 2009 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 CBC793A6B4E for ; Thu, 11 Jun 2009 01:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 wXWaZzizrOFk for ; Thu, 11 Jun 2009 01:01:10 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 859733A6841 for ; Thu, 11 Jun 2009 01:01:09 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5B7la1W099125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 00:47:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5B7la5l099124; Thu, 11 Jun 2009 00:47:36 -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-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5B7lNXP099112 for ; Thu, 11 Jun 2009 00:47:35 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by bwz22 with SMTP id 22so1310450bwz.10 for ; Thu, 11 Jun 2009 00:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kcqdFTPwRuY5iyV4xkOetYOHotJn1AyFtguYqoP4ksY=; b=BbVSe/WAibHhoWmlUiizu5Qjb/XpDr3gGAQ87gaV3cFhID6ImyD5jNhGJeNfKijyIv P8fBF+Yh50CCAWtBEvKZfmBwESUAhWM9pNOdTQ9uZUDsJCq1OymWuHYFxh1nZ0N0PUIQ WjRSCNzUbII2vP8Znr2n7+kU92Rko/bUE1PH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wk3+NWo7mVyznEAHCPbfwsbzteS9nj5icdtkF3P0g5R1qJeLTojQBYtthZxJifSj2A 1GL2tuC6n6HfkfZCscoLtfXq0w74Vgxvqfs6vlth46+avyGa71UKR1JNX5wVO5evJo7k k8ovXuHZOfcxZjE464hKGQEh8ftMwjyDRsfHM= MIME-Version: 1.0 Received: by 10.223.126.1 with SMTP id a1mr1989545fas.52.1244706443067; Thu, 11 Jun 2009 00:47:23 -0700 (PDT) In-Reply-To: <23b83f160906101732gd1b0759i32795a75c689ffd7@mail.gmail.com> References: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> <4A2F00B6.7020504@degeneration.co.uk> <7b9ad66d0906100039y65db0273l5f060744fa373dbe@mail.gmail.com> <23b83f160906101732gd1b0759i32795a75c689ffd7@mail.gmail.com> Date: Thu, 11 Jun 2009 09:47:23 +0200 Message-ID: Subject: Re: Tools not supporting atom:content with @src ? From: Thomas Broyer To: Ross Singer Cc: Atom-Syntax Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 11, 2009 at 2:32 AM, Ross Singer wrote: > > Out of curiosity, why isn't your entry/id the http URI of your PDF document? > > It seems like you could then have some description in your summary (or > anything, really) and pretty much any feed reader would make the title > linkable to the PDF. I hope not! Repeat after me: entry/id is *not* a link, it's just an ID that happens to have the form of an URI. (this is different from RSS when the ID can be --defaults to?-- the "permalink") would obviously work as you describe (and has already been proposed in this thread) -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Jun 11 06:27:04 2009 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 5A6AF3A6A7B for ; Thu, 11 Jun 2009 06:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Sg9YOHZ8W99F for ; Thu, 11 Jun 2009 06:27:03 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0DD253A68B5 for ; Thu, 11 Jun 2009 06:27:02 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BDBflg018390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 06:11:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BDBfUm018389; Thu, 11 Jun 2009 06:11: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-ew0-f217.google.com (mail-ew0-f217.google.com [209.85.219.217]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BDBTDb018374 for ; Thu, 11 Jun 2009 06:11:40 -0700 (MST) (envelope-from rossfsinger@gmail.com) Received: by ewy17 with SMTP id 17so1684639ewy.10 for ; Thu, 11 Jun 2009 06:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QLEKAU0LHFEx0Yr6SKhCqaa+rxj0BS0fq+jvKS7T6u0=; b=iJCElgMtHgXL78ivkoYdgjlx6Tvzw8oBQTHCcRN4J1UVMtTTffTJy76XwzyO7O5Mk8 4ub7m3csdt+dtEmRruBfey2yBAsZKleQ1eH5uUsd7V1uDobm4VZ1/Btny6LYM3JoklRr kDw7oWI4f3/WS3XSLPDYt6nFWtK2yE7eKTcMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YOUbfg3bLYMIrRCTVSlWpIn8Y5rMEPH2OGtVn5054Lh457Vp9PnsslresHZiHgYeTs mnGE80p25OsPZN0jkosgdhg5HTueqTC5MPjJ2nGS+N4PY/bLLyzGApacFRhS8uIZ0Px3 kgpWzK5e+R/EC5Mx41Ocsq+JhlIpn2+K9ECLY= MIME-Version: 1.0 Received: by 10.216.39.85 with SMTP id c63mr922602web.103.1244725888511; Thu, 11 Jun 2009 06:11:28 -0700 (PDT) In-Reply-To: References: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> <4A2F00B6.7020504@degeneration.co.uk> <7b9ad66d0906100039y65db0273l5f060744fa373dbe@mail.gmail.com> <23b83f160906101732gd1b0759i32795a75c689ffd7@mail.gmail.com> Date: Thu, 11 Jun 2009 09:11:28 -0400 Message-ID: <23b83f160906110611p65100c2bsa7fdf9a5731decf2@mail.gmail.com> Subject: Re: Tools not supporting atom:content with @src ? From: Ross Singer To: Thomas Broyer Cc: Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Wasn't the question how to make this work with popular feed readers? Is anything I wrote not true in that regard? Also, what argument are you making against using the http URI the identifier? I understand if the tag URI is necessary for internal reasons for the application, but if the http URI is, indeed, a viable identifier for the resource... why not use that? -Ross. On Thu, Jun 11, 2009 at 3:47 AM, Thomas Broyer wrote: > On Thu, Jun 11, 2009 at 2:32 AM, Ross Singer wrote: >> >> Out of curiosity, why isn't your entry/id the http URI of your PDF document? >> >> It seems like you could then have some description in your summary (or >> anything, really) and pretty much any feed reader would make the title >> linkable to the PDF. > > I hope not! > Repeat after me: entry/id is *not* a link, it's just an ID that > happens to have the form of an URI. > (this is different from RSS when the ID can be --defaults to?-- the "permalink") > > would obviously work as you > describe (and has already been proposed in this thread) > > > -- > Thomas Broyer > From owner-atom-syntax@mail.imc.org Thu Jun 11 08:15:35 2009 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 8A9203A691C for ; Thu, 11 Jun 2009 08:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 rkZDSlgHLN7J for ; Thu, 11 Jun 2009 08:15:34 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8F37E3A6CA7 for ; Thu, 11 Jun 2009 08:15:34 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BExWcA025032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 07:59:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BExWFM025031; Thu, 11 Jun 2009 07:59:32 -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-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BExLvX025021 for ; Thu, 11 Jun 2009 07:59:32 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by fxm25 with SMTP id 25so1568873fxm.10 for ; Thu, 11 Jun 2009 07:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pn+y1UVJFLI9RS1ngZRJl0eB7m8Y1wIXSfuVmjabSJQ=; b=eqIauLdgHwhIBYMTLPEZ6jASSEDm/pzqHCtjAJ0jTNQ4Q6wnho2P0vWNsZ3q7tzfYd YVWtriM//Z0wCKjwAAmmo1xjC5k1TusvmtWb/MtZ6P7WAZdw8anxUvp3F7Wrby0TZQ/b dM1i/cObsl6Xqlacd1n1HhYVOod3KvTYTyRKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TnNl3Az1/16HPCC/oUqunT01ToIII+14aOmzsG0z0KxMhsnWz2lSY9QR8ihdjQaI2A pAspS8pjb4su59GlIt7v11UC81NJDSPPQITWggzySQEufeK9ntD9vF3y2Dv4lz7riPf3 11u9Cqkvh44LLnkBjFpA5XDv7iGSUf2PyG1Yk= MIME-Version: 1.0 Received: by 10.223.105.16 with SMTP id r16mr2317926fao.24.1244732360370; Thu, 11 Jun 2009 07:59:20 -0700 (PDT) In-Reply-To: <23b83f160906110611p65100c2bsa7fdf9a5731decf2@mail.gmail.com> References: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> <4A2F00B6.7020504@degeneration.co.uk> <7b9ad66d0906100039y65db0273l5f060744fa373dbe@mail.gmail.com> <23b83f160906101732gd1b0759i32795a75c689ffd7@mail.gmail.com> <23b83f160906110611p65100c2bsa7fdf9a5731decf2@mail.gmail.com> Date: Thu, 11 Jun 2009 16:59:20 +0200 Message-ID: Subject: Re: Tools not supporting atom:content with @src ? From: Thomas Broyer To: Ross Singer Cc: Atom-Syntax Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 11, 2009 at 3:11 PM, Ross Singer wrote: > Wasn't the question how to make this work with popular feed readers? > > Is anything I wrote not true in that regard? I *hope* feed readers do not use entry/id as a permalink (in the absence of any link); I don't know how popular feed readers actually work (never tested). > Also, what argument are you making against using the http URI the > identifier? =C2=A0I understand if the tag URI is necessary for internal > reasons for the application, but if the http URI is, indeed, a viable > identifier for the resource... why not use that? The problem is not really using the "permalink" as the entry identifier, but using the identifier as a permalink! --=20 Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Jun 11 08:57:22 2009 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 61D243A6D07 for ; Thu, 11 Jun 2009 08:57:22 -0700 (PDT) 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.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_BASE64_TEXT=1.753] 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 X1TwZeGHYaiA for ; Thu, 11 Jun 2009 08:57:16 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 434943A6955 for ; Thu, 11 Jun 2009 08:57:15 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BFhMtE027630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 08:43:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BFhMpM027629; Thu, 11 Jun 2009 08:43: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 yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.153]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BFhAHT027599 for ; Thu, 11 Jun 2009 08:43:21 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by yw-out-1718.google.com with SMTP id 6so794160ywa.4 for ; Thu, 11 Jun 2009 08:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-rim-org-msg-ref-id :return-receipt-to:message-id:reply-to:x-priority:references :in-reply-to:sensitivity:importance:to:subject:from:date :content-type:mime-version; bh=gWzuBr3woEc0wUGZNuXQnOnXgK2giAGCksFE9WfM/3I=; b=gFb1Dw04bBh5nysAgg9z4uohh1g0qHSDfc3dGkFQaFsylCUSaUxyWMw48bft+v0IIf mTiFHFGd4Y3DbvkisKFsOXpu5qKdB+XGK2N2MdLrrKeT3K9HGJh9Z7pqssaz3kFbeZ4G HNQdRdt39e/QkiV2PdcM7lssGD2swxUdn5qsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-rim-org-msg-ref-id:return-receipt-to:message-id:reply-to :x-priority:references:in-reply-to:sensitivity:importance:to:subject :from:date:content-type:mime-version; b=S41zuTf+Bu3TPr3KTjiFIlI5bVFLlbIMeZ61JheGBLDTj8ifK7rfmkqQhxRizHeBbd Qgo7kZ+T7eR5ncONxcWqY7cyXJ7W8bcQHBlwWx4UZ0fkVANh45FMNBBu6qVjMKno4Vc9 FUddEWz7FDm4uwAWbSi/OCdENOn04Jo5Hco9M= Received: by 10.90.26.3 with SMTP id 3mr2262777agz.27.1244734989891; Thu, 11 Jun 2009 08:43:09 -0700 (PDT) Received: from bda703.bisx.prod.on.blackberry (e703.bda.bis.na.blackberry.com [67.223.79.112]) by mx.google.com with ESMTPS id 11sm402446aga.70.2009.06.11.08.43.08 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Jun 2009 08:43:08 -0700 (PDT) X-rim-org-msg-ref-id:2007080839 Message-ID:<2007080839-1244734918-cardhu_decombobulator_blackberry.rim.net-924508906-@bxe1007.bisx.prod.on.blackberry> Reply-To: jasnell@gmail.com X-Priority: Normal References: <20090610003357.59F6B3A6916@core3.amsl.com> <7D3F8024-3112-4D6B-B0C8-79A7654CB7B7@oracle.com><7AAE36EDD1ECFA4494AA25ADA2338C8501A1DFBE@CORPUSMX20B.corp.emc.com> In-Reply-To: <7AAE36EDD1ECFA4494AA25ADA2338C8501A1DFBE@CORPUSMX20B.corp.emc.com> Sensitivity: Normal Importance: Normal To: Davis_Cornelia@emc.com, owner-atom-syntax@mail.imc.org, nikunj.mehta@oracle.com, atom-syntax@imc.org Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-02 From: jasnell@gmail.com Date: Thu, 11 Jun 2009 15:41:58 +0000 Content-Type: multipart/alternative; boundary="part158790-boundary-1574582474-1848417798" MIME-Version: 1.0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --part158790-boundary-1574582474-1848417798 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="Windows-1252" WWVzIHlvdXIgaW50ZXJwcmV0YXRpb24gaXMgY29ycmVjdC4gDQpTZW50IGZyb20gbXkgVmVyaXpv biBXaXJlbGVzcyBCbGFja0JlcnJ5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBEYXZpc19Db3JuZWxpYUBlbWMuY29tDQoNCkRhdGU6IFRodSwgMTEgSnVuIDIwMDkgMDA6NDc6 MzIgDQpUbzogPG5pa3Vuai5tZWh0YUBvcmFjbGUuY29tPjsgPGF0b20tc3ludGF4QGltYy5vcmc+ DQpTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kaXZpbGx5 LWF0b20taGllcmFyY2h5LTAyIA0KDQoNCkkgYXNrIHlvdXIgZm9yZ2l2ZW5lc3MgZm9yIHJlaGFz aGluZyBhbiBvbGQgKGEgZmV3IGRheXMgb2xkKSB0b3BpYyAtIHRoZQ0Kc3VnZ2VzdGlvbiB0aGF0 IEphbWVzIFNuZWxsIG1hZGUgZm9yIHVzaW5nIGEgbWVkaWEtdHlwZSBwcm9maWxlIHRvDQpkaXN0 aW5ndWlzaCBiZXR3ZWVuIGFuIGVudHJ5J3MgY2hpbGRyZW4gYW5kIGFuIGVudHJ5J3MgZGVzY2Vu ZGFudHMuICBJDQp0aGluayBJIGdldCBpdCBidXQgd2FudCB0byBydW4gdGhpcyBieSB0aGUgZ3Jv dXAgZm9yIGNvbmZpcm1hdGlvbi4NCg0KIA0KDQpJbiB0aGUgZm9sbG93aW5nIChmcm9tIEphbWVz KToNCg0KIA0KDQo+IDxsaW5rIHJlbD0iZG93biIgdHlwZT0iYXBwbGljYXRpb24vYXRvbSt4bWw7 dHlwZT1mZWVkO3Byb2ZpbGU9dHJlZSINCmhyZWY9Ii4uLiIgLz4gPGxpbmsgcmVsPSJkb3duIg0K dHlwZT0iYXBwbGljYXRpb24vYXRvbSt4bWw7dHlwZT1mZWVkO3Byb2ZpbGU9ZmxhdCIgaHJlZj0i Li4uIiAvPiANCg0KICANCg0KYSB2YWx1ZSBvZiBwcm9maWxlPWZsYXQgaXMgdXNlZCB0byBpbmRp Y2F0ZSB0aGF0IHdlIHdhbnQgdGhlIGNoaWxkcmVuIHRvDQpiZSByZXByZXNlbnRlZCB3aXRob3V0 IGFueSBleHBhbnNpb24gYW5kIGEgdmFsdWUgb2YgcHJvZmlsZT10cmVlIGlzIHVzZWQNCnRvIGlu ZGljYXRlIHRoYXQgd2Ugd2FudCB0aGUgY2hpbGRyZW4gdG8gYmUgcmVwcmVzZW50ZWQgd2l0aCBh IHBvdGVudGlhbA0KZXhwYW5zaW9uLiAgSSBjb25mZXNzIHRoYXQgaW5pdGlhbGx5IEkgdGhvdWdo dCB0aGF0IHRoaXMgd2Fzbid0IGENCm1pbWV0eXBlIGlzc3VlLCB0aGF0IHdlIHdlcmUgdGFsa2lu ZyBhYm91dCB0d28gZGlmZmVyZW50IHJlc291cmNlcyAtIHRoZQ0Kc2V0IG9mIGNoaWxkcmVuIGFu ZCB0aGUgc2V0IG9mIGRlc2NlbmRhbnRzLiAgQnV0ICB3aGF0IGlzIHByb3Bvc2VkIGhlcmUNCmlz IGZhciBtb3JlIGVsZWdhbnQsIGFuZCBpcyBuaWNlbHkgY2FzdCBhcyBhIG1pbWUtdHlwZSBjaG9p Y2UuICBUaGUga2V5DQppcyB0aGF0IHRoZSBsaW5rIHJlbGF0aW9uICJkb3duIiBvbmx5IGV2ZXIg cmV0dXJucyBhIGNoaWxkIChhcw0KYXBwbGljYXRpb24vYXRvbSt4bWw7dHlwZT1lbnRyeSkgb3Ig YSBmZWVkIGNvbnRhaW5pbmdfb25seSBjaGlsZHJlbl8NCihhcyBhcHBsaWNhdGlvbi9hdG9tK3ht bDt0eXBlPWZlZWQpIC0gd2hhdCBkaWZmZXJzIGlzIHRoZSByZXByZXNlbnRhdGlvbg0KZm9ybWF0 IG9mIHRoYXQgY2hpbGQgKGV4cGFuZGVkIG9yIG5vdCkuDQoNCiANCg0KU291bmQgcmlnaHQ/DQoN CiANCg0KQW5kIHllcywgSSB1bmRlcnN0YW5kIHRoYXQgdGhlIG1pbWUgdHlwZXMgYW5kIHByb2Zp bGUgZGVzaWduYXRvcnMgYXJlDQptb3N0IGRlZmluaXRlbHkgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhpcyBJLUQuDQoNCiANCg0KVGhhbmtzLA0KDQpDb3JuZWxpYQ0KDQogDQoNCkNvcm5lbGlhIERh dmlzDQoNClNlbmlvciBUZWNobm9sb2dpc3QNCg0KRU1DIENvcnBvcmF0aW9uLCBPZmZpY2Ugb2Yg dGhlIENUTw0KZGF2aXNfY29ybmVsaWFAZW1jLmNvbQ0KcDogODA1LjU2MC45MDM5DQptOiA4MDUu NDUyLjg5NDENCmY6IDgwNS44ODAuMDM5MA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpGcm9tOiBvd25lci1hdG9tLXN5bnRheEBtYWlsLmltYy5vcmcNClttYWlsdG86b3du ZXItYXRvbS1zeW50YXhAbWFpbC5pbWMub3JnXSBPbiBCZWhhbGYgT2YgTmlrdW5qIFIuIE1laHRh DQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMTAsIDIwMDkgOTo1OCBBTQ0KVG86IGF0b20tc3ludGF4 IFN5bnRheA0KU3ViamVjdDogRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQpkcmFm dC1kaXZpbGx5LWF0b20taGllcmFyY2h5LTAyIA0KDQogDQoNCkJhc2VkIG9uIGZlZWRiYWNrLCBJ IGhhdmUgc2ltcGxpZmllZCB0aGUgSS1EIHRvOg0KDQpJbi1saW5lIGV4dGVuc2lvbnMgbW92ZWQg dG8gZHJhZnQtbWVodGEtYXRvbS1pbmxpbmUNCg0KICAgICAgUmVtb3ZlZCBkb3duLXRyZWUgYW5k IHVwLXRyZWUgcmVsYXRpb25zDQoNCiAgICAgIFJlbW92ZWQgY2FyZGluYWxpdHkgcmVzdHJpY3Rp b25zIG9uIHVwIGFuZCBkb3duIGxpbmtzDQoNCiANCg0KSFRNTDogaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtZGl2aWxseS1hdG9tLWhpZXJhcmNoeS0wMg0KDQpUZXh0OiBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZGl2aWxseS1hdG9tLWhpZXJhcmNoeS0wMi50eHQNCjxo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtbWVodGEtYXRvbS1pbmxpbmUtMDAudHh0PiAN Cg0KRGlmZjoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZGl2aWxs eS1hdG9tLWhpZXJhcmNoeS0wMi50eHQNCg0KIA0KDQpJIGFtIGFsc28gdHJhY2tpbmcgb3BlbiBp c3N1ZXMgYWJvdXQgdGhpcyBJLUQgcHVibGljbHkgYXQNCmh0dHA6Ly9jb2RlLmdvb2dsZS5jb20v cC9hdG9tLWV4dC9pc3N1ZXMvbGlzdC4gVGhlIHNvdXJjZSBmb3IgdGhpcyBJLUQNCmlzIGFsc28g YXZhaWxhYmxlLCBpZiB5b3UgYXJlIGludGVyZXN0ZWQuDQoNCiANCg0KTG9va2luZyBmb3J3YXJk IHRvIGNvbW1lbnRzIG9uIHRoZSBJLUQuDQoNCiANCg0KTmlrdW5qDQoNCmh0dHA6Ly9vLW1pY3Jv bi5ibG9nc3BvdC5jb20gPGh0dHA6Ly9vLW1pY3Jvbi5ibG9nc3BvdC5jb20vPiANCg0KIA0KDQog DQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQoNCg0KDQoNCkZyb206IElFVEYgSS1EIFN1 Ym1pc3Npb24gVG9vbCA8aWRzdWJtaXNzaW9uQGlldGYub3JnPg0KDQpEYXRlOiBKdW5lIDksIDIw MDkgNTozMzo1NyBQTSBQRFQNCg0KVG86IG5pa3Vuai5tZWh0YUBvcmFjbGUuY29tDQoNCkNjOiBj b2xtLmRpdmlsbHlAb3JhY2xlLmNvbQ0KDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWRpdmlsbHktYXRvbS1oaWVyYXJjaHktMDIgDQoNCiANCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtZGl2aWxseS1hdG9tLWhpZXJhcmNoeS0wMi50eHQgaGFzIGJl ZW4NCnN1Y2Nlc3NmdWx5IHN1Ym1pdHRlZCBieSBOaWt1bmogTWVodGEgYW5kIHBvc3RlZCB0byB0 aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogICAgICAgICAgZHJhZnQtZGl2aWxseS1h dG9tLWhpZXJhcmNoeQ0KUmV2aXNpb246ICAgICAgICAgICAwMg0KVGl0bGU6ICAgICAgICAgICAg ICAgICBIaWVyYXJjaHkgUmVsYXRpb25zIGZvciBBdG9tDQpDcmVhdGlvbl9kYXRlOiAgMjAwOS0w Ni0wOQ0KV0cgSUQ6ICAgICAgICAgICAgICAgICAgICAgICAgSW5kZXBlbmRlbnQgU3VibWlzc2lv bg0KTnVtYmVyX29mX3BhZ2VzOiA3DQoNCkFic3RyYWN0Og0KVGhpcyBzcGVjaWZpY2F0aW9uIGRl ZmluZXMgbGluayByZWxhdGlvbnMgZm9yIGhpZXJhcmNoaWNhbCBuYXZpZ2F0aW9uDQphbW9uZyBB dG9tIGZlZWRzIGFuZCBlbnRyaWVzLkVkaXRvcmlhbCBOb3RlDQoNClRvIHByb3ZpZGUgZmVlZGJh Y2sgb24gdGhpcyBJbnRlcm5ldC1EcmFmdCwgam9pbiB0aGUgYXRvbS1zeW50YXgNCm1haWxpbmcg bGlzdCAoaHR0cDovL3d3dy5pbWMub3JnL2F0b20tc3ludGF4LykgWzFdLg0KDQoNCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQuDQoNCg0KDQogDQoNCg0K --part158790-boundary-1574582474-1848417798 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="Windows-1252" PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RS L1JFQy1odG1sNDAiPiA8aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDExIChmaWx0ZXJlZCBtZWRpdW0pIj48IS0tW2lmICFtc29dPjxz dHlsZT4gdlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fSBvXDoqIHtiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjVk1MKTt9IHdcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30gLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9PC9zdHlsZT48IVtlbmRpZl0tLT48c3R5 bGU+PCEtLSAgLyogRm9udCBEZWZpbml0aW9ucyAqLyAgQGZvbnQtZmFjZSAJe2ZvbnQtZmFtaWx5 OkhlbHZldGljYTsgCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30gQGZvbnQtZmFjZSAJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsgCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30gIC8q IFN0eWxlIERlZmluaXRpb25zICovICBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsIAl7bWFyZ2luOjBpbjsgCW1hcmdpbi1ib3R0b206LjAwMDFwdDsgCWZvbnQtc2l6ZTox Mi4wcHQ7IAlmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9IGE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsgCXtjb2xvcjpibHVlOyAJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9IGE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZCAJe2NvbG9yOmJsdWU7IAl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30gdHQgCXtmb250LWZhbWlseToiQ291cmllciBOZXciO30gc3Bhbi5F bWFpbFN0eWxlMjAgCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsgCWZvbnQtZmFtaWx5 OkFyaWFsOyAJY29sb3I6bmF2eTt9IEBwYWdlIFNlY3Rpb24xIAl7c2l6ZTo4LjVpbiAxMS4waW47 IAltYXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9IGRpdi5TZWN0aW9uMSAJe3BhZ2U6 U2VjdGlvbjE7fSAtLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPiAgPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz48L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4gIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4gICA8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4gIDwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT48L2hlYWQ+IDxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPWJsdWUg c3R5bGU9J3dvcmQtd3JhcDogYnJlYWstd29yZDstd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13 ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UnPlllcyB5b3VyIGludGVycHJldGF0 aW9uIGlzIGNvcnJlY3QuIDxwPlNlbnQgZnJvbSBteSBWZXJpem9uIFdpcmVsZXNzIEJsYWNrQmVy cnk8L3A+PHA+PGhyIHNpemU9MiB3aWR0aD0xMDAlIGFsaWduPWNlbnRlciB0YWJpbmRleD0tMT48 Yj5Gcm9tPC9iPjogIERhdmlzX0Nvcm5lbGlhQGVtYy5jb208YnI+PGI+RGF0ZTwvYj46IFRodSwg MTEgSnVuIDIwMDkgMDA6NDc6MzIgLTA0MDA8YnI+PGI+VG88L2I+OiAmbHQ7bmlrdW5qLm1laHRh QG9yYWNsZS5jb20mZ3Q7OyAmbHQ7YXRvbS1zeW50YXhAaW1jLm9yZyZndDs8YnI+PGI+U3ViamVj dDwvYj46IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRpdmlsbHktYXRv bS1oaWVyYXJjaHktMDI8YnI+PC9mb250PjwvcD4gPGRpdiBjbGFzcz1TZWN0aW9uMT4gPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTogMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPkkgYXNr IHlvdXIgZm9yZ2l2ZW5lc3MgZm9yIHJlaGFzaGluZyBhbiBvbGQgKGEgZmV3IGRheXMgb2xkKSB0 b3BpYyAmIzgyMTE7IHRoZSBzdWdnZXN0aW9uIHRoYXQgSmFtZXMgU25lbGwgbWFkZSBmb3IgdXNp bmcgYSBtZWRpYS10eXBlIHByb2ZpbGUgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBhbiBlbnRyeSYj ODIxNztzIGNoaWxkcmVuIGFuZCBhbiBlbnRyeSYjODIxNztzIGRlc2NlbmRhbnRzLiZuYnNwOyBJ IHRoaW5rIEkgZ2V0IGl0IGJ1dCB3YW50IHRvIHJ1biB0aGlzIGJ5IHRoZSBncm91cCBmb3IgY29u ZmlybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+IDxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6IDEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9y PW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOiAxMC4wcHQ7Zm9udC1mYW1p bHk6QXJpYWw7Y29sb3I6bmF2eSc+SW4gdGhlIGZvbGxvd2luZyAoZnJvbSBKYW1lcyk6PG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4gPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBj b2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTogMTAuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+IDxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6IDEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpu YXZ5Jz4mZ3Q7IDwvc3Bhbj48L2ZvbnQ+PHR0Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZsdDtsaW5rIHJlbD0mcXVvdDtkb3du JnF1b3Q7IHR5cGU9JnF1b3Q7YXBwbGljYXRpb24vYXRvbSt4bWw7dHlwZT1mZWVkO3Byb2ZpbGU9 dHJlZSZxdW90OyBocmVmPSZxdW90Oy4uLiZxdW90OyAvJmd0OyAmbHQ7bGluayByZWw9JnF1b3Q7 ZG93biZxdW90OyB0eXBlPSZxdW90O2FwcGxpY2F0aW9uL2F0b20reG1sO3R5cGU9ZmVlZDtwcm9m aWxlPWZsYXQmcXVvdDsgaHJlZj0mcXVvdDsuLi4mcXVvdDsgLyZndDsgPC9zcGFuPjwvZm9udD48 L3R0PjxvOnA+PC9vOnA+PC9wPiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9y PW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOiAxMC4wcHQ7Zm9udC1mYW1p bHk6QXJpYWw7Y29sb3I6bmF2eSc+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4gPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJp YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTogMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y Om5hdnknPmEgdmFsdWUgb2YgcHJvZmlsZT1mbGF0IGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhhdCB3 ZSB3YW50IHRoZSBjaGlsZHJlbiB0byBiZSByZXByZXNlbnRlZCB3aXRob3V0IGFueSBleHBhbnNp b24gYW5kIGEgdmFsdWUgb2YgcHJvZmlsZT10cmVlIGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhhdCB3 ZSB3YW50IHRoZSBjaGlsZHJlbiB0byBiZSByZXByZXNlbnRlZCB3aXRoIGEgcG90ZW50aWFsIGV4 cGFuc2lvbi4mbmJzcDsgSSBjb25mZXNzIHRoYXQgaW5pdGlhbGx5IEkgdGhvdWdodCB0aGF0IHRo aXMgd2FzbiYjODIxNzt0IGEgbWltZXR5cGUgaXNzdWUsIHRoYXQgd2Ugd2VyZSB0YWxraW5nIGFi b3V0IHR3byBkaWZmZXJlbnQgcmVzb3VyY2VzICYjODIxMTsgdGhlIHNldCBvZiBjaGlsZHJlbiBh bmQgdGhlIHNldCBvZiBkZXNjZW5kYW50cy4mbmJzcDsgQnV0ICZuYnNwO3doYXQgaXMgcHJvcG9z ZWQgaGVyZSBpcyBmYXIgbW9yZSBlbGVnYW50LCBhbmQgaXMgbmljZWx5IGNhc3QgYXMgYSBtaW1l LXR5cGUgY2hvaWNlLiZuYnNwOyBUaGUga2V5IGlzIHRoYXQgdGhlIGxpbmsgcmVsYXRpb24gJiM4 MjIwO2Rvd24mIzgyMjE7IG9ubHkgZXZlciByZXR1cm5zIGEgY2hpbGQgKGFzIDwvc3Bhbj48L2Zv bnQ+PHR0Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQnPmFwcGxpY2F0aW9uL2F0b20reG1sO3R5cGU9ZW50cnk8L3NwYW4+PC9mb250 PjwvdHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDsgY29sb3I6bmF2eSc+KSBvciBhIGZlZWQg Y29udGFpbmluZ188aT48c3BhbiBzdHlsZT0nZm9udC1zdHlsZTppdGFsaWMnPm9ubHkgY2hpbGRy ZW48L3NwYW4+PC9pPl8gKGFzIDwvc3Bhbj48L2ZvbnQ+PHR0Pjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPmFwcGxpY2F0aW9uL2F0 b20reG1sO3R5cGU9ZmVlZDwvc3Bhbj48L2ZvbnQ+PC90dD48Zm9udCBzaXplPTIgY29sb3I9bmF2 eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsOyBjb2xvcjpuYXZ5Jz4pICYjODIxMTsgd2hhdCBkaWZmZXJzIGlzIHRoZSByZXByZXNlbnRh dGlvbiBmb3JtYXQgb2YgdGhhdCBjaGlsZCAoZXhwYW5kZWQgb3Igbm90KS48bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5h dnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOiAxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6bmF2eSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4gPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTogMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPlNv dW5kIHJpZ2h0PzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+IDxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6IDEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9y PW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOiAxMC4wcHQ7Zm9udC1mYW1p bHk6QXJpYWw7Y29sb3I6bmF2eSc+QW5kIHllcywgSSB1bmRlcnN0YW5kIHRoYXQgdGhlIG1pbWUg dHlwZXMgYW5kIHByb2ZpbGUgZGVzaWduYXRvcnMgYXJlIG1vc3QgZGVmaW5pdGVseSBvdXRzaWRl IHRoZSBzY29wZSBvZiB0aGlzIEktRC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPiA8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOiAxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4gPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTogMTAu MHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOiAxMC4wcHQ7Zm9udC1mYW1pbHk6QXJp YWw7Y29sb3I6bmF2eSc+Q29ybmVsaWE8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPiA8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOiAxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4gPGRpdj4gPGRpdj4gPHAgY2xhc3M9TXNv Tm9ybWFsPjxiPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZTtmb250LXdlaWdo dDpib2xkJz5Db3JuZWxpYSBEYXZpczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2I+PC9wPiA8 cCBjbGFzcz1Nc29Ob3JtYWw+PGk+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5 O2ZvbnQtc3R5bGU6aXRhbGljJz5TZW5pb3IgVGVjaG5vbG9naXN0PC9zcGFuPjwvZm9udD48L2k+ PGZvbnQgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpBcmlh bDtjb2xvcjpuYXZ5Jz48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPiA8cCBjbGFzcz1Nc29O b3JtYWw+PGk+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5O2ZvbnQtc3R5bGU6 aXRhbGljJz5FTUMgQ29ycG9yYXRpb24sIE9mZmljZSBvZiB0aGUgQ1RPPC9zcGFuPjwvZm9udD48 L2k+PGZvbnQgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpB cmlhbDtjb2xvcjpuYXZ5Jz48YnI+PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTEgY29sb3I9bmF2 eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC4wcHQ7IGZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOm5hdnknPjxhIGhyZWY9Im1haWx0bzpkYXZpc19jb3JuZWxpYUBlbWMuY29tIiB0 aXRsZT0ibWFpbHRvOmRhdmlzX2Nvcm5lbGlhQGVtYy5jb20iPmRhdmlzX2Nvcm5lbGlhQGVtYy5j b208L2E+PC9zcGFuPjwvZm9udD48Zm9udCBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxicj48L3NwYW4+PC9mb250Pjxmb250 IHNpemU9MSBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjBw dDsgZm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+cDogODA1LjU2MC45MDM5PC9zcGFuPjwv Zm9udD48Zm9udCBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OkFyaWFsO2NvbG9yOm5hdnknPjxicj48L3NwYW4+PC9mb250Pjxmb250IHNpemU9MSBjb2xvcj1u YXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjBwdDsgZm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6bmF2eSc+bTogODA1LjQ1Mi44OTQxPC9zcGFuPjwvZm9udD48Zm9udCBjb2xv cj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5h dnknPjxicj48L3NwYW4+PC9mb250Pjxmb250IHNpemU9MSBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjBwdDsgZm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2 eSc+ZjogODA1Ljg4MC4wMzkwPC9zcGFuPjwvZm9udD48Zm9udCBjb2xvcj1uYXZ5IGZhY2U9QXJp YWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+IDwvZGl2PiA8L2Rpdj4gPGRpdj4gPGRpdiBjbGFzcz1Nc29Ob3Jt YWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiA8aHIg c2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+IDwvc3Bhbj48L2Zv bnQ+PC9kaXY+IDxwIGNsYXNzPU1zb05vcm1hbD48Yj48Zm9udCBzaXplPTIgZmFjZT1UYWhvbWE+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OlRhaG9tYTtmb250LXdl aWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9MiBmYWNlPVRhaG9t YT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEnPiBvd25l ci1hdG9tLXN5bnRheEBtYWlsLmltYy5vcmcgW21haWx0bzpvd25lci1hdG9tLXN5bnRheEBtYWls LmltYy5vcmddIDxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5PbiBCZWhhbGYgT2Yg PC9zcGFuPjwvYj5OaWt1bmogUi4gTWVodGE8YnI+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0 OmJvbGQnPlNlbnQ6PC9zcGFuPjwvYj4gV2VkbmVzZGF5LCBKdW5lIDEwLCAyMDA5IDk6NTggQU08 YnI+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlRvOjwvc3Bhbj48L2I+IGF0b20t c3ludGF4IFN5bnRheDxicj48Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U3ViamVj dDo8L3NwYW4+PC9iPiBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZGl2 aWxseS1hdG9tLWhpZXJhcmNoeS0wMiA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPiA8L2Rp dj4gPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6IDEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4gPGRpdj4gPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGNsYXNzPWFwcGxlLXN0 eWxlLXNwYW4+PGZvbnQgc2l6ZT0xIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo5LjBwdCc+QmFzZWQgb24gZmVlZGJhY2ssIEkgaGF2ZSBzaW1wbGlmaWVkIHRo ZSBJLUQgdG86PC9zcGFuPjwvZm9udD48L3NwYW4+PG86cD48L286cD48L3A+IDwvZGl2PiA8ZGl2 PiA8ZGl2PiA8ZGl2PiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0xIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTogOS4wcHQnPkluLWxpbmUgZXh0ZW5z aW9ucyBtb3ZlZCB0byBkcmFmdC1tZWh0YS1hdG9tLWlubGluZTxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+IDwvZGl2PiA8ZGl2PiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0xIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTogOS4wcHQnPiZuYnNw OyZuYnNwOyAmbmJzcDsgJm5ic3A7UmVtb3ZlZCBkb3duLXRyZWUgYW5kIHVwLXRyZWUgcmVsYXRp b25zPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4gPC9kaXY+IDxkaXY+IDxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTEgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOiA5LjBwdCc+Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDtSZW1vdmVkIGNhcmRp bmFsaXR5IHJlc3RyaWN0aW9ucyBvbiB1cCBhbmQgZG93biBsaW5rczxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+IDwvZGl2PiA8ZGl2PiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0x IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTogOS4wcHQnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+IDwvZGl2PiA8ZGl2PiA8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0xIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTogOS4wcHQnPkhUTUw6Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtZGl2aWxseS1hdG9tLWhpZXJhcmNoeS0wMiI+aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZGl2aWxseS1hdG9tLWhpZXJhcmNoeS0wMjwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPiA8L2Rpdj4gPC9kaXY+IDxkaXY+IDxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTEgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOiA5LjBwdCc+VGV4dDombmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQv ZHJhZnQtbWVodGEtYXRvbS1pbmxpbmUtMDAudHh0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQv ZHJhZnQtZGl2aWxseS1hdG9tLWhpZXJhcmNoeS0wMi50eHQ8L2E+PG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4gPC9kaXY+IDxkaXY+IDxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTEg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOiA5LjBwdCc+RGlm ZjombmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWRpdmlsbHktYXRvbS1oaWVyYXJjaHktMDIudHh0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWRpdmlsbHktYXRvbS1oaWVyYXJjaHktMDIudHh0PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+IDwvZGl2PiA8ZGl2PiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0xIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTog OS4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+IDwvZGl2PiA8ZGl2PiA8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0xIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTogOS4wcHQnPkkgYW0mbmJzcDthbHNvJm5ic3A7dHJhY2tpbmcm bmJzcDtvcGVuJm5ic3A7aXNzdWVzJm5ic3A7YWJvdXQmbmJzcDt0aGlzJm5ic3A7SS1EJm5ic3A7 cHVibGljbHkmbmJzcDthdCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9jb2RlLmdvb2dsZS5jb20vcC9h dG9tLWV4dC9pc3N1ZXMvbGlzdCI+aHR0cDovL2NvZGUuZ29vZ2xlLmNvbS9wL2F0b20tZXh0L2lz c3Vlcy9saXN0PC9hPi4gVGhlIHNvdXJjZSBmb3IgdGhpcyBJLUQgaXMgYWxzbyBhdmFpbGFibGUs IGlmIHlvdSBhcmUgaW50ZXJlc3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPiA8L2Rp dj4gPGRpdj4gPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MSBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6IDkuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPiA8L2Rpdj4gPGRpdj4gPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6IDkuMHB0 Jz5Mb29raW5nIGZvcndhcmQgdG8gY29tbWVudHMgb24gdGhlIEktRC48bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPiA8ZGl2PiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0xIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTogOS4wcHQnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+IDxzcGFuIHN0eWxlPSdvcnBoYW5zOiAyO3dpZG93 czogMjstd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3Jk ZXItdmVydGljYWwtc3BhY2luZzogMHB4Oy13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1pbi1lZmZl Y3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOiAwcHgnPjxzcGFuIHN0eWxlPSdvcnBoYW5zOiAy O3dpZG93czogMjstd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtp dC1ib3JkZXItdmVydGljYWwtc3BhY2luZzogMHB4Oy13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1p bi1lZmZlY3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOiAwcHgnPjxzcGFuIHN0eWxlPSdvcnBo YW5zOiAyO3dpZG93czogMjstd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsg LXdlYmtpdC1ib3JkZXItdmVydGljYWwtc3BhY2luZzogMHB4Oy13ZWJraXQtdGV4dC1kZWNvcmF0 aW9ucy1pbi1lZmZlY3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOiAwcHgnPiA8ZGl2IGFwcGxl LWNvbnRlbnQtZWRpdGVkPXRydWU+IDxkaXYgc3R5bGU9J3dvcmQtd3JhcDogYnJlYWstd29yZDst d2Via2l0LW5ic3AtbW9kZTogc3BhY2U7LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZSc+IDxkaXYgc3R5bGU9J3dvcmQtd3JhcDogYnJlYWstd29yZDstd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZSc+IDxkaXYgc3R5 bGU9J3dvcmQtd3JhcDogYnJlYWstd29yZDstd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7LXdlYmtp dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZSc+IDxkaXYgc3R5bGU9J3dvcmQtd3JhcDog YnJlYWstd29yZDstd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7LXdlYmtpdC1saW5lLWJyZWFrOiBh ZnRlci13aGl0ZS1zcGFjZSc+IDxkaXY+IDxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTEg Y29sb3I9YmxhY2sgZmFjZT1IZWx2ZXRpY2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2snPk5pa3VuajxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+IDwvZGl2PiA8ZGl2PiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0x IGNvbG9yPWJsYWNrIGZhY2U9SGVsdmV0aWNhPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrJz48YSBocmVmPSJodHRwOi8vby1taWNy b24uYmxvZ3Nwb3QuY29tLyI+aHR0cDovL28tbWljcm9uLmJsb2dzcG90LmNvbTwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPiA8L2Rpdj4gPGRpdj4gPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MSBjb2xvcj1ibGFjayBmYWNlPUhlbHZldGljYT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4gPC9kaXY+IDwvZGl2PiA8L2Rpdj4gPC9kaXY+IDwvZGl2 PiA8L2Rpdj4gPC9kaXY+IDwvZGl2PiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTogMTIuMHB0Jz48L3Nw YW4+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4gPC9zcGFuPjwvc3Bhbj4gPGRp dj4gPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6IDEyLjBwdCc+QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6 PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4gPC9kaXY+IDxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OiAxMi4wcHQnPjxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4gPGRpdj4gPGRp dj4gPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxmb250IHNpemU9MSBjb2xvcj1ibGFjayBmYWNlPUhl bHZldGljYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj YTtjb2xvcjpibGFjaztmb250LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxm b250IHNpemU9MSBmYWNlPUhlbHZldGljYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0OyBm b250LWZhbWlseTpIZWx2ZXRpY2EnPklFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZyI+aWRzdWJtaXNzaW9uQGlldGYub3JnPC9h PiZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPiA8L2Rpdj4gPGRpdj4gPHAgY2xhc3M9 TXNvTm9ybWFsPjxiPjxmb250IHNpemU9MSBjb2xvcj1ibGFjayBmYWNlPUhlbHZldGljYT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFj aztmb250LXdlaWdodDpib2xkJz5EYXRlOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9MSBm YWNlPUhlbHZldGljYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0OyBmb250LWZhbWlseTpI ZWx2ZXRpY2EnPkp1bmUgOSwgMjAwOSA1OjMzOjU3IFBNIFBEVDwvc3Bhbj48L2ZvbnQ+PG86cD48 L286cD48L3A+IDwvZGl2PiA8ZGl2PiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGZvbnQgc2l6ZT0x IGNvbG9yPWJsYWNrIGZhY2U9SGVsdmV0aWNhPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrO2ZvbnQtd2VpZ2h0OmJvbGQnPlRvOiA8 L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPTEgZmFjZT1IZWx2ZXRpY2E+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EnPjxhIGhyZWY9Im1haWx0bzpu aWt1bmoubWVodGFAb3JhY2xlLmNvbSI+bmlrdW5qLm1laHRhQG9yYWNsZS5jb208L2E+PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4gPC9kaXY+IDxkaXY+IDxwIGNsYXNzPU1zb05vcm1hbD48 Yj48Zm9udCBzaXplPTEgY29sb3I9YmxhY2sgZmFjZT1IZWx2ZXRpY2E+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2s7Zm9udC13ZWln aHQ6Ym9sZCc+Q2M6IDwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9MSBmYWNlPUhlbHZldGlj YT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSc+PGEg aHJlZj0ibWFpbHRvOmNvbG0uZGl2aWxseUBvcmFjbGUuY29tIj5jb2xtLmRpdmlsbHlAb3JhY2xl LmNvbTwvYT48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPiA8L2Rpdj4gPGRpdj4gPHAgY2xh c3M9TXNvTm9ybWFsPjxiPjxmb250IHNpemU9MSBjb2xvcj1ibGFjayBmYWNlPUhlbHZldGljYT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpi bGFjaztmb250LXdlaWdodDpib2xkJz5TdWJqZWN0Ojwvc3Bhbj48L2ZvbnQ+PC9iPjxiPjxmb250 IHNpemU9MSBmYWNlPUhlbHZldGljYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0OyBmb250 LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC13ZWlnaHQ6Ym9sZCc+TmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1kaXZpbGx5LWF0b20taGllcmFyY2h5LTAyPHNwYW4gY2xhc3M9YXBwbGUt Y29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9mb250PjwvYj48bzpwPjwvbzpw PjwvcD4gPC9kaXY+IDxkaXYgc3R5bGU9J21pbi1oZWlnaHQ6IDE0cHgnPiA8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZTogMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPiA8L2Rp dj4gPC9kaXY+IDxkaXY+IDxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTox Mi4wcHQnPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTIuMHB0Jz48YnI+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kaXZpbGx5 LWF0b20taGllcmFyY2h5LTAyLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVseSBzdWJtaXR0ZWQgYnkg TmlrdW5qIE1laHRhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48YnI+PGJyPiBG aWxlbmFtZTo8c3BhbiBjbGFzcz1hcHBsZS10YWItc3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPiBkcmFmdC1kaXZpbGx5LWF0 b20taGllcmFyY2h5PGJyPiBSZXZpc2lvbjo8c3BhbiBjbGFzcz1hcHBsZS10YWItc3Bhbj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PC9zcGFuPiAwMjxicj4gVGl0bGU6PHNwYW4gY2xhc3M9YXBwbGUtdGFiLXNwYW4+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4gSGllcmFyY2h5IFJlbGF0aW9u cyBmb3IgQXRvbTxicj4gQ3JlYXRpb25fZGF0ZTo8c3BhbiBjbGFzcz1hcHBsZS10YWItc3Bhbj4m bmJzcDsgPC9zcGFuPiAyMDA5LTA2LTA5PGJyPiBXRyBJRDo8c3BhbiBjbGFzcz1hcHBsZS10YWIt c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPiBJbmRlcGVuZGVudCBTdWJtaXNz aW9uPGJyPiBOdW1iZXJfb2ZfcGFnZXM6IDc8YnI+PGJyPiBBYnN0cmFjdDo8YnI+IFRoaXMgc3Bl Y2lmaWNhdGlvbiBkZWZpbmVzIGxpbmsgcmVsYXRpb25zIGZvciBoaWVyYXJjaGljYWwgbmF2aWdh dGlvbjxicj4gYW1vbmcgQXRvbSBmZWVkcyBhbmQgZW50cmllcy5FZGl0b3JpYWwgTm90ZTxicj48 YnI+IFRvIHByb3ZpZGUgZmVlZGJhY2sgb24gdGhpcyBJbnRlcm5ldC1EcmFmdCwgam9pbiB0aGUg YXRvbS1zeW50YXg8YnI+IG1haWxpbmcgbGlzdCAoPGEgaHJlZj0iaHR0cDovL3d3dy5pbWMub3Jn L2F0b20tc3ludGF4LyI+aHR0cDovL3d3dy5pbWMub3JnL2F0b20tc3ludGF4LzwvYT4pIFsxXS48 YnI+PGJyPjxicj48YnI+IFRoZSBJRVRGIFNlY3JldGFyaWF0Ljxicj48YnI+PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4gPC9kaXY+IDwvZGl2PiA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTogMTIu MHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPiA8L2Rpdj4gPC9ib2R5PiA8 L2h0bWw+ICA= --part158790-boundary-1574582474-1848417798-- From owner-atom-syntax@mail.imc.org Thu Jun 11 09:55:20 2009 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 1BEA33A68ED for ; Thu, 11 Jun 2009 09:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 nJGL+ZHUm278 for ; Thu, 11 Jun 2009 09:55:19 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 124423A6CC4 for ; Thu, 11 Jun 2009 09:55:18 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BGfiSe031444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 09:41:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BGfiuj031443; Thu, 11 Jun 2009 09:41: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-px0-f175.google.com (mail-px0-f175.google.com [209.85.216.175]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BGfXm8031425 for ; Thu, 11 Jun 2009 09:41:43 -0700 (MST) (envelope-from john@johnpanzer.com) Received: by pxi5 with SMTP id 5so124514pxi.16 for ; Thu, 11 Jun 2009 09:41:32 -0700 (PDT) Received: by 10.114.147.1 with SMTP id u1mr4356717wad.108.1244738492601; Thu, 11 Jun 2009 09:41:32 -0700 (PDT) Received: from ?192.168.1.100? (adsl-70-231-239-10.dsl.snfc21.sbcglobal.net [70.231.239.10]) by mx.google.com with ESMTPS id b39sm7432935rvf.11.2009.06.11.09.41.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Jun 2009 09:41:31 -0700 (PDT) Message-ID: <4A3133C6.4090308@acm.org> Date: Thu, 11 Jun 2009 09:41:42 -0700 From: John Panzer Reply-To: jpanzer@acm.org User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ross Singer CC: Thomas Broyer , Atom-Syntax Subject: Re: Tools not supporting atom:content with @src ? References: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> <4A2F00B6.7020504@degeneration.co.uk> <7b9ad66d0906100039y65db0273l5f060744fa373dbe@mail.gmail.com> <23b83f160906101732gd1b0759i32795a75c689ffd7@mail.gmail.com> <23b83f160906110611p65100c2bsa7fdf9a5731decf2@mail.gmail.com> In-Reply-To: <23b83f160906110611p65100c2bsa7fdf9a5731decf2@mail.gmail.com> 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: Ross Singer wrote: > ... what argument are you making against using the http URI the > identifier? I understand if the tag URI is necessary for internal > reasons for the application, but if the http URI is, indeed, a viable > identifier for the resource... why not use that? > If the http URL is a permanent identifier that will never disappear unless the resource itself does, and will never be reassigned to some different resource, then sure. In practice it's very hard to guarantee this. From owner-atom-syntax@mail.imc.org Thu Jun 11 10:03:12 2009 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 E59053A6D5D for ; Thu, 11 Jun 2009 10:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=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 Ko4diXjmvQDm for ; Thu, 11 Jun 2009 10:03:12 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D5AEF3A6D53 for ; Thu, 11 Jun 2009 10:03:11 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BGqY4Z032050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 09:52:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BGqYii032049; Thu, 11 Jun 2009 09:52: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 mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BGqMaK032038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Jun 2009 09:52:33 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.0.10] (localhost.localdomain [127.0.0.1]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id n5BGqHNF030439; Thu, 11 Jun 2009 11:52:18 -0500 Message-ID: <4A313641.8060808@defuze.org> Date: Thu, 11 Jun 2009 18:52:17 +0200 From: Sylvain Hellegouarch User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: jpanzer@acm.org CC: Ross Singer , Thomas Broyer , Atom-Syntax Subject: Re: Tools not supporting atom:content with @src ? References: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> <4A2F00B6.7020504@degeneration.co.uk> <7b9ad66d0906100039y65db0273l5f060744fa373dbe@mail.gmail.com> <23b83f160906101732gd1b0759i32795a75c689ffd7@mail.gmail.com> <23b83f160906110611p65100c2bsa7fdf9a5731decf2@mail.gmail.com> <4A3133C6.4090308@acm.org> In-Reply-To: <4A3133C6.4090308@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Panzer a écrit : > > Ross Singer wrote: >> ... what argument are you making against using the http URI the >> identifier? I understand if the tag URI is necessary for internal >> reasons for the application, but if the http URI is, indeed, a viable >> identifier for the resource... why not use that? >> > If the http URL is a permanent identifier that will never disappear > unless the resource itself does, and will never be reassigned to some > different resource, then sure. In practice it's very hard to > guarantee this. Well it goes quite beyond the persistence of the value. The atom:id is an opaque string, it's a IRI, not a URL. Bypassing the difference really breaks the spirit behind it. Use atom:link for that. - Sylvain From owner-atom-syntax@mail.imc.org Thu Jun 11 10:45:17 2009 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 26C1028C14C for ; Thu, 11 Jun 2009 10:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=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 NAuQCwFs4J5c for ; Thu, 11 Jun 2009 10:45:16 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B19E528C193 for ; Thu, 11 Jun 2009 10:45:15 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BHXS9U034555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 10:33:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BHXSeC034554; Thu, 11 Jun 2009 10:33: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 mail-yx0-f198.google.com (mail-yx0-f198.google.com [209.85.210.198]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BHXGDZ034537 for ; Thu, 11 Jun 2009 10:33:27 -0700 (MST) (envelope-from joe.gregorio@gmail.com) Received: by yxe36 with SMTP id 36so131400yxe.16 for ; Thu, 11 Jun 2009 10:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=4O/lQllgpwlMDwAHrFS7Zqpgibu2e6OpxytPsPZa8Sw=; b=KdJexHsVYUDBzs+xkkiRTqrVWi7apVYigxoJiU7iw64O0/7pvIR9WrJMTW5+CoW8lv znI83sEw/+7C527t/t3RFAfRyAhvVk5eZUsNwFcDPd07XOyBKOmSoth28YTkwN4us7WX IknId3mPXKRjl32OGsJtd64VltToWQLWGP2Lg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=x9OST3Do9K/7JehqtbUoP24mjUVTLMYGCWjpa5p4rpdVoxNhThbrKNIJacA2Eo+NXl lcy0u5v1xrBIXhmSdf3E0cFGc1UVI0jp2Jk6GeiS6Gf2YxFrUT8GLTh0MHQ8me2QyczY FgfgU4rmD0xATQ+dczXHKGQBAqlxJQhfwYgE4= MIME-Version: 1.0 Received: by 10.151.109.5 with SMTP id l5mr5579357ybm.110.1244741595953; Thu, 11 Jun 2009 10:33:15 -0700 (PDT) In-Reply-To: <4A2EE11F.2080809@gmail.com> References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2EE11F.2080809@gmail.com> Date: Thu, 11 Jun 2009 13:33:15 -0400 X-Google-Sender-Auth: 79e87d4872c845b2 Message-ID: <3f1451f50906111033g7833b29bh74fd02b0b5dcb170@mail.gmail.com> Subject: Re: Sub-typing Atom documents From: Joe Gregorio To: James M Snell Cc: "Nikunj R. Mehta" , atom-syntax Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jun 9, 2009 at 6:24 PM, James M Snell wrote: > > I've already started working up an I-D for a new profile media type > parameter. I should be able to get it published by tomorrow end-of-day > > Example: > > =A0application/atom+xml;profile=3D"http://example.org/profile/foo" > > The profile parameter value is a URI that identifies a logical profile to > which the Atom document conforms. Only a single profile value is allowed = for > now. Why not extend the Service Document with extra information about what the s= erver will accept? That was the point of the service document which was to contain that kind of information. Thanks, -joe > > - James > > Nikunj R. Mehta wrote: >> >> Several recent discussions suggest the need for sub-typing Atom document= s. >> There are two major requirements for sub-typing Atom documents: >> >> 1. In Atom Publishing Protocol, signaling the requirement for an Atom >> extension (whether blessed by IETF or not) to be present in accepted con= tent >> [1]. To illustrate the requirement by example, one would see: >> >> application/atom+xml;type=3Dentry;extension=3Dtoken >> >> 2. Establishing an expectation on an Atom processor for the media type o= f >> a linked resource, e.g., whether the representation in-lines a complete >> hierarchy of Atom entries and feeds [2]. Once again to illustrate the >> requirement by example, one would see: >> >> > href=3D"children"/> >> >> Of these cases, a really strong case can be made for the first requireme= nt >> to use a media type parameter, since it has to happen in the absence of = the >> actual Atom document. There is only one must-understand signaling mechan= ism >> in AtomPub and that is app:accept. If a media type parameter is used in >> app:accept that cannot be understood by its receiver, the receiver has n= o >> choice but to cease communications with the server. Since almost every >> AtomPub-style "API" introduces its own set of requirements for what >> constitutes an entry the server is willing to accept. >> >> For example, Google Finance API in its protocol reference states that an >> entry posted as a new portfolio must include a "gf:portfolioData" elemen= t >> inside an atom:entry [3]. CMIS servers may require the presence of a typ= e >> identifier as extended entry metadata in order to accept an entry posted= to >> a collection [4]. >> >> It seems quite reasonable to establish a single media type parameter and >> allow every such API to define their own acceptable values for this purp= ose. >> This approach =A0provides fair warning and enables AtomPub niches to leg= ally >> exist, and even interoperate. >> >> The second case can probably benefit from a media type parameter, but it >> is not clear what the semantics of that parameter would be. Specifically= : >> >> =A0 1. Do Atom processors fail if, when processing Content-Type header, >> =A0 =A0 =A0they encounter a media type parameter they don't know about o= r a >> =A0 =A0 =A0value in a known media type parameter that they don't underst= and. >> =A0 2. Does introduction of media type parameters for >> =A0 =A0 =A0application/atom+xml require standards track RFC? >> >> >> Nikunj >> http://o-micron.blogspot.com >> >> [1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html >> [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html >> [3] >> http://code.google.com/apis/finance/developers_guide_protocol.html#Creat= ingPortfolios >> [4] http://www.oasis-open.org/committees/download.php/32668 > > --=20 Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Thu Jun 11 10:51:03 2009 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 516F53A6ABA for ; Thu, 11 Jun 2009 10:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.234 X-Spam-Level: X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] 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 BkCeMPezvXEK for ; Thu, 11 Jun 2009 10:51:01 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 50D693A6954 for ; Thu, 11 Jun 2009 10:51:01 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BHc7Jg034937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 10:38:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BHc7bZ034936; Thu, 11 Jun 2009 10:38: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 yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.158]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BHbuae034921 for ; Thu, 11 Jun 2009 10:38:06 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by yw-out-1718.google.com with SMTP id 6so829937ywa.4 for ; Thu, 11 Jun 2009 10:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-rim-org-msg-ref-id :return-receipt-to:message-id:content-transfer-encoding:reply-to :x-priority:references:in-reply-to:sensitivity:importance:to:cc :subject:from:date:content-type:mime-version; bh=8Ko9Iek0pwAwgaeqyhJ2PaDvnZ/yUiXWofCDLOF40tg=; b=AA36zpNfeLTxN/yWk4TsR0LJCkVHR6DdxM+uRDAHZ+NyGn0XQNv0ckkqGikQqBxMoJ tj6Pwnn9lmxysSrnbQKVlRXDRLDXJIiJpgXSTpv6SJyrT2TiUzHI5dYh4tvqZ3L/7++B WwKR2+AsgF1dEanpIGMdlOJ6AdoakqxXz/e1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-rim-org-msg-ref-id:return-receipt-to:message-id :content-transfer-encoding:reply-to:x-priority:references :in-reply-to:sensitivity:importance:to:cc:subject:from:date :content-type:mime-version; b=jSjrjw9PS8+5IkgTqHft8e5uypcpUsHK69iW5/4RDgh2601uNFlO7wMz1DAmGXJ3/8 +z8+R++KomGOLA12cx7JMEjdyk1MvST1XbJbsUf9BuYi+oc32nTKFXWUPrJyKxmANqC8 T9YJlDMLGVllh8YL1qjIs9fXg+CtxSUzu570M= Received: by 10.90.50.5 with SMTP id x5mr2330141agx.83.1244741875245; Thu, 11 Jun 2009 10:37:55 -0700 (PDT) Received: from bda703.bisx.prod.on.blackberry (e703.bda.bis.na.blackberry.com [67.223.79.112]) by mx.google.com with ESMTPS id 8sm526642agd.77.2009.06.11.10.37.54 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Jun 2009 10:37:54 -0700 (PDT) X-rim-org-msg-ref-id:465066524 Message-ID:<465066524-1244741872-cardhu_decombobulator_blackberry.rim.net-687038506-@bxe1007.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 Reply-To: jasnell@gmail.com X-Priority: Normal References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2EE11F.2080809@gmail.com><3f1451f50906111033g7833b29bh74fd02b0b5dcb170@mail.gmail.com> In-Reply-To: <3f1451f50906111033g7833b29bh74fd02b0b5dcb170@mail.gmail.com> Sensitivity: Normal Importance: Normal To: "Joe Gregorio" , joe.gregorio@gmail.com Cc: "Nikunj R. Mehta" , "atom-syntax Syntax" Subject: Re: Sub-typing Atom documents From: jasnell@gmail.com Date: Thu, 11 Jun 2009 17:37:54 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: VGhhdCdzIHBvc3NpYmxlIGFsc28gYnV0IG5vdCBhbGwgdGhlIHVzZSBjYXNlcyB3ZSdyZSBkZWFs aW5nIHdpdGggaGVyZSBpbnZvbHZlIHNlcnZpY2UgZG9jdW1lbnRzLiBXZSBuZWVkIGEgbWV0aG9k IG9mIGlkZW50aWZ5aW5nIHRoZSBraW5kIG9mIGF0b20gZG9jdW1lbnRzIHdlJ3JlIGRlYWxpbmcg d2l0aCBhdCBhIGZpbmVyIGxldmVsIG9mIGRldGFpbCB0aGFuIHRoYXQgY3VycmVudGx5IGFsbG93 ZWQgYnkgdGhlIGV4aXN0aW5nIGF0b20gbWVkaWEgdHlwZS4gDQoNCi0gamFtZXMNClNlbnQgZnJv bSBteSBWZXJpem9uIFdpcmVsZXNzIEJsYWNrQmVycnkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEpvZSBHcmVnb3JpbyA8am9lQGJpdHdvcmtpbmcub3JnPg0KDQpEYXRlOiBU aHUsIDExIEp1biAyMDA5IDEzOjMzOjE1IA0KVG86IEphbWVzIE0gU25lbGw8amFzbmVsbEBnbWFp bC5jb20+DQpDYzogTmlrdW5qIFIuIE1laHRhPG5pa3Vuai5tZWh0YUBvcmFjbGUuY29tPjsgYXRv bS1zeW50YXggU3ludGF4PGF0b20tc3ludGF4QGltYy5vcmc+DQpTdWJqZWN0OiBSZTogU3ViLXR5 cGluZyBBdG9tIGRvY3VtZW50cw0KDQoNCk9uIFR1ZSwgSnVuIDksIDIwMDkgYXQgNjoyNCBQTSwg SmFtZXMgTSBTbmVsbDxqYXNuZWxsQGdtYWlsLmNvbT4gd3JvdGU6DQo+DQo+IEkndmUgYWxyZWFk eSBzdGFydGVkIHdvcmtpbmcgdXAgYW4gSS1EIGZvciBhIG5ldyBwcm9maWxlIG1lZGlhIHR5cGUN Cj4gcGFyYW1ldGVyLiBJIHNob3VsZCBiZSBhYmxlIHRvIGdldCBpdCBwdWJsaXNoZWQgYnkgdG9t b3Jyb3cgZW5kLW9mLWRheQ0KPg0KPiBFeGFtcGxlOg0KPg0KPiCgYXBwbGljYXRpb24vYXRvbSt4 bWw7cHJvZmlsZT0iaHR0cDovL2V4YW1wbGUub3JnL3Byb2ZpbGUvZm9vIg0KPg0KPiBUaGUgcHJv ZmlsZSBwYXJhbWV0ZXIgdmFsdWUgaXMgYSBVUkkgdGhhdCBpZGVudGlmaWVzIGEgbG9naWNhbCBw cm9maWxlIHRvDQo+IHdoaWNoIHRoZSBBdG9tIGRvY3VtZW50IGNvbmZvcm1zLiBPbmx5IGEgc2lu Z2xlIHByb2ZpbGUgdmFsdWUgaXMgYWxsb3dlZCBmb3INCj4gbm93Lg0KDQpXaHkgbm90IGV4dGVu ZCB0aGUgU2VydmljZSBEb2N1bWVudCB3aXRoIGV4dHJhIGluZm9ybWF0aW9uIGFib3V0IHdoYXQg dGhlIHNlcnZlcg0Kd2lsbCBhY2NlcHQ/IFRoYXQgd2FzIHRoZSBwb2ludCBvZiB0aGUgc2Vydmlj ZSBkb2N1bWVudCB3aGljaCB3YXMgdG8NCmNvbnRhaW4gdGhhdA0Ka2luZCBvZiBpbmZvcm1hdGlv bi4NCg0KICBUaGFua3MsDQogICAtam9lDQoNCj4NCj4gLSBKYW1lcw0KPg0KPiBOaWt1bmogUi4g TWVodGEgd3JvdGU6DQo+Pg0KPj4gU2V2ZXJhbCByZWNlbnQgZGlzY3Vzc2lvbnMgc3VnZ2VzdCB0 aGUgbmVlZCBmb3Igc3ViLXR5cGluZyBBdG9tIGRvY3VtZW50cy4NCj4+IFRoZXJlIGFyZSB0d28g bWFqb3IgcmVxdWlyZW1lbnRzIGZvciBzdWItdHlwaW5nIEF0b20gZG9jdW1lbnRzOg0KPj4NCj4+ IDEuIEluIEF0b20gUHVibGlzaGluZyBQcm90b2NvbCwgc2lnbmFsaW5nIHRoZSByZXF1aXJlbWVu dCBmb3IgYW4gQXRvbQ0KPj4gZXh0ZW5zaW9uICh3aGV0aGVyIGJsZXNzZWQgYnkgSUVURiBvciBu b3QpIHRvIGJlIHByZXNlbnQgaW4gYWNjZXB0ZWQgY29udGVudA0KPj4gWzFdLiBUbyBpbGx1c3Ry YXRlIHRoZSByZXF1aXJlbWVudCBieSBleGFtcGxlLCBvbmUgd291bGQgc2VlOg0KPj4NCj4+IDxh cHA6YWNjZXB0PmFwcGxpY2F0aW9uL2F0b20reG1sO3R5cGU9ZW50cnk7ZXh0ZW5zaW9uPXRva2Vu PC9hcHA6YWNjZXB0Pg0KPj4NCj4+IDIuIEVzdGFibGlzaGluZyBhbiBleHBlY3RhdGlvbiBvbiBh biBBdG9tIHByb2Nlc3NvciBmb3IgdGhlIG1lZGlhIHR5cGUgb2YNCj4+IGEgbGlua2VkIHJlc291 cmNlLCBlLmcuLCB3aGV0aGVyIHRoZSByZXByZXNlbnRhdGlvbiBpbi1saW5lcyBhIGNvbXBsZXRl DQo+PiBoaWVyYXJjaHkgb2YgQXRvbSBlbnRyaWVzIGFuZCBmZWVkcyBbMl0uIE9uY2UgYWdhaW4g dG8gaWxsdXN0cmF0ZSB0aGUNCj4+IHJlcXVpcmVtZW50IGJ5IGV4YW1wbGUsIG9uZSB3b3VsZCBz ZWU6DQo+Pg0KPj4gPGF0b206bGluayByZWw9ImRvd24iIHR5cGU9ImFwcGxpY2F0aW9uL2F0b20r eG1sO3R5cGU9ZmVlZDtpbmxpbmUtZGVwdGg9MSINCj4+IGhyZWY9ImNoaWxkcmVuIi8+DQo+Pg0K Pj4gT2YgdGhlc2UgY2FzZXMsIGEgcmVhbGx5IHN0cm9uZyBjYXNlIGNhbiBiZSBtYWRlIGZvciB0 aGUgZmlyc3QgcmVxdWlyZW1lbnQNCj4+IHRvIHVzZSBhIG1lZGlhIHR5cGUgcGFyYW1ldGVyLCBz aW5jZSBpdCBoYXMgdG8gaGFwcGVuIGluIHRoZSBhYnNlbmNlIG9mIHRoZQ0KPj4gYWN0dWFsIEF0 b20gZG9jdW1lbnQuIFRoZXJlIGlzIG9ubHkgb25lIG11c3QtdW5kZXJzdGFuZCBzaWduYWxpbmcg bWVjaGFuaXNtDQo+PiBpbiBBdG9tUHViIGFuZCB0aGF0IGlzIGFwcDphY2NlcHQuIElmIGEgbWVk aWEgdHlwZSBwYXJhbWV0ZXIgaXMgdXNlZCBpbg0KPj4gYXBwOmFjY2VwdCB0aGF0IGNhbm5vdCBi ZSB1bmRlcnN0b29kIGJ5IGl0cyByZWNlaXZlciwgdGhlIHJlY2VpdmVyIGhhcyBubw0KPj4gY2hv aWNlIGJ1dCB0byBjZWFzZSBjb21tdW5pY2F0aW9ucyB3aXRoIHRoZSBzZXJ2ZXIuIFNpbmNlIGFs bW9zdCBldmVyeQ0KPj4gQXRvbVB1Yi1zdHlsZSAiQVBJIiBpbnRyb2R1Y2VzIGl0cyBvd24gc2V0 IG9mIHJlcXVpcmVtZW50cyBmb3Igd2hhdA0KPj4gY29uc3RpdHV0ZXMgYW4gZW50cnkgdGhlIHNl cnZlciBpcyB3aWxsaW5nIHRvIGFjY2VwdC4NCj4+DQo+PiBGb3IgZXhhbXBsZSwgR29vZ2xlIEZp bmFuY2UgQVBJIGluIGl0cyBwcm90b2NvbCByZWZlcmVuY2Ugc3RhdGVzIHRoYXQgYW4NCj4+IGVu dHJ5IHBvc3RlZCBhcyBhIG5ldyBwb3J0Zm9saW8gbXVzdCBpbmNsdWRlIGEgImdmOnBvcnRmb2xp b0RhdGEiIGVsZW1lbnQNCj4+IGluc2lkZSBhbiBhdG9tOmVudHJ5IFszXS4gQ01JUyBzZXJ2ZXJz IG1heSByZXF1aXJlIHRoZSBwcmVzZW5jZSBvZiBhIHR5cGUNCj4+IGlkZW50aWZpZXIgYXMgZXh0 ZW5kZWQgZW50cnkgbWV0YWRhdGEgaW4gb3JkZXIgdG8gYWNjZXB0IGFuIGVudHJ5IHBvc3RlZCB0 bw0KPj4gYSBjb2xsZWN0aW9uIFs0XS4NCj4+DQo+PiBJdCBzZWVtcyBxdWl0ZSByZWFzb25hYmxl IHRvIGVzdGFibGlzaCBhIHNpbmdsZSBtZWRpYSB0eXBlIHBhcmFtZXRlciBhbmQNCj4+IGFsbG93 IGV2ZXJ5IHN1Y2ggQVBJIHRvIGRlZmluZSB0aGVpciBvd24gYWNjZXB0YWJsZSB2YWx1ZXMgZm9y IHRoaXMgcHVycG9zZS4NCj4+IFRoaXMgYXBwcm9hY2ggoHByb3ZpZGVzIGZhaXIgd2FybmluZyBh bmQgZW5hYmxlcyBBdG9tUHViIG5pY2hlcyB0byBsZWdhbGx5DQo+PiBleGlzdCwgYW5kIGV2ZW4g aW50ZXJvcGVyYXRlLg0KPj4NCj4+IFRoZSBzZWNvbmQgY2FzZSBjYW4gcHJvYmFibHkgYmVuZWZp dCBmcm9tIGEgbWVkaWEgdHlwZSBwYXJhbWV0ZXIsIGJ1dCBpdA0KPj4gaXMgbm90IGNsZWFyIHdo YXQgdGhlIHNlbWFudGljcyBvZiB0aGF0IHBhcmFtZXRlciB3b3VsZCBiZS4gU3BlY2lmaWNhbGx5 Og0KPj4NCj4+IKAgMS4gRG8gQXRvbSBwcm9jZXNzb3JzIGZhaWwgaWYsIHdoZW4gcHJvY2Vzc2lu ZyBDb250ZW50LVR5cGUgaGVhZGVyLA0KPj4goCCgIKB0aGV5IGVuY291bnRlciBhIG1lZGlhIHR5 cGUgcGFyYW1ldGVyIHRoZXkgZG9uJ3Qga25vdyBhYm91dCBvciBhDQo+PiCgIKAgoHZhbHVlIGlu IGEga25vd24gbWVkaWEgdHlwZSBwYXJhbWV0ZXIgdGhhdCB0aGV5IGRvbid0IHVuZGVyc3RhbmQu DQo+PiCgIDIuIERvZXMgaW50cm9kdWN0aW9uIG9mIG1lZGlhIHR5cGUgcGFyYW1ldGVycyBmb3IN Cj4+IKAgoCCgYXBwbGljYXRpb24vYXRvbSt4bWwgcmVxdWlyZSBzdGFuZGFyZHMgdHJhY2sgUkZD Pw0KPj4NCj4+DQo+PiBOaWt1bmoNCj4+IGh0dHA6Ly9vLW1pY3Jvbi5ibG9nc3BvdC5jb20NCj4+ DQo+PiBbMV0gaHR0cDovL3d3dy5pbWMub3JnL2F0b20tcHJvdG9jb2wvbWFpbC1hcmNoaXZlL21z ZzExMzk4Lmh0bWwNCj4+IFsyXSBodHRwOi8vd3d3LmltYy5vcmcvYXRvbS1zeW50YXgvbWFpbC1h cmNoaXZlL21zZzIxMTE0Lmh0bWwNCj4+IFszXQ0KPj4gaHR0cDovL2NvZGUuZ29vZ2xlLmNvbS9h cGlzL2ZpbmFuY2UvZGV2ZWxvcGVyc19ndWlkZV9wcm90b2NvbC5odG1sI0NyZWF0aW5nUG9ydGZv bGlvcw0KPj4gWzRdIGh0dHA6Ly93d3cub2FzaXMtb3Blbi5vcmcvY29tbWl0dGVlcy9kb3dubG9h ZC5waHAvMzI2NjgNCj4NCj4NCg0KDQoNCi0tIA0KSm9lIEdyZWdvcmlvICAgICAgICBodHRwOi8v Yml0d29ya2luZy5vcmcNCg== From owner-atom-syntax@mail.imc.org Thu Jun 11 10:57:41 2009 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 C0F643A6BB2 for ; Thu, 11 Jun 2009 10:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujfsvIZGLP2n for ; Thu, 11 Jun 2009 10:57:40 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 28C703A6ABA for ; Thu, 11 Jun 2009 10:57:39 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BHj1uX035347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 10:45:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BHj1NX035346; Thu, 11 Jun 2009 10:45: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 rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BHioYU035318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 11 Jun 2009 10:45:01 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5BHiRt1022700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Jun 2009 17:44:28 GMT Received: from abhmt002.oracle.com (abhmt002.oracle.com [141.146.116.11]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5BHii22013627; Thu, 11 Jun 2009 17:44:45 GMT Received: from [10.0.1.195] (/24.130.214.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Jun 2009 10:44:38 -0700 From: "Nikunj R. Mehta" To: jasnell@gmail.com In-Reply-To: <465066524-1244741872-cardhu_decombobulator_blackberry.rim.net-687038506-@bxe1007.bisx.prod.on.blackberry> Subject: Re: Sub-typing Atom documents X-Priority: Normal References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2EE11F.2080809@gmail.com><3f1451f50906111033g7833b29bh74fd02b0b5dcb170@mail.gmail.com> <465066524-1244741872-cardhu_decombobulator_blackberry.rim.net-687038506-@bxe1007.bisx.prod.on.blackberry> Message-Id: <0F7328DB-C559-4AAB-8131-AA21AB23FF01@oracle.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 10:43:16 -0700 Cc: "Joe Gregorio" , joe.gregorio@gmail.com, "atom-syntax Syntax" X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt002.oracle.com [141.146.116.11] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010206.4A314287.027C:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The app:accept can be used in service documents as well as embedded in app:collection inside feeds. That seems to be the best target for extension. There are only two ways I know of to extend app:accept - 1. media type parameters 2. attributes to be used with app:accept draft-gregorio-atom-multipart uses #2 and James is suggesting using #1. Is there any other kind of extension that is possible? Thanks, Nikunj http://o-micron.blogspot.com On Jun 11, 2009, at 10:37 AM, jasnell@gmail.com wrote: > That's possible also but not all the use cases we're dealing with > here involve service documents. We need a method of identifying the > kind of atom documents we're dealing with at a finer level of detail > than that currently allowed by the existing atom media type. > > - james > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: Joe Gregorio > > Date: Thu, 11 Jun 2009 13:33:15 > To: James M Snell > Cc: Nikunj R. Mehta; atom-syntax Syntax > > Subject: Re: Sub-typing Atom documents > > > On Tue, Jun 9, 2009 at 6:24 PM, James M Snell > wrote: >> >> I've already started working up an I-D for a new profile media type >> parameter. I should be able to get it published by tomorrow end-of- >> day >> >> Example: >> >> application/atom+xml;profile="http://example.org/profile/foo" >> >> The profile parameter value is a URI that identifies a logical >> profile to >> which the Atom document conforms. Only a single profile value is >> allowed for >> now. > > Why not extend the Service Document with extra information about > what the server > will accept? That was the point of the service document which was to > contain that > kind of information. > > Thanks, > -joe > >> >> - James >> >> Nikunj R. Mehta wrote: >>> >>> Several recent discussions suggest the need for sub-typing Atom >>> documents. >>> There are two major requirements for sub-typing Atom documents: >>> >>> 1. In Atom Publishing Protocol, signaling the requirement for an >>> Atom >>> extension (whether blessed by IETF or not) to be present in >>> accepted content >>> [1]. To illustrate the requirement by example, one would see: >>> >>> application/atom+xml;type=entry;extension=token>> app:accept> >>> >>> 2. Establishing an expectation on an Atom processor for the media >>> type of >>> a linked resource, e.g., whether the representation in-lines a >>> complete >>> hierarchy of Atom entries and feeds [2]. Once again to illustrate >>> the >>> requirement by example, one would see: >>> >>> >> href="children"/> >>> >>> Of these cases, a really strong case can be made for the first >>> requirement >>> to use a media type parameter, since it has to happen in the >>> absence of the >>> actual Atom document. There is only one must-understand signaling >>> mechanism >>> in AtomPub and that is app:accept. If a media type parameter is >>> used in >>> app:accept that cannot be understood by its receiver, the receiver >>> has no >>> choice but to cease communications with the server. Since almost >>> every >>> AtomPub-style "API" introduces its own set of requirements for what >>> constitutes an entry the server is willing to accept. >>> >>> For example, Google Finance API in its protocol reference states >>> that an >>> entry posted as a new portfolio must include a "gf:portfolioData" >>> element >>> inside an atom:entry [3]. CMIS servers may require the presence of >>> a type >>> identifier as extended entry metadata in order to accept an entry >>> posted to >>> a collection [4]. >>> >>> It seems quite reasonable to establish a single media type >>> parameter and >>> allow every such API to define their own acceptable values for >>> this purpose. >>> This approach provides fair warning and enables AtomPub niches to >>> legally >>> exist, and even interoperate. >>> >>> The second case can probably benefit from a media type parameter, >>> but it >>> is not clear what the semantics of that parameter would be. >>> Specifically: >>> >>> 1. Do Atom processors fail if, when processing Content-Type >>> header, >>> they encounter a media type parameter they don't know about >>> or a >>> value in a known media type parameter that they don't >>> understand. >>> 2. Does introduction of media type parameters for >>> application/atom+xml require standards track RFC? >>> >>> >>> Nikunj >>> http://o-micron.blogspot.com >>> >>> [1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html >>> [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html >>> [3] >>> http://code.google.com/apis/finance/developers_guide_protocol.html#CreatingPortfolios >>> [4] http://www.oasis-open.org/committees/download.php/32668 >> >> > > > > -- > Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Thu Jun 11 11:10:38 2009 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 9429D3A6878 for ; Thu, 11 Jun 2009 11:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Og93IWIu6tK for ; Thu, 11 Jun 2009 11:10:37 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5098C3A687F for ; Thu, 11 Jun 2009 11:10:37 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BHxsG6036294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 10:59:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BHxsqk036293; Thu, 11 Jun 2009 10:59: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 smtp.ischool.berkeley.edu (bliss.ISchool.Berkeley.EDU [128.32.78.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BHxhtT036277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Jun 2009 10:59:54 -0700 (MST) (envelope-from dret@berkeley.edu) Received: from [128.32.226.188] (dhcp188.ISchool.Berkeley.EDU [128.32.226.188]) (authenticated bits=0) by smtp.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id n5BHxhv9005320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 11 Jun 2009 10:59:43 -0700 Message-ID: <4A31460B.5020301@berkeley.edu> Date: Thu, 11 Jun 2009 10:59:39 -0700 From: Erik Wilde User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Atom-Syntax Subject: Re: Tools not supporting atom:content with @src ? References: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> <4A2F00B6.7020504@degeneration.co.uk> <7b9ad66d0906100039y65db0273l5f060744fa373dbe@mail.gmail.com> <23b83f160906101732gd1b0759i32795a75c689ffd7@mail.gmail.com> <23b83f160906110611p65100c2bsa7fdf9a5731decf2@mail.gmail.com> <4A3133C6.4090308@acm.org> In-Reply-To: <4A3133C6.4090308@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 128.32.78.13 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hello. John Panzer wrote: > Ross Singer wrote: >> ... what argument are you making against using the http URI the >> identifier? I understand if the tag URI is necessary for internal >> reasons for the application, but if the http URI is, indeed, a viable >> identifier for the resource... why not use that? > If the http URL is a permanent identifier that will never disappear > unless the resource itself does, and will never be reassigned to some > different resource, then sure. In practice it's very hard to guarantee > this. it's not that hard to guarantee that it will never be re-assigned, and that's all it takes ("disappearing" is not something that can happen to the identifier, i guess you mean that it stops working because of some server or domain reorganization issues). if you encode the date into it as many publishing schemes do, for example, re-assignment becomes almost a non-issue. and it's ok if it stops working from the identifier point of view, all that's required is that it needs to provide identification properties. cheers, dret. From owner-atom-syntax@mail.imc.org Thu Jun 11 11:16:13 2009 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 E4D473A687F for ; Thu, 11 Jun 2009 11:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_45=0.6, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 SM0QdWptWkWo for ; Thu, 11 Jun 2009 11:16:12 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 329433A6873 for ; Thu, 11 Jun 2009 11:16:11 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BI4jrg036635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 11:04:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BI4jVJ036634; Thu, 11 Jun 2009 11:04: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 asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BI4ZNk036624 for ; Thu, 11 Jun 2009 11:04:45 -0700 (MST) (envelope-from algermissen1971@mac.com) MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Received: from spool003.mac.com ([10.150.69.53]) by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0KL300FVJ4QF5U60@asmtp030.mac.com> for atom-syntax@imc.org; Thu, 11 Jun 2009 11:04:35 -0700 (PDT) Received: from webmail040 ([10.13.128.40]) by spool003.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0KL300MC2670WZ20@spool003.mac.com>; Thu, 11 Jun 2009 11:04:23 -0700 (PDT) Date: Thu, 11 Jun 2009 20:04:11 +0200 From: Jan Algermissen To: Joe Gregorio Cc: James M Snell , "Nikunj R. Mehta" , atom-syntax Syntax Message-id: <138228027404607077371424877263830832607-Webmail@me.com> In-reply-to: <3f1451f50906111033g7833b29bh74fd02b0b5dcb170@mail.gmail.com> References: <96028DCC-E62D-4B3E-BF19-EE93E65BA516@oracle.com> <4A2EE11F.2080809@gmail.com> <3f1451f50906111033g7833b29bh74fd02b0b5dcb170@mail.gmail.com> Subject: Re: Sub-typing Atom documents Content-transfer-encoding: quoted-printable Received: from [198.185.18.34] from webmail.me.com with HTTP; Thu, 11 Jun 2009 20:04:11 +0200 X-Originating-IP: 198.185.18.34 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: =20 On Thursday, June 11, 2009, at 07:33PM, "Joe Gregorio" = wrote: > >On Tue, Jun 9, 2009 at 6:24 PM, James M Snell wrote: >> >> I've already started working up an I-D for a new profile media type >> parameter. I should be able to get it published by tomorrow end-of-day >> >> Example: >> >> application/atom+xml;profile=3D"http://example.org/profile/foo" >> >> The profile parameter value is a URI that identifies a logical profile t= o >> which the Atom document conforms. Only a single profile value is allowed= for >> now. > >Why not extend the Service Document with extra information about what the = server >will accept? That was the point of the service document which was to >contain that >kind of information. Wasn't this the intent of the features draft? What I like about the profile parameter is that it provides the opportunity= to do a sort client side negotiation with a server that can serve up Atom = in different varieties, such as: My Entry =20 The client could pick the variant it wants based on the profile. Jan =20 On Thursday, June 11, 2009, at 07:33PM, "Joe Gregorio" = wrote: > >On Tue, Jun 9, 2009 at 6:24 PM, James M Snell wrote: >> >> I've already started working up an I-D for a new profile media type >> parameter. I should be able to get it published by tomorrow end-of-day >> >> Example: >> >> =A0application/atom+xml;profile=3D"http://example.org/profile/foo" >> >> The profile parameter value is a URI that identifies a logical profile t= o >> which the Atom document conforms. Only a single profile value is allowed= for >> now. > >Why not extend the Service Document with extra information about what the = server >will accept? That was the point of the service document which was to >contain that >kind of information. > > Thanks, > -joe > >> >> - James >> >> Nikunj R. Mehta wrote: >>> >>> Several recent discussions suggest the need for sub-typing Atom documen= ts. >>> There are two major requirements for sub-typing Atom documents: >>> >>> 1. In Atom Publishing Protocol, signaling the requirement for an Atom >>> extension (whether blessed by IETF or not) to be present in accepted co= ntent >>> [1]. To illustrate the requirement by example, one would see: >>> >>> application/atom+xml;type=3Dentry;extension=3Dtoken >>> >>> 2. Establishing an expectation on an Atom processor for the media type = of >>> a linked resource, e.g., whether the representation in-lines a complete >>> hierarchy of Atom entries and feeds [2]. Once again to illustrate the >>> requirement by example, one would see: >>> >>> >> href=3D"children"/> >>> >>> Of these cases, a really strong case can be made for the first requirem= ent >>> to use a media type parameter, since it has to happen in the absence of= the >>> actual Atom document. There is only one must-understand signaling mecha= nism >>> in AtomPub and that is app:accept. If a media type parameter is used in >>> app:accept that cannot be understood by its receiver, the receiver has = no >>> choice but to cease communications with the server. Since almost every >>> AtomPub-style "API" introduces its own set of requirements for what >>> constitutes an entry the server is willing to accept. >>> >>> For example, Google Finance API in its protocol reference states that a= n >>> entry posted as a new portfolio must include a "gf:portfolioData" eleme= nt >>> inside an atom:entry [3]. CMIS servers may require the presence of a ty= pe >>> identifier as extended entry metadata in order to accept an entry poste= d to >>> a collection [4]. >>> >>> It seems quite reasonable to establish a single media type parameter an= d >>> allow every such API to define their own acceptable values for this pur= pose. >>> This approach =A0provides fair warning and enables AtomPub niches to le= gally >>> exist, and even interoperate. >>> >>> The second case can probably benefit from a media type parameter, but i= t >>> is not clear what the semantics of that parameter would be. Specificall= y: >>> >>> =A0 1. Do Atom processors fail if, when processing Content-Type header, >>> =A0 =A0 =A0they encounter a media type parameter they don't know about = or a >>> =A0 =A0 =A0value in a known media type parameter that they don't unders= tand. >>> =A0 2. Does introduction of media type parameters for >>> =A0 =A0 =A0application/atom+xml require standards track RFC? >>> >>> >>> Nikunj >>> http://o-micron.blogspot.com >>> >>> [1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html >>> [2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html >>> [3] >>> http://code.google.com/apis/finance/developers_guide_protocol.html#Crea= tingPortfolios >>> [4] http://www.oasis-open.org/committees/download.php/32668 >> >> > > > >--=20 >Joe Gregorio http://bitworking.org > > > From owner-atom-syntax@mail.imc.org Thu Jun 11 12:38:18 2009 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 37CE628C17C for ; Thu, 11 Jun 2009 12:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.996 X-Spam-Level: X-Spam-Status: No, score=-5.996 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LZ-Bop77YyY for ; Thu, 11 Jun 2009 12:38:17 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B287F3A6A70 for ; Thu, 11 Jun 2009 12:38:16 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BJRS1k041495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 12:27:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BJRSbD041494; Thu, 11 Jun 2009 12:27: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 rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BJRHmK041477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 11 Jun 2009 12:27:27 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5BJSAAC010666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Jun 2009 19:28:12 GMT Received: from abhmt002.oracle.com (abhmt002.oracle.com [141.146.116.11]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5BJSNxl026172; Thu, 11 Jun 2009 19:28:23 GMT Received: from [10.0.1.195] (/24.130.214.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Jun 2009 12:27:11 -0700 Cc: Message-Id: <57F7E2E5-7154-4B2C-8323-C5583FFB6B5D@oracle.com> From: "Nikunj R. Mehta" To: Davis_Cornelia@emc.com In-Reply-To: <7AAE36EDD1ECFA4494AA25ADA2338C8501A1DFBE@CORPUSMX20B.corp.emc.com> Content-Type: multipart/alternative; boundary=Apple-Mail-60-153176917 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-02 Date: Thu, 11 Jun 2009 12:25:49 -0700 References: <20090610003357.59F6B3A6916@core3.amsl.com> <7D3F8024-3112-4D6B-B0C8-79A7654CB7B7@oracle.com> <7AAE36EDD1ECFA4494AA25ADA2338C8501A1DFBE@CORPUSMX20B.corp.emc.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt002.oracle.com [141.146.116.11] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4A315A90.022C:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-60-153176917 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Jun 10, 2009, at 9:47 PM, Davis_Cornelia@emc.com wrote: > I confess that initially I thought that this wasn=92t a mimetype =20 > issue, that we were talking about two different resources =96 the set =20= > of children and the set of descendants. But what is proposed here =20= > is far more elegant, and is nicely cast as a mime-type choice. The =20= > key is that the link relation =93down=94 only ever returns a child (as = =20 > application/atom+xml;type=3Dentry) or a feed containing _only =20 > children_ (as application/atom+xml;type=3Dfeed) =96 what differs is = the =20 > representation format of that child (expanded or not). Actually, atom-hierarchy-02 allows link@rel=3Ddown with other non-Atom =20= @type values too. Not only that, presently a combination of @type =20 values can be used in a single entry with link@rel=3Ddown, including =20 Atom content type. Is that overly flexible? That is the currently open question. Nikunj http://o-micron.blogspot.com --Apple-Mail-60-153176917 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable On Jun 10, 2009, at = 9:47 PM, Davis_Cornelia@emc.com = wrote: I confess that initially I = thought that this wasn=92t a mimetype issue, that we were talking about = two different resources =96 the set of children and the set of = descendants. But what is proposed here is far more elegant, = and is nicely cast as a mime-type choice. The key is that the link = relation =93down=94 only ever returns a child (as ) or a feed containing _only children_ (as ) =96 what differs is the = representation format of that child (expanded or = not). Actually, = atom-hierarchy-02 allows link@rel=3Ddown with other non-Atom @type = values too. Not only that, presently a combination of @type values can = be used in a single entry with link@rel=3Ddown, including Atom content = type. Is that overly flexible? That is the = currently open question. Nikunj http://o-micron.blogspot.com = --Apple-Mail-60-153176917-- From owner-atom-syntax@mail.imc.org Thu Jun 11 12:44:34 2009 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 8A0033A6C2C for ; Thu, 11 Jun 2009 12:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.412 X-Spam-Level: X-Spam-Status: No, score=-5.412 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hbof0vZnzlCL for ; Thu, 11 Jun 2009 12:44:33 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 340CF3A67CC for ; Thu, 11 Jun 2009 12:44:32 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BJV2CG041721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 12:31:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BJV2vv041720; Thu, 11 Jun 2009 12:31:02 -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 acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BJUonh041703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 11 Jun 2009 12:31:01 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5BJQW8F007948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Jun 2009 19:26:33 GMT Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5BJUo0c007382; Thu, 11 Jun 2009 19:30:50 GMT Received: from [10.0.1.195] (/24.130.214.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Jun 2009 12:30:43 -0700 Cc: atom-syntax Syntax Message-Id: From: "Nikunj R. Mehta" To: Hadrien Gardeur In-Reply-To: <404dcbd20906101336r7eca4b0bwecf3f0c7c33dafff@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-61-153389373 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-02 Date: Thu, 11 Jun 2009 12:29:21 -0700 References: <20090610003357.59F6B3A6916@core3.amsl.com> <7D3F8024-3112-4D6B-B0C8-79A7654CB7B7@oracle.com> <404dcbd20906101336r7eca4b0bwecf3f0c7c33dafff@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt001.oracle.com [141.146.116.10] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4A315B64.0336:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-61-153389373 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 10, 2009, at 1:36 PM, Hadrien Gardeur wrote: > I'd like to see some recommendations concerning thr:count, now that > ah:count isn't in the I-D anymore. > > Maybe something like: > "A link@rel="down" MAY indicate the number of child elements through > thr:count [RFC4685]. Atom clients can use this information to decide > if they need to GET the entry." > And remind this too: http://tools.ietf.org/html/rfc4685#section-6 This is certainly doable. In case you are interested, you can track it [1]. Nikunj [1] http://code.google.com/p/atom-ext/issues/detail?id=1 --Apple-Mail-61-153389373 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Jun 10, 2009, at 1:36 PM, = Hadrien Gardeur wrote: I'd like = to see some recommendations concerning thr:count, now that ah:count = isn't in the I-D anymore. Maybe something = like: "A link@rel=3D"down" MAY indicate the number of child = elements through thr:count [RFC4685]. Atom clients can use this = information to decide if they need to GET the entry." And = remind this too: http://tools.ietf.or= g/html/rfc4685#section-6 This is = certainly doable. In case you are interested, you can track it = [1]. Nikunj [1] http://cod= e.google.com/p/atom-ext/issues/detail?id=3D1= --Apple-Mail-61-153389373-- From owner-atom-syntax@mail.imc.org Thu Jun 11 12:54:03 2009 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 0EE7128C17C for ; Thu, 11 Jun 2009 12:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.112 X-Spam-Level: X-Spam-Status: No, score=-5.112 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiWMIPzPA3fL for ; Thu, 11 Jun 2009 12:54:02 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D3BD63A6A14 for ; Thu, 11 Jun 2009 12:54:01 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BJhAqs042706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 12:43:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BJhAdo042705; Thu, 11 Jun 2009 12:43:10 -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 rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BJh8qe042698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 11 Jun 2009 12:43:09 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5BJi2tw013868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Jun 2009 19:44:04 GMT Received: from abhmt008.oracle.com (abhmt008.oracle.com [141.146.116.17]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5BJh9eX000559; Thu, 11 Jun 2009 19:43:10 GMT Received: from [10.0.1.195] (/24.130.214.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Jun 2009 12:43:03 -0700 From: "Nikunj R. Mehta" To: jasnell@gmail.com In-Reply-To: <477525907-1244658553-cardhu_decombobulator_blackberry.rim.net-228592719-@bxe1007.bisx.prod.on.blackberry> Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-02 X-Priority: Normal References: <20090610003357.59F6B3A6916@core3.amsl.com> <7D3F8024-3112-4D6B-B0C8-79A7654CB7B7@oracle.com> <4A2FF3AF.3070803@gmail.com> <477525907-1244658553-cardhu_decombobulator_blackberry.rim.net-228592719-@bxe1007.bisx.prod.on.blackberry> Message-Id: <33554C6B-3EC8-4699-AB00-8422B7250C2E@oracle.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 12:41:41 -0700 Cc: "atom-syntax Syntax" X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt008.oracle.com [141.146.116.17] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4A315E48.0249:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 10, 2009, at 11:29 AM, jasnell@gmail.com wrote: > Yes, the issue did exist before given that the linked atom feed > could easily have multiple atom:entry elements with the same atom:id > value as allowed by rfc4287. It is a simple matter to answer whether > there can be multiple distict child sets or a single logical child > set and to answer whether membership in that set is based on > instance or identity. > I see what you are saying. Perhaps we can just follow RFC4287 and say that the entry with the latest atom:updated wins. In that sense, membership in the logical child set is based on instance. [1] > - James > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: "Nikunj R. Mehta" > > Date: Wed, 10 Jun 2009 11:15:04 > To: James M Snell > Cc: atom-syntax Syntax > Subject: Re: New Version Notification for draft-divilly-atom- > hierarchy-02 > > > On Jun 10, 2009, at 10:55 AM, James M Snell wrote: > >> Thank you for the changes. Another issue that needs to be looked at >> (which existing in the previous version of the draft as well) > > This issue did not exist in the previous draft since only one link > with @rel value down and @type application/atom+xml was possible. > >> is how a processor can reconstruct the logical set of children for >> an entry... that is, for instance, if the set of child entries >> contains multiple atom:entry elements with the same atom:id value, >> are those viewed as separate children or is only the entry with the >> most recent atom:updated value included in the set of children? > [1] http://code.google.com/p/atom-ext/issues/detail?id=4 From jtellis@amec-connectionallay.org Thu Jun 11 21:02:29 2009 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 A1C983A6BED for ; Thu, 11 Jun 2009 21:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.268 X-Spam-Level: X-Spam-Status: No, score=-5.268 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 l14Gmdb-oCqM for ; Thu, 11 Jun 2009 21:02:22 -0700 (PDT) Received: from 97-127-225-157.dvnp.qwest.net (97-127-225-157.dvnp.qwest.net [97.127.225.157]) by core3.amsl.com (Postfix) with SMTP id 392783A6A69 for ; Thu, 11 Jun 2009 21:02:20 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: DataArt Monthly News #07879 From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090612040221.392783A6A69@core3.amsl.com> Date: Thu, 11 Jun 2009 21:02:20 -0700 (PDT) Special Offers by email Dear our client, You have registered to receive special offers by email. Your first newsletter will be delivered soon. You may unsubscribe at any time by clicking unsubscribe in the emails you receive, or by visiting www.5BKk0.caringhigh.com. You may also change your preferences at any time by visiting www.oSeu0.objectlead.com. Best regards, First Online Business Brothers. From owner-atom-syntax@mail.imc.org Thu Jun 11 21:45:10 2009 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 6E6C93A6D93 for ; Thu, 11 Jun 2009 21:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.177 X-Spam-Level: X-Spam-Status: No, score=-100.177 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=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 4xQzauA2Verq for ; Thu, 11 Jun 2009 21:45:09 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 17BFB3A6D70 for ; Thu, 11 Jun 2009 21:45:08 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C4WV5F069301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 21:32:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5C4WVPu069300; Thu, 11 Jun 2009 21:32:31 -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 wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C4WKoq069287 for ; Thu, 11 Jun 2009 21:32:30 -0700 (MST) (envelope-from john@johnpanzer.com) Received: by wf-out-1314.google.com with SMTP id 28so716785wfc.28 for ; Thu, 11 Jun 2009 21:32:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.34.20 with SMTP id m20mr1171074wfj.347.1244781139826; Thu, 11 Jun 2009 21:32:19 -0700 (PDT) In-Reply-To: <4A313641.8060808@defuze.org> References: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> <4A2F00B6.7020504@degeneration.co.uk> <7b9ad66d0906100039y65db0273l5f060744fa373dbe@mail.gmail.com> <23b83f160906101732gd1b0759i32795a75c689ffd7@mail.gmail.com> <23b83f160906110611p65100c2bsa7fdf9a5731decf2@mail.gmail.com> <4A3133C6.4090308@acm.org> <4A313641.8060808@defuze.org> Date: Thu, 11 Jun 2009 21:32:19 -0700 X-Google-Sender-Auth: 15a7b7c625a9eaab Message-ID: <30ac519d0906112132l507bf651p79e3e5c6d576c86c@mail.gmail.com> Subject: Re: Tools not supporting atom:content with @src ? From: John Panzer To: Sylvain Hellegouarch Cc: jpanzer@acm.org, Ross Singer , Thomas Broyer , Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: An http URL is as good as any other URI as an opaque identifier, all other things like permanence being equal. On Thursday, June 11, 2009, Sylvain Hellegouarch wrote: > John Panzer a =E9crit : > > > Ross Singer wrote: > > ... what argument are you making against using the http URI the > identifier? =A0I understand if the tag URI is necessary for internal > reasons for the application, but if the http URI is, indeed, a viable > identifier for the resource... why not use that? > > > If the http URL is a permanent identifier that will never disappear unles= s the resource itself does, and will never be reassigned to some different = resource, then sure. =A0In practice it's very hard to guarantee this. > > Well it goes quite beyond the persistence of the value. The atom:id is an= opaque string, it's a IRI, not a URL. Bypassing the difference really brea= ks the spirit behind it. > > Use atom:link for that. > > - Sylvain > From owner-atom-syntax@mail.imc.org Thu Jun 11 23:49:00 2009 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 C9EB23A6C33 for ; Thu, 11 Jun 2009 23:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=0.661, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 1+Gfm1AWFhGc for ; Thu, 11 Jun 2009 23:49:00 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id CBDE33A68E4 for ; Thu, 11 Jun 2009 23:48:59 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C6cFDL074991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 23:38:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5C6cFq0074990; Thu, 11 Jun 2009 23:38: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 mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C6c4pj074980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Jun 2009 23:38:14 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.0.10] (localhost.localdomain [127.0.0.1]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id n5C6bxrP007061; Fri, 12 Jun 2009 01:38:00 -0500 Message-ID: <4A31F7C7.7010202@defuze.org> Date: Fri, 12 Jun 2009 08:37:59 +0200 From: Sylvain Hellegouarch User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: John Panzer CC: Ross Singer , Thomas Broyer , Atom-Syntax Subject: Re: Tools not supporting atom:content with @src ? References: <7b9ad66d0906091542u3f2fca2fpc775d2504d5dbedc@mail.gmail.com> <4A2F00B6.7020504@degeneration.co.uk> <7b9ad66d0906100039y65db0273l5f060744fa373dbe@mail.gmail.com> <23b83f160906101732gd1b0759i32795a75c689ffd7@mail.gmail.com> <23b83f160906110611p65100c2bsa7fdf9a5731decf2@mail.gmail.com> <4A3133C6.4090308@acm.org> <4A313641.8060808@defuze.org> <30ac519d0906112132l507bf651p79e3e5c6d576c86c@mail.gmail.com> In-Reply-To: <30ac519d0906112132l507bf651p79e3e5c6d576c86c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Panzer a écrit : > An http URL is as good as any other URI as an opaque identifier, all > other things like permanence being equal. > Of course it is, but the question wasn't about using a URL as a identifier, but using the identifier as the locator. - Sylvain From owner-atom-syntax@mail.imc.org Fri Jun 12 02:54:34 2009 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 8EEC93A6864 for ; Fri, 12 Jun 2009 02:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.036 X-Spam-Level: X-Spam-Status: No, score=-6.036 tagged_above=-999 required=5 tests=[AWL=-3.437, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtxZEG-N4hnx for ; Fri, 12 Jun 2009 02:54:33 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7DF2B3A67F6 for ; Fri, 12 Jun 2009 02:54:33 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C9fMdH084315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 02:41:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5C9fMWi084313; Fri, 12 Jun 2009 02:41: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 mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n5C9f95C084291 for ; Fri, 12 Jun 2009 02:41:20 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 12 Jun 2009 09:41:08 -0000 Received: from p508FD498.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.212.152] by mail.gmx.net (mp071) with SMTP; 12 Jun 2009 11:41:08 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/W0zQSI+HW33E7p98JuRlU/dnVBaf3AzdQfrQeiM IupAupHydvTpzr Message-ID: <4A3222B1.20800@gmx.de> Date: Fri, 12 Jun 2009 11:41:05 +0200 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: "Nikunj R. Mehta" CC: atom-syntax Syntax , atom-protocol Protocol Subject: Re: Exploring a new WG around Atom References: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> In-Reply-To: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Nikunj R. Mehta wrote: > > Recent discussions on the atom-syntax mailing list has revealed interest > in creating a new WG to look at several extensions of Atom. Here are > several extensions that have been discussed: > > 1. Hierarchy operations including meta-publishing > 2. In-line representation > 3. Bi-directional text > > Please respond to this email if you are interested in helping to explore > a new WG further. Please also identify if you have a specific interest > area to consider for a potential new Atom WG. > ... 4. Using the PATCH method (*) for partial updates to Atom entry documents. BR, Julian (*) From owner-atom-syntax@mail.imc.org Fri Jun 12 04:29:09 2009 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 DFC353A6D33 for ; Fri, 12 Jun 2009 04:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoeiOhcR9BVs for ; Fri, 12 Jun 2009 04:29:09 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C7C6E3A6ADB for ; Fri, 12 Jun 2009 04:29:08 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CBFkih090126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 04:15:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5CBFkYd090125; Fri, 12 Jun 2009 04:15: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 mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CBFYGK090108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 12 Jun 2009 04:15:45 -0700 (MST) (envelope-from Brett.Lindsley@motorola.com) X-VirusChecked: Checked X-Env-Sender: Brett.Lindsley@motorola.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1244805333!13508957!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 28561 invoked from network); 12 Jun 2009 11:15:34 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-13.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Jun 2009 11:15:34 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.14.3/8.14.3) with ESMTP id n5CBFHuj027969; Fri, 12 Jun 2009 04:15:33 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n5CBFH1t029336; Fri, 12 Jun 2009 06:15:17 -0500 (CDT) Received: from de01exm69.ds.mot.com (de01exm69.am.mot.com [10.176.8.25]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n5CBFHLx029331; Fri, 12 Jun 2009 06:15:17 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Exploring a new WG around Atom Date: Fri, 12 Jun 2009 07:14:55 -0400 Message-ID: In-Reply-To: <4A3222B1.20800@gmx.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Exploring a new WG around Atom Thread-Index: AcnrRAwI8bAv0HtTSrKTGIrgF7jmKgACpYeQ References: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> <4A3222B1.20800@gmx.de> From: "Lindsley Brett-ABL001" To: "atom-syntax Syntax" , "atom-protocol Protocol" X-CFilter-Loop: Reflected Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I am also interested in new WG activities. My interests are: 1. Intermediate aggregation. 2. Security, signatures, etc. 3. Usage rules, rights, etc. Some of this may be outside the domain of Atom WG. I am interested in using Atom for non-blogging publication applications. Brett Lindsley Motorola Applied Research & Technology Center From owner-atom-syntax@mail.imc.org Fri Jun 12 07:07:41 2009 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 460213A67E7 for ; Fri, 12 Jun 2009 07:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.921 X-Spam-Level: X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[AWL=-3.322, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nvAU00ALN4c for ; Fri, 12 Jun 2009 07:07:40 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D6FF53A6765 for ; Fri, 12 Jun 2009 07:07:39 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CDu4WT099192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 06:56:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5CDu407099191; Fri, 12 Jun 2009 06:56: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 mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n5CDtqoX099182 for ; Fri, 12 Jun 2009 06:56:03 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 12 Jun 2009 13:55:52 -0000 Received: from p508FD498.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.212.152] by mail.gmx.net (mp012) with SMTP; 12 Jun 2009 15:55:52 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+9fmRKZ0e9Mnan0a3rw4CTwpuEJQgafhHGb2VukN V/CSZjTgZfzh65 Message-ID: <4A325E64.7040409@gmx.de> Date: Fri, 12 Jun 2009 15:55:48 +0200 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 Syntax'" Subject: Re: I-D Action:draft-brown-versioning-link-relations-00.txt References: <20090612134501.3D17F3A68AA@core3.amsl.com> In-Reply-To: <20090612134501.3D17F3A68AA@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, as part of the ongoing process of making the CMIS AtomPub protocol bindings a good citizen IETF-wise, we have been going through all the link relations it defines, and grouped them into CMIS-specific (these will use a CMIS-specific IRI and will not be registered), and general purpose. The second group consists of the hierarchy link relations we are already discussing (Nikunj's Internet-Draft), and link relations for navigating version histories, which Al Brown and myself have been working on. This draft (*) is just a start; we have a few open issues (marked as such), examples are missing, and I'd also like to discuss the relationship with JCR and WebDAV in an appendix, but didn't have time to do so yet. Nevertheless it would be nice to get early feedback about whether this makes sense, and whether something important is missing to make it useful in non-CMIS scenarios. Feedback appreciated! BR, Julian (*) HTML version and latest edits at: ) Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Link Relations for Simple Version Navigation > Author(s) : A. Brown, J. Reschke > Filename : draft-brown-versioning-link-relations-00.txt > Pages : 6 > Date : 2009-06-12 > > This specification defines Atom link relations for navigation between > a resource and its versions.Editorial Note (To be removed by RFC Editor > before publication) > > Please send comments to the Atom Syntax mailing list > (). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From owner-atom-syntax@mail.imc.org Fri Jun 12 07:25:53 2009 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 C462E3A6814 for ; Fri, 12 Jun 2009 07:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCDFhFWUYwvq for ; Fri, 12 Jun 2009 07:25:52 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 66D003A6806 for ; Fri, 12 Jun 2009 07:25:52 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CECP2Y000432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 07:12:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5CECPWe000430; Fri, 12 Jun 2009 07:12: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 rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CECDAW000408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 12 Jun 2009 07:12:24 -0700 (MST) (envelope-from colm.divilly@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5CED7n9005954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Jun 2009 14:13:09 GMT Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5CEDJLq015963; Fri, 12 Jun 2009 14:13:19 GMT Received: from [10.169.115.231] (/10.169.115.231) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 12 Jun 2009 07:12:07 -0700 Message-ID: <4A326242.6080407@oracle.com> Date: Fri, 12 Jun 2009 15:12:18 +0100 From: Colm Divilly Organization: Oracle Corporation User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Nikunj R. Mehta" CC: atom-syntax Syntax , atom-protocol Protocol Subject: Re: Exploring a new WG around Atom References: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> In-Reply-To: <76C65F4C-7CEB-4F16-B9E7-35757E3D6D76@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: abhmt004.oracle.com [141.146.116.13] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4A326238.00B1:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm interested, specific areas of interest would be: - meta-publishing - query-feed discovery/navigation, i.e. discovering what queries can be applied to a collection, or even a mechanism for end-users to publish their own custom queries searching over AtomPub collection(s), and advertise those queries to other users. Regards, Colm Divilly Nikunj R. Mehta wrote: > > Recent discussions on the atom-syntax mailing list has revealed > interest in creating a new WG to look at several extensions of Atom. > Here are several extensions that have been discussed: > > 1. Hierarchy operations including meta-publishing > 2. In-line representation > 3. Bi-directional text > > Please respond to this email if you are interested in helping to > explore a new WG further. Please also identify if you have a specific > interest area to consider for a potential new Atom WG. > > Nikunj > http://o-micron.blogspot.com > From k_boomera@agora.bungi.com Fri Jun 12 09:28:50 2009 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 63E923A6806 for ; Fri, 12 Jun 2009 09:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.335 X-Spam-Level: X-Spam-Status: No, score=-26.335 tagged_above=-999 required=5 tests=[BAYES_60=1, GB_I_LETTER=-2, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_NJABL_SPAM=2.072, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 VfHTR8FbQs9r for ; Fri, 12 Jun 2009 09:28:49 -0700 (PDT) Received: from OL4-138.fibertel.com.ar (OL4-138.fibertel.com.ar [24.232.138.4]) by core3.amsl.com (Postfix) with SMTP id 017953A67E2 for ; Fri, 12 Jun 2009 09:28:47 -0700 (PDT) To: atompub-archive@lists.ietf.org Subject: ALM Works From: atompub-archive@lists.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090612162848.017953A67E2@core3.amsl.com> Date: Fri, 12 Jun 2009 09:28:47 -0700 (PDT) Special Offers by email Dear our client, You have registered to receive special offers by email. Your first newsletter will be delivered soon. You may unsubscribe at any time by clicking unsubscribe in the emails you receive, or by visiting www.DsTwn.salthim.com. You may also change your preferences at any time by visiting www.4JDKk.subtlefruit.com. Best regards, First Online Business Brothers. From mcnaughtonjm9@sbinformatica.com.br Fri Jun 12 12:32:08 2009 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 7B65C3A68AA; Fri, 12 Jun 2009 12:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -37.857 X-Spam-Level: X-Spam-Status: No, score=-37.857 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_RHS_DOB=1.083, URIBL_SBL=20, 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 Z46XA9QwgJnq; Fri, 12 Jun 2009 12:32:01 -0700 (PDT) Received: from c-98-243-101-254.hsd1.mi.comcast.net (c-98-243-101-254.hsd1.mi.comcast.net [98.243.101.254]) by core3.amsl.com (Postfix) with ESMTP id 9D6F83A682B; Fri, 12 Jun 2009 12:31:54 -0700 (PDT) Message-ID: <000d01c9eb94$759efa50$6400a8c0@mcnaughtonjm9> From: atompub-archive@megatron.ietf.org To: Subject: Feel Full Faster and Stay Full Longer Date: Fri, 12 Jun 2009 12:32:01 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9EB94.759EFA50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9EB94.759EFA50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable View online version here: here =20 =20 =20 =20 =20 =20 June=20 12, 2009 =20 =20 =20 =20 Sign up Forward Archive Advertise =20 =20 =20 =20 Feel Full Faster and Stay Full Longer Just push the button =20 This=20 Newsletter was created for atompub-archive@megatron.ietf.org =20 =20 =20 =20 =20 =20 =20 Subscriber=20 Tools =20 Update=A0account=A0information=A0|=20 Change=A0e-mail=A0address=A0| Unsubscribe=A0| Print=A0fri= endly=A0format=A0| Web=A0version=A0 =20 ¿=20 1999-2009 Qsofo, Inc.=AE=A0Legal=20 Information =A0 ------=_NextPart_000_0007_01C9EB94.759EFA50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable View online version here: here June=20 12, 2009 Sign up Forward Archive Advertise Feel Full Faster and Stay Fu= ll Longer Just push the bu= tton This=20 Newsletter was created for atompub-archive@megatron.ietf.org<= /STRONG> Subscriber=20 Tools ¿=20 1999-2009 Qsofo, Inc.=AE=A0Legal=20 Information Update=A0account=A0information=A0|=20 Change=A0e-mail=A0address=A0| Unsubscribe=A0| Print=A0friendly=A0format=A0| Web=A0version=A0 =A0 ------=_NextPart_000_0007_01C9EB94.759EFA50-- From slouch@planetmoon.com Fri Jun 12 15:16:20 2009 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 6BEEA3A6A5F; Fri, 12 Jun 2009 15:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.143 X-Spam-Level: X-Spam-Status: No, score=-31.143 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_MISMATCH_BR=2.4, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_URI_LET_DIG_PIC=1.157, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_RHS_DOB=1.083, URIBL_SBL=20, 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 mpoRfaNYaqmz; Fri, 12 Jun 2009 15:16:19 -0700 (PDT) Received: from 201-66-197-74.paemt702.dsl.brasiltelecom.net.br (unknown [189.73.191.74]) by core3.amsl.com (Postfix) with ESMTP id A21303A68F5; Fri, 12 Jun 2009 15:16:18 -0700 (PDT) Date: Fri, 12 Jun 2009 19:16:13 -0300 Message-Id: From: atompub-archive@megatron.ietf.org To: atompub-archive@megatron.ietf.org Subject: Completely Safe...NO Side Effects Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Having problems viewing this email? Click here. Know someone else? Forward This Email! We hope you enjoy receiving emails from Kuxqnyza. If you do not wish to receive them, please click here. Copyright ¿2000-2009 Ilql, Inc. 08224, Inc. 9441565 woetg ozzqyyjiu, WK 1714 Privacy Policy | Terms of Use | Customer Service | Site Map From staggeringf@planetwebsite.com Fri Jun 12 15:26:07 2009 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 B892D3A6928; Fri, 12 Jun 2009 15:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.274 X-Spam-Level: * X-Spam-Status: No, score=1.274 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_52=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, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_URI_VDRUG_GIF=1.666, SUBJECT_DIET=1.466, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, 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 hNyEcS79lDqZ; Fri, 12 Jun 2009 15:26:06 -0700 (PDT) Received: from 201-24-179-248.cpece700.dsl.brasiltelecom.net.br (201-67-26-64.cpece700.dsl.brasiltelecom.net.br [201.67.26.64]) by core3.amsl.com (Postfix) with ESMTP id 37F5A3A68C1; Fri, 12 Jun 2009 15:26:05 -0700 (PDT) Message-ID: <000d01c9ebac$a6412800$6400a8c0@staggeringf> From: atompub-archive@megatron.ietf.org To: Subject: Acai Berry Lose weight now Date: Fri, 12 Jun 2009 18:25:11 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9EBAC.A6412800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9EBAC.A6412800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 Having problems viewing=20 this email? Click=20 here. =20 =20 =20 =20 =20 =20 =20 =20 =20 =A0 =20 =20 =20 =20 =20 Know=20 someone else? Forward This=20 Email!We hope you enjoy receiving emails=20 from Kuxqnyza. If you do not wish to receive them, please= click=20 here.Copyright ¿2000-2009 Ilql, Inc.=20 73095, Inc. 7712 zqkjn jrtvhb, WK 9057795Privacy=20 Policy=A0=A0|=A0=A0Terms of=20 Use=A0=A0|=A0=A0Customer=20 Service=A0=A0|=A0=A0Site=20 Map =A0 =A0 ------=_NextPart_000_0007_01C9EBAC.A6412800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =A0 ------=_NextPart_000_0007_01C9EBAC.A6412800-- From owner-atom-syntax@mail.imc.org Fri Jun 12 16:06:04 2009 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 282843A6967 for ; Fri, 12 Jun 2009 16:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HEnkiH13mEM for ; Fri, 12 Jun 2009 16:06:03 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E6D553A6856 for ; Fri, 12 Jun 2009 16:06:02 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CMr5aH029622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 15:53:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5CMr5fK029621; Fri, 12 Jun 2009 15:53:05 -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-px0-f175.google.com (mail-px0-f175.google.com [209.85.216.175]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CMqsvu029613 for ; Fri, 12 Jun 2009 15:53:05 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by pxi5 with SMTP id 5so809341pxi.16 for ; Fri, 12 Jun 2009 15:52:54 -0700 (PDT) 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:content-type :content-transfer-encoding; bh=BciWUCHo7NiM5KOs+2fESncUnYelRrauXUiZ6LTQwRs=; b=VrTMSrQ3mchIe27P7Fk/XREZtpKu2FjJ5i5C6vDScaLHSK0HmWJ2bQ9O5dzR3n3Gyd 45P9Jg9I3WbDHFpk6psW8O6UpLqwOMJM+EIXZS/QHqFSy3Huxs4yItqrxWI0zRkbwYpF XEOrUwT9NKfGAMcvRQ2rNyZhb6LRwmLMnt1pU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=aOnF86xah3poFu7i5eHMAgyNxAX/xKaZ+CX811GEOxUHXxD+T1cSLXCa8yy3nquZJF E+bkTRqNORWMsobLVZIjYln+aZUrT9yXl+/EVhUpmNrkxi/+B/YlTr1timwUxLAeLvcs /vuM7rE4IhJJD2zxlQQcdIXrArk/1D+wtPYfw= Received: by 10.143.45.14 with SMTP id x14mr1599351wfj.329.1244847174330; Fri, 12 Jun 2009 15:52:54 -0700 (PDT) Received: from ?192.168.2.102? (c-98-224-93-96.hsd1.ca.comcast.net [98.224.93.96]) by mx.google.com with ESMTPS id 29sm1873976wfg.28.2009.06.12.15.52.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Jun 2009 15:52:53 -0700 (PDT) Message-ID: <4A32DC3B.7000102@gmail.com> Date: Fri, 12 Jun 2009 15:52:43 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: atom-syntax Subject: Profile Media Type Extension 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: Well, the second half of my work week ended up getting preempted by a stupid primary development workstation that decided to go kaput on me so I have not yet had the opportunity to write up the Profile media type extension spec. While I'm waiting for the last few apps to download so I can reinstall them, I figured it would at least be helpful for me to write up my thoughts and I'll get the draft published next week. Basically, a "Profile" is going to be some kind of document that provides implementation guidelines for an Atom app. It will define a specific use of Atom along with whatever extensions, assumptions, options, etc necessary for that. For instance, one could easily imagine a "Blogging" profile for Atom that describes in detail how to use the Atom publishing protocol specifically for Weblogs, etc. Every Profile document will be associated with an identifier. The identifier is either a short name or an IRI following the same pattern as atom:link/@rel values. However, use of the short names will be restricted and must follow a strict convention... Specifically, only Profiles published through the IETF process will be allowed short names. For a Profile published as an Internet-Draft, the profile identifier is the document name. For instance, given a theoretical draft-snell-profile-blogging-01.txt, the identifier for the Profile is "draft-snell-profile-blogging-01". For a Profile published as an RFC, the project identifier is the RFC# in the pattern "RFC####". The shortnames are always case-insensitive so "rfc9999" is equivalent to "RFC9999" or "Rfc9999", etc. For all other Profiles, the identifier is an absolute IRI that SHOULD be dereference-able to retrieve the Profile document. In all Atom media types, the profile parameter is an optional quoted, whitespace delimited list of profile identifiers, e.g. application/atom+xml; profile="RFC9999 draft-snell-profile-blogging-01 http://example.org/profile/foo" Someone looking at this media type can determine that the Atom document in question conforms to three profiles identified by "RFC999", "draft-snell-profile-blogging-01", and "http://example.org/profile/foo". What "Conformance" means depends entirely on the profile. The profile parameter is intended only as a hint. An application can use it to help make decisions about a linked resource, etc but the presence of a particular profile identifier in the media type does not place any obligations on the application. As always, comments are requested and welcomed. - James From owner-atom-syntax@mail.imc.org Sat Jun 13 01:39:09 2009 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 CF1F63A699C for ; Sat, 13 Jun 2009 01:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.876 X-Spam-Level: X-Spam-Status: No, score=-5.876 tagged_above=-999 required=5 tests=[AWL=-3.277, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do8okAg26e0P for ; Sat, 13 Jun 2009 01:39:09 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B11903A6930 for ; Sat, 13 Jun 2009 01:39:08 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5D8Pr8S053837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Jun 2009 01:25:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5D8PrSx053836; Sat, 13 Jun 2009 01:25: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 mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n5D8PerR053825 for ; Sat, 13 Jun 2009 01:25:51 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 13 Jun 2009 08:25:39 -0000 Received: from p508FD30F.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.211.15] by mail.gmx.net (mp067) with SMTP; 13 Jun 2009 10:25:39 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+oY3RDfgKocyXlMlBepmu41I+dXyr29sUZrtsuL2 4QO+umeolY/Vpr Message-ID: <4A33627E.3090109@gmx.de> Date: Sat, 13 Jun 2009 10:25:34 +0200 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 M Snell CC: atom-syntax Subject: Re: Profile Media Type Extension References: <4A32DC3B.7000102@gmail.com> In-Reply-To: <4A32DC3B.7000102@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: James M Snell wrote: > ... > Every Profile document will be associated with an identifier. The > identifier is either a short name or an IRI following the same pattern > as atom:link/@rel values. However, use of the short names will be > ... I think in this is a case where you really want a URI. > restricted and must follow a strict convention... Specifically, only > Profiles published through the IETF process will be allowed short > names. For a Profile published as an Internet-Draft, the profile > identifier is the document name. For instance, given a theoretical > draft-snell-profile-blogging-01.txt, the identifier for the Profile is > "draft-snell-profile-blogging-01". For a Profile published as an RFC, > the project identifier is the RFC# in the pattern "RFC####". The > shortnames are always case-insensitive so "rfc9999" is equivalent to > "RFC9999" or "Rfc9999", etc. For all other Profiles, the identifier is > an absolute IRI that SHOULD be dereference-able to retrieve the Profile > document. "SHOULD be referenceable": doesn't compute, unless you define the format. (It is not needed for interoperability, so doesn't deserve RFC2119 keywords). You would also need to define what you mean by "IETF process". Do private submissions directly to the RFC Editor count? Suggestion: just always require URIs; Internet Drafts and RFCs have a canonical URN through RFC2648. For instance urn:ietf:rfc:4287 > ... BR, Julian From owner-atom-syntax@mail.imc.org Tue Jun 16 03:43:45 2009 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 0AE0A3A6B01 for ; Tue, 16 Jun 2009 03:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.715 X-Spam-Level: X-Spam-Status: No, score=-5.715 tagged_above=-999 required=5 tests=[AWL=-2.986, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MLH_Stock1=0.87] 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 zdf0TgMnYuwy for ; Tue, 16 Jun 2009 03:43:44 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id F05173A6AA7 for ; Tue, 16 Jun 2009 03:43:43 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GASYSa091224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 03:28:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5GASY9B091223; Tue, 16 Jun 2009 03:28: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 mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GASNG8091201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Jun 2009 03:28:33 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1596B23E3F1 for ; Tue, 16 Jun 2009 06:28:21 -0400 (EDT) Message-Id: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> From: Mark Nottingham To: Atom-Syntax Syntax Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Talking about Atom in Stockholm Date: Tue, 16 Jun 2009 20:28:15 +1000 X-Mailer: Apple Mail (2.935.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There seems to be a lot of new discussion around Atom recently. Who's up for a Bar BoF in Stockholm? -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Jun 16 08:12:31 2009 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 E2E613A6D8C for ; Tue, 16 Jun 2009 08:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87] 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 jTU6CuFQjYJy for ; Tue, 16 Jun 2009 08:12:31 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id CC9853A6D74 for ; Tue, 16 Jun 2009 08:12:30 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GEvfMi015434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 07:57:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5GEvfwH015433; Tue, 16 Jun 2009 07:57: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-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GEvTXu015423 for ; Tue, 16 Jun 2009 07:57:40 -0700 (MST) (envelope-from lindstream@gmail.com) Received: by fxm11 with SMTP id 11so2394516fxm.10 for ; Tue, 16 Jun 2009 07:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZpiCyq8dLwryfqtE1Z3QviiWKwia3Mpz070ia8VMB+E=; b=dTjDkmJ5Eqj/b1YmZELq3nW8yotJgluiFFsPdQezAVaPPAksP7ir0lZQYTHEQ/NjSU yB/9y+LCRMK1WjjLyvY5EI3Sk/x4sZUd1NulUKhcDsPti7BzAdql45ZcUS+1v2ik0HWB 0XmAvg1gdhyN6O8dxmcvYP4CyxxBZjpE9qbAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BlALVr4EU/xnaLR0nZOVDonjTjsI6bovxuZZvwqFwXtzfPhRP6Nzveo3BwU/e65rE5 MgZJn2e4xZCokHkwhF9WsE3XufDcaSiHFzOFeAj7s+eULdIbrNthrjdOURIUykGWYUaC Luof/wqVtMngfARCDFOnGe9LWGjaluHI34j1w= MIME-Version: 1.0 Received: by 10.204.97.140 with SMTP id l12mr8270660bkn.133.1245164248761; Tue, 16 Jun 2009 07:57:28 -0700 (PDT) In-Reply-To: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> References: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> Date: Tue, 16 Jun 2009 16:57:28 +0200 Message-ID: Subject: Re: Talking about Atom in Stockholm From: =?ISO-8859-1?Q?Niklas_Lindstr=F6m?= To: Mark Nottingham Cc: Atom-Syntax Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, sounds like a good idea! I live there, and I'd love to drop in. When did you have in mind? Around the IETF meeting between the 26-31th July? Best regards, Niklas Lindstr=F6m On Tue, Jun 16, 2009 at 12:28 PM, Mark Nottingham wrote: > > There seems to be a lot of new discussion around Atom recently. Who's up = for > a Bar BoF in Stockholm? > > -- > Mark Nottingham =A0 =A0 http://www.mnot.net/ > > From owner-atom-syntax@mail.imc.org Tue Jun 16 08:20:54 2009 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 12CFD3A69C4 for ; Tue, 16 Jun 2009 08:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.959 X-Spam-Level: X-Spam-Status: No, score=-0.959 tagged_above=-999 required=5 tests=[AWL=-1.334, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_MLH_Stock1=0.87] 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 vh8YvoKoHtYw for ; Tue, 16 Jun 2009 08:20:53 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D6A743A695F for ; Tue, 16 Jun 2009 08:20:52 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GF5vEl016121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 08:05:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5GF5vQK016120; Tue, 16 Jun 2009 08:05: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 mailhost.dizzyd.com ([207.210.219.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GF5j0x016095 for ; Tue, 16 Jun 2009 08:05:56 -0700 (MST) (envelope-from stpeter@stpeter.im) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by mailhost.dizzyd.com (Postfix) with ESMTPSA id 48D0B40C9C; Tue, 16 Jun 2009 09:05:45 -0600 (MDT) Message-ID: <4A37B01B.2040805@stpeter.im> Date: Tue, 16 Jun 2009 08:45:47 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Mark Nottingham CC: Atom-Syntax Syntax Subject: Re: Talking about Atom in Stockholm References: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> In-Reply-To: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/16/09 4:28 AM, Mark Nottingham wrote: > Who's up for a Bar BoF in Stockholm? +1. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko3sBsACgkQNL8k5A2w/vwkhQCgiGP13Sr8j/E7DGk6FPKcah4C bLwAoO4qllmao1XIygOXZDsvp8u8WkT+ =+VUh -----END PGP SIGNATURE----- From owner-atom-syntax@mail.imc.org Tue Jun 16 08:24:09 2009 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 37A7A3A6C07 for ; Tue, 16 Jun 2009 08:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] 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 qpvj4CFExKBP for ; Tue, 16 Jun 2009 08:24:08 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 294E23A691F for ; Tue, 16 Jun 2009 08:24:07 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GFD5Mw016791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 08:13:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5GFD5vJ016790; Tue, 16 Jun 2009 08:13:05 -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-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GFD3OQ016778 for ; Tue, 16 Jun 2009 08:13:04 -0700 (MST) (envelope-from peter.krantz@gmail.com) Received: by fxm11 with SMTP id 11so2408512fxm.10 for ; Tue, 16 Jun 2009 08:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VyYGkkOBVDnhD+3eBmPu8okQSPwCIlKtB7fb8M8XhQY=; b=J9pMMRwYJtAFIVDlMM55BpLILVf+WBxjeLr2wRToQgE3debpWYWGuGtlKkuWIIwgfa 9PRhlQjirO7ZALUxkEOZFFfUnhYuu3jRD776ooK7F4BcCuBzq4xqURvVDG//yHWqqGYc 9dl52o9Zc0JYjmcZp1ueF5/b68RNN2/yDZwRM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ApHQJnt5SVwDxZHAEV7FaHOYn0qHGblrxQiExvfFpi+WnDGoRZ60I+bcY74GQe3ygX LCvsaxgOMovgGWc/wL150SCRs+r+BkL/tlNNVvpHwfchR1obyzd8a7J268FqqgWBI3nU 0KIbOj3kNMTUFKwfUb4PzCYAk4UeC6KBz9Ov8= MIME-Version: 1.0 Received: by 10.103.243.9 with SMTP id v9mr4531995mur.69.1245165183065; Tue, 16 Jun 2009 08:13:03 -0700 (PDT) In-Reply-To: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> References: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> Date: Tue, 16 Jun 2009 17:13:02 +0200 Message-ID: <7b9ad66d0906160813i2df45687t3e69419a83954182@mail.gmail.com> Subject: Re: Talking about Atom in Stockholm From: Peter Krantz To: Mark Nottingham Cc: Atom-Syntax Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jun 16, 2009 at 12:28, Mark Nottingham wrote: > > There seems to be a lot of new discussion around Atom recently. Who's up for > a Bar BoF in Stockholm? > I am! I live in Stockholm as well. When did you have in mind? Regards, Peter From owner-atom-syntax@mail.imc.org Tue Jun 16 14:59:12 2009 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 D98303A6A6F for ; Tue, 16 Jun 2009 14:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MLH_Stock1=0.87] 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 kBeRtpNjCB8O for ; Tue, 16 Jun 2009 14:59:12 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B38A53A6C5E for ; Tue, 16 Jun 2009 14:59:11 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GLjhnV046875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 14:45:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5GLjhcs046874; Tue, 16 Jun 2009 14:45:43 -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 ey-out-1920.google.com (ey-out-1920.google.com [74.125.78.144]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GLjUWt046864 for ; Tue, 16 Jun 2009 14:45:42 -0700 (MST) (envelope-from foolistbar@googlemail.com) Received: by ey-out-1920.google.com with SMTP id 3so21847eyh.28 for ; Tue, 16 Jun 2009 14:45:26 -0700 (PDT) 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=UzFnY+rH8zi6mxnhxTOw+JWv/aljfK9LYr0sjH+TeCY=; b=lou7iaCS2iGKTYR2Q8gUlJ21cnu5ZSnobJE/Maq/RasuAdGEr4knDmfukubGBOBWnF S6z+GmLTJIYQMErkPpJFQhDKc6mjsyJ2bkgbL7ORngJyhp3CZY9amrpqgaefsGXqXqJy KxVOcpG0ON75zuYAY0iP9Hc68ghm3SOiy25OA= 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=qyeq4jun8ff2E+hgwGXODwheHf9rshhbb/OupIvNzhrzUkzcqyDkTUjQ47tg/ieTUs 9MkbXwmLb5CshJyfcXRvJzp9ymUB60ZIfiESGuqbY7M/2Uej9Yd3O8eZqzx9OG8lebbT Cl5bwJojOOxquZu52dpvUyBz+eo1E0ivX4xcI= Received: by 10.216.47.201 with SMTP id t51mr3055369web.198.1245188726281; Tue, 16 Jun 2009 14:45:26 -0700 (PDT) Received: from ?192.168.0.199? (host86-174-38-173.range86-174.btcentralplus.com [86.174.38.173]) by mx.google.com with ESMTPS id t12sm15046983gvd.21.2009.06.16.14.45.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 14:45:25 -0700 (PDT) Cc: Atom-Syntax Syntax Message-Id: From: Geoffrey Sneddon To: Mark Nottingham In-Reply-To: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Talking about Atom in Stockholm Date: Tue, 16 Jun 2009 22:45:23 +0100 References: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> X-Mailer: Apple Mail (2.935.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 16 Jun 2009, at 11:28, Mark Nottingham wrote: > Who's up for a Bar BoF in Stockholm? Depending on time and bar (as I am < 18), I might be able to come. -- Geoffrey Sneddon From owner-atom-syntax@mail.imc.org Tue Jun 16 20:24:22 2009 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 AC99528C182 for ; Tue, 16 Jun 2009 20:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.681 X-Spam-Level: X-Spam-Status: No, score=-5.681 tagged_above=-999 required=5 tests=[AWL=-2.952, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MLH_Stock1=0.87] 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 lX3c+pU3UL1e for ; Tue, 16 Jun 2009 20:24:21 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A32193A6BC4 for ; Tue, 16 Jun 2009 20:24:16 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5H3C3aY066284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 20:12:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5H3C3se066283; Tue, 16 Jun 2009 20:12: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 mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5H3Bqxm066264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Jun 2009 20:12:03 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CE86623E3F1; Tue, 16 Jun 2009 23:11:50 -0400 (EDT) Cc: Atom-Syntax Syntax Message-Id: <852A72DA-A862-41AD-A3F6-AE58224197B0@mnot.net> From: Mark Nottingham To: Geoffrey Sneddon In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Talking about Atom in Stockholm Date: Wed, 17 Jun 2009 13:11:48 +1000 References: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> X-Mailer: Apple Mail (2.935.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Bar BoF" is often a loose term; we can meet pretty much anywhere. How about a boat ride out into the archipelago? :) I'm there from Tuesday PM until the weekend; once the schedule comes out, we can get an idea of what times people might be most free. Cheers, On 17/06/2009, at 7:45 AM, Geoffrey Sneddon wrote: > > On 16 Jun 2009, at 11:28, Mark Nottingham wrote: > >> Who's up for a Bar BoF in Stockholm? > > Depending on time and bar (as I am < 18), I might be able to come. > > > -- > Geoffrey Sneddon > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jun 17 00:24:05 2009 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 91AA03A6A6D for ; Wed, 17 Jun 2009 00:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, SARE_MLH_Stock1=0.87, UNPARSEABLE_RELAY=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 4a4MmzTHRHY2 for ; Wed, 17 Jun 2009 00:24:05 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 26D3A3A67EF for ; Wed, 17 Jun 2009 00:23:36 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5H7A4W0080577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jun 2009 00:10:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5H7A41B080576; Wed, 17 Jun 2009 00:10: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 mgw4.noc.ntt.com (mgw4.noc.ntt.com [210.160.15.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5H79nlf080550 for ; Wed, 17 Jun 2009 00:10:00 -0700 (MST) (envelope-from h.asakura@ntt.com) Received: from mop1.noc.ntt.com by mgw4.noc.ntt.com (NTT-Com MailSV) with ESMTP id n5H79mHJ018865 for ; Wed, 17 Jun 2009 16:09:48 +0900 (JST) Received: from mip02.noc.ntt.com (mvi1.noc.ntt.com) by mop1.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0KLD004MQFWB0L@ntt.com> for atom-syntax@imc.org; Wed, 17 Jun 2009 16:09:48 +0900 (JST) Date: Wed, 17 Jun 2009 16:09:12 +0900 From: "ASAKURA Hiroshi" Subject: Re: Talking about Atom in Stockholm In-reply-to: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> Cc: h.asakura@ntt.com, atom-syntax@imc.org Message-id: <20090617143629.066D.FF7A234@ntt.com> MIME-version: 1.0 X-Mailer: Becky! ver. 2.50 [ja] (Unregistered) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, Mark. Sorry, I've not read recent threads, however, I also feel that we have new problems to deploy Atom and AtomPub more widely. I think BoF is a good idea. However, it might be difficult to go only for Atom's BoF. If it covers AtomPub or if other BoF such as hybi would be opened, we, NTT Communications, could go. --- Hiroshi ASAKURA NTT Communications Corp. From dianeao050@qeplp.com Wed Jun 17 04:01:59 2009 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 AA8933A6E2E; Wed, 17 Jun 2009 04:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.152 X-Spam-Level: X-Spam-Status: No, score=-32.152 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, GB_OPRAH=2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, 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 b+CFvxDsCzeN; Wed, 17 Jun 2009 04:01:58 -0700 (PDT) Received: from mail.useindia.com (unknown [122.170.3.16]) by core3.amsl.com (Postfix) with ESMTP id 3BC9B3A6E2C; Wed, 17 Jun 2009 04:01:58 -0700 (PDT) Message-ID: <000d01c9ef3b$03b089e0$6400a8c0@dianeao050> From: atompub-archive@megatron.ietf.org To: Subject: Acai Berry is amazingly smooth and suprisingly tasty, Get your free trial. Date: Wed, 17 Jun 2009 16:31:50 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9EF3B.03B089E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9EF3B.03B089E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your ticket to a new Slim and Vibrant life , Acai berry.=20 It works for Oprah and is endorsed by Rachel Ray. Move to our site =A0 =A0 Thank You!=20 best regards Ronny=20 Elliot ------=_NextPart_000_0007_01C9EF3B.03B089E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your ticket to a new Slim and Vibrant life , Acai berry. It works for Oprah and is endorsed by Rachel Ray. Move to our site =A0 =A0 Thank You! best regards Ronny=20 Elliot ------=_NextPart_000_0007_01C9EF3B.03B089E0-- From multiplicationsuuq40@mnb.com.au Wed Jun 17 16:34:05 2009 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 6D4233A6407; Wed, 17 Jun 2009 16:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -49.875 X-Spam-Level: X-Spam-Status: No, score=-49.875 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=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_WEB=0.619, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_SBL=20, URI_NOVOWEL=0.5, 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 1MnvDZTnCKli; Wed, 17 Jun 2009 16:34:04 -0700 (PDT) Received: from 201-41-121-191.cpece700.dsl.brasiltelecom.net.br (200-140-55-188.cpece700.dsl.brasiltelecom.net.br [200.140.55.188]) by core3.amsl.com (Postfix) with ESMTP id 382503A689D; Wed, 17 Jun 2009 16:33:54 -0700 (PDT) Message-ID: <000d01c9efa3$fe95d5f0$6400a8c0@multiplicationsuuq40> From: atompub-archive@megatron.ietf.org To: Subject: The Acai Berry diet gives you the upper hand. Date: Wed, 17 Jun 2009 20:33:18 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9EFA3.FE95D5F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9EFA3.FE95D5F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Count on Acai Berry fruit to maintain a healthy body. Enter everyone =A0 Acai Berry , Lose wieght feel great.=20 =A0 Visit our site =A0 =A0 best ragards Webb ------=_NextPart_000_0007_01C9EFA3.FE95D5F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Count on Acai Berry fruit to maintain a h= ealthy body. Enter everyone =A0 Acai Berry , Lose wieght feel great. =A0 Visit our s= ite =A0 =A0 best ragards Webb ------=_NextPart_000_0007_01C9EFA3.FE95D5F0-- From owner-atom-syntax@mail.imc.org Thu Jun 18 07:47:50 2009 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 40E5428C316 for ; Thu, 18 Jun 2009 07:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] 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 lKFwd0jcOLcY for ; Thu, 18 Jun 2009 07:47:49 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0F3E428C0E1 for ; Thu, 18 Jun 2009 07:47:48 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5IEdrqL008289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jun 2009 07:39:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5IEdrLe008288; Thu, 18 Jun 2009 07:39: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 acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5IEdgoO008248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 18 Jun 2009 07:39:52 -0700 (MST) (envelope-from colm.divilly@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5IEedxV002040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Jun 2009 14:40:40 GMT Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5IEevvT011046; Thu, 18 Jun 2009 14:40:58 GMT Received: from [10.169.115.231] (/10.169.115.231) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Jun 2009 07:39:36 -0700 Message-ID: <4A3A51AC.2010703@oracle.com> Date: Thu, 18 Jun 2009 15:39:40 +0100 From: Colm Divilly Organization: Oracle Corporation User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mark Nottingham CC: Atom-Syntax Syntax Subject: Re: Talking about Atom in Stockholm References: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> In-Reply-To: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: abhmt001.oracle.com [141.146.116.10] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010205.4A3A51A9.0230:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'd be interested in attending, especially if we're going to cover AtomPub as well. Regards, Colm Divilly Mark Nottingham wrote: > > There seems to be a lot of new discussion around Atom recently. Who's > up for a Bar BoF in Stockholm? > > -- > Mark Nottingham http://www.mnot.net/ > From decretum1996@KTZ.de Fri Jun 19 00:32:18 2009 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 77D673A6960 for ; Fri, 19 Jun 2009 00:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.497 X-Spam-Level: X-Spam-Status: No, score=-14.497 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HOST_EQ_BROADBND=1.118, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.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, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 g4ZA1bXdp7Um for ; Fri, 19 Jun 2009 00:32:12 -0700 (PDT) Received: from n19z137l45.broadband.ctm.net (n19z137l45.broadband.ctm.net [202.86.137.45]) by core3.amsl.com (Postfix) with ESMTP id 06F623A6856 for ; Fri, 19 Jun 2009 00:32:11 -0700 (PDT) From: To: atompub-archive@lists.ietf.org Subject: For: atompub-archive@lists.ietf.org Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Message-Id: <20090619073212.06F623A6856@core3.amsl.com> Date: Fri, 19 Jun 2009 00:32:11 -0700 (PDT) uxe Having problems= viewing=20 this email? Click=20 here. =A0 Know=20 someone else? Forward This=20 Email! We hope you enjoy receiving emai= ls=20 from Kuxqnyza. If you do not wish to receive them, please= click=20 here. Copyright ¿2000-2009 Ilql, I= nc.=20 73095, Inc. 7712 zqkjn jrtvhb, WK 9057795 P= rivacy=20 Policy=A0=A0|=A0=A0T= erms of=20 Use=A0=A0|=A0=A0Customer=20 Service=A0=A0|=A0=A0S= ite=20 Map =A0 Sign up for newsletters and offers from apjriv. If you can't read this message from dixi , then Click Here. You are receiving this e-mail because you subscribed to pyopos Featured Offers. libu respects your privacy. Please read our online Privacy Statement. If you would prefer to no longer receive this Featured Offer Newsletter, please click the “Unsubscribe” link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in utox Featured Offers. This shall not constitute an offer by wjd. cyr shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice. To set your contact preferences for other jtqyd communications, see the communications preferences section of the regui Privacy Statement. ©2009 qzody | Unsubscribe | More Newsletters | Privacy agq Corporation, toly Way, zudiwy From untrustworthyf092@lltbldg.com Fri Jun 19 14:55:49 2009 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 BDE573A6BFF; Fri, 19 Jun 2009 14:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.733 X-Spam-Level: X-Spam-Status: No, score=-23.733 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, GB_OPRAH=2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_MISMATCH_NET=0.611, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, 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 fU7g3mVB+bXS; Fri, 19 Jun 2009 14:55:49 -0700 (PDT) Received: from dbec62748.dslam-172-17-1-245-448-0386-cnt-04.dsl.cantv.net (unknown [190.198.39.72]) by core3.amsl.com (Postfix) with ESMTP id 9B85A3A6B2F; Fri, 19 Jun 2009 14:55:48 -0700 (PDT) Date: Fri, 19 Jun 2009 23:55:57 +0100 Message-Id: From: atompub-archive@megatron.ietf.org To: atompub-archive@megatron.ietf.org Subject: You'll be shocked at how easy it is. Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Oprah Is an Acai Berry Success story. Speed to visit Hollywoods hottest secret , Acai Berry Diet. Wanna click? best ragards Kane From titlepyd94@amazingnz.com Sat Jun 20 08:19:00 2009 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 4974C3A6B53 for ; Sat, 20 Jun 2009 08:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.807 X-Spam-Level: X-Spam-Status: No, score=-23.807 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_START_LOSE=1.493, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.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, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, 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 Fidx1TqpGVD5 for ; Sat, 20 Jun 2009 08:18:58 -0700 (PDT) Received: from CPE-24-208-29-120.new.res.rr.com (CPE-24-208-29-120.new.res.rr.com [24.208.29.120]) by core3.amsl.com (Postfix) with ESMTP id C6D0C3A6B07 for ; Sat, 20 Jun 2009 08:18:57 -0700 (PDT) Date: Sat, 20 Jun 2009 10:19:09 -0600 Message-Id: From: atompub-archive@lists.ietf.org To: atompub-archive@lists.ietf.org Subject: Lose wieght without dieting , Acai Berry. Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Fast And effective weight loss solutuion, Acai diet available now ! Get Noticed with Acai Berry. welcome Thank You! best regards Mahlon Vann From kercorneli@aiservices.com Sat Jun 20 22:20:42 2009 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 50FF13A6859 for ; Sat, 20 Jun 2009 22:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.836 X-Spam-Level: X-Spam-Status: No, score=-86.836 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_WEOFFER=0.3, 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 JpJFYNZcjuAT for ; Sat, 20 Jun 2009 22:20:40 -0700 (PDT) Received: from bl8-167-91.dsl.telepac.pt (bl8-171-17.dsl.telepac.pt [85.241.171.17]) by core3.amsl.com (Postfix) with SMTP id 30C4A3A680A for ; Sat, 20 Jun 2009 22:20:38 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: Re: Mystery/Shopper [$850/week] From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090621052039.30C4A3A680A@core3.amsl.com> Date: Sat, 20 Jun 2009 22:20:38 -0700 (PDT) Thank you for your interest in the Mystery Shopper position. Our company conducts surveys and evaluates other companies in order to help them achieve their performance goals. We offer an integrated suite of business solutions that enables corporations to achieve tangible results in the marketplace. We get hired by other companies and act like customers to find out how they are handling their services in relation to their customers. Mystery Shopping is the most accurate and reliable tool a business can use to gather information regarding their actual customer service performance at the moment of truth. This moment of truth is not when the staff is on their best behavior because the boss is around - it is when they interact with customers during their normal daily routines. This is where you, the Mystery Shopper, come in. You pose as an ordinary customer and provide feedback of both factual observations (ex...the floor was free of debris) and your own opinions (ex...I felt that the temperature in the establishment was too cold). Mystery Shoppers must remain anonymous. You must act as a regular customer and be careful not to do anything that would reveal you as a shopper. An inexperienced shopper could tip off the staff to his/her identity by asking for the manager's name for no clear or appropriate reason. If you are going to be bringing someone with you on the shop, make sure you educate them about the process as well. Beware that even whispers can be overheard by employees. If anyone notices you are a shopper, you can bet that word will quickly spread around the establishment and you will get some of the best customer service in town. No company can afford to have a gap between the promise of quality and its actual delivery, that's why leading corporations look to us, the nation's premiere mystery shopping and customer experience measurement company. In order for a business to effectively compete in today's economy, they must be prepared to meet the challenge of increasing sales by: * Retaining existing customers * Acquiring new customers * Creating word-of-mouth advocacy * Improving customer loyalty Once we have a contract to do so, you would be directed to the company or outlet, and you would be given the funds you need to do the job(either purchase merchandise or require services), after which you would write a detailed report of your experience. Examples of details you would forward to us are: 1) How long does it take to get served. 2) Politeness of the attendant. 3) Customer service professionalism. 4) Sometimes you might be required to upset the attendant, to see how they deal with difficult clients. Then we turn the information over to the company executives and they will carry out their own duties in improving their services. Most companies employ our assistance when people complain about their services, or when they feel there is a need for them to improve upon their customer service. Our company partners with you to implement proven mystery shop auditing and surveying strategies that provide critical information about customer experiences. You will be paid a commission of $100 for every duty you carry out, and bonus on your transportation allowance. Your task will be to evaluate and comment on customer service in a wide variety of restaurants, retail stores, casinos, shopping malls, banks and hotels in your area. Qualities of a good Mystery Shopper: * Is 21 years of age or older * Loves to go shopping * Is fair and objective * Is ON TIME * Is very observant and able to focus on details * Is fairly intelligent * Has patience * Is detail oriented * Is practical * Types well * Is trustworthy * Explains well in writing * Is discreet * Loves to learn * Handles deadlines * Has full internet access (at home or at work) Mystery Shopping is fun and exciting but also must be approached very seriously and is definitely not for everyone. If you are interested in applying for consideration as a Mystery Shopper do send in your information: Robin@super-videozz.com Full Name: Address: City: State: Zip Code: Phone Number: Age: Occupation: As soon as we receive your information we will add you to our database and we will look for locations in your area that needs to be evaluated. Thank you, Michael McDowell WA Surveys 410 Roosevelt Way NE Seattle, WA 98105 From jharezlak@amcore.com Sun Jun 21 14:52:42 2009 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 787CF3A6C5D for ; Sun, 21 Jun 2009 14:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.053 X-Spam-Level: X-Spam-Status: No, score=-76.053 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_WEOFFER=0.3, TVD_RCVD_IP=1.931, 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 LUUE4LsHr5jn for ; Sun, 21 Jun 2009 14:52:41 -0700 (PDT) Received: from 117.242.91-79.rev.gaoland.net (117.242.91-79.rev.gaoland.net [79.91.242.117]) by core3.amsl.com (Postfix) with SMTP id 2066A3A6A4D for ; Sun, 21 Jun 2009 14:52:38 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: Re: Mystery Shopper [$800/week] From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090621215239.2066A3A6A4D@core3.amsl.com> Date: Sun, 21 Jun 2009 14:52:38 -0700 (PDT) Thank you for your interest in the Mystery Shopper position. Our company conducts surveys and evaluates other companies in order to help them achieve their performance goals. We offer an integrated suite of business solutions that enables corporations to achieve tangible results in the marketplace. We get hired by other companies and act like customers to find out how they are handling their services in relation to their customers. Mystery Shopping is the most accurate and reliable tool a business can use to gather information regarding their actual customer service performance at the moment of truth. This moment of truth is not when the staff is on their best behavior because the boss is around - it is when they interact with customers during their normal daily routines. This is where you, the Mystery Shopper, come in. You pose as an ordinary customer and provide feedback of both factual observations (ex...the floor was free of debris) and your own opinions (ex...I felt that the temperature in the establishment was too cold). Mystery Shoppers must remain anonymous. You must act as a regular customer and be careful not to do anything that would reveal you as a shopper. An inexperienced shopper could tip off the staff to his/her identity by asking for the manager's name for no clear or appropriate reason. If you are going to be bringing someone with you on the shop, make sure you educate them about the process as well. Beware that even whispers can be overheard by employees. If anyone notices you are a shopper, you can bet that word will quickly spread around the establishment and you will get some of the best customer service in town. No company can afford to have a gap between the promise of quality and its actual delivery, that's why leading corporations look to us, the nation's premiere mystery shopping and customer experience measurement company. In order for a business to effectively compete in today's economy, they must be prepared to meet the challenge of increasing sales by: * Retaining existing customers * Acquiring new customers * Creating word-of-mouth advocacy * Improving customer loyalty Once we have a contract to do so, you would be directed to the company or outlet, and you would be given the funds you need to do the job(either purchase merchandise or require services), after which you would write a detailed report of your experience. Examples of details you would forward to us are: 1) How long does it take to get served. 2) Politeness of the attendant. 3) Customer service professionalism. 4) Sometimes you might be required to upset the attendant, to see how they deal with difficult clients. Then we turn the information over to the company executives and they will carry out their own duties in improving their services. Most companies employ our assistance when people complain about their services, or when they feel there is a need for them to improve upon their customer service. Our company partners with you to implement proven mystery shop auditing and surveying strategies that provide critical information about customer experiences. You will be paid a commission of $100 for every duty you carry out, and bonus on your transportation allowance. Your task will be to evaluate and comment on customer service in a wide variety of restaurants, retail stores, casinos, shopping malls, banks and hotels in your area. Qualities of a good Mystery Shopper: * Is 21 years of age or older * Loves to go shopping * Is fair and objective * Is ON TIME * Is very observant and able to focus on details * Is fairly intelligent * Has patience * Is detail oriented * Is practical * Types well * Is trustworthy * Explains well in writing * Is discreet * Loves to learn * Handles deadlines * Has full internet access (at home or at work) Mystery Shopping is fun and exciting but also must be approached very seriously and is definitely not for everyone. If you are interested in applying for consideration as a Mystery Shopper do send in your information: Pat@super-videozz.com Full Name: Address: City: State: Zip Code: Phone Number: Age: Occupation: As soon as we receive your information we will add you to our database and we will look for locations in your area that needs to be evaluated. Thank you, Michael McDowell WA Surveys 410 Roosevelt Way NE Seattle, WA 98105 From oxospar@allencanning.com Sun Jun 21 19:37:00 2009 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 2D9D93A6B51 for ; Sun, 21 Jun 2009 19:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -84.325 X-Spam-Level: X-Spam-Status: No, score=-84.325 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_WEOFFER=0.3, 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 xFQ6jDgINnYp for ; Sun, 21 Jun 2009 19:36:59 -0700 (PDT) Received: from alcoholconcern.org.uk (unknown [75.137.144.162]) by core3.amsl.com (Postfix) with SMTP id 55B8B3A67DA for ; Sun, 21 Jun 2009 19:36:57 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: Re: Mystery~Secret Shopper [$650/week] From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090622023658.55B8B3A67DA@core3.amsl.com> Date: Sun, 21 Jun 2009 19:36:57 -0700 (PDT) Thank you for your interest in the Mystery Shopper position. Our company conducts surveys and evaluates other companies in order to help them achieve their performance goals. We offer an integrated suite of business solutions that enables corporations to achieve tangible results in the marketplace. We get hired by other companies and act like customers to find out how they are handling their services in relation to their customers. Mystery Shopping is the most accurate and reliable tool a business can use to gather information regarding their actual customer service performance at the moment of truth. This moment of truth is not when the staff is on their best behavior because the boss is around - it is when they interact with customers during their normal daily routines. This is where you, the Mystery Shopper, come in. You pose as an ordinary customer and provide feedback of both factual observations (ex...the floor was free of debris) and your own opinions (ex...I felt that the temperature in the establishment was too cold). Mystery Shoppers must remain anonymous. You must act as a regular customer and be careful not to do anything that would reveal you as a shopper. An inexperienced shopper could tip off the staff to his/her identity by asking for the manager's name for no clear or appropriate reason. If you are going to be bringing someone with you on the shop, make sure you educate them about the process as well. Beware that even whispers can be overheard by employees. If anyone notices you are a shopper, you can bet that word will quickly spread around the establishment and you will get some of the best customer service in town. No company can afford to have a gap between the promise of quality and its actual delivery, that's why leading corporations look to us, the nation's premiere mystery shopping and customer experience measurement company. In order for a business to effectively compete in today's economy, they must be prepared to meet the challenge of increasing sales by: * Retaining existing customers * Acquiring new customers * Creating word-of-mouth advocacy * Improving customer loyalty Once we have a contract to do so, you would be directed to the company or outlet, and you would be given the funds you need to do the job(either purchase merchandise or require services), after which you would write a detailed report of your experience. Examples of details you would forward to us are: 1) How long does it take to get served. 2) Politeness of the attendant. 3) Customer service professionalism. 4) Sometimes you might be required to upset the attendant, to see how they deal with difficult clients. Then we turn the information over to the company executives and they will carry out their own duties in improving their services. Most companies employ our assistance when people complain about their services, or when they feel there is a need for them to improve upon their customer service. Our company partners with you to implement proven mystery shop auditing and surveying strategies that provide critical information about customer experiences. You will be paid a commission of $100 for every duty you carry out, and bonus on your transportation allowance. Your task will be to evaluate and comment on customer service in a wide variety of restaurants, retail stores, casinos, shopping malls, banks and hotels in your area. Qualities of a good Mystery Shopper: * Is 21 years of age or older * Loves to go shopping * Is fair and objective * Is ON TIME * Is very observant and able to focus on details * Is fairly intelligent * Has patience * Is detail oriented * Is practical * Types well * Is trustworthy * Explains well in writing * Is discreet * Loves to learn * Handles deadlines * Has full internet access (at home or at work) Mystery Shopping is fun and exciting but also must be approached very seriously and is definitely not for everyone. If you are interested in applying for consideration as a Mystery Shopper do send in your information: Basil@ms-shopper.com Full Name: Address: City: State: Zip Code: Phone Number: Age: Occupation: As soon as we receive your information we will add you to our database and we will look for locations in your area that needs to be evaluated. Thank you, Michael McDowell WA Surveys 410 Roosevelt Way NE Seattle, WA 98105 From mjh@ae.wakwak.com Sun Jun 21 23:43:17 2009 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 C8AA53A6835 for ; Sun, 21 Jun 2009 23:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.386 X-Spam-Level: X-Spam-Status: No, score=-88.386 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_WEOFFER=0.3, 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 gIND4t53myRc for ; Sun, 21 Jun 2009 23:43:16 -0700 (PDT) Received: from aetna.com (unknown [61.247.237.170]) by core3.amsl.com (Postfix) with SMTP id 39BD53A67C1 for ; Sun, 21 Jun 2009 23:43:14 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: Re: Mystery Secret Shopper [$700/week] From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090622064315.39BD53A67C1@core3.amsl.com> Date: Sun, 21 Jun 2009 23:43:14 -0700 (PDT) Thank you for your interest in the Mystery Shopper position. Our company conducts surveys and evaluates other companies in order to help them achieve their performance goals. We offer an integrated suite of business solutions that enables corporations to achieve tangible results in the marketplace. We get hired by other companies and act like customers to find out how they are handling their services in relation to their customers. Mystery Shopping is the most accurate and reliable tool a business can use to gather information regarding their actual customer service performance at the moment of truth. This moment of truth is not when the staff is on their best behavior because the boss is around - it is when they interact with customers during their normal daily routines. This is where you, the Mystery Shopper, come in. You pose as an ordinary customer and provide feedback of both factual observations (ex...the floor was free of debris) and your own opinions (ex...I felt that the temperature in the establishment was too cold). Mystery Shoppers must remain anonymous. You must act as a regular customer and be careful not to do anything that would reveal you as a shopper. An inexperienced shopper could tip off the staff to his/her identity by asking for the manager's name for no clear or appropriate reason. If you are going to be bringing someone with you on the shop, make sure you educate them about the process as well. Beware that even whispers can be overheard by employees. If anyone notices you are a shopper, you can bet that word will quickly spread around the establishment and you will get some of the best customer service in town. No company can afford to have a gap between the promise of quality and its actual delivery, that's why leading corporations look to us, the nation's premiere mystery shopping and customer experience measurement company. In order for a business to effectively compete in today's economy, they must be prepared to meet the challenge of increasing sales by: * Retaining existing customers * Acquiring new customers * Creating word-of-mouth advocacy * Improving customer loyalty Once we have a contract to do so, you would be directed to the company or outlet, and you would be given the funds you need to do the job(either purchase merchandise or require services), after which you would write a detailed report of your experience. Examples of details you would forward to us are: 1) How long does it take to get served. 2) Politeness of the attendant. 3) Customer service professionalism. 4) Sometimes you might be required to upset the attendant, to see how they deal with difficult clients. Then we turn the information over to the company executives and they will carry out their own duties in improving their services. Most companies employ our assistance when people complain about their services, or when they feel there is a need for them to improve upon their customer service. Our company partners with you to implement proven mystery shop auditing and surveying strategies that provide critical information about customer experiences. You will be paid a commission of $100 for every duty you carry out, and bonus on your transportation allowance. Your task will be to evaluate and comment on customer service in a wide variety of restaurants, retail stores, casinos, shopping malls, banks and hotels in your area. Qualities of a good Mystery Shopper: * Is 21 years of age or older * Loves to go shopping * Is fair and objective * Is ON TIME * Is very observant and able to focus on details * Is fairly intelligent * Has patience * Is detail oriented * Is practical * Types well * Is trustworthy * Explains well in writing * Is discreet * Loves to learn * Handles deadlines * Has full internet access (at home or at work) Mystery Shopping is fun and exciting but also must be approached very seriously and is definitely not for everyone. If you are interested in applying for consideration as a Mystery Shopper do send in your information: Gary@super-videozz.com Full Name: Address: City: State: Zip Code: Phone Number: Age: Occupation: As soon as we receive your information we will add you to our database and we will look for locations in your area that needs to be evaluated. Thank you, Michael McDowell WA Surveys 410 Roosevelt Way NE Seattle, WA 98105 From mlesiak@almaden.ibm.com Mon Jun 22 07:47:02 2009 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 744B03A6DE6 for ; Mon, 22 Jun 2009 07:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.005 X-Spam-Level: X-Spam-Status: No, score=-89.005 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_WEOFFER=0.3, 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 xousU8JrGGyT for ; Mon, 22 Jun 2009 07:47:01 -0700 (PDT) Received: from 121ware.com (unknown [81.214.190.177]) by core3.amsl.com (Postfix) with SMTP id 459703A6AE7 for ; Mon, 22 Jun 2009 07:46:58 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: Re: Mystery Shopper [$800/week] From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090622144659.459703A6AE7@core3.amsl.com> Date: Mon, 22 Jun 2009 07:46:58 -0700 (PDT) Thank you for your interest in the Mystery Shopper position. Our company conducts surveys and evaluates other companies in order to help them achieve their performance goals. We offer an integrated suite of business solutions that enables corporations to achieve tangible results in the marketplace. We get hired by other companies and act like customers to find out how they are handling their services in relation to their customers. Mystery Shopping is the most accurate and reliable tool a business can use to gather information regarding their actual customer service performance at the moment of truth. This moment of truth is not when the staff is on their best behavior because the boss is around - it is when they interact with customers during their normal daily routines. This is where you, the Mystery Shopper, come in. You pose as an ordinary customer and provide feedback of both factual observations (ex...the floor was free of debris) and your own opinions (ex...I felt that the temperature in the establishment was too cold). Mystery Shoppers must remain anonymous. You must act as a regular customer and be careful not to do anything that would reveal you as a shopper. An inexperienced shopper could tip off the staff to his/her identity by asking for the manager's name for no clear or appropriate reason. If you are going to be bringing someone with you on the shop, make sure you educate them about the process as well. Beware that even whispers can be overheard by employees. If anyone notices you are a shopper, you can bet that word will quickly spread around the establishment and you will get some of the best customer service in town. No company can afford to have a gap between the promise of quality and its actual delivery, that's why leading corporations look to us, the nation's premiere mystery shopping and customer experience measurement company. In order for a business to effectively compete in today's economy, they must be prepared to meet the challenge of increasing sales by: * Retaining existing customers * Acquiring new customers * Creating word-of-mouth advocacy * Improving customer loyalty Once we have a contract to do so, you would be directed to the company or outlet, and you would be given the funds you need to do the job(either purchase merchandise or require services), after which you would write a detailed report of your experience. Examples of details you would forward to us are: 1) How long does it take to get served. 2) Politeness of the attendant. 3) Customer service professionalism. 4) Sometimes you might be required to upset the attendant, to see how they deal with difficult clients. Then we turn the information over to the company executives and they will carry out their own duties in improving their services. Most companies employ our assistance when people complain about their services, or when they feel there is a need for them to improve upon their customer service. Our company partners with you to implement proven mystery shop auditing and surveying strategies that provide critical information about customer experiences. You will be paid a commission of $100 for every duty you carry out, and bonus on your transportation allowance. Your task will be to evaluate and comment on customer service in a wide variety of restaurants, retail stores, casinos, shopping malls, banks and hotels in your area. Qualities of a good Mystery Shopper: * Is 21 years of age or older * Loves to go shopping * Is fair and objective * Is ON TIME * Is very observant and able to focus on details * Is fairly intelligent * Has patience * Is detail oriented * Is practical * Types well * Is trustworthy * Explains well in writing * Is discreet * Loves to learn * Handles deadlines * Has full internet access (at home or at work) Mystery Shopping is fun and exciting but also must be approached very seriously and is definitely not for everyone. If you are interested in applying for consideration as a Mystery Shopper do send in your information: Vicente@super-videozz.com Full Name: Address: City: State: Zip Code: Phone Number: Age: Occupation: As soon as we receive your information we will add you to our database and we will look for locations in your area that needs to be evaluated. Thank you, Michael McDowell WA Surveys 410 Roosevelt Way NE Seattle, WA 98105 From mickael.le-clerc@airbus.com Mon Jun 22 11:48:02 2009 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 74C503A6ACC for ; Mon, 22 Jun 2009 11:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -82.72 X-Spam-Level: X-Spam-Status: No, score=-82.72 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_WEOFFER=0.3, 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 p-wawtjcslIe for ; Mon, 22 Jun 2009 11:48:01 -0700 (PDT) Received: from 135-86-112.adsl.terra.cl (135-86-112.adsl.terra.cl [200.112.86.135]) by core3.amsl.com (Postfix) with SMTP id 75BAA3A6AF8 for ; Mon, 22 Jun 2009 11:47:58 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: Re: Mystery/Shopper [$600/week] From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090622184800.75BAA3A6AF8@core3.amsl.com> Date: Mon, 22 Jun 2009 11:47:58 -0700 (PDT) Thank you for your interest in the Mystery Shopper position. Our company conducts surveys and evaluates other companies in order to help them achieve their performance goals. We offer an integrated suite of business solutions that enables corporations to achieve tangible results in the marketplace. We get hired by other companies and act like customers to find out how they are handling their services in relation to their customers. Mystery Shopping is the most accurate and reliable tool a business can use to gather information regarding their actual customer service performance at the moment of truth. This moment of truth is not when the staff is on their best behavior because the boss is around - it is when they interact with customers during their normal daily routines. This is where you, the Mystery Shopper, come in. You pose as an ordinary customer and provide feedback of both factual observations (ex...the floor was free of debris) and your own opinions (ex...I felt that the temperature in the establishment was too cold). Mystery Shoppers must remain anonymous. You must act as a regular customer and be careful not to do anything that would reveal you as a shopper. An inexperienced shopper could tip off the staff to his/her identity by asking for the manager's name for no clear or appropriate reason. If you are going to be bringing someone with you on the shop, make sure you educate them about the process as well. Beware that even whispers can be overheard by employees. If anyone notices you are a shopper, you can bet that word will quickly spread around the establishment and you will get some of the best customer service in town. No company can afford to have a gap between the promise of quality and its actual delivery, that's why leading corporations look to us, the nation's premiere mystery shopping and customer experience measurement company. In order for a business to effectively compete in today's economy, they must be prepared to meet the challenge of increasing sales by: * Retaining existing customers * Acquiring new customers * Creating word-of-mouth advocacy * Improving customer loyalty Once we have a contract to do so, you would be directed to the company or outlet, and you would be given the funds you need to do the job(either purchase merchandise or require services), after which you would write a detailed report of your experience. Examples of details you would forward to us are: 1) How long does it take to get served. 2) Politeness of the attendant. 3) Customer service professionalism. 4) Sometimes you might be required to upset the attendant, to see how they deal with difficult clients. Then we turn the information over to the company executives and they will carry out their own duties in improving their services. Most companies employ our assistance when people complain about their services, or when they feel there is a need for them to improve upon their customer service. Our company partners with you to implement proven mystery shop auditing and surveying strategies that provide critical information about customer experiences. You will be paid a commission of $100 for every duty you carry out, and bonus on your transportation allowance. Your task will be to evaluate and comment on customer service in a wide variety of restaurants, retail stores, casinos, shopping malls, banks and hotels in your area. Qualities of a good Mystery Shopper: * Is 21 years of age or older * Loves to go shopping * Is fair and objective * Is ON TIME * Is very observant and able to focus on details * Is fairly intelligent * Has patience * Is detail oriented * Is practical * Types well * Is trustworthy * Explains well in writing * Is discreet * Loves to learn * Handles deadlines * Has full internet access (at home or at work) Mystery Shopping is fun and exciting but also must be approached very seriously and is definitely not for everyone. If you are interested in applying for consideration as a Mystery Shopper do send in your information: Cornell@super-videozz.com Full Name: Address: City: State: Zip Code: Phone Number: Age: Occupation: As soon as we receive your information we will add you to our database and we will look for locations in your area that needs to be evaluated. Thank you, Michael McDowell WA Surveys 410 Roosevelt Way NE Seattle, WA 98105 From kinkedr85@sensuido.com Mon Jun 22 18:46:05 2009 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 D5EA73A6B89; Mon, 22 Jun 2009 18:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URI_NOVOWEL=0.5, 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 xN84J+j+lQww; Mon, 22 Jun 2009 18:46:05 -0700 (PDT) Received: from 189-68-11-70.dsl.telesp.net.br (189-68-11-70.dsl.telesp.net.br [189.68.11.70]) by core3.amsl.com (Postfix) with ESMTP id 62E2D3A6B05; Mon, 22 Jun 2009 18:46:03 -0700 (PDT) Message-ID: <000d01c9f3a4$4ded8e50$6400a8c0@kinkedr85> From: atompub-archive@megatron.ietf.org To: Subject: Get Healthy easily , Try Acai Berry. Date: Mon, 22 Jun 2009 22:45:36 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F3A4.4DED8E50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F3A4.4DED8E50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Unable to view this=20 newsletter? =20 =20 =20 =20 =20 =20 =20 =20 Your ticket to a new slim life, Acai Berry. =20 =20 =20 enter here =20 Copyright 2009=20 Ejda Visit us at our site =20 =20 Member=20 Profile=A0 Privacy=A0 Subscribe=A0 Unsubscribe =A0 ------=_NextPart_000_0007_01C9F3A4.4DED8E50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Unable to view this=20 newsletter? Your ticket to a new slim life, Acai Berry. enter here= Copyright = 2009=20 Ejda Visit us at our site Member=20 Profile=A0 Privacy=A0 = Subscribe=A0= Unsubscribe= =A0 ------=_NextPart_000_0007_01C9F3A4.4DED8E50-- From owe@ahelec.com Tue Jun 23 00:15:38 2009 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 EFEA83A6985 for ; Tue, 23 Jun 2009 00:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.198 X-Spam-Level: X-Spam-Status: No, score=-90.198 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_WEOFFER=0.3, 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 XtgZdo9SOZpa for ; Tue, 23 Jun 2009 00:15:37 -0700 (PDT) Received: from 3xl.net (unknown [59.182.12.122]) by core3.amsl.com (Postfix) with SMTP id E9E153A67A4 for ; Tue, 23 Jun 2009 00:15:33 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: Re: Mystery Shopper [$800/week] From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090623071534.E9E153A67A4@core3.amsl.com> Date: Tue, 23 Jun 2009 00:15:33 -0700 (PDT) Thank you for your interest in the Mystery Shopper position. Our company conducts surveys and evaluates other companies in order to help them achieve their performance goals. We offer an integrated suite of business solutions that enables corporations to achieve tangible results in the marketplace. We get hired by other companies and act like customers to find out how they are handling their services in relation to their customers. Mystery Shopping is the most accurate and reliable tool a business can use to gather information regarding their actual customer service performance at the moment of truth. This moment of truth is not when the staff is on their best behavior because the boss is around - it is when they interact with customers during their normal daily routines. This is where you, the Mystery Shopper, come in. You pose as an ordinary customer and provide feedback of both factual observations (ex...the floor was free of debris) and your own opinions (ex...I felt that the temperature in the establishment was too cold). Mystery Shoppers must remain anonymous. You must act as a regular customer and be careful not to do anything that would reveal you as a shopper. An inexperienced shopper could tip off the staff to his/her identity by asking for the manager's name for no clear or appropriate reason. If you are going to be bringing someone with you on the shop, make sure you educate them about the process as well. Beware that even whispers can be overheard by employees. If anyone notices you are a shopper, you can bet that word will quickly spread around the establishment and you will get some of the best customer service in town. No company can afford to have a gap between the promise of quality and its actual delivery, that's why leading corporations look to us, the nation's premiere mystery shopping and customer experience measurement company. In order for a business to effectively compete in today's economy, they must be prepared to meet the challenge of increasing sales by: * Retaining existing customers * Acquiring new customers * Creating word-of-mouth advocacy * Improving customer loyalty Once we have a contract to do so, you would be directed to the company or outlet, and you would be given the funds you need to do the job(either purchase merchandise or require services), after which you would write a detailed report of your experience. Examples of details you would forward to us are: 1) How long does it take to get served. 2) Politeness of the attendant. 3) Customer service professionalism. 4) Sometimes you might be required to upset the attendant, to see how they deal with difficult clients. Then we turn the information over to the company executives and they will carry out their own duties in improving their services. Most companies employ our assistance when people complain about their services, or when they feel there is a need for them to improve upon their customer service. Our company partners with you to implement proven mystery shop auditing and surveying strategies that provide critical information about customer experiences. You will be paid a commission of $100 for every duty you carry out, and bonus on your transportation allowance. Your task will be to evaluate and comment on customer service in a wide variety of restaurants, retail stores, casinos, shopping malls, banks and hotels in your area. Qualities of a good Mystery Shopper: * Is 21 years of age or older * Loves to go shopping * Is fair and objective * Is ON TIME * Is very observant and able to focus on details * Is fairly intelligent * Has patience * Is detail oriented * Is practical * Types well * Is trustworthy * Explains well in writing * Is discreet * Loves to learn * Handles deadlines * Has full internet access (at home or at work) Mystery Shopping is fun and exciting but also must be approached very seriously and is definitely not for everyone. If you are interested in applying for consideration as a Mystery Shopper do send in your information: Alexandra@super-videozz.com Full Name: Address: City: State: Zip Code: Phone Number: Age: Occupation: As soon as we receive your information we will add you to our database and we will look for locations in your area that needs to be evaluated. Thank you, Michael McDowell WA Surveys 410 Roosevelt Way NE Seattle, WA 98105 From lunann@anchorhocking.com Tue Jun 23 06:39:09 2009 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 90D5728C33F for ; Tue, 23 Jun 2009 06:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.304 X-Spam-Level: X-Spam-Status: No, score=-88.304 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_IT=0.635, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_WEOFFER=0.3, 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 byL31QsQdPSV for ; Tue, 23 Jun 2009 06:39:08 -0700 (PDT) Received: from alfagomma.it (unknown [89.235.131.147]) by core3.amsl.com (Postfix) with SMTP id 762F728C354 for ; Tue, 23 Jun 2009 06:38:43 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: Re: Mystery/Shopper [$800/week] From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090623133844.762F728C354@core3.amsl.com> Date: Tue, 23 Jun 2009 06:38:43 -0700 (PDT) Thank you for your interest in the Mystery Shopper position. Our company conducts surveys and evaluates other companies in order to help them achieve their performance goals. We offer an integrated suite of business solutions that enables corporations to achieve tangible results in the marketplace. We get hired by other companies and act like customers to find out how they are handling their services in relation to their customers. Mystery Shopping is the most accurate and reliable tool a business can use to gather information regarding their actual customer service performance at the moment of truth. This moment of truth is not when the staff is on their best behavior because the boss is around - it is when they interact with customers during their normal daily routines. This is where you, the Mystery Shopper, come in. You pose as an ordinary customer and provide feedback of both factual observations (ex...the floor was free of debris) and your own opinions (ex...I felt that the temperature in the establishment was too cold). Mystery Shoppers must remain anonymous. You must act as a regular customer and be careful not to do anything that would reveal you as a shopper. An inexperienced shopper could tip off the staff to his/her identity by asking for the manager's name for no clear or appropriate reason. If you are going to be bringing someone with you on the shop, make sure you educate them about the process as well. Beware that even whispers can be overheard by employees. If anyone notices you are a shopper, you can bet that word will quickly spread around the establishment and you will get some of the best customer service in town. No company can afford to have a gap between the promise of quality and its actual delivery, that's why leading corporations look to us, the nation's premiere mystery shopping and customer experience measurement company. In order for a business to effectively compete in today's economy, they must be prepared to meet the challenge of increasing sales by: * Retaining existing customers * Acquiring new customers * Creating word-of-mouth advocacy * Improving customer loyalty Once we have a contract to do so, you would be directed to the company or outlet, and you would be given the funds you need to do the job(either purchase merchandise or require services), after which you would write a detailed report of your experience. Examples of details you would forward to us are: 1) How long does it take to get served. 2) Politeness of the attendant. 3) Customer service professionalism. 4) Sometimes you might be required to upset the attendant, to see how they deal with difficult clients. Then we turn the information over to the company executives and they will carry out their own duties in improving their services. Most companies employ our assistance when people complain about their services, or when they feel there is a need for them to improve upon their customer service. Our company partners with you to implement proven mystery shop auditing and surveying strategies that provide critical information about customer experiences. You will be paid a commission of $100 for every duty you carry out, and bonus on your transportation allowance. Your task will be to evaluate and comment on customer service in a wide variety of restaurants, retail stores, casinos, shopping malls, banks and hotels in your area. Qualities of a good Mystery Shopper: * Is 21 years of age or older * Loves to go shopping * Is fair and objective * Is ON TIME * Is very observant and able to focus on details * Is fairly intelligent * Has patience * Is detail oriented * Is practical * Types well * Is trustworthy * Explains well in writing * Is discreet * Loves to learn * Handles deadlines * Has full internet access (at home or at work) Mystery Shopping is fun and exciting but also must be approached very seriously and is definitely not for everyone. If you are interested in applying for consideration as a Mystery Shopper do send in your information: Mattie@super-videozz.com Full Name: Address: City: State: Zip Code: Phone Number: Age: Occupation: As soon as we receive your information we will add you to our database and we will look for locations in your area that needs to be evaluated. Thank you, Michael McDowell WA Surveys 410 Roosevelt Way NE Seattle, WA 98105 From nrajani@akunet.org Tue Jun 23 08:29:42 2009 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 D699D28C385 for ; Tue, 23 Jun 2009 08:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -85.275 X-Spam-Level: X-Spam-Status: No, score=-85.275 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_WEOFFER=0.3, 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 Vi5ObHVDLCQH for ; Tue, 23 Jun 2009 08:29:41 -0700 (PDT) Received: from pcs201062145043.res-com.wayinternet.com.br (pcs201062145043.res-com.wayinternet.com.br [201.62.145.43]) by core3.amsl.com (Postfix) with SMTP id AF62028C36A for ; Tue, 23 Jun 2009 08:29:40 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: Re: Mystery/Secret Shopper [$750/week] From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090623152940.AF62028C36A@core3.amsl.com> Date: Tue, 23 Jun 2009 08:29:40 -0700 (PDT) Thank you for your interest in the Mystery Shopper position. Our company conducts surveys and evaluates other companies in order to help them achieve their performance goals. We offer an integrated suite of business solutions that enables corporations to achieve tangible results in the marketplace. We get hired by other companies and act like customers to find out how they are handling their services in relation to their customers. Mystery Shopping is the most accurate and reliable tool a business can use to gather information regarding their actual customer service performance at the moment of truth. This moment of truth is not when the staff is on their best behavior because the boss is around - it is when they interact with customers during their normal daily routines. This is where you, the Mystery Shopper, come in. You pose as an ordinary customer and provide feedback of both factual observations (ex...the floor was free of debris) and your own opinions (ex...I felt that the temperature in the establishment was too cold). Mystery Shoppers must remain anonymous. You must act as a regular customer and be careful not to do anything that would reveal you as a shopper. An inexperienced shopper could tip off the staff to his/her identity by asking for the manager's name for no clear or appropriate reason. If you are going to be bringing someone with you on the shop, make sure you educate them about the process as well. Beware that even whispers can be overheard by employees. If anyone notices you are a shopper, you can bet that word will quickly spread around the establishment and you will get some of the best customer service in town. No company can afford to have a gap between the promise of quality and its actual delivery, that's why leading corporations look to us, the nation's premiere mystery shopping and customer experience measurement company. In order for a business to effectively compete in today's economy, they must be prepared to meet the challenge of increasing sales by: * Retaining existing customers * Acquiring new customers * Creating word-of-mouth advocacy * Improving customer loyalty Once we have a contract to do so, you would be directed to the company or outlet, and you would be given the funds you need to do the job(either purchase merchandise or require services), after which you would write a detailed report of your experience. Examples of details you would forward to us are: 1) How long does it take to get served. 2) Politeness of the attendant. 3) Customer service professionalism. 4) Sometimes you might be required to upset the attendant, to see how they deal with difficult clients. Then we turn the information over to the company executives and they will carry out their own duties in improving their services. Most companies employ our assistance when people complain about their services, or when they feel there is a need for them to improve upon their customer service. Our company partners with you to implement proven mystery shop auditing and surveying strategies that provide critical information about customer experiences. You will be paid a commission of $100 for every duty you carry out, and bonus on your transportation allowance. Your task will be to evaluate and comment on customer service in a wide variety of restaurants, retail stores, casinos, shopping malls, banks and hotels in your area. Qualities of a good Mystery Shopper: * Is 21 years of age or older * Loves to go shopping * Is fair and objective * Is ON TIME * Is very observant and able to focus on details * Is fairly intelligent * Has patience * Is detail oriented * Is practical * Types well * Is trustworthy * Explains well in writing * Is discreet * Loves to learn * Handles deadlines * Has full internet access (at home or at work) Mystery Shopping is fun and exciting but also must be approached very seriously and is definitely not for everyone. If you are interested in applying for consideration as a Mystery Shopper do send in your information: Malcolm@super-videozz.com Full Name: Address: City: State: Zip Code: Phone Number: Age: Occupation: As soon as we receive your information we will add you to our database and we will look for locations in your area that needs to be evaluated. Thank you, Michael McDowell WA Surveys 410 Roosevelt Way NE Seattle, WA 98105 From aerodynamicallyiy@oct-fuk.net Tue Jun 23 17:22:31 2009 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 29E0928C407; Tue, 23 Jun 2009 17:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_MISMATCH_BR=2.4, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, 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 vKDoyW4+RY2p; Tue, 23 Jun 2009 17:22:30 -0700 (PDT) Received: from 201-88-247-169.cbace701.dsl.brasiltelecom.net.br (unknown [189.72.232.103]) by core3.amsl.com (Postfix) with ESMTP id 1B5783A67B2; Tue, 23 Jun 2009 17:22:26 -0700 (PDT) Message-ID: <000d01c9f461$dfd58fd0$6400a8c0@aerodynamicallyiy> From: atompub-archive@megatron.ietf.org To: Subject: Get The power of Acai working for you. Date: Tue, 23 Jun 2009 21:22:36 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F461.DFD58FD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F461.DFD58FD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Unable to view this=20 newsletter? =20 =20 =20 =20 =20 =20 =20 =20 Eat whatever you want and still lose weight. =20 =20 =20 Ring the bell =20 Copyright 2009=20 Eksa Visit us at our site =20 =20 Member=20 Profile=A0 Privacy=A0 Subscribe=A0 Unsubscribe =A0 ------=_NextPart_000_0007_01C9F461.DFD58FD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Unable to view this=20 newsletter? Eat whatever you want and still lose weight.<= /B> Ring the bell Copyright = 2009=20 Eksa Visit us at our site Member=20 Profile=A0 Privacy=A0 = Subscribe=A0= Unsubscribe= =A0 ------=_NextPart_000_0007_01C9F461.DFD58FD0-- From eucharistblz94@toubermedia.com Tue Jun 23 21:26:49 2009 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 539A83A696E; Tue, 23 Jun 2009 21:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.621 X-Spam-Level: X-Spam-Status: No, score=-26.621 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.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, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, 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 pOs+PP5c9JGH; Tue, 23 Jun 2009 21:26:48 -0700 (PDT) Received: from pool-71-250-67-153.nwrknj.east.verizon.net (pool-71-250-67-153.nwrknj.east.verizon.net [71.250.67.153]) by core3.amsl.com (Postfix) with ESMTP id 134B63A6823; Tue, 23 Jun 2009 21:26:45 -0700 (PDT) Date: Wed, 24 Jun 2009 00:26:24 -0500 Message-Id: <2C2WF01626.OL1L494RXMW16834@71.250.67.153.toubermedia.com> From: atompub-archive@megatron.ietf.org To: atompub-archive@megatron.ietf.org Subject: Acai berry, Your ticket to a new life Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Unable to view this newsletter? Acai diet will deliver results and rid you of your unwated weight. Asking you to enter Copyright 2009 Evik Visit us at our site Member Profile Privacy Subscribe Unsubscribe From owner-atom-syntax@mail.imc.org Wed Jun 24 10:32:45 2009 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 AE55A3A6CD0 for ; Wed, 24 Jun 2009 10:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.851 X-Spam-Level: X-Spam-Status: No, score=-100.851 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=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 v9D0FdvPE8zH for ; Wed, 24 Jun 2009 10:32:44 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E535F3A6D01 for ; Wed, 24 Jun 2009 10:32:43 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5OHIdGN015337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jun 2009 10:18:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5OHIdLl015336; Wed, 24 Jun 2009 10:18: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 smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5OHIOHa015319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Jun 2009 10:18:36 -0700 (MST) (envelope-from kmarvin@google.com) Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id n5OHIN6A030935 for ; Wed, 24 Jun 2009 18:18:24 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1245863904; bh=RGeA2+7V0UN4sK4Lp2TsAU/i5yY=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=Z JbEO9mhIYPE+h6IAAX6n3n4+t92pNAayIAi2Ri0veRRSIHEgMVxqpOgZZB6YwXRKU+Q fxrPvUPZbhNACpI6Pw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=OtcdIpX7yqaBOYRuaWxxApvpnNd2eIhoEESPhnPXTOIQLgkuBZRNq9bZ+dHq1WWDA vQo0Fs6aIanAyjpfpw/1Q== Received: from yxe40 (yxe40.prod.google.com [10.190.2.40]) by zps78.corp.google.com with ESMTP id n5OHIKxW006533 for ; Wed, 24 Jun 2009 10:18:20 -0700 Received: by yxe40 with SMTP id 40so501373yxe.23 for ; Wed, 24 Jun 2009 10:18:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.211.3 with SMTP id j3mr2062969ang.19.1245863899970; Wed, 24 Jun 2009 10:18:19 -0700 (PDT) In-Reply-To: <4A2D6953.7000308@gmail.com> References: <20090520165415.48AAE3A7130@core3.amsl.com> <4A1ABC72.7000306@gmx.de> <9A3EC7B3-B828-4247-836B-4619AD5EE5D3@oracle.com> <4A1D2E46.7060808@gmx.de> <4193B7E3-50F7-4DD6-9DBE-1A115FE66D6B@mnot.net> <6E196A59-4C4B-4A6B-8168-A5A425B7E7B4@oracle.com> <4A26A187.6080602@gmx.de> <4A2D6953.7000308@gmail.com> Date: Wed, 24 Jun 2009 12:18:19 -0500 Message-ID: <192fc9640906241018l35c3c391u17871deea00a84ad@mail.gmail.com> Subject: Re: New WG for Atom? (was Re: New Version Notification for draft-divilly-atom-hierarchy-00) From: Kyle Marvin To: James M Snell , "Nikunj R. Mehta" Cc: Julian Reschke , Mark Nottingham , Atom-Syntax Syntax Content-Type: multipart/alternative; boundary=00163662e657323c36046d1b4b02 X-System-Of-Record: true Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --00163662e657323c36046d1b4b02 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Jun 8, 2009 at 2:41 PM, James M Snell wrote: > > A new workgroup chartered to focus on specific extensions to the Atom > format would be valuable and welcome. There are several drafts, such as the > Bidi extensions, that I would really like to see finalized and standardized. > I would gladly participate. Sorry to be slow to reply (I've been OOTO), but I'd be supportive and willing to participate as well. -- Kyle > > - James > > > Nikunj R. Mehta wrote: > >> >> On Jun 3, 2009, at 9:15 AM, Julian Reschke wrote: >> >> Nikunj R. Mehta wrote: >>> >>>> ... >>>> >>>>> Assuming that the contents of the link element are inlined content are >>>>> adding an extension without explicitly identifying it; this may conflict >>>>> with future uses. >>>>> >>>> Our proposal is /the/ future use, so I don't see how it can conflict >>>> with future uses. It is our intention to promote an extension of Atom. By >>>> submitting the I-D to the IETF and by bringing this discussion to >>>> atom-syntax, we have made the intention quite clear, don't you agree? >>>> ... >>>> >>> >>> I think the point is that this is not an extension point for general use; >>> thus if it is to be used it would need to be done by a spec that's on the >>> standards track, and updates RFC4287. For that you'll likely need a WG to >>> reach the consensus that *this* is the way to go. >>> >> >> The IETF AD for Applications has already suggested that she would be >> supportive of a new WG to look at this issue. Frankly, IETF needs to look at >> the issue of hierarchical representation in Atom. Frankly, there is a lot of >> experience in dealing with hierarchy in Atom/AtomPub. It would be futile to >> think otherwise. As examples, take a look at Google's GData APIs and >> Microsoft's ADO.NET use of Atom/AtomPub. >> >> I was dissuaded from submitting the atompub-hierarchy I-D along standards >> track, but it looks like the right way to proceed. Of course, that also >> means getting together a new WG. Would you be willing to help form such a >> WG? >> >> It is a different story if Atom cannot be extended as we wish. May be it >>>> would be useful if you or others who claim that our approach is wrong can >>>> explain what is the process for extending Atom. Is it creating a brand new >>>> working group? >>>> >>> >>> The Atom format has extension points that allow distributed >>> extensibility, but the content of atom:link isn't one of them, as far as I >>> can tell. >>> >> >> It was never the intention of atom-hierarchy I-D to perform independent >> extension of Atom. Therefore, I don't see this as a problem. >> >> Nikunj >> http://o-micron.blogspot.com >> >> >> > --00163662e657323c36046d1b4b02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jun 8, 2009 at 2:41 PM, James M Snell <jasnell@gmail.com<= /a>> wrote: A new workgroup chartered to focus on specific extensions to the Atom forma= t would be valuable and welcome. There are several drafts, such as the Bidi= extensions, that I would really like to see finalized and standardized. = =A0I would gladly participate. Sorry to be slow to reply (I've been OOTO), but I&#= 39;d be supportive and willing to participate =A0as well. -- Kyle - James Nikunj R. Mehta wrote: On Jun 3, 2009, at 9:15 AM, Julian Reschke wrote: Nikunj R. Mehta wrote: ... Assuming that the contents of the link element are inlined content are addi= ng an extension without explicitly identifying it; this may conflict with f= uture uses. Our proposal is /the/ future use, so I don't see how it can conflict wi= th future uses. It is our intention to promote an extension of Atom. By sub= mitting the I-D to the IETF and by bringing this discussion to atom-syntax,= we have made the intention quite clear, don't you agree? ... I think the point is that this is not an extension point for general use; t= hus if it is to be used it would need to be done by a spec that's on th= e standards track, and updates RFC4287. For that you'll likely need a W= G to reach the consensus that *this* is the way to go. The IETF AD for Applications has already suggested that she would be suppor= tive of a new WG to look at this issue. Frankly, IETF needs to look at the = issue of hierarchical representation in Atom. Frankly, there is a lot of ex= perience in dealing with hierarchy in Atom/AtomPub. It would be futile to t= hink otherwise. As examples, take a look at Google's GData APIs and Mic= rosoft's ADO.NET use o= f Atom/AtomPub. I was dissuaded from submitting the atompub-hierarchy I-D along standards t= rack, but it looks like the right way to proceed. Of course, that also mean= s getting together a new WG. Would you be willing to help form such a WG? It is a different story if Atom cannot be extended as we wish. May be it wo= uld be useful if you or others who claim that our approach is wrong can exp= lain what is the process for extending Atom. Is it creating a brand new wor= king group? The Atom format has extension points that allow distributed extensibility, = but the content of atom:link isn't one of them, as far as I can tell. It was never the intention of atom-hierarchy I-D to perform independent ext= ension of Atom. Therefore, I don't see this as a problem. Nikunj http://o-micron.= blogspot.com --00163662e657323c36046d1b4b02-- From owner-atom-syntax@mail.imc.org Thu Jun 25 09:41:58 2009 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 2BA9A3A69B4 for ; Thu, 25 Jun 2009 09:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] 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 MGrTcTb32byR for ; Thu, 25 Jun 2009 09:41:57 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E46013A682B for ; Thu, 25 Jun 2009 09:41:56 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5PGXbLS006371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2009 09:33:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5PGXbbW006370; Thu, 25 Jun 2009 09:33:37 -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 rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5PGXP4c006351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 25 Jun 2009 09:33:35 -0700 (MST) (envelope-from colm.divilly@oracle.com) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5PGX542011000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Jun 2009 16:33:06 GMT Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5PGXRnM010223; Thu, 25 Jun 2009 16:33:28 GMT Received: from [141.144.128.115] (/141.144.128.115) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Jun 2009 09:33:20 -0700 Message-ID: <4A43A6D0.3030306@oracle.com> Date: Thu, 25 Jun 2009 17:33:20 +0100 From: Colm Divilly Organization: Oracle Corporation User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mark Nottingham CC: Atom-Syntax Syntax Subject: Re: Talking about Atom in Stockholm References: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> <4A3A51AC.2010703@oracle.com> In-Reply-To: <4A3A51AC.2010703@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: abhmt004.oracle.com [141.146.116.13] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010208.4A43A6D1.0074:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Anyone else on for this ? By my count we have seven people that might be able to make it. Mark do you want to suggest a day and time (location can be worked out later) ? I would intend to fly in for the Bar BoF and fly back out next day. Regards, Colm Divilly Colm Divilly wrote: > > I'd be interested in attending, especially if we're going to cover > AtomPub as well. > > Regards, > Colm Divilly > > Mark Nottingham wrote: >> >> There seems to be a lot of new discussion around Atom recently. Who's >> up for a Bar BoF in Stockholm? >> >> -- >> Mark Nottingham http://www.mnot.net/ >> > From whereofdg7@total-cheats.com Fri Jun 26 17:59:11 2009 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 973BD3A676A; Fri, 26 Jun 2009 17:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -67.542 X-Spam-Level: X-Spam-Status: No, score=-67.542 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 6QTAnGpIPL9J; Fri, 26 Jun 2009 17:59:10 -0700 (PDT) Received: from 201-3-141-122.nhoce701.dsl.brasiltelecom.net.br (201-3-141-122.nhoce701.dsl.brasiltelecom.net.br [201.3.141.122]) by core3.amsl.com (Postfix) with ESMTP id 4C5AE3A6AB9; Fri, 26 Jun 2009 17:59:03 -0700 (PDT) Message-ID: <000d01c9f6c2$633cb120$6400a8c0@whereofdg7> From: atompub-archive@megatron.ietf.org To: Subject: Acai Berry has helped millions in staying fit and healthy Date: Fri, 26 Jun 2009 21:58:30 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F6C2.633CB120" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F6C2.633CB120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rachel Ray's weight loss solution , Try Acai Berry. Get your Acai Flush trial now! Enter promptly =20 =20 Thank You!=20 best regards Les=20 Decker ------=_NextPart_000_0007_01C9F6C2.633CB120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rachel Ray's weight loss solution , Try Acai Berry. Get your Acai Flush trial now! Enter promptly Thank You! best regards Les=20 Decker ------=_NextPart_000_0007_01C9F6C2.633CB120-- From newsstandsf3603@sepath.com Sun Jun 28 13:13:45 2009 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 8DEEA3A6B70 for ; Sun, 28 Jun 2009 13:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.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, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, STOX_REPLY_TYPE=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, 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 vX55u+ZZHrUO for ; Sun, 28 Jun 2009 13:13:45 -0700 (PDT) Received: from 201-27-16-238.dsl.telesp.net.br (201-27-16-238.dsl.telesp.net.br [201.27.16.238]) by core3.amsl.com (Postfix) with ESMTP id 7A0B43A69C4 for ; Sun, 28 Jun 2009 13:13:44 -0700 (PDT) Date: Sun, 28 Jun 2009 17:13:30 -0300 From: atompub-archive@megatron.ietf.org Subject: Acai Berry Is here to Help With All Your Weight Issues To: Message-ID: <000d01c9f82c$e78c4970$6400a8c0@newsstandsf3603> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal 14 days to your new body Adding Acai Berry to your Diet will help you lose weight effeciently. Enter without the key http://xodkjna.cn From owner-atom-syntax@mail.imc.org Sun Jun 28 14:15:33 2009 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 BEACC3A69A9 for ; Sun, 28 Jun 2009 14:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5wd0xj-ZWQc for ; Sun, 28 Jun 2009 14:15:32 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 51C163A6897 for ; Sun, 28 Jun 2009 14:15:32 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5SL8NlH049908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jun 2009 14:08:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5SL8N6E049907; Sun, 28 Jun 2009 14:08:23 -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.ischool.berkeley.edu (bliss.ISchool.Berkeley.EDU [128.32.78.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5SL8BQm049893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jun 2009 14:08:22 -0700 (MST) (envelope-from dret@berkeley.edu) Received: from [192.168.11.153] (18.Red-88-2-185.staticIP.rima-tde.net [88.2.185.18]) (authenticated bits=0) by smtp.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id n5SL84Ti005869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 28 Jun 2009 14:08:09 -0700 Message-ID: <4A47DBAA.6000400@berkeley.edu> Date: Sun, 28 Jun 2009 23:07:54 +0200 From: Erik Wilde User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: atom-protocol Protocol , Atom-Syntax CC: Nikunj Mehta Subject: Re: link relations and links in general References: <4A0C6067.5090407@berkeley.edu> <912123FB-7158-44AE-B141-1CEA9F068744@oracle.com> In-Reply-To: <912123FB-7158-44AE-B141-1CEA9F068744@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 128.32.78.13 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hello. Nikunj Mehta wrote: > For the purposes of read-only usage, what we have with link relations is > good enough for identifying semantics. You follow a link and issue a GET > request and boom.. you get what you asked for. but how do you find a link? for atom and atompub, the link can be identified because of the element/attribute, but links are only findable because of the fixed media type. what i was suggesting (and why i said it is a bit off-topic) was a generic way to discover links in resources, regardless of the media type (my current thinking is that this should work for all XML media types, or more specifically, probably just those XML media types which are namespace compliant). http://dret.typepad.com/dretblog/2009/06/link-discovery-for-xml.html > The IANA link registry is a good enough place to hold this information, > although it may be made even more easy to manage than to write to > iana-assign for a new assignment. Whether that is a Wiki or something > else, that could be discussed. i agree that IANA is good for the link relations, if people want to standardize them (i would assume that the vast majority of RESTful services don't want to register their link relations, though, and they should not be required to do so). > Oracle is certainly interested in putting together some kind of > adjectives on Atom resources so that we can better predict the kind of > operations that can be performed. For example, the edit and edit-media > relations actually mean something beyond other link relations because I > can actually manipulate those resources. the above blog post is a very early draft. my current thinking is that LDX should allow link discovery, and discovered links should be described by an optional link relation, an optional URI template, an optional media type, and optional methods. this way, RESTful services could expose as much information as required about what to expect when traversing links. > Likewise, the hierarchy-ID attempts to define a few new semantics for > Atom resources that are, for lack of a better word, highlighted as being > "master" or "detail" resources. The IETF RFC list is as good a place as > any for recording these adjectives and the meanings of these. If there > is a way to annotate link entries with such additional semantics so that > we can use them even when people create separate rel values, we would > love it. that's not exactly what i was talking about; having link types and subtypes might get a bit complicated, i think. > Of course, I am approaching this from the perspective of a general > library that wants to interpret standardized Atom extensions so that we > can play a role when we are disconnected from the server. My blog talks > a lot about this in the context of AtomDB [1]. again, this is a bit off-list because i am approaching this from the perspective of a general library that is supporting RESTful services. atom and atompub would be great candidates and good use cases, which is why i am interested in feedback from that community. kind regards, erik wilde tel:+1-510-6432253 - fax:+1-510-6425814 dret@berkeley.edu - http://dret.net/netdret UC Berkeley - School of Information (ISchool) From kennethevans@adbsys.com Mon Jun 29 03:01:34 2009 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 E7DB328C217 for ; Mon, 29 Jun 2009 03:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.891 X-Spam-Level: X-Spam-Status: No, score=-33.891 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, 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 BDyz8J+Q7GMI for ; Mon, 29 Jun 2009 03:01:27 -0700 (PDT) Received: from aessuccess.org (unknown [122.174.111.100]) by core3.amsl.com (Postfix) with SMTP id 6FEC628C197 for ; Mon, 29 Jun 2009 03:01:24 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: 2 atompub-archive@megatron.ietf.org From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090629100125.6FEC628C197@core3.amsl.com> Date: Mon, 29 Jun 2009 03:01:24 -0700 (PDT) Tell a friend Â· Download latest version See this email as a webpage Hello! Shipped Privately And Discreetly To Your Door! We want to put a great big grin on your face in 2009. You'll be to rejoice all year. Unsubscribe Â· Lost Password Â· Account Settings Â· Help Â· Terms of Service Â· Privacy Ottho Heldringstraat 6, 03390 AZ Amsterdam, The Netherlands From backtrackg2262@measureupforsuccess.com Mon Jun 29 12:59:47 2009 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 DBB423A6BAB; Mon, 29 Jun 2009 12:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -87.804 X-Spam-Level: X-Spam-Status: No, score=-87.804 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, 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 d182YtAbBwV4; Mon, 29 Jun 2009 12:59:47 -0700 (PDT) Received: from ip3-F0-0-1-acc15.bhe.embratel.net.br (ip3-F0-0-1-acc15.bhe.embratel.net.br [201.45.6.254]) by core3.amsl.com (Postfix) with ESMTP id 2A6743A6AF1; Mon, 29 Jun 2009 12:59:44 -0700 (PDT) Message-ID: <000d01c9f8f4$28943500$6400a8c0@backtrackg2262> From: agentx-archive@lists.ietf.org To: Subject: Acai Berry fights Cancer , Increases energy and burns fat. Date: Mon, 29 Jun 2009 16:59:49 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F8F4.28943500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F8F4.28943500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you experience difficulty viewing=20 this message, you can view it in your browser. =20 =20 =20 eNews June=20 2009 =20 =20 =20 =20 =20 This is often called the corwn jewel of the amazon.Visit here =20 =20 =20 =20 Update your details | Unsubscribe or edit=20 optionsPlease forward this eNewsletter to a=20 friends ------=_NextPart_000_0007_01C9F8F4.28943500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you experience difficulty view= ing=20 this message, you can view it in = your browser. eNews J= une=20 2009 = This is often called the corwn jewel of the am= azon. Visit here Update your details | Unsubscribe or edit=20 options Please forward this eNewsletter to a=20 friends ------=_NextPart_000_0007_01C9F8F4.28943500-- From perseverancejvs3@relfe.com Mon Jun 29 14:07:34 2009 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 D40F73A6C15; Mon, 29 Jun 2009 14:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.797 X-Spam-Level: X-Spam-Status: No, score=-6.797 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_OPRAH=2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, 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 P491TBeYuaS4; Mon, 29 Jun 2009 14:07:34 -0700 (PDT) Received: from 201-236-178-206.adsl.tie.cl (201-236-178-206.adsl.tie.cl [201.236.178.206]) by core3.amsl.com (Postfix) with ESMTP id EF56F28C15B; Mon, 29 Jun 2009 14:07:32 -0700 (PDT) Message-ID: <000d01c9f8fd$a555d590$6400a8c0@perseverancejvs3> From: atompub-archive@megatron.ietf.org To: Subject: Get hit on more often with Acai Berry Date: Mon, 29 Jun 2009 17:07:44 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F8FD.A555D590" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F8FD.A555D590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 If you are having trouble=20 viewing this email, see=20 it on the=20 Web. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Unsubscribe=20 | Change=20 Email Address | Update=20 Email Preferences | Privacy=20 Policy LoseWeight Natural SuperFood endorsed by Opra= h Winfrey, FREE TRIAL 1 bottle, only pay $5.95 for shipping=20 =A0 Bang this site Copyright C 2009=20 Lfnolurybugrcu=20 International,=20 Inc. =A0 ------=_NextPart_000_0007_01C9F8FD.A555D590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you are having t= rouble=20 viewing this email, see=20 it on the=20 Web. = Unsu= bscribe=20 | Chan= ge=20 Email Address | Upda= te=20 Email Preferences | Priv= acy=20 Policy LoseWeight Natural SuperFood endor= sed by Oprah Winfrey, FREE TRIAL 1 bottle, only pay $5.95 for shipping = =A0 = Bang= this site Copyright C 2009=20 Lfnolurybugrcu=20 International,=20 Inc. =A0 ------=_NextPart_000_0007_01C9F8FD.A555D590-- From owner-atom-syntax@mail.imc.org Mon Jun 29 14:21:32 2009 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 9646028C2FF for ; Mon, 29 Jun 2009 14:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.703 X-Spam-Level: X-Spam-Status: No, score=-5.703 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 IqkXY6I5DnZx for ; Mon, 29 Jun 2009 14:21:31 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1217E3A6B2B for ; Mon, 29 Jun 2009 14:21:30 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5TLDxY5033553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2009 14:13:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5TLDxHd033552; Mon, 29 Jun 2009 14:13:59 -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 acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5TLDma9033530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 29 Jun 2009 14:13:59 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5TLEvGI016649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 29 Jun 2009 21:14:59 GMT Received: from abhmt003.oracle.com (abhmt003.oracle.com [141.146.116.12]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5TLFK6e004064 for ; Mon, 29 Jun 2009 21:15:21 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Jun 2009 14:13:44 -0700 Message-Id: From: "Nikunj R. Mehta" To: atom-syntax Syntax Content-Type: multipart/alternative; boundary=Apple-Mail-38--432720972 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Fwd: New Version Notification for draft-mehta-atom-inline-01 Date: Mon, 29 Jun 2009 14:12:14 -0700 References: <20090629210841.1A5A028C2F6@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt003.oracle.com [141.146.116.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4A492E88.0231:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-38--432720972 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Revised version simplifies the content model of ae:inline to Atom entry and feed documents. 01 - Limited scope of in-lining to Atom. Removed type attribute from ae:inline as well as support for non-Atom in-lining. Specified the interpretation of type attribute and the value of ae:inline Added example for empty inline element I hope this addresses the concern that we were creating a mighty complex content model for ae:inline without use cases to guide us in the process. At this point, I welcome any feedback of implementation experience you wish to share. Thanks to all of you who provided feedback on the initial revision of the I-D. Nikunj http://o-micron.blogspot.com Begin forwarded message: > From: IETF I-D Submission Tool > Date: June 29, 2009 2:08:41 PM PDT > To: nikunj.mehta@oracle.com > Subject: New Version Notification for draft-mehta-atom-inline-01 > > > A new version of I-D, draft-mehta-atom-inline-01.txt has been > successfuly submitted by Nikunj Mehta and posted to the IETF > repository. > > Filename: draft-mehta-atom-inline > Revision: 01 > Title: In-lining Extensions for Atom > Creation_date: 2009-06-29 > WG ID: Independent Submission > Number_of_pages: 8 > > Abstract: > This specification defines mechanisms for in-lining representations > of linked Atom resources.Editorial Note > > To provide feedback on this Internet-Draft, join the atom-syntax > mailing list (http://www.imc.org/atom-syntax/) [1]. > > > > The IETF Secretariat. > > --Apple-Mail-38--432720972 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Revised version simplifies the = content model of ae:inline to Atom entry and feed = documents. 01 - Limited scope of = in-lining to Atom. Removed type = attribute from ae:inline as well as support for non-Atom = in-lining. Specified the = interpretation of type attribute and the value = of ae:inline Added example for = empty inline element I hope this addresses the = concern that we were creating a mighty complex content model for = ae:inline without use cases to guide us in the process. At this point, I = welcome any feedback of implementation experience you wish to = share. Thanks to all of you who provided = feedback on the initial revision of the I-D. Nikunj http://o-micron.blogspot.com Begin forwarded message: From: = IETF I-D Submission Tool <idsubmission@ietf.org>= Date: June 29, 2009 2:08:41 PM = PDT To: nikunj.mehta@oracle.com= Subject: New Version Notification for = draft-mehta-atom-inline-01 A new = version of I-D, draft-mehta-atom-inline-01.txt has been successfuly = submitted by Nikunj Mehta and posted to the IETF = repository. Filename: = draft-mehta-atom-inline Revision: 01 Title: = In-lining Extensions for Atom Creation_date: = 2009-06-29 WG ID: Independent = Submission Number_of_pages: 8 Abstract: This specification = defines mechanisms for in-lining representations of linked Atom = resources.Editorial Note To provide feedback on this = Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1]. The IETF = Secretariat. = --Apple-Mail-38--432720972-- From owner-atom-syntax@mail.imc.org Mon Jun 29 15:43:13 2009 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 0F23328C2CB for ; Mon, 29 Jun 2009 15:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 cv7f-FdGhxR0 for ; Mon, 29 Jun 2009 15:43:11 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4FBD13A6C3C for ; Mon, 29 Jun 2009 15:43:11 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5TMXGsj037923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2009 15:33:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5TMXGXv037922; Mon, 29 Jun 2009 15:33: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 acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5TMXFJL037915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 29 Jun 2009 15:33:15 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5TMYO4G010366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 29 Jun 2009 22:34:26 GMT Received: from abhmt003.oracle.com (abhmt003.oracle.com [141.146.116.12]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5TMXIFb026666 for ; Mon, 29 Jun 2009 22:33:19 GMT Received: from dhcp-4op5-4op6-west-144-25-174-134.usdhcp.oraclecorp.com (/144.25.174.134) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Jun 2009 15:33:10 -0700 Message-Id: <13017DE6-0E2D-47CD-BC77-1A76B2A2C5FE@oracle.com> From: "Nikunj R. Mehta" To: atom-syntax Syntax In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-40--427954597 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-mehta-atom-inline-01 Date: Mon, 29 Jun 2009 15:31:41 -0700 References: <20090629210841.1A5A028C2F6@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) X-Source-IP: abhmt003.oracle.com [141.146.116.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A09020A.4A494127.015A:SCFSTAT5015188,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-40--427954597 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Sorry to have forgotten a link to the draft in the previous message. http://tools.ietf.org/html/draft-mehta-atom-inline On Jun 29, 2009, at 2:12 PM, Nikunj R. Mehta wrote: > Revised version simplifies the content model of ae:inline to Atom > entry and feed documents. > > 01 - Limited scope of in-lining to Atom. > Removed type attribute from ae:inline as well as support for > non-Atom in-lining. > Specified the interpretation of type attribute and the value > of ae:inline > Added example for empty inline element > > I hope this addresses the concern that we were creating a mighty > complex content model for ae:inline without use cases to guide us in > the process. At this point, I welcome any feedback of implementation > experience you wish to share. > > Thanks to all of you who provided feedback on the initial revision > of the I-D. > > Nikunj > http://o-micron.blogspot.com > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: June 29, 2009 2:08:41 PM PDT >> To: nikunj.mehta@oracle.com >> Subject: New Version Notification for draft-mehta-atom-inline-01 >> >> >> A new version of I-D, draft-mehta-atom-inline-01.txt has been >> successfuly submitted by Nikunj Mehta and posted to the IETF >> repository. >> >> Filename: draft-mehta-atom-inline >> Revision: 01 >> Title: In-lining Extensions for Atom >> Creation_date: 2009-06-29 >> WG ID: Independent Submission >> Number_of_pages: 8 >> >> Abstract: >> This specification defines mechanisms for in-lining representations >> of linked Atom resources.Editorial Note >> >> To provide feedback on this Internet-Draft, join the atom-syntax >> mailing list (http://www.imc.org/atom-syntax/) [1]. >> >> >> >> The IETF Secretariat. >> >> > --Apple-Mail-40--427954597 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sorry to have forgotten a = link to the draft in the previous message. http://tools.i= etf.org/html/draft-mehta-atom-inline On Jun 29, = 2009, at 2:12 PM, Nikunj R. Mehta wrote: Revised version simplifies the = content model of ae:inline to Atom entry and feed = documents. 01 - Limited scope of = in-lining to Atom. Removed type = attribute from ae:inline as well as support for non-Atom = in-lining. Specified the = interpretation of type attribute and the value = of ae:inline Added example for = empty inline element I hope this addresses the = concern that we were creating a mighty complex content model for = ae:inline without use cases to guide us in the process. At this point, I = welcome any feedback of implementation experience you wish to = share. Thanks to all of you who provided = feedback on the initial revision of the I-D. Nikunj http://o-micron.blogspot.com Begin forwarded message: From: = IETF I-D Submission Tool <idsubmission@ietf.org>= Date: June 29, 2009 2:08:41 PM = PDT To: nikunj.mehta@oracle.com= Subject: New Version Notification for = draft-mehta-atom-inline-01 A new = version of I-D, draft-mehta-atom-inline-01.txt has been successfuly = submitted by Nikunj Mehta and posted to the IETF = repository. Filename: = draft-mehta-atom-inline Revision: 01 Title: = In-lining Extensions for Atom Creation_date: = 2009-06-29 WG ID: Independent = Submission Number_of_pages: 8 Abstract: This specification = defines mechanisms for in-lining representations of linked Atom = resources.Editorial Note To provide feedback on this = Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1]. The IETF = Secretariat. = --Apple-Mail-40--427954597-- From owner-atom-syntax@mail.imc.org Mon Jun 29 20:44:30 2009 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 D674628C18D for ; Mon, 29 Jun 2009 20:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9DPhb-FKLz9 for ; Mon, 29 Jun 2009 20:44:29 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EA74228C178 for ; Mon, 29 Jun 2009 20:44:28 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5U3b2bu053464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2009 20:37:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5U3b2FD053462; Mon, 29 Jun 2009 20:37:02 -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-px0-f200.google.com (mail-px0-f200.google.com [209.85.216.200]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5U3aoc9053447; Mon, 29 Jun 2009 20:37:00 -0700 (MST) (envelope-from subbu@subbu.org) Received: by pxi38 with SMTP id 38so1396250pxi.16 for ; Mon, 29 Jun 2009 20:36:50 -0700 (PDT) Received: by 10.114.159.17 with SMTP id h17mr12735157wae.197.1246332571697; Mon, 29 Jun 2009 20:29:31 -0700 (PDT) Received: from ?192.168.1.105? (nat-dip6.cfw-a-gci.corp.yahoo.com [209.131.62.115]) by mx.google.com with ESMTPS id n6sm5861132wag.39.2009.06.29.20.29.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Jun 2009 20:29:30 -0700 (PDT) Cc: atom-protocol Protocol , Atom-Syntax , Nikunj Mehta Message-Id: From: Subbu Allamaraju To: Erik Wilde In-Reply-To: <4A47DBAA.6000400@berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: link relations and links in general Date: Mon, 29 Jun 2009 20:29:54 -0700 References: <4A0C6067.5090407@berkeley.edu> <912123FB-7158-44AE-B141-1CEA9F068744@oracle.com> <4A47DBAA.6000400@berkeley.edu> X-Mailer: Apple Mail (2.935.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Nikunj Mehta wrote: >> For the purposes of read-only usage, what we have with link >> relations is good enough for identifying semantics. You follow a >> link and issue a GET request and boom.. you get what you asked for. > > but how do you find a link? for atom and atompub, the link can be > identified because of the element/attribute, but links are only > findable because of the fixed media type. what i was suggesting (and > why i said it is a bit off-topic) was a generic way to discover > links in resources, regardless of the media type (my current > thinking is that this should work for all XML media types, or more > specifically, probably just those XML media types which are > namespace compliant). > > http://dret.typepad.com/dretblog/2009/06/link-discovery-for-xml.html I suspect that this is heading towards XLink. > >> The IANA link registry is a good enough place to hold this >> information, although it may be made even more easy to manage than >> to write to iana-assign for a new assignment. Whether that is a >> Wiki or something else, that could be discussed. > > i agree that IANA is good for the link relations, if people want to > standardize them (i would assume that the vast majority of RESTful > services don't want to register their link relations, though, and > they should not be required to do so). And certainly they are not required to do so. People that do not want to standardize relations can use URIs. >> Oracle is certainly interested in putting together some kind of >> adjectives on Atom resources so that we can better predict the kind >> of operations that can be performed. For example, the edit and edit- >> media relations actually mean something beyond other link relations >> because I can actually manipulate those resources. > > the above blog post is a very early draft. my current thinking is > that LDX should allow link discovery, and discovered links should be > described by an optional link relation, an optional URI template, an > optional media type, and optional methods. this way, RESTful > services could expose as much information as required about what to > expect when traversing links. Of these, the media type is already part of the link element. List of methods can be described as part of the semantics of the link relation. There was a talk about link-templates in the past to address URI templates. But given that, URI template is still is not solid, links with URI templates may have to wait a bit longer. Subbu From owner-atom-syntax@mail.imc.org Mon Jun 29 22:25:23 2009 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 E9FD43A6DC5 for ; Mon, 29 Jun 2009 22:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.607 X-Spam-Level: X-Spam-Status: No, score=-5.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9uHH5QkzjCr for ; Mon, 29 Jun 2009 22:25:22 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1BAB43A6D95 for ; Mon, 29 Jun 2009 22:25:21 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5U5IgHL058054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2009 22:18:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5U5Ig41058053; Mon, 29 Jun 2009 22:18:42 -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.ischool.berkeley.edu (bliss.ISchool.Berkeley.EDU [128.32.78.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5U5IVQW058040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Jun 2009 22:18:41 -0700 (MST) (envelope-from dret@berkeley.edu) Received: from [10.0.0.6] (75-101-1-224.dsl.dynamic.sonic.net [75.101.1.224]) (authenticated bits=0) by smtp.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id n5U5I6Jp000764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Jun 2009 22:18:06 -0700 Message-ID: <4A48AAA9.1020108@berkeley.edu> Date: Mon, 29 Jun 2009 13:51:05 +0200 From: Erik Wilde User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Atom-Syntax Subject: extension for update properties Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 128.32.78.13 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hello. i am sure this has already been discussed at some point in time, but i cannot remember seeing it, so i am asking this here: it might be useful to give a feed publisher some simple methods of making statements about a feed's update properties, such as a timestamp, a frequency, and some variation specification (maybe even a "maximum number of updates per time interval"). all of this would not be binding, but it might already help a client to adjust its feed polling strategy better than by observation alone. the update model should probably be simple and thus could probably be a simple extension with a small number of elements. would anybody be interested in such an extension? or are there already some "extensions" like this but they are not yet standardized? i am thinking about this in the context of the "web of things", where i want to provide access to a lot of real-world objects or events via feeds, and a substantial number of these feeds will have update models that could help clients to more effectively access the feed. thanks and cheers, erik wilde tel:+1-510-6432253 - fax:+1-510-6425814 dret@berkeley.edu - http://dret.net/netdret UC Berkeley - School of Information (ISchool) From mail@airi.de Tue Jun 30 11:31:27 2009 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 3056C3A6CCC for ; Tue, 30 Jun 2009 11:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.211 X-Spam-Level: X-Spam-Status: No, score=-91.211 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, SARE_WEOFFER=0.3, 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 eLa9HQxO2OyZ for ; Tue, 30 Jun 2009 11:31:27 -0700 (PDT) Received: from abril.com.br (unknown [186.136.156.136]) by core3.amsl.com (Postfix) with SMTP id C9CE03A67FF for ; Tue, 30 Jun 2009 11:31:24 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: Re: Secret Shopper [$950/week] From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090630183125.C9CE03A67FF@core3.amsl.com> Date: Tue, 30 Jun 2009 11:31:24 -0700 (PDT) Thank you for your interest in the Mystery Shopper position. Our company conducts surveys and evaluates other companies in order to help them achieve their performance goals. We offer an integrated suite of business solutions that enables corporations to achieve tangible results in the marketplace. We get hired by other companies and act like customers to find out how they are handling their services in relation to their customers. Mystery Shopping is the most accurate and reliable tool a business can use to gather information regarding their actual customer service performance at the moment of truth. This moment of truth is not when the staff is on their best behavior because the boss is around - it is when they interact with customers during their normal daily routines. This is where you, the Mystery Shopper, come in. You pose as an ordinary customer and provide feedback of both factual observations (ex...the floor was free of debris) and your own opinions (ex...I felt that the temperature in the establishment was too cold). Mystery Shoppers must remain anonymous. You must act as a regular customer and be careful not to do anything that would reveal you as a shopper. An inexperienced shopper could tip off the staff to his/her identity by asking for the manager's name for no clear or appropriate reason. If you are going to be bringing someone with you on the shop, make sure you educate them about the process as well. Beware that even whispers can be overheard by employees. If anyone notices you are a shopper, you can bet that word will quickly spread around the establishment and you will get some of the best customer service in town. No company can afford to have a gap between the promise of quality and its actual delivery, that's why leading corporations look to us, the nation's premiere mystery shopping and customer experience measurement company. In order for a business to effectively compete in today's economy, they must be prepared to meet the challenge of increasing sales by: * Retaining existing customers * Acquiring new customers * Creating word-of-mouth advocacy * Improving customer loyalty Once we have a contract to do so, you would be directed to the company or outlet, and you would be given the funds you need to do the job(either purchase merchandise or require services), after which you would write a detailed report of your experience. Examples of details you would forward to us are: 1) How long does it take to get served. 2) Politeness of the attendant. 3) Customer service professionalism. 4) Sometimes you might be required to upset the attendant, to see how they deal with difficult clients. Then we turn the information over to the company executives and they will carry out their own duties in improving their services. Most companies employ our assistance when people complain about their services, or when they feel there is a need for them to improve upon their customer service. Our company partners with you to implement proven mystery shop auditing and surveying strategies that provide critical information about customer experiences. You will be paid a commission of $100 for every duty you carry out, and bonus on your transportation allowance. Your task will be to evaluate and comment on customer service in a wide variety of restaurants, retail stores, casinos, shopping malls, banks and hotels in your area. Qualities of a good Mystery Shopper: * Is 21 years of age or older * Loves to go shopping * Is fair and objective * Is ON TIME * Is very observant and able to focus on details * Is fairly intelligent * Has patience * Is detail oriented * Is practical * Types well * Is trustworthy * Explains well in writing * Is discreet * Loves to learn * Handles deadlines * Has full internet access (at home or at work) Mystery Shopping is fun and exciting but also must be approached very seriously and is definitely not for everyone. If you are interested in applying for consideration as a Mystery Shopper do send in your information: Chase@mystery-ms.com Full Name: Address: City: State: Zip Code: Phone Number: Age: Occupation: As soon as we receive your information we will add you to our database and we will look for locations in your area that needs to be evaluated. Thank you, Chase McDowell WA Surveys 410 Roosevelt Way NE Seattle, WA 98105 From owner-atom-syntax@mail.imc.org Tue Jun 30 11:59:53 2009 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 6A19B3A68FE for ; Tue, 30 Jun 2009 11:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.086 X-Spam-Level: X-Spam-Status: No, score=-1.086 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_26=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 fQru6ZTFBLYj for ; Tue, 30 Jun 2009 11:59:52 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7DA793A698D for ; Tue, 30 Jun 2009 11:59:51 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5UIq50x022983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2009 11:52:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5UIq5iF022982; Tue, 30 Jun 2009 11:52:05 -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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.145]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5UIprI2022952 for ; Tue, 30 Jun 2009 11:52:03 -0700 (MST) (envelope-from pjkeane@gmail.com) Received: by qw-out-1920.google.com with SMTP id 4so180885qwk.28 for ; Tue, 30 Jun 2009 11:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=+mUTdi589GLpejqw2eSVD3xeHvIPuqHZ8Q4HcTbzTuY=; b=mWKi609STG8SmFl/uvT05aoReR9LJ0M1nLsjtEe2uiqBwWg5J8Nz6GG5tN19daJLs4 T1cPLG/3kKsQKWPqNZkNwr8AXrQJGJnHUQrJQSmCXeRn4/4qaGr8m8o0P0jqDVaJAC7V ++WHAJ2fmrYm2vTHTuB0nj2VguxMt7H1gfki4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=E67fpX882rejI5jqrYIPR9H/rbZgova3tAhV86K6spGxZ3xuhLopvRhPY1lsskUlTm JRPS+HBPRV3v6COumAbF7sa9NqGptw35qYTrvkEPdwNs+GobVZYp+/80p90yh62tXwI5 zSFQboN2JT9hcepYfgW8TjlydTpDm8MgRFXeo= MIME-Version: 1.0 Received: by 10.231.35.196 with SMTP id q4mr1517860ibd.49.1246387912759; Tue, 30 Jun 2009 11:51:52 -0700 (PDT) In-Reply-To: <13017DE6-0E2D-47CD-BC77-1A76B2A2C5FE@oracle.com> References: <20090629210841.1A5A028C2F6@core3.amsl.com> <13017DE6-0E2D-47CD-BC77-1A76B2A2C5FE@oracle.com> Date: Tue, 30 Jun 2009 13:51:52 -0500 X-Google-Sender-Auth: 9f3ba567e28c4a1b Message-ID: <8158ad750906301151l4d5628adiccd01f94cbc89264@mail.gmail.com> Subject: Re: New Version Notification for draft-mehta-atom-inline-01 From: Peter Keane To: "Nikunj R. Mehta" Cc: atom-syntax Syntax Content-Type: multipart/alternative; boundary=0022152d5cbdcadc88046d954ca1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0022152d5cbdcadc88046d954ca1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Nikunj- This looks good. I still have a sense, though, that the same pre-fetch capability could be achieved vi a a different mechanism. I have found it useful to provide an atom:link@rel=alternate that has a type attribute indicating atom *feed* (i.e., "here is the feed representation of this entry") that returns a feed -- (some what akin to mime multipart?) in which the entry in question is the first entry in the feed, and the pre-fetched entries are the remaining entries in the feed (they are siblings in the feed, but links or categories in each can express the implied hierarchy). I realize there is a need to say *which* links are pre-fetched, but that could be a function of either a custom @rel (instead of just "alternate") pointing to the feed OR query parameters (another can o' worms) that indicates which links will be prefetched. This may be unwise for reasons I am not seeing, but I've found it quite useful. (Not to mention one small side-effect: I can always ask for the "feed" version of an entry when I need to view it in Firefox, which typically will not display a plain atom:entry). --peter keane On Mon, Jun 29, 2009 at 5:31 PM, Nikunj R. Mehta wrote: > Sorry to have forgotten a link to the draft in the previous message. > > http://tools.ietf.org/html/draft-mehta-atom-inline > > On Jun 29, 2009, at 2:12 PM, Nikunj R. Mehta wrote: > > Revised version simplifies the content model of ae:inline to Atom entry and > feed documents. > 01 - Limited scope of in-lining to Atom. > Removed type attribute from ae:inline as well as support for non-Atom > in-lining. > Specified the interpretation of type attribute and the value > of ae:inline > Added example for empty inline element > > I hope this addresses the concern that we were creating a mighty complex > content model for ae:inline without use cases to guide us in the process. At > this point, I welcome any feedback of implementation experience you wish to > share. > > Thanks to all of you who provided feedback on the initial revision of the > I-D. > > Nikunj > http://o-micron.blogspot.com > > Begin forwarded message: > > *From: *IETF I-D Submission Tool > *Date: *June 29, 2009 2:08:41 PM PDT > *To: *nikunj.mehta@oracle.com > *Subject: **New Version Notification for draft-mehta-atom-inline-01 * > > > A new version of I-D, draft-mehta-atom-inline-01.txt has been successfuly > submitted by Nikunj Mehta and posted to the IETF repository. > > Filename: draft-mehta-atom-inline > Revision: 01 > Title: In-lining Extensions for Atom > Creation_date: 2009-06-29 > WG ID: Independent Submission > Number_of_pages: 8 > > Abstract: > This specification defines mechanisms for in-lining representations > of linked Atom resources.Editorial Note > > To provide feedback on this Internet-Draft, join the atom-syntax > mailing list (http://www.imc.org/atom-syntax/) [1]. > > > > The IETF Secretariat. > > > > > --0022152d5cbdcadc88046d954ca1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Nikunj- This looks good.=C2=A0 I still have a sense, though, that= the same pre-fetch capability could be achieved vi a a different mechanism= .=C2=A0 I have found it useful to provide an atom:link@rel=3Dalternate that= has a type attribute indicating atom *feed* (i.e., "here is the feed = representation of this entry") that returns a feed -- (some what akin = to mime multipart?) in which the entry in question is the first entry in th= e feed, and the pre-fetched entries are the remaining entries in the feed (= they are siblings in the feed, but links or categories in each can express = the implied hierarchy).=C2=A0=C2=A0 I realize there is a need to say *which= * links are pre-fetched, but that could be a function of either a custom @r= el (instead of just "alternate") pointing to the feed OR query pa= rameters (another can o' worms) that indicates which links will be pref= etched. This may be unwise for reasons I am not seeing, but I've found it q= uite useful.=C2=A0 (Not to mention one small side-effect: I can always ask = for the "feed" version of an entry when I need to view it in Fire= fox, which typically will not display a plain atom:entry). --peter keane On Mon, Jun 29,= 2009 at 5:31 PM, Nikunj R. Mehta <nikunj.mehta@oracle.com> wrote: Sorry to have forgotten a link t= o the draft in the previous message. http://tools= .ietf.org/html/draft-mehta-atom-inline On Jun 29, 2009, at 2:12 PM= , Nikunj R. Mehta wrote: Revised version simplifies the content model of ae:i= nline to Atom entry and feed documents. =C2=A0=C2=A0 01 - Limited scope of in-lining to Atom.=C2=A0=C2=A0 =C2=A0 =C2=A0Removed type attribute from ae:inline as= well as support for non-Atom in-lining. =C2=A0=C2=A0 =C2=A0 =C2= =A0Specified the interpretation of type attribute and the value of=C2=A0ae:= inline =C2=A0=C2=A0 =C2=A0 =C2=A0Added example for empty inline element= I hope this addresses the concern that we were creating= a mighty complex content model for ae:inline without use cases to guide us= in the process. At this point, I welcome any feedback of implementation ex= perience you wish to share. Thanks to all of you who provided feedback on the initi= al revision of the I-D. Nikunj http://o-micron.blogspot.com Begin forwarded message= : From: IETF I-D Submission Tool <idsubmission@ietf.org><= /font> Date: June= 29, 2009 2:08:41 PM PDT To: nikunj.mehta@oracle.= com Subject: = <= b>New Version Notification for draft-mehta-atom-inline-01=C2=A0 A n= ew version of I-D, draft-mehta-atom-inline-01.txt has been successfuly subm= itted by Nikunj Mehta and posted to the IETF repository. Filename: draft-mehta-atom-inline Revision: 01 Title: I= n-lining Extensions for Atom Creation_date: 2009-06-29 WG ID: Independent Submission Number_of_pages: 8 Abstrac= t: This specification defines mechanisms for in-lining representations of linked Atom resources.Editorial Note To provide feedback on this = Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1]. The IETF Secretariat. <= /div> --0022152d5cbdcadc88046d954ca1-- From owner-atom-syntax@mail.imc.org Tue Jun 30 12:03:04 2009 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 A30B03A6EA2 for ; Tue, 30 Jun 2009 12:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bcm6GerrlIse for ; Tue, 30 Jun 2009 12:03:03 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 42A913A68FE for ; Tue, 30 Jun 2009 12:03:03 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5UIuQZw023278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2009 11:56:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5UIuQZH023276; Tue, 30 Jun 2009 11:56:26 -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.ischool.berkeley.edu (bliss.ISchool.Berkeley.EDU [128.32.78.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5UIuFCG023259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2009 11:56:25 -0700 (MST) (envelope-from dret@berkeley.edu) Received: from [10.0.0.4] (75-101-1-224.dsl.dynamic.sonic.net [75.101.1.224]) (authenticated bits=0) by smtp.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id n5UIuDcJ016811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Jun 2009 11:56:14 -0700 Message-ID: <4A4A5FDD.7040602@berkeley.edu> Date: Tue, 30 Jun 2009 11:56:29 -0700 From: Erik Wilde User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: atom-protocol Protocol , Atom-Syntax CC: Subbu Allamaraju , Nikunj Mehta Subject: Re: link relations and links in general References: <4A0C6067.5090407@berkeley.edu> <912123FB-7158-44AE-B141-1CEA9F068744@oracle.com> <4A47DBAA.6000400@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 128.32.78.13 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hello subbu. Subbu Allamaraju wrote: >> http://dret.typepad.com/dretblog/2009/06/link-discovery-for-xml.html > I suspect that this is heading towards XLink. not really. the important difference is that XLink links instances (it specifies links for concrete URIs), whereas LDX specifies how to discover links in media types. i think this is an important difference, and my post definitely failed to be very specific about this. the reason why i think it's important is that REST centers around media types and following links, and LDX should be a god match with that. >> i agree that IANA is good for the link relations, if people want to >> standardize them (i would assume that the vast majority of RESTful >> services don't want to register their link relations, though, and they >> should not be required to do so). > And certainly they are not required to do so. People that do not want to > standardize relations can use URIs. so is the namespace for link relations strings (standardized) and URIs? what about CURIEs? and how could i distinguish between a CURIE and a string with a colon? and do some link relation definitions use QNames? i am still wondering what "datatype" a link relation should have, or what people are already using somewhere. cheers, dret. From jhumnih@aitlbd.net Tue Jun 30 14:10:46 2009 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 C0C023A6CB4 for ; Tue, 30 Jun 2009 14:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -73.7 X-Spam-Level: X-Spam-Status: No, score=-73.7 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_WEOFFER=0.3, TVD_RCVD_IP=1.931, 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 cKEz2EgkeNbU for ; Tue, 30 Jun 2009 14:10:45 -0700 (PDT) Received: from 200-219-75-19.ggs6102.3g.brasiltelecom.net.br (200-219-75-19.ggs6102.3g.brasiltelecom.net.br [200.219.75.19]) by core3.amsl.com (Postfix) with SMTP id C062C3A6869 for ; Tue, 30 Jun 2009 14:10:40 -0700 (PDT) To: atompub-archive@megatron.ietf.org Subject: Re: Mystery/Shopper [$800/week] From: atompub-archive@megatron.ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090630211042.C062C3A6869@core3.amsl.com> Date: Tue, 30 Jun 2009 14:10:40 -0700 (PDT) Thank you for your interest in the Mystery Shopper position. Our company conducts surveys and evaluates other companies in order to help them achieve their performance goals. We offer an integrated suite of business solutions that enables corporations to achieve tangible results in the marketplace. We get hired by other companies and act like customers to find out how they are handling their services in relation to their customers. Mystery Shopping is the most accurate and reliable tool a business can use to gather information regarding their actual customer service performance at the moment of truth. This moment of truth is not when the staff is on their best behavior because the boss is around - it is when they interact with customers during their normal daily routines. This is where you, the Mystery Shopper, come in. You pose as an ordinary customer and provide feedback of both factual observations (ex...the floor was free of debris) and your own opinions (ex...I felt that the temperature in the establishment was too cold). Mystery Shoppers must remain anonymous. You must act as a regular customer and be careful not to do anything that would reveal you as a shopper. An inexperienced shopper could tip off the staff to his/her identity by asking for the manager's name for no clear or appropriate reason. If you are going to be bringing someone with you on the shop, make sure you educate them about the process as well. Beware that even whispers can be overheard by employees. If anyone notices you are a shopper, you can bet that word will quickly spread around the establishment and you will get some of the best customer service in town. No company can afford to have a gap between the promise of quality and its actual delivery, that's why leading corporations look to us, the nation's premiere mystery shopping and customer experience measurement company. In order for a business to effectively compete in today's economy, they must be prepared to meet the challenge of increasing sales by: * Retaining existing customers * Acquiring new customers * Creating word-of-mouth advocacy * Improving customer loyalty Once we have a contract to do so, you would be directed to the company or outlet, and you would be given the funds you need to do the job(either purchase merchandise or require services), after which you would write a detailed report of your experience. Examples of details you would forward to us are: 1) How long does it take to get served. 2) Politeness of the attendant. 3) Customer service professionalism. 4) Sometimes you might be required to upset the attendant, to see how they deal with difficult clients. Then we turn the information over to the company executives and they will carry out their own duties in improving their services. Most companies employ our assistance when people complain about their services, or when they feel there is a need for them to improve upon their customer service. Our company partners with you to implement proven mystery shop auditing and surveying strategies that provide critical information about customer experiences. You will be paid a commission of $100 for every duty you carry out, and bonus on your transportation allowance. Your task will be to evaluate and comment on customer service in a wide variety of restaurants, retail stores, casinos, shopping malls, banks and hotels in your area. Qualities of a good Mystery Shopper: * Is 21 years of age or older * Loves to go shopping * Is fair and objective * Is ON TIME * Is very observant and able to focus on details * Is fairly intelligent * Has patience * Is detail oriented * Is practical * Types well * Is trustworthy * Explains well in writing * Is discreet * Loves to learn * Handles deadlines * Has full internet access (at home or at work) Mystery Shopping is fun and exciting but also must be approached very seriously and is definitely not for everyone. If you are interested in applying for consideration as a Mystery Shopper do send in your information: Mohamed@mystery-ms.com Full Name: Address: City: State: Zip Code: Phone Number: Age: Occupation: As soon as we receive your information we will add you to our database and we will look for locations in your area that needs to be evaluated. Thank you, Mohamed McDowell WA Surveys 410 Roosevelt Way NE Seattle, WA 98105 From owner-atom-syntax@mail.imc.org Tue Jun 30 20:09:36 2009 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 380983A6A57 for ; Tue, 30 Jun 2009 20:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] 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 raUaygkcZokk for ; Tue, 30 Jun 2009 20:09:35 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E7D1B3A68D3 for ; Tue, 30 Jun 2009 20:09:34 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6130U9Z052045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2009 20:00:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6130USU052044; Tue, 30 Jun 2009 20:00: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 mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6130Irk052032 for ; Tue, 30 Jun 2009 20:00:29 -0700 (MST) (envelope-from lisa.dusseault@gmail.com) Received: by vwj27 with SMTP id 27so215750vwj.16 for ; Tue, 30 Jun 2009 20:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ITaKd1kYWSMNfEGmK7pwSKWUFDOEFmwmKyi7Q8+Uyic=; b=EzH0v0AsUXgKlxE+AjFVlGQiWZ0z3MOhMXi8SY+AFIa+QJBcakBwHqs5BDATovkOOa qNakkz881JwWwTbAWWSSx2nZe43twUwg5m+c5dZT29ToTJCKAJ6PpJwCnEO1EGJznScu rv6Hnp7Ee9Q/EnSuDGO5KVQXlupKOik9qS6AY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Qk4K7Tm0em/+q03xmz/sVu5pe9+eF4ozqtQTa/Woi/Yk9knCuBvjGOh7GqKpr70shc ie2PRVWpx3rgGV5ZYQASIjYLaka6fpjkSO6zML1eXIsz0KdZ2vK2e94w3V6bLHYaJWw8 Ty7YnDrkEUNnyvhtwd6MxuG2hITxwyslizSkQ= MIME-Version: 1.0 Received: by 10.220.71.6 with SMTP id f6mr7876782vcj.99.1246417217798; Tue, 30 Jun 2009 20:00:17 -0700 (PDT) In-Reply-To: <4A43A6D0.3030306@oracle.com> References: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> <4A3A51AC.2010703@oracle.com> <4A43A6D0.3030306@oracle.com> Date: Tue, 30 Jun 2009 20:00:17 -0700 Message-ID: Subject: Re: Talking about Atom in Stockholm From: Lisa Dusseault To: Colm Divilly Cc: Mark Nottingham , Atom-Syntax Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Typically a bunch of people who don't necessarily follow the mailing list closely but are at an IETF anyway, will come to a BOF or bar BOF and may participate afterward. It helps to send announcements out to ietf@ietf.org, discuss@ietf.org (the Apps Discuss list) and developer or other related lists. And I'll be there. :) Lisa On Thu, Jun 25, 2009 at 9:33 AM, Colm Divilly wrot= e: > > Anyone else on for this ? > > By my count we have seven people that might be able to make it. > Mark do you want to suggest a day and time (location can be worked out > later) ? > > I would intend to fly in for the Bar BoF and fly back out next day. > > Regards, > Colm Divilly > > Colm Divilly wrote: >> >> I'd be interested in attending, especially if we're going to cover AtomP= ub >> as well. >> >> Regards, >> Colm Divilly >> >> Mark Nottingham wrote: >>> >>> There seems to be a lot of new discussion around Atom recently. Who's u= p >>> for a Bar BoF in Stockholm? >>> >>> -- >>> Mark Nottingham =A0 =A0 http://www.mnot.net/ >>> >> > > From owner-atom-syntax@mail.imc.org Tue Jun 30 20:17:18 2009 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 2ADCE3A6B4F for ; Tue, 30 Jun 2009 20:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MLH_Stock1=0.87] 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 iRMhCbAoqwj7 for ; Tue, 30 Jun 2009 20:17:17 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C7DF73A68D3 for ; Tue, 30 Jun 2009 20:17:16 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n613A9WV052554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2009 20:10:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n613A94S052553; Tue, 30 Jun 2009 20:10: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 mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6139vli052522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Jun 2009 20:10:08 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [120.19.174.70] (unknown [120.19.174.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 45FF323E3E1; Tue, 30 Jun 2009 23:09:56 -0400 (EDT) References: <0A8DDE61-62C5-43EB-8DBC-D3F4D63E2A89@mnot.net> <4A3A51AC.2010703@oracle.com> <4A43A6D0.3030306@oracle.com> Message-Id: <4733B55F-5D7F-4D12-83AA-E0FA216814F8@mnot.net> From: Mark Nottingham To: Lisa Dusseault In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A341) Mime-Version: 1.0 (iPhone Mail 7A341) Subject: Re: Talking about Atom in Stockholm Date: Wed, 1 Jul 2009 13:09:35 +1000 Cc: Colm Divilly , Atom-Syntax Syntax Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At the moment Im thinking about Wednesday night, provided that it doesn't clash with the iri bar bof ( we've talked about Thursday pm for that, but not yet confirmed). Assuming it doesn't, does that work for people? As far as venue, my only observation is that it will be light until after 9, and it seems a pity to waste daylight in such a beautiful city. How do people feel about an outdoor meeting - eg a park or restaurant? Mark Nottingham On 01/07/2009, at 1:00 PM, Lisa Dusseault wrote: > Typically a bunch of people who don't necessarily follow the mailing > list closely but are at an IETF anyway, will come to a BOF or bar BOF > and may participate afterward. It helps to send announcements out to > ietf@ietf.org, discuss@ietf.org (the Apps Discuss list) and developer > or other related lists. > > And I'll be there. :) > > Lisa > > On Thu, Jun 25, 2009 at 9:33 AM, Colm > Divilly wrote: >> >> Anyone else on for this ? >> >> By my count we have seven people that might be able to make it. >> Mark do you want to suggest a day and time (location can be worked >> out >> later) ? >> >> I would intend to fly in for the Bar BoF and fly back out next day. >> >> Regards, >> Colm Divilly >> >> Colm Divilly wrote: >>> >>> I'd be interested in attending, especially if we're going to cover >>> AtomPub >>> as well. >>> >>> Regards, >>> Colm Divilly >>> >>> Mark Nottingham wrote: >>>> >>>> There seems to be a lot of new discussion around Atom recently. >>>> Who's up >>>> for a Bar BoF in Stockholm? >>>> >>>> -- >>>> Mark Nottingham http://www.mnot.net/ >>>> >>> >> >> From owner-atom-syntax@mail.imc.org Tue Jun 30 22:59:36 2009 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 7466F28C128 for ; Tue, 30 Jun 2009 22:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNllqPw0tqmT for ; Tue, 30 Jun 2009 22:59:35 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C98F528C101 for ; Tue, 30 Jun 2009 22:58:45 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n615pNJs062619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2009 22:51:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n615pMG5062617; Tue, 30 Jun 2009 22:51: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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.150]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n615pAmt062598; Tue, 30 Jun 2009 22:51:21 -0700 (MST) (envelope-from subbu@subbu.org) Received: by qw-out-1920.google.com with SMTP id 4so422148qwk.28 for ; Tue, 30 Jun 2009 22:51:10 -0700 (PDT) Received: by 10.224.54.66 with SMTP id p2mr7933024qag.266.1246427470349; Tue, 30 Jun 2009 22:51:10 -0700 (PDT) Received: from ?10.71.0.119? (ip67-95-215-2.z215-95-67.customer.algx.net [67.95.215.2]) by mx.google.com with ESMTPS id 6sm1830552qwk.44.2009.06.30.22.51.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Jun 2009 22:51:09 -0700 (PDT) Cc: atom-protocol Protocol , Atom-Syntax , Nikunj Mehta Message-Id: From: Subbu Allamaraju To: Erik Wilde In-Reply-To: <4A4A5FDD.7040602@berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: link relations and links in general Date: Tue, 30 Jun 2009 22:51:34 -0700 References: <4A0C6067.5090407@berkeley.edu> <912123FB-7158-44AE-B141-1CEA9F068744@oracle.com> <4A47DBAA.6000400@berkeley.edu> <4A4A5FDD.7040602@berkeley.edu> X-Mailer: Apple Mail (2.935.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 30, 2009, at 11:56 AM, Erik Wilde wrote: > hello subbu. > > Subbu Allamaraju wrote: >>> http://dret.typepad.com/dretblog/2009/06/link-discovery-for-xml.html >> I suspect that this is heading towards XLink. > > not really. the important difference is that XLink links instances > (it specifies links for concrete URIs), whereas LDX specifies how to > discover links in media types. i think this is an important > difference, and my post definitely failed to be very specific about > this. the reason why i think it's important is that REST centers > around media types and following links, and LDX should be a god > match with that. Ah I see. Just read your post again. I don't think link discovery on its own solves anything, unless the author of the representation or the media type says something about a link appearing at any given position an an XML document. Subbu

From:	= "Nikunj R. Mehta" <nikunj.mehta@oracle.co= m>
To:	Julian Reschke <julian.reschke@gmx.de>
Cc:	Atom-Syntax Syntax <atom-syntax@imc.org><= /td>
Date:	= 05/28/2009 12:32 PM
Subject:	Re: New Version Notification for draft-divilly-atom-hi= erarchy-00

<ecblank.gif> From:	<ecblank.gif> "Nikunj = R. Mehta" <nikunj.mehta@oracle.com>
<ecblank.gif> To:	<ecblank.gif> Julian = Reschke <julian.reschke@gmx.de>
<ecblank.gif> Cc:	<ecblank.gif> Atom-Syntax Syntax <atom-syntax@imc.org>
<ecblank.gif> = Date:	<ecblank.gif> 05/28/2009 12:32 PM
<ecblank.gif> Subject:	<ecblank.gif> Re: = New Version Notification for = draft-divilly-atom-hierarchy-00

From:	= Peter Keane <pkeane@mail.utexas.edu>
To:	Al Brown/Costa Mesa/IBM@IBMUS
Cc:	"Nikunj R. Mehta" <nikunj.mehta@oracle.co= m>, Atom-Syntax Syntax <atom-syntax@imc.org>, Julian Reschke &= lt;julian.reschke@gmx.de>, owner-atom-syntax@mail.imc.org, Sam Ruby/= Raleigh/IBM@IBMUS, James M Snell/Fresno/IBM@IBMUS
Date:	= 06/02/2009 01:35 PM
Subject:	Re: Recap - call for preferences/discussion - Re: New = Version Notification for draft-divilly-atom-hierarchy-00

From:	= Bill de hOra <bill@dehora.net>
To:	Al Brown/Costa Mesa/IBM@IBMUS
Cc:	Peter Keane <pkeane@mail.utexas.edu>, Atom-Synta= x Syntax <atom-syntax@imc.org>, James M Snell/Fresno/IBM@IBMUS, J= ulian Reschke <julian.reschke@gmx.de>, "Nikunj R. Mehta"= ; <nikunj.mehta@oracle.com>, owner-atom-syntax@mail.imc.org, pjke= ane@gmail.com, Sam Ruby/Raleigh/IBM@IBMUS
Date:	= 06/02/2009 03:18 PM
Subject:	Re: CMIS Folders & categories

From:	= Pablo Castro <Pablo.Castro@microsoft.com>=
To:	"Nikunj R. Mehta" <nikunj.mehta@oracle.co= m>, Mark Nottingham <mnot@mnot.net>
Cc:	Julian Reschke <julian.reschke@gmx.de>, Atom-Syn= tax Syntax <atom-syntax@imc.org>
Date:	= 06/03/2009 03:55 PM
Subject:	RE: New Version Notification for draft-divilly-atom-hi= erarchy-00

<ecblank.gif&g= t; From:	<ecblank.gif>= "Nikunj R. Mehta" <nikunj.mehta@oracle.com&g= t;
<ecblank.gif&g= t; To:	<ecblank.gif> Atom-Syntax Syntax <atom-syntax@imc.org>
<ecblank.gif&g= t; Date:	<ecblank.gif>= 06/05/2009 11:18 AM
<ecblank.gif&g= t; Subject:	<ecblank.gif&= gt; Fwd: New Version Notification for draft-divilly-atom-hierarchy-01

From:	= James M Snell <jasnell@gmail.com>
To:	Al Brown/Costa Mesa/IBM@IBMUS
Cc:	"Nikunj R. Mehta" <nikunj.mehta@oracle.co= m>, Atom-Syntax Syntax <atom-syntax@imc.org>, owner-atom-synta= x@mail.imc.org
Date:	= 06/08/2009 11:55 AM
Subject:	Re: Fwd: New Version Notification for draft-divilly-at= om-hierarchy-01

<ecblank.gif> From:	<ecblank.gif> James= M Snell <jasnell@gmail.com>
<ecblank.gif> To:	<ecblank.gif> Al = Brown/Costa Mesa/IBM@IBMUS
<ecblank.gif> Cc:	<ecblank.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.com>, = Atom-Syntax Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.= org
<ecblank.gif> Date:	<ecblank.gif> 06/08/2009 11:55 AM
<ecblank.gif> Subject:	<ecblank.gif> Re: = Fwd: New Version Notification for = draft-divilly-atom-hierarchy-01

<ecblank.gif&g= t; From:	<ecblank.gif>= James M Snell <jasnell@gmail.com>
<ecblank.gif&g= t; To:	<ecblank.gif> Al Brown/Costa Mesa/IBM@IBMUS
<ecblank.gif&g= t; Cc:	<= ;ecblank.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.com&g= t;, Atom-Syntax Syntax <atom-syntax@imc.org>, owne= r-atom-syntax@mail.imc.org
<ecblank.gif&g= t; Date:	<ecblank.gif>= 06/08/2009 11:55 AM
<ecblank.gif&g= t; Subject:	<ecblank.gif&= gt; Re: Fwd: New Version Notification for draft-divilly-atom-hierarchy-01

From:	= James M Snell <jasnell@gmail.com>
To:	atom-syntax <atom-syntax@imc.org>
Date:	= 06/08/2009 03:36 PM
Subject:	Atompub Features Draft Dead for Good?

<ecblank.gif> = From:	<ecblank.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
<ecblank.gif> To:	<ecblank.gif> Al = Brown/Costa Mesa/IBM@IBMUS
<ecblank.gif> Cc:	<ecblank.gif> James M Snell <jasnell@gmail.com>, atom-syntax = Syntax <atom-syntax@imc.org>
<ecblank.gif> Date:	<ecblank.gif> 06/08/2009 03:33 PM
<ecblank.gif> Subject:	<ecblank.gif> Re: = New Version Notification for = draft-divilly-atom-hierarchy-01

<ecblank.gif> From:	<ecblank.gif> James M Snell <jasnell@gmail.com>
<ecblank.gif> = To:	<ecblank.gif> Al Brown/Costa = Mesa/IBM@IBMUS
<ecblank.gif> = Cc:	<ecblank.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.com>, = Atom-Syntax Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org
<ecblank.gif> = Date:	<ecblank.gif> 06/08/2009 11:55 AM
<ecblank.gif> = Subject:	<ecblank.gif> Re: Fwd: New Version = Notification for draft-divilly-atom-hierarchy-01

From:	= jasnell@gmail.com
To:	Al Brown/Costa Mesa/IBM@IBMUS
Cc:	"atom-syntax" <atom-syntax@imc.org>, o= wner-atom-syntax@mail.imc.org
Date:	= 06/08/2009 04:36 PM
Subject:	Re: Atompub Features Draft Dead for Good?

From:	James M Snell <jasnell@gmail.com>
To:	atom-syntax <atom-syntax@imc.org>
Date:	06/08/2009 03:36 PM
Subject:	Atompub Features Draft Dead for Good?