From myronhilliard@1-800-psychic.com Sun May 2 05:00:05 2010 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 490CA3A67A7 for ; Sun, 2 May 2010 05:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.726 X-Spam-Level: X-Spam-Status: No, score=-2.726 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, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, 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, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FORGED_AMAZON=3, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, 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 3nd1s0c0hxty for ; Sun, 2 May 2010 04:59:52 -0700 (PDT) Received: from pool-98-117-211-77.bltmmd.fios.verizon.net (pool-98-117-211-77.bltmmd.fios.verizon.net [98.117.211.77]) by core3.amsl.com (Postfix) with SMTP id B7C353A68F0 for ; Sun, 2 May 2010 04:59:51 -0700 (PDT) From: "Amazon.com Email Subscriptions" To: "atompub-archive@megatron.ietf.org" Subject: Amazon.com Deal of the Day X-AMAZON-MAIL-RELAY-TYPE: subscription X-AMAZON-RTE-VERSION: 2.0 MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100502115951.B7C353A68F0@core3.amsl.com> Date: Sun, 2 May 2010 04:59:51 -0700 (PDT)
Please click here if the e-mail below is not displayed correctly.
amazon.com
Free Two-Day Shipping with   › Amazon Prime
Your Amazon.com Today's Deals See All Departments
Tiffen Dfx Digital Filter Software V2
$149.95 $79.99 (47% off)
4.28571428571429
This Tiffen Dfx digital filter suite is a powerful but user-friendly stand alone application for still images. It offers a definitive set of digital optical filters, including simulations of many popular award-winning Tiffen glass filters, specialized lenses, optical lab processes, film grain, exacting color correction plus natural light and photographic effects, all in a controlled digital environment. Whether you are an amateur or professional photographer, a video or film editor, or graphic designer, Dfx's visual workflow and easy to use tools will help you create stunning images. Windows XP, Vista or Macintosh v10.4.6 and higher required for use.
Explore Other Great Gold Box Deals
Save $20 on Adobe Photoshop Elements 8
Great gift for Mom! Dbest Quick Cart
Lunar: Silver Star Harmony Limited Edition for $25.98
100 Albums for $5 Each
Save $20 on Adobe Photoshop Elements 8
$99.99 $59.99 (40% off)
 
 
Great gift for Mom! Dbest Quick Cart
$34.95 $29.99 (14% off)
 
 
Lunar: Silver Star Harmony Limited Edition for $25.98
$39.99 $25.98 (35% off)
 
 
100 Albums for $5 Each
 
Save up to $500 off the combined purchase of select Canon cameras and printers
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
Save $10 on "Alice in Wonderland Combo Pack"
Save up to 40% on Our Bestselling Fitness Products
Save up to $500 off the combined purchase of select Canon cameras and printers
 
 
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
 
 
Save $10 on "Alice in Wonderland Combo Pack"
 
 
Save up to 40% on Our Bestselling Fitness Products
 


This message was sent to the following e-mail address: atompub-archive@megatron.ietf.org

You're receiving this e-mail because you subscribed to Gold Box Deals. If you do not want any more e-mails of this kind, it's easy to unsubscribe.

Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit Amazon.com. The List Price represents the full retail price listed on the product itself, suggested by the manufacturer or supplier, or estimated in accordance with standard industry practice. For items offered as a set, List Price may represent open-stock prices.

© 2010 Amazon.com. All rights reserved.
Amazon.com is a registered trademark of Amazon.com, Inc.
Amazon.com, 1200 12th Ave. S., Suite 1200, Seattle, WA 98144-2734.
Reference: 15067840
From lucinha@agora.com.br Sun May 2 16:38:27 2010 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 653603A67E9 for ; Sun, 2 May 2010 16:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.812 X-Spam-Level: X-Spam-Status: No, score=-7.812 tagged_above=-999 required=5 tests=[AWL=-8.814, 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, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, 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, SARE_FORGED_AMAZON=3, 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_PH_SURBL=1.787, 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 8zPShtlhOEta for ; Sun, 2 May 2010 16:38:16 -0700 (PDT) Received: from 35-82-113-92.pool.ukrtel.net (140-123-113-92.pool.ukrtel.net [92.113.123.140]) by core3.amsl.com (Postfix) with SMTP id C86D63A68CE for ; Sun, 2 May 2010 16:38:08 -0700 (PDT) From: "Amazon.com Email Subscriptions" To: "atompub-archive@megatron.ietf.org" Subject: Amazon.com Deal of the Day X-AMAZON-MAIL-RELAY-TYPE: subscription X-AMAZON-RTE-VERSION: 2.0 MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100502233811.C86D63A68CE@core3.amsl.com> Date: Sun, 2 May 2010 16:38:08 -0700 (PDT)
Please click here if the e-mail below is not displayed correctly.
amazon.com
Free Two-Day Shipping with   › Amazon Prime
Your Amazon.com Today's Deals See All Departments
Tiffen Dfx Digital Filter Software V2
$149.95 $79.99 (47% off)
4.28571428571429
This Tiffen Dfx digital filter suite is a powerful but user-friendly stand alone application for still images. It offers a definitive set of digital optical filters, including simulations of many popular award-winning Tiffen glass filters, specialized lenses, optical lab processes, film grain, exacting color correction plus natural light and photographic effects, all in a controlled digital environment. Whether you are an amateur or professional photographer, a video or film editor, or graphic designer, Dfx's visual workflow and easy to use tools will help you create stunning images. Windows XP, Vista or Macintosh v10.4.6 and higher required for use.
Explore Other Great Gold Box Deals
Save $20 on Adobe Photoshop Elements 8
Great gift for Mom! Dbest Quick Cart
Lunar: Silver Star Harmony Limited Edition for $25.98
100 Albums for $5 Each
Save $20 on Adobe Photoshop Elements 8
$99.99 $59.99 (40% off)
 
 
Great gift for Mom! Dbest Quick Cart
$34.95 $29.99 (14% off)
 
 
Lunar: Silver Star Harmony Limited Edition for $25.98
$39.99 $25.98 (35% off)
 
 
100 Albums for $5 Each
 
Save up to $500 off the combined purchase of select Canon cameras and printers
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
Save $10 on "Alice in Wonderland Combo Pack"
Save up to 40% on Our Bestselling Fitness Products
Save up to $500 off the combined purchase of select Canon cameras and printers
 
 
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
 
 
Save $10 on "Alice in Wonderland Combo Pack"
 
 
Save up to 40% on Our Bestselling Fitness Products
 


This message was sent to the following e-mail address: atompub-archive@megatron.ietf.org

You're receiving this e-mail because you subscribed to Gold Box Deals. If you do not want any more e-mails of this kind, it's easy to unsubscribe.

Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit Amazon.com. The List Price represents the full retail price listed on the product itself, suggested by the manufacturer or supplier, or estimated in accordance with standard industry practice. For items offered as a set, List Price may represent open-stock prices.

© 2010 Amazon.com. All rights reserved.
Amazon.com is a registered trademark of Amazon.com, Inc.
Amazon.com, 1200 12th Ave. S., Suite 1200, Seattle, WA 98144-2734.
Reference: 15067840
From office@aldebaran-at.net Sun May 2 23:38:27 2010 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 C4DBC3A690B for ; Sun, 2 May 2010 23:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.548 X-Spam-Level: X-Spam-Status: No, score=-11.548 tagged_above=-999 required=5 tests=[AWL=-6.061, 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, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, 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_DYNAMIC=0.1, SARE_FORGED_AMAZON=3, 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_PH_SURBL=1.787, 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 upuRsgh96WB6 for ; Sun, 2 May 2010 23:38:17 -0700 (PDT) Received: from 197-197-93-178.pool.ukrtel.net (197-197-93-178.pool.ukrtel.net [178.93.197.197]) by core3.amsl.com (Postfix) with SMTP id F28FF3A68EA for ; Sun, 2 May 2010 23:38:12 -0700 (PDT) From: "Amazon.com Email Subscriptions" To: "atompub-archive@megatron.ietf.org" Subject: Amazon.com Deal of the Day X-AMAZON-MAIL-RELAY-TYPE: subscription X-AMAZON-RTE-VERSION: 2.0 MIME-Version: 1.0 Content-Type: text/html X-Antivirus: avast! (VPS 100502-1, 02.05.2010), Outbound message X-Antivirus-Status: Clean Message-Id: <20100503063812.F28FF3A68EA@core3.amsl.com> Date: Sun, 2 May 2010 23:38:12 -0700 (PDT)
Please click here if the e-mail below is not displayed correctly.
amazon.com
Free Two-Day Shipping with   › Amazon Prime
Your Amazon.com Today's Deals See All Departments
Tiffen Dfx Digital Filter Software V2
$149.95 $79.99 (47% off)
4.28571428571429
This Tiffen Dfx digital filter suite is a powerful but user-friendly stand alone application for still images. It offers a definitive set of digital optical filters, including simulations of many popular award-winning Tiffen glass filters, specialized lenses, optical lab processes, film grain, exacting color correction plus natural light and photographic effects, all in a controlled digital environment. Whether you are an amateur or professional photographer, a video or film editor, or graphic designer, Dfx's visual workflow and easy to use tools will help you create stunning images. Windows XP, Vista or Macintosh v10.4.6 and higher required for use.
Explore Other Great Gold Box Deals
Save $20 on Adobe Photoshop Elements 8
Great gift for Mom! Dbest Quick Cart
Lunar: Silver Star Harmony Limited Edition for $25.98
100 Albums for $5 Each
Save $20 on Adobe Photoshop Elements 8
$99.99 $59.99 (40% off)
 
 
Great gift for Mom! Dbest Quick Cart
$34.95 $29.99 (14% off)
 
 
Lunar: Silver Star Harmony Limited Edition for $25.98
$39.99 $25.98 (35% off)
 
 
100 Albums for $5 Each
 
Save up to $500 off the combined purchase of select Canon cameras and printers
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
Save $10 on "Alice in Wonderland Combo Pack"
Save up to 40% on Our Bestselling Fitness Products
Save up to $500 off the combined purchase of select Canon cameras and printers
 
 
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
 
 
Save $10 on "Alice in Wonderland Combo Pack"
 
 
Save up to 40% on Our Bestselling Fitness Products
 


This message was sent to the following e-mail address: atompub-archive@megatron.ietf.org

You're receiving this e-mail because you subscribed to Gold Box Deals. If you do not want any more e-mails of this kind, it's easy to unsubscribe.

Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit Amazon.com. The List Price represents the full retail price listed on the product itself, suggested by the manufacturer or supplier, or estimated in accordance with standard industry practice. For items offered as a set, List Price may represent open-stock prices.

© 2010 Amazon.com. All rights reserved.
Amazon.com is a registered trademark of Amazon.com, Inc.
Amazon.com, 1200 12th Ave. S., Suite 1200, Seattle, WA 98144-2734.
Reference: 15067840
From mughnk@aamuri.aamu.edu Mon May 3 10:18:47 2010 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 55D6728C22D for ; Mon, 3 May 2010 10:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.47 X-Spam-Level: X-Spam-Status: No, score=-7.47 tagged_above=-999 required=5 tests=[AWL=-7.595, 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, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, 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_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FORGED_AMAZON=3, 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_PH_SURBL=1.787, 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 GNdXBzEKSa0c for ; Mon, 3 May 2010 10:18:39 -0700 (PDT) Received: from 35-201-133-95.pool.ukrtel.net (57-31-133-95.pool.ukrtel.net [95.133.31.57]) by core3.amsl.com (Postfix) with SMTP id 7A4C43A6A64 for ; Mon, 3 May 2010 10:18:17 -0700 (PDT) From: "Amazon.com Email Subscriptions" To: "atompub-archive@megatron.ietf.org" Subject: Amazon.com Deal of the Day X-AMAZON-MAIL-RELAY-TYPE: subscription X-AMAZON-RTE-VERSION: 2.0 MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100503171818.7A4C43A6A64@core3.amsl.com> Date: Mon, 3 May 2010 10:18:17 -0700 (PDT)
Please click here if the e-mail below is not displayed correctly.
amazon.com
Free Two-Day Shipping with   › Amazon Prime
Your Amazon.com Today's Deals See All Departments
Tiffen Dfx Digital Filter Software V2
$149.95 $79.99 (47% off)
4.28571428571429
This Tiffen Dfx digital filter suite is a powerful but user-friendly stand alone application for still images. It offers a definitive set of digital optical filters, including simulations of many popular award-winning Tiffen glass filters, specialized lenses, optical lab processes, film grain, exacting color correction plus natural light and photographic effects, all in a controlled digital environment. Whether you are an amateur or professional photographer, a video or film editor, or graphic designer, Dfx's visual workflow and easy to use tools will help you create stunning images. Windows XP, Vista or Macintosh v10.4.6 and higher required for use.
Explore Other Great Gold Box Deals
Save $20 on Adobe Photoshop Elements 8
Great gift for Mom! Dbest Quick Cart
Lunar: Silver Star Harmony Limited Edition for $25.98
100 Albums for $5 Each
Save $20 on Adobe Photoshop Elements 8
$99.99 $59.99 (40% off)
 
 
Great gift for Mom! Dbest Quick Cart
$34.95 $29.99 (14% off)
 
 
Lunar: Silver Star Harmony Limited Edition for $25.98
$39.99 $25.98 (35% off)
 
 
100 Albums for $5 Each
 
Save up to $500 off the combined purchase of select Canon cameras and printers
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
Save $10 on "Alice in Wonderland Combo Pack"
Save up to 40% on Our Bestselling Fitness Products
Save up to $500 off the combined purchase of select Canon cameras and printers
 
 
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
 
 
Save $10 on "Alice in Wonderland Combo Pack"
 
 
Save up to 40% on Our Bestselling Fitness Products
 


This message was sent to the following e-mail address: atompub-archive@megatron.ietf.org

You're receiving this e-mail because you subscribed to Gold Box Deals. If you do not want any more e-mails of this kind, it's easy to unsubscribe.

Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit Amazon.com. The List Price represents the full retail price listed on the product itself, suggested by the manufacturer or supplier, or estimated in accordance with standard industry practice. For items offered as a set, List Price may represent open-stock prices.

© 2010 Amazon.com. All rights reserved.
Amazon.com is a registered trademark of Amazon.com, Inc.
Amazon.com, 1200 12th Ave. S., Suite 1200, Seattle, WA 98144-2734.
Reference: 15067840
From owner-atom-syntax@mail.imc.org Tue May 4 11:05:02 2010 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 F40803A68ED for ; Tue, 4 May 2010 11:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.777 X-Spam-Level: * X-Spam-Status: No, score=1.777 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 Hm5LeaeEKSyW for ; Tue, 4 May 2010 11:05:01 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id DD2FB3A67AF for ; Tue, 4 May 2010 11:04:57 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44Ht1N3099350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 10:55:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o44Ht1dn099349; Tue, 4 May 2010 10:55:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.212.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44Ht0UB099330 for ; Tue, 4 May 2010 10:55:00 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by pxi6 with SMTP id 6so1783198pxi.16 for ; Tue, 04 May 2010 10:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=6R65+JpK38YZRDZ7EQEer/ogbDv6nkjgd+AmcItzCdI=; b=fM3MAlLm+supvgOMLxeB9ogQ/6W1grqwRcwpkpZx2NUdFy9Km04zTw50mPUrz6mUiD sQqVH76EvVIZlZ7sOkmU2AQC2N9VsJGouGc1yxnLd90LDcHV5ddgG7UYmP7VbkIW1+/B YEtmuZ9SrQgd6YmrROThn1tKjhKjQA1+AMt/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=kP1F/w32p1DTcINqNJy4u8plOJvkSaF3pVR+wsOl8bAaf+AH7seKuPj8EggWE/+9Md 6XNjlRS1T+wl2Iq4fZt+NaC2tkcBOB9SSzVZeyBl7zAbCUJGtEkuq3yUhsigQRNekJRQ Q8C4tVgN+Wc+BPr79aJl6p+d6CfUSnTxasIZo= MIME-Version: 1.0 Received: by 10.114.2.25 with SMTP id 25mr11498312wab.100.1272995699700; Tue, 04 May 2010 10:54:59 -0700 (PDT) Received: by 10.114.58.7 with HTTP; Tue, 4 May 2010 10:54:59 -0700 (PDT) Date: Tue, 4 May 2010 13:54:59 -0400 X-Google-Sender-Auth: 4cd676e6ba487692 Message-ID: Subject: Link Extensions. Need "md5" or some kind of hash. From: Bob Wyman To: Atom-Syntax Content-Type: multipart/alternative; boundary=00504502f52b7b34790485c868a3 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --00504502f52b7b34790485c868a3 Content-Type: text/plain; charset=ISO-8859-1 I find that I have a real need for the "md5" Link rel mechanism defined in James Snell's old Atom Link Extensionsdraft or something functionally equivalent. Basically, what I need to do is ensure that the "src" attribute on an atom.content element is pointing to a known version of a resource rather than simply to any resource that has the same URL as in the src attribute. I'm then going to sign the Atom entry that contains this "by ref" content element. I've looked at the HTML5 RelExtentions Wiki but don't see anything there that looks like it does the job. Has anyone else needed hashed links in Atom? If so, what approach did you use to provide them? Is anyone aware of plans to introduce an "md5" or equivalent attribute to the HTML5 list? bob wyman --00504502f52b7b34790485c868a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I find that I have a real need for the "md5" Link rel mechanism d= efined in James Snell's old Atom Link Extensions draft or someth= ing functionally equivalent. Basically, what I need to do is ensure that th= e "src" attribute on an atom.content element is pointing to a kno= wn version of a resource rather than simply to any resource that has the sa= me URL as in the src attribute. I'm then going to sign the Atom entry t= hat contains this "by ref" content element.

I've looked at the HTML5 RelExtentions Wiki=A0but don't see anything = there that looks like it does the job.

Has anyone = else needed hashed links in Atom? If so, what approach did you use to provi= de them? Is anyone aware of plans to introduce an "md5" or equiva= lent attribute to the HTML5 list?

bob wyman

--00504502f52b7b34790485c868a3-- From owner-atom-syntax@mail.imc.org Tue May 4 12:42:27 2010 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 A4EE028C435 for ; Tue, 4 May 2010 12:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.376 X-Spam-Level: ** X-Spam-Status: No, score=2.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, 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 2607wOTKk25T for ; Tue, 4 May 2010 12:42:23 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 42FEE28C430 for ; Tue, 4 May 2010 12:06:14 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44Iv60Q002805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 11:57:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o44Iv6Xw002801; Tue, 4 May 2010 11:57:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-ww0-f43.google.com (mail-ww0-f43.google.com [74.125.82.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44Iv4Al002791 for ; Tue, 4 May 2010 11:57:05 -0700 (MST) (envelope-from pjkeane@gmail.com) Received: by wwc33 with SMTP id 33so939658wwc.16 for ; Tue, 04 May 2010 11:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=DgAqmeah7WmSb2+7pr1gtz7pDM7LdYs7y6qCOUnO5y0=; b=J78jc4aJnCVDSPEOQqAvdTrK90EBDg9k0MBssiOHIGFIbaeU8JZjtlvfDRy29PakTT KnsY91g/Mfrt6Ogn1bFlNu9U1jaPrUuAkoFxsPxLfVjZXhL3lMLZLcmLuFcFOjkPaLy5 4O91ZMVhc/EDN/A+8okp9u1bswAC05Tlu75Iw= 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=Q9mIdXDP+F84VnuyeBH3fjwgVdCp2EeGieJ0oosJiq+Gz4O9hLmwas5w2zpXCgUK37 MHsSvNXI+DPGrLwRzpCL/4WBTWfiqVAq9NhkKbaH+gErd1FZfy3TyZBNbpJIMLmtzsj7 dpgBmfax5LcglyOg5UAQEGZccYuQ/OkOPShbw= MIME-Version: 1.0 Received: by 10.216.85.198 with SMTP id u48mr3743508wee.225.1272999422862; Tue, 04 May 2010 11:57:02 -0700 (PDT) Received: by 10.216.88.17 with HTTP; Tue, 4 May 2010 11:57:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 May 2010 13:57:02 -0500 X-Google-Sender-Auth: 044f05068bd6245e Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Peter Keane To: Bob Wyman Cc: Atom-Syntax Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o44Iv5Al002793 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, May 4, 2010 at 12:54 PM, Bob Wyman wrote: > I find that I have a real need for the "md5" Link rel mechanism defined in > James Snell's old Atom Link Extensions draft or something functionally > equivalent. Basically, what I need to do is ensure that the "src" attribute > on an atom.content element is pointing to a known version of a resource > rather than simply to any resource that has the same URL as in the src > attribute. I'm then going to sign the Atom entry that contains this "by ref" > content element. There have been a number of discussion of such in the past on atom-syntax -- usually focussed on James Snell's link extension draft. You might also look at the Atom-Media extensions that came out of activity streams work [1] -- no md5, but that'd be an obvious addition. I think the MediaRSS spec is widely used, and it does have an md5 as a element w/ @algorithm [2]. When I have had need for it, I generally used a locally name-spaced attribute on atom:link, although that's obviously a sub-optimal solution. The RESTful implications of such a use are (I think) somewhat interesting. It creates a tight-binding (early binding) that is somewhat at odds w/ the late-binding nature of REST. I think that's why attributes on atom:link are always "advisory" and overridable (see RFC4287 sec. 4.2.7.3 and 4.2.7.6) by what's actually at the end of the wire. Another (probably impractical) approach is to have the resource as actual content instead of just a link. --peter keane [1] http://martin.atkins.me.uk/specs/atommedia [2] http://video.search.yahoo.com/mrss > I've looked at the HTML5 RelExtentions Wiki but don't see anything there > that looks like it does the job. > Has anyone else needed hashed links in Atom? If so, what approach did you > use to provide them? Is anyone aware of plans to introduce an "md5" or > equivalent attribute to the HTML5 list? > bob wyman > From owner-atom-syntax@mail.imc.org Tue May 4 12:53:22 2010 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 E4EA528C470 for ; Tue, 4 May 2010 12:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_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 RY2WVR+FLHv2 for ; Tue, 4 May 2010 12:53:21 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 10ADE3A6A8A for ; Tue, 4 May 2010 12:16:33 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44J8iU6003386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 12:08:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o44J8ifk003385; Tue, 4 May 2010 12:08:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44J8f8b003380 for ; Tue, 4 May 2010 12:08:43 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by vws17 with SMTP id 17so952505vws.16 for ; Tue, 04 May 2010 12:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZIrKNhHVbd/FdVjiOv+sB6MnRrlCcPNEBEtDzwavdrc=; b=qKZLMkFkaOrgXFaVTyhC501uedgrikGhp8asBsGpN8QNPF8STKe/jaUUpPIq0Cncp2 kggs65oh2AtWnMeiKT6xgpnXtivDMt/t1fzyVCgPGT3rO2zQzjIxQ91KkLbb8WkcdvwQ x/uGpf+yKLMat3QtyYGtcO9feSLTwJc4iIyxM= 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=ZMhDV163+7FUx1ibBvLj0o57t6H6aqg4TAClhHZkSeWJwjv75dIjpdpY226Y+Oydl5 mtajbtAsDHhELwbzh7gA9L1j2o5Sh1csmz2hD0fT/aTfdd/fPZxTA3JdPOvCwF6nSVSf jmMl6cIDd4aJgzwxP5HHbHHNSJQNFTaMhS4Ms= MIME-Version: 1.0 Received: by 10.229.245.68 with SMTP id lt4mr3577117qcb.71.1273000121065; Tue, 04 May 2010 12:08:41 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Tue, 4 May 2010 12:08:40 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 May 2010 12:08:40 -0700 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: James Snell To: Peter Keane Cc: Bob Wyman , Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o44J8h8b003381 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've noticed that Google has actually started using an etag attribute in their API which has roughly the same concerns about binding, etc. I'm a big fan of including as much metadata as practical possible without going overboard and think that a hash attribute (or set of hash attribute options not limited to md5) would be a good thing in general. I've been starting to dust off a few of the old I-D's this week starting with the tombstones draft (again) so perhaps I'll also pull out that link extensions draft and give it a do-over. - James On Tue, May 4, 2010 at 11:57 AM, Peter Keane wrote: > > On Tue, May 4, 2010 at 12:54 PM, Bob Wyman wrote: >> I find that I have a real need for the "md5" Link rel mechanism defined in >> James Snell's old Atom Link Extensions draft or something functionally >> equivalent. Basically, what I need to do is ensure that the "src" attribute >> on an atom.content element is pointing to a known version of a resource >> rather than simply to any resource that has the same URL as in the src >> attribute. I'm then going to sign the Atom entry that contains this "by ref" >> content element. > > There have been a number of discussion of such in the past on > atom-syntax -- usually focussed on James Snell's link extension draft. >  You might also look at the Atom-Media extensions that came out of > activity streams work [1] -- no md5, but that'd be an obvious > addition.  I think the MediaRSS spec is widely used, and it does have > an md5 as a element w/ @algorithm [2].  When I have had > need for it, I generally used a locally name-spaced attribute on > atom:link, although that's obviously a sub-optimal solution. > > The RESTful implications of such a use are (I think) somewhat > interesting.  It creates a tight-binding (early binding) that is > somewhat at odds w/ the late-binding nature of REST.  I think that's > why attributes on atom:link are always "advisory" and overridable (see > RFC4287 sec. 4.2.7.3 and 4.2.7.6) by what's actually at the end of the > wire.  Another (probably impractical) approach is to have the resource > as actual content instead of just a link. > > --peter keane > > [1] http://martin.atkins.me.uk/specs/atommedia > [2] http://video.search.yahoo.com/mrss > > >> I've looked at the HTML5 RelExtentions Wiki but don't see anything there >> that looks like it does the job. >> Has anyone else needed hashed links in Atom? If so, what approach did you >> use to provide them? Is anyone aware of plans to introduce an "md5" or >> equivalent attribute to the HTML5 list? >> bob wyman >> > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Tue May 4 12:53:45 2010 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 D95013A6D38 for ; Tue, 4 May 2010 12:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.454 X-Spam-Level: * X-Spam-Status: No, score=1.454 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_47=0.6, 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 PYA2gz72p+Vf for ; Tue, 4 May 2010 12:53:44 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C312F28C4C3 for ; Tue, 4 May 2010 12:16:54 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44J04as002980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 12:00:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o44J047u002979; Tue, 4 May 2010 12:00:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-ww0-f43.google.com (mail-ww0-f43.google.com [74.125.82.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44J03SN002973 for ; Tue, 4 May 2010 12:00:03 -0700 (MST) (envelope-from lindstream@gmail.com) Received: by wwc33 with SMTP id 33so941784wwc.16 for ; Tue, 04 May 2010 12:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=L4IIRGtJ5ihV96Ps6OJl8hlP0a9DksmgWtsT01f+OpQ=; b=A9UTflWxMxHuZptyx+RIOOWFVs9pR0+bzbwTURqy0c3iGFXV34VW3vuqqxN55XjhZ1 F5zFFkt5gcAETQ5DEJ9ELeUob7DbrL4FOCC+TvxnRb8d9pBNKl4982QXKGPMKP84Tatt 06aLjviIjgBbH3yCgpHUj6d8bEbzDaT+AWlpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=VO+zCwDYIm72QD/KCOznBIAtq95nq+152PiSs2HSsFovWyYnV8sS0hDE3wXCo9VPkN Q0FPrbvoGXyFqMgJBtRpn4tmrfhS3rOZS4Dx2UCIzsILGu15OxoP0MmSmvRZJrCTvySN SzV/gSBseKGrpcXH1P7GD57O+hfwcyPSczvjI= Received: by 10.216.168.7 with SMTP id j7mr2417501wel.214.1272999602157; Tue, 04 May 2010 12:00:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.19.203 with HTTP; Tue, 4 May 2010 11:59:42 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?Niklas_Lindstr=F6m?= Date: Tue, 4 May 2010 20:59:42 +0200 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. To: Bob Wyman Cc: Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Bob! On Tue, May 4, 2010 at 7:54 PM, Bob Wyman wrote: > I find that I have a real need for the "md5" Link rel mechanism defined in > James Snell's old Atom Link Extensions draft or something functionally > equivalent. Basically, what I need to do is ensure that the "src" attribute > on an atom.content element is pointing to a known version of a resource > rather than simply to any resource that has the same URL as in the src > attribute. I'm then going to sign the Atom entry that contains this "by ref" > content element. [...] > Has anyone else needed hashed links in Atom? If so, what approach did you > use to provide them? I'm actually using the le:md5 just as described in that draft. And pointing the publishers I want checksums from to it. It was either that or put up a page myself to link to with basically the same idea, and I figured the draft is already and will be online for quite some time, and easier to find than anything I would throw together. (I figured I could go with something based in RDF-land as well, but that's just as arbitrary from an Atom perspective.) Of course, the draft is stale and all, but I've found nothing more "standard". I asked here a couple of times over the past two years, and there is some interest, but I haven't heard about any definite alternative. Note that I don't actually recommend this practise, I just didn't find anything better, and haven't (yet) attempted to e.g. "adopt" the draft (which could be a way forward I guess, if such a thing is possible). Or defined an alternative elsewhere online. Best regards, Niklas From owner-atom-syntax@mail.imc.org Tue May 4 12:56:42 2010 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 6A9F028C365 for ; Tue, 4 May 2010 12:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.376 X-Spam-Level: ** X-Spam-Status: No, score=2.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, 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 5GFxduzTra5o for ; Tue, 4 May 2010 12:56:41 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6304B28C4E9 for ; Tue, 4 May 2010 12:20:46 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44JCtWf003675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 12:12:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o44JCtNg003674; Tue, 4 May 2010 12:12:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-ww0-f43.google.com (mail-ww0-f43.google.com [74.125.82.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44JCrka003667 for ; Tue, 4 May 2010 12:12:54 -0700 (MST) (envelope-from pjkeane@gmail.com) Received: by wwc33 with SMTP id 33so951663wwc.16 for ; Tue, 04 May 2010 12:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=573W/EfSKkUbJ/sBZEdORaOybUNb/1+NVFkuETXWizw=; b=YPfTZ3S5CL/DymJPk54W1vsRKXpevNN8iikmfnqDnZX13mO9V9GOoq++plfD6fXasy 5V8s2gS4ZYVURm6yJKDYbHUojA5MpRSyfSygJinlvNOF+As5JGIiLCOMPvVmaZ3sPrFZ FPKZa7h03LtnSPSGIdOhAfntlM5q45i9l2k18= 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=fTJ36rWp10lfjcuLp/LoWNJg0BGfkbt2Pzy7hHVpheJlS2ySMMV0D2sgjYsWIrZBnF VAsZLr96K0Iu1Yatp0kyGt2FUVO5mLLQVqFhzwnYYtnjYgi6E2GeM3+mTH4Q9FHOKfw/ pgOnif4GYMt+cmw5aXeJMSsANXUa1a11qKYjA= MIME-Version: 1.0 Received: by 10.216.86.208 with SMTP id w58mr1858203wee.45.1273000371610; Tue, 04 May 2010 12:12:51 -0700 (PDT) Received: by 10.216.88.17 with HTTP; Tue, 4 May 2010 12:12:51 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 May 2010 14:12:51 -0500 X-Google-Sender-Auth: fdd7b27ac5c29562 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Peter Keane To: James Snell Cc: Bob Wyman , Atom-Syntax Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o44JCtka003668 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, May 4, 2010 at 2:08 PM, James Snell wrote: > I've noticed that Google has actually started using an etag attribute > in their API which has roughly the same concerns about binding, etc. > I'm a big fan of including as much metadata as practical possible > without going overboard and think that a hash attribute (or set of > hash attribute options not limited to md5) would be a good thing in > general. I've been starting to dust off a few of the old I-D's this > week starting with the tombstones draft (again) so perhaps I'll also > pull out that link extensions draft and give it a do-over. > Very much appreciated. Glad to see you back on atom-syntax. --peter > - James > > On Tue, May 4, 2010 at 11:57 AM, Peter Keane wrote: >> >> On Tue, May 4, 2010 at 12:54 PM, Bob Wyman wrote: >>> I find that I have a real need for the "md5" Link rel mechanism defined in >>> James Snell's old Atom Link Extensions draft or something functionally >>> equivalent. Basically, what I need to do is ensure that the "src" attribute >>> on an atom.content element is pointing to a known version of a resource >>> rather than simply to any resource that has the same URL as in the src >>> attribute. I'm then going to sign the Atom entry that contains this "by ref" >>> content element. >> >> There have been a number of discussion of such in the past on >> atom-syntax -- usually focussed on James Snell's link extension draft. >>  You might also look at the Atom-Media extensions that came out of >> activity streams work [1] -- no md5, but that'd be an obvious >> addition.  I think the MediaRSS spec is widely used, and it does have >> an md5 as a element w/ @algorithm [2].  When I have had >> need for it, I generally used a locally name-spaced attribute on >> atom:link, although that's obviously a sub-optimal solution. >> >> The RESTful implications of such a use are (I think) somewhat >> interesting.  It creates a tight-binding (early binding) that is >> somewhat at odds w/ the late-binding nature of REST.  I think that's >> why attributes on atom:link are always "advisory" and overridable (see >> RFC4287 sec. 4.2.7.3 and 4.2.7.6) by what's actually at the end of the >> wire.  Another (probably impractical) approach is to have the resource >> as actual content instead of just a link. >> >> --peter keane >> >> [1] http://martin.atkins.me.uk/specs/atommedia >> [2] http://video.search.yahoo.com/mrss >> >> >>> I've looked at the HTML5 RelExtentions Wiki but don't see anything there >>> that looks like it does the job. >>> Has anyone else needed hashed links in Atom? If so, what approach did you >>> use to provide them? Is anyone aware of plans to introduce an "md5" or >>> equivalent attribute to the HTML5 list? >>> bob wyman >>> >> >> > > > > -- > - James Snell >  http://www.snellspace.com >  jasnell@gmail.com > From margindd@ahdubai.com Tue May 4 13:07:19 2010 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 0E6B53A6D19 for ; Tue, 4 May 2010 13:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.387 X-Spam-Level: X-Spam-Status: No, score=-16.387 tagged_above=-999 required=5 tests=[AWL=-0.900, 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, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, 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_DYNAMIC=0.1, SARE_FORGED_AMAZON=3, 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_PH_SURBL=1.787, 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 dCy06eAU8pX5 for ; Tue, 4 May 2010 13:07:16 -0700 (PDT) Received: from 161-182-93-178.pool.ukrtel.net (161-182-93-178.pool.ukrtel.net [178.93.182.161]) by core3.amsl.com (Postfix) with SMTP id 4FA4C28C55C for ; Tue, 4 May 2010 12:29:34 -0700 (PDT) From: "Amazon.com Email Subscriptions" To: "atompub-archive@megatron.ietf.org" Subject: Amazon.com Deal of the Day X-AMAZON-MAIL-RELAY-TYPE: subscription X-AMAZON-RTE-VERSION: 2.0 MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100504192935.4FA4C28C55C@core3.amsl.com> Date: Tue, 4 May 2010 12:29:34 -0700 (PDT)
Please click here if the e-mail below is not displayed correctly.
amazon.com
Free Two-Day Shipping with   › Amazon Prime
Your Amazon.com Today's Deals See All Departments
Tiffen Dfx Digital Filter Software V2
$149.95 $79.99 (47% off)
4.28571428571429
This Tiffen Dfx digital filter suite is a powerful but user-friendly stand alone application for still images. It offers a definitive set of digital optical filters, including simulations of many popular award-winning Tiffen glass filters, specialized lenses, optical lab processes, film grain, exacting color correction plus natural light and photographic effects, all in a controlled digital environment. Whether you are an amateur or professional photographer, a video or film editor, or graphic designer, Dfx's visual workflow and easy to use tools will help you create stunning images. Windows XP, Vista or Macintosh v10.4.6 and higher required for use.
Explore Other Great Gold Box Deals
Save $20 on Adobe Photoshop Elements 8
Great gift for Mom! Dbest Quick Cart
Lunar: Silver Star Harmony Limited Edition for $25.98
100 Albums for $5 Each
Save $20 on Adobe Photoshop Elements 8
$99.99 $59.99 (40% off)
 
 
Great gift for Mom! Dbest Quick Cart
$34.95 $29.99 (14% off)
 
 
Lunar: Silver Star Harmony Limited Edition for $25.98
$39.99 $25.98 (35% off)
 
 
100 Albums for $5 Each
 
Save up to $500 off the combined purchase of select Canon cameras and printers
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
Save $10 on "Alice in Wonderland Combo Pack"
Save up to 40% on Our Bestselling Fitness Products
Save up to $500 off the combined purchase of select Canon cameras and printers
 
 
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
 
 
Save $10 on "Alice in Wonderland Combo Pack"
 
 
Save up to 40% on Our Bestselling Fitness Products
 


This message was sent to the following e-mail address: atompub-archive@megatron.ietf.org

You're receiving this e-mail because you subscribed to Gold Box Deals. If you do not want any more e-mails of this kind, it's easy to unsubscribe.

Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit Amazon.com. The List Price represents the full retail price listed on the product itself, suggested by the manufacturer or supplier, or estimated in accordance with standard industry practice. For items offered as a set, List Price may represent open-stock prices.

© 2010 Amazon.com. All rights reserved.
Amazon.com is a registered trademark of Amazon.com, Inc.
Amazon.com, 1200 12th Ave. S., Suite 1200, Seattle, WA 98144-2734.
Reference: 15067840
From owner-atom-syntax@mail.imc.org Tue May 4 13:14:34 2010 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 9279628C1BC for ; Tue, 4 May 2010 13:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_28=0.6, J_CHICKENPOX_29=0.6, 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 q2PF8fvqyb9u for ; Tue, 4 May 2010 13:14:33 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 89F123A6AA6 for ; Tue, 4 May 2010 12:35:07 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44JRaJI004540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 12:27:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o44JRaLf004539; Tue, 4 May 2010 12:27:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44JRYLV004534 for ; Tue, 4 May 2010 12:27:35 -0700 (MST) (envelope-from lindstream@gmail.com) Received: by wyf23 with SMTP id 23so2389808wyf.16 for ; Tue, 04 May 2010 12:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=uajBT5eYrv9GjuCIF59MOat6w+AMgP8ynNaU3EBbqj8=; b=buIQXOzxqcSYJX+IRYAiqAtJ7Kv7220TbwRMC77h2wKSlgfVxAF5ZVRL+Htz9m0J/8 um3t6Qe0CnJTGiMhz9x44i/7ZJQiL3IOYIH1E0IRl3bEk9JjE/jAt6emzdn/T5+mhagO KuqKO/ZzE/Jb6xasW9PpZTf3K1ENYv3ozjRFE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=NZ1ENPjMyPlaW/8cwZ1LImeEl/7vCvUTcQ9k9yiSJP70gaWYDMoD+/1fb3vNObuXJ4 UCpp8abaU47Y00oQHXafZKciFWfqbmyvEDlwerz+KLMJzEO+VjNgxmTSfbjKS2Cfn6dA Gfu2gnhI5toW8sxlUSjpuFnDAvp8KEh+ofbKQ= Received: by 10.227.137.208 with SMTP id x16mr1707756wbt.124.1273001253179; Tue, 04 May 2010 12:27:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.19.203 with HTTP; Tue, 4 May 2010 12:27:13 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?Niklas_Lindstr=F6m?= Date: Tue, 4 May 2010 21:27:13 +0200 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. To: James Snell Cc: Peter Keane , Bob Wyman , Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: James, On Tue, May 4, 2010 at 9:08 PM, James Snell wrote: > > I've noticed that Google has actually started using an etag attribute > in their API which has roughly the same concerns about binding, etc. > I'm a big fan of including as much metadata as practical possible > without going overboard and think that a hash attribute (or set of > hash attribute options not limited to md5) would be a good thing in > general. I've been starting to dust off a few of the old I-D's this > week starting with the tombstones draft (again) so perhaps I'll also > pull out that link extensions draft and give it a do-over. that is wonderful! I'm really happy to hear you're doing this. Let me know if I can help in any way. Specifically, I think le:md5 is nice to keep since it corresponds to the HTTP Header. But I agree it would be good with support for more algorithms. Either as multiple attributes (le:sha1, le:sha2 etc), or le:checksum + le:algorithm. Or perhaps something akin to the value space of . Best regards, Niklas From owner-atom-syntax@mail.imc.org Tue May 4 13:41:00 2010 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 B003228C465 for ; Tue, 4 May 2010 13:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.077 X-Spam-Level: ** X-Spam-Status: No, score=2.077 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 EqTPufFFtVNX for ; Tue, 4 May 2010 13:40:59 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C14CA3A6CFE for ; Tue, 4 May 2010 12:53:27 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44JinPL005469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 12:44:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o44Jinxd005468; Tue, 4 May 2010 12:44:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-pz0-f180.google.com (mail-pz0-f180.google.com [209.85.222.180]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44Jim10005463 for ; Tue, 4 May 2010 12:44:49 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by pzk10 with SMTP id 10so82935pzk.20 for ; Tue, 04 May 2010 12:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=HbyRr+J8004ysMY9K48SuBhU8pvM9tgVLu1kikJusrQ=; b=rGrE4qKAg4EjmvpGmu18U1W7riQu97Km/DLp+TUA0sV/XoY5eyIFiTdghI2kSQSGiF NuHd5Wq9tH8VGBMSAdPdejcUjLxZsd10pUlmzfpsfhVENUyJEuTK3efhOEmPL5dcgQ+U 57hAEyRvx/LKXE159jX37W25GAY2OJSBF+gFY= 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=g35T/N+SUeCphej7cdUB2wRNr4HsiKywQJvJJp+ep6lg7KP9kLUy+/vADflR9CsFpx LQ+JHWnkLKRqJz7lgVnucNlVzesUd2VKeq51C2DhFeWDlY/Fb/yTALGb/rBmTGVleUcV bE7ziukV0GKUijK6ydF5ipjrKPThlxPw5MLnE= MIME-Version: 1.0 Received: by 10.114.33.18 with SMTP id g18mr9461392wag.2.1273002287999; Tue, 04 May 2010 12:44:47 -0700 (PDT) Received: by 10.114.58.7 with HTTP; Tue, 4 May 2010 12:44:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 May 2010 15:44:47 -0400 X-Google-Sender-Auth: ee869896ea2a44d0 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Bob Wyman To: James Snell Cc: Peter Keane , Atom-Syntax Content-Type: multipart/alternative; boundary=001636b1495d2ca9e20485c9f193 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636b1495d2ca9e20485c9f193 Content-Type: text/plain; charset=ISO-8859-1 James, Breathing life back into the draft would be greatly appreciated. At the risk of boring people, I'd like to expand a bit more on what I'm trying to accomplish. There might be other things that I've missed... As some are aware, some of us have been working on the Salmonprotocol and specifically on Salmon "Magic Signatures" which are an attempt to provide a *very* simple mechanism for signing content without losing too many of the benefits of the older, more complex methods. The Magic Signature draft specifically addresses the signing of Atom Entries used with Salmon and, in most cases, there is an implicit assumption that the "content" of the entries will be essentially "pass by value" or, in other words, included within the Magic Signature itself. The problem I've got is that there are times when "pass by ref" makes a great deal more sense. The signed object might be very large, might have security or copyright constraints that make copying difficult, etc. So, I'd like to use the "src" attribute to point to a remote resource and then to use a hash function to essentially pull the remote data into the scope of the signature. For this, I need to be able to specify the specific version of the resource pointed to. (The version is, of course, implicit when I pass by value -- by embedding the signed data in the Magic Signature.) What I'm looking for is something that I might use in much the same way that I would use an "artifact" in SAML. I realize that I could just adopt the SAML method, but, I'm attracted by the idea that an Atom based system may not need to do what SAML did in inventing a whole different datastructure for use when signing data by-ref. bob wyman On Tue, May 4, 2010 at 3:08 PM, James Snell wrote: > I've noticed that Google has actually started using an etag attribute > in their API which has roughly the same concerns about binding, etc. > I'm a big fan of including as much metadata as practical possible > without going overboard and think that a hash attribute (or set of > hash attribute options not limited to md5) would be a good thing in > general. I've been starting to dust off a few of the old I-D's this > week starting with the tombstones draft (again) so perhaps I'll also > pull out that link extensions draft and give it a do-over. > > - James > > On Tue, May 4, 2010 at 11:57 AM, Peter Keane > wrote: > > > > On Tue, May 4, 2010 at 12:54 PM, Bob Wyman wrote: > >> I find that I have a real need for the "md5" Link rel mechanism defined > in > >> James Snell's old Atom Link Extensions draft or something functionally > >> equivalent. Basically, what I need to do is ensure that the "src" > attribute > >> on an atom.content element is pointing to a known version of a resource > >> rather than simply to any resource that has the same URL as in the src > >> attribute. I'm then going to sign the Atom entry that contains this "by > ref" > >> content element. > > > > There have been a number of discussion of such in the past on > > atom-syntax -- usually focussed on James Snell's link extension draft. > > You might also look at the Atom-Media extensions that came out of > > activity streams work [1] -- no md5, but that'd be an obvious > > addition. I think the MediaRSS spec is widely used, and it does have > > an md5 as a element w/ @algorithm [2]. When I have had > > need for it, I generally used a locally name-spaced attribute on > > atom:link, although that's obviously a sub-optimal solution. > > > > The RESTful implications of such a use are (I think) somewhat > > interesting. It creates a tight-binding (early binding) that is > > somewhat at odds w/ the late-binding nature of REST. I think that's > > why attributes on atom:link are always "advisory" and overridable (see > > RFC4287 sec. 4.2.7.3 and 4.2.7.6) by what's actually at the end of the > > wire. Another (probably impractical) approach is to have the resource > > as actual content instead of just a link. > > > > --peter keane > > > > [1] http://martin.atkins.me.uk/specs/atommedia > > [2] http://video.search.yahoo.com/mrss > > > > > >> I've looked at the HTML5 RelExtentions Wiki but don't see anything there > >> that looks like it does the job. > >> Has anyone else needed hashed links in Atom? If so, what approach did > you > >> use to provide them? Is anyone aware of plans to introduce an "md5" or > >> equivalent attribute to the HTML5 list? > >> bob wyman > >> > > > > > > > > -- > - James Snell > http://www.snellspace.com > jasnell@gmail.com > --001636b1495d2ca9e20485c9f193 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable James,=A0
Breathing life back into the draft would be greatly appreciat= ed.=A0

At the risk of boring people, I'd like = to expand a bit more on what I'm trying to accomplish. There might be o= ther things that I've missed...

As some are aware, some of us have been working on the<= a href=3D"http://www.salmon-protocol.org/"> Salmon protocol and specifi= cally on Salmon "Magic Signatures" which are a= n attempt to provide a very simple mechanism for signing content wit= hout losing too many of the benefits of the older, more complex methods. Th= e Magic Signature draft specifically addresses the signing of Atom Entries = used with Salmon and, in most cases, there is an implicit assumption that t= he "content" of the entries will be essentially "pass by val= ue" or, in other words, included within the Magic Signature itself. Th= e problem I've got is that there are times when "pass by ref"= makes a great deal more sense. The signed object might be very large, migh= t have security or copyright constraints that make copying difficult, etc. = So, I'd like to use the "src" attribute to point to a remote = resource and then to use a hash function to essentially pull the remote dat= a into the scope of the signature. For this, I need to be able to specify t= he specific version of the resource pointed to. (The version is, of course,= implicit when I pass by value -- by embedding the signed data in the Magic= Signature.)

What I'm looking for is something that I might use = in much the same way that I would use an "artifact" in SAML. I realize= that I could just adopt the SAML method, but, I'm attracted by the ide= a that an Atom based system may not need to do what SAML did in inventing a= whole different datastructure for use when signing data by-ref.

bob wyman

On Tue, May= 4, 2010 at 3:08 PM, James Snell <jasnell@gmail.com> wrote:
I've noticed that Google has actually started using an etag attribute in their API which has roughly the same concerns about binding, etc.
I'm a big fan of including as much metadata as practical possible
without going overboard and think that a hash attribute (or set of
hash attribute options not limited to md5) would be a good thing in
general. I've been starting to dust off a few of the old I-D's this=
week starting with the tombstones draft (again) so perhaps I'll also pull out that link extensions draft and give it a do-over.

- James

On Tue, May 4, 2010 at 11:57 AM, Peter Keane <pkeane@mail.utexas.edu> wrote:
>
> On Tue, May 4, 2010 at 12:54 PM, Bob Wyman <bob@wyman.us> wrote:
>> I find that I have a real need for the "md5" Link rel me= chanism defined in
>> James Snell's old Atom Link Extensions draft or something func= tionally
>> equivalent. Basically, what I need to do is ensure that the "= src" attribute
>> on an atom.content element is pointing to a known version of a res= ource
>> rather than simply to any resource that has the same URL as in the= src
>> attribute. I'm then going to sign the Atom entry that contains= this "by ref"
>> content element.
>
> There have been a number of discussion of such in the past on
> atom-syntax -- usually focussed on James Snell's link extension dr= aft.
> =A0You might also look at the Atom-Media extensions that came out of > activity streams work [1] -- no md5, but that'd be an obvious
> addition. =A0I think the MediaRSS spec is widely used, and it does hav= e
> an md5 as a <media:hash> element w/ @algorithm [2]. =A0When I ha= ve had
> need for it, I generally used a locally name-spaced attribute on
> atom:link, although that's obviously a sub-optimal solution.
>
> The RESTful implications of such a use are (I think) somewhat
> interesting. =A0It creates a tight-binding (early binding) that is
> somewhat at odds w/ the late-binding nature of REST. =A0I think that&#= 39;s
> why attributes on atom:link are always "advisory" and overri= dable (see
> RFC4287 sec. 4.2.7.3 and 4.2.7.6) by what's actually at the end of= the
> wire. =A0Another (probably impractical) approach is to have the resour= ce
> as actual content instead of just a link.
>
> --peter keane
>
> [1] http://martin.atkins.me.uk/specs/atommedia
> [2] h= ttp://video.search.yahoo.com/mrss
>
>
>> I've looked at the HTML5 RelExtentions Wiki=A0but don't se= e anything there
>> that looks like it does the job.
>> Has anyone else needed hashed links in Atom? If so, what approach = did you
>> use to provide them? Is anyone aware of plans to introduce an &quo= t;md5" or
>> equivalent attribute to the HTML5 list?
>> bob wyman
>>
>
>



--
- James Snell
=A0http://www.snel= lspace.com
=A0jasnell@gmail.com

--001636b1495d2ca9e20485c9f193-- From owner-atom-syntax@mail.imc.org Tue May 4 14:45:29 2010 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 AE2CB28C330 for ; Tue, 4 May 2010 14:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.564 X-Spam-Level: X-Spam-Status: No, score=0.564 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DRUGS_MUSCLE=0.01, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCC-VpLe+J6Q for ; Tue, 4 May 2010 14:45:29 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A4E8128C633 for ; Tue, 4 May 2010 13:49:08 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44KeTDW008270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 13:40:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o44KeTnQ008269; Tue, 4 May 2010 13:40:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44KeRh3008263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 May 2010 13:40:28 -0700 (MST) (envelope-from rsalz@us.ibm.com) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o44KUNVW012790 for ; Tue, 4 May 2010 16:30:23 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o44KePUP146422 for ; Tue, 4 May 2010 16:40:27 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o44KeP19022444 for ; Tue, 4 May 2010 16:40:25 -0400 Received: from D27ML602.RCHLAND.IBM.COM (d27ml602.rchland.ibm.com [9.10.229.17]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o44KePap022441; Tue, 4 May 2010 16:40:25 -0400 In-Reply-To: References: To: Bob Wyman Cc: Atom-Syntax MIME-Version: 1.0 Subject: Re: Link Extensions. Need "md5" or some kind of hash. X-KeepSent: B0997B07:2F7457B9-85257719:007165E3; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Richard Salz Message-ID: Date: Tue, 4 May 2010 16:40:26 -0400 X-MIMETrack: Serialize by Router on d27ml602/27/M/IBM(Release 8.5.1FP2|March 17, 2010) at 05/04/2010 03:40:24 PM, Serialize complete at 05/04/2010 03:40:24 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have some concerns about hashing XML without doing some kind of canonicalization first -- namely, will it work in practice? I don't know. If it does, great, c14n is generally expensive. We wrote a draft I-D on security processing for Atom nearly a year ago. Not much interest anywhere, but I still think it's pretty good. :) https://datatracker.ietf.org/idst/status.cgi?submission_id=17333 /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ From owner-atom-syntax@mail.imc.org Tue May 4 14:54:38 2010 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 B80CE28C51B for ; Tue, 4 May 2010 14:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.187 X-Spam-Level: * X-Spam-Status: No, score=1.187 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DRUGS_MUSCLE=0.01, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=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 RK6FTqxoZ5hR for ; Tue, 4 May 2010 14:54:37 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 753C228C557 for ; Tue, 4 May 2010 13:58:22 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44KoUYi008856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 13:50:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o44KoUnd008855; Tue, 4 May 2010 13:50:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-pv0-f171.google.com (mail-pv0-f171.google.com [74.125.83.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44KoTmZ008850 for ; Tue, 4 May 2010 13:50:29 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by pvh11 with SMTP id 11so256677pvh.16 for ; Tue, 04 May 2010 13:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=nDeUZNy+rMDM0kxp6duuLh/KY6/aTk80VpFMwEs0bPc=; b=g+ZlQ5ON75sUmfNs0C++mJ4Phli+kjR9FuLxmgObwYfz8GCt8C/E6E+G7owRj14odY lYSHiTRKo/MkH/zizml3rqFvJ2fJU4S+5Xt78VmfusVHach1CX6MaqTLd5Xgo0ep7lKJ pR0TW/4ayuQ1kTxw9x1HPv8RWRt7gol9XL06s= 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=up2OyWiexwQPUQ8Is4gFuQbf9yDJN90cUjcTIHtgd72DxDEs3g0A+brlqDqzOdhcb2 w+D3wtBoJ/QGcO+5Ge9OifpRS+OdvCY2zuf+1jTyzFgM4NfWDrIexgHvse2SM//BVUyc p84wvSJijhx2iagxJAdk/RSMn5mqtQcxlbnuI= MIME-Version: 1.0 Received: by 10.114.33.18 with SMTP id g18mr9517643wag.2.1273006227615; Tue, 04 May 2010 13:50:27 -0700 (PDT) Received: by 10.114.58.7 with HTTP; Tue, 4 May 2010 13:50:27 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 May 2010 16:50:27 -0400 X-Google-Sender-Auth: 449b7459b4016cdc Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Bob Wyman To: Richard Salz Cc: Atom-Syntax Content-Type: multipart/alternative; boundary=001636b1495dfe6f060485cadb8d Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636b1495dfe6f060485cadb8d Content-Type: text/plain; charset=ISO-8859-1 Richard Salz wrote: > I have some concerns about hashing XML without > doing some kind of canonicalization first Right. That's one of the sweet things about Salmon's Magic Signaturestuff. The idea is that you punt on canonicalizing the XML by just dumping it into a base64 blob. You then sign the blob, not the XML. As a result, all the canonicalization issues disappear and you've got a nice, easy to implement signature method. See the draft for details: http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html bob wyman On Tue, May 4, 2010 at 4:40 PM, Richard Salz wrote: > I have some concerns about hashing XML without doing some kind of > canonicalization first -- namely, will it work in practice? I don't know. > If it does, great, c14n is generally expensive. > > We wrote a draft I-D on security processing for Atom nearly a year ago. > Not much interest anywhere, but I still think it's pretty good. :) > > https://datatracker.ietf.org/idst/status.cgi?submission_id=17333 > > /r$ > > -- > STSM, WebSphere Appliance Architect > https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ > > --001636b1495dfe6f060485cadb8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ri= chard Salz=A0<rsal= z@us.ibm.com>=A0wrote:
>=A0I have some concerns about has= hing XML without
> doing some kind of=A0canonicalization first
Right. That's one = of the sweet things about Salmon's Magic Signature s= tuff. The idea is that you punt on canonicalizing the XML by just dumping i= t into a base64 blob. You then sign the blob, not the XML. As a result, all= the canonicalization issues disappear and you've got a nice, easy to i= mplement signature method.

See the draft for details:=A0http://salm= on-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html

bob wyman

On Tue, May 4, 2010 at 4:40 PM, Richard Salz <<= a href=3D"mailto:rsalz@us.ibm.com">rsalz@us.ibm.com> wrote:
I have some concerns about hashing XML with= out doing some kind of
canonicalization first -- namely, will it work in practice? =A0I don't = know.
=A0If it does, great, c14n is generally expensive.

We wrote a draft I-D on security processing for Atom nearly a year ago.
Not much interest anywhere, but I still think it's pretty good. :)

=A0 =A0 =A0 =A0https://datatracker.ietf.org/idst/sta= tus.cgi?submission_id=3D17333

=A0 =A0 =A0 =A0/r$

--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blog= s/soma/


--001636b1495dfe6f060485cadb8d-- From owner-atom-syntax@mail.imc.org Tue May 4 15:03:41 2010 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 E92CF28C3F5 for ; Tue, 4 May 2010 15:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.564 X-Spam-Level: X-Spam-Status: No, score=0.564 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DRUGS_MUSCLE=0.01, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckDHDdU3ar17 for ; Tue, 4 May 2010 15:03:38 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1FDAB28C687 for ; Tue, 4 May 2010 14:09:13 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44L0ZpD009378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 14:00:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o44L0Zbv009377; Tue, 4 May 2010 14:00:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44L0Xie009370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 May 2010 14:00:35 -0700 (MST) (envelope-from rsalz@us.ibm.com) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e4.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o44KmDei007495 for ; Tue, 4 May 2010 16:48:13 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o44L0FhU1511676 for ; Tue, 4 May 2010 17:00:16 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o44L0FpH000762 for ; Tue, 4 May 2010 18:00:15 -0300 Received: from D27ML602.RCHLAND.IBM.COM (d27ml602.rchland.ibm.com [9.10.229.17]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o44L0EfK000708; Tue, 4 May 2010 18:00:15 -0300 In-Reply-To: References: To: Bob Wyman Cc: Atom-Syntax , bobwyman@gmail.com MIME-Version: 1.0 Subject: Re: Link Extensions. Need "md5" or some kind of hash. X-KeepSent: 78F3F044:7CB6051B-85257719:0073204D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Richard Salz Message-ID: Date: Tue, 4 May 2010 17:00:16 -0400 X-MIMETrack: Serialize by Router on d27ml602/27/M/IBM(Release 8.5.1FP2|March 17, 2010) at 05/04/2010 04:00:14 PM, Serialize complete at 05/04/2010 04:00:14 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > See the draft for details: http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html Interesting. The term "magic" is a little to cutesy for me, but maybe I'm just getting old. The draft, and the RFC on base64 it references, aren't specific enough about whitespace. Maybe I read too quickly, but the sample shows indented lines -- is the leading whitespace ignored? Embedded whitespace? Where odes it say that? I'd propose something similar: all whitespace is ignored when generating the digest. Then even more issues vanish. /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ From owner-atom-syntax@mail.imc.org Tue May 4 15:41:55 2010 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 7306228C1E6 for ; Tue, 4 May 2010 15:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.187 X-Spam-Level: * X-Spam-Status: No, score=1.187 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DRUGS_MUSCLE=0.01, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=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 aMXwEkoBS9Ib for ; Tue, 4 May 2010 15:41:54 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id F36FB3A6A0F for ; Tue, 4 May 2010 14:55:37 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44LlZde011984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 14:47:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o44LlZOj011983; Tue, 4 May 2010 14:47:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-pv0-f171.google.com (mail-pv0-f171.google.com [74.125.83.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o44LlXUG011977 for ; Tue, 4 May 2010 14:47:35 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by pvh11 with SMTP id 11so281540pvh.16 for ; Tue, 04 May 2010 14:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=mD3OT7fA9MY1aKXmfWgn81pHLSqIcX690Y+CoMTUw9Y=; b=RkolNO7Qe4CpNm7I2EF9Jsvvbn7HeeYXNSKOL5nJzWt5yQRmLS3AeNmEx+i/ml2Q3b XldOS+H4Q/fUXl0CdrKrXZNCWF4G6BAjJlDFAtg97BibaG3k/XxtIfnkCjikFbOzZ9L2 lN2sStAuAhGm0vMqO3aKPbeovcSwviZloJmJA= 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=D5ecApkQb/fAnS9PMXM0AgJ3BbmuCFCN6bf9tzcPhF7EZbX6/YpHVcQewC6cseCmDd Y6s8FT12ePGTZYoxumGj8cK8YOGVeKoXV8kEt0WbDU3j3R3OmTNT0NM2NKwZj79MgYNf yznfuwVcspmsR9jD55ign2nPK8KoaEzhvQGxo= MIME-Version: 1.0 Received: by 10.114.33.18 with SMTP id g18mr9566234wag.2.1273009653303; Tue, 04 May 2010 14:47:33 -0700 (PDT) Received: by 10.114.58.7 with HTTP; Tue, 4 May 2010 14:47:33 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 May 2010 17:47:33 -0400 X-Google-Sender-Auth: 545e76da1c332b37 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Bob Wyman To: Richard Salz Cc: Atom-Syntax Content-Type: multipart/alternative; boundary=001636b1495d2e6d130485cba89d Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636b1495d2e6d130485cba89d Content-Type: text/plain; charset=ISO-8859-1 Richard Salz wrote: > is the leading whitespace ignored? Section 7.2 of the draft says: "Normalize the string by removing all whitespace characters from input." So, Yes, whitespace is ignored. Simple! Note: Magic Signature discussions should be on: http://groups.google.com/group/salmon-protocol bob wyman On Tue, May 4, 2010 at 5:00 PM, Richard Salz wrote: > > See the draft for details: > > http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html > > Interesting. The term "magic" is a little to cutesy for me, but maybe I'm > just getting old. > > The draft, and the RFC on base64 it references, aren't specific enough > about whitespace. Maybe I read too quickly, but the sample shows indented > lines -- is the leading whitespace ignored? Embedded whitespace? Where > odes it say that? > > I'd propose something similar: all whitespace is ignored when generating > the digest. Then even more issues vanish. > > /r$ > > -- > STSM, WebSphere Appliance Architect > https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ > > --001636b1495d2e6d130485cba89d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ri= chard Salz=A0<rsal= z@us.ibm.com>=A0wrote:
>=A0is the leading whitespace i= gnored?

Section 7.2 of the draft says: "Normalize the stri= ng by removing all whitespace characters from input."
So, Ye= s, whitespace is ignored. Simple!

Note: Magic Sign= ature discussions should be on:=A0

bob wyman<= /div>

On Tue, May 4, 2010 at 5:00 PM, Ri= chard Salz <rsalz@= us.ibm.com> wrote:
> See the draft for de= tails:
http://salmon-protocol.googlecode.com/svn/= trunk/draft-panzer-magicsig-00.html

Interesting. =A0The term "magic" is a little to cutesy for = me, but maybe I'm
just getting old.

The draft, and the RFC on base64 it references, aren't specific enough<= br> about whitespace. =A0Maybe I read too quickly, but the sample shows indente= d
lines -- is the leading whitespace ignored? =A0Embedded whitespace? =A0Wher= e
odes it say that?

I'd propose something similar: =A0all whitespace is ignored when genera= ting
the digest. =A0Then even more issues vanish.

=A0 =A0 =A0 =A0/r$

--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blog= s/soma/


--001636b1495d2e6d130485cba89d-- From atompub-archive@megatron.ietf.org Wed May 5 09:42:11 2010 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 F37BD3A6980 for ; Wed, 5 May 2010 09:42:10 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 5 May 2010 09:42:10 -0700 (PDT) Received: from resigned-flasher.volia.net (resigned-flasher.volia.net [93.73.138.82]) by core3.amsl.com (Postfix) with SMTP id 1AD633A699C for ; Wed, 5 May 2010 09:42:05 -0700 (PDT) From: Approved VIAGRA® Store Subject: Please Read To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100505164206.1AD633A699C@core3.amsl.com> Date: Wed, 5 May 2010 09:42:05 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is atompub-archive@megatron.ietf.org

Copyright 58686 Inc. All rights reserved.

From owner-atom-syntax@mail.imc.org Wed May 5 09:49:08 2010 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 F32113A69FF for ; Wed, 5 May 2010 09:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.187 X-Spam-Level: * X-Spam-Status: No, score=1.187 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DRUGS_MUSCLE=0.01, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=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 lIUmRSCoSDGO for ; Wed, 5 May 2010 09:49:06 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D49FB3A682E for ; Wed, 5 May 2010 09:49:02 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o45GhM9U075282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 May 2010 09:43:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o45GhMLN075281; Wed, 5 May 2010 09:43:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-pz0-f181.google.com (mail-pz0-f181.google.com [209.85.222.181]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o45GhJho075273 for ; Wed, 5 May 2010 09:43:20 -0700 (MST) (envelope-from john@johnpanzer.com) Received: by pzk11 with SMTP id 11so2636193pzk.28 for ; Wed, 05 May 2010 09:43:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.128.1 with SMTP id f1mr6197158wfn.101.1273077798863; Wed, 05 May 2010 09:43:18 -0700 (PDT) Received: by 10.142.212.2 with HTTP; Wed, 5 May 2010 09:43:18 -0700 (PDT) Reply-To: jpanzer@acm.org In-Reply-To: References: Date: Wed, 5 May 2010 09:43:18 -0700 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: John Panzer To: Bob Wyman Cc: Richard Salz , Atom-Syntax Content-Type: multipart/alternative; boundary=000e0cd72c26f906d60485db850b Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --000e0cd72c26f906d60485db850b Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 4, 2010 at 2:47 PM, Bob Wyman wrote: > Richard Salz wrote: > > is the leading whitespace ignored? > > Section 7.2 of the draft says: "Normalize the string by removing all > whitespace characters from input." > So, Yes, whitespace is ignored. Simple! > It also makes generating printable examples much, much easier ;) > > Note: Magic Signature discussions should be on: > http://groups.google.com/group/salmon-protocol > > We'd welcome discussions about both magic signatures and salmon on the salmon-protocol list; if there is wider interest in magic signatures we can start a new list. Aside: Sorry about the name, we needed something to go out with and couldn't some up with anything better... > bob wyman > > On Tue, May 4, 2010 at 5:00 PM, Richard Salz wrote: > >> > See the draft for details: >> >> http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html >> >> Interesting. The term "magic" is a little to cutesy for me, but maybe I'm >> just getting old. >> >> The draft, and the RFC on base64 it references, aren't specific enough >> about whitespace. Maybe I read too quickly, but the sample shows indented >> lines -- is the leading whitespace ignored? Embedded whitespace? Where >> odes it say that? >> >> I'd propose something similar: all whitespace is ignored when generating >> the digest. Then even more issues vanish. >> >> /r$ >> >> -- >> STSM, WebSphere Appliance Architect >> https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ >> >> > --000e0cd72c26f906d60485db850b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, May 4, 2010 at 2:47 PM, Bob Wyman <bob@wyman.us> wrote:
Richard Salz=A0<rsalz@us.ibm.com>=A0wrote:<= /div>
>=A0is the leading whitespace ignored?

Section 7.2 of the draft says: "Normalize th= e string by removing all whitespace characters from input."
= So, Yes, whitespace is ignored. Simple!

It also makes generating printable examples much, much easier ;)
=
=A0

Note: Mag= ic Signature discussions should be on:=A0


We'd welcome discussions about both= magic signatures and salmon on the salmon-protocol list; if there is wider= interest in magic signatures we can start a new list.

Aside: =A0Sorry about the name, we needed something to = go out with and couldn't some up with anything better...
=A0<= /div>
bob wyman

On Tue, May 4, 201= 0 at 5:00 PM, Richard Salz <rsalz@us.ibm.com> wrote:
Interesting. =A0The term "magic" is a little to cutesy for = me, but maybe I'm
just getting old.

The draft, and the RFC on base64 it references, aren't specific enough<= br> about whitespace. =A0Maybe I read too quickly, but the sample shows indente= d
lines -- is the leading whitespace ignored? =A0Embedded whitespace? =A0Wher= e
odes it say that?

I'd propose something similar: =A0all whitespace is ignored when genera= ting
the digest. =A0Then even more issues vanish.

=A0 =A0 =A0 =A0/r$

--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blog= s/soma/



--000e0cd72c26f906d60485db850b-- From atompub-archive@megatron.ietf.org Wed May 5 12:33:36 2010 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 2B5323A6ABB for ; Wed, 5 May 2010 12:33:36 -0700 (PDT) X-Quarantine-ID: <9VkHisXXRx3P> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 5 May 2010 12:33:35 -0700 (PDT) Received: from 109-184-45-239.dynamic.mts-nn.ru (109-184-45-239.dynamic.mts-nn.ru [109.184.45.239]) by core3.amsl.com (Postfix) with SMTP id 84CEA28C1A1 for ; Wed, 5 May 2010 12:33:25 -0700 (PDT) From: Approved VIAGRA® Store Subject: Electronic Discount Code 76% for atompub-archive@megatron.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100505193325.84CEA28C1A1@core3.amsl.com> Date: Wed, 5 May 2010 12:33:25 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is atompub-archive@megatron.ietf.org

Copyright 34274 Inc. All rights reserved.

From area-request@lists.ietf.org Thu May 6 07:27:41 2010 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 328B128C272 for ; Thu, 6 May 2010 07:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.667 X-Spam-Level: X-Spam-Status: No, score=-30.667 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_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 ETJNL+FnRaE4 for ; Thu, 6 May 2010 07:27:35 -0700 (PDT) Received: from advancedsurfaces.com (186-24-23-3.genericrev.telcel.net.ve [186.24.23.3]) by core3.amsl.com (Postfix) with SMTP id DB5D028C271 for ; Thu, 6 May 2010 07:02:20 -0700 (PDT) From: RX-Store Subject: Sales Event get 75% off To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100506140221.DB5D028C271@core3.amsl.com> Date: Thu, 6 May 2010 07:02:20 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://sheengine.ru/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 63188 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 64761 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 48178 is unauthorized. 31710

From owner-atom-syntax@mail.imc.org Thu May 6 12:26:24 2010 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 C35743A679C for ; Thu, 6 May 2010 12:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.176 X-Spam-Level: * X-Spam-Status: No, score=1.176 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPjoLNY4sDr6 for ; Thu, 6 May 2010 12:26:24 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C26F23A6940 for ; Thu, 6 May 2010 12:26:21 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o46JJJVN068436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 May 2010 12:19:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o46JJJFB068435; Thu, 6 May 2010 12:19:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-gy0-f171.google.com (mail-gy0-f171.google.com [209.85.160.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o46JJIBt068430 for ; Thu, 6 May 2010 12:19:18 -0700 (MST) (envelope-from ed.summers@gmail.com) Received: by gyf3 with SMTP id 3so192235gyf.16 for ; Thu, 06 May 2010 12:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=IAp1AB5SVTQWLxT2IYT46Ue+hZ3vTUSAk0z55JM9q5g=; b=kvr+gUQYj7q0wXMJgPitzHtQhOgIVYMcpLdyMJb1nv6pe1KQcta5JW230/3TqySigF JPEIxuSWJ/kGFwy6AHVzI6OPRATTPr37ZUBDJl5mHDlTsmsItEv9meuO4YWFZSa7zGyu zWfAb5p3HkwryW+EnbMnYbfLS09Zty13lJI1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=m4SZl1rNUVcifIXoc516lwlsMz8KJO6djBUZeKBx29DI46p/I/DY+jHSUTSSDO92Ad 816DQUP0ZLuyoocbAs43BtZDfoXJr5elPy0EDV/hw5IIwHQiKxtsnDSLShfMxSsbJdyA uNlh3bjBI+uw103k389RkFS79AUuu1twYciIo= MIME-Version: 1.0 Received: by 10.151.28.10 with SMTP id f10mr2253668ybj.171.1273173554781; Thu, 06 May 2010 12:19:14 -0700 (PDT) Received: by 10.151.143.19 with HTTP; Thu, 6 May 2010 12:19:14 -0700 (PDT) Date: Thu, 6 May 2010 15:19:14 -0400 X-Google-Sender-Auth: 93a1af946938d507 Message-ID: Subject: atom validator From: Ed Summers To: atom-syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I was wondering if anyone knew of an Atom-only validator. I realize there are general feed validators out there, but I've noticed some minor glitches with them [1], and I'm really not so interested in validating all kinds of feeds--just Atom. I'm also particularly interested in validators that could potentially be extended (source code) to validate Atom that uses Open Publishing Distribution System (OPDS [2]) extensions. Any pointers/suggestions you can provide would be welcome. //Ed [1] http://sourceforge.net/mailarchive/forum.php?thread_name=t2vf032cc061005050626ncfa1d8c2g3c1fcbbe80e1cbec%40mail.gmail.com&forum_name=feedvalidator-users [2] http://code.google.com/p/openpub/wiki/CatalogSpecDraft From atompub-archive@megatron.ietf.org Fri May 7 03:22:51 2010 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 E09513A69B4 for ; Fri, 7 May 2010 03:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.423 X-Spam-Level: X-Spam-Status: No, score=-16.423 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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, RDNS_NONE=0.1, 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 twoRd5nF-oqB for ; Fri, 7 May 2010 03:22:41 -0700 (PDT) Received: from afo.net (unknown [82.209.218.220]) by core3.amsl.com (Postfix) with SMTP id B74E93A6AE2 for ; Fri, 7 May 2010 03:21:27 -0700 (PDT) From: RX-Store Subject: New Private Message for atompub-archive@megatron.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100507102127.B74E93A6AE2@core3.amsl.com> Date: Fri, 7 May 2010 03:21:27 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://canyes.ru/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 80047 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 53496 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 70920 is unauthorized. 59627

From atompub-archive@lists.ietf.org Fri May 7 19:20:56 2010 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 A6E3B3A657C for ; Fri, 7 May 2010 19:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.494 X-Spam-Level: X-Spam-Status: No, score=-25.494 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, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, 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, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 5h6YsJTm1OlD for ; Fri, 7 May 2010 19:20:50 -0700 (PDT) Received: from c-69-248-145-183.hsd1.nj.comcast.net (c-69-248-145-183.hsd1.nj.comcast.net [69.248.145.183]) by core3.amsl.com (Postfix) with SMTP id A2C093A6890 for ; Fri, 7 May 2010 19:19:35 -0700 (PDT) From: RX-Store Subject: New Private Message for atompub-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100508021935.A2C093A6890@core3.amsl.com> Date: Fri, 7 May 2010 19:19:35 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://takeextol.ru/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 55412 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 22380 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 02513 is unauthorized. 60703

From area-request@lists.ietf.org Sat May 8 06:16:42 2010 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 13BBB3A6A99 for ; Sat, 8 May 2010 06:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.728 X-Spam-Level: X-Spam-Status: No, score=-32.728 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 Aakwy8K+Za5n for ; Sat, 8 May 2010 06:16:35 -0700 (PDT) Received: from algolith.com (temperate-abhorer.volia.net [93.74.87.81]) by core3.amsl.com (Postfix) with SMTP id 8457D3A6A87 for ; Sat, 8 May 2010 06:16:32 -0700 (PDT) From: RX-Store Subject: Sales Event get 78% off To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100508131633.8457D3A6A87@core3.amsl.com> Date: Sat, 8 May 2010 06:16:32 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://takeextol.ru/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 36831 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 18696 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 23768 is unauthorized. 26435

From atompub-archive@megatron.ietf.org Sat May 8 19:15:20 2010 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 9AA323A6850 for ; Sat, 8 May 2010 19:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.43 X-Spam-Level: X-Spam-Status: No, score=-21.43 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 3wK2AYB3UTis for ; Sat, 8 May 2010 19:15:14 -0700 (PDT) Received: from amarais.net (unknown [190.166.103.222]) by core3.amsl.com (Postfix) with SMTP id CF90C3A67B4 for ; Sat, 8 May 2010 19:15:12 -0700 (PDT) From: RX-Store Subject: Please Read To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100509021512.CF90C3A67B4@core3.amsl.com> Date: Sat, 8 May 2010 19:15:12 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://famoussudden.ru/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 30660 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 01869 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 64090 is unauthorized. 53261

From atompub-archive@lists.ietf.org Sun May 9 08:00:52 2010 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 61E413A6A09 for ; Sun, 9 May 2010 08:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.877 X-Spam-Level: X-Spam-Status: No, score=-13.877 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, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 cYWzVpFA64JS for ; Sun, 9 May 2010 08:00:46 -0700 (PDT) Received: from 205-178-135-95.pool.ukrtel.net (205-178-135-95.pool.ukrtel.net [95.135.178.205]) by core3.amsl.com (Postfix) with ESMTP id 1E79B3A69FD for ; Sun, 9 May 2010 08:00:37 -0700 (PDT) From: RX-Store Subject: Special Discount 70% for atompub-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html X-Antivirus: avast! (VPS 100315-1, 15.03.2010), Outbound message X-Antivirus-Status: Clean Message-Id: <20100509150038.1E79B3A69FD@core3.amsl.com> Date: Sun, 9 May 2010 08:00:37 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://famoussudden.ru/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 62449 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 54762 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 02948 is unauthorized. 69132

From archive@lists.ietf.org Sun May 9 13:33:29 2010 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 C1E1C3A68E9 for ; Sun, 9 May 2010 13:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.305 X-Spam-Level: X-Spam-Status: No, score=-5.305 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_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, HTML_IMAGE_ONLY_24=1.552, 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_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, 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_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 CGb1ls9EWmX8 for ; Sun, 9 May 2010 13:33:23 -0700 (PDT) Received: from 201-42-30-174.dsl.telesp.net.br (201-42-30-174.dsl.telesp.net.br [201.42.30.174]) by core3.amsl.com (Postfix) with SMTP id CE0453A67C1 for ; Sun, 9 May 2010 13:33:20 -0700 (PDT) From: RX-Store Subject: Sales Event get 79% off To: MIME-Version: 1.0 Content-Type: text/html X-Antivirus: avast! (VPS 100114-1, 14/01/2010), Outbound message X-Antivirus-Status: Clean Message-Id: <20100509203321.CE0453A67C1@core3.amsl.com> Date: Sun, 9 May 2010 13:33:20 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://famoussudden.ru/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 27064 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 75870 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 71592 is unauthorized. 38988

From jeff.hcc@hccled.com.cn Tue May 11 01:14:19 2010 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 AD2DA3A6B27 for ; Tue, 11 May 2010 01:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.1 X-Spam-Level: **** X-Spam-Status: No, score=4.1 tagged_above=-999 required=5 tests=[BAYES_99=3.5, J_CHICKENPOX_56=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 e90co6rIMSRF for ; Tue, 11 May 2010 01:14:18 -0700 (PDT) Received: from mail.umail103.cn4e.com (mail.umail103.cn4e.com [211.152.42.170]) by core3.amsl.com (Postfix) with ESMTP id A3B2F3A6405 for ; Tue, 11 May 2010 01:14:15 -0700 (PDT) Received: from PUBLIC (unknown [113.90.244.47]) by mail.umail103.cn4e.com (Postfix) with ESMTPA id 4E53A487CF for ; Tue, 11 May 2010 16:13:59 +0800 (CST) Message-ID: <00c3b32a$40309$0d1a6762644676@public> Reply-To: "HCC LED" From: "HCC LED" To: atompub-archive@megatron.ietf.org Subject: New Energy Saving Way---------save 65% energy than present traditional fluorescent tube light Date: Tue, 11 May 2010 16:13:49 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="TJUYd6jE45CUKzHkj7yv2NNRXiYkeco4=_" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: My e-mail client v1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 This is a multi-part message in MIME format --TJUYd6jE45CUKzHkj7yv2NNRXiYkeco4=_ Content-Type: text/plain; format=flowed; charset=""; reply-type=original Content-Transfer-Encoding: 7bit Dear Purchasing Manager/Product Manager, Greetings! I am Jeff , export manager of HCC TECHNOLOGY CO.,LTD. We are a LED lighting manufacturer and supplier in China, is proud to introduce our LED T8 Fluorescent tube. As an effective replacement for the traditional fluorescent T8 tube, the LED T8 tube is not only more energy efficient (the 15w LED tube replaces the 36w fluorescent tube, save 65% energy), but also environmentally safe because, unlike fluorescents, LED does not contain Hydrargyrum. The LED T8 Tube provides an excellent replacement solution for supermarkets,home lighting, warehouses, factories, schools, offices, hospitals, and any facility where fluorescents are now being used. It goes without saying, with the advent of Green Technology, the market potential for this product is extremely attractive. If you are in the lighting business, the LED T8 fluorescent tube is an effective answer for your customers' lighting needs. The attached pdf file provides the specifications, pictures and prices of our LED T8 Tube selections to help you determine which item is the best product for your customer. Also I am glad to inform you that all of our Led T8 Fluorescent tubes have passed CE, ROHS, FCC certification. More information, please visit our web: www.hccled.cn . If you have any further questions , please contact me by email or via phone. Waiting for your quick reply. Best Regards, Jeff Export Manager HCC TECHNOLOGY CO., LIMITED Factory Address: 5F, Building 7, Fengsheng Industrial Zone, Potouxia Villiage, Guanlan, Baoan, Shenzhen, Guangdong ,China Tel: 0086-755-29228763 Fax: 0086-755-27040510 Mob:0086-13689529749 Email: export@hccled.cn MSN:jeffhcc@hotmail.com Skype:hccled Web: www.hccled.cn --TJUYd6jE45CUKzHkj7yv2NNRXiYkeco4=_ Content-Type: application/octet-stream; name="HCC-LED T8 Tube(April 2010).pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="HCC-LED T8 Tube(April 2010).pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nMWZ62/byBHAYT6kDSVYcihZjKVYK0q0HrbofZNMLuf20OKAol9yMNAPZj+l vSuK2kX0/3/o7JKSFYdy1cZ2bIjWzg53Z2d/M/vwZ0xiyjDRv+svn249XUoJSVKKKV795lElsBSJ ilWCBUsoZlzi1d+9X0HzZ/j85n320pjrH9PE9vdPt/ina+/ylwSkicLXv3o0JoRAi7qW4ozEmcIp o7r/61tvdmBZtuNaB7U6qr/K72yr3mgiJ1815tf/hHYyaIeIynZSgVOSxlRttQOtQCPQQr5C9cNW o33UyO9eI9evdxrdFjruBW9AfNKodyyQv+7Bo4763UF+h96aZx2dtrT0SNfXh114vactoSxmYMaf vRketEdh6I8nNceZRGdR5NfGU4RQPuvl89Fa7sMQamduDSrQotk8H11cLJfLuHt52R4cxZeWjdY/ g3x+bgVNcl81n3qzIfTf7F02R4gGMRtwDsLCq4U3liqLpZQCL2liRH/zZoet9tFrv9NtH9tOF0aq 7b5e3MwOT/q94LhjO0GrN3gzX6YJiQURM+etY58O8cg+CsL2oNuxu8f2ydH45NgPmraWT04iXbAn wVm7FdiDaTfUDeWz+V+v/+RREnNmXHLY6vrBG203ZwSoAauk0PMDVt3M8vlJL4yCwXzJOJWx4LMF xufwwYdWPjdN7eYFQOEKS7BYFvN8gfHb5UWvZ9vx5T6IKCFikZpXXYE6UqFET3Cz0UxHyI3C88sM 9amaOpGvm8s0nnpMkUCqYQMSWQOmYoTGYXgRjW0zOVOB3uV3560mem+1m73XgxH6Yeg7E3fsXMBn Eo2d91ovX0GPLRsYsloZ4u0WAIJqTjjx4XPmhB2qtRxQavAB6p/3dEfT8MPECT+gRZDp2rFAQ6tt BQgP7PNB0Gu2AuguqoXhZOqE4Ycfr67E70wzIYjAShAdgwiNde3vfxxeCV1bE+jYWg6CEfKvoEyl jDPMi9ECOovhcIL9cDzp90N/EkbaFX+89j56hSt/+bn8sto39qsmhAllZoSIWBbBf3pAXh3YiDJS 4zXLBbDu+9030+yafi4S3Y0iWYnOzSwKYz+cLyWoxYzO3Fo8DUuUWawgmOQ6lCLneNi/GOKfvmCi 33irfQ+5JZ+jaKyfY//S3oTmboBFQtYJTwMsMAC8wHsBDEFuUk81wOPoAcCV4E7DJwAXgJ24LkDm TsPvg64banZnvkCLQa+J+mDfmw3MQj4k2Q0n4fQ5SZbAFlcvRbKkkMlKkJ043AK54PpFQOYpWdMo 15l4sdwLZAEgl4t1Bcj+w0z8FchnT5WB3VCTHOnH9DslYTd6JAufaXajZ87CAmh6sSQsaFZSA+yO 43y1DW+kWf42eM/2g5cBiGW8yk0WHu4FL4f9FtvBLpiyF7xPkoVd6AzAHesUPIGoeZTfR/Gdakwn xqANw+gBwObtXQw7VzuSrwHYeebky5kw+8+XIZizdaq/mU3zVRxtE+zHzhMRbIz+7NEkxTThqT6B 3XqJoJvSv4qSkqwoGc1N6R/eX/DdN5zOyjCBYZVb5sVyk+SLODEGfvwGfxbhxJJyLdsvnHbuymED /1SLwiau/mtUPd+q4OxeFWBBKILqWVcFxmFexEsFFYNBFqA9T1C50VdRlREaK5WWUbUuFVGVwum0 KGnN+9LTRBWFcRFxH1Vm9Vnip4wqmj6yw5qCa/6nsHqa5UqfGiJXP77XXiva+9RgYix67lMDBepZ +lIxRsV6mbyBGQq/ODdMp9++9foixkisCJWK6+vFLM0SCZZo31WI9/ZkdURlscIqgQgtHJnPWb6y dRK3ndh2qHLtfO4mxM3n/4dLE0ypCaR1v3wzgxwn+sKt6DWldYc7pF4rdpC75p0rhRPINOW56TAh lntK83lWzPeSszSWaYaXIs5YcWd2SCyHJu58mWTmxhQGeOha5B2xiv6WKSU8JnTG6vnKRXat3jDz KCB/Z4pCt+ZCkFvvSe1V0UkKWUhKMMTgYJi3j076A/vkrBO07B+Cjq0vBMPislC/w5i5OYF5B2PB s/bpu7oCvx64NfsDPMD8ct519pQJMTsU2D/AQM11MSM75AmvlHNW3PWVckpZKU++kG/0qYQ0TYRJ 06ArWUqKCiHYgxr4a2pMni8rFBYqIVumVlZoW6sqjFGVFWxHBYUviiSsvFcneD0+XSEzXlZI/da6 7wTL1Nyp6vVDrivMC6U/tl8wcpnRSrmAPVeFXCRMVsl5mla2z3X+qpDDYk6q5FSJSnvWHtqWf4bR mv9OwFFN73IBfcg8CoJDt/DpFoKMUvyHf+u1EktVqMoUnJMUqiLN+L0q+1o13ahC1Kk9VWE7kD6i qiB9bAwgyZYqf0w1ywoHPFRlpQFc7/qlUWVSbA1LFKofvf8AXLlrOmVuZHN0cmVhbQplbmRvYmoK NiAwIG9iagoxNzk2CmVuZG9iagoxOCAwIG9iago8PC9MZW5ndGggMTkgMCBSL0ZpbHRlciAvRmxh dGVEZWNvZGU+PgpzdHJlYW0KeJzFlutv2zYQwFFbMljZgIOpiD3YrRlaquwkpkXySErr0mxFiwLD vjQw0A9VP/U1DI2H+P//0KPkV1unyJBHLUjgPcA78+5H8oKmXEiaumc1eHceXATCZtRIk3Fj6Xlg Qaylz5UkMllJpeda+id4TedBSl/i+wnnybhyv3Li7fG7c/psFkzPLGqtobOPgeBpmhoorYJKwZWh FoCnGZ2dB6PDAaUPJ8edTv2QT8ezf4MXs+AVPlcPlaM2he9D5SnPgGaiiuMDeaANse1OMW81W9kB SRg7muakJ0zixaELnfMcU/47GMVATLPeL+Z5s1bMD4jvMXYcD+v1cRKMEiC/FfOjdos8qe21Or/0 D8jvg9CL/KF3jG8UD70nzq9YYMh2vVnMa+2cqL12McaZGh6L/Mf4iX3GHgjn6KFfU/VJ76jjgiXs JPLYCTns5s46BDKo7dW6hPbrR/1up9XuYsS4wViUYFonT09P4Y9yGoaqIXOqfVSRobP++XRwCs7a ALJfm/S7mEJ4igqhNc+pqv7ye1eHQURD34t6PT+MWLwuRbWYZy+Xg8VVq7+rJBKMq4m1lRnL8uhe ev9enQiZNlSj5hejrbjXbQAFlmtJbaaWzfYGaxJzxsYTjX5cilHiOfHt7K9ApNjpGqgup8IFib39 Qe94QJ991Rm95kO3+sWCFGMSD93X98Kpa4wy64owDUpsCFtJFWFagd4QtpEqwq5LlgHFDWzIAopk TSbbZF2XKCttmcBOqIpFEv8vqhJ2A1TFiQMKp3NuP4eqOHZUjUI47HdapIf5/bqmDPS3iMVxxJLb RMzgxp1ld4WYySzPZYWY5/PhFmHYELeCGOgcNoitpM9LKc02iG2km0EMceayIozfDmEGCVPyJggL b4Own3RuXZ2w8C4I00gY3NkhppEwWB5iXoMXi68Qa/AwuS5i4RZiQiM2kFuHDd4eJcicLj4EHyu6 lgbj9KrSy/Qyg1W7DUoiSjsN9hIDgLwkK2FTanKZOgNIzN1s6YUVu/RaKdilXwXY1l9QbcqrNJYh o+jFc1xIo0S5r+C9enqG+Tz/z6G/djVY4JWr1hI2rupHruD20m9dXwVfAAzrEVdlbmRzdHJlYW0K ZW5kb2JqCjE5IDAgb2JqCjgyNwplbmRvYmoKNCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3gg WzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0 Wy9QREYgL0ltYWdlQyAvVGV4dF0KL1hPYmplY3QgMTUgMCBSCi9Gb250IDE2IDAgUgo+PgovQ29u dGVudHMgNSAwIFIKPj4KZW5kb2JqCjE3IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAw IDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE RiAvSW1hZ2VDIC9UZXh0XQovWE9iamVjdCAyMCAwIFIKL0ZvbnQgMjEgMCBSCj4+Ci9Db250ZW50 cyAxOCAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNCAwIFIK MTcgMCBSCl0gL0NvdW50IDIKL1JvdGF0ZSAwPj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlwZSAvQ2F0 YWxvZyAvUGFnZXMgMyAwIFIKL01ldGFkYXRhIDI2IDAgUgo+PgplbmRvYmoKMTUgMCBvYmoKPDwv UjE0CjE0IDAgUi9SMTMKMTMgMCBSL1IxMgoxMiAwIFIvUjExCjExIDAgUj4+CmVuZG9iagoxNCAw IG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xvclNwYWNlL0RldmljZVJHQgovV2lkdGggMzYwCi9I ZWlnaHQgMzYwCi9CaXRzUGVyQ29tcG9uZW50IDgKL0ZpbHRlci9EQ1REZWNvZGUvTGVuZ3RoIDEw MTI2Pj5zdHJlYW0K/9j/7gAOQWRvYmUAZAAAAAAB/9sAQwAOCgsNCwkODQwNEA8OERYkFxYUFBYs ICEaJDQuNzYzLjIyOkFTRjo9Tj4yMkhiSU5WWF1eXThFZm1lWmxTW11Z/9sAQwEPEBAWExYqFxcq WTsyO1lZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZ/8AA EQgBaAFoAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIB AwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBka JSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SV lpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX2 9/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAEC dwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4 OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQAC EQMRAD8A84ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKsQ2F3Ou6G2ldT3VSRQBXoq3/Zd+Dj7HP8A98GnDSNRPSyuD/wA0AUq Ku/2RqP/AD5XH/fBpf7G1L/nxuP+/ZoAo0VoDQ9VPTT7r/v0ahn02+tlLT2dxEo6s8ZA/OgCrRRR QAUUUUAFFFFABRXoB8P6P2tGH/bRv8aP+Ef0j/n1P/fxv8arlZPMjz+ivQBoGkAY+yE/WRqDoOk/ 8+n/AI+aOVhzI8/or0EaFpQPFoPxYmmnQtNzkWy/rRysOZHAUV6ANF08dLaP8qeuk2A/5dIj9Vo5 WHMeeUV6ONNsR0s4f++BTv7Pscj/AEODj/YFHKHMebUV6V9gsSf+POD/AL4FOFlaDpaxD/gIo5Qu eZ0YJ7V6aLS3B+WFB9BUscUadI1/KjlHc8u2t6H8qURueiMfoK9VBX+4v5U8N/siiwXPKPIlP/LJ /wDvk04WtwekEp/4Aa9UJB6qKQBRzsWiwXPLhZ3TdLaY/RDThp96f+XS4/79n/CvUBj+4v5VIrY6 KtFgueWDTb49LO4P/bM07+ydR/58bj/v2a9UEh9BTxI3tSsFzygaTqBOPsVxn/rmaX+x9Rzj7Dcf 9+zXrG8+1LvPtRYLnk50fUh1sp/++DTTpOoDrZzf98GvW959qXccdF/KiwXPJBpGoHpaS/lThouo n/l0k/KvWOB/CPyp2eOi/lRYLnlC6DqbdLSSpF8N6swyLN/zFep7vYflQHbOcCgDy3/hGNX/AOfN vzFPTwrrDf8ALoV+rCvUfMb0WjzW9Fo0A4HTvB9xHMsuo7FhXkqDkmu0spYdgjhVVVRgAVLLIxHR fyrIuGNvciVMKpPIFUhWubuBS49hUcUgkjVh0IzUgNWQFJjnNOzSZoAXn1pkkSyxlHUMp4INOozi gLnmXirQjpdz50I/0aU8D+6fSufr2HVbCPUrCW2kHDjAP909jXkM0TwTyQyrteNirD0IrOSsaJ3G UUUVIwooooA9RopAKXFaXM7ATik3Cmup4xmhEJbByAaLhYdkUuaYowafRcLBmjIHeihgNp+lK47A GHrRuFRKD7fnUrgBUx1IOeaVwsKCDzS01R8o4p+B6Ci4WEzRnmlx7CmSjkdqLgSBval3c0yMdOQe afIB5nTv0pXHYXNLmkH0pcUXAUEUu6io25kx/T/61FwJg3tShhnkCljUnsfypqghh/hRcZICPQU7 I9BTRn2p4BouAufYUBs54FABpqqTI1FxDyeOgoDewqQrmMj/AD/OoVBJ/Ci4x+RQCPagKT0p4hY+ lK4DCw9qaXHpU32aQ+lNa2kHpRcCtI4x0FZ14Q0ZHetNrWVugFVprKcg8Ci4DtLl8y1AzyvFXcn1 rN0ZTFdSwSDnGa3FijI5B/OrTJaK2T60m4+tXBBEfX86DbxerfnVXJsU9x9aN59at/Zo89TSeREO pouFiujetefeOrAW+qJdIMLcL83+8P8A62K9GaFP4Tiua8a2n2jQpHAy9u4f8Oh/n+lJ6oa0Z5tR RRWZoFFFFAHqI/Cj8qX/AD1op3JGkZ9KUKB6D8qXPHBNAY46n9azcnzWHbQiXrnPrUgqOPgD6mpa 0EFGM8c0Ud6VxihOaHHKjJ70H/PWkc/vIx9azhK7Y2hwGBS4pF6U6tBCUbcsKU00H5wDik3oBIF7 Ujr85oBGeo/KkY5duQeR3rKnJvcpoWnCmilz9K1JHZoUfvc8dPSmE+4/OhHHmHJXp60m9Bl2Lbnk D8qcDHuzgflVdXAP3l/OmqwJ+8vU9zUQba1Bl9Qnp/OnAL6fzqmrY/iH61Irj+8PzNaAWgq+n6Gk RE3McfpVcuP7y/maRJUw3zr196T2AvbIyPu/oahEKjsfyNRean99f1pEdT0YdPQ0o3sDJwijoD+R py/7rDHsear71zjcM/Q0bk/vD8jVAWifY/kaYxPof++TVcsmOo/75NMZk/vD/vhqQE24jPDf98n/ ABqORiAT8w/4Cf8AGqzFPUf98GoX2Zzu/wDHGp2AbDJt1hG/vLitrfXNGTF9CQc89ea3N9XEiRZ3 0vmVV30u+rsSWd9NL1X30F6LATbuaqanH51jcxbd3mRMuPwqTfSS3AghaYoJBGpbae/FJ+Q0ePPD JG5V0YMDggimV6UPFlg+R/ZkGW4yRXFeI0hTVG8j7rKCeMc1hGfNurGrVjKoooqxHqIPHX9aQk45 xg+5pdvuPzNMl3KFxt5/2iKBCZyq9P1p3boP1pmcBef1NOU5P/66lrUAQfN06fhTz97/APXSIMP9 falYHd2x9DVAGMjpScen6U/BEbHjj2NRDp2pAKQeOB/3xSOGyhA7/wByk7Dj9DSsAyjI6H+6amK1 GSjiMZ5PsP6Uo5/hI/CkPzRgfTqP6U5UbP8A9h/9eqbEI+Rxj8gDTDncMZ/IGn3CnfhtvK9NuP5V GcZHH6UDHDOe/wD3yKcMlz17dhUQ6/d/8dqVSN+dv6VMVYGPPB4B/ClCk98fXFI2Cw4H5ZqWPg8Z /IU7pCIiDnv+lNUHzDhm6eooZvnPTg+lRljk8fpTYFhSc/eb8xTo8knJY/iKrKxz0/8AHRUqHBP+ FTHQZNnDfxf99CpBnGd5HtuFVOs3bOP7n9atKf3Y5I/EU72AYXOfvP8ATeKYsjDPzt1/56Com4Y/ /EVGM5PPf+4KbAuiRsH5m/7+CliYlfvMeP74NU1J9T/3yKfGcDGfzWlEGT7vmPJz/wBdBSliP4j/ AN/BVaL/AFzcnH+5j9aml5iPzE+2M/pRcBfM6/Mf+/opjScfe/8AItVtxBOc/wDfqmM2e5/79UwJ mf8A2v8AyLULyf7X/kWoWb6/9+qhk/H/AL90wFkf/SIjnJ3f3s1t+ZXMk4nTr1/u4rd38CriTIs+ YKPMqtvo31ZBZ82jzarbqN1MRY8ynbwyEYzx0qruqSNuv0pDPNtSup/7QuFDlQshAA4AGaoMxYks SSe5q1qn/IUuv+urfzqrWJqFFFFAHq27n7x/76qK4OfL78/WlLfMee/qKjlILJzkg8d6zp9QYA8A 8/8AfVOH+eaRQSnfP0pwB9/yrQQvf/69OJHHP6008dzSMx4wf/HqiewIeSPLb1x61Cpyo+lOLHY2 fT+9TIskD6UQ2Gxw6dvzpccdvzNGD70pyFz/AFqhDh0Gc4pwIz/+uoSwC5JAP+9j9aQvhuSP++6x qt6WKRNcH94vXG30wKiPbpQ7AyLjbkKeQxP607sOtaoQg69qeOtIAT60h4OD+tMCQct0P41Kh56H 8qqhhu4K9PUinK3P8H/fVYzbuhoGJLtnP3j1pp60gIJbG37x6Upx61qIUZqRSR6/gaYAfSkyP9mg B6sTOeG6dzVlHPbf+YrPVh5rY2dPcVKjDPPlfrWM78ysNbDnJ3Hr/wB9VFznr+tLkZ/h/AGgYzjj P0rYQqk+p/OnqSPX/vrFNKlVyRge60zcP9n/AL5zQBJC375+Dkf7VTMxMRHzfi4qjGw3MTs/75NS FwVPMf8A37rOXxDRGx5P/wAcqMt/nzKQnk9Ov9ymM30/74rQQ12/z5lQu2fT/v5TnPP/ANrqN29v /IdNARMT5in3/vZrZydoxWKWzIoI7/3cVsbuBVxJY8sRSBqaWpN1XYkk3UbqjzRup2ES7qfG3NV9 1Pjb5qAPPNU/5Cd1/wBdG/nVWrOo86jc/wDXRv51WrE1CiiigD1Ddyee/qKRm6c9/wC8P6VNx7UE DH/1xQo2JuRr93t+dOH+eacwG3rUY4PQ/pSbsNDpeo5z9Dmoi+Djn9KfM25h1/HBpn4UNXQAHOD1 /MURHIH09c0o+g/SlTAoSsgFxn/9YpZDiIY657HP6UwjB6foKSY/uACDyfb+lSnd2GIzEKTk/mBT WkIbqf8AvoClx8px6+gox9f0pyjcLhvJYHcTwf4xUp+6KZjpn+lOfkD/AAzTEPTAYZ/nimOf3hxn Hsc/rSxnBAwfwwKZKQZ34OeOvNSncYm8h+C3T+8KFlOfvN/30KQjn/61KPp+gocbhcVGyTyTk+ua Uk5HX9KB16U0jMnAB4/u5pgWFxg5I/FqiLH1P51Ih9m6eoquMdgO/akncBBIQ7fM3T+/SiZh/E3/ AH8FIetC/wCelDimFyRHLdyeP7+aFb5zknHuwpFpqffY44z2ApgWJGXy+NoPs5zVcueeW/76qdzm I8np0yP5VUPf/wCJpJ3AZ5pH8RH/AG0pfOJ/iP8A38ph/wA8CkDfT8hTcbgO3Zzyf++6jZvr/wB9 07OR/wDWqNv8/LTAjZue/wD33UTN9f8Avunt1/8AsahY89/++aYDQd0q/X1zWnuOeemKzE5kX1z6 VfdjkVcSWS7qXdVcPS7qsgn3CjdUG+l30wJt1SRnn8Kq76ntsyOFHVuBSYHAXxzfTn/po386grsd T8D30QmuRJFszkLkdT2rjiCCQeCODXPGSlqjWwUUUVQHrOKQjimhjRupkhjtijHPU00uVOfSk8/n 7rVlUT0sNDZeZAM9qTGfT8qR5MuWweB0pwrQAAx2FH3aWmtQBIVGetQ3ZCwryfvCpDKP7rflUNw+ 9FAB69xXPBS53fYp2sOC4yOvPpTto9B+VAO71H1p1bkjSoIHA/KlGGYCg00MFfJzj2FJ7DJUwG5z Ucu1riQDPAFHmLno35UwuPOc89B2rGjzWfMOQuM9h+VKFHoPypQKWtxDcYOaWPDMT6CkNNjcKzA5 qZXs7AWEIB7/AJ1XAyM/WpBIue/5VGjAjH1rKjzNe8OVgx9KAMdh+VOxRWwhvSiHq5obpUcUgAbO evpUzvyuw1uWd3yEc9P71VCKl3jB6/lUYOfwqKPNy+8OXkRlfp+VJt+n5VIaaa3IIyMConFTNUL0 AV2B3Z4/KoWHzE/0qdqhegYQDMy/Wrkh5qraj98D6c1M7c1pElhupA+ehzTM0mcVRJLupd1Q5pd1 MRLuqeMnypCCAQpwT24qmGqa4k8nSbqU9oyPz4pNjRj2mspbSFnnLgAjABJP51gSyGWZ5DwXYsfx ptFc6ilsat3CiiiqEep0UZpM1pYzuI3So+Pb8qkJqOlyhcQgf41MKjp+aLDuLTWpc000rBcjIGT0 /Kk2AjjGfpTiOaAPaiw7j4xgfU0/8aYmcc07NFgENROM1KTUbjPalYCMA5608Lz9aTHtTgORxRaw 7kuKKSjNFgEIqBgQ5wanNRsOelKwDVBz1p8anP0pAvtT06nihKwD9tJilpKLANYcVVC4J+tWmqEr 7UWAaoODT0XqfWkVfanqOOlJKwxpFNIFSYpppiImA9KiYCpyKicUAVXFQuOKssKhkA9KdgEthgsf akc806L5YSfWomyTVrYlhmkLUYNGDVAGaXNG00bTQIUE7hxVfxFc+TpsVqD80zbm+g/+vVyCMs4z wB1Ncxq939s1CSRT+7X5U+gqJMpIpUUUVBQUUUUAduPEFkf+Xhf++W/wpf8AhILL/nuv5GuHoq+c nlO4Ov2X/PZfyNA12yP/AC3WuHoo5w5Tu/7asv8An4j/ADp41i0P/LxF/wB9iuBoo5w5Tv8A+1bX H+vi/wC+xR/atr/z3j/76FcBRRzhyne/2taf89k/Ogavaf8APdfzrgqKOYOU7/8Ata1/57J+dL/a 1p/z3T868/opcwWO/OrWn/PdPzpP7Wsz/wAt1/OuBoo5h2O/Gp2n/PZfzpw1O0/57J+defZNGaOY LHoX9pWvedPzpRqVqek6fnXnlGaLhY9E+323/PZPzpPt1t/z2T86883H1NLuPqaLhY9EF7b/APPZ Pzpwu4D0lX8684yfU0u5vU/nRcLHpH2qL/nov50faYv+ei/nXm+9/wC8fzpfMf8Avt+dFwsejfaI j/y1X86Tzoj/AMtF/OvOt7/3m/OjzH/vt+dK4WPRxLH/AH1/Ol82P/nov515wJpR0kf86PPl/wCe j/nRdBY9H3p/fH503cv94fnXnf2ib/nq/wD30aUXU46TP/31RdAegll6bhUbkeorhPttz/z3k/Ol F/dDpO/507oNTtGNQuNxwOa5MajdjpO/51qaXq4GUu3+jGmmhO5tFdsYAqPaaYdTsCcm4X8qP7V0 0dbj8lNVoIfsNLsqH+29MX+ORvolNbxDpq/dinf8AKLoLMs+X7UoiJPSqDeJ7Yfcs3P+89VZ/E9w yFbeGOEn+LqaXMgsyzrV+lrbNaxH99JwxH8IrmKV3aRy7sWZjkk96SobuUkFFFFIYUUUUAFFdt/w iun/AN+b8WH+FKPC1gP+eh+rU7CucRRXdp4Z00dYmP1c/wCNSjw5pYH/AB7/APj5/wAaLBc8/or0 IeHNLx/x7/8AjxoHhzSx0t/zY0WC557RXoq+H9NHS2U/Xmp00XTl/wCXSI/VaLBc8zor1EaVp4/5 coP++BSjSdP/AOfOD/vgUWA8tor1MaTp+c/YoP8AvgU8aXYf8+Vv/wB+xRYZ5TRXqp0mwPWyt/8A v2KBpGng5Flb5/65iiwHlVFerf2XYjpZW3/fpaX+zLHvZW3/AH6X/CiwHlFWLexurpS1vbySqDgl VJFeltpWngf8eFp/35X/AAqMlbQoIUWOMHlVGBRYR5+NF1IkYspuf9mnjQNUP/LlL+OBXp46UDFV yi5jzH/hH9V/58pP0qrd2F1ZEC5gePPcjj869ZwD2qrqFlFe2ckEq5VhRyhzHk9FS3du1rcyQuCC jEc1FUFBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeoA04GkxTh 9Ku5NgzSg0AUuKVwsANOFJinAUXHYUU6mgU4ClcBQadmmhaXAouA4GnZpFAJqdIkP8VK4yPNGase QuOtL5C460XArZPpSEn0qz5A9RQI1B5ANFwKbE+lZN4xIYYro3SID7i/lWZKkBJ3RqfwpXAIJC8E bDuop+80mlun2NflHDEDPpmrvmqOgH5VomRYph2/yKUSEHmrYkA7D8qDIh6qv5U7iscF43tFSWC6 QY35Rv5j+tcpXfeNkDaSSP4ZVYfqP61wNRLctbBRRRSGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFAHqu3ilVQKkK1GRg8CkwHYoKjFOjGRzTnx0FJS6AMAApeMUjjGMCnIec Gi9gEPQU8dKVsbeKRh8lJO+oC8YNJjjvTRkKKmGNvWk5cq1GAB4qVRUWfT1pqlt5p9BFkEjPNP3f J1qujfLzTtw2YzSbs7ATF8Ec01nHHIzVeXPy4pjEgjrTAlkk46isqaTk8/rVuUnB5rInJANUgLOn SbYGGf4zVwXA9ayrI4hb/eNWNxrVbEMu/aB60n2mqfmUhcU7ElTxSfO0OU8/KVP61wNd3rN8tppz b1LrIdhXHWuENRLcuOwUUUVJQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAetKylQSwpGKkdRUJtYf73/AI9UbW0X9/8A8eq/ZmfON89hLjPHWrUMgdNxI5qhJAi8hv8Ax6qz nb0c/nS5B8xuMykdRVa5kKkbTWM07A/fNMNxJ/fpchVzdhlO5VY9eat7lxjIrlTdTDpIaQ3k4/5a Glyhc6kkbOo4qmHdpMZ4+tYBvrgD/Wn8qT+0LntKfypco7nWQSBkyTUgK7s5rkP7Sux0lP5Cj+1b wdJm/wC+RRyiudVctiH5TzUKF1VWPqK53+1r4f8ALZv++RSjV7/P+uf/AL5FHKO51m4MopGwTXKf 2tqIPE0n/fIpw1fUs/6+T/vkUWEdHKMisu5Tg8VnnWNTz/r5cf7oqN9V1DHM0v8A3yKdhl22bEbf 71S+ZVC2lZrfcxySxJNP82tFsQy4ZARTC9VTLSebVEkl9p41S2EJuI4Nrbt0hAH05IrO/wCERjx/ yF7XP1X/AOKqTWJFGlMzKGwwwCcc1zHnnOQij8/8awmpX0ZrG1hksZhmeNvvIxU/UU2ldi7s7HLM cmkpgFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHoh+0/3Yfypp+0f3Iv ypxLf3R+QqMk/wB0f981tYyuIzS90j/I1CznuFH4U5if7o/75qF8+n6VNh3ELr6j8qb5iDq4/Ko2 qNs+ppWHcsiaIdZf/HaXz7fvMB/wE1SP1P50059T+YpWKL/nWv8Az84/4CaUTWn/AD9gf8ANZuT/ AHm/MUZP95vzFFgNQT2Y/wCX1f8Avg08XFkP+X5f++DWTk/3n/NaXcf77/mtKwGt9qsh/wAv6/8A fBpftll/z/L/AN8GskOf+ekn/fSf4UvmN/z0l/76T/CiwGob2zP/AC9/+OUn9oWg6XP/AJDFZnmN /wA9Jf8AvpP8Kd5rf89Zv++0/wAKLAaB1G0/5+T/AN+hUE19bMhCzMSf+mYqt5zf89Zv+/i/4U1p WI/1s3/fxf8ACgCWNgsCgHg5NIZKZIcBRnoKhJNaEFjzKPMqtupQSTTAi1yf/RIYQeWbcfwrCq7q s3mXW0dIxtqlWT3LQUUUUhhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB 1X/CT2xJzbv9QRR/wkdmesMo/AVytFXzsnkR1LeILE/8s5vyFRNrtkTwk3/fI/xrm6KXMw5UdCdY tSf4/wAqadVtj3b8qwKKOZhym4dTtz/EfyNH2+2P/LTH4GsOilcdjbN7b/8APUfkaabyD/nqPyNY 1FFwsbH2yH/noPyNH2yH/noP1rHoouFjXN5D/fH5Gm/bIv74/I1lUUXCxq/aov76/lR9qi/vrWVR RcZrC6jP8a1YtSs0oCshxyQDWDUttcPazCSPGR2PQ0JiaOjkUs5pnln0rN/tu4zxHCP+A/8A16cN eux0SH/vir5kTys0RCfSo7lhaW7SsMHoo9TVQ+Ir3GAsI+iVnXN1NdyeZO5du3oKTkNIhYlmJJyT yaKKKgoKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoqwtjdN0gk /wC+aeNNuz/yxI+pAoAqUVe/si8xny1/7+L/AI0f2Ref881/7+L/AI0AUaKvjR7w/wAC/wDfYp66 Hen+GMfV6AM2itZPD943eJfqx/wqZfDF23/LaAfif8KAMOiuhXwncn/l4h/Wp18GzHreRD/gJosF zl6K65PBDHrfoP8Atn/9epB4DdjxqEf4p/8AXosK5xtFduvw9dv+YlH/AN8H/GpV+HLEc6nHn/rm f8aBnB0V33/Ctz21NP8Av3/9ej/hWz5/5CUf/fBoA4GivQk+Gw/j1EH6LWhH4WTRLGSW3aOYr8zl uWI9uKdhHluD6GgAnoDXrsKQSxK4iTDDP3RUqxRDpGg+gFVyE8x46QR1Bor2Pyou6L+VUr/RrG/h aOSCNWPR1XBBo5A5jymirmq6dNpd89tOORyrdmHrVOoLCiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooA67A9KOKZuHqn5Uufcf981QD8j2/MU9WHqPzqIZ9f0p659TSAl DD1FSKR/n/8AVUI3erfnUihvU4/3qBE6n6/kamVj6H8jVcD1I/77NSqF9U/FzQBaRj6N/wB8mp0L f3W/75NVECf3ov8Avs1Onld2g/EmgRbTef4X/wC+f/r1ZjD/AN1/y/8Ar1UQQd2tfxBq1F9m7vZf ihNAFtFk/uv+Q/xqZVk/ut/47/8AFVChtf79h/35NTqbX+/Y/wDfg1Ix67/7p491/wAakAb0P5p/ jTA1t/es/wDwHNKGt/79p/4DmmBIM+n/AI8n+NI670KkZBGD8yf40m6D+/bf+A5o3Q/37f8A8BzQ M5mwEiRPFg/uZGT171a/eejflTYHWHVb+NGUqXDjau0cj0q8Jz61omQ1qVMv7/lQGf3q55/vR5/B p3Jscl4zs/telLdKMyW5591PX+lcDXr2poLjT548DLRsvHuK8hqJFxCiiipKCiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigDrty/8APZz/AMApMqf45Pyp28f8/Dn/AIDSbh/z 0kP4VQw455elH0P40h69ZPxFIMf3XNICQfQVIvH8KfjUK/8AXMmnqD/zxH40CLCn3iFSo/8AtwD8 KrgP2hSpVEvaGL8aBFpJcf8ALe3H/Af/AK9WEnx/y924/wCAf/Xqoom7RQfjUyfac8Ja/iKYi6l0 AP8Aj/tx/wBs/wD69Wor0DH/ABM7cf8AbL/69UUN2Ogsx9RViN74dDYj6rSA0Y9QX/oMQD/tiP8A GpxqKd9Zh/78iqMcmodpdPH/AAH/AOvVhZdQ/wCfrTh/wAf40hlkX6f9BiP/AL8ilF+h/wCYuh/7 YioRNqH/AD/aeP8AgI/xpwmv/wDoI6eP+Aj/AOKoAl+2p/0FR/35FH21P+gr/wCQR/hUXn3v/QTs P++R/wDFUG4vf+gtYD/gI/8AiqBmHdTBtduHW5M4aJcsV2/hin+d71U1OWVtbczXEVw3kj5ogAOv saj8z3rWOxnLcv8Ane9Bm96z/Mo8yqJNFZs+hrlNU1m2kt57eXTbSF+V3Icsp+ma3Y5PmFeeaku3 UrpT2lb+dZVI3sXBlaiiipLCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig DsTv/wCei/lTSW/56fpVho2H/LICo2Vh/CBViuQE/wC2aTcO7MalIb6fhTCT/fx+FIdxmV9XpwZP SQ0hY/8APUj8KN//AE3b8qQx26L/AJ5yGnq0X/PGQ/lUXmj/AJ+X/I0eeo/5e5fyNAi0Hi/59XP5 U9ZIf+fKQ/lVT7Qn/P7N+RpRcx97+4H4H/GmIvrJD/0D5D+I/wAKkWSL/oFyn8R/hWcLuIddRuh+ B/xp4vIP+gneD6A/40AaiSRf9AeY/iP8KnSVO2hyn8R/8TWOL62HXVb/AP75P/xVPF/a/wDQU1I/ gf8A4qkBspJ8xI0SUj0JHH/jtTCVsf8AIBf8/wD7GsMX1n/0EtSP4H/4qnC9sf8AoIamfw/+yoA3 PMl7aA3/AH1/9jQZJu2gN/30f/iaxPtth/z+6mf8/wC9TWvNP/5+dUP+f96gCS5djqjl7X7KfLHy E579egoL1RSWN7mVommZdoGZfvfzqTzK0iRItbvek31W8yjzKoRcjf5xXD6swfVbth0Mrfzrr4ny 4rirpt91M395yf1qJlRIqKKKzLCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigDv3iA/wCWDD/gVQOmP+WJH4092TP3Yv8Avo1E5X0T/vo1oQRsv+xio249PypzEei/nUZI/wBn 86QxCfdfypC5/voP+A0hPutNJ9x+VIYvmMP+W0Y/4B/9ak81v+fiL/vj/wCtTd3+0P8Avmjd/tD/ AL4oAeJm/wCfqL/v3/8AWpwnYf8AL7CP+2f/ANaowx/vj/v1S7z/AM9B/wB+aAJBcuP+YhCP+2X/ ANani7k/6CkI/wC2P/1qh3n/AJ6j/vxSiQ/89/8AyXFAFgXj/wDQZiH/AGwP+FOF43fXYx34gP8A hUAmb/n4x/26ini4f/n6b8LQUgJjek9dfU/9u5/wp41A4x/wkBx7W5/wqEXL/wDP5J/4CCnfaZe1 5P8AhaCgCX+0W/6GGT8Lc0xtQ5z/AMJBOT04gb/Gm/apv+fy5/C1FNa6mx/x93X/AH4AoGRJLueR zO0+SPnYYJpd9QgkoWYliSeSMGmb60RDLO+jfVfdRuqiS9buBIGOMLyc+1Y3iTUItRlglSKCJ1BU rEcgj1NWrqfydPnY9WXYPqeP5Zrmqxmru5pHYKKKKQwooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooA7x0Oc5NQup96w28SXZ6JGPzNRnxBdnqsX5GtOZEWZtsD6mo2H1rGOu3R /gi/I/40061cH+CL8j/jSuh2ZsH8fzpp+p/Osg6xOf4I/wAj/jTf7Wm/uR/kaVxmufqfzpM+5/Os g6nN/dT8jTf7Sm/up+VFwNnd7n86N/u351jf2jN/dT8qT+0JvRfyouBs+YfVv++qPMP95v8Avqsb +0JfRaT7fL6LRcLG15p/vN/31S+cf7zf99msT7fL6LR9ul9FouFjb84/3m/77NL5x9W/77NYf26X /Zo+3S+i0rgbnne7f99mmmXI6n/vo1jC/k7qv61Zsr1HuVWYKi/3ieBTTA1WG2NR7VCVyala5tWP /HxF/wB9CgTWh/5eYf8AvsVehJGFPrShTUwe0/5+7f8A7+Cq11qFrbKfLdZ5OwX7v4mhsClrUuPK tweR87fU9P0/nWVT5pXnmeWQ5dzkmmVkWFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH/2QplbmRzdHJl YW0KZW5kb2JqCjEzIDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0NvbG9yU3BhY2UvRGV2aWNlUkdC Ci9XaWR0aCA0MDUKL0hlaWdodCA0NDgKL0JpdHNQZXJDb21wb25lbnQgOAovRmlsdGVyL0RDVERl Y29kZS9MZW5ndGggMTA5MDQ+PnN0cmVhbQr/2P/uAA5BZG9iZQBkAAAAAAH/2wBDAA4KCw0LCQ4N DA0QDw4RFiQXFhQUFiwgIRokNC43NjMuMjI6QVNGOj1OPjIySGJJTlZYXV5dOEVmbWVabFNbXVn/ 2wBDAQ8QEBYTFioXFypZOzI7WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZ WVlZWVlZWVlZWVn/wAARCAHAAZUDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQF BgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi 4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl 8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImK kpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP0 9fb3+Pn6/9oADAMBAAIRAxEAPwDzaiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAW ilooASilooASilooASilooASilooASilooASilooASilooASilooASilooASilooASilooASiloo ASilooASilooASilooASilpVRm6Bj9BQA2ineW/91vypfKf+4/5UAMop/lP/AHH/ACo8qT+4/wCV ADKKf5Mn9x/yNNKkHByD70AJRS0UAJRS0UAJSU6m0AFFFFABRRRQAUUUUAOortj4R07tPdfiR/hS Hwlp/aa5/Mf4VXKxXRxVFdsPCenAcy3JP1H+FH/CKaf/AM9Lj8x/hRysOZHE0V2w8K6cD96c/VhT T4Wsc8GXHu1HKw5kcXRXajwxYD+Fz/wI09fDenDrEx/4GaOVhzI4eiu8Hh3TB/y7k/8AAzTv+Ef0 vj/Rj/32f8aOVhzI4Giu/wD+Ef0s/wDLqf8Avo04aDpg6Wo/EmjlC559SV6GNE08Hi1T8RUsek6e v/LnCfqgpWC55vRXpw07T/8Anyg/79ipFsbFellAP+2YosFzy2jFepmzs+1pCPogoW0tV/5d0/IU WC55Zj60uM+teqrb269IVH0FSqsQGPKX8qLBc8l2n0NL5bf3W/KvXVEY6RKPwqQMv/PMflRYLnj4 jc9Fb8qPKf8AuP8AlXsPyZz5a59cU7Kn/lmv5UWC5475Mv8Azzf/AL5NJ5Mn9x/yr2T5T1jWk8uI jmJPyosFzx4W8x6RSH/gJpfss/8Azxk/75NeviGEf8sl/KneXEB/qlosFzx8WVyekEv/AHwaeunX jDItZj9ENevARjpGKVWAPCUWC55D/Zd9/wA+k/8A3wacmkag/wB2zn/74Nev+YP7n60vm/7P60Ae Z6Z4Vvp51N3E0MA5Yt1rvtPt7OGJYoIkAUY6CrE8gZcFMjuCayHc2lyGQbYyenpTWgnqbPkRHrGn /fNOESAcIo/CiNw6Bh0Ip4NWQM8qP+4v5Uuxc5AH5U6jNMAGRUN3aRXcDRXCCRG7EVNmgHFAXPKv EmiSaPecAm3kPyN6e1Y9eua/pi6tp0sB+/jMZPZu1eSOjRuyOCrKcEHsazkrGidxKKKKkYU2nU2g AooooAKKKKACiiigD1PJ9TRk+tIKX8a0uZ2Dd70bvemSZyKRFLNjPWi4WJN3vRn3NRqMHnmn4ouF hcmjJoxSMPlNK4WHZ96N3PWoV3ehqR0Cqp/vA0rjsODe9Ln3pqD5RTgBRcLBketAYZpeKZJnjFFw JAwpQwpkeTjJ7+tOcDzOOmaVxjs0uaSlxRcBwoyBSYqNj8+Mii4E4I9DTgQT0NNjAPp+dIv3hRcC UY96cMehpgHtTwPai4Dsj0NAYehoA9qYozI3tRcCTdx0NAb2NPK5jPtUKjJ/Ci4EmaARSBfanCJj /DSuMQkUhYU7yJD/AA01oJB1Wi4EUrjHes2+w0Z9RyK0HgkbohqpPazEH90aLgWNLm8y1X1Xiru4 1l6ECs0sEgwRzitxYEIPJq0yGivvNG81Z+yof4z+VBtF/v8A6VV0KxV3mjefarH2QZ4f9KPsijq1 F0FmRK+eteceONPFnrHnoMR3Q3/8CHX+h/GvSmt8fdYVzHjy08/RvOx89u4JPseD/MflSeqGtGec 0UUVmaBTadTaACiiigAooooAKKKKAPUxmloA/wA4oxTuSNYEilUEYP8An+dLkADp+lJu45x+lZuT 5rDtoRryc1IKij6D3JqatBCUuMgij8aAeetK4CCMZpXX7o470u73/WkckvH+P+c1nCTb1KaFUYAp 2KReRTq0JEpGXLLmnGmqfnHWk3oMeqY6cUjj94Sc9aUdetDkl27dKypyctxtWCnCmilzWoh3FIoB lHfj1pMmiMkyH6Um7IC5CFz/APXNKEjLE5/WoUJBpFLZJ9z3FRCTaGy2scft+dOCJ7fnVZXYd/1F Sq7ev6itBEwjT1H50JGm5j/Woi7D+L/x4URyEhvm7/3hSewyz5UZB5/WoRCo/iP50eYcfeH/AH1T Vkb+/wBv71KLugZIEUfxfrT1ZecN096h8w/3x/33R5h/56D/AL7piLBfH8X60xpP9ofnUBkOP9YP +/lNaQ4/1g/7+UDJPNxn5v1/+tUckvB+cfn/APWqBpDn/Wj/AL+VC8jZ/wBcP+/tFhEdvIE1gN/f XFbe+ua8zbfwnPf1zW5vrSJMiz5lL5nvVXfS76uxNyz5nvTS/vVffSF6LBcn3VR1mIT6deRsCwki Yfjip99JLPHFG0sylo0BLAHGRSeiGjxoggkHORSV6U2peFpWYtpoZ27nHJrifENrFa6kywbdjKGA XoKwjPmNWrGZTadTasQUUUUAFFFFABRRRQB6kDx60E+2PypQp9P1FMl3KF+Un6EH/wDVQIM/KvP/ AI8KXPH/ANlTAcBe35U5Tk9f1qWtQCMfNinng4/rSIPm69felbO7gDH1qhB26/rSZHr+tO5CHgf9 9VHk98j8aQxSenT/AL6NNkPzI2Bx3yf50u7gc/8Aj1DncFO7of71TFWY2SjiME8UAg9P60HmMEH8 c4pVB/2T/wACNUIR/l4PB9800n5gRj8jT5wwbGAox2JH86jJAYc/rSAcDz2/I0o++eB27Gowwz1/ U1KhXf8AX3NTFWGxxIBA/pTgpPQD8qRsbh2/GpY8E9j+BNWIhIOf/saYqneTgdP7lOdsOfr61GXA Y8fqaQE6g+g/7906Mcn/AOJxVdX56D9aljbBPT86UdAJuh7/APfFSANjI6f7lVM/vuo/76P8qtKM oOn/AHzTuA0sc98f9c6Yhb5uD1/55CoCcMeV/wC+jUeeT9zr70PYC8CeeD/36FLEWxznp/cxVNTg fw/rT4jgYyv5kURBljLbyfnz/uUpZx3b/vgVViwZmyU/AkmpZQBFn5fyouBJvfn7/wD3wKYzv/t/ 98iqYdQTzF+ZpjOp7xfmaYyyzP8A7f8A3yKid5M9X/75FVXdcdY/zNQSFR/FH+ZoESSMRcRHnO7u MVt7xXMFsTpgqeexNb2/itIkyLPmCl8wVU30u+rILPmijzBVXfRuoAs+YKUlZImVhkEYI9arbqfG 3X6UAeb6hdNHezpEiRqjlVAUcYNUZpXmkLysXY9Sasarxqd1/wBdW/nVSsbGwtNp1NoAKKKKACii igAooooA9Yxz2/75FRXOMxjjr6f4UpPzHgdfSo5jymfX6VnTd7gwA4HH/jtOA9j+Qpqj5O1OH4fl WhI4cGnenP8AKmnIP+FDE8cH8s1E3aI1uOP+rf6VAv3R9O1SZOxuD0/u1HFyo+neiGw2OGfQ/pS8 47/nSc/5FLzj/wCtVCHg9OaeGwfvfrUW4475/D+VJubPRvyFYVXaxUSS5YGVeR93/PNRnPUUSsS6 /eztPUg/pRjgf4VstiQGf8mng800D/OKM/WgCQEbuv8ASpUYZ6j9arhju4yePUU5WbPRvzFYzeqK Q1jl3/3vTFNOc0Zyzf7x75oxWxIqk/5NSKcf/qzTBRn/ADuoAcj/AL48np/dxVlHH1/4AaoIx85s ZJA/v1MjtkfKf+/mKxqN8yKWwOx3Hr/3zUeWGaU8nkf+PZpvHoPzrYQ9WPv+VOUkf3vypnAHb86T I9v++qAJIXzK+S34rUzMfKP3v++MfrVCJvmc4H/fdSl/lPCf9/DWUn7w1sRs7ZPMn5CmM7esn5Cm ErluF6/3jUbFfRPzNaiFd29ZPyFQyO//AE0/IUjlc9E/M1G7J6J+ZpgMYnzVJ3de9bG4gLgVi7lM igADnsa2N3Aq4kseWxQGphakzVkkm6l3VFmjdQIl3U+Nuar7qfG3zUAeear/AMhO6/66N/OqtWNS 51G5/wCujfzqvWRqFNp1NoAKKKKACiiigAooooA9R7njv/doYcj5e/8AdxUvlr/d/SgxLj7o/wC+ aErEtjFB296cAfelKALgD9KYODz/ACNJuwIdLkEZ/UVEWGen/jtPmI3DAx+GKjwM8jNDV0MXdkHj /wAcoizgdenpigKP7v6U6NQvbH4UJWQC4J9fypZfliB6c9xxTDwT/wDXpJiBCOxJ64I/WpTu7DGu flPAPttzSMfm+6P++KCMqR15+tIVBPIB/A0SjcB38X3ex/gxUp+7UQRePlH5VI/3Rj+v9KoQ+MHc Ov4UyQ/vGH8xzSxkZAP8iaZKR5zgdscdP0qU7jE3Ybpnj+5mhX56f+OU0j5s4FCqv90flQ43C49O /wBf7uKVuo6flSKFB6YpGx5g+nqf6UxFhAcH736VCT/nbUqbT27f3c1XGOMe/c0k7jEDYduP/HAa cHPp/wCQxUZUZPA/KlVV/uj8qHG4XJUOfXp/dAoUkueP/HaagA6AD9KamPMbIGAfc0wLUpPl9H/E g/pVcsff/vipXVTETjt/dqqSOen5mkncBBIRng/98Cl8w+jf98CoWA7qD+BoAX+6v5GhxuwuO3Hn 73/fIpjMf9r/AL5FLxjsPzqJsf7P60wGuxz1b/vkVEzt/tfkKVsZ/h/Wonxn+H9aYDclpV5PXvWp 5hzj2rLj5kXGODV92wRVxJZNuo3VAHo31oQWM+9Gag30u+gCXdUkR5/Cqu+p7fLttHU8ChgcBfnN 9cH/AKaN/OoK6PUvCGrQvPP5BMWS2T1rm+lYJp7GotNp1NpgFFFFABRRRQAUUUUAetbR6CkKjHSg PRvpk6DSAeKAvPb8qTzMHJoM6Z/+tWVS+lhoZMPnAGOlN25okkUuSOgHpThWghAoHalAC0tNagY8 pz2qK7wkSnIHzVI00f8AeHFQ3To6KFIPNc8Obnd9inaw4LjINLtHp+tKCGzt9adW5IwqMD/GnDDE D0oNNVlV8sQBSewEqKA3P8qilCm4kCnoB2p3mJn74qMuvnOcjGBWNFyadypC4z/+ugL/AJzTgKWt yRuMHNCDLH6UGmxOoZgSBUSvZ2GiwmM//WqsBkZ+tSh1z94VGjArgdeazottajkJj2/WlCj0/Wlx S4rYQ3GKIeS/p9KG6UyGRQGyw61M78rsC3LGRsP09BVQ55qbeuDyKhBB6dqii246jkRlfb9aTb7V Kaaa2JI8YGKicn1qVqiegCu27d7fWoWLbic/qaneoHpgLBzMv1q5Ieaq2g/fD25qaRuTVxJYbqN9 Rk00cdKskn30bqhzS7qYEu6rEDsqOyfeVSV+tUg1TyyCLTbqU9FjP68UmCKtv4juMlb29MkYB3Bp C2T9K5KdxJNI4G0MxYD0qOlrnjBR2Nm7hTadTaoQUUUUAFFFFABRRRQB6rR+NGaTNXYzuI3So6e1 Mo5QuIRn8alAqOpKLDuLTGp1NNKwXIznJ5P5mkZSRzzj3pSOTSgUuUdx8Y4P1p1NQ8dKWiwAaifP Y1IaY4osAwbs9f1pcHcfek/OnjqOtJRsO5IBS4pM0ZosAjCoDuDnB4qcmon696LAIu7NOjBz9KQD 3NPQ8nrSUbAPxRilzSZp2AY44qsAwJ5PX1q03SoCPrSsAgJwck05B1NIo+tSL070JWAaQKaQKkNM NMCJgKidRVhhULigCs4qBxVpxUEgFOwCWowzH0FDtzTofliY+tRMeatbEsM0hakpcH0qhBmlzSYP pRg+lACg8gVH4iuBBpKwD707ZP8Auj/69WIIy7gYrndeuxd6i+w5ji/dr+HX9aiTGkZ1FFFQWFNp 1NoAKKKKACiiigAooooA9EGrWpH+uhx/vij+1rb/AJ7Rf99CvPKKvnI5T0M6rbD/AJbR/wDfQoGp W56SJ+YrzyijnDlPRvt8J/jT8xTheRnoVrzelzRzeQcp6R9rTHUUhuo/7wrznc3qfzo3N/eP50cy DlPRDeRf31oF7D/fSvO9zf3j+dG5vU/nRzD5T0YXsX99aX7ZEf41rzje394/nRvb+8fzpcwWPRzd xf31ppvIf+eifnXnW5v7x/OgOw6MfzouFj0UXUX99fzpwuov76/nXnPmP/fb86PMf++350XQWPR/ tMf99fzpftMf99PzrzcyyH+NvzoEsg6Ow/Gi6HY9I89P7y/nSecn95fzrzr7RN/z1b86PtE3/PRv zouhWPRhKv8AeX86cJV7EV5v9om7Sv8AnThd3A/5bP8AnSuh2PR/NHqKPMHqK85+23I/5bv+dL9u uv8Anu/50XQHohcHuKbnPcV559tuf+e7/nS/b7r/AJ7v+dF0B6GD7ilz7ivPRqN2P+Xh/wA6P7Su 8/69/wA6NAPQT9RTT+FcF/al7/z8NSjVr0f8tyfrRoB3R+oqJ64z+2b3/nr+lKNavP8AnoD+FPQN TrGqGTkgDqa5oa3dj+JT+Famk6qk+VuCiP69M01Zku5pbdseKj2mpWuLc9ZogP8AeFJ9otB965hH /AhVAR7TRsNPN/py/eu4vw5pratpKdbjd/uoTRdC1DZSiMmom1/Sl6CZ/ouKqz+KIVU/ZbQ7+zSH gfhS5kOzJdXvVsbRo0bFxKMAD+EdzXKU+4nkuZmllbc7HJNMqG7lJBRRRSGFNp1NoAKKKKACiiig AooooAdRXV/8Icv/AD+Mf+Af/XpR4PTvcufoKdmK5ydFdgnhC3x808x+mP8ACpR4Qs8czTk/Uf4U WYXOKorth4Qsv+es/wCY/wAKUeELIf8ALSY/jRYLnEUV3K+ErEdTK3/Aqnj8K6aPvRO3/AjRYLnn 9FeijwxpX/Ps3/fZoHhjSv8An2P/AH2aLBc85pa9GHhfSs/8ezf99mnjwzpP/Pp/4+f8aLDPNqK9 IPhfSj/y6n/vtv8AGgeFtKBz9lJ+rt/jQB5vRXpP/CMaSP8Alzz/AMDb/Gl/4RnSf+fIf99t/jRY DzWlVGf7qsfoM16K3hjSAP8AjzP/AH9f/GpoIYNNCx20Kxwk/MOpz60WEebC3mOMRSHP+yaeLK5b OLeY4/2DXrIUegp2AafKLmPJRY3R6W03/fBqKWGSFtsiMjejDFev4FUNY0uLUbN4nAzjKtjlT60c ocx5ZRUk8TQTPE/DISpplSUJRS0UAJRS0UAJRS0UAJRS0UAJRS0UAJRS0UAJRS0UAJRS0UAJS0UU AFFFFABTadTaACiiigAooooAKKKKAPUgx9acGPrTQKcMVdybChj6ml3H1NIBTsUrgKGPqaUMfU0m KUCi4WHAn1NOBPqaaBSgUrjHgn3pQfrTQtKBRcB+6lDfWmquTU6Qbu4pXAZupd1S/Zj6il+z8daL jIN1IW+tT/ZzR5K/xD9aLiKrt9ayb18qwwa6GSCIDv8AnWZNbQMSGz/31SuMfDKWiRvVQaf5mO1N 0vy2s0yM7SV5+tXP3I/gU1omRYqiWlEvPPerI8oH7i0EQnrGKdxWPP8AxvYrBdxXMYwJcq2PUVzF d746jB0wEfwSgj8iP61wVQ9y1sFFFFIYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAU2nU2gAooooAKKKKACiiigD1bbxSotSFaYeD3pMQuKCvFPjGRSuAKSl0AYFFOxxSPxinJycG lewxD0FOHSnMo201h8lCd9QHcAHmk7U0E7RUwHy0ublWoCAcCpUB7ZqPPv0NIsjbz1o6AWQzc88U /f8AJVZHyvJp5b5OtDkk7ATb+lNZsY9zVaUn5cUxmIIpgTyyHFZU8hyetWZmODWTOx5poC1pkpW3 YE9HNXBOPUVk2LYhb/eNT7q1WxDL/ngdxSG5FUd4pCw9aqxJV8XN5uiykHoyn9a4Cu91m7gh02Rb gBkl+XGMn149+K4I1Ety47BRRRUlBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BTadTaACiiigAooooAKKKKAPXVOQCcU1hmoTaOBxK/51G1tIP+WrVXs2Z86D7QRJjtVqJ/MUtxzW dJbshzvNQGSSPhXOKXIPmRtNyP8A69V7iUxkbayWu5R/HUbXkp6kGlyFXNyCYsVDdTzVkkbcVzP2 6ZTwV4o/tO4H8QpcoXOkOAn0qqJpC+BnFYh1a4A6rTf7WnGSBHn6UuQdzqIJA6ZzTwBuzXLDWrhe AI8fSl/t24HaP8qfKK50lyxSL5etQpI4Cs2cZrCOvTkcrCfqtA1+fgbIP++aXKFzpywZQaR+SK5r /hIbkHhYP++KcPEV1n7sH/fFPlA3JRkVlXSnBqufEVz02QH/ALZ1DJrkzA5jtz/2zosBZtGxG3+9 U3mCqFrMWgLHGWYnin+bWq2JZbMgNNL1VMtHm0yQ1PTLjV7ZYbQK0ituwT2x/wDXrL/4QjV8ZxD/ AN9H/CresTbNMZ9zjDDGw4zXOfb3z96X8ZKxnz82hpG1irIjRyMjjDKSpHvSU6WQyyvI33nYsfxp tMYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2nU2gAooooAKKKKACiiigD0c zTf88G/77phml7wt/wB905n9j+Zphk+v/fRrWxlca0rHrGR/wOoWcHqv/j1Pd8//ALRqu5/zmlYd wYr/ALP50nyeqfnUTVG3+eKVhlkbO7RfnTtsR/jh/OqDD2H5U0r7D/vmlYZo+XF/z0t/zFKIYv8A nra/mKyyvsP++KNo9F/74pWGaywRf89bP8WFPEEP/PSy/wC+hWNtH91P+/VLsH91P+/X/wBeiwG0 IYh/y0sv++hS+XCD/rLP8xWLsX+7H/34/wDr0u1f7sf/AID/AP16LCNkiD/npaDFIHth/wAtLX9a yNq/3Y//AAH/APr0u0f3Y/8AwH/+vRYZqmS2/wCelp+tV55LcocSW5PsDVLA9I//AAGH+NNbGDwn /gOB/WgCxE22BRn1NIZKikO1VHHAqIk1oQWfMo8yqu6lDZNMBmvT4sYogeXfcR7D/wDXXP1oaxKJ LlVH/LNcfjVCsnuWhKWiikMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKbTqb QAUUUUAFFFFABRRRQB2v/CQ6aSfmcf8AAaP7d01v+WxH1U1xdFXzsjkR2Tazpx/5b/8AjpqJtWsC cC4/8dNclRRzsORHUHUrMniVfyphv7U9JUrmqKXMPlOhN7bnpIlH2iE9JI/zFc9RSuOx0Bni/vp+ Yppmj/vp/wB9CsGii4WN3z0x99P++hR56f3k/MVhUUXCxtm4j/vL+YpPtCf3l/OsWii4WNrzk/vL /wB9Ueev95fzrFoouFjaEynoQfxqa3UySAY4rn6s2N2bSYSBdwxgjOM0Jg0b8oy5pmw1T/txM/8A HqPxf/61OGvqP+XND/wI1fMibMteV7U2YrbwvK3RenufSoj4jUD5bGIfVqzL6/mvnBkwFH3UUYAp OQJFZ3Mjs7cljk0lFFQWFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABTa dTaACiiigAooooAKKKKAHUUojZuisfoKeLadukUh/wCAmgCOirH9n3hGfs02P9w0f2feYz9mm/74 NAFeirI068P/AC7y/wDfNOGl3zdLeT8RigCpRV5NHv36QH8SBUq+HtSbpAP++1/xoAzKK118M6mf +WSD/gYqZfCOqN2hH1egLmFRXRr4L1Rv47cf8DP+FP8A+EG1Yn5Wtz/wM/4UBc5miuqXwBrDfxW3 /fz/AOtUg+Hmskffth/20/8ArUAcjRXYf8K51jtJbH/gZ/wo/wCFc61n71v/AN/KAOPpK7RPhvqx +9LAPo2a0IPBv9kWjzXcCXZHLscfKPYUwued0V6nHo+lyRqwsYCCMj5akXRdMHSxg/74FPlJ5jyi ivWDoumHrY2//fsVR1Hwpp91CwghFvL/AAsnAz9KfIw5kebUVPfWc1hdSW9wpWRDg+/uKgqCgooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKbTqbQAUUUUAFFFFABRRRQB2AP oT+dLknuf1pmfYf99UZ/3fzqhEnPoaev0qEf8Bpy/wDAfypATqcVIrY7/rUAz7f981Iob3/IUATq 3uPzqZJB/eH51XUN/t/pUyB/9v8AMUAWUlH94fnUyS/7Q/OoEV+Pv/8AfYqwiuf7/wD39oETpL/t fz/wqxHIT3P5H/CoY0f0b/v/AIq1DGe6/ndEUgJo2b/a/wC+W/wqdWk/2v8Avlv8KbHEP7i/+BZq ZYl/uR/+BbUhiqzns/8A3w3+FSKX9JP++G/wpojT+5F/4FNShE/uw/8AgS1ADwX9JP8AvhqbMhli eNlcqwIPyNRsj/uw/wDgQ1BSP0g/8CGoA5jTnZbcxHOYmKHI54NWvMb1pLZhBqWoRfJjzA4w24YI 9avCVe6r+VapkNalPzGpRM1W96f3V/KjdHg/Iv5U7iscd46shPZRXyL88J2v7qen6/zrha9c1iFL jTLmMKPnjYY/DivIqiXcuItFFFSUFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FNp1NoAKKKKACiiigAooooA6/A/56QfgKOO0if8AfNO5H8cH4LSZ9ZI/wWmAmevz/pTgR6k03d/0 0H/fNG4f3z+VAEin/e/OpU/3GP8AwKq4Zf8AaNPBX+65/GgCyoP/ADy/NqmRT/zxT/vuqg2/88XP 41KoX/n2Y/8AAqBF1EP/ADwh/FqsRo3/ADwtvxb/AOtWeij/AJ88/wDAqnROf+QeD/wOgRpRo2P9 RZfi3/1qtwq/H7jTvxb/AOtWSkZ/6BcZ+r1Yjibto8J+rUCNmMP/AM8tKH1P/wBap1D/ANzShWTF FL20S1P1b/61WUt5j00Oy/Fv/rUijQG/00sUvz+umVTEFz20Wx/76/8ArU8QXY6aRp4/H/61AFrc /wDe0yk3t/z00yoPJvP+gVp/5/8A1qXyb3/oF6d+f/1qAMO6Yprlyd0Dbo1J8np/+un+dVTVPNj1 pxNBDAxhHyxdDz17VH5taR2IluaHnUGas/zaTzKqxJpCUNweR6etchqUuhNazLFpcttLghXZuAfy roIpPmFed6nu/tG6DEk+a3X61nUjexcGVaWiipLCiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACm06m0AFFFFABRRRQAUUUUAdkUYf8s4xTTu/2BUzIo/5ZsPrTCuP4KqwrkZZu7LSb j3cD6CnEf7IFNP0QUh3AOR/y1x+FOEo/57N+RpmT6x0u5h/HEPwFAD/NUf8ALeT8jT1nj7zTfrUO 9h/y1g/IU4SuP+W9uPwH+FAFgTw95Z/1qRbm37y3P6/41VEz/wDP1bj/AICP8KetxJ/z+2w/4CP8 KBFtbq17y3f6/wCNSLeWXeS9/X/Gqa3Uo/5iFqP+AD/CpFvJh/zFbUf8AH/xNAi4l7Yd3v8A9f8A 4qplvtN/6fz+f/xVUVv5x/zGbUf9s/8A7GpRqU4/5jtsPpF/9jQMtpe6duOVvmHpg5/9CqUXumf8 8b//AD/wKqQ1Kb/oPwfhF/8AY08anL/0MEf/AH6P/wATQBb+16Z/z7X5/wA/WkN3pn/Ppffp/jVf +1JP+hhX8Ij/APE0xtUf/oYj+Ebf4UAVpZYZNRdreOSNPLAxJ16/jTy1VGuDPeSu10br5QPMIx/P FO8ytIkS3LG6jfVbzKPMqiS5G/ziuG1gg6reEdDK3867CJ8uK4m8bfdzt6yMf1rOZcSKiiioLCii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACm06m0AFFFFABRRRQAUUUUAegOFx1n/ ABFQPt/6afiKnkc5583/AL7FQux/6af99VoQQMB/tUxgPTNPcn0b/vqo2PsfzpDuNI/2V/Ok/wCA RfnSH6D86Ycei/nSHcdz/wA84PxP/wBek+Y/8srb/vr/AOvTCB/dj/Okwv8Adh/OgCYBv+eVp/31 /wDXpQH/AOeNl+LD/GoQE/uwfmaMJ/dtvzNAFgB/+eOnfiw/xpwEn/PDS/xYf41W2x/3LP8AM0oW P+5Y/iTQItgTH/llo4+rL/jTws393RB9StUwIv7mnfjup48rH3NL/ENSsMuYnPfQx9CtPDTYxv0I fgtUwYv7ulf98tS7oh20n/v21AF3zJh/y10Ef8BX/CmNJNnP2nRB7BF/wqrvi/6hX/fk/wCFI0ke OumfhAf8KABGO+VmaJicDMQwv4Uu+q6/cLfKMn+EYFJvrREMs76N9V99G+qEXbVh5oJ5A5NY3id7 GWWCSxtPsgIIdMjk+v61cuJxDY3D5wdhUfU8VzFYzV2XHYKKKKRQUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAU2nU2gAooooAKKKKACiiigDvHj57flUTp7D8qzH8UA9LX8zUZ8SZ /wCXVf8Avr/61aXRFmaTL9PyqNl+n5VnHxAD/wAuw/76/wDrUw66p/5dv/Hv/rUroepokfT8qaR9 PyrOOtA/8sP/AB7/AOtTTrAP/LD/AMepXQ9TRP8Anikz/nArNOrA/wDLH/x6kOq/9Mv/AB6i4Gpn 3/QUbvf9BWV/an/TL9aT+0/+mf60XA1g59f/AB0UeYfX/wAdFZP9pn/nn+tJ/aR/55/rRcLGv5vv /wCOilE59f8Ax0Vj/wBon/nn+tJ/aJ/55/rRcLG155/vH/vkUv2g/wB8/kKxP7RP9z9aX+0T/c/W lcDa+0H++36U1pyQfnb9KyBqI7ofzqxY3UdxcrGQVz0z0poDRIxGgPXGaiI54q04DHgr+dAhz3X8 6uxFyqAaUKauC1Y9Nv5iq11Pb2SkyurOOiKck/4UXsBn63LtiigB5PzsP0H9ayKkup2ubh5nwCx6 DoB6VHWRoFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABTadTaACiiigAo oooAKKKKAFopKKAFopKKAFopKKAFopKKAFopKKAFopKKAFopKKAFopKKAFopKKAFopKKAHUlJRQA tLTaKAHUU2igB1FNooAdRTaKAHUU2igB1FNooAdRTaKAHUU2igB1FNooAdRTaKAHUU2igB1NoooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/2QplbmRzdHJlYW0KZW5k b2JqCjEyIDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0NvbG9yU3BhY2UvRGV2aWNlUkdCCi9XaWR0 aCA1MjEKL0hlaWdodCA0ODMKL0JpdHNQZXJDb21wb25lbnQgOAovRmlsdGVyL0RDVERlY29kZS9M ZW5ndGggMTcxNzA+PnN0cmVhbQr/2P/uAA5BZG9iZQBkAAAAAAH/2wBDAA4KCw0LCQ4NDA0QDw4R FiQXFhQUFiwgIRokNC43NjMuMjI6QVNGOj1OPjIySGJJTlZYXV5dOEVmbWVabFNbXVn/2wBDAQ8Q EBYTFioXFypZOzI7WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZ WVlZWVn/wAARCAHjAgkDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL /8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2Jy ggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo 6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQD BAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaX mJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6 /9oADAMBAAIRAxEAPwDzaiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiitbw3ptvqupm3uWkWPyy2YyAcgj1B9 aAMmivRf+EJ0jH+uvv8Avtf/AImk/wCEI0j/AJ7Xv/fa/wDxNVysV0ed0V6J/wAITpH/AD2vf++1 /wDiaP8AhCNJ/wCe17/30v8A8TRysOZHndFei/8ACEaPj/XX3/fa/wDxNH/CEaR/z2vf++l/+Jo5 WHMjzqivRh4I0f8A57X3/fa//E0f8IPo/wDz2vv++1/+Jo5WHMjzmivRf+EH0j/nte/99r/8TTh4 H0f/AJ7X3/fa/wDxNHKw5kecUV6P/wAIPo3/AD3vv++1/wDiaP8AhB9F/wCe99/32v8A8TRysOZH nFFejnwPo3ae+/77X/4mlHgbRv8Anvff99r/APE0crC6PN6K9I/4QfRv+e99/wB9r/8AE0f8INo3 /Pe+/wC+1/8AiaOVhdHm9Fekf8INov8Az3vv++1/+Jo/4QbRv+e99/32v/xNLlYXR5vRXpH/AAg2 jf8APe+/77X/AOJo/wCEG0bH/Hxff99r/wDE0+VhdHm9Fekf8ILo3/Pe+/77X/4mlHgXRu9xff8A fa//ABNLlYXR5tRXpP8Awgui/wDPxff99r/8TS/8ILon/Pxff99r/wDE0crC6PNaK9L/AOEF0T/n 4v8A/vtP/iaT/hBdE/5+L/8A77X/AOJo5WF0ea0V6V/wgmif8/F9/wB9r/8AE0o8CaH3uL//AL7X /wCJo5WF0eaUV6X/AMILof8Az8X/AP32n/xNH/CCaJ/z8X3/AH2v/wATRysLo80or0z/AIQTQ/8A n4v/APvtP/iaP+EE0P8A5+b7/vtf/iaLMLnmdFeljwJon/Pzff8Afa//ABNIfAmi9rm9/wC+1/8A iaLMLo81or0v/hBNEx/x833/AH2v/wATR/wgmiZ/4+b7/vtf/iaLMLo80or0z/hA9D/5+r7/AL7X /wCJo/4QPQ/+fq+/77X/AOJoswueZ0V6X/wgeif8/V7/AN9r/wDE0jeBNF7XN7/32v8A8TRZhc81 or0weA9DxzdXv/fa/wDxNH/CB6Jn/j6vcf76/wDxNFmFzzOivTf+EC0P/n6vv++1/wDiaP8AhAtD /wCfq+/77X/4mizC55lRXpv/AAgWh/8AP1e/99r/APE0f8IFof8Az9Xv/fa//E0WYXPMqK9O/wCE B0L/AJ+73/vtf/iaD4C0Ptd3v/fa/wDxNFmFzzGivTv+EB0L/n7vv++1/wDiaT/hAtEz/wAfV7/3 2v8A8TRYLnmVFemf8IFon/P1e/8Afa//ABNMfwNo8QLi6uXwDhWI/oBRZhc82or0hPA2ltyZp8ex pf8AhBdKPCz3APvSGebUV6SPAWmY5ubjP4Uv/CBaRtwbm7B9Qy/4UWFc81or0N/h/Yn7l/MPqgNZ 9/4CuIoy1ldLcEDOxl2mgZxlFOdGjkZHUq6kgg9QabQAUUUUAFFFFABXQeC2ZdbJQZPlN/MVz9dD 4KQPrZBJA8pjkH3FAHoAlmx9yk86X/nmaVVizt8x+vcmnpDsmddxIAHU5qrk2GedL/zzNHnS/wDP M1Y2UbKLhYr+fL/zzNL58v8Azzan+QJpnzIUCD+9gVLDYxythbxc+nmUXCxX8+X/AJ5tSmeT+41T G2a3unjZywAHU5p4QHvRcLIrefJ/cNH2iT+41XFhVv4qX7CZpcecUAHrii4WKX2h+6N+VH2hv7jf lV5NM3thbls/71Daa8MwBlLAjPPNFwsUftD/ANxvypftL/3G/Kr/ANkP96nCzP8Aeo5gsZ32lv7j flS/am/uN+VXZLFmZVEu3ucVEbMA4Ny/6UcwWK5uWx9xvyo+1N/cP5VbbT5U8t1lZlY96U27DqKL hYp/am/uN+VL9qP90/lVsQA9TiiS0YxkI+CTjNFwsVPtR/ut+VH2s/3G/Krv9kyjrcEfUio59MuI oXk81iFGeoo5gsVvtX+w35Ufaz/cP5VOIztGeuKXy6OYLFf7X/st+VH2r/Zb8qs7MVGlpNJD53ms F7njAouFiP7Wf7p/Kg3fqp/KpYbWSdtsVwzH8KbEjAOrncVYjJFFwsM+1/7J/Kj7X/sn8qn2CjaK OYdiD7WPQ/lS/ax6H8qHVmlYCXy1UDsKYuHYKt1kn/ZFFxWHfa1HY/lS/bF9D+VOaCaCdFlYlXBI BUCpNgPYUXHYg+2L6H8qPtien6VPsHoKjmGE+XAYkAHFFwsM+2L6fpR9rT0/SlMUgfYZ1DHtsFOl s7qOF5S3CjPMYo5gsM+1x+35Ufa4/b8qlRVKKSBkjPSl2L6D8qOYLEX2uP2/Kk+1x+35VNsTI4H5 VAkc0gZ1aNV3ED93nFFxWF+1x+35Ufa4++Pyp62lyxwGQn/rl/8AXpkSnzZY5QhKY5C4o5h2D7XF 7flR9ri9vyqXZH/dH5UeXH/dX8qOYLEX2uL/AGaPtcXt+VEq/NGkQjBbPLLmm+RPzkw/9+zRcVh3 2uL2pPtcX+zTJI5YlR5EiMZYLkIRUxSL+4Pyo5h2Gfaov9mo3uoSpAC1Iyw9So/KqkyIWG3GPpRz CsaFtKrxjHTFTZHrWBI0kMLqCQd3WqpuZxx5jVIzqSaT5TjODXLrc3LdGY496d9snA+8aLhY6fjt SrjnPpXLG+uRzuPtUsWpzqRnmi4WOa8c6b9l1FbpF+WcfMf9oVy1eo+I4V1LwxcOoy8S+av4df0z Xl560DEooooAKKKKACuj8CjOvH/ri38xXOV0ngSTyteLBd37lhj8RUzTcWkB6U6r5QyQTnPIqeK3 WTMjdW64qk8xmIDQlR67qsQxyGPgNj61cE1GzJbLYto6eLaMdqreVJ/tfnS7ZR6/nTAsfZIiD+7U 565FD2kKpkRIG9QKri5Kjkmo57mR1xHkn61kubm12GaAiDncVGSOaU26EcqKqQvMYgf61Lum9P1r WwrivZr1Xg1C8cydEVh3JqQtN6frTftBHDGs6ily+6CGmWJEy8exvUVbEkdxh1J6YqhOzzDamCfe lhjkKcYGPQ04J8vvbhc0PKX1pwhHrVIRy+p/OnBZh0J/OqAsiFd2RnPSjyFB5UH8KqmeSPrmmm8Y ggZrOSlzaDuWVG7C4bCngVLsz61Qt3nLkZz361YDTj/9daWEStArdqhe2YMNpPBzinb5qaZ3Tl6A D9+Gy8SuP1pv2yIM8BVhu/KnC7/2qr4mMu91+VuhyOaypqSvzDbLYRJRnApDajtUZhbsCPxpVWRT xn861ENktWA6flUP2Y+WqeXkAfxCrXmTD6Uv2ojgnms6ik4+6NFFkW3Cy+SA6nggVGoOWOD8zFjn 3q7NcO6gJjPvTlaVo8lVqoJqOoXKRFIetXSrnqgprQkj7gpgUUXa0jAZLY6jpUibgTuAYY9KshVi GTH+VMeaPBxEa5qlOq6ilF6DTVivNOs7wvuJKKVIoBzU0UGf4Bg89ak+z4P3P1rqsIq5pCiuV3Hg HP1q55P/AEzH50LEqnLJgUgKLQws2TAD755qw0yCzmtQ5AIwNxyRVkCHOcD86i8oF3cRg+9c9BVb v2g3boVFYYA9Bilq55PA/d0eT/0zroEU+9NiVVtmjd2YbiSBx1q95J/550Lbqc7lx+NTPm5Xy7gV IGCyAh5VI6HeTUTOHuppt2fMI7egrR+yooJHJ+tRR2u3jyzxWOG9q4/vdxu3Qq0tW/s/+waDbnsh roEUwuLmKTcBtyMetTSygyHhj+PFSi2JwGTipPs6E9vzrnxDqqP7rcat1KV84ltY034wwbB9qgJz 0NXbm2yykLn6Uw2p4+U1tDm5VzbiKDdagc5Ydh9K0zZ88hqY1llvlVvxpgUfL85tpH8IobT1I6V0 FrZputiw+YxHd78j/GrptIj/AA1QHJf2eoU8VDJYY5CnHvXZ/ZIv7tDWkLDBQYo0DU4Y2uByDUbW 3fFdy2nW7dUqCTR4HBxwT09qNBnL2I3Wt1btypUgj2IryqRSkjKwwQcV7Le2QsJZCRuRoySM4ziu LlvNInJ8zTmDevnE/wAxUSbj0Glc4yiuqaHQpCP9HnT1w4/wrN1WysIUElpNIf8AYdf65pKfSw+U x6KKKskK6LwQyJrhL5wYWHAz3Fc7XR+B/wDkOn/ri38xQB6GtxbKOFcn3U1btrr90N6Faq9qcaq5 Jd+1J70j3S7T16VSpVPNK4DJLyFkX5mBH+yaat3bjkyP/wB8mpaaelFwsW7S8Bh5jZRnjPep/ta1 QzhRSZptgi+bpenNZ8l5G38e0g8ilB+YUHk9qVwsNS6h/im/SrdpfKxYBG2dQ3Y1UIHoKcvCU7is aP2tPek+2KPWs7JpM0rjLEl3GWcFwp96gW5t8/NMMfWhgM8gU3YPQflRcLFiLUIRdbYUYrjGRyBV w3ie9ZqKAeBijmhsDS+2JjvVWe9i8xVY4yDgmq/NBUMoyAfrRcBPtERPMuB9ae1/BAi4LSHPReTU ZjX+6v5UqxqGBAA9wKLhY0xeoyg4YZGcGj7YnvWex5pM0XHYt3F4oiY81WmuUJBVwPxpAAQQeRTP LQ/wL+VFxWJFuYhlnkzgdiKms9Sjmg+VXG3jkYqmYY/7i/lUuAqgDii4WL/2xfQ0fbF9DWfSjrSu OxN9tRllU8ZbBBNRrLAW+ZyV9MiomhiZyTGpJ6nFM+zw/wDPJPyp3CxZXVLaK8EKhvmAxgZq79tT 0rMihjjJKIqk+gp1DYGj9tT0NVrm+XdGuD8xqvQyK6DcobB4zSuAv2p+mz8c1K1/HBaSF88c1VNv Ef8AlmKT7NCcZjFO4WNOHUopoleMEqak+2p/dNZ5AAAAwPSkpNgaBvVx0NUGvt0KukbN170DqKgN rDk4jx9CaLgSpfOzD90y+5NTwatC11LCc+YOcVR+yw/3T/30alhhji3MiAMep707gaf21P7po+2r /dNZ2aM0gJ5r8ecqbWOVJqm984bHkyfmKdJEkmxmGSvQ5qBrSEnOGz/vGi4E7amkEIaYMo3DPtV1 dRidFdMlWGQayDZwkgMGYZzhmJFTsAoAUAADgCi4F836f3Wph1GMcbW/Os/PPNMILEYNAHQWV2rM hY4CRH+Yq4L2Eng1yP2wxeavTCAfrVY6i2f/AK9VoLU7kXcJ/ix9ad9oi/vivPn1GXdwaYdUnzyS PpS0HqeifaYf+ei/nS+fERnzF/OvOjfzsMg9PfmkXUp2yCTzx1osg1O016PfaqVxu5A/EV4ZJdzN KzeYw3GvXG1Q3NpaRfxIp3H6CvHD1NJjRL9pmP8Ay0amNK7jDMT9aZRRYAooooAK6DwWXGtnZtz5 Tfe+orn63/BqF9aYK20iJjn8RQB37STxvGHCYY44zVhmqAv5yw5cMYycj0p5NMkdupkkjKvyY3E4 GaBS+XvKnIAU5OaQyMNdd1i/M0ySa4jALpGVyAcMc1aVXcttnGfTHSmSsZYUjZlLq/OB2oi09UIk LHApuTQTzRmgBHkKIzYzjtUfmXJ/5Yp/33UjxmVCoIHPekMErnKSpu9KG0hkTy3CqWMK4H+3VhW3 RqemRmlcMbaRG2hzxx3pOiqPQUxC0UlLgsCF5OOKQyETytysBIPQ7hR5s3/Puf8AvsU5IbgRhVCA gdCakj3g4lXaw9DmgBtvL5kZYqUIJBBp+aZCpWM5HJJNOoYIXNQvcMJTGkLvtGSQRU1MgQmeZmOB kY96AGedJ/z7SfmP8aWKctN5bROjYyM45qQQyOx2Tr9MU3lrzcR91MH0zSi09UDJD1NFHeimA2SU RJkgtk4AHU1F9ob/AJ95vyH+NSSIXaIAfx5PtTzDMWwksf8Au0NpAV3uti7ngmVR1OBxVknKg+tQ XKSeQ6Ny/HA5qc9APQUAJS96SlFAFc3aEnbHKwzjITNBul/55Tf98GpIoJo4goaNfrT2SZcbyuPV e9HkAy3nWYPtDAqcEMMEVJUNsD5lwxGNzDHvxU1ABTJZ0iChtxLdAoyafTFTzL+BC20FSN2OBQBF 9rjzjbKP+2bU5buEsoO8ZOBlCBU98kkEipAGlUfeYDvVS4LvEoYEHevUe9AF1utJQ3Wm0AOBwar/ AG2DPVvrsP8AhUx+630NU0llSKMKrH5RkBelAEv223/vN/3wf8KmhlSWNjGcgHB9qrefNx257rUl ocifjnf/AEoAmz7UZ9qSjNIBk1xFCFEjbSenvUP223P/AC0/Q0TttuYsfe2HFO23hz+6GPwpgRre 27OqiQZJwAeM1O/WqN2ZCIhIuD5i9sd6tyHmgBjnjimKcnFD5xTEOGqeozKvJCt3KB0wM1H5nAqO 9b/SbkjtiqZlYY5qhrY0CwphYVS85j3o800rjRe8zaMcfiKYzcLtxVTzTS7zjJpXKSNW0Yqd27I2 Nz+Fed969DiUx2qk94ZHH5V533pmYUUUUwCiiigArc8JNs1Zz/0yb+YrDrW8OeZ/aREYBJjI59OK AO+sWyhOMZNW81m6c2JHRm+YY+WtDNNkjs1IqllwKhzVGW5nSSXymICgdBWdSPPFx7jNUIyAseKo wMDPIcHOfzrMOp3jZHzN7YqxZzu90PM+Qlfuk1GGoKjHlTuDdzWzmjNNzRmtgJYwWBAp6IyknGMV mXF3NA4WE4JBJ4qn/bVycqef+A1yVcN7Sop32GmaMcge6fJb+lWiayEmX7RG0e9VcjO8Y571q12d CR2adGSW4qPNQz3Bt0LqAT0ANS1dWGW1Vt2e9VppsXm0uw47dKonXZFYrsQEcc1D9tM0hk2ncB+F cuFw8qN+Z3uNu5uZ4ozUcbFoUJ6kdqdmutiQ6nKhOQDUZOKoyXcq2jSxuEYE8eoqKkOeLj3A1EjZ TuIxiq0DfO5yTk1jjWblh1LZ7bavafM028sAMGssNh/YRcb3HJ3NAUuaYOlGa6BE0YJzjrQsTbum Pes64u5IZNsWAdpOTVQa9Nkg7SR2xXHiMN7aSd7WKTsabOWvXG/p2qYnmsW3vDJMJCvLtjHpWxXZ 0JHZoBOeKbmo5ZPLRm9BmgCwyHPTNRXZZEjBcJz3rNbWpl7RjjvVd9Ve7kEbgDHQjiuKjhZU6rqO V7lN3VjeUEJyc0VXtJfNtycY2nb9amzXayR1G05B4I9D0pM1CLhftQiZd3y7vvYoAssz7upFJNIx eME9qp/2zACQ0bZqOW+jmmiZOjHbjuK4cPRrQqSlOV0ym1Yvk80tMBpc13EjgeeKe8jgABsAVWlk 8uNn/ujNRDVbUqpbeCRnGK5cVCpOnak9Rq19SzcuzQBSRndwTSr8sfPWs+7voZ41SHIYHPIqzaze dCTz8p2nNa0YzjBKbuxPcnopuaXNaADRhyp9DTn3Fj1qnNerDKEwxbbuGKrnXo15aH/x6uTF0J1o pQdiouxbumYzRA4PHems3NZ0mppczI6qQMhetXzmumEXGKTd2T1EY0xfvCnZHem/xCqsBzGpykT3 JHGXxWb5rE9atamf3kp9ZDWfTAsed2pTNmq2aUGgCwJTnFSpLk4qmDT0bGKVikzet5zJbXAPSG1k /ka4Ou406N5rO/WPhniKA4z1HoK58+HNQzxEx/4A3+FS5Rjo2CTexj0Vrnw5qeRi2c59FP8AhUEu jX0QO6BuOwoU4vZg4tdDPopehpKsQVt+E4/M1cruK/uzyDjuKxK2fC3/ACFu/wDqz0+oppXYmd5B aRxZcDc56seTU+DWfkY/ipc+7Vo4EcxoAGq7WpMjMsjru6gYxUGT/eal3n+89LkDmH/Y3zxM/wCQ p0dgnnCaQmR16E8YqLe399qcJH/56NRyBzF3Bx0pcH0qj5r/APPVqXzZP+epo9mPmJpbdnkDq20g Y6ZqL7JJnPmL/wB8Unmyf89TS+bJ/wA9TS5A5hGsPtBUTtuRTnAGKvAYGAOB0qn50o6S0vny/wDP QflT5GHMW+fSobiEzIADggg8iovPl/56D8qd58399fypcgcxE1mxfJ8s/wDAaU20rIU3IFYYOF5p /ny/31/KlE8v95fyo5GHMTW8AtoVjUs2O7GpKr/aJvVKPPl/2KORhcsdRVaOGVI9hEbD1OaX7RL/ ALFH2iX0SjkY+YZ5Mq8hIs/jS29q6TtOzkbv4B0p/ny+iUv2iXGNqYo5GK5PRUH2iT+4v50faJP7 i/nS5GPmQ2aKQzh1RXG3BBOKh8hw277NGD7N/wDWqx9ok/uL+dH2h/8AnmPzo5GF0VZrWaYKiIsO GzvBzWioKoqs24gcn1qEXDg/6sfnS/aH/wCeQ/OjlYXRNUc6GSB1X7xGBTftDf8APL9aPtDf88v1 o5GF0VDbFlXfZgkADO8U4REEf6GOP9oVZ+0H/nl+tH2g/wDPL9aORhdEVhBcRGRpZAI3JIj/ALv4 1dqD7ScY8o/nR9p/6ZH86ORhdE+aozo4ui/ktIjJt+Uj+tT/AGn/AKZH86PtI/55NRyMLoynsVLk /ZZv++h/jStazYRbSFoZA2dz4x/OtT7QP+eTUC4UHPltRysLolj3CNQ5BcDkj1p1Q/aV6+W1J9qT vG9HKwuhblDJBIq8kqQKx3tFbaxt7hW2gHA/+vWv9qT/AJ5vQbmP+49LlYXRmRQRxsGNtcE+pH/1 6t6el0kkm4KtsxJVT96p/tMf916UXUYXG1qOVhdE1LnrUH2qL+6/5UfaovR/yo5WF0VbtMXiyMkj IYypKDODmqDWtpnJhnx6FDWz9pi9H/Kmm5hP9/8AKjlY7oxJYlEapZQyCXeCNyECtiMyeUnnBRJj 5tvTNL58PXLflSNPCT/F+VHKxXQhpCcEUhlgPGW/KmGSIDIY/lRyyHdHKan2PrIx/Ws6t6/tGlii Kj+8f1qiNPkHJXikBnjrTsVoCxfuBSiyb0oAohc0pAHNXfsjDotSx6e8jAbaAJ7aY2mhTyrJ5ckh +Vs4NZf9tXan/j+f/vs1e8Xxpa6VYwoMMzE8egH/ANeuPqHBPcpNo6L+27n/AJ/3H/AzTpPEdyv/ AC+ySZHIyf61zdFCpxXQfMxSckk96SiirJCtPQWK6hlTg7D/AErMq7pM8Vveb5m2rtIzgn+VNbgz rBNJj75pfOl/vH86zhqlh/z2/wDHW/wpf7Tsf+e4/I/4VrzIixoefL/eNO8+X+9WadUsu04/I/4U f2nZf89x+Ro5kFjS+0Tf3qX7RL/erOGpWZ5+0L+tL/aNl/z8LRzILGj9pl9aPtU3rWcNSsv+fhaU alZngXC0cyCxo/apfWj7XKPSs/7fZ/8APyn50ov7L/n6T86OYLGgLuX2pRdye1Z39oWf/P1H+dO+ 3WnGLqL/AL6FHMgsX/tcnoKX7W/oKzxfWv8Az9Rf99Cl+3Wn/P1F/wB9CjmQWND7W/8AdFL9rb+6 KzRe2pOPtMP/AH2Kf9rtf+fuD/v4KOYLF/7Y390UovD/AHBWf9stf+fqD/v4KPtlr/z9Qf8AfwUc yCxoC8P9wUovP9is/wC1W+Bi5hP/AAMUfaoP+fiH/vsUcyCxo/bB/cpftg/ufrWb9qg/5+Iv++xS i5gPSeI/8DFF0FjR+2D+4fzo+2L/AHT+dZ/2iL/ntH/30KPtEX/PaP8A76FF0FjR+1p/dP50v2tf 7p/Os77RF/z2i/77FO81P+eif99Ci4WL/wBrX0P50v2tPRqz/MT/AJ6J/wB9CjzU/vp/30Kd0FjQ +1p/tfnS/a0/2qzw6n7rIf8AgQpdw9V/Oi6Cxf8Ataf7VL9rT/arP3D1X86Nw9V/Oi4WND7XH6tS i6T1as/B9KXn0/WlcVi/9qT+81H2pP7xqhg+lHPpTHYv/ak/vGl+1J/fNZ/PpRye1AWND7Un980f ak/vms7BHalx7UAaH2pP+eho+0r/AM9DWdg+lHPpSCxo/aV/56H8qPtK/wDPSs/BP8Jowf7poA0P tK/89P0o+0jP+sFZ2PajHsaYrGj9oX/noKPPH/PQflWdj2NGPakM0PPH98flSGYf31qhg+hpdp9D QBd80f31pDJngMvNU8exp0anzY+P4qANdLZXhUHsKk+yR46UkcyKgGRTvtCdyKysURmzjI6CmmxX tip/Pj/vD86Tzk/vD86AIRYoOoqaK2Reg5xQ1zFGMvIqj3YCqV3r1hZxl2uY3OOFRgxP5UAct45n 36pDCGyIos49CT/9YVzFWdRu2vr+a5YY8xsgeg7VWpDCiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAClpKKACiiigBaM0lFAC0UlFAC0ZpK KAFzQGYdCR9DSUUAO3v/AHj+dG9/7x/Om0UAO3v/AHj+dO86X/no/wD30ajooAk86X/no/8A30aP Ol/56P8A99Go6KAJRcTDpLIPoxpftVx/z3k/77NQ0UAS/aZ/+e0n/fRo+0z/APPaT/vo1FRQBP8A bLr/AJ+Jv++zR9suf+fiX/vs1BRQBP8AbLr/AJ+Jv++zSi+ux0upx9JDVeigCz9vvP8An7n/AO/h qRNVvo1wLlz7scn8zVKigC4dTvj1upf++qjN7dN1uJT/AMCNV6KAJjcznrNIf+BGmmaU9ZHP/AjU dFACliepJpKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiitnwxZW99qMkV1HvQRFg Mkc5Hp9TQBjUV6F/wjuk97XP/A2/xpf+Ec0f/n0P/fx/8adhXPPKK9D/AOEc0j/n1/8AIjf40n/C N6Rj/j1P/fxv8aLBc89or0P/AIRvR8c2pz/10f8AxoHh3R/+fQ/9/H/xosFzzyivRf8AhHNG/wCf Q/8Afx/8aU+HNFJ4tCP+2r/40WC55zRXo3/COaL/AM+h/wC/j/40n/COaN/z5n/v4/8AjRYLnnVF ei/8I5ov/Pmf+/r/AONH/COaKf8Al0P/AH8f/GiwXPOqK9H/AOEb0X/nzP8A39f/ABpp8NaPni0P /fx/8aLBc86or0X/AIRvRv8An0P/AH8f/GlHhrR/+fU/9/H/AMaLBc85or0f/hGtG/59D/38f/Gk /wCEb0bP/Hof+/j/AONFguec0V6N/wAI3ov/AD6H/v4/+NN/4RvSc82vH++3+NFgued0V6N/wjej f8+h/wC/j/40f8I1o3/Pof8Av4/+NFguec0V6P8A8I1ov/Pqf+/j/wCNH/CNaN2tT/38f/GiwXPO KK9GHhvRu9p/5Ef/ABp3/CNaJj/j0P8A38f/ABosFzzeivRz4b0Xtan/AL+P/jS/8I1one1P/fx/ 8aLBc83or0X/AIRvRv8An0P/AH8f/Gk/4RrR8/8AHqf+/j/40WC553RXop8NaP2tj/38f/Gmr4c0 jPNof+/j/wCNFguee8YpK7W70HTBdBViaNCMfK5P480xvC2nH7lzMPriiwXONorrT4TtT0vXH1Sg eEYD/wAxAj/tl/8AXpDuclRXWSeD0C/u9RUt6NEQP51Sn8K30akxyQS/7KsQf1FAGBRUk0MkErRz IyOvUEVHQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV0 Hg041aXP/PA/+hLXP1v+Dtv9qy7zgeSf/QlpoGdtketLkClWGNhw9I0IXkZNUSFBPpURbb1Bpvmo OmaLAT845oAqD7QtJ56+9FgLPbrRiq3nrQJ1B60WAtY96TB71WNwvrR56+posBaxRgDvVXz19TSe cM9TRYC5kdjSHr1qqJk9aDMh70WAtcetKPrVUTLjrR5y9jRYC1R1qv5yY6mk89f71FgLGKTNQ+ep PLUvnR/3qLAT0c1X82PP3qd5y9moAm5pRmq/nL/fo89f71FgJ+e1Lziq/njswo88f3qLATnNGDUH nA9Wo80f36AJ8e9IfrUHmj+9SiRf74oAmNNzzTPNXuwP40xpEUE7h+dICjqE/wAy4xwakjIKA+tY 95M7TH0pLiaSOOEIxHBoegI3RinAj1rmftMw6OTTlup+m41Nx2OkJx70Aj865z7bcD+I05b64Jxu /Oi4WNDWdPW/s2AH7+MZjPf6fQ1wneu2s9QZpgkoxu4DVy+swC31W4RfultwwPUZ/rQMo0UUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV0XgqNZdXmVhkfZyf8A x5a52uj8DqzaxMFOD9nb/wBCWgDuDpoHMZKn60gtpk6kkVMEmH8Q/OlCzf3hT1ERxpGGzLnI9ala K2ZT93ntVdkllOWIA/Wo57U7AImJbuSalxu7sLkT6dlvkyQT60h0tx/e/OrlokqRY6Gpv3/94VQG UdNcdn/OlisvLfc+72B5rWAmx94VEpmkdcsqp39aNQKbLEFOV/Ss3yd0u0F8H36VsTxTb3COGTtm ltbcmP7qgipjHlWgXMn7M3956Psx/vtW99mb0Wmm0J7LVagZFuiRysHYk4zzVhhEVbjt6VO0DbgV VQO/PNK8DCLCkFyenYColC7uFzGWNmkKhn6ZqT7O/wDfatm3hynATcOKm+zt6JV6gYH2aT++1Wbe FFU+Y24+9axt29EqBUJkYmNSvT8aTTatcChcpEISVOGHTFUkVndlDsCPatWW3mk+XahBPNTw2akM AF3Dg0oxcVa4GN5En/PQ/lS+RL/fP5VuizI7LS/ZW/urVXYGJbx5uCkj5AHParRgiIxnHvmrEtqf MyiLkHDUyS3cqPLQA981EouTvdoDJCyO7qsn3Tg5FL5M3/PQflWxb2XUHaH6n3qb7E3otXdgYPkz /wB8flS26lrjZI4Kjg8Yrd+xE9lqrLYfvv3Srvz83NF2BAbeIggHB9c1nkSFnCup2nB4rYnsjHFu RlY/3cVHb2DHdkKGPJ5qIqUetw0MkrP/AHl/Ko2E/qv5Vutp8h6bahfTZv8AZqrsNDn5Y5s5O2pJ YCyAlegHFa76bJgnA6etbGlaXBelBIf+XdGPHfJFP1EcT5OO1AjyeK9J/wCEYsj1z+VIfC9lnI4P 0osh3Z5yLfJ6Gj7NgdDXo48N2oXAJ/KmP4bhxwwx6YosguecywMkbEA5HIrL8RLme3n7SxDP1B// AFV6nN4aRkYZBO015v4nhMUUKEcxSMn+fyoaC9znKKKKQwooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACug8GSmLVpWAyTAR/wCPLXP1ueEzjU5f+uJ/9CWgDu/tr+gp RqO3rtBrOnn8pAcZJOKhEqPKfMmZE/2F5oeojZ/tMc/dPtUCak8ku0IuO59KxWkcBsTeYf4QF5NX 7YgQL8pUnqCKmMeUDQ+2v/dFL9tf+6Kp7hSM4VST0AzVXAvrf4+9tB9DSnUFweEPsKwzcrIu7zUQ leBkUySRgcJcRSA/xcLiocbu92BrHUmLKBGDuOOKnN64OAorJsZkZWUA5U9ccGrW4VdwLn26T+6K Vb5s87R9apbqrSTBpjGCBtxkn3o3A2PtoPUJ+dVn1IoGbYpAqjcGJEHky+a57YAA/OooZ44mjSUj MmenOKiEXHq2M2vtrgDCrR9uk/uiqhYGjdV3EW/t7ryQAAMmlhvvMTeEXms64mSKPc4yCQuPrVfc RkhVAzwM1Mk2rJ2GbbXZClti1HFqJeIOiLg1iSSyBCxQBRycN2q7BLHJApjYEe3aiCaVm7iZo/b5 P7oo+3v/AHRVLNFUBeW9Eu47ASpwfrSPdYUnyxgVitcfMxjjcjJBI9QeaR53PAjk5NZuMua/Np2G bEWoKzMFjAZetO+3v/dFZlvNF5jRkhZcDIPf0qfNaCLf25v7g/Oo3v18xQYxvIzx6VBxVa6MQKgg +YQduPbmi4GsZU/55frUT3iRTIpjG5h8uazJRcQxrI8Q2HusgJ/KoVmVnEkgKhDgFuxNZxjJSu5X Bmu2otz8g/Oom1Nh/wAs/wBarsBnIIIPoaiYVbAsHUmII8v9av6Tqv2KOZ2wxjjRAPqTWERhvrWf dTsDNGD97b+mapPuFjuE8XKzBfLBJ96l/wCEo+XPlp+deciXDgjOR71PHMQ3DZoug5WeixeI0ePc VAP1qT+3oyegxXn4uWUHBzn0pWvWAqromzPRrXVreSVYycM/A56mvO/GVnJc6hcpAQVSXJGCece1 Vm1SSOaNlbBRgQahv7ydop7iOcozS5ZgcZ4qZPTQpLXUwX065U48uq8kbxNh1KmtIardA83jH681 UvLp7oqZGDMv8QGKzi5dSnboVaKKKsQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFbHhk41CTnH7o/zFY9aWhttvHP8A0zP8xVR3E9jr9/8AtCjd7is7zTR5p9a35TK5pbvc Ubz6j86zhKaPNNHKFzR3n1H50bz61n+afWjzTRyjuaGfYUcei1Q80+tHmn1o5QuaIcgYH5Ub2rP8 0+tHnH1o5QuaO9qacMcsqk+4qh5x9aXzj60uVBcvbV/55r+QpVwpyqgH2FUPOPrS+c3rRyhc0PMa jzGrP85qPOb1o5EFy+53rtddw9DTPLj/AOeQqn57etL57etHIguWjFF/zyWpQ+0YVQB7CqHnt60e e3rRyBcv+a1HmtVDz29aXz29aXIg5iyYo9xPl8k5OO5o8uP+5Vbz29aPPb1p8gXLSqiNuEY3epGT UnmmqPnt60ee3rS5EHMXvONMcrJt3rkqcg+lVPPb1o89vWjkQcxZwn+0P+BGmtHEylWBYHqCTiof PNHnmjkQcxaVlRAqKFA7Cmlwar+eaTzj7UezQ+YkdvfpWLet/pEh+laTzVj3bbpZT3yKicbIqDuy Pec04SEYOagyaN1YmxaE7UNMT3qruNKGoDQe5JNSX426bIvpIv8AKmQgPNGpOAWHNWrqH7RbTqDg +bwcE9BRfuS1roc7RWh/Zc3ZlP4H/CmnTJwf4f1o549xWZRoqWaCSE4kXFRVQgooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKv6QcXTf7h/mKoVc0s4uG/wBw/wAxVR3E9jc3 Ubqg30u6t7mVifdRuqDfS7qLgT7qN1Qb6XdRcCfdRuqDfRvouFifdRuqDfRup3CxPupd1Qb6N9Fw sT7qN1QbqN1FwsT7qN1Q76N9FwsTbqN1Q7qN1FwsTbqXdUG+jfRcLE+6jcag3Ub6LhYn3Ubqg3Ub 6LhYn30b6g3Ub6LhYn3Ub6g3Ub6LhYn30b6g30b6LhYn30m+od9JvouFiRnNZV05DN7mrxasy5OC PfJrOpsVAjMho3mo80ZrE0JQ9KHqHNKGpBctq+Bu7irUj3EVhHNC7IGcliDis/eNhrS1MeVoFqnd mz+lK19B31KX9q3g4F0//fVPTWr5WGbtz9WzWXSUvZx7D5maF5qEt1CVml3ntx0rPooqkktiQooo pgFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFWtPOJ2/3f6iqtWrD/AF7f7v8A UU1uJmjupd1NxRWtybDt1G6m0tFwsLupd1NxRRcLDt1G6m0uKLhYduo3U3FFFwHb6N1NoxRcLDt1 LupmKKLhYfuo30zFGKLhYfuo3Uyii4WH7qN9MoouFh+6jfTKKLhYfuo30ykouFiTfRvqOii4WH7q XfUdFFwsP30b6joouFiTdRvqOii4WHbutUr1SJEH+yKtgZOPWrNzZeZKD/sgVEmNGFijFa39n0f2 fUFGTilxWr/Z1L/Z3tQIzraJpplQDqa0/EjBY7WAfwgmr2nWCxSFyOaxNdn87UWA6RjbQMzaKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKt6d/r2/3f6iqlPik aJtyHBximgNrAowKy/ts3qPyo+2ze35VXMKxq4FGBWX9tl/2fyo+3S+i0cwWNTAowKzPt0votH2+ T+6tHMgsamKMVmfb5P7i0v8AaD/3B+dHMFjS20bazRqDf3B+dL/aB/55j86OZCsaW0Um2s/+0D/z z/WlGoD/AJ5n86OZDsX9tG2qH9oL/cP50v8AaCf3Go5kKxe20bao/wBoJ/cal/tCP+61HMgsXdtG 2qX2+P0al+3x+jUXQWLm2jbVT7fF/tflR9vi9W/Ki6Cxb20baqfbofU/lSi9hP8AER+FF0Fi1tpN tQfbIP8Anp+hpftcP/PQUXQWJttG2oftcP8Az0FH2qH/AJ6Ci4WJttG2ovtMX/PRfzoFzF/z0X86 LoLEu2k20z7RF/z1X86Xz4/+ei/nRdDsO20bKQTR/wDPRfzp3mx/89F/Oi6Cw6JMzIMZ5rb2rgVh QXCJMWaROBgc1a/tGP8A57R/nSbuCNLYtLsWsptSj7XCUn9qxDrMv5GkBrbFpQgrKGrW+MmYfkaX +2LUAkzH6BTQBevLpLO2Zz1xwPWuMkcySM7dWOTVnUL972TONsY6CqdIYUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAVp6FYRajePDMzKojLAr65A/rWZW34UONTk/64n+a04q7sJ6I2D4WsMD97MP xH+FJ/will2nmH5f4Vr7xS7639mjPmZht4Ttz926kH1UGmf8IknP+mH/AL4rf30u+j2aDnZz3/CI qf8Al8/8c/8Ar0f8Ih/0+j/vj/69dDvpd/vS9mg52c6fCGel6P8Av3/9ekPhA4+W9XPvH/8AXro9 /vRv96PZoOdnLnwlP2uoj/wE0n/CJXef+PiD9f8ACuq3+9G/3o9mh85yn/CJXmeJ7f8AM/4Uf8Il ef8APe3/ADb/AArrN3vRv96Xs0HOcmPCV7/z3tvzb/Cmt4Tvh0ltz/wI/wCFdfvo30ezDnONbwtq A6GFvo1MPhnUh/BGf+Biu130bqPZoOc4ZvDuqD/l2z9JF/xqJtD1Jeto/wCBB/rXf7qNx9aPZhzn nh0nUAcfY5s/7tN/sy+/585/++DXou73pd/vS9mPnPOf7Mv/APnzuPwjNJ/Zt9/z5XP/AH6b/CvR 959aXef71Hsw5zzb+z7zvaTj6xmk+w3f/PtN/wB8GvSt/vRuHrR7MOc8ya3mX70Mgx6qaaY3AyUY fhXp2Voyvt+VHs2HOeX4PoaSvUfl9vyoIQjBC/lS9mw5zy6ivT/Jtz1ijOf9kU021qesEJ+qCj2b DnR5lRXphtLM9baA/wDbMUw2Gn4/487b/v0v+FHs2HOjgBp14yK620jKwyCFzkUhsbtettMP+AGv QARHKFXhQMADoKsBz/eqWrFJ3PNDa3C9YJR9UNM8qT/nm35V6cXJ6mm8e35VIHmWx/7rflSdK9Ow nov5VXuLCzuQfOgjY+uMGmB5xRXS6x4eSCJp7PcQvLIeePauapDCiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACtzwkobU5Qf8Anif/AEJaw63/AAcQNVlz/wA8 D/6EtVHcUtjrPKx0xRtHdasbk9aMr6103MSvsU9DikMR7VYOw9xSbVzw2KLgVipHakqyeP4gable 4ouBBRmptqHvR5Xowp3AhozUpiPYimmNvSgBmaXNGxvSkwaBC5ozSUUAOzRmm0UAOzRmkooAXdRu NJRQA7dRuNMzS5oAduPrRuNNzQKAHbj60bj602jNADtxo3mmZooAfuNG80zNGaAJN5pC5pmaKAI5 GPmA1TfUGDsB2NXVXdcIPU1k+Tudj71hV3NYbFj+0Go/tFsVW8mkMFZFlv8AtFqcuonPNUjCaaYS PWgDetJ0uMqe4wRXA6lb/ZdRuIeyucfSuospDDcrk8HisTxMgXWZSP4gD+lAGRRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABW54SGdTl/64n/0Jaw62fDDlNRk I/55H+YqofEhS2Oz2fX86XZ9fzqp57etHntjrXSYlvZ9aNvuaq+e3rR57etAFrb7mjZ7mq3nt60v 2hvWgCzs9zS7T6mqvnt60v2hqALOD6mjafU1W+0NS/aDQBPtPrRs96g+0Gl+0H2oAl8v3pfL96h8 80eeaAJfLpfL9xUPnml+0H2oAl8v3FL5f0qL7Qfaj7QfagCXy/pSeX9Kj+0fSl+0e1AD/L+lJ5Xs Kb9o9hR5/tQA7yvYUeUfQUn2j2FL9o9hRqAeUfQUhhb2pftAz0o+0D0oAQQn0/WjyT6frTvtA9KT 7QvpRqA3yT6frR5R9P1p/nr6UnnrQAzym9P1o8pvSn+evpR54ouAyGIi7hLDjeAa1tP8OfabSOcu Bvzx+JrMilVrq3XnmRa63T76CHToEdgG254+tZVNy4ma3hhVX5nBFRjw/F/eVccfNXQfboXVjkEd qqxXAZwJGV1J6AVmMyv+EaDDIII9R0pr+GGx2rfgu0LHJwoOBirXnx/3h+dAzgtQ0CW1haYDhOa5 bWtOnvr3fAmcIAea9gvFjuLOZMg5Q147qkrw30jCQKpGBzUzva6Kj5mZ/Yt9ziEnHpUT6XexjLW7 /lVsX7AH99+tPj1WRf8AluR+NZ3l2KsjHZWRirAqR2NNqxez/aLgyE5JAyar1oSFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABWr4eOL5/wDrmf5isqtPQTi9f/rmf5iqhuhS 2Om3Ubqi3Ubq6TEm3Ubqi3UbqAJt1G6od1LuoAl3Uu6od1LuoAl3Uu6od1G6gCbdRuqLdRuoAm3U bqh3Uu6gCXdxRuqLdRuoAlzRmog1LuoAlzRmo91G6gCTNG6o91G6gCTdRuqPdSbqAJd1G41Huo3U ASbqNxqPdRuoAk3UbjUe6jdQMk3Gjcaj3UbqBCiQpPG2fusDVafU5hMmxjtWMD9KWZsAmsnzDnms arNKaua0esTqMEmrMOsyhhg7cZ4zWCJOlPMgwPWsrl8p0susOsIIfnPaoJtdn83hjjA71gNOSMU0 yZ5ouHKdhpWvuPtPmnIMJA571wmvHdcxN3aMH9TVyOVg2F7iqGsHM0PtEP60XFaxnUUUUDCiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK0dEOLx/wDrmf5is6r+kHF0 3+4f5iqjuJ7G/uo3VBupd1dFzKxPuo31Bupd1FwsT7qN1QbqXdRcCfdRuqDfRuoAn3Uu6oN9G+i4 FjdRuqDfRvoAn3Ubqh30bqAJt1LuqDdRuoAn3Ubqh3UbqAJt1LuqDdRvoAn3Ubqg3UbqAJ91G6od 1G6gCbdRuqHdRuoAm3Ubqh3UbqAJt1G6od1JuoAn3Um+od1G+gBLh/kb6VlO2CPoKu3L/u2+lZUk h349hWNXdGkNCbfS76q+YacJKyNLljdSh+Kr+ZSh80h3L1qu6Q+yk1mam2blfaNf5Vegl8sOfVSK oakMXbD0Vf5CmiXuVKKKKYgooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACrmmHFw3+4f5iqdWtP/ANe3+7/UU47iZr7qN9RZozW1yLEu6l3VDmlzRcLEu+l31DmjNFws TbqXfUO6jdRcLE26jdUO6l3UXCxNvo3VBupd1O4WJ91G+oN1G6lcLE+6jfUG6jdTuFixvo31Buo3 UXAn30b6g3UbqLhYn30b6g3UbqLhYsb6N9V91G6i4WLG+k31Buo3UXCxY30b6r76N9FwsT76N9Qb qN1FwsT76N1Qb6QtRcLBct+6PvxWTIf3jfWtJzu2j1YVlsfnb6msp7lRDNG6m5oqCh2TTgxFR0tA FuI7iq+pAq5e6Ldy3bvEFKt0JYVW0tPNvoV6/Nk1JeXoS5mHmEkOelRK/Qat1E/sC9x/B/30Kp3m nz2YBmAwehBzUn9oNnq1V57l5l2sSRnNC5uoO3QgoooqxBRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAVb04Znb/d/qKqVYspUhmLOcArimtwNXFGKhF7bn+PH4GnC7t/+eg/ I1d0SSYoxTRcwH/lov504SxE/wCsX86dwDFGKcHQ/wAS/nTgAehH50AR4oxUu32o2+1AEWKXFSbf ajbQBHikxUu2jbQBFijFS7aNtAEWKMVLtpNlAEeKKk20baAI6Kk2UbaAIqKk20baAI6Kk20m2gBl GaftpNtFwGZozT9tJtoAbmjNO20YouA3NJmnbaNtFwFiXfKvtk/pWcYGyeK3NPi3O59BirX2BaiW 40cx5DelHkt6V0xsV9KabJfSpA5vyW9KPJb0NdH9hX0pfsC+lAylo0Bj8ycjlVOK59yWdiepOa66 9ZbLSpiOGZdo+prj6ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigBQSOhNOEsg6O350yigCUXM46Sv/31TheXI/5bP+dQUUAWRfXI /wCWzfjThqNyB/rAfqoqpRQBd/tO5x1Q/wDAaX+1J/7kR/4D/wDXqjRRcDQ/tWbvHF+R/wAaT+1J f+ecf61Qop3Av/2nJ/zzT9aUao3eJT+NZ9FF2Bp/2oO8H/j1KNTj7wt+DVl0UXYGuNTt+8cg/EUv 9o2392X8hWPRRdgbH9o23/TT8qcL+1I5Zx/wGsWii7Cxs/b7b+83/fNOF7anrKR/wE1iUUXYWNz7 Xa/89h/3yaPtdqSf3o/I1h0UXYWN0XNsf+Wy/rThNbnpNH+dYFFHMxWOgDwkcTR/99U4BGIw6HPo wrnacjlGDDqDmnzMLHYWCmOIkjkk1bD+1cumu3aLtUR4HtT/APhIbvH3Y/ypDOl35oyK5keILvH3 Y/yp3/CRXY6Rw/iD/jSEdKCKC2BntXMN4hvT0ES/RaqXGp3dyMSzEr6AYFAyzrl8LmcRxnMafqay qKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP//ZCmVuZHN0cmVhbQplbmRvYmoKMTEgMCBv YmoKPDwvU3VidHlwZS9JbWFnZQovQ29sb3JTcGFjZS9EZXZpY2VSR0IKL1dpZHRoIDE5NAovSGVp Z2h0IDk1Ci9CaXRzUGVyQ29tcG9uZW50IDgKL0ZpbHRlci9EQ1REZWNvZGUvTGVuZ3RoIDIzMTg+ PnN0cmVhbQr/2P/uAA5BZG9iZQBkAAAAAAH/2wBDAA4KCw0LCQ4NDA0QDw4RFiQXFhQUFiwgIRok NC43NjMuMjI6QVNGOj1OPjIySGJJTlZYXV5dOEVmbWVabFNbXVn/2wBDAQ8QEBYTFioXFypZOzI7 WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVn/wAARCABf AMIDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIE AwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJico KSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6 /8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNE RUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmq srO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEA PwD0iiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKjlmjhQtLIqKO7HFAElFYd14lsociLdOw/ujA/M1j3Pia9lyIVSBfYbj+tYTxFOPU554mnH qdmSAOaqz6lZwf625iU+m7Jrg57y5uT+/nkk9iePyqv09K5pY3+VHPLG/wAqO1l8S6en3Xkk/wB1 D/Wqz+K4R/q7aRvqwFcnkeopQCegJ+grJ4uo9jF4uo9jpG8WP/BaKPq//wBamHxXcdrWL/vo1giG ZvuwyH6IaeLO6PS2mP8AwA0vb1u4vb1mbg8Vz97WP8GNSL4s5+ez/KT/AOtWD9gvP+fSf/vg0Gwv P+fSf/vg01WrD9vXOmj8VWjffhmT6AGrkWv6dLj/AEgIfRwRXFm0uV620w/4AajMUi9Y3H1U1SxV VbopYqqt0ejxXEMwzFLG4/2WBqWvMQdhyPlP5Vdt9XvrfHl3TkejHcP1rWOMX2kaxxq+0j0GiuSt vFUy4FzAjj1Q4P5Vr2uv2FwQDKYmPaQY/XpXRGvTlszphXpy2ZrUU1HV1BVgwPQg5p1bGwUUUUAF FFFAAao32q2diP38yh+yDlj+FW5YxIhUkgH0OKgi0+1hOY7eMN3O3JP41Mr9CZc3QwLjXb+7O3T7 SRV/vFNx/wAKonR9XvW3zqxJ7yv/AErtsY7UtYOhz/HJsweH5/jk2cjF4VuWx5txEnsATVuPwpAP 9bcSt/ugCujpDTWGproNYWkuhjx+G9OTrG7/AO85/pVlNH0+P7tpF+Iz/OsfxR4iudFu4YoIonWR C5L59a6SFy8KORyygnFb+wjFJ23N/YRilLlWoxLS2T7lvEv0QVKFUdFA+grnvFWu3Gi/Zvs8cT+b uzvz2x/jWzY3JuNPguJMKZI1dsdBkZqvZtRUujL9m1FS6Ms0VymoeMUFx9m0q2a8mzgMM7fwA5NR fb/FxHmDT4Qv93Az/wChVoqUuuhaoy3eh2NJXL6X4peW9Ww1K0e3uydvyqSM9sjqP5VvX99b6fat cXUgjjXv1JPoPeolCUXZkShKLsy1QQK40+KtS1GVk0bTS6qcb35/PsPzofVfFdqPMn06KRByQq5/ kav2MutjT2EutjsGijfho1P1UVXk06zk+/aQn/gArL0DxLFq8rW7QPBcIMleSv59vxrfrKULO0kY zp2dpIypPD+nP/y77f8AdYiqkvhW1b/VzTJ9SGFdBRWTo03ujJ0ab3RzC+H9Qs23WN8F9jlf05FW Y77V7Ti8svPQfxwkZ/Kt6ikqKj8LsJUVH4W0ULbVrS5YIsmyT/nnINrfkavA1HNbxTrtliSQf7Qz UUdr5HEMjqv9xjuH4Z6Vor9TRX6lqim/P6CiqKHUUUUAFFFFABQaKDQB5/8AEIZ1K0/64n+dXYvF GqJEijQ5mAUAHDc/pVH4h4/tG0z/AM8T/Ou7tubWL/cX+VdUpJU43VzrlKKpRurnm3ifVLrU1t/t Vg9p5e7buz82ceoFdHrNxJb+BYPKJBkiijJHoRz/AIVT+IuNthn/AKaf0rdjsI9T8KwWkhwJLdMH +6cAg/nTlJckHbS5UpR5IO2lyh4Es4Y9I+1BQZpXYFvQA4Arqa89sL7UfCU7297bNJau2cr0z6qf 6Vur410kpuzOD/d8vn+dRVpylJyWqZnVpzlJyWqZ0Xkx+cJfLXzAMb8c49M1wfjyaSXV7W1LERLG GH1YkE/pWtpniK+1XVQLSwJ0/oZGOCPfPT8BUni7QZNVgjuLUA3MII25++vpn1pU/wB3NcwUv3dR c5u2VpDZWsdvboEjQYAHf3qxXE6b4uaxjW01i3mWSMbfMC8kD1B/pV+fxvpaRkxCaVuy7dv6mplR nfa5EqNS+1zpEhjjZ2SNFZzlioxuPvUlc94d1bUtUmle6sfJtTzG/T8MHr9a6GolFp2ZnKLi7MKK KKkkKKKKACiiigAooooAKKKKACiiigAooooAjkhjkOXjR8f3lBp+MDpS0UAMeKOTHmIr46bhmnBQ oAAAA6AUtFADWRWUqyhgeoNVv7NsS277FbZ9fKXP8qt0UXC9hqIsahUUKo6ADAp1FFAEUtvDOMTR RyD/AG1B/nUaafZxMGjtLdCO6xqP6VZop3Y7sMUUUUhBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2QplbmRzdHJlYW0K ZW5kb2JqCjE2IDAgb2JqCjw8L1I3CjcgMCBSL1I5CjkgMCBSPj4KZW5kb2JqCjIwIDAgb2JqCjw8 L1IxMwoxMyAwIFIvUjEyCjEyIDAgUj4+CmVuZG9iagoyMSAwIG9iago8PC9SNwo3IDAgUi9SOQo5 IDAgUj4+CmVuZG9iago3IDAgb2JqCjw8L0Jhc2VGb250L0FPUUpZSCtBcmlhbC9Gb250RGVzY3Jp cHRvciA4IDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDYxL1dpZHRoc1sgNzIy IDcyMiAyNzggNjExIDY2NyA3MjIgNzc4IDYxMSA3NzggNjY3IDI3OCAyNzggNzIyIDY2NyAzODkK NjExIDYxMSA2MTEgNTU2IDMzMyAyNzggNjExIDg4OSA1NTYgMzMzIDU1NiA1NTYgNTU2IDI3OCAz MzMgNTU2CjU1NiA4ODkgNjExIDU1NiA2MTEgMjc4IDMzMyA2MTEgMzMzIDY2NyA1NTYgMzMzIDU1 NiA1NTYgNTU2IDk0NAoyNzggNzIyIDgzMyA3MjIgNTU2IDU1NiA3MjIgNzIyIDc3OCA1NTYgNjEx IDcyMiA2MTEgNjExXQovRW5jb2RpbmcgMjQgMCBSL1N1YnR5cGUvVHJ1ZVR5cGU+PgplbmRvYmoK MjQgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9CYXNlRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Rp ZmZlcmVuY2VzWwoxL0gvQy9zcGFjZS9UL0UvTi9PL0wvRy9ZL3BlcmlvZC9jb21tYS9EL1Avci9v Ci9kL3UvYy90L2kvbi9tL2UvY29sb24vYS95L3Mvc2xhc2gvcGFyZW5sZWZ0L2ZpdmUvemVybwov cGVyY2VudC9wL3YvYi9sL2YvaC9wYXJlbnJpZ2h0L1Mvb25lL2h5cGhlbi9zaXgvdHdvL2VpZ2h0 L1cvSQovVS9NL0EvdGhyZWUvbmluZS9CL1IvUS9kb2xsYXIvRi9LL2cvWl0+PgplbmRvYmoKOSAw IG9iago8PC9CYXNlRm9udC9FT1pTVEYrQXJpYWwvRm9udERlc2NyaXB0b3IgMTAgMCBSL1R5cGUv Rm9udAovRmlyc3RDaGFyIDEvTGFzdENoYXIgNjYvV2lkdGhzWyA3MjIgNTU2IDgzMyA1NTYgNTU2 IDU1NiAyNzggMjc4IDcyMiA1NTYgMjIyIDI3OCA1NTYgNjY3IDU1NgoyMjIgNTU2IDU1NiA1NTYg NTU2IDU1NiA2NjcgNTU2IDMzMyA1MDAgMjIyIDY2NyA1NTYgNTAwIDc3OCA3MjIKNjExIDI3OCA1 NTYgNTU2IDMzMyA1NTYgNTU2IDU1NiA2MTEgNTAwIDcyMiA1NTYgMjc4IDcyMiAyNzggNTAwCjEw MTUgODMzIDUwMCAyNzggMzMzIDY2NyA3MjIgNzc4IDUwMCA1MDAgMjc4IDY2NyA2NjcgNjY3IDMz MyA5NDQKMjc4IDU4NCA3MjJdCi9FbmNvZGluZyAyNSAwIFIvU3VidHlwZS9UcnVlVHlwZT4+CmVu ZG9iagoyNSAwIG9iago8PC9UeXBlL0VuY29kaW5nL0Jhc2VFbmNvZGluZy9XaW5BbnNpRW5jb2Rp bmcvRGlmZmVyZW5jZXNbCjEvUi9vL20vZml2ZS9vbmUvc2V2ZW4vY29tbWEvc3BhY2UvVS9uL2kv dC9mb3VyL0IvdS9sCi9kL2cvZWlnaHQvTC9oL1AvYS9yL2svai9TL2Uvei9HL0MvVAovY29sb24v emVyby9zaXgvaHlwaGVuL3R3by9uaW5lL3RocmVlL0YveC9IL3Avc2xhc2gvdwo0Ny9jL2F0L00v Si9mL3BhcmVucmlnaHQvRS9EL1EveS9zL0kvVi9BL0svcGFyZW5sZWZ0Ci9XL3NlbWljb2xvbi9w bHVzL05dPj4KZW5kb2JqCjggMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9B T1FKWUgrQXJpYWwvRm9udEJCb3hbLTEgLTIxMCA5NDIgNzczXS9GbGFncyA0Ci9Bc2NlbnQgNzcz Ci9DYXBIZWlnaHQgNzczCi9EZXNjZW50IC0yMTAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDE0MQov TWlzc2luZ1dpZHRoIDc1MAovRm9udEZpbGUyIDIyIDAgUj4+CmVuZG9iagoyMiAwIG9iago8PC9G aWx0ZXIvRmxhdGVEZWNvZGUKL0xlbmd0aDEgMzA2MjAvTGVuZ3RoIDE5NTk3Pj5zdHJlYW0KeJyk vAt8VMX1OD4z973Pu+9XNns3m+wm2YSEZEMIRHIDIYIpJDxNwEh4P1QIyEO0QlTeqGBVHoolWgXF B0sikPCQ+K7224LVKtpaaYui1lS+LUWqZPd/5u4G4dt+v5/P7/PfMHPmzsy5M3POmTPnzMwFYYSQ EbUhBjXUTygqQdpv2U8hmjzztumtqefb4wjhl2cuX6p8G3jkvyDjDwgJQ+a0zr1N/PJILkKiGyHu o7m3rpyTqp/5NELX/33e7OmzfvPn4F6EVsyCzEHzIMO6ypqEBs/Dc/a825bekW7vA3j/wlsXzZye ep6zA+o4b5t+R6vxPiuDkMkOmcrC6bfNTten73O1Lrp9aep5RQ0tb10yu7U6OIvWjyEkL+KOoAwt 7EUZbBhlIJQ82x8S85NnaRmF5Gto3Z8K6V8HegF9hHOxgjrx98iFLmEPHohGIxZ9B5Taj/rQo8iO JqJt2IqykRNNQqMxC3Wi6H78eHJ58it0HfoZeip5GN+b3AflW9Bb6BL04I8sRuVoLNSfhGajr5jP UVPyMSSi9UiPhqLx2Immow/h75/Qh4fRI+gV/NPkJWjVju6F91WialSdfDV5GeWj+9mt3GnpIHoI HcV8cmZyPspEWWgTiSY/TH6GwqgJ/QK9AH2K4h52FAqiW9BatAN7mLcg9Sh6GiWwgTQzI7gT0NJo NBktRCvQJrQPvYutuIE7zZ1P3pU8h3hkQ7nQp/noK1yGx5BnWENyWPITNBV1o1/CeOlfDzuV3ctN TVQln0i+hhzoMNbhY/hVroR7sO+e5JPJl5AB+jMQKDIW2pmB7kOvonfQf6O/k9XJ1WgUmgAtv4n9 WMFhoPiHxENWkVXM+2gAjLYZersM7UZx4MgRdBQdB9r8Hp1Bn2M79uEb8Az8EP47MZBZ5CTzOPMy 8wGL2eeA3iGUAzRaip5Bh9B/oV+jk5iD9xfjBrwAL8Lb8RP4DImTb8h3rMjex/7A9nHhxJnED8mx yX8iN/Kin6A70Wqg7S9QJ3oZ/Qb9Dv0d/QNdxDIejOfhJ3Ecn8HfEIlkkXrSSraRZ8iLzFjmIeZV towdzt7C/pr9hFvHbRamC4nLexIPJ15MvJc8nHwPZMcE7w+jWqDoPSAVz6AT6H14+8foU/RnKj/w /qF4Cr4ZWrkdb8CP4Bfxm/g9/DWMEml/WWQoqYFWF5ElQKd7ycPkEWj9JPydIp+QT8lfyT8Zjsli BjGLmSeZONPFnGK+YGU2zA5gB7L17BQ2CZwp4a7nJnDPcs9zr3Hn+Up+Ft/KfyncK6wR/6svv++P CZSYl4gnOkF2RZCkO4ESP0dPgdy/DDx4Fyj6G+jxGXQBuODFQRyBflfgWlyHx+Ab8U14Nr4Xr8c/ wzvw4/gp/BKMAMZABOh7lFSTCWQ6mU3WkPXkAfIy/B0h75APyWnSCz13MSEmygxkRjNTmKnMQhjD UmYVswYo+xCzjznJvM+cY75keoFrLjaTXcbeye5k97Ivs+9xP+Fug7+nuBNcD/ced5m7zBPey2fw RfwC/ln+zwIvDBIahI3CB8I/xFacgfOh5wq66kc8MAczyT5iZ1fjXsjwYxaZYeRR4MMEmBX/QFVM AvhiouXQNwfxsDaKyass6EeyFB9FZfhNtJonDGhV9gzqwH8gZ9jXyXXod7gFe9i9zELuXRJEz4M2 2kqOkaN4OHqZVJLJZBeD8Of4WfQ5yPsd6BF8C74dPY978RB8Ny7Hq9EHxMlMwGtQZfIpwmIJj8bn EfQA3cPOQjej//OHK0Bbf5X4OWtkfwr6qQttA46+gD7Dz6HvMZf8BrQbA9poOmiZ+0He1yKq9Zph nq2G+egBDXIrfxK9jHnQ+OX8MPZOdB79C33FHQGJGg6a9FxiPvtz9i/J8mQhzDCYZehZmHfz0PUw Yz4HKTkOz/TpJpjpOtAlJTCrG9AUNAvdDVrvoWQ8uSt5X3JlchH6FeB+jwvw97gdZkQXYFSiX8Lf FvQx3gzz8Pr/e5z/2y8xC/Wgr7Eb5+ASmA+93HJuK7ePe5l7hfs1PxCovQY9DhL9Z5BmHYxgJnoP fY2+wyLwxoMKUAz6Oxj63ohuJU3McTQCe1ErzNlc0OPD0yO5Hd5yL1BvF8zn4zA3zoOeuAm9gk5j gl0wopnQvgjvqQM6T4Pae4CD9+FOyJkFWjsf/RXGbcKDyVJoT4U3bQOt1QN9+gP6Aqid1PpVAHqh Bk+Gd32HbkSzoIVBqAEfAA4cQhWgWWuY/wJ6Z2MZDcdZ+GnAa4EZakJ+VMH9BRNUkBibHEzmM8dh jUlCfjusXj50HV4MvTDDOPqQA9ejssR46MP7CKnVE9WqYddVDh1SMbi8LFZaMrC4aEBhQTQ/LzcS zskOZQWVQKY/w+f1uF1Oh91mtchmk9Gg10miwHMsQzAqGBmqbVHi4ZY4Gw6NGlVIn0PTIWP6VRkt cQWyaq+tE1datGrKtTVVqDnnf9RUUzXVKzWxrFSiysICZWRIif+6JqR04SnjGiH9QE2oSYn3aukx WnqrljZCOhgEBGWke16NEsctysh47fJ5m0a21MDrDuh1I0IjZusKC9ABnR6SekjFXaHWA9g1DGsJ 4ho55ABBohE6FfeGakbGPaEa2oM4kzNy+qx4w7jGkTW+YLCpsCCOR8wMzYij0PC4OapVQSO0ZuL8 iLigNaPMp6NBm5UDBT2b7u+S0YyWqGFWaNb0mxrjzPQm2oYlCu3WxF13nnX/+Agvt45oXH91qY/Z NNI9X6GPmzatV+I94xqvLg3SuKkJ3gG4JKe2ZVMtNH0/ELFuggKtkbVNjXG8FppU6EjoqFLjmx0a SXNaFihxKTQ8NG/TghZgjXdTHI1fGezwetXu5BnkHalsmtgYCsarfKGm6TUZB+xo0/iVnR5V8Vxb UlhwQLakCHvAZE4nDMarE7OvlGkprTpN1Y2/QllMexQaDQIRV2Yq0JPGEIxpMI1mD0abZg6GavBr woAVnwUcmR+XRrRskofQfIof53LkkLLpnwgkINT7zbU509M5fI78T0STVE6uiBqU96fj0Wg8P5+K iDACeAp9HKY9lxUWLO8ig0KtsgIAyIcagLbTm4YUAfmDQcrgzV0qmgEP8bZxjalnBc3wdSC1KNoU Jy20pKe/xDGJlrT1l1xBbwmBJL+MqFHviIvhK//MstM2ct6QOHb+H8WzU+V1E0J146Y0KiM3taRp WzfxmqdU+eArZelU3DaikfGRdIr4GK0UhPKmK5XpQ6MhzubAP14T6llxBoRSy8BKbVxuGZWKm3TB 4P+K0yWIVyF1Jc9TLA38iJbuZXxI9Nrnodc8X9M7wyYG+suGSd3EKZs26a4pqwUFtGlTbUip3dSy aXpXsm1GSJFDm7rJXrJ3U+vIln6GdiWPbPbFa+9vgkHMw0NAWAkafiCEN4w7oOINE6Y0dsvgqWyY 2NhBMBnRMrzpQDaUNXaDKaJqueRKLn1S6BOqwyDoHUTUinzdKkJtWimrZWjPM7sw0vLE/jyMZnaR VJ6s5cGvEFHeC8MSY9EIGX3/fSIsaznX/KbQHH4TrN+VaBF4AATJqAhWLsSPTSbBViCvoInMY8iM MQoke5gdnbK9RO1idnaabSVqtcw8ihogEBRnxqAeCAQtYh5CqyEQqF7XUTiwpJsmOnWmEhnqb0YK hDYIDGqHGGvPKgRaf3OnzUlff1+H2aLh3dVRHEslOmV3SUO1nbkDYWY2sxCM/gAYiwthSQ0wMwH6 Ac5gZoF7S/updprlkjZorwqqV4HtlAfF1YwTLJIAU8N4YTWk1ZZ1mFLtLOvIzS+p1jEjGLdWxcwY wRgIMCIjdJQElKMMJbHKbOiU9LR/GzpkR8lxZi0jgLMWYNqglitgPs7oUBEEOpKJnZKxZGu1gZkI w5wIZAlAHzHarcUqs7ADXgTtjWQywIEJMLcwfnCmAkwtk9nhCPQcZR7Wqv2MvgXaG9YhllLQaTSV 9FRLzDAojTMPAsUf1Frb2hkeDLZWmMlFxRAIEHU1pFZTdjKbILUJ2LQJWLMJWLMJerEJWI2YjVCy EeoUMXeiVmYF2gphN6RZeKWjAyjYrSWyc0u6GQ/jBkrIR4F2GHK9nZKJ9szdYbVp1dydBlNJ1XHm dlQPgUDnl3a63CWLjjL52lAKOt0+itDaIRmAdK4ULwDRSXlwnMlgMjVK+DUKxKsD8IyRmQkgTN4l pyh1yPvkd5S/1P3R4K/S8Ndp+JsUTPaQU53QitpFfkvhmeoM8jm8bBr5FO2GFCFHyeuoGBA+IV20 F+Rj0o2qAJ6G51kAuwGWAjzSEfxloIt0dQKAvj/eYXTSwZLXO6JF6UQgJ51w+dIJq7OkOoe8Rl5F GfCKjwBmA3yV9IDLHiAnALoB9oAB+EuAB0kZGgrw5TR8gxyjMk0Ok0NgigZIZ4eJdiHeIVCwv4On 4KUOlHpqKAocIy+R58GLDZAXO8JeyH22M5wdMB+F92FwFpd2+APWah15EjfiC1CpHQxVgMhKnuoo py/Z2nFMCXSTrWSr6i5Xc9RCdQ9TnFNcWLyHUXKUQqVc2aNUy+RBxAHxYMKSzRCXI4WA9EBQIWwl GzvY8nh1H4yJjougNojbtVQLxK1aCpwmJF8pPa+lqshaVA+BwDtWQVgNoQ3CPeCgbCV3QrgLwk8h 3K3lLIWwDMIKUB+tgNEKGK2A0aphtAJGK2C0AkarhtGqtb4MAsVoAYwWwGgBjBYNowUwWgCjBTBa NAza3xbAaNEwGgCjATAaAKNBw2gAjAbAaACMBg2jATAaAKNBw1ABQwUMFTBUDUMFDBUwVMBQNQwV MFTAUDWMYsAoBoxiwCjWMIoBoxgwigGjWMMoBoxiwCjWMBTAUABDAQxFw1AAQwEMBTAUDUMBDAUw FA1DBgwZMGTAkDUMGTBkwJABQ9YwZI0/yyBQjDOAcQYwzgDGGQ3jDGCcAYwzgHFGwzgDGGcA4wxZ cYA5Vf0moJwClFOAckpDOQUopwDlFKCc0lBOAcopQDmVHvpSjRgExGYVhNUQ2iBQ3B7A7QHcHsDt 0XB7NPFaBoHixgEjDhhxwIhrGHHAiANGHDDiGkYcMOKAEdcw2gGjHTDaAaNdw2gHjHbAaAeMdg2j XRPcZRAoxv+7UP4/s4bcgxtFWFxJG87T4Gr0jQZXodMavBsd0OBP0R4N3oXu1eCdqFyDK1BYg/A+ DS5FARF3BMrN1U5QAfUQpkFYBGE3hP0QTkAQtNRJCJ9BSJIyNYs1C/XCbmG/cELg9gtnBGLm6/nd /H7+BM/t58/wRKn2EaOmR0G1oC1avBribyHAIgJxlZaqIjFoNwZ6tgz+YiSmWnqVb/PxyXx8Ih/v z8db8nG1RK7HrKbpFFQODmQAN6qG8LDAaQjl4cgw0EwPHvrGFegIDwp04WMpkKdGAX4D4QCEPRDu hVAOoQRCIYQcCAEtLx/qN6pZ6VcegxCBEISg0CaQ0wnmj9Uiqt3EiPd0vmlEEm0nkgt4RzsixQC6 OiL1AA53RGYEqiV8CEWoGYQPAueeB7i/I3AWil9MgRc6AkcBPNsRiAFo7ogMADC1I/LrQLURT0IB lqJOTMMJMG4Kx3cEJkO1cR2BPADRjkiY1s6HhnKgNA83orMAc9JY2amWQh2BoQCyOgIVtLaIIpTx mEeFWvc4CBQyndChb7txI4tVfaA38HDgG0D/KxAWxONjpYsFcDKnC09WdYFjhT+HytWBjmodrQ/r w4E0jFN4MLAnZ2PgcXgXzjkU2BkYEHiwsEuE7Aeg3xu1JjoC94Kz87xqC7QFigNLC88Gbg/cEJge GB9ozoH8jsBNgWO0m6gJN5LnDwUa4IWjYRQ5HYHrc7q0LtYGVgbUQCRQoRyj9EWDU+8tLzxGKYBK Uq0XAH3zc7qojE8q78IWNV84L2wVpgrDhaFCSMgSMgW/YBetoiyaRIOoE0WRF1mRiEi0dyXPqFFq BNt5zRbmWRqzWlomNCZIs5EJFgm6AcVtTB2pmzAc18V7ZqK6GUr84oRQF9aBL8GFhuO4tQ7VTRwe Hxyt6xKS4+Pl0bq40DC18QDGDzZBbpxsAEt9YmMXTtKstT7qtB/AaO0Dvm6EsWftA01NyO1cXuWu sg6zVNTW/IeoJR1Hf/y5r07649vqJjTG9/mb4iU0kfQ31cXvoS59NzET48iabmKioKmxm20l5pHj aT7bWtME1c5q1UCaTVANRSiAauJwpNBqoE+G02rAo1S9MKBDvSAFUE9nRGGtXlhn1OqxmNY7cFoZ WXNAUbQ6OQid1uqczkFX1QGJAdyaA+GwViuk4EZaCzeGFK1jedqLAgGoUhjQqmCw67QXBbDWWLzo xyo56SplV6qUaW0x+Mc6gVQde25/HXsu1In+//zNHh7FnQOXrXqd7pK0hEbOhtAS37x8njveNkNR Dqxalt4+CbfMmDmPwumz48tCs2viq0I1yoGBr/+H4tdp8cBQzQH0+siJjQdeV2fXdAxUB44MTa9p 6qyqbKy+pq2NV9pqrPwPL6ukL2ukbVVV/4fialpcRduqpm1V07aq1CqtrZHzqdw3NB4Q0fAm8Mo1 2En0OpDhFl+wabhTbh1GBbp7aNC9yneERfhZpI82xQ2h4XEjBFpUWF1YTYtgntEiE90KSxe5Vw0N +o7gZ9NFMmRbQsNRP2kRrVQXLxtXFw+CJ01FJa5O/888u53+tGI3Gjm/Bv7B81ItwN/VNdHt//G3 9D/9li1bdjuNlkVvR6gunj+hLj5oHPREEKCplpomyBvQn8cwWt4BSRrZleyBwih0Ai+lzdFUFEeB gqoOvC6BtPPtAqGuwtJOr79k0XFYwVdDAD+OrOgo0vxlsqIzK4f6L0s7i8pSEPxTCju8wRJoobMc UCnMSUHVUgiJrTlbC7eWt+e0F7aX85B7aA9kBvbQpbSjaA+DlkZv7ycEJJc2AbGhW7S9Jzsy/FrD 7TQRjTZFb8cavf6d2Lif6FcIe3v6rbdrr1/az5BU/u0oVTlVGF3Wj7QsjaIVLtNQtAZB9YIK5uAP rCkBDX+Z4AQvdJEq1YY4NsEgncAmMPKIPJcgzDEcRhKOYzdyR+WLlX2VY+ULlWP6KlEVpOXLEA0s DlqClhyIQNGjywrTc1nl0A9IYXtoC7XJUtbNFyMFRdAAYlU3slbO6bI2cnOd3CTrVOccbq6ygltm Xa4sK1zPrbWuV9YWGviwMxzG5daywlp8feEkTlxuXWpbXsjoZMsAl1sIRrDXg8mAwkjYAssQcvpy vbw+qMsym2QlkAeOrcuZmzeg0GKVzTq9wej2+pCCSSQczBJ4A+vxr2jIxJlH8GSEgMNWZwxRXnoz Y2iPN5cyHZIUHoSi3D3uI5ggLx592CUZV5hN2NSFg2qurEKhrELNIrlKrpcZ+RtdkOYFtbxgVbA+ yAS/EbvIlMM6gZNOurG7i2SphaLnhOekh0zzLPIQsyfgqfIwqz1bPMQTzTSpemNst+mk6TMTEzAV mYgJvEfVaFwRiBZFSZSWRiHnUIMd273F2VQsJciTs5Vskq1VXc1uYcm3bJIl7IrMK+WZSibJpOXy av8WPynyY79qMMb8nqIuPObAa+4oMDW6uHlM7+LohebFEI+VLy4e0xtdfKF38eKoxVqxeMmSJUWV fc2U7d/0Nkejch9EF5rPVp39ppc+aQ/YYnVV0IBSiYqrgquC4eRKUyX8TDKNQW7Q4uZm3JxjCYfL YoPKy0odTqdLCEcsTqfDzguOUFk4HMlxOm0877A7XbZBg8pi4Qj+6o3DJ194aPcxb59r+vmXfv/6 Qy+ezsSc3DhoaK1a/VDdzfVTPsa/GPyXp57+zDJzpq1zW3B5fmJl9cmnDl7KOHrIcfrNjIalLLK3 DCmbmtFXYlpUN2K6l06HpuSb/HHufaSnO1coioaiDnVsIGNRBs74nT/T7vdn+g0ZvD1TCcQKMor9 obOD/1l81h/Nk87K/3SfDWQyGF0nX0euc7m8KIzPh3H4pth+VIDPF+CCm8xKQCFKF5ZUP+LxeR7z N9n3IwM+b8CGm+rRNLCKPJVjRmiMaB7T17z4Ig3N6cTYkbNrvmgG0leO6b3QW3QWIiAqULvCWqFF 6wdEm++W3xhYbIsNKi2h1AtlhcvtLmdpSTkQLRIOgdzjEC7F/0d504uP7HyRht8HPQWFHkXxFBZ4 grjyFGN8N3HixW3bfyx0B6EQYrbhzVeOvwXhl1sGZmcP3LKlOCd74PfneP0Py9985ZU333rllbe1 rC1aMbX7bkmMI/OAyjKqVU255r0MESWMJBlZxeM4C0lgtGWBhnpE1Un/MDyusMUgyF1kW6flmVuo /mnu7bvQK/eiqiq5UgYJws04FCZlsm1QeSkhDrvV5SSzX93ZPnPymp6Nc68rCyXGncN//woHMTlz PPFe4sa/PZ149vE5tCcjoCeq1pPRqjtCIrq5ZK5uO9lLnjUJEugU+GeVaZ8Q6D+tTy+L/+AeN9De WBeMoL3p7Tt7bWdsw5iyGGFKnVaHXSDMyAk1QzLmbDyxfe/wuhcS4zpeufTZsr/h53DRR4nMS+99 m7iQ+IH2ZFmiGz+D6Xl51UFJ1PM6oQtnqj5+Fx6s1+mW4LCQbQaRVFAx6FePYe7ytJic7YO2QSL6 sAVmXEUFsD8IrOWFyKBB5aH7sSd/2ZTySaPIBux5584HWpWlGTMm0faq8Xoyn7SDbi5Rg8VYxQSX g6aWGYUpZlimhpO1thjkYZ+5lbZ1tnmMDPJX1NsMTYCurya5eD32JM7Rtz0M0QvQewZlqw4yGOlI +Kresld620f7OrC4FPAfphddNOxkX/IcGQpcYNBgmBoYjyaMnRB63gnrEP4r8XLMX+EtD2v9uDCm FxTTGBh1ZVXlem5AVJN5AcSawbe8n3jIw33zvR04hSYnz7EmrgeZoBsPq3V36Dbo9uJ9wj5pr+mw 9EtJnGxpcjZ5JwfmWuY553nnBsQKUsEPkgYZR5PR/Eip1rhX+hV5h39DesP4Mfk9/4H0gdEiuxU3 cVOVmgNK3r1HNAbMRWZipirfvAdx/tP1LGa9WfbTek/w/dd+7O9i2mHQpTRQIUGg9EpcTosswCxE Frl8kCuLF3iL7ITpOKh8kEUOh0nJ7+7YsnXF7z5MfA9xaYPTH6svTQGuZ8fLiWmJlkPb8Gi8B//8 0LavqifeloDfq2r1xFuBmeTVauDLU8DSMNBAQpNV6RZyF9kMZGXBw++cxmGui9x8WJQ4jAwSOgq+ AkGYNKtGDrEBVmHjLMt6dEfwXtyOUuyrHEPXfo3wF5p7QdRQczBo4YWyQdnlpUw4ce6x9xZiUnyW DW0dmcx+Zx2VjFKEWAP0wI+r1GkH3Ye83b532bfdp9ynPKe84gjfiIwR/smex9lH3fvYPRki71VQ Ll/uHcWOcI/wjPCK2e5sT7aXcYbZyewG9y7froxd/n0Z+/yiFfllv+If6F/uX+Pf6v/QL/opX5x2 R8xPZIPZTwWYUAlUQYy6+pd48mQnwQYz9cdDAUORgRgo7wx7bJx02unE9dBlb8B8Wl5BPJn9DLyg cRAUL53nfdHFZ8HsiTYvrtT0b2m0mVp3yJ/s6bBU0D50mDWgmuQKVpQrONEC0FKRMsiaDvBkxMRG VS/5PD7is2F638WiqfDmJioZdeMajyNf8gzKgOBPnhk8eHAThjWyGVuCg6zlg6iuBlXNCzmDslNq XOBZXmANlyNy+zevRIfMbmqcJya+9GDxrY8vXT+mNHHxeifmEj88gqXfH6i6cdLNsxfclfHlu1+/ NLNzRvWFhjDl0hiYKz7gUh76WC1Z73jHQe7K2JxB9jDPcXvth5gj3CH7J+5PPaLTjh9wPuAiQfBK WeyyOYMBo2zQdeFs1VBvxKpxi5EYjdjZhYlqDtiKbMRGyWvb4+MwkPygDHIF8gfEKYFsdk/EGDf0 AA8MTvn06sCWwO7A/sCJABc4I5yuz8bZ3qjztGsFPo08+Vcm04X0dAIJtFQUNacZQiP6uLiXrohU FWokpVQFogL5ULMtR5tbGvWEcucVMg4jpSX0voVALQ4Uysoeg2XjknE3rlgyflBdYMkdjaNHzdEn +ny3vb7y5N1z31+1PfHFb99OfI/XBuctXNO64KeOz5n5N97QOKulYO3uqWtu3fDq7b5ja19NnKdn IVOBrmXcHpB+Wc0TTYqh3DrSOtqz0/hz03brJybJarFZg5aQda0VJh026gwGo9Vi6SLtqtNktJtM RqvOTu/YqZhpwFthWl9DxMMaDX1GWI6mqMaArkhHdJTcuj12SmK93RlT7MV21c7Yu/Dzqt1iCchF Muk3VTXblbZlM5tNrFkGop9yYdWFXd6AZt5ajSvwsVMIq2g32k+Xgsz3u/H1aWVAWXAWWKElqFKQ tTkBGdErHGleDAygOtoEShpf4YrGkWvYEbGB5yCAWYKAD6ARs6dit2H5mMY7V05f2XJ2KznX97eC m2ccxez8LYlfJRFe6Z+2aMvW9etvCZIfEv/6V1Hi/McHH3ztE9BgNwLF80GSXSiEjqtDF+iXievF 7Z693F7xOdM+W7fpkOW4rcdy0mZ0cIMsNfKdzoPkt/Ipu3AUnQR0Fgtuq+xTYGpSEmYCiXx7zMZA sChIUob9nioJq9IpKSkxUheu79yPMabEygqwRcAWVeOJgwOhXZF5uh5MO2+O+7TVk/0/VoMLKVVy oRkImF4XqOSitMSCvGIurAkoUMWqCSYsEwhmPLZfoRvPmhPndRNHNN0lz98V/yFx6eQfE3/G+X/b +/u+J1eNGzuvdeK4VnZC5sSG9r6fJi588KfEedyEN+KH8ayjl7/a+Oidm7esXQ18nZD8gnVx9MAs GxVj48Fi0R+IhbuSl9RbIfG25W3bR9xHArtMXm5fIzNhlG8YhIYaatFPDAvZmSKsn44VkfWR7cYd 7qeNz7mf8+7J3BvZU/Bccbf3cKZrhW2dbZ19fYTdDrTYDnMiY8AOSEUlms5hBlCCVQ2oH0AGHCEP gtLrUWWnO9aa0ZZB2sHszuCtuZoLA9WKc9Vckgtutmq0Gquy6rPAk4LsLJrj5bnAaWlF9HS9GZu9 JZ7TzIqc007PwH/XG9pC3FwFvousaYwouDKU9M00aPRP6wzwTMAP1/yStKKlGoINZUVolu0qNjBX pfGo22Z+/v575xa03Lk60ffRL9c+sbx7Wn1Dy7Sx41q8K5puXLK0ae5sxjXgyZanP/zw6Tm78wce u+tXifk/Pb3ibTxu4s3TJtZPa+m7bum9dy+fe/eD1I6pBu7Y0xJ9Sm0caqmzzNbfKW4Un+OeE/eY 9tgOom7moKnL8rLtTfSupcdmidkm65uM0yzjbS023sOtcO50fSp/Zufm2XBKwAO+IhBwNSXcnBxU QLgpkWVNwIslXC99Jp1PC3h7SsCv0t2+lIwb3afrrdjqzUnJuuEqGb9wxeb5X2S8n8BpLVAOc56U xUC8qZCDX4I1Wjo0ujZjWTdx5I13WhbsfvEHLP36M5yZ+PDbFz4gN989fuxckPFFeELmhIb2y3dh /YefYUtib2JZYmFi12EmY8O2u+5/cG0bUPEdWOb+zIa13Y4Bqo8ZjHl+MKuT9jOE8GGscMUc4faL v35e8zDotkblRRCUqt6UtQuLr+Udaq9iD2Ok8PI/UtYr3clG3AnuCLxXh6u7kZA8rUrlFTE+FyJB E93cshivQgRPp9WGYATKIMpD+aCpcnVFhsGonKsyLEALyGxmDjdPnKv7kjHfwGPqFjE6SWIFCWMF CWDWCrzEsgrH2zmOF3Wq1z9Mp6l6rz+myyEMw7P0eEU18QLhWBYj0UBd0S4yXdUHsHZduw3s5C6S rUoBCRdLbRKRjpBsxEINSQGb0KO/eWa/se4BvoGid/dpvid1PWUw/cZQv7MILKCoZn6vv/uN9QPc FAjg0q9/442UgfOyFJOMMRSlNk1dXD+hLp45bgqYSUwy0SGyuiPJBFDq8gGeHTw4beGk7KNgkIE/ HLQxDHci8Upb36GVibfIUFyR/+5beEyikztyeRNR+s7QXaVtQPkZQHkbWHoF6LRatSIfzzPdkf8F e5FlpaBD4nMLgjlOa8BR7yDFjv0O4nDYQ1k5Vpuo2HMwIr5IK9/GE74uN7IfdBI1EiV9DJbT+8En GqAOaBjQMqB1QNuArQPaB4jKgGJQUvYsBSm2YjBsusjmzsKBE/pN4z4wD8FTj6ZME21njAZNxWgG oiPZ1uGvcFAD0UtB2wEbtQmboNJVsyJFKzPd7dQpQBdquARLMkm/+gHPjueCYHaC065thYRDjCWY fgiHtpEbXnp+/ZRF09ZtbX5y+Q2JzxNGnPvai/k/ubHuhoL39mFre3T4BHXlu9wR/007p819IRo5 tnrW8cVGkbBvJV7kpBuvr5kkcX3diTskQ/PY4TflU+twevIcdzP4Z170oTp2nbTRvtG5G+3g35Y+ YD7Q/5ORcqRcQ64xz57nXMYtk9ZxomATXC6by5VH8pkcTsjldnLbpXeYN/VcFa4HK2a8jPAZdB4m DyW5xa1tvXXqQF668BTV5S5kRZNqssZMddPMmCp01eGOgc2eq2ZZC3WM+VvTZPQt0l7lLYZFwhFp F7BZCAjFAiMA9zp9qyZcsVLGyqB/0gvuBTBRzkYppIlm6sFgalpzPBtSqOoJKi6nK7Xwgi8Gyoet woHhiV9/k/hDYgO+E8ew8dlZJYnfe59Z/otf/bJ9+T7im3r+K7wFT8EL8aO7b47XLlnzdeL7xNff bKO64RGQ0OkgoTI4w6vV0lyY7te7ZrOzDVy+q8I1ytnknOfkKlyDfOt9O7ltei5goWJps+aYZdET 2S9gIS2TdFSqrS2IlWAxKGuLFaRQLpaJTKVQ+Y9SeEUE6SgXYypGLqe2KcHTv1BKiIYRKjcgRY8Q /+GWe7paCsvnjLlvxtN97+PcT39aPmpaZeWtE4Yd5I5khF9LnPvNwfvaZ9blB9jXLpeZrJPf3Lfv 0ByricrIo+DnnYeR6tFW9TqRYwUxh7cGOFzM7QfFykkMmwNOqU7K0SNR4OsYMkqH9FjvVYzFRtXI GFlJwdRZA5GAERmuHpHGwMoxFyovVP6HacXBfPJXcDCfYFpx10wrutlYqe02OILp8ChbdfkrcqZP YUq5I5cSR79LLP4Oer8der8Gei+hJWoV9J7ncgRFLBZPiJ+JbJG4VSSiiFJDkKD/VXw9aI3xDIJn r6Iv1hP9tf3X/af+N6dc575KK+38f+rfdqa3byiZ1beL9u2ZS30PUcrOgNlH9yQV0HC1gzPrMicL y8XlhrXiGsNa1xqfxLt4n9Vl9eVact253txMcZR+KjtRmqJfwN7F3ule6j1kOiS/bXxL/kg+J5uY DF6hs00NeCsC1AIjGDszCnnJSiecta7ehm10ttnobMt3FpoZBOuGZxpkR6yTSUBRGBhyVjHYXp5I uw6bdQFdsY7R0VkXXLX7mllHBy9f6F2srRep2QeTj7ptlX2Lo5WawtMmIC4LWmAGZmWDMIKLW6qw 6TnokK3UOihjqsiq5sTug18k9r3Q0/3Ab7EFlxYkPgk83/ba518eaz46gvi+6+uasvFVPPf9z/Gs aaM/f7f81rsv/j3xQ+KH0bEjME66VuRr8vkLNUdiOR1DJF0Oa93PYIZBPMcBKwVRBOnkRIU/SWce 2axmqcYGY4uRaTW2GQkV1XZjj5E1En2K2T10Z0ET12XXTsAlF5vT5yPakgkR5bkmr4wmr0xqGaDg f8hrv0hc+duGc0kNzk2c7jvGHek7Qaq/ryX39K2GMd1PvyCEMTFokTYPOktiMY4qjFCOBtUquyuG OJVr4Nq4MxwX4Fq4Vu48x7ZxdIeIQSJhPsYIxdEZxPRQfUwHdQqeWLSQHdjPzCXpoVRp25uLl0Bv af/ux7ncke9roR87gbavU9rih1SvyGOrVafjGMKwsFhJOknUcZIo6cQufFiNCrxdEHiGGjE6MGJ0 OgmMFh0jMaIeaoPNAh1Der0oiGwXmdXBjRIBqFZBUxTkCuX71cTMH+nuoSLnTin6K2T3AN21EwkE AcwVd5QFV1RLiDQhypXiGwyNK1N2y0FJ0RtjwJd3O8QI2C/UgEEjGlVPmI9IW9kdfDsbZ3tYYQ3/ LPsle5EDeyt5prN8fEyiBM+GRA5/nW4ps47ZyeyUHtPtY44w7zC6V5lTzGUdc51uOEOWgK2Do4ub mzR54JNfdlr1VXxX8ktwxPVVbLHRCZHBXsUqemsV9ORUp9mTgiZXCkINDUIlDabrdZhsVejq40Mw HyincBDDP8GyEyRpMn6w7zSpTdyTuA3Udd8ysrnvzcv3kPg/EyOBk0+AHnyGewlx6DrV2yBQKWFh BUciy3kFwlxNe35g99UqLkElZExfWkg0+XU8Ae2d4V76YfR3VI+BMgNn5AgyELeq1zNhMaxnWJh9 oLJVKWNITKcMGRrTqJmG6tMZAyAXIh5k6C/SNzqw6nQ6G8lgZSmgC5ECVpGKdHPJPHa2tEC3gtzB Pi3t0x2UjuguSt/rnLvZrdJu3VvSO7qPyGn2Q+lj3TnyJfu59LXOuEK6Q3cfuZ+9T7pft5UIjfrZ ZAE7V5qnW05WskINqWNrpDrdjeKNUqNOcOuKTDEyhI1JQ3VVJoEhBpaXJJ2DeFmXJKT38wJAKJ3E GQShhDcZSrStdCI2iMaYnkbaKE0gWaJqisT0NIKsXapME3qRoY4ZEXRIpLJbVUklNsXIZlzUK3/Q SzN8XcmhaiG0orCiJJUwrJ1hWKLX6UoYAkkCr2EMLCEGmFSSIAa0Q0pjJ/126AgZrCmIqc0pxeCa MDHGlQiqsFrE4vHVwIXjekVvIF1ksGoFjaBCRaRCJVQSoIYxvMZIdZx8YTE96av8m1zp9ch9i/sW V3rd9OAPMuSzi+kukDbzUpPtKt8g7QfYJoDEi8kzB/QKNfqbtZ+mUaIIZgSIDUhqSmItD+GjWIcF fCzRm/g08ZfEH8H0dzNffl/L3vvDKhpApnaA5gnRdRv/RjVJDC96GJfIWkGvAXURnVdUw9JhU6jm w4iYEkEEFSQyIiECIwG9gFYMS0fM0hGzJfxJbW98s+pR9Q36Fj3Tqm/Tk3Z9j56k1npRSr9Um/Om CRNiUsk164HuqvUA3CRYEfqXBHjSNCm1+EEnVdBTO/gBhVJyRNeHM6oEUiEqKRnpOSxRqdGcqaim jkZotdoO6cvENn2ZNrDrvANi4gSIOMbJlDAqw9Yya8FsaRc7xLMM/wZzUvxEZBSmSIwxQ8V68WfM brGd2S/GmROiPuWklpbFiFqqOalnVGNRSYwoNBLsZZCzXZWCA2JkIkRa7dpMBZ4gEokguAnjEgpI RBhKSoWxRBVuIpMFyU58whgyUnhMeF74FfmYfEnOCf8i+gjJFW4Q7hA2CC8Qnq4mS368NdIvCk1I kwSqQ7BlB1ZII7YlPuo7AAJQyLz/fS1z7HINta6bwDI6B5aRGfnQU+qk7dx2cYdhh4kVsWASzYI7 4r5DWmEVVljucKxjN4obDetMa60b7RscG1wb3Ou8BsEKkuB1WL12r9vhFWyFRslTKDDOyH4dRjpZ p6TsGlUp9qv+Fn+rv83f7ucV/3k/8cuRdoTpGVexxvP7OzNWvX7F+NFs8ObUmQ/dQQBBXwx+XAy8 NGrdpBwNhO3WK7tGTSNKXpy7sRPX4LWJVYnjie7EKjzwiwMH/vLp4cNnyAdndrR2RIckFiYeSzyR WATuxrx/JZLJ5OVLP1A6UNv7EswCSocVag7Pddu73cz1HJ7LfcgRqyXHaDIhn0ytVzMSnf/mVzgD /uL0+Di/bL5ay2dc61pc8SzSZuyP3gUwDFyntIMaCnkIDC3tnz6Kf49N41ftm7F97IJ3Xn1q//IR N48qa+eOOIOf7l/fNd/i6PuIfS3RMmBGdcM8o07j6218JvDVgXLB9bt7nX998DH0mH2Xc5eLv0O+ 27VCWadbZ9ogb7Bv9Im8X8rx+ux+e9CTc4vrTiQuRbhJmAcittK7MnOlsknYaNnoXafsFB7Tb7M8 JxxyvuX80Gkp9zVa5gvzdXeilWCO4J+gm9CtiM12ZkUi2U4BMTwJZ4DxG+kiPzkYrs8qlAilmNkS I114gmpmPpCkcDjgiZC6/fnYmqamNSUt+Wp+S35rflt+ez6v5J/PJ/mBSLsBmw0BQ7GBodsLnXn/ U1qArmf7wDJGVRd6o3JfAuQGp29R0ENd7ZYEPQXK0W5HhCN8v7+KLODQ5QxKy5GDOq3l4Ui5kxt4 W9ttI1TT4a37Ey8l7sFteDSuxavKchNHKirOHDz4pz+9oFZMaZ7wsyNjB7xnDwl3VeEH8Tw8F29J LE7sfGXrQnXEK3clfrjcB4LmGBp8roRKGrWiwQoFzgTRJfXeCvNo843CAv0CAz1VbQ8dMp2WdLzI 61yiUzfIVGuqNQuiLFnsJrvZLg8yDTJfb15mWim/r9PfId3hWe7fIG3wrPPzktMuGcymCaZlpjWm R0y/MHEmxWiwG40Gs8FhdDlzbLIdt9jb7cRuR0qQCjKItAOJJrrZFUFGGUzDD3yRdj7O9/CneJZf 3xrCSqg4REJBx9XynHW1xajN0vRujbZs/eiaafqZ3qi46uRCc1aAByDqJc70frDLFmQGkFDIYvlR 3kPbyKK//q7ttVdb7l7Qmfj5h0sm3jyn8ve/W1BZPyr75XPckfp3733mo4zB655P/BlXPd8U7NvF jM1uHH7DVANH7aQbkl+wfwfpL8Cn1Ou6LV3+Q7lvFbCCTXC4bC6HOzqbm527lL/DuDT3Y8OHIUOT bpJpUlZTaJ5hjnVucH7u3IIV/nX+bUGDNURtqcxAjEJ1tscbG5c1LvRq1qshdnHW4tA9WfeE/pT1 pxAf1eUbs7OyQxXGWKhOV2esyRoRWmCcHVppvDNro3FT1h7dXuOzWTYw5I18Fh/y6DxGZ5aQFdIZ Weya7FY9SmyRGy9y73YT9xEyG/lgfTCAc+nDvkI7g0ZhumCM9ioxeozVgFvwVtyO47gHi/hvrOqt kFnMFuZL7m+TLuxSba6Yq06IhL0DYM7IcZnIdfhbS4qBnsLfprVR3YTGA0gd3KTttWnXAS5El9AN Hnp3KXo2BZdEz8IESi0qmqmdBfTw+YeFqMmcgn/psFVkAXkAwNM7HVb6dEo1WyuMirVCpwUzzftS NRkgz1ihc9Ngq7jmsl7/oa5jiG6IsSyrDOg42jgiqza0R/dclg7Rg93UFsyVM6+I9lcWG/Sjsyvw DrvLyWqSRXejbsCKd/f6LQ9d95NY999a1q/+9jlsxy4hcdp29933jC4qGIzjJ5fdn0QnEl8nPsSf Zjy0YeW42GifdcDQyStfan19zt/fNS6eWZZVEcspmnPb8c2r/nALxlS+CmC16Nb2q5eooSKpmC3m GqRWqU3aKgk85kgOyxABiZLL5WVXU0sIF6o6XlBwMaJfutFHC2NqIK2kjWwlLPGIfS+kuTKu8QAB rmh7HX2VEI2cXXM2vVpUao4BLOlldKcDf5YYwz6QGMu+dunSD/Q7u4dhLc+GXnnQJnWwIAqSIIMS ka4Xr5eEG6XJ8jZ5u2WH43HnXvmw8yPH5/xFXm80GDAiQo5NMugV40lq7mouu6/B1+JjWn1tPqL4 in3tvh4f68Pg2yqeYk+Ph/FQReD9X132Xk0ZaK6uLWgBlji1qQ3WiGwioSy6WVb2MM7V27b8dFWb F+cW33P6pd9+vMruB/Pki+ODp9w2d9tLTPRyInHpk21N0x+ftOoipbqAkLCZej84qVqjTJRX9KV6 FvFYr3qHxMD7a+sEyFwFOzxlYF+eUyW6t++ByND/hOgTR2d1k9MfYxWIBHBIeIMXOaQ8lCMJX+nO Gb6T/qX7zsC9zb2je9vwCfoA/J8PDV+jzyXpefYX3PO6ZwxH2U7uqO6g4ZesNIDN4op0iuFx9mHu cd2jBjG9iy9ik5Hece00BVMmtAQJcF+CtMu7OlOezS7VQf2cWfRJzzMIC6y2T6Zx/ipfRlOqvpdf 07Oc0pUs7uTBlelKlqg3McigIIYQBSM7CKmO57gSvc6u1+skXhAUUbKLosTqDYa00wONMAZEMGtg OJ1ekEReFASObh7AyqC5P7A0gPwWgXfThYtVncIf1x9Xi6i3CY8GhR6EEOwx9p91eD1j+pq97r4+ r6ev2d1/3JHyZeT0n9Z7eo1Ri5GFujhjrvZxrgUpW11zcRan7VsaLW6mhxvg39iC1C3HsxNP4aJP sQH0Iv4Tzk/sSryV+EPiU5AlC/PtZcQi8HdG/dBFb0nB2tsIEiSiN7sRm3xFHaYv69FhlmE5RmA5 luFSaYVgO9BBy1F4gRpkmBXANwKuMAQ8HsTpRDwZLL+5qp4HUoPrSJCoO0pc8G6euA6Cd6Qg8AVd h/GVpXNOp0SJRc/GPPJZ8PlSAGZ3mkIXz6bvImqksaQ9QPHq3RawBSrXi/S6Fm5G0f59CQtx9p3D U3ETHo8n9X1O5jPj+o6Rmssv9u2EeeMEbXVc8/Dm0LO18wfNFQLB1rTCNRBQWZgH/02vo+tMpxKJ YToxfOAvYUbgVcjgFXjgGZbJYUFbULHsreqDvkajWoT776n6VAeh4oYJCCHh8znC5HAswV0krILd LOSAVPHcKLFVwprjlyMZYpI37SPq2WJwuxqYFmhnvOYYwHqlu/xCv5KBQPenotpGdure9Bda3Jt2 lNOOHYZB+JSYtmiG6FFhm6VMxaP4BjwLL+Jb8Wq+DYtECebGBBXqgVW6p8NSpqfVy2RPbKzQLMwk 84Ul5G7hAeEgOSpIfiILhUQRqkhx2jtrEDaRNt0W/SVyXjCnT95Qc2q/KFoKbAEVjYMOJ0P6JrED L3/KDMd65vClLy6HvoNRjU5+yQ5gh6EQKsGL1XmCV8zg/E7vDb5RGaNzfi9/ZpEGeWo9N4bneOaG 14V/5nnYu8fb7Xvb+0ufgeeNDifvcUb4PEeTZwVZR/bwB/m3eMOJ2Mcy8WeXDLQUGLPV6IBYtpqV C5HHH1uUfTmbZNdqN6qKTebYdX5Mb37F/f/ys35/AS5FKuSmCD4pqGZYqoKqT4bI7Y0Fu8jSg6xg MOoKqHBAmQahWINQowBqqKpdnzkwLOZJucamgGG3gQRASxuwQTU5YwZvfQzHWkASHyyG6VqaF5zm wp+5cL1rmmuRi3F5SudX9++TghWyuLc5xWbt6ay2ngBhQRGC66/ZJpqFGU3Jb0eRHy9u6u13/bPB 2ff5YxOzZ2WT5mgT5QjIJaNdlU4dmIMRERlEbyM4HYzd6QpqngC9x0stifJB5ekrCNQH087Oteti eHYy+tuTx7rqGF9O4mu9LDCjnm5++vjkx3/25k8aFtVNxDcP+jq7vLHmJyNLZT3584DHHmnaeDjR df/an2SUe8Ta2o4NUx6oy8hRMsaNHJr4rbXEHakcOrkkXJ49G0i+HqThEc33zEBPdCNr8pI6UF9R 7rveR6yT+cm6yc7J7qaM7wS+jB1qHGor841k64x1tpG+R4Sdks5gAjWMvPSLC06wU17Y9Hoz0rmC orc1E2fKeYQJm+kXiQbciug5vsdflaL34soxvX2VX4wFnzTlkfbSlVvzlHDziEZVP4efo5vjnOOe n8E1N6Fmbc+a3qVJXTCIOGza1ee037Qee+7teC2R6OueekC1xkavbL5vzdzZ67gjfecfSZxL/Ctx PvHJ1KZdJP+Z+tbdzx968gm6pk+CsVfBTPCgP6njGs1N1ibnPPN863zn3e6Vnu1ku+Et+S33R/KH 7q/4r8SvbF85LvG2wbbBjhusNzhr3U2G+QZhiLXcWe5mVnArzOu5deaNnmete53d1kNOyaRJqC9m 0j5BsMdMpUaa48mMGdOeqPEIZpEOaGa16JEKVZEK9VDpVpDTI7CMslCkuARMc3EQFRlpwhisB0PJ 6xOCdo+3sfrHO0nNY3qj4HrSY5rms9HUGSnAlOW6uP82UupGRjnH81fuI7EDE381zayff/fqWxrm OLA9euHXXyX+ip29r31OvimZMPGhfcd3TV1U9MprOIxZLOCcvdSTnAi0m56Wm61qobWJb9I1WVPS sgNE45IktWa2ZZIhTMwwxBHz3MDUGG5w1Hh2SpJdExc9lRrVpBdMZmCFzpVnMoYxlRSzGXm3UNkJ ih5/Y+WVES6+mJIYzSpJ7cto/hzIinE+P18335qSFr65KRgsSw/QWlrisgTx1aLCTk/8UH1gyuHE D4nXOu7Fnj5rUc2d0zesmTtr/a6pTTgCfo0Jex4h8uXWfT9Z+MzTh5/crd3i+ZKNgKzYUQb+RTeS YZ7U6it2So8Zt8nPcnt1R6Wjxi6vKNrxKHI9X6urz3zWeIg/5H1b90vDh7rThkvCd0ZjhjnDoYKG cKgmS8zsOOE46WAcmjRkVmnQ5AJIHlDBmbY2mFpMxOS20qXkkMcXw6VW7Zjdr6SO27PyUjBamILu DA2qZlCn7fTrTBm6Pc1qpZ9FsXqrm5I7Wy+gIC5ypISoKHNa5qLM3ZlspjkoqkZzDAie1obRa87d e+lnWXa3mmuvcquZZohABbuprta8p6o+zT2zQieghraZApWsaVVNYUd/1QtpY0pDQFBgraCd7nBR EO+UdMO0x+pglWZuNZ2lGrRZa96kApVMtFETbd6kArFSW6raZRZwEsHEK9XsftAWmIq4AqY+lXHE BDUvwJby01zke+we9NX+xF/Xzsf293uxle9TmXunD58SYe6YfFNlJcbjix578uBDn4IsRBNvJ47f vXkUvvXO1SNG3E71hhsmwBfg4TtRl1oyiMX5rCIrlia2zc2J7Ak3cTgtxG51Wkw2M5JNNvrRrF0S zXo8TZ/UEz1lhI7HFrMTJ53YSR8z6be15+mntja7TiqtEuvFBpERc+UiyzQLsXRhVjWabGFin4ba nT1O4qQyAeaL0+O6o5vMR+mPfyrH0G+5LjeD6+Y5i9wwTehmCIQqiCpKzPBLr0O2Us13LXEJmlZw lDpCoF5D7l0VO5fdcXt4xLDryn7728S5XWy4Yd2aCdlvyBXj6j69fJgZrc39xDi2RbMgivBYdcYK /3o/sRqMrQPXGdsGsgoOkRBTjEtJKaPiEWQEM9XcZG/KmZw3GVh1i/mS5ZLNOtRY6hyaW1pQZ6xx 1uXWFJw39Ll0D8KarTcY9fkGY8TkdDkKjQZwqN3ZdAYc1GaAJugmiyYknXpDCubmpyZAKCcFB8ZS E0Fy+LSFfxpHFU7AHKHApCukBNc7BLeHz8/Th71uqnQkj8fr3TIQDwQV1KXqUGl20OopvqJ9LqT1 j9wr953tX6z6LqT3vvvXf6R1Tmu8A5ijie+Pm4A0UAs6vcQt1vSWeb59fs7cvDnR+UU8XeVcnNPV v+6X8dpVRSrArjLwZMF7VcBQuPri4kpcLfpzJy8sz7EZV/V8ePcMjE+82YaFYa1HtyT+/ufL97XM fXDDvNn31UYGOzKDzoGhmx9/4eCW32E99r746OXrjx1ZUNn9oInc99wTT/78mfYngFg/A3u9CfS6 E3WoUTMO4ArKSHk4Hm75I/4XlgTOyWWTRss8CwdGts1usdoYO8FmSlQ/I0g6nd2hA6NfrwuLkqpk x/ZLOAkGt1f76sKZlR3b6m53k1b3eTf51o3dyB52OjS1BXXbHfi8Azs8rqoU4RcviaYvYEDqYvop 5ZWCZ9cLNHVp5pVYmb5ySw2ETOIAUY5pyx1Pk/j5Dcen76r3J84p466rXViaOAdmwee7R7Vu2NL3 EBm4d0pZzcZ1fd/AoEG2tS9htDN5Aa3oRhI9hbfoqlSpQSJtUlzqkU5J30pcQGqRVkvtkMExvIDA VzPTe9b07J1BzWAT8RwvsDoiwJqpyWIwO8Z6xPS4fhxHlTY9f7w4AJNzSbT/wuLDqQuL7CHMJi7/ cAMb/uGT/m91tB5O0G4NqHm0f1wDR9q4ONfDneK+TV0VWM21QwaX+gwH7DCM+nuCPOy/9STddvrT nvTNgFUI8Ttgpkfw0G6UB9jN0BZoVoODdxpiTEyMuWOhGjJSHOmuCRkUpihvgtSS15a3O+9pfq+w x3CQP2iI553KO5NnQnlFeQ1QcCLvszw+T/VmxKrguU0r5IQgK3j9VBV26ISgphFZQbZYIr6MjHBE B+Q0y2GrRZ1S1mLBi4A4XaRWNXt9YX8G5C3KwC0ZOAPyXs4JhyPUiuhAKKItrFIVheog6HcEqkbU agiVELIjsYg65LpYUeRk5LMIY44EIm0RBkWUSHEkGWEjnty/VPY7BultwtT8r7wIaxio2YvgeFX+ KI7aZkNq17//LuCSKFW1OGoLOqjN79Isf5dTE8/IFfH8UVJXYWZzz5xtxbVP3bTsqVyQV39k3NB5 AxLnMqsGVc8rTJxjww89N3HSpInTbqrZ0ddEpv18QOWozdsShNQ+PqWgds3Ovsupc3q2CXjmRLtV t2Bz2aaI80S2i8XALblGrDF/JXO8Nl0tgsnIG/R6ML8IDjuRNl3Bg6Xf0Pwv01WnDxtMlL5Go+HK rE19AnntrNUo9W8TV9uQuWK5Ba+ZphqRYPKyTYlz2eMqRi+NgvBzm99vfqw+QDJfmD24YU1HIsCG d708Yt6au+hcHQ822WMwUiNY8NvVUV/ic+J3tu8c7NvkS45YPZxHIk3yZNtkZ5N7O9nB7xC3G7qk 35Hfc3+Qfmc4x53jvzTKe8Vfkf/iXxffMnDLxI38GpGxaFKod1ES2VnBXiF4W3ytPuIzBdE1JnfK cUkZov0aXZovzwE7dL6bxVSd42ZbzJr6LIJ+mRLOuUp3j9/Ut+u/cSzxzjc/S3y3CSvbFi589NGF C7eRrPsxvynx9rf/nXh9TfLZnz/7bPuuZ5+l492cuJXdDuOVweZ+TB0w2DbKRqwxpsJYYYv5apjR xtG2Gt+/fBL12/pt8YvCv3wizJ+rfTSnXi+bTf0+miXPZDKHZVkzvvX/00sb01sJjJTP/pufpulb uoZRP+0q25ved3VQSU/fBI9Q8/vHUW/GfOlLC7oxSVzubtxSDyx2Pjhnxr3rZs7dAKxtmJX4Y6Iv cTHxce2kvq+Y7s7nn+jc+9RuEMj1CDHl2tifVXO3c1gy4QncHG4ZxxRZG03zTK1WVifREzqyxZA0 kCpDvYEYusgKNU8QQL4ZwutykSRLxVKrxEre1dbdVjLNutq633rKylplFKZbizB+QtpwO91btFR1 4wzU76peEeeLzZ4xKdMKKAHSXVGSIsViVBd3TaD/EwO9+VsyuEn7ti5FiZSRxVtwO5XoEbfUtDTd eP11Q8cXseHtt9SU/XNA9b7Ef8MYi0GeZRhjPnlN7eEtfEiMuCyu0A7rDvv2yKP5kmCvtRPrUWO3 6e3g56FLxotZfJ5xknG28VH9duverG6DUB1Ss2vCc7Nmhddb19vXZd2XLZWHR/K1+huM9eba4PAs ISs7Ei43lAXpKUdZtsDrOIsUdBsjhqysrJCQnaUW3G64w77SsTxvWf4Gx5r8xxyP5r+c9XLI2Ia3 uO5378x/Lj9ewLuCTjUYijnVjEAs4MSfgRlbKgYbcrbkkBzV7Y/leAu0ayqgdRsKcHEBLirABZnB YhnLpeDKpjVz6vawriq1LtEbEp7oHV2U5JdB22q7MWkNot3Kpnq4F6V3DsvoviF24nDWoGBtcCJu cs3C810XsQ67COsNZpFcm9FAcr3TWMzW5uobvNhbaxPADoZ//V+409C82EcPln5FrchgVwpmaQdv 2fT5TGcgO/Xs8WrPqg8StxjxoKzarB3GR7LeyPogiw9mGYws60VpOxWVanuZrsIqnHZqtOesnNS2 oB/WPoRTp2lsC27D5zGDsKydrbFaTZsTamKsjkEsnsaeZwkdglOFVztLXSq816XCS11qWXnMRXfb XGpOHkTwXrMroG1ssa5JXhW0t9mLG7xJL0kPXjte0370FnXzYnqfeknqMUWM9HlY+vMO+DWnbj1m J99RJb21ypwLEdDhm0PGCoPdUEGTHQZ6wvb1AX0FSl9da7ryZUjqy/RIdiT9Fc41R2Wu9Efsxdhr XTjztvIcu2N04oWpqz75/JMPchPfWaY1LipWMsL41abGC99+3IeLouMn5WYUKQ67pW7Y5J2bjj24 eeCw4QFnKNORMeeGunU/+20c0f+A80vyEPcErAm/VvMUBO6ILu//a+/aYpu2wvB/bMe5OHGcxI7t NL2vSWmAFuICCa0aBuXSC6UtbelGoK00IcQeNjrEhKZxeRhiAwnGYBvaBEM8dQ+UMlRAQuoDEts0 aZPGJDTtga3s9oAUISYNVJL95yTlMgk0bS97iD995+LYrf3b5/j/z38u3qTcJg967aYGBh/UQPcH VKL7OZUYvNPusrsNKm4v6Kf0cZ0fwmhK53U0uyY0QqvM86DR2TVeS8luyVnvqge0fDaz4XxCqtbg I7q/T2tRT6pnVX5I3aMeVr9RM6oNVEWlA/gE1Qy9fmpWmWgfX4z1xFI2mkLNTVF320ze26bcZVbb bdaujIfeosPt4gWrLU3QRFOZTHWx4MbyVTfGG2t83K4pKRqOthkjb3TsSkjOvXtJSIjczK7fFwuX fF8X725dcIx8ffPbM9kDKJ9DWMv0ChHUDz5K6QO+Lb7jNt4pmmIT1+Rr59p9v3J2ps37BCkILk1F gxSt0oimAa0g5SDTEvKm6zO0BKfjoXrgIBkHcTxdqc9/Yv6mHaTzTTiRCHXcqY98ePza5JWt28Y6 iFne07J6ex0xT/aNbBo7zp3KGjdfWtq14xaZQjUZ71NCPegFvE+JlKQ0W22o3rLTQKSBgwb8xdyN 8xgzBb0ilLROCETkJYfD5ZbQCuH8fMgZclXBPOma5MaynUkFSyssF9gkFUypBuokC5LSfnAWfG0u 4nGzvyU5dUsg4CQiuKh/hbop8r6zlF8ClyC5nE6OIyKmnQnaGpgywrWW5ClnfekFj66HFFeLq4t1 X2pISQKXkIQWoUvghctcAypoe1JedyOQCjqulJjuq/humfTlihmdt9P4pUqb+dkmaJ7ppwrrwUzw EljRjqVpC0l+vA6pDOi06TlQSchkdj2Jfp7URVn5klRmUXoPfrrQGpw3jyvLy1RGy78HZRog1mf+ WhsJ0BrRcHstR9Djtew0EGlgC+I+Lt9NPWmhwSB4JFlUOAiIQoATeJ7Qpo4h/BxcJGdRKF5PvVwL FVqDNqTx1ARk9WXEYpahP1xmadSbneBThmntZl7AaMrJsRxHOJrzkwSkwousQk8D9WqhvMU6H5gY Utnkh0HFYq9u71TuohV/O12flwyZHXHMvIN2mdnoBfmk28cVLK5JLK4TggKXcxmUf+YcrxA27qkw hOG3lOzxtQSUgImB32ix4dtyHjM0nsB8oTtvoDKAYrbLPBr2UdYQK5NY9k9SnT2wvGb5wO513WvN 5xtHNpkoeJm7M8NdSo80V/l+8IwO5uchXvQ4yNtcM8M+7hpDjo/wrfwr/B0hbhNtE7YJcZvdhrju 2Ok48zicwy7NNSFFpbek6+6d7h89NZ4a2SUv8Y4ow8rPvk5/yP9VYEZdpU6qk9oN7UawVw8/DqPa +MRsMSdDV0qaw7Hwp+EZitKFZe6yvWX3yncifq88WBWuOlydZLhXRBFFFFFEEUUUUUQRRRTx38Hs Iq6wYosKPFvfLYQUMRGL8ItrFyysr2vyeaPxvp5VG1YOdHSvW126YmO/XzICjt7B1q417e5FqmJq Jcm5SxqeC4ZrGi37nPltzf9ubbX/1SbACRYKVD6Z5lwOQ0JDOp83hjGgM6oshlpYAAuhHuqgCXzg hSjEoQ96YBVsgJUwAB3QDetgNZTCCtgI/eAHCQwIgAN6YRBaoQvWQDu40SpVQQETNCiBJMyFJWiN 07VAw1ADjWCBHebAfGiDZnYFfrZ8I4BIp7Fdtn3r8MtsVnFymOb/4eZ4MpuBTO6JHYWVfETat6JA LgFPUBiFlfZSGJwlNwbbkMsfMgE7MB7F+CiXyGXx+H7kaWQc2Vngi8iBAnuRy/CcL55G2zUA5HHk MPI9Wz8cE6bhfTEBI3Q//q+DlJj+EPd/LI7BEUx/gL8P0mNZTM/vhzb8fS6mj1LaD4Gd0taP1zkN wadyFNZgvB/jPozXF67XYOlpeDd/r4+IcnkT9x9B9iDfoeRL2fkNeF455g9hWmKQAfLl8BkbfS7c L1vOjZ+9vNnb9IfDzD/I09NNbMXZS99dCNy/P/NAAYeGxzpnn+Nf90iB1wplbmRzdHJlYW0KZW5k b2JqCjEwIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvRU9aU1RGK0FyaWFs L0ZvbnRCQm94Wy00NSAtMjEwIDk3OSA3MjldL0ZsYWdzIDQKL0FzY2VudCA3MjkKL0NhcEhlaWdo dCA3MjkKL0Rlc2NlbnQgLTIxMAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTQ2Ci9NaXNzaW5nV2lk dGggNzUwCi9Gb250RmlsZTIgMjMgMCBSPj4KZW5kb2JqCjIzIDAgb2JqCjw8L0ZpbHRlci9GbGF0 ZURlY29kZQovTGVuZ3RoMSAzNjM3Mi9MZW5ndGggMjI3MjQ+PnN0cmVhbQp4nKR8CXxUxf34zLxz 77ebvXez+zab3ZAsGMhBCETyEAJiBMKdIJFwXyIJAVQUCSqnKGgrnhU8qnggSwgYAv0RlWo9KNaD elRBi2cbpZZSFbL7/87sbghtf/9P/59/XuZ4M/PeHN/7O/MWYYSQCbUgDtWMm1hYhNjfnWcgmjJ7 yczG1P1mN0L4f2avXK5uL3hnJRT8CSGx/7zG+UveuqnuIYQkI9xfP/+6m+al2rs7EZozdMHcmXN+ /0D0HoTugvZo4AIosBXbktDhLXCfu2DJ8htT7bdcCe9fft3S2TNT96vpoJxLZt7YaBhl3AX5nVCg Xj9zydz0+D6AyNW4tHl56v6uw7S+cdncxgmJo99Ae+hfnxQ6kAeCV3gaefgogjkkv4LwNU0TC5Nf 03qakm/h6fZ0QGgX2o0Xot3oCHoZn4Gn9qCDqA39DrnQCPQIugX9Em1AIpoGJZvQBLgEKP8l9iTb UCF6DNbxMXQM2k5Ft6IO5MTu5DdoDVrHvQtPrYOVzkHDUA1aiu7CVydXoOnoJH87KkNXo+tRI25J 1ibvTt6bfBL9Gh3kfpfsRgbkRbPhOpb8Tvgg+SfUD564Dz2ITuJ7dfuRBr20QMtfoWXoIa6ex8n5 yZ9hBCF0A4yBR2PQMdxJYvD2uegr7Ma3cMPhLU8k48mj0MqP6tEC9BDqwKV4FAkJ05NjkseQE/q4 Ed76IGpFB+BqR79BH2GjcCb5ZPIM8qC+aDTMpw39Hndyie61iUpYMQFWKR+VQ81S9D/oNfQ2DuOX yFLBKBQJmrAq+R6yowFoMoz2aXjyS/xPcitca7hX+ZHJK5AZ1uUeutrot+gz7MWFeByeQvLJUvIo twzJ0OMAuOaghbDeD8DbP8UxfIAYyXHuCf45/ryYnTiVNANEouhh9Cv0EjbBTFXcjG/DJ/CfyXAy gzxMPud+yT/DvyPNhFlfi5agu9Bz6J/Yhgfh8fgavADfgjfge/CD+Bh+G39NhpFJZDH5nlvANXG/ 4a+AayLfzN8urBfuFL9O1CaOJv6Q+GeyKLkejQd8WAujvw89CjM7iI6jD+E6iT7HAjZgM1wqDuHJ +Ga4bsV34cfxLvwMboNe3saf42/wD/gf+DxBcInER0IkB64wWUZuIL8kj5DjcL1N/kp+4lxcDhfj SrkKro5bCqPawG2Daz/3Ge/lj/NJWOciYbuwQ9glPCe8LJwRjdJtMpLfuvBEd0H3pwmU2JjYnmhN tCU/Qw6AoRdWIYgqYPQz4VoE8N4OGLcHvYuNsHZeXICH4qthZWbgRbgJ3wgreQd+CP+ajf0FfBhW 6Y/4exizifjZmC8jpeQKMg6ua8lc0kS2kXtJGzlBfuYkzsBZOAdXwI3i6rm53HLuJm47F+fe4j7h PufOcRfgSvJ6Psjn8FE+xo/iZ/Ar+Ef5r/ivhOnCm8IXol5cIq4X28W/SQOloVKNNF6ql7ZKB6T3 5AbAzlfQfvQi6vWHT3FruSpuP7qbFPMe8nvye8DnGWgON4YAppJdeCNZjdtIrnCjOIQMwWPRGT4K a/0q2UHOkSHcGFyNJ6JFZEDqbaKdfxaSCv4V1MUfhrn9Ht58o2jEt5LvRSNqxYiUQ5+/5frzMe5N 9BF3Ekv8Y+hjXo9duIs8zdUAFvyGHyrUohD3CHqBa8Kr0X5SBdzpvLwF8Hgsfhb4wiRchH/kkogj YwGLyrg/o9vRYvIB6gI63ojux3P4+ehuVIxvQV+hp4Aq8oXrxQLRgV8nC/nNJAu3IcI/A7Mrx7mY E+zoDlzPPSR+Tz5EK9BxXo8+5Z6H0R8nL3Bj+DPCBLwAKGA1Wo+akmvRTUIt/w6ejzg8BUX4U8Dd buGK+BCka4CrTAeedgCouwP4wDBuDJS4AXOuBryYDBziIbgeAD7BAwYtBBqfClzs96hNnETa0XzB jIHrIMS/mZiApiWfQg8m56Prk/eifsAPNiRvgTfuQl+grWgXXpe4GTWiAFDOp/hqYSQ5LoxM9iOb yYdkItl+KXxhtSPYjb6F6wW4GSocQpv5P6KJqDK5Jfk+YHcf4LAPolnoKnQaZvkd9HAl14mKE2PJ 3uRIrhHmexKNTz6dDGI9WpC8Do1Dh9GvJQHNlGLa8MmThmmVQy+vGDK4fFBZaUlx0YD+hZf16xsr yO+TF43khnNCajCQ7fd5PW6X02HPslkVi9lkNOh1siQKPEcw6lsVHtmgxqMNcT4avvLKfvQ+PBMK ZvYqaIirUDTy0jZxtYE1Uy9tqUHLef/SUku11HpaYkWtQBX9+qpVYTV+bERYbcfTxtdC/q4R4To1 3sXyY1h+G8ubIB8KwQNqlXvBCDWOG9Sq+MiVCzZXNYyA1+016IeHh8/V9+uL9uoNkDVALu4KN+7F rqGYZYiravBegmQTDCruDY+oinvCI+gI4lykauaceM342qoRvlCorl/fOB4+OzwrjsJXxC0x1gQN Z93ExeFxiXWjLqSzQXeqe/t2bt7SrqBZDTHjnPCcmdNr49zMOtqHNQb9joi7Vp12X7yFl9uG127o XevjNle5F6r0dvPmDWp85/ja3rUhGtfVwTvgWRIZ2bB5JHS9BRaxeqIKvZF1dbVxvA66VOlM6KxS 85sbrqIlDYvUuC58RXjB5kUNABrv5jiacFOo1evVDiZPIW+VunlSbTgUr/SF62aO8O+1o80Tbtrn 0VTPpTX9+u5VrKmF3Wu2pDNGU+/M3J46lmPNaa56Qs/KYjqi8GhAiLg6W4WR1IZhToNoNHcQ2jx7 EDSDvzoMT8XnAEQWxnXDGzYrg2k5fT4uRJSwuvkfCDAg3PXXS0tmpkvEiPIPRLMUT3pQDeoz+Xgs Fi8ooCgiDQeYwhiHsvvSfn1XtpNwuFFRIYHlQzWwtjPrBhfC8odCFMB3tmtoFtzEW8bXpu5VNMvX irTCWF2cNNCazkyNYzKtacnU9DzeEAZMbkNUlXXE5WjPv0VxZlUtGBzHzv9L9dxUffXEcPX4abVq 1eaG9NpWT7rkLlU/qKcunYtnDa/lfCSdIz6O1QJSTu9pTG9qjXE+Av8iQ+o57ZIMWMlKsDoyrjRc mYrr9KHQf/lQe/IMfYolFx9LDzM+OHbp/ZBL7i8ZnnEzBwMGMVg9adrmzfpL6gDVUh2OTieA8WhS bUgdHkeTgTIj8N+e7BxEQ50vrsGSDacNAP9SRenbSxr60vk6+KPY2a/vSGB0mzePDKsjNzdsntme bJkVVpXw5oPkZfLy5saqhgzitCc77vTFR26pg7VagAcDURB0xd4w3jh+r4Y3TpxWe1ABO2DjpNpW gsnwhivq9uZCXe1BFSGNlRJaSgvpjUpvUDWGSbYSmbX3HdQQamG1PCtg97PbMWJlcqYMo9ntJFWm ZMoIlPGpMo2V0T/KY4ZPqu2NPYwk6/pRUQaW09DEWDRcQT/vSUQVVnLJ33RaIm6GqBKtRBL0oYBE ngJS1ZQEfQGRvZMsw3I4F/oeQhICh4IQF0IYB2EGhK0QdkAQkSVdshTCGghHIJxhNRrnar23WGuH 5E6W7Ft0XRG7nZm6nV7PbvdNrUulY8an0hGjU80Gp5oNKEkVX3ZFKs3rm0ptkaIWmupNRZ3DnJwT vQ2BoEaIMTmKLBiDVrGTc6A4BMKJ6RKNs+3LjRbtOMLxCHOEw2AFBJOdHG41WYuG6UmSfI9sKEi+ I12pGtK1z2wt2jHsKvI52gPhCASOfA7XZ+QztIacguVUIK6EsAPCEQjHIXwPQSSn4DoJ16fkU2Qh n6BCCJUQZkDYAeEIhO8hSOQTiBXyJwocFtN8JQRC/gSxQj6GaX0MsYV8BLmPyEcwtHdby8qLDrJM rDCdCUbSGZcvnbE5i9rJO60/5QfbyZ/3qbHgzmH9yXsoDoFAZ+/By99DKoQaCA0QGiGIkDsBuROo BcI2CDshxCGI8MwJeOYEPPMGhLcgnED9IWgQaiDI5O1W6KadHG+NXhEc5gSV+TUwX4PkGPkdS98i r7L0TfJblr4OaQDSN8irrYEgGmaAegTPKJAqkBZCvUBe2pdrCyaHWckRWJ4gxIUQKiGMgzADwlYI IjlCclrnBG3wkkPoDRlBy1b0DUufQo/LSFsU1KLDAcdUGkUHXw45iHaoO6JEi25/EG5pFL37XsjR KHrHFsjRKLpqLeRoFL1uJeRoFJ2zCHI0ik6bATkaRcdNghxE7eTRF3PzgmXjFmN1mIXcAKt0A6zS DbBKNyAeLDK40E88HdvDrQUFsGIPabH8gmBLB245jFsm4JbHcctc3HIrblmLWypwy7W4JYZb/Lgl gFs03HIID4KlaMFa2yW35Zobt7yBW3bjlmbcEsUtEdySi1tUXKa1k1Dr6GKWVLFk3zBKV5BePrTI AmMMwYqGAK1DQPZHID4OIcnuNGik5qQaewI0zdlXUJm6v2xw0dJhV5JX4MFXAAyvoJMQeADQK4BG r8BLXoEXWCCuhDADQieE7yEkIYjQOgcGvpXFFogLIVRCmAFhDYTvIYhsON9DIGhpeoh72MAK04Me R+/IK3BRkzdEQlq24ldiypXcVj+2BPC4QDJAypDTCUzQZpWt7dh04J+mH/9pQrphOnI32YqyARDb 0unW1p+yg+34gdbooeAwB74fBXjAOlyOojgC6SDUzO5LkV+maQnyk+cgLWr1T4HHLK3RvsEObKZP HQj+5D8d/MbfTiD7tf9Q8I9qO49bg+9DyXMHgu/5NwVfL2yXoeRwtB1D0qGypgf9g4K732BN10LF Q63BW2lyILjaPyq42M8q5qYqrm2GO80SnBCdFrwS3jfCPyuoNcM7DwQr/dcGK1KtSukzB4L9YQix VLYABpvvZ52GA+yFk8va8QKtr7RdqpXGgX1cJPWVQlJQypZ8kl22yYpslo2yXpZlUeZlIiPZ3p48 pcWonLGLTNyIPI15llcIjUlKMBEsEzCi4llcNameeAWujnfORtWz1Pi5ieF2rAcdQghfgeO2alQ9 6Yr4oFh1u5ScEC+LVcelmmtq92J8dx2UxslGkJ2Tattxkhat81Ft/SDC2LruLh9N+6y7q64OuZ0r K92VtqHW8pEj/kPUkI5jF//cl+Sz49urJ9bGn82uixfRTDK7rjr+C6rOH8Q/4DNVIw7iv9GkrvYg NxT/UDWBlnNDR9TVVbfjKawdUvHfoB1gzN9YOzmAVNoOqXIg1e6hVLsIPA/tcmkC7XQ6FGHtIjod a8dj2m5vc27ViL25uayNS0XNrE2zS+3d5o0ItIlEWBtnC3qDtXnD2ULbxIeyJn4/NAn4WRPsRX7W xI+9rMmUi00K00029TTZxHri8MU2/lQb06lMG9MpaBP7b//mXhGL4X1D6mZPp6ZQQ7hqLoSG+J0r F7jjLbNUde/surSNFG2YNXsBTWfOjdeF546Izw6PUPcOmf4fqqfT6iHhEXvR9KpJtXuna3NHtA7R hlSFZ46o2zeqpqTskr429fRVUvMfXlZDX1ZC+xpV9h+qy2j1KNpXGe2rjPY1ShvF+kIMx2tq98ro ijrQvFm6jxj0gK8NvlDdFU6lcShD3iEh962+DlBIdiEDGCJGMGpNEGhVv2H9htEqoClaZab2brrK feuQkK8D70pXKVBsDV+BYstXNK9A7qqFI1L/zfAHRctX0AVPxbHm/+0P6qrAdB1BveDV8YKJ1fFK 0DH3ShKUNtApxQdnygyGKtC4U4WXQeFgWshxPQ1pWQUt0+nSDf8d/ivS6XBKBS3k0D6sBfBy1FzH xQPVkwiwgklpw6ID1CUqHprrYILNOIabM+9gw0apPKLzzYTlK9K59DosT6epp+CR5sxy9PzRVaJ8 ijmgBQTCRUIoZA1ZIxABT0MXVK7zgiag80jlOylTuyUxnjQI74IOfbmmz7MAx7NJsqK04+J9aIdZ hlSzSjvM1yJO4VSO4563/mqLO6acq+8+16Wc60KVFZUVA/rjehwl1pKygWXFogSXQ8H45H2/HzPt 8Nqb8i4Px3AsMf4w/hGbv/uo+/zbdZu3H/pNIphQL+l/rmbsQ/ooRKdXMLLp6Aj0OzgMaRso69ea waprUxQyGTI/tlksLHO6zWRimb9qFr2eTLaYg2Zift6WHiNdkn8ZZ1YYWUvyonAVO11Oh0K61+JY LOfyvFVrD08bczwxHp/Cnx0+uH3ztHfOd3/0XeKHhAyjXIa6+MH8AWRAg7Qgul5HfpK56wVJ1F2v 5/U/Cfj6SjIODCmPceo0d2yscrZ+zNmKrgrldEUFKjxb0V1xdkD/iDVUGrIWW0OOkJXgRBPe+ize mmjqwvfuoumuxPXQz7OJT/Ht6BjSo7H79QC858R2XKNFMVdBCNbjCqQHjZ+rQOIgafA4NAMtRWvQ TgD0TsNjD8CMz9afPa1AvxWoksZKl9Ldha228gH9i0uLHXZRyhs4sOzAsZqpReUDuWPHmu6MjvHM vAb6HYbbySKyBPClr+ZpJI0cGYPHQJdhRLxCIzTw8I130Zmdrle+RIVjugb0R02wmKUhxzCSj9v3 76e41AHRBhg9hyKam9DBVqSGuAfxO6F+J89Gea6+HuDRlRpUx7Fjx5hwTX5FygEPODTxIOKSn7ba y0l78lNNtZffz2HC7eD2gLWzEmE7tAYE55Ce+xqRrwE/noHO+X2r4M0VytkuJQXrDcJlsfrVylEK 81jMgYsxfmZbotYj/PVneANBk5Nf8VahE/AuG0/eS6hBqum9AV6wB0wml649+TXDMZrRPBTJdFZk pCXIaTRCbKRlqBAQ7BhEx2A+dEa+veK/v+ksvEmkb/oSsJVlvtM8BoNIX6nQEqQYjTSmZT2vvPjO NlH1KH5AfzDPDf+TPIWcEGwQLKC4zOLFDWSjYaPldbOgkwxuUpV1teMqz3DfpKzpjumeCb7F0mLD 7KzrHIs9Db6byA3iSsMqywbxAWm78rr7I3JCPGH42OLtGW6zTguFS/rrMNIpOqLbFrQ2I2B+mhlK VUQN+m2B1+5MERfQVX1TrCs9TFzfhOrRIPqHIdTVZSm2gcVFTqcNiEwM5+RFsxRncdFAqxIN50ji 5MXv7lzZuvyKRe8+9t5N9xx85pZbnnnm1luuqifvYh5f/vyMfYnkR4lE4pXdD7yIf5W4//szeAFe 9N3C9RRXTgIAzwPs9GiPpnKayVqymF9DtpIHZf55HuuQKBBOJ2AjwW/o2ej1dE4IU34Dyh7jIpD5 VrMygPoZQM0MoLDKmoeCKwMTBh+vUdBMlhIhsxL9BawKmkAEj6EDV+B1KEUaTTFYlzQnhpuKMd1A iJWucmwtp+uD6mOhsFUUpVKgwmJyvm3Yu5Pu/7xwOX/z0FuCL4x6YwadWwXgsgRzC+DX0riksyom d1aWONlEUclqZZnvNJ2iQC5gFwIURV20QSBAawN+M9QEjHTkgXZySDMSvculBhUrIWoQuEHhe8do fAwVdtGRVtL4aBFFXtLTodFmI6xDTWexkkw/pzSDLYtMDthpGX13K7yakorBQCa7KBdmq/ifeqP4 TPujvbHOtIFDhCHiIeGIeEh6TX7dL4021hknmRcb55hX2VZlbbIdtn3h/cJ3xms8Yngxi/jAFMpW Aor4P8kzSALklyHVAbS8Ab0ii+Ibfq/d7/fKfi9wC9nr50wBpZ08uW+cFYOh5N5PZ4DYclgwMeqb Xe/CalNcx4fIWqQiBQ/SjNb9lWQGWUrWEJ50kFwwh7buTSE78JVzMcpegLl0V1R2ddefttooZCHa YL4sZgZWk+K0KEMBg1A9rl9WVxdxhKJlAPGBA0tLAPUZEwa6AHYMglKUeOlCGXFFnnjo+10P3nzb I/hg1o9/ePfclU+//Pj0wO7dwypmd9569It5i3/xyOas4x9+u7v22cNPbpw5ADBlSvJL3gmYEsN1 acAZPG6Nrr/bjzBF1ZgRbnB+WG+yGC0BvT7fEfDzgXy/kG8Km4xuD4hZVaHIr0pRCkXaPFpIuc+x QnohW3llJQiRLoBf16vKq7Zy5WisiAYKvz6CyWmqMq038VXWqdaVPm6C8zplkX2Oc4XpJvt602b7 Jt+vTXpB5RjeGIwmMy9h6BdTsFB34SFMt8hNuLTNaHTw7g7yJPKQBVoejFKAYZpszTPUpSpR3RST 1RapOcp4UxSjqBIlMOKzL9Ka6LZ+7nY8qNXzLu4AsxbBxA0XuVXfdnzv3gzDYlCkPOtsrD7Ft7pP U+QEOUnhmQInkCoAEKgVN9VllTkpz2KAk8p6shkYUiBKNEbhnOiUtuB9i9fseXx18dV2m6G5ff2i hVvsbaFvX7jxjcXz5ty2LfH1iZeS+Hb3gxvit93ymP1RcuPq2bfdcYe6/7X5rXNmPHJZ4Dd3dyb+ 8SUM2gs8QBE6gL+ZcFQbaKs1LjA+ZHzG+LpRuJq72vRLnrMBjiOjyEmC3sBJyAjE/gbH2zmO50yI GE28xB0ih5AMquBOTY94HpqgN/R8O5n3oiDotexgiT7DCfUpwcQy3zEJpW/HZZpJ0nLCJVJLqFTa ZiEUnQwmewkiClEJR+jD9BnInD5AnyH7ze14C1vpvwL3Y4zwLGUvFcqXCuODytmKcxXWcrrI5eUb LovxQDIWiwWWm2nPJpD5tnJgOe9phuJyLqdfOcdnZ1fQV9QBMKCNZjdqhnJjS025UYuWG3P8kPYr Z9y2DtTbUlxsLXaErZwVk+3dd5Bf/eLVV9sSpXjGr7kDF676deIxIOr7uhcD4lHZHxKeAh47JUU5 YHXD/Ex0Qthv1gccDr+NsgqDhecDfpMZI8kN8oJpBCzDqIzyNEolFI8AibqPAmVQwsi3Md5rYXG1 96bszdnbs57OesV4wvixT9Zluc0FXk7XX+hv6AA+xgF1KFl6hy0r6w2zxW7OspstJiARLYsORDPv BIXWbNEcOD2oFy08fpeSD3A1TaXDs85QliprlK0KrwCRuBmRuDFyK27izhCJe5tqO4xLkQXfB0g1 qNW8/z8RS/BSYrlILvVUowQaYROtt0IAtnB6g3xZTAAoIsb4GM/DTaBtXUI2QCtZoPNyQC/IYZdA E4hO/o3jwetua9u9ZeqWPs/cTT7sfnHcHfd0Ynn5XWd/141blM13Hn38odZxlU7yt+cTK6cnzv3h tXtaT1GtbQxAzgE8LxsV4HFprhe04CCegTns6xPQTNhkAlHlE3ICdpM+gFFEoUKMaXBKwKVQCLoY z3MxDc6VVreOvXdM+W0GkvVdytF6Csl+iz14hKQ5RnhGqNNsk9TF3BxpjrzINkddLq/wr5PX+0/I 7zmtkkqXOC9FE+LkMGN4NBdiFRKtyFPDaohWWOkoa0wExunD786ggASmp8uMGfTZQZoN7Y80KwyQ YAspQKUwizMvUo1E2dZXTyEXwOWas9I1w7XUtcbFu5y0zuWk3bnaSe6+WEpJA0rs6gFimuMxTgdz TEOMkg/ldnVYAquIqmaiRJmbjQqocA6yKmWU1WF7L5By5/e5+45ePGXY5Flk2OH5bd03vH3HZ4nT v9r09e5PusvG3T122ZOP37zqWX6ieVH/Mf2Hfven2Q2Jf76zuetWXI1vwc+8tOvlC5/UP1vX/ugD e/bAAswEfucUnkYm1KiZj5owD/9E5nXAyygV9ieY1xlNzRxH6JKMYyKaI16L3Kz7CxoHsJ9BuEpI luI1oDx6zGkspnZYU8WYs11jlXNUG6OWAZXe5dbylKgGZKUWjIg4UQoPtNnKZnL7tyS6qgdaDnK3 /X0T//PuLfclbInz7R/vxt/i1x6h9vREwEAPYKALhVF/glI42GZEvsBllEeCHkYmX3aZLRQQhT4B mymgM1Jko1bAAWZFxCzUjqVoaMkoTjTDKi1uLmPkcplWXA/6crkOI23uYG90MPR1XLQWLjVFqMbV VV7eY5G8yAYiZgYipgZymlkmlgwPT/dPyyBzQcuhhbRb+qSDsTMHm+nF+WU6g75wYXoAmUApqKzU ifOdo52jo18av+kv6Prj1Wg1voVfLjcZlhlXmFa57kSb8RZ+vbzWcIdxveku11vWV7NsOUAprX7V SxNVLaRJPzVKySeQrxpRwI2MMIydl+FeK918RId17WS+psSaLZoKtGPByKJYiKUd33OgyN0cB9MZ 6ltzmx09Jo1DcxDHtgE9Js1ZoP2zKZbXlZ5bPZscFVppimF8rn5ZE2qqq8PRaGlJWp3LaAIISrLs vailN+ngRY3XfXmk89vFSzbclTj34YeJc/fMWr94wbpN8+ZvHDx628S1u3bftuZpzpf/wKKdH53c Oe/+/L5HNx5OIow7t76EJy244/YZszfccSE5Ztu4p1pue3ZXxpalOBkArvhCGt6GIIiAiBUEwDkG UCoJGHdyUxOnD4Wo28pAamWWjtVt7Rsz9AlQD8o4M2c221ENxkyNNClgVWAqaXKoEk1X5Wisvogx kSK2MABtin4K5aKf/LbHkug1iIuyUytgwtPKsPh/6fXSvv6lq8LeHWklg71XO7XwNc6p4Xncdc4l 3vnhVd7VgS3eOwMPOZ/xHvZ+6/xSPadmXe581LnbyQ3OnyOSPCp3w4BM7pAqqn0C48wzqJD10y7x uzUpltxGBxHswOXIABzZeqlY3daX8uk2yqatPbhk1azEui32Wm9tk6JSV2/ZmWG7qL4J19elJeVQ UlqSR7ktpAiQyWZlJnMUM5RxMFxq3O28ZebE1TUD8cBDSw5cwNKrW7tuXvW3x5//iLz56+U3tj5z y+rH8ERl1fVXr/mg0eieshjLH5zEykOJPyd+SHyV2PfCEa7k4QNHH9kCLBdw5iCYP+v5KPMQDgI9 QkCipCNiBc9VYJHXkwrQaxChFvNjctq31ET5J1gDDA6MHLJKix0chIPHjh3j6o4du/D0sWPwbubF Yu82o3VaYbPhdsMvDE8YzhgEWMuovkw/Uj9FP1e/X/+5XjLozRLtU6oQRcHMG57TU49XWKjg2TDW IiSIUgWvH2QYLBTylTxRecw/ZskMqeLsadAuqauLapjd3V1Kyu/FBomU1ymTR8uaMgPtcYEdSzvB MqPOuMLo5lxivPS+8D4ahaaif2pT+ZCiOkOhSKmp2FxlHu0eERqZO3L0qCmTzKvyzc5IPo7qCrKj +aXegeXDI1PcddnXhKbkTxldN2Wue25kXv5K76rsZbnr3Hd4t2TfGdoQ9ZiVGjPiJlLBprfk9TfU GIhBch4iV6LhqJocahs+mNMHqZ43GKuxxhiJdeAxKI8cOlB4Za5FwlI7uV2zKDVDUa5tpyW3v9II ykEHfgb5yKNtlYMKcqG9DoXJo5pOLcWlntqpW9Ieya5uqtLVd53thiUD7lbY1VUP9HUaFquy/jQg Z1oqUrM1QpGRsjbmwnGVFXMpLCwbaCstIbnhHJ447Da+WM0tKxZFPpyTm5sHrctsKFTEU7cq0/Py otiexm7AYzPhNw17bHzdroVP/LBs6qPlOfu2BfKzS6csW/dcYvexbxOr338f/+IfWMSzavcX/5h4 9m+fJjYlfhw+ac4q/BLWfsR3Lpv51oEPqibbTQnnbZMG3dJ05YaZWtMi7YnqaxZ8sHYHrtx5Tf3D 3TO3WHx5l9dg09ancc4LHyfmf/uPxKPPxG9d+NGaZV/c95uPz36CLVh98/XdbyY+/eyNgjwPvnrT A8PveHPexu3Dtv0e4J/sBpSrA+tLQmY8/wA2WxRm5vzQls78yNgooXK5jolUJh4FFhcq/ZX58gJd g7KR26a8LrwqdipnFIMs1OEppEZZYIgrfzf+3fR3s4438ibezBn0OoHnwTaWRUkyQl4WjRJGCLrR LMwvpUpGO1QRjqNlDlrGqbzRDk/pAoIgB0RObCeNmg7Jxm80ggnpwAYQFwbNZlTRXImbUMMf50/y 3DYgnHaMNUONsVM6aeS2GbGR3isW6bhE1kgtEpF+YTnxxxRheSDAvxuww+tRgIe5Kyu8gC0V1L/c Rb2rMdD8N1zmZiljCWDbbVCOHjUfPbpBSKVAfdVxw8TqeGD8tNo23sLJUkfyDFgdP1IWWIeXNdWn vGVhXIzDXIjLCnHRPFHiSPEfSO0nz3U//NiH+G8PjszxFwsdP4/EhxMjyDS8/eANd91JdbHtoDd+ A5CyMnsg6yDiASajqBeV50eGp4TnhZt1d+jEhd4VQqMOuJBwu0HMc+o4d15BwJmt02XZAgUF+fnI nx2AdQsGAlYku6OikSpgIljFWjEVWqKNCixRpCsvyvTtIoO1aKd4IE6KRI1++oRRT9sZKV44aCuj t292QGVORzXtcTzHpCDLpL2NP7cxIKcyYsr/qGc+x/rYkOnuHn9iPeitY9nNmK6zaRdj2hcFAQRL BbDB8kJrOfVipJwY1N9YbA318lKYSRiHilKOqGgYTOaiMkabkN9OorvebJ43f93WqS0vbUn8Al++ dtBV1SNvezTxMV5ybXT4tMGT7tuS2C101B2ce+1TxXmHW+bvbRjATbA6540ZvTT//E7JOGjxyAk3 DaA+zHnJr4SVwrsAlXf3zyaLsglOqbpsfl9rM2hORUWm2agRLc9uQXdkb0MPCc9xvzYd5NpMr5ne Rqez/55tNduyrdnZXIHYx1rgV4OjTFPsUx1TPAuExdk32+60PcQ9aH7Ivws/SXZZ3zdnITvyKnbF y9Ntg9Y+5Ux16denXLEgzPuyAkbOF+B1StRyFYqqoGN4g66oKmPZSEcjewKzpzM+GQNGCQsNcdpe srLFBAhQ/zaYSsuwizE8WDhbbjFwOylKhTTlh1RM820vX5545YuuxB8f3oOHv/wn3HfIkeKXf/HM n6cv+XL9E58TMuD78y/h69/5Ak/ee+rNfjvvfTzx/T2HEt9sPkxlz6PAe6YBRltg7b7QCtUgHi6n sNOqBCxIhiHrcJA5+XQMqXR6tkvhZiUM9RhL8gazlf8a9f6ZQb0fM6gX+FfUS+frL6LcgP7Db9IG cj5JFmVB5mVe9Li9biIa9EAHehAXTrszy8mJPs4VwjYzRG7ZH8JOvTWEYBVjsQL4W4vrKYa6nC4n mJsE8DMSKkp7SsEWDT2Kf3pu2q11y5vHrrrn2LrEXlx+z68HVI25/7qxuxNvCR2O7KtnJY4ffTqR eGZm0e6BA6q+eerLfxYEYNaPA2eg3zIZ0H2aQxQCsixJiOPpQup1AQOSJYod2YqtRJrEXaXqVRPR e0287v+DXI1DrkkhUHrRxjCCrR9z9nTsX+l0QP/UNmAqPM7nXniUi114n7tD6NidqHw+YdpNqQhU e34dzEGH7tJibA5bQfxnpgFTeEQlqoEQr+G/GLdmSO1apYkw8W/D1w+Z3mv4vcZ/OmU0U931X8e+ i/vkwhck3l1Dxz14d/c8GMMSoP2DQPsRnKV5fXafgzTk4WvlLGzjcnNRyOYiERQgjDhVOgaMRVfA zIEVp8M4mhfJVTkO5pXXwJyMp9lMmPRNexs/YhBg0tdHnyfLWvJwXnZU1WM9M2T0nujsa3pIeYxS fy49Hxg8dXz0mMcV7D7l9S2nig8g9Ag+7PN7/R4/JxqjSsQRDUblCB8NR9ym7BByWrJC0NiepUpw lyNEQthvAMy2WyEK6EIhlMtBxPbyAcOpKtqzM09xHTSr0oj1Eu7hdEmXEWAfdM+cKlSA/VbuarJk a+LtnR8kdrTtwzUf78D43uie0KwDS9e9fENo0AZM7rn1zFBS+TzuPrWs+SC+9oMTuLltfvsv+ze2 jBl/x7iNO44mfmyZWYatAI8ngaPkMEr4gPpYOzVvlqOE5wI6/U7923qiFwgxyEDBqiSJ1P/LJB6s N3VgQY65ykRqeLuZ5MNM8tW3mLCJGNT0jlqnpoeX/hfoJ6fRrxfHcaapRzVh1VRjajA1mvghde5Y fVPPVlqKA6XgGKtgzmSgJrDLGRvCIOQAJSGEIX7yZfLzyy93i0JH91Nk2s8jyb7uMTDGI0BQa2EV OPTWfko7hG7l7Rt0OdvS21dckkr79U+lffJTaTiSSrMDqdTtTW0BFpiUElXYJuwRAFdBWduKdqI4 4guRhmrQSXQGCTYVCrchTkj5zekquNOr89fM6nyXWZ1zmpLS9NjqPM6fqOvFfIdPr21tAXWuvq5p WUV3fWZJqEOdkmKx9cjLVDWCOZYlv+JmMm3oGU2ZS+aLy8kKcaNpo1XUMXprM1Bya8dezcAHLDpd VK+XowZqmtORGTJubUOKO7BMSmjTEo05GA31ahZWs7SsmqyGLD4LRxHbNkqxxG8zQP1TmqdU2w5k ZtKl1DelZtTFTLWurlgltTTSjuKBpTAR5m6MDtkjNc4evajPy3Uv3fbSMbzTveuW4c23cj9c8LS/ sehTyhdB6xMmUIzGCS3A5ZSVy7rBefpScaB+lH4qt577Iyet1H/IfQhCiHIJJhr7CFv4zcKz/Ley oOdxKX+CJzqK1DpbqIRTaQRKwz5juY2W7oN7OZ3yNM1maec+m5OWf6pd7oE+I5HLZZ3HczmQrk6v k/UCx/OqoLcLAtwBOYmgtYt6PRIIj4lkkJGs54gBI76dDNYs/QW8U4gLncIpgReukmmZob+EVdDC 4xIHRt56zWhQ/1+F0Q8XhdEuqsancairG2x3ar9TjlRByaeiggbgglSRp3uXkLrZjowkKxVyBajt blDbfaC2U636g0F1KbcSvTmzz2il63VGc0FGVMzWElkxKyU6mtMrQBvpw0x1TG9if3T3xqrLgXXr 6ynnacjxlQNxfHrACVlnuUiX1WArl3Ps5bxmL6fLvD8CWUd5r9NNdfTFuGlZfQxRw4FiPw5h+Jes 218mH2Cp+0FyWxJ1nzsD5J9P/tj9woUHyJffJvgU1vAFgDUCWqIZMQEOKCCZ+hLaydOaRSLcfy36 z/2buiT+m7r0ZX1K5qdINOSA4b0DZPr33dDFAwiJFhiJQk5ndp9k4AGMQ8pmk5VJN2AOkBHoRn8f mjPaaLVgMXI6hImsM5iRrCN6g8hoV0kT7s8HGOEqiG7ppWfyY2YmF9ouObJCHcWVnZ3K22930l3P WCwFLZQ5whKUGD8SWcyxmGexwGKZYluY5ghTKkBgUmlsvmgR61ksZQxmmS5YkG3YCtio6m0lFhYJ Rg5hM6hkMuhmdOL0bSzDXnKITEE2WKspmimtvYiZ5WevRdTtHDtbCLjOxEJFajL1F3EvfbbOp61B xCLbiU/mVxrXG38HS2kcbRxt4fL5iKmvuZa7hl9putG8wSQbiCCXmwaax5FqboSkyWNMV5j1D5AH ue3SdnkX97Qk2ojFbO4vEKB2IhtNpv6CDFnZOMEyAWtggsuyTm8Avm82KxRODbYWG7F1kF3IhAe0 CqrcjgdoeqNOr2rGNQZs6IBJmrEBakg7GO46CyCipVHBSjuZ8qIqNAgtAogSsmuflYpGDz3nVV/h BjxjtjnkvT03p+vBUodlUHpdXrDfKaFvWM0MdkiA9140zH+DjMnzgIMnEEmeYHZ5ddwIdX0Y9ZuS P+4162lpepv2vQOhcnPfENuqPVBWbi4qY9n9/aA0vR0bqwPLHmiUejgB/bHTNbAMh0BA4zC2PoBz 8TX9nZ5SPAMLhxJT9iRqhY7zP9xzZc3D3IWfR/Jvni/lT52nxPgIcPog1YDx6r02Q0bPkN1GJ9sX +VoL0ZxMQApLMrBbmUgcJ+t4QnSSzHOqKAoZeSv0qDRCipJACdG8DJ3rVQNWDTWGBkOjocUgGGTQ pplSY4LO/ju1mv93vaZHre4lzGP1MabJNJ29RJNhnrfy8g08g1CG0XLJUy8Cf5VViBBjplSpBBi0 ydrIcph+54GR5bJWlMoWlUvAXanpe8AD2aJUlpaGU+foDOFyyWyHkEXvzx7Igmx2KpsNWQfN/ri3 h93iXqQDICzGVL/C1kde40jHaxcSALC1/BoAVsv5lrTdyncDpEzIjVq1vnOti+2kWqm2X6NcY+cN xgBQC3K5U3aLLSozT4mspPlIWpOXvaoXw7/Xbfp/NWf+3Rrz9GbJae9JU33Kf9Jj0KT0R1DLmREa ABOehEJWyPfYnyT/3jHX3Vv3XeL1xEZ88+FH668ecEdik9Bhts09sORQorv7eQ5vWTP9doeJrkJt 8m7hO+E9+sU1XqDdNyO6I0o87jIHMfj5ILUs7EF7WCwQ+rli0SFChWtw9GrhatfoaL0wOVwbXSrc zK0StnBbhPvQQ9yT6DnuffS+8wv0hesLt9cvxFCBMETg64V73duj70f5iLMgWuIsj452j/ZXBavC 1dEpcq11smOaf1r2lOBUdWrOQmGeY3H05ujd/rujH7v/FPUY3NgBlNrqK0f0mMUgXznvtrsLhMEC TzhnH07qE3U7BSSGuCyvQOgNEnIDAQtH5NyApPNGs9wUElkZ3TUro/1l0W1DCouszC4TzWgRCpWs q4hXLWgpIAWhKFCagdkRBsbEDZ78jNcl5XapPzfmbI9vq6uSOV/S9pmrHFmLldeV1+vT3hi0jPKX pmURMKGieWIvm4q6EqB0oLWERNkGNiouKovm8f/YsKz80V898dvXEof3xHHV62/ikc9d3/3lriXP 3fTNPR8mPse+Py2Yfs3cX9XHNpTffE0nnv7Rh3hOx0uJX3+0P3HyrsL6R3B5K9b/IvHHBDRO/D5v iAdg/hjwqN2A+W6Ugy9oIZvBjG0D/dOC8+QlQV7Hjg/KLJZYnEsVcbpk7DAfzRgzGUMmY2tPfr7P 5i2B9My+nLwSK73PzitR0qklnUL9B/uyo6l6aK+kU1qvjYZMxHyV/yp1omG6f4l/me5G802WdfqN lvtNz1jaLV+bv7IoIK1Vq8VutVqsFqPO5iMhr1Mv2uj5P8Gt0zldXk/ARVkhO67qcqFQDqNhN+CB WQ5EzY+ImYOyYoY8mbGYw8xGkTlI69XcxtyWXC43x/3f0rX4v/LTMFVs/8VNkTYNPafd1D1FBV6a vmN0Z6i8kJ3TSx3TE3pOBPf6Q2k7S9PLmqXcogy22gZTtoebmMQzA/f0esqtwF9tEMyav1wBNVXJ CULoYZh1vVytLqcrK8xdRoCFhBk7YXu/ocfI5qNvrXrj3TF9Jl+dPPvy5Oun9gtVf4YfW7d97P1P JPoLHeN+d9MjJ7IjuWNXJJrwgDu2DDJI3Su44rKbRi1g516nJ7/i/yK8i/oTh5Y3m5vNN3PLeT6S V8qV+4dzo6Wrs6uCI3JH5k3k6qTp2VP7bMoyh6nrhK53biYTyWSimUxeJhNmoEg1TmUimUw0k8mj 9upImutjiuaSXC4vMtBSEh4RqSqcpk4JT45cZ1hkWmyeZ5/rvsmwyrTKslpZkdscWc9tNmwybbbc pazLvT1yr2m7ZbsjkNY0+4WiNl/Uq4vmg0GJ8r02vmhAFM0F4jL1u8m3yUd8EaepXyAvgiOCU6CM JbXjEuinCwScHHPoxIBH1KfcOTSpZyf5CrtSl0/rF8k1mwxCyJ8d8MmSyHNExJHcHCgThYCvn1ej aLcVZE+XE/VjzimmJShYxTW4ATfibVgE0zmuZfWjXdKuYcRX6aIoH+dT09dsJpPz6dBM9Ll8bxHM CUdtVP2gVbYMktt6NnZskygteAaknVX1Y04zO7mLefkvup8VsPnpfl3sLJ0RoDHdaaEe/jpqPzdd xGLghVllAVJclPae5uaxownsmGLaR+2wu5y8iyEp5ZfR6S+aZvxu9dJnJ9ZMH5K4bvzC+bf+8Msn flovdFh2PxN/rHwQ/rC2ZdX68796LfH3B/EflevvmnpF84iq+WHXzFjZE3OXvjRn4VtrzXfevfaa ccXFi/sM2b9yxfHm5d9QTO0P+kAH20PbpJkEEoAFR+znQHTtpHmfmtqJelFUMSmkhzIw3o/TvqSv NQNjD3KaN/yQMbs+zzCJCxmmkEgZAPSN8oEHe1tgsJygXZ2u/1Jh30Kk/NX0iCD7+CIrkc1vTvgE 0+7dP/+djvax5FfMR2ZHH2r6qKWWr5Vfl3knRQMn6IAl/BB5JH+VvNLylPC1RTIiYm0nh9pEnT1K Mvol6dEviZJ2UJ7S/Mw8qledWHXWOEmDs9HZ4uScJuaszKizejV9CDPFDvUZTNH3sEM9nzaJUuxQ 38MO9fUOql5eZIdg6o9R6tOuljEMgZiGE0P1uNhqJynPI/W1MLeLlW94eU7i/Hu/T/zc+PKo3atP HBA6Luz9JHHhibux6Rtu3IXWI/tnvcy+uEA6kHMj6ZlUPDR97s4mYCQzjU6PBJ0sYCIUfnJM+eSY tbgY1rySbSb7tNxCARegPlxEX2jsb2wwbpI36bYZO41njAbVWGMkPDHIJH1oRYeNYAjCKysr2Y4i PK3X6VRZsMuygABFiGAnRNBBV9+oerCs5sp4LpGZk61PeY2MW+RtMtxjrJmI1qd8BsFbyQ5CCC2x qkKNQPqDNbVN6BTOCAJYVBv3GRp2pSyqJnp+nwa3kvqGxOvpcqe+I0lvdNJ9zpTVZAfLqBVZABJ/ a9XZME3AsAS1KHU4iBpQfaDZQGZAIfazDuwDCXrMLoSLU/ZQMSbDun/3Dl59WTCnH97yavfLoFX/ saXxxhv5/J9H0jX3ICStpLoF/liL5qOoNd8WdZejgdZy20D3aDTKOto2yl2LplprbVPdygPyA5b0 QmrFCvZ6Yo4SocQ4QhhhrHZMEiYZr3HMEeYYFzuWC8uNNzssgoNa3jYZSI0wOFZWMqi5GPekix/g eLBvRQkWXw+YqDOZLRajPctmczhdbjeokhX7BORWaWq0WWmqTXOA+YQEQsCGsmOM3IIsBxxuu8Ph thl1uoDDBlmb1WixqIrVrihWm84oux2CxaoAXcGQBM6tWCw6nSwTGJPbZrNakex1ubzKMB0ej1Rk hNgBQUMCHn9ApVt5Hk87vnNvSjGo93rGdIM53O31dLvHVs0d8WWPTpAxh6k+QLerMwFMrzG9jeNL E6CkDWbl6FGIKo5mcr0jALYFgG2lOGHT0wNXKQyIQGHBRQxIG9xmKNln1ARtUAopltUDQmSlECLL BklWMRjJdBMc40cTN792Mtc7SI9d374zLuzv9+UriesPJd7Mk1z2xOtAq5X33/eXXO7Tbm/ir3+/ s417AQyy+i3q3FHnnwDheVXya97PD0V9UBnpp/XVmXQFHpO3IN9UUFBuGugo8w0uGF1Qb6ovWGRa WNDQf7Npff5Dzoe9z5gcfTKe3zz29RPNPeV5ts8Bz6E+Rz3H+7zj+KSPPMKJA1TeWSlLstkuHoEo pZxvMs0FXUF3rG9BSTlf3nc0f2XfKXJdbJ68MLbSuMH4uvEn008xa1mJGfNKYW6Jqyhkd8/IX5pP 8v2F5krzVvMOc9Is7DDvMX9v5szG9Pd+32a+ADyrOej3L2Z2gs0s0hNuZrOfc7WTZw+477P7/RKi jbxMVFTl6Yv8nCF/pjITiUyKREK5lHOnFaO/pjh3Lk+5bS7ddaLnLHOpPk7nnktd2gbaXS7rKDcj g3LbyTWaOU+j3yOo0f7RPVGhnOr3VOKDwnTiAMsMKGfOhEC4pH95ZznZWY7LXXRsw+gbXRF3TmHu EfG4SIJipUhEM1Om2eFO0c20aHboU2SmrmhmGjXb5xIHDOr1sRGoCzEFmBc78dsjDiq6Y198QaXA 6VjmU4dM+6aUspT55AExlZid3kZNqdM/VHkoY1dpSV7qIPdQwrQJp8Nhd7rCUU6UzCR1Og0acRVz Di7ac3hU85Wliz+aj4urNq65KTvuvv7tTRufrVF0rpzDfteso0unFy1ZuODxaPbtk0c+t27s2rF2 s8mbG9Ff3+/yuiZ3053V2syrLrvxzPl1lw/Cn/TxK33GFF7ZcM24y28AfliT/JrrAoz24mlpGVRi XmPBFgOmGy+NiEO8zW+Q3H7egM0OSabLL7GllNhpQ0mhSymxNTj23qsp/epofRENVFSN0hlx0D88 a7hrYtZEV0NWg+th8jD3kOlJ5UmvUTZ59IvIQm6RsMLYaGoxPWXcrzug3280Oo3rjX8mnDlnhmWp ZY2Fs2BAQu2m/mw3qAGGtQ3tRKfQGRChFosBXRyjH4aea5YZBuf4YH65hlgQeCamh3QA2lijGIKv ZNukXtoMj/Y7co9LOChVSkQy00aSnjaSGAFKA3wlR9N6EPX2p3Y+l6V/aId95DCormvZ2VjXsswu qLW8UKk/Df9MmwQRVYddqWPf6aNfGc2RApmr2Jv9/QsfJf657JtNu/8U3ONZM23js0/esehuvM71 4nGcjfXPY7J2z2O+xde98u6Jl2+jPpGRALOTqTM6eLL2pJ7wpoipxDTCJJTaS/1TyST9BPtE/3wy R5irm21v8HcG3xPez/rE80XWF/bvXX/xfJF9KpgMOoPBmLfCWeGt9jYGtwWly0iu6TLnYFJqqiZV ppH20f6p+imm+aYvxK+cP+OzZgU7OLNBsSAfrLUV6R1A/u5iehbVElGUt61YsWrWBmuLlQ9qFCdS RyqsNsoQrIytUTK0ihSDrGwHycoUPLriVjNdcWvGQ22l6tgV7CDtclvuEem4dFJKSjwF0TiJkwIM 5RglS4EUKjKwMcYlMf4keQIlNb3PDjSN6eq+qNjXN7EPeStOM3WOBnbKhx3Uo17WUOklZ/Xopkjv w8eD5h5d8/6KRe/d3rC9cF+3+vyKlb/edfONj61/dMv5J3ZgbvP4YcT880hie+uNl1796K2jFGbV IDkCQGcOgNlEzRVEfgeZzNUL9brJhrncYmGpbq5BdqS+vmYLcFqbQHPZfvYdhO1D4Wf7OS8/wDbY M8A/zDbGO8w/3jbdM8E/07bEO9N/o3ij4xw551aQE1tMLleNk2rGnNNv2absVIii8D6/XkId5FmK sYxJM5NMoeuuAHXclwXU49JMwJeZqmzKfLhkyuxCmmh7XV5BSdyETd4g3byLREtoqg2jjDiIg85i JVfScgtKMpBSe0HKzyCVIjA/gxHbp6aQKusNqdiY7tNjFbDCzjX1qNx0kzZ92Leiu6kifVo2fSCL 7V9lSIw6ppDVLoWYNo5D7PsLkbu2o+93B79JfI/tf3ofm/GFr/Wt62Zv6f6IjDcOmrLplmfwFNcT bTiIOWzEfRKfJn5S1D0dC/B964cveAq4SBaAsEV4F7mwSQvYddjiKfT092ieRs/DxkdMz5hkr6mP Ke7p9PAeuh59vMGSbNnEGS1+PXaQmD2L50Sk32HH9mSWxrsiPOLIvZi5xPcNGFTCXOMxf7BkG8Ie jZKJRzMBmSA7s9v6MLsthxIO6pu22H5Iu3XsabcOleIs8yU7mk4dP+zbFvSE23MYd6AQOof1yB2L nYv1IgPqMT8L6hto51311KirYF9illtTRzfsilXUSaIMMlTR2XzIKlp8OIZjBWvX4hjQybJia7i0 uLSkjJrEwNYoV3PQ78Vad+zI8t6+8urpvkFFE0YcP849tKVpccnIqbZf6Uc2zNpyYR5QxBWJ8dy3 QBH0hP1SrcFgEOx9DRH71YYqu6jL9mT3NUTtfcPlhoH2qwwj7VOkWsMCw8/6fzjMl4X75g0ND827 Om9b3519pYGhgfmVfUcaRoaq8ieFJuUvlGaHZuc39G3p+1He16Hvwt/nWV1O0dFO9rb18WdJTJIo KpjTVI60oE70NpjU7WS1ViT4/RZ9VY7fqHc6iiPF+ojb/bYLKy7N1eBqcfF9YcnJ5L6MrbkYW3P1 sDUXY2v0YyFW+m2KrdFW9OOhNFtz0Q9ArmLfEy234AjKCeYesRy3nLQkLXzQUmkZB4KOUYzFS2Fr yWEfsDCLN/Xhm4XxNosn1nd5iLK32Nhe7O0sMLRLOVz36XP0G7PT6aPyp1OGaxMIJRc9HsZUjLzU CXnK51ylmQMDvb+0mLfHUDR8+eqNbjNeGf/4zPV/uOvwqqfmfrzzf7598KnVt+zaverGXbXe8ZGi OdPK4nfiik8ewHjLAy0XFv14/MbnuII/dB5565VXX6GW1waEOHp+zI5nHkROQHyHq4R9x8oUsAhf ylVxHSaeFQ12eUpcstVotXNgEVv8gmQ36I0RnVY8sCSpw5067GQyxqmxA3t9WGynINBR1dPKju4x 1VPnpe101MPGQKKzU5DoqIBhn5PRw37s/twBts06lrkoXCUDS+LOM07S6NzpjDuTTt5J7JHUFpYC YzhDf11BBcw5hXi2V5J2v/6suRiV8pmjOb02sn7WnIwyCSNLwvwsYx2janrtqbAv3NluVuxsrDed sp8EoHLKSj+0Sh+sMotmKWIWjT5skoEuEd1gWouAqFPHd1If01rDVgZG0WHd0HZr58oXqttWLK65 q0Lo6P7h3vonH+meQR7bcPPEu1d3HwKa3AiAqmBneiR0TLtWN5DOYJxum26nLq7r1J3UndFJSBfU NepadDvSRad0SZ0+qAMdS+IJpxO5WzESBZHXi1JEQPwOficf5zv5U7zYyZ/hCeJV/m2443m63UzX je9ZN56tG6+nvfKMs/EZzsZnfFM8JSI9XUN+rPyvq7esgn0WCyuFM6YoRfllTTH2tQKsysa2tjb+ L8ePn3fw0fMf0bPpjyfG48Fszjb0vlbFCxFhCF8srBcElywIEs8TXshC2GQgnN3IWwWDRGdoECW/ 1bINODrY0UajKaLXbzPgoKHSMM7A0WMDWhmdUfoYAfNfGZjVYQiwzRojnZRBZls2jLYNniz77tCo 3lTNqJiesRurUKO7CVWOYRs4tvQGTsrULi7eoMips6NmWbFEZUXvwzqz5EMpjKA/KVLswKkvramf in5HsL4tsSBnYLBsYFvxsPtH89/84Q8/3fygefS9/PTzO4+OmUPpFXCB+5GeCSIzNZ+Y0q3EKeI0 HWcx/V04J3K6zKHu1BaLPpPRZTJsP5lt0UzmbtATm6hmsVNAZ/bZ8kp0dH8LUpvACkKsQLsDSkSe F3ixTDcKQCH209fqb+BW6D/i/ixKT4k4LEaliFwuDtJVmsaZ6vg6sVaq063mbxIe1L0qvsOfEE+L 30j/FH+SHTa9XuA4ntDTRDoZbnSyHEmdIeJ4PpI6V6QHhOWpe4wXqFPGYEB6vh1bNJ3AM/s7R6Z3 IZVZB8xIlLzbQAEyRBCJYAwCuxKNA8qh57kGMNpnEEep42cMk5GNcQBmTiBmmiCP0fRZaNS83rBm oGa+6qZzzFcdu7jzAuqpq5x6zfjMsSJ6vkgCsMsVHIvTPipTtQ4HdXdwROc20S1usD1S34Jrel3f 7HKdnJ1dQc8FtWbT40Hvtaos2RtKf/HNzhc0ofRvL4nJztYQ2wpvddLk01aFHSqChN0ZWbLXkDmf QPe3aVe2T3gs253Qm91ewSK6kdXqpg//da+vPO1ar0vZx9TJnjp2VIxxGEtAofjZbxKL8JFPE4+t ETouHMbxxMruOSS4KnENxcvbISpj9PrnAwJjUOwgYdmg1IHCktJU2n9AKs1JHTjUIiBuLEJQ2CGc FPhxEJ0RuKDQKLQISYEHbq4nXIrB0zcxRu8AzWYHwp1gZpLe3P7Hi9w+uxe3T8E6pY/JaWUs405P JjMO9jTvQmP5S3kXZV7UuZA6hIjZHf2jK3N7GzuOmJKhYhR0pjB+jR4bOZs5BXQ28ys4H2hjDKaS CH+aP637zPWFKrwvnFOJS1bDOrdP1XFcOOAXHVSlkLAY9noU/dsRvC2yM0IiwMfMkW1WbOWZxca2 pa3MkcMsNjv7tpD9LgqdqJUwu42xMStz4VgzZwasmXNE1nZcrxndkW0+7GOv8/W8zsde56Nnsaz0 dT4mJX3M8PZRWmLC2WekL/ZlfEM++j4nIsXhCH4bYeoDIEFE6Y9j9Jf9b/THOC5ypiXwhYyOfFaz M1GcAoU5RZK5kXZ8475/5cBMqIBFovQq6eolnOu7mUO0aVnqBGBlioitrt4noM1Ge1bUbrT6sM3k yAjqtOlCf1+BbSi52BevTFwzPbq34H6s6KlFK+8P3vrGo8/uC08f2vjLtto5V68dzEfvGztjVm3H ngPdeeRX180YfN+T3feT1htvrHnonu4PMzrXl4AvTrxayxI4MYvsUtqVP3NfZZ3hzmWJPGW5FYAw Nyn4AeVt9yl30s2rst1sd9pA58Ki06Q3mY3mXDfTs9xM5zIwbcvAtC1Dj7ZlYERgyGEt6AozbcvA tC24/ykFUAPTtgxUG2Ps0MAUOgOGf8NYNyU6L9W83GfcpNG90x13d7p5N0eKHU5Gm+farNb0wcH/ qHDp/0XhsvZSuPg0JXZqtn9V4Ma62EelPX/0x8WYEnZJaYwdtGXHi0AG92hhTtGq08t6Sc+JStQq mn3YorelgUwPqDdRLsygnPbz9QLxhsdXfNLwWI2ibytYfGXz03z0/j1VjWOKVnc3k/XXLxl271vd 7AuWEcmv+TyAogl58OIDDnf6MMjXjMjol+5aM815WIVN0nuMo8Qr5SlinTxfXCjLJcpg22BnqbtK qbZVO6vc04XpuglKva3eOcG9RFiim6MssS1xznHfgB06UTBdw00SJumvMV7HzRXm6q8z6l1+XrIC y7Dn+pjt42NoIPX82JPEnDlpR2Dm1ArLpH+pIfX5O8ukjy92alm5kZL+EkaSIqkSJw04CTyClo+m rgTIm3OR0UzNXvalGGK+RuRn8GUuhDTVMv6D2EFqpMErKTsgaICXuhTSP1aXgpzSFKs/V9/rkELP b2xRfw8VW7qJwkTdLGGWjqeyiTbJYj/TgNI/2tDbKBrx5KbffoydN//lzpOJroOtG9a37lu3oZVk 4by7VyY+6z72l9twAJveevOtP/z2zTdgQBsSC/kQQNCGAniWdrdR6adcrlQrfKUaV0lQzTeGs4sc RdlXZDeq21R5sGuw7yrXVb46+RrjdNd03yJ5sXGhssS12Nepvmv/xP2J993AafvpwCk1qTrDfEyJ OUr5wcpI/iplmvKF4S/ZCcVgNXNOv59yeaffbEBmT+7beqzoNX2DvkXPqwyEqpbeFP1SM7B9Undm kzSj0PWcHE393pqe4lqYbZgux1nFpNgWQagTtCC8E8fxGcwHcSUehzlM5RzjxphxY8y48f9p71mD o6rSPOfc2/f97k533+5O0ul0pzvpmMQ8CB2CaRAJECFAJJCQKKyKS0AZHuOIZBRKWHzgC2sFdixf sArObPFIAgHGknVZfC2arUKtcXVhV5xhZpYt1kJnle30nnNud0Sd2bVqf21VcnLu/e6zu8/5zvc6 3/cdSDEEUlsdJIOZmmLJrVQxgnSqA5NIYpS1i1sb/fDqaViHEBsZEpz8zSkaPk3HYz7MFlPi1e48 UfUWeGjQd9xkruq9rXuatv/5gyN9Pz67ofvxKvOlu+/5+cvr1h4cXe569eF587Zld+4evfLIjU2Z K8ye0yffef+dtz8ktHQLHoqncB+a4K30pGo3NFhYytaz17Md7DJ2HcuJpiAKouo2RRUwApRp4wNJ TDwhQCESdkM3iph/Wocckyr+M21eRdI4ivLf4l2OGsldJU7OsVpPfk+NPG/0Xl5DIo1I66TySYKA 8dZWjTqr9q4hkWJOQzm2Gx6TpC0vXre8ZfHN102dOulmTxFb9sLqGU0vx1tblqzJnCGt0JK9wBzE rVDD+NIb2Ign0iTOEqdFOyO3R/rFx8TN0ZfcP698nVFFX8Dvq2mr/MDnCqIFCBm1UPL3CD1ij9Qj 9yg9ap/QJ/ZJfXKf0qcOlg3GdeJeES2fEO2WuuTbym5LrCtdF90YfUp6Rtme2FH5lzV7pH3K7vie xEDZ35d5E3mZJ5IHSvNANA8kHD0kdw8BSvNANA8UEj9OqyjVLcRjisQGwmUFrFxVGCBGoohdSe3Y dovdbt9i77ffszndLrZX2Wdttth+3Eb2q7hvCjBeUKtq2kNuN4izsgFHsEoBDUijRAY83nrH2qqZ 9RBW9RSuLESFoQKedabDqAr867ya++u0m3QwG6qSiwMwELXTbn99LXm8mloG/c6WjCub5k20w+RJ O0yesqmKYlPLqj2MFh/ioxX40aFQaqQCVpBPIU9U5D3MKhxvQ44Av6P5SioC9KNK4hX1S2pP1KKW 2o21qJZYiKPA70hWFOXCTitjIkIA8gXCNKsK+RLhqE6Huk6/nh6mZizCj8M0Rwv1Z88ZtCJn8wqU fW3ODNy7esxhEVcD79bMyU3DJZOrr4rVTTpzLkmSAG81nYYjUjNx7CG7sTg0n8On0/Frikpdnsoy 07AMt8FwETUcBGKCD0LXNXhT5MGHJVppEERKVUUox0p0Ii5KXJINgmKjkHB0J/qMbqgvb0Vy06ZN 4CoCRSwNvWOJmuJl8SrUUD+h8XsOQ7gQz1hqa2s5pD+0of+ehthTp3a1T5lY8WTHT1/tNg8oa5f3 93m91cHNr+3oXH7qp+/9Ck4OrVhz+7TJpf5Y7cxNc1rXJ4qTMzbc4Z/fM7+xNFTolqJ1U/p7up9b +AsyTqPZz1GFaxfwkRg1iQRelREN+0R6CgY22hBARZUgA7yGmNQlzCQYWTciIAJVK6bALC/cIN6w hP8Rv5F/gmcB5tHP8wf4E/wIz/GELRBaxTtsgQKf0wnaXGBCDqBWf0dWc7g/4TLEiJATAhz5hT+G +oAfTji47DvqEE27mmk2zl9uprM0mWZC5M26OpqBAnPymM+ZpCE2aLOR5imjPjjICNzY/GcrKzdv HhgacicTRS88Z1x3+4vo1m2QXzn66LbMU7MrA1STxLTsHFmxD7YfBQEyu4F1RBR2e4m756V0neWp T7phVHB7Fej2ypiYm7iZQJ035vcRwTVApWIflYd9FjUAj018+yj59o1Jwj5PzhScszv6qGrjI5Kw Stoj64MnfNA3J0A1TyIEBy4F0I8CzwcOBLIBNqDExDHGQTKJhsUR8ZzIinnGIY4xjpzdU6LWTvJ+ yi9EKgWL1OwozrG/pXwS8+L3xV3MQajDcHM+iQUeRAHW0FRdJf4rJEQZi7ysEgSqYDrGpoqKTZgF 42dz82fxMmpw8n0TkMa09L9/8+52Qx6UzbvmzXts0uAzgzPubG9Yi7ZnBh69tnVex+MPotSVj0jK eABcR3DvWGxhPqbHIuZ2il+OywGXk1fO0DSLLPV0I5AZVpwLJwY1x8CIiSeBzDQ9lkwGAgXzO8jp EpBUhSYiUEyIWIk1pZym66CySdIunTY+OG2coeE9OX8ezECdZiI/N4jb2AMr2HIJzTIXm4+ZjBl2 kv7l0pexecAkiCUWl9QboULHBpY+UhytZzlFdHNB0bZcLGA5WZQ1wTKAm/HwISEoF2JpOMZXCEmt HjTwTcIkbRrTyqX52UKbfL3eas6yFuvzrRX8bcId1nruXn6dcJQ7ph+2vuCuiAnZTICEGtcSetyq 9kwEjdZPhL8QdjI7lJfhXrRXfkkZAoe5Y9qb7Afcr8QL7AX9N9Zl7msxJFNfY4VuDc5xCqFEm26t nMkpKGk6awFT4IUYr8c0IhJqPKNCJaYOZz9INxI8VFEMVlC5T4UeNyfJZpmUNG9i50s95kqz33zY lEyJZQAk3eF0zHddp6qTl6sdh03jPCkOfcf/wbSHoS5VvEuUJEFWFMkwTTyC2wZcwMJcaWZ6maRr 4b8zeSHMm5aVdPEel4vXcD/HVM2jqpqA9ZikJHjw48TPKub4WQEEeYsVdFPRVPr1LDxSSdQ7QpCz dBJ/IXm+NFRIAmw3qow6DF9OS+F2Ca6S7peQNIwWpMV2E64y7zeJe+OCtGy44BJqc2Jc+OYh+KX7 y2WU6dmzL/f2+jHnwv8BO4PhP+5jlUsTZNLtD3Cx4jWjmVQCk9p2oLhj0aAaVsLol9lzWGo5B7Ts yCCo0cMWxtGxXFxdbQfqO2gU3chBnmRXwidKOtoO1FGnByF77iAfds5auYgn4tQ9chgze/xuYTg7 coivIW88BCaiY84njb187Dkffc7MnhuQwmwYTMz5b+VcxM8ctlKg0qKBFQfdxGzYlVcEko6HOY2G Ir5e1MfL7aOOXkycgW2jx4/ta2Hr9h19rmHy4f2jg8f3lX/IlmV+dt58G92V2fnOabTsykeof+i/ 3iPLiwDA/AemNAb8OOcDU6BDmWORyCFOxRipU5lLr05SpKTZK4JHdAvqEdsJs5xrp7r1p9mnhV3a X+knXCe4E/w7uqinvakA4xYL1IDRAJvkTfAxWai2FrJdfJe8SNsBd0o75SNoWHlTflv7B+Mj5n3x H9V/Mj6TrPzgkhVgmbpfxayDRAWkNQLpHEAqkCTE0VAnghKYDDnuhcs4juEFUYQcJ7pYBjN1HVNs Feq6asiYbSBVZhRD4nSkS8YpcEpERgyIHgBEBqmnVKjGFMajKIwkigyDOCzrKQqQ2i1ozVTvUyKS vpQT70tLwzB4JM3N5TbSRDnXp7Uwcx+KtOO2nGn2n8xl9yV4nAn4LxqfGZcv0ujNb/CZphLPYWtv Lt1lSte3ChRLnS3eEdRtFppzSDGo+QtTMo28KkwpEV+KwZUcHypJGdT3tyAFIyUpMR0aC3HtogYY am+ug7DOR7wCG4mlmYlDHW4e3fUvu6tClbGBD0efhI988lHT6G9RAo5+1Vozte7KqJJ5F87qGu3F v6tkdB7z7xhHAvAPORwplDw6IzMhW7c4mXOnLT0sp5VwDlfs6mTgk4D/dMA2yI6qYZRtBAf0ENTJ j7gzlEp4OvX9EpNW07hDwomaeoNseEW0vKrfistxJa5OUCaoDdouU05YCfcMb5fV5e4qWG4tdy8v WM/dra437/XcW7BFfdjcZm1zP+TZKe2Vf2kcN495fif9xvOFmjG+8mRDRXmM8rrlUJDVp+mbdUa3 x76+oyZaY26qjbquGJhWSoCxPW53zJI8+EBXMDGMyRJWdCQ3cVCUOfICEDJCqDr0WgiFhlHLkI7b Iu0ZRjel5RYrbaFbrNcsZA3DqYd1GAE3BCVyibZWOqzUKO0KM1fJKkjBdwxU67htUMtgMNyPCSNu vAzJmISRiMRh+o3L522SE/xiwG9cpBDwE9Ewj1HC1dMjBKW2UvzBVE/D1MaPqc1xoGQvADl7AV5N azzZfz7cmJIijSkNj7KhgpSZC0LpIhIRCYzG6OOOOzPmjdSt1Ou4lZJ006WR+z2TKptn+Mwylzx6 5+ufJCPFyU8HR1dOidb0d9aP3rHPSESDK/RCNpHZ9eNN/XejFVfe3D+1q4PIoAlMe85gvNLg/rRq DaO3BGTBWstH5sneTYsYgNcV0Vmz19OzMFCOEmK1kYIpaSacjqYLM8V2owfehG4SusW5xkp4K7oV K9Yb4Dphg/gI3CI8JH4FL6OgLZTBciEppoS/Fj6EPBktR4yCeoTJq0ji1kqxqoSaRAkJkhSDCLM/ BEkCLbTUlcQ/UVqqAidzOeXmSU1Cw1AfxMzQxR1HiwEAPDFMUMNfRH1eg0BLa0u0jdolzUU9S6Pk krYOSPdBuB/AdrAKkHXlaOAasHVjXQkhG8TunpsHyxDgfJJ6pxgZouY1G59hJeAz6qiVi7w1tJO5 EOvVvVQcw705VA7LBKJ2O60nkLbER68fIa1ImtJJJbK6C/bSvhcw+dBJI+R2F44EU6LgDU4mwtkh X4oK1pI3hTy4BrzfEJa6BsiVkvAHyE+oKylIoD1rF422M7dl/nbV+j74++2MwG3/SebmDeLPnDX2 Cv5oWQD24vIx9MNJsAs+iVahT5jP2bOux7mV/EL+b4Q/YMmjRXo2X+RnlbVqi/oxbtp/1ScbLuNB 42vzLush613PrQUTcTnuHfL93k7bOwLlgU/xgPxeKVxRuKLohuLi4tHw3pLnI2si/1Z6T/RkbGpZ d3xyoqgc4PJAcmHyt5XDlcNVF6uz1yZri8fLeBkv42W8jJfxMl7Gy3gZL+Pl/1qoXoRyq5F7sD5I 1oQlUzMcBhrmz/V7Ajozcd6NC32xRe2ts4LVbXXTFsyZPWFGb0VZY6HbNgpC3vLFyQ6r25xeWnPN TCURr+/prExFq+SmIu1a8P/6jyV5JgFZ5RO3z6Wp2SzeQrIlC+nibQOYD+YCP8nRC3TcdhPBPHAj WAh8IAYWgXbQCmaBIKgGbaAOTMN65hwwG0wAM0AvqABloBEUAjewgYF10BDwYrVvMUiCDmCBbmCC 6WQlDnANmAkUkABxUA96QCeoBCkQBVVABk2gCGjAaWCIn0F0OV+OLI85Zc3ypSvp6oPwCXL8A/+E bx9eApey3zqRW7GeoxNDTkUp8D/XV0B/vrK/AGvwuVcwPAXvj5Hr7FqwANezuDbj2olrIHduNq5L ce0gx/jeo/TZ71ShGKxydWZHXZ3gadcbYBmuz2L4RfZTsJdLgTvx8R5832u4sxrJPfhdT3OvgJ34 /DO0doJn8X2LMPwChnvwczU5WOQfBfYPqfids2gFYC7eT8e1DX+mG++n4roVvgEehG9kd+PreA8e wJ+/lZzHdVpuvxW3yRZ8vQU/F8XHD5CKvwdZslkHJbj/mf+l70jf4HsOHth/7Ba9+Qsh6HTmi5/G K8j+6PuDX369P3OHAQQFH4r5vvxvWcjeeQplbmRzdHJlYW0KZW5kb2JqCjI2IDAgb2JqCjw8L0xl bmd0aCAxNTQzPj5zdHJlYW0KPD94cGFja2V0IGJlZ2luPSfvu78nIGlkPSdXNU0wTXBDZWhpSHpy ZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAtZmlsdGVycyBlc2M9IkNSTEYiPz4KPHg6eG1wbWV0 YSB4bWxuczp4PSdhZG9iZTpuczptZXRhLycgeDp4bXB0az0nWE1QIHRvb2xraXQgMi45LjEtMTMs IGZyYW1ld29yayAxLjYnPgo8cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMub3JnLzE5 OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUuY29tL2lY LzEuMC8nPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0nY2FiODc2OGQtNTliMS0xMWRmLTAw MDAtMjY1YmMzOTQ2NmE0JyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8n IHBkZjpQcm9kdWNlcj0nQUZQTCBHaG9zdHNjcmlwdCA4LjU0Jy8+CjxyZGY6RGVzY3JpcHRpb24g cmRmOmFib3V0PSdjYWI4NzY4ZC01OWIxLTExZGYtMDAwMC0yNjViYzM5NDY2YTQnIHhtbG5zOnhh cD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLycgeGFwOk1vZGlmeURhdGU9JzIwMTAtMDUt MDQnIHhhcDpDcmVhdGVEYXRlPScyMDEwLTA1LTA0Jz48eGFwOkNyZWF0b3JUb29sPkFGUEwgR2hv c3RzY3JpcHQgOC41NCBQREYgV3JpdGVyPC94YXA6Q3JlYXRvclRvb2w+PC9yZGY6RGVzY3JpcHRp b24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSdjYWI4NzY4ZC01OWIxLTExZGYtMDAwMC0y NjViYzM5NDY2YTQnIHhtbG5zOnhhcE1NPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0v JyB4YXBNTTpEb2N1bWVudElEPSdjYWI4NzY4ZC01OWIxLTExZGYtMDAwMC0yNjViYzM5NDY2YTQn Lz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J2NhYjg3NjhkLTU5YjEtMTFkZi0wMDAwLTI2 NWJjMzk0NjZhNCcgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBk Yzpmb3JtYXQ9J2FwcGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1s Omxhbmc9J3gtZGVmYXVsdCc+XDM3NlwzNzdcMDAwSFwwMDBDXDAwMENcMDAwLVwwMDBMXDAwMEVc MDAwRFwwMDAgXDAwMFRcMDAwOFwwMDAgXDAwMFRcMDAwdVwwMDBiXDAwMGVcMDAwXChcMDAwQVww MDBwXDAwMHJcMDAwaVwwMDBsXDAwMCBcMDAwMlwwMDAwXDAwMDFcMDAwMFwwMDBcKTwvcmRmOmxp PjwvcmRmOkFsdD48L2RjOnRpdGxlPjxkYzpjcmVhdG9yPjxyZGY6U2VxPjxyZGY6bGk+XDM3Nlwz NzdcMDAwQVwwMDBkXDAwMG1cMDAwaVwwMDBuXDAwMGlcMDAwc1wwMDB0XDAwMHJcMDAwYVwwMDB0 XDAwMG9cMDAwcjwvcmRmOmxpPjwvcmRmOlNlcT48L2RjOmNyZWF0b3I+PC9yZGY6RGVzY3JpcHRp b24+CjwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKPD94cGFja2V0IGVuZD0ndyc/PgplbmRzdHJlYW0KZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVj ZXIoQUZQTCBHaG9zdHNjcmlwdCA4LjU0KQovQ3JlYXRpb25EYXRlKEQ6MjAxMDA1MDQxNjIzMDYr MDgnMDAnKQovTW9kRGF0ZShEOjIwMTAwNTA0MTYyMzA2KQovVGl0bGUoXDM3NlwzNzdcMDAwSFww MDBDXDAwMENcMDAwLVwwMDBMXDAwMEVcMDAwRFwwMDAgXDAwMFRcMDAwOFwwMDAgXDAwMFRcMDAw dVwwMDBiXDAwMGVcMDAwXChcMDAwQVwwMDBwXDAwMHJcMDAwaVwwMDBsXDAwMCBcMDAwMlwwMDAw XDAwMDFcMDAwMFwwMDBcKSkKL0NyZWF0b3IoXDM3NlwzNzdcMDAwUFwwMDBEXDAwMEZcMDAwQ1ww MDByXDAwMGVcMDAwYVwwMDB0XDAwMG9cMDAwclwwMDAgXDAwMFZcMDAwZVwwMDByXDAwMHNcMDAw aVwwMDBvXDAwMG5cMDAwIFwwMDAwXDAwMC5cMDAwOVwwMDAuXDAwMDMpCi9BdXRob3IoXDM3Nlwz NzdcMDAwQVwwMDBkXDAwMG1cMDAwaVwwMDBuXDAwMGlcMDAwc1wwMDB0XDAwMHJcMDAwYVwwMDB0 XDAwMG9cMDAwcikKL0tleXdvcmRzKCkKL1N1YmplY3QoKT4+ZW5kb2JqCnhyZWYKMCAyNwowMDAw MDAwMDAwIDY1NTM1IGYgCjAwMDAwMDMyMjkgMDAwMDAgbiAKMDAwMDA5MDQ0MiAwMDAwMCBuIAow MDAwMDAzMTU0IDAwMDAwIG4gCjAwMDAwMDI4MjAgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBu IAowMDAwMDAxODgxIDAwMDAwIG4gCjAwMDAwNDQ1ODggMDAwMDAgbiAKMDAwMDA0NTk1OCAwMDAw MCBuIAowMDAwMDQ1MjU1IDAwMDAwIG4gCjAwMDAwNjU4MzkgMDAwMDAgbiAKMDAwMDA0MjAwMyAw MDAwMCBuIAowMDAwMDI0Njg1IDAwMDAwIG4gCjAwMDAwMTM2MzMgMDAwMDAgbiAKMDAwMDAwMzM1 OSAwMDAwMCBuIAowMDAwMDAzMjk0IDAwMDAwIG4gCjAwMDAwNDQ0NjcgMDAwMDAgbiAKMDAwMDAw Mjk4NiAwMDAwMCBuIAowMDAwMDAxOTAxIDAwMDAwIG4gCjAwMDAwMDI4MDAgMDAwMDAgbiAKMDAw MDA0NDUwNiAwMDAwMCBuIAowMDAwMDQ0NTQ5IDAwMDAwIG4gCjAwMDAwNDYxNTcgMDAwMDAgbiAK MDAwMDA2NjA0MCAwMDAwMCBuIAowMDAwMDQ0OTczIDAwMDAwIG4gCjAwMDAwNDU2NjIgMDAwMDAg biAKMDAwMDA4ODg0OSAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDI3IC9Sb290IDEgMCBSIC9J bmZvIDIgMCBSCi9JRCBbPDExRTVEM0E5QzcyREVFQzNDMUM0QTYyRTAxOUYwODA3PjwxMUU1RDNB OUM3MkRFRUMzQzFDNEE2MkUwMTlGMDgwNz5dCj4+CnN0YXJ0eHJlZgo5MDk1OAolJUVPRgo= --TJUYd6jE45CUKzHkj7yv2NNRXiYkeco4=_-- From owner-atom-syntax@mail.imc.org Wed May 12 10:07:23 2010 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 EB3DA28C272 for ; Wed, 12 May 2010 10:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.454 X-Spam-Level: * X-Spam-Status: No, score=1.454 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_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 GUHdDwjzdr6z for ; Wed, 12 May 2010 10:07:23 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 0ABC628C286 for ; Wed, 12 May 2010 09:49:40 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4CGgclo043087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 09:42:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4CGgc23043086; Wed, 12 May 2010 09:42:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4CGgbvu043081 for ; Wed, 12 May 2010 09:42:37 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by vws15 with SMTP id 15so248975vws.16 for ; Wed, 12 May 2010 09:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rh585L4lMll7NS7TTnRLPMj9jpBh2WYxy4S3KOgxA7M=; b=Pf+GfKsckPWu8mQLvvwA7vHTArKwzrB2taGfO4qcD4HBWGUFlCFUGIQuk3OTw1lXoW 51JWGffmYFwiIDft8We2hDUJvvACCAxkXQZYITadMfkfBy/+qe7cmWcXembZ/sHIyRQK F3Z/fJoLgfIxhZXLqedJ8yL3JL+h7h+2gQ0RM= 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=KrPr4gH/2aKC5/rjpcHYy+nr8FyjlIfrATz8wJ8RIj7lnrI5Fq3k3zMEvRLRLCx838 SLt3IyfeTYwoROPas4klmTJqR+5YXmOQmtkaM9qeBw2sSYhJ1gdqpRCGhmdAlQQHTT8/ hTKK/bVPXTV/pAYcy4WMA0IEs4AqpAfO/N/YI= MIME-Version: 1.0 Received: by 10.229.211.68 with SMTP id gn4mr5011258qcb.79.1273682549917; Wed, 12 May 2010 09:42:29 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Wed, 12 May 2010 09:42:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 May 2010 09:42:29 -0700 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: James Snell To: Bob Wyman Cc: Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4CGgbvu043082 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Updated the Link Extensions Draft... http://www.snellspace.com/wp/2010/05/atom-link-extensions/ http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-03.txt - James On Tue, May 4, 2010 at 10:54 AM, Bob Wyman wrote: > I find that I have a real need for the "md5" Link rel mechanism defined in > James Snell's old Atom Link Extensions draft or something functionally > equivalent. Basically, what I need to do is ensure that the "src" attribute > on an atom.content element is pointing to a known version of a resource > rather than simply to any resource that has the same URL as in the src > attribute. I'm then going to sign the Atom entry that contains this "by ref" > content element. > I've looked at the HTML5 RelExtentions Wiki but don't see anything there > that looks like it does the job. > Has anyone else needed hashed links in Atom? If so, what approach did you > use to provide them? Is anyone aware of plans to introduce an "md5" or > equivalent attribute to the HTML5 list? > bob wyman > -- - James Snell http://www.snellspace.com jasnell@gmail.com From atompub-archive@megatron.ietf.org Wed May 12 10:55:18 2010 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 CD48D3A6A0A for ; Wed, 12 May 2010 10:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.611 X-Spam-Level: X-Spam-Status: No, score=-10.611 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_NONE=0.1, 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 NSB7soFh3ynp for ; Wed, 12 May 2010 10:55:17 -0700 (PDT) Received: from alsayasi.com (unknown [59.177.199.254]) by core3.amsl.com (Postfix) with SMTP id 7A54B28C372 for ; Wed, 12 May 2010 10:32:32 -0700 (PDT) From: RX-Store Subject: Sales Event get 78% off To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100512173233.7A54B28C372@core3.amsl.com> Date: Wed, 12 May 2010 10:32:32 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://rosebreak.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 02870 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 83690 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 87596 is unauthorized. 24951

From owner-atom-syntax@mail.imc.org Wed May 12 12:59:22 2010 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 252A93A6880 for ; Wed, 12 May 2010 12:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.927 X-Spam-Level: * X-Spam-Status: No, score=1.927 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 vMY8yo5gR6Jy for ; Wed, 12 May 2010 12:59:20 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2EB443A6891 for ; Wed, 12 May 2010 12:59:19 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4CJrQxo055418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 12:53:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4CJrQ1o055417; Wed, 12 May 2010 12:53:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-gy0-f171.google.com (mail-gy0-f171.google.com [209.85.160.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4CJrPwx055412 for ; Wed, 12 May 2010 12:53:26 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by gyf3 with SMTP id 3so192644gyf.16 for ; Wed, 12 May 2010 12:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=XNzbRlhDFcrzGOyjfkBGv78/9Czc8gReQ1qCKwtd6oE=; b=mzYJi9chF0HDv+stHagSMmuUnZnipnPQb7Qe+nnDn0PHUePCehyO2ikSvjNfKbpCId lvWmkvW6QE3c2twsZBIOFaNTqrfHnJ6ziRWg5SzUjDORadaSFI46bm3COBMk7hM/JxIq YsAPHhYPjbL49d9eWwbsONGveJ5LEWwRNNSAk= 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=Tfc627SCP9r5kZiF4H8Sf+5zBGaHx/oF3vI9gzA1LG4uidLTIPxPf4bqc/bSS+ziRr OM2m8nPjcCRXGz27DRiESXp7WVHcX1cFrhP6fKhBylLJl2+cikIkBLnW6vOlPC0l9Nf0 YeCDeIzJlNHlzNEyufHXply5mB9xjl+fVuhJU= MIME-Version: 1.0 Received: by 10.101.172.1 with SMTP id z1mr4857093ano.235.1273694004420; Wed, 12 May 2010 12:53:24 -0700 (PDT) Received: by 10.100.154.20 with HTTP; Wed, 12 May 2010 12:53:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 May 2010 15:53:24 -0400 X-Google-Sender-Auth: 6vkznjxtTun5CrFXZDb4M5tq92Y Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Bob Wyman To: James Snell Cc: Atom-Syntax Content-Type: multipart/alternative; boundary=001636c92539afa9b804866afed6 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636c92539afa9b804866afed6 Content-Type: text/plain; charset=ISO-8859-1 James, thanks for updating and revising this draft! I would strongly encourage you to make the markup more expressive and flexible by supporting "a generic hash attribute with an internal structure for specifying algorithm and value". Actually, I would suggest that you extend this a bit further to include a specification of the encoding for the hash value.Thus, I would suggest the following pattern: hash_algorithm.encoding.hash_value Alternatively, you could define a single, required hash_value encoding. (Which wouldn't be too bad a thing to do.) Clearly, there should be a registry of hash_algorithms as well as encodings (if supported). In your blog post, you mention that clients might tend to rely on the value returned by the Content-MD5 header. While this may be reasonable for HEAD requests, clients should probably not trust the remote server when doing GETs; they would be well advised to recompute the hash to ensure that the remote server isn't lying about the hash (there are quite a number of useful, but often deceitful, reasons why this might happen). Also, please note that it should be possible to include a hash value which uses a different hashing algorithm and encoding than is used by the Content-MD5 implementation. Thus, for any particular web resource, we might have quite a number of possible hash/encoding combinations and, in some cases, even have two hashes available for a single GET (i.e. The Content-MD5 header value and perhaps an SHA1/base64 hash specified in the link.) You might make a note about some of these odd cases in your security considerations section. bob wyman On Wed, May 12, 2010 at 12:42 PM, James Snell wrote: > Updated the Link Extensions Draft... > > http://www.snellspace.com/wp/2010/05/atom-link-extensions/ > > http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-03.txt > > - James > > On Tue, May 4, 2010 at 10:54 AM, Bob Wyman wrote: > > I find that I have a real need for the "md5" Link rel mechanism defined > in > > James Snell's old Atom Link Extensions draft or something functionally > > equivalent. Basically, what I need to do is ensure that the "src" > attribute > > on an atom.content element is pointing to a known version of a resource > > rather than simply to any resource that has the same URL as in the src > > attribute. I'm then going to sign the Atom entry that contains this "by > ref" > > content element. > > I've looked at the HTML5 RelExtentions Wiki but don't see anything there > > that looks like it does the job. > > Has anyone else needed hashed links in Atom? If so, what approach did you > > use to provide them? Is anyone aware of plans to introduce an "md5" or > > equivalent attribute to the HTML5 list? > > bob wyman > > > > > > -- > - James Snell > http://www.snellspace.com > jasnell@gmail.com > --001636c92539afa9b804866afed6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable James, thanks for updating and revising this draft!

I wo= uld strongly encourage you to make the markup more expressive and flexible = by supporting "a generic hash attribute with an in= ternal structure for specifying algorithm and value". Actually, I would suggest that you extend = this a bit further to include a specification of the encoding for the hash = value.Thus, I would suggest the following pattern:
hash_algorithm.encoding.hash_value

Alternatively, you could define a single, = required hash_value encoding. (Which wouldn't be too bad a thing to do.= )=A0Clearly, there should be a registry of hash_algorithms as well as encod= ings (if supported).
<= br>
In your blog post, you mention that clients might = tend to rely on the value returned by the Content-MD5 header. While this ma= y be reasonable for HEAD requests, clients should probably not trust the re= mote server when doing GETs; they would be well advised to recompute the ha= sh to ensure that the remote server isn't lying about the hash (there a= re quite a number of useful, but often deceitful, reasons why this might ha= ppen). Also, please note that it should be possible to include a hash value= which uses a different hashing algorithm and encoding than is used by the = Content-MD5 implementation. Thus, for any particular web resource, we might= have quite a number of possible hash/encoding combinations and, in some ca= ses, even have two hashes available for a single GET (i.e. The Content-MD5 = header value and perhaps an SHA1/base64 hash specified in the link.) You mi= ght make a note about some of these odd cases in your security consideratio= ns section.

bob wyman

On Wed= , May 12, 2010 at 12:42 PM, James Snell <jasnell@gmail.com> wrote:
Updated the Link Extensions Draft...

=A0http://www.snellspace.com/wp/2010/05/atom-link-extensions= /
=A0http://www.ietf.org/internet-drafts/d= raft-snell-atompub-link-extensions-03.txt

- James

On Tue, May 4, 2010 at 10:54 AM, Bob Wyman <bob@wyman.us> wrote:
> I find that I have a real need for the "md5" Link rel mechan= ism defined in
> James Snell's old Atom Link Extensions draft or something function= ally
> equivalent. Basically, what I need to do is ensure that the "src&= quot; attribute
> on an atom.content element is pointing to a known version of a resourc= e
> rather than simply to any resource that has the same URL as in the src=
> attribute. I'm then going to sign the Atom entry that contains thi= s "by ref"
> content element.
> I've looked at the HTML5 RelExtentions Wiki=A0but don't see an= ything there
> that looks like it does the job.
> Has anyone else needed hashed links in Atom? If so, what approach did = you
> use to provide them? Is anyone aware of plans to introduce an "md= 5" or
> equivalent attribute to the HTML5 list?
> bob wyman
>



--

--001636c92539afa9b804866afed6-- From owner-atom-syntax@mail.imc.org Wed May 12 13:18:57 2010 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 AE25C3A67E3 for ; Wed, 12 May 2010 13:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.553 X-Spam-Level: ** X-Spam-Status: No, score=2.553 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW3R0VnwAP-f for ; Wed, 12 May 2010 13:18:56 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2E5843A67CC for ; Wed, 12 May 2010 13:18:50 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4CKDLns056565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 13:13:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4CKDLnJ056564; Wed, 12 May 2010 13:13:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-pv0-f171.google.com (mail-pv0-f171.google.com [74.125.83.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4CKDLNb056555; Wed, 12 May 2010 13:13:21 -0700 (MST) (envelope-from abdelazer@gmail.com) Received: by pva18 with SMTP id 18so288119pva.16 for ; Wed, 12 May 2010 13:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=W8mxUDZNQxFTB8x01357aiHbRyCU1q9hygBJuXCRYFo=; b=tPDs63x8IjDRtuaWtKj6nqcv/qb3alpxjwKn6Cw4Eshguw+3Vhq/+BFKo8LE91CcvJ 5rPCUljIEh6mX/JRBDA59NoDicWBZXlgDK8srvAjqz7dpJs+bUZRoVPTfFqB1IVtuAU1 RrN7Twh5yLqRXKOV+75sytmYiQUaHqb5JYeoo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=tc3YU7OaSWXB0yNiB21iNMewz1XNzhdpw0LH7O7Z54QIpxS19X880981IvxLLYJLBc vf28SLjfsIuGd85XlGsUKtrtb0Ihy9zN4XZlV8rdUHXOCIf+l31L7PKN4UW3Iq1155U0 yObFVyWJHf5/6oj5lSiReIL3405rBeQfcXK2c= Received: by 10.141.89.2 with SMTP id r2mr5360417rvl.277.1273695200194; Wed, 12 May 2010 13:13:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.14.16 with HTTP; Wed, 12 May 2010 13:13:00 -0700 (PDT) From: Keith Fahlgren Date: Wed, 12 May 2010 13:13:00 -0700 Message-ID: Subject: Call for comments: OPDS Catalogs 0.9 draft, an Atom-based standard for ebook distribution To: Atom-Protocol , atom-syntax@imc.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4CKDLNb056556 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, The OPDS Catalogs 0.9 draft at http://code.google.com/p/openpub/wiki/CatalogSpecDraft is now ready for your review and we'd love to get your feedback and comments. Please submit any and all critiques or comments to the openpub mailing list (http://groups.google.com/group/openpub) or add an issue (http://code.google.com/p/openpub/issues/entry) by 19 May 2010. What are OPDS Catalogs? OPDS stands for "Open Publication Distribution System" and OPDS Catalogs enable the aggregation, distribution, and discovery of books, journals, and other digital content by any user, from any source, in any electronic format, on any device. The OPDS Catalogs specification is based on the Atom syndication format and prioritizes simplicity and speed. Is this vaporware? Nope. The OPDS Catalogs 0.9 draft is based on a lot of existing, in-production software and collaboration between ebook reading systems, publishers, and distributors. Feedbooks, for example, already distributes more than 2 million ebooks every month using its OPDS Catalogs (http://feedbooks.com/catalog.atom) and ebook readers like Aldiko, Stanza, QuickReader, FBReader, Ibis Reader, and others already support the evolving specification. Publishers and libraries have been early adopters of the OPDS Catalogs as the specification has evolved toward 0.9 as well. Some highlights: * Internet Archive (1.8 million free books, http://bookserver.archive.org/catalog/) * O'Reilly Media (hundreds of technical ebooks, http://catalog.oreilly.com/aldiko/main.xml) * PragPub Magazine, from The Pragmatic Programmers (http://pragprog.com/magazines.opds) * Smashwords (http://www.smashwords.com/atom) OPDS Catalogs are the first component in the Internet Archive’s BookServer Project (http://www.archive.org/bookserver). Thanks for your feedback, Keith Fahlgren & the openpub community From owner-atom-syntax@mail.imc.org Wed May 12 13:29:39 2010 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 B63C03A6937 for ; Wed, 12 May 2010 13:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.376 X-Spam-Level: ** X-Spam-Status: No, score=2.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, 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 i+s3RtT4XE6w for ; Wed, 12 May 2010 13:29:38 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 776753A63C9 for ; Wed, 12 May 2010 13:29:38 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4CKOdsQ057135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 13:24:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4CKOdQp057134; Wed, 12 May 2010 13:24:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-ww0-f43.google.com (mail-ww0-f43.google.com [74.125.82.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4CKOcKx057129 for ; Wed, 12 May 2010 13:24:38 -0700 (MST) (envelope-from pjkeane@gmail.com) Received: by wwb18 with SMTP id 18so42983wwb.16 for ; Wed, 12 May 2010 13:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=7wshaNmtojMF0viVA/sAubEUBQhXfqDV1ZuXKKnlVwE=; b=xzIw2dudFcIMff9jjsYoqge97mL+o+W+Q+ZXp98wXtz2ztapB+pxhlsJ9TvYb1terf i7fb0+bCZAFTwvJZKqd1J1n45FIHBSAUawik47/2G35X1yCF7lthSwEJ8VYNHFov/jgc Qybo85RyyCyBXPu7LJ8fBZTWl7c+brT9Zg/0s= 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=h068zER3b1/WNZiChWgND8a/TYzXRUZT5mirizgu74TsAVfUlCxfXw8kPLIkxQzhoA HOgAAf5pwh5JipGqGQmwn8pJHGaNhlsKiDNSr2v2T7ixYvnqh3yPlSkr9D2H4gG9aUzO mToGmW35rfvMvaJDwjzEtXFnxe1P022nQAaZU= MIME-Version: 1.0 Received: by 10.216.154.140 with SMTP id h12mr4975975wek.193.1273695876906; Wed, 12 May 2010 13:24:36 -0700 (PDT) Received: by 10.216.89.20 with HTTP; Wed, 12 May 2010 13:24:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 May 2010 15:24:36 -0500 X-Google-Sender-Auth: ntWn8hrli9PnR9QJDEtDtaH5GcE Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Peter Keane To: Bob Wyman Cc: James Snell , Atom-Syntax Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4CKOdKx057130 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, May 12, 2010 at 2:53 PM, Bob Wyman wrote: > James, thanks for updating and revising this draft! > I would strongly encourage you to make the markup more expressive and > flexible by supporting "a generic hash attribute with an internal structure > for specifying algorithm and value". Actually, I would suggest that you > extend this a bit further to include a specification of the encoding for the > hash value.Thus, I would suggest the following pattern: > > hash_algorithm.encoding.hash_value > I certainly understand the value of alternative algorithms, although I do appreciate the "what's the simplest thing...." approach of this draft. I'll note that the MediaRSS extension uses an element to express hash information: dfdec888b72151965a34b4b59031290a Perhaps simply using that element as "content" of the atom:link element offers the desired added flexibility? --Peter Keane > Alternatively, you could define a single, required hash_value encoding. > (Which wouldn't be too bad a thing to do.) Clearly, there should be a > registry of hash_algorithms as well as encodings (if supported). > In your blog post, you mention that clients might tend to rely on the value > returned by the Content-MD5 header. While this may be reasonable for HEAD > requests, clients should probably not trust the remote server when doing > GETs; they would be well advised to recompute the hash to ensure that the > remote server isn't lying about the hash (there are quite a number of > useful, but often deceitful, reasons why this might happen). Also, please > note that it should be possible to include a hash value which uses a > different hashing algorithm and encoding than is used by the Content-MD5 > implementation. Thus, for any particular web resource, we might have quite a > number of possible hash/encoding combinations and, in some cases, even have > two hashes available for a single GET (i.e. The Content-MD5 header value and > perhaps an SHA1/base64 hash specified in the link.) You might make a note > about some of these odd cases in your security considerations section. > bob wyman > On Wed, May 12, 2010 at 12:42 PM, James Snell wrote: >> >> Updated the Link Extensions Draft... >> >>  http://www.snellspace.com/wp/2010/05/atom-link-extensions/ >> >>  http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-03.txt >> >> - James >> >> On Tue, May 4, 2010 at 10:54 AM, Bob Wyman wrote: >> > I find that I have a real need for the "md5" Link rel mechanism defined >> > in >> > James Snell's old Atom Link Extensions draft or something functionally >> > equivalent. Basically, what I need to do is ensure that the "src" >> > attribute >> > on an atom.content element is pointing to a known version of a resource >> > rather than simply to any resource that has the same URL as in the src >> > attribute. I'm then going to sign the Atom entry that contains this "by >> > ref" >> > content element. >> > I've looked at the HTML5 RelExtentions Wiki but don't see anything there >> > that looks like it does the job. >> > Has anyone else needed hashed links in Atom? If so, what approach did >> > you >> > use to provide them? Is anyone aware of plans to introduce an "md5" or >> > equivalent attribute to the HTML5 list? >> > bob wyman >> > >> >> >> >> -- >> - James Snell >>  http://www.snellspace.com >>  jasnell@gmail.com > > From owner-atom-syntax@mail.imc.org Wed May 12 14:15:40 2010 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 8C1253A6933 for ; Wed, 12 May 2010 14:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.304 X-Spam-Level: * X-Spam-Status: No, score=1.304 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOwkYK78N8yK for ; Wed, 12 May 2010 14:15:37 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 7345C3A6911 for ; Wed, 12 May 2010 14:15:37 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4CLAV7R059565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 14:10:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4CLAVBR059564; Wed, 12 May 2010 14:10:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4CLAU68059558 for ; Wed, 12 May 2010 14:10:30 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by vws15 with SMTP id 15so537552vws.16 for ; Wed, 12 May 2010 14:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rQLXpexJEnMB1/sMPGzg+U4YmmE6Komh50F8SsPRdYo=; b=Y61wdNL2GK1vtBP200yqK434/ZMnCVN8baM7vRX+ODXws0X+DzdxCRp+ha5eCfmUKS JtiG2BJfA3/mDNCjqqhWXu7OpalXKK+ZEU5XjKfrTqaVKpXD9lHS2mHuh6k3O5mYImpi eLtr+8yfwSddWbCFoxPQp4jaR79sbdUXBp0cg= 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=fUXnClYiH0oYHsIyjlKbTilLA5aVzAJFapXYD1c+ecWjvzOl+szLnSUL+A7g3VZnJt KJvlQsxzTJM61SCBcMZxhy6XcqSwiaQqIaNKWmE2nb73mEgw2ZZUTTU1FoJkhL7mjhSs 5Px9D4I9y+8AvFbUNQ3w3JhJs2nlwu1jLChF0= MIME-Version: 1.0 Received: by 10.229.214.12 with SMTP id gy12mr825757qcb.173.1273698628873; Wed, 12 May 2010 14:10:28 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Wed, 12 May 2010 14:10:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 May 2010 14:10:28 -0700 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: James Snell To: Bob Wyman Cc: Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4CLAV68059560 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, May 12, 2010 at 12:53 PM, Bob Wyman wrote: > James, thanks for updating and revising this draft! > I would strongly encourage you to make the markup more expressive and > flexible by supporting "a generic hash attribute with an internal structure > for specifying algorithm and value". Actually, I would suggest that you > extend this a bit further to include a specification of the encoding for the > hash value.Thus, I would suggest the following pattern: > > hash_algorithm.encoding.hash_value > Hmm... for me, this immediately starts screaming overkill. I'd almost prefer to go the route of defining individual attributes for each hash algorithm... e.g. md5="..." sha256="..." Each using the basic hex encoding. The spec can define a handful of these for the most common hash algorithms and establish the pattern. New attributes for new algorithms can be added later. Just seems simpler. > Alternatively, you could define a single, required hash_value encoding. > (Which wouldn't be too bad a thing to do.) Clearly, there should be a > registry of hash_algorithms as well as encodings (if supported). > In your blog post, you mention that clients might tend to rely on the value > returned by the Content-MD5 header. While this may be reasonable for HEAD > requests, clients should probably not trust the remote server when doing > GETs; they would be well advised to recompute the hash to ensure that the > remote server isn't lying about the hash (there are quite a number of > useful, but often deceitful, reasons why this might happen). Also, please > note that it should be possible to include a hash value which uses a > different hashing algorithm and encoding than is used by the Content-MD5 > implementation. Thus, for any particular web resource, we might have quite a > number of possible hash/encoding combinations and, in some cases, even have > two hashes available for a single GET (i.e. The Content-MD5 header value and > perhaps an SHA1/base64 hash specified in the link.) You might make a note > about some of these odd cases in your security considerations section. > bob wyman > On Wed, May 12, 2010 at 12:42 PM, James Snell wrote: >> >> Updated the Link Extensions Draft... >> >>  http://www.snellspace.com/wp/2010/05/atom-link-extensions/ >> >>  http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-03.txt >> >> - James >> >> On Tue, May 4, 2010 at 10:54 AM, Bob Wyman wrote: >> > I find that I have a real need for the "md5" Link rel mechanism defined >> > in >> > James Snell's old Atom Link Extensions draft or something functionally >> > equivalent. Basically, what I need to do is ensure that the "src" >> > attribute >> > on an atom.content element is pointing to a known version of a resource >> > rather than simply to any resource that has the same URL as in the src >> > attribute. I'm then going to sign the Atom entry that contains this "by >> > ref" >> > content element. >> > I've looked at the HTML5 RelExtentions Wiki but don't see anything there >> > that looks like it does the job. >> > Has anyone else needed hashed links in Atom? If so, what approach did >> > you >> > use to provide them? Is anyone aware of plans to introduce an "md5" or >> > equivalent attribute to the HTML5 list? >> > bob wyman >> > >> >> >> >> -- >> - James Snell >>  http://www.snellspace.com >>  jasnell@gmail.com > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Wed May 12 14:27:21 2010 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 D002A3A684C for ; Wed, 12 May 2010 14:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.846 X-Spam-Level: * X-Spam-Status: No, score=1.846 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, MISSING_HEADERS=1.292] 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 X4XhT432Wqkf for ; Wed, 12 May 2010 14:27:20 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 485F53A6826 for ; Wed, 12 May 2010 14:27:18 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4CLMuBW060288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 14:22:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4CLMuRL060287; Wed, 12 May 2010 14:22:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4CLMtSE060282 for ; Wed, 12 May 2010 14:22:56 -0700 (MST) (envelope-from mart@degeneration.co.uk) Received: by vws15 with SMTP id 15so550486vws.16 for ; Wed, 12 May 2010 14:22:55 -0700 (PDT) Received: by 10.220.62.199 with SMTP id y7mr6128589vch.80.1273699374509; Wed, 12 May 2010 14:22:54 -0700 (PDT) Received: from [172.16.129.195] ([204.9.180.30]) by mx.google.com with ESMTPS id m13sm2309715vcs.13.2010.05.12.14.22.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 May 2010 14:22:53 -0700 (PDT) Message-ID: <4BEB1C2A.4000207@degeneration.co.uk> Date: Wed, 12 May 2010 14:22:50 -0700 From: Martin Atkins User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 CC: Atom-Syntax Subject: Re: Link Extensions. Need "md5" or some kind of hash. References: 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: On 05/12/2010 02:10 PM, James Snell wrote: > > On Wed, May 12, 2010 at 12:53 PM, Bob Wyman wrote: >> James, thanks for updating and revising this draft! >> I would strongly encourage you to make the markup more expressive and >> flexible by supporting "a generic hash attribute with an internal structure >> for specifying algorithm and value". Actually, I would suggest that you >> extend this a bit further to include a specification of the encoding for the >> hash value.Thus, I would suggest the following pattern: >> >> hash_algorithm.encoding.hash_value >> > > Hmm... for me, this immediately starts screaming overkill. I'd almost > prefer to go the route of defining individual attributes for each hash > algorithm... e.g. > > md5="..." > sha256="..." > > Each using the basic hex encoding. > > The spec can define a handful of these for the most common hash > algorithms and establish the pattern. New attributes for new > algorithms can be added later. > > Just seems simpler. > Strongly agreed. Having one attribute which can represent all hash types would be useful only if there were some way for a consumer to dynamically discover how to produce a hash of a particular type, which is not practical. Otherwise, an implementation must already have a fixed set of supported hash types, in which case it is beneficial to separate them into separate attributes so that publishers can choose to produce more than one of them to accomodate the capabilities of different consumers, each of which will support only a subset of the set of all existing hash algorithms. From owner-atom-syntax@mail.imc.org Wed May 12 14:45:33 2010 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 19E463A6995 for ; Wed, 12 May 2010 14:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.076 X-Spam-Level: ** X-Spam-Status: No, score=2.076 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nphlD0CgrPV for ; Wed, 12 May 2010 14:45:32 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 35E6728C11C for ; Wed, 12 May 2010 14:45:23 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4CLfOEN061259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 14:41:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4CLfNrs061258; Wed, 12 May 2010 14:41:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4CLfMle061253 for ; Wed, 12 May 2010 14:41:23 -0700 (MST) (envelope-from pjkeane@gmail.com) Received: by wyb39 with SMTP id 39so426613wyb.16 for ; Wed, 12 May 2010 14:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=WUsNZabdPkx+d0MJ7dlbYBUIfYlAsk1FOwPRnGL2pa0=; b=SH+Joq7UdNxbs58//JkrYoefSQR48dD4xXQ88S0uDDuJKXf4mwLIvDH9GZuM8ov5zM w1QdJlNwBtaZ1HVYKloIQ027dMATA7sXE1ZtY5evKoSgKiel1DjT3ABURhiv4k/aRE/S Jiwno5eILePIr9Vea1ifbaiIehK3YcIQ7GBGs= 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=a4hLe/Ng4I8jZz8mrQxeTQn+V+Mr7w9R0gCdAV/TVeGNxWNebJx5A0bNVjc1aG7uxC O7K2pAaGthx/zjmaxCGqX78gjg+tYQkTuO5RhZeEFPTFgWZdmUxgYl92B6KLV0NkqNeF xnCJqPI2ag2fOYXUHRtQHrBDZ6DKMjsY6ge5g= MIME-Version: 1.0 Received: by 10.216.91.80 with SMTP id g58mr1394843wef.181.1273700481214; Wed, 12 May 2010 14:41:21 -0700 (PDT) Received: by 10.216.89.20 with HTTP; Wed, 12 May 2010 14:41:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 May 2010 16:41:21 -0500 X-Google-Sender-Auth: B5g2-iqnelXuGNZAP-KOHyvRA40 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Peter Keane To: James Snell Cc: Bob Wyman , Atom-Syntax Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4CLfNle061254 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, May 12, 2010 at 4:10 PM, James Snell wrote: > > On Wed, May 12, 2010 at 12:53 PM, Bob Wyman wrote: >> James, thanks for updating and revising this draft! >> I would strongly encourage you to make the markup more expressive and >> flexible by supporting "a generic hash attribute with an internal structure >> for specifying algorithm and value". Actually, I would suggest that you >> extend this a bit further to include a specification of the encoding for the >> hash value.Thus, I would suggest the following pattern: >> >> hash_algorithm.encoding.hash_value >> > > Hmm... for me, this immediately starts screaming overkill. I'd almost > prefer to go the route of defining individual attributes for each hash > algorithm... e.g. > >  md5="..." >  sha256="..." > > Each using the basic hex encoding. > > The spec can define a handful of these for the most common hash > algorithms and establish the pattern. New attributes for new > algorithms can be added later. +1 > > Just seems simpler. > >> Alternatively, you could define a single, required hash_value encoding. >> (Which wouldn't be too bad a thing to do.) Clearly, there should be a >> registry of hash_algorithms as well as encodings (if supported). >> In your blog post, you mention that clients might tend to rely on the value >> returned by the Content-MD5 header. While this may be reasonable for HEAD >> requests, clients should probably not trust the remote server when doing >> GETs; they would be well advised to recompute the hash to ensure that the >> remote server isn't lying about the hash (there are quite a number of >> useful, but often deceitful, reasons why this might happen). Also, please >> note that it should be possible to include a hash value which uses a >> different hashing algorithm and encoding than is used by the Content-MD5 >> implementation. Thus, for any particular web resource, we might have quite a >> number of possible hash/encoding combinations and, in some cases, even have >> two hashes available for a single GET (i.e. The Content-MD5 header value and >> perhaps an SHA1/base64 hash specified in the link.) You might make a note >> about some of these odd cases in your security considerations section. >> bob wyman >> On Wed, May 12, 2010 at 12:42 PM, James Snell wrote: >>> >>> Updated the Link Extensions Draft... >>> >>>  http://www.snellspace.com/wp/2010/05/atom-link-extensions/ >>> >>>  http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-03.txt >>> >>> - James >>> >>> On Tue, May 4, 2010 at 10:54 AM, Bob Wyman wrote: >>> > I find that I have a real need for the "md5" Link rel mechanism defined >>> > in >>> > James Snell's old Atom Link Extensions draft or something functionally >>> > equivalent. Basically, what I need to do is ensure that the "src" >>> > attribute >>> > on an atom.content element is pointing to a known version of a resource >>> > rather than simply to any resource that has the same URL as in the src >>> > attribute. I'm then going to sign the Atom entry that contains this "by >>> > ref" >>> > content element. >>> > I've looked at the HTML5 RelExtentions Wiki but don't see anything there >>> > that looks like it does the job. >>> > Has anyone else needed hashed links in Atom? If so, what approach did >>> > you >>> > use to provide them? Is anyone aware of plans to introduce an "md5" or >>> > equivalent attribute to the HTML5 list? >>> > bob wyman >>> > >>> >>> >>> >>> -- >>> - James Snell >>>  http://www.snellspace.com >>>  jasnell@gmail.com >> >> > > > > -- > - James Snell >  http://www.snellspace.com >  jasnell@gmail.com > > From owner-atom-syntax@mail.imc.org Wed May 12 17:59:01 2010 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 5A7173A68F2 for ; Wed, 12 May 2010 17:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.254 X-Spam-Level: * X-Spam-Status: No, score=1.254 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfGOyKyAXU9O for ; Wed, 12 May 2010 17:59:00 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 0C1CE3A6856 for ; Wed, 12 May 2010 17:58:59 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4D0rHB0070845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 17:53:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4D0rHhE070844; Wed, 12 May 2010 17:53:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.221.179]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4D0rGxR070836 for ; Wed, 12 May 2010 17:53:16 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk9 with SMTP id 9so803044qyk.2 for ; Wed, 12 May 2010 17:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=USrfN1KA9z5Pkru40OAmsYqFHn2dGJja7cxGqEVZiyo=; b=LJhUv59/jpt7zmL9kCWtEmfnwbEuyQnjBkGhsvBCRRCrOhtFbCWLxwW6EptJZWhnlN 66/h3KO+KbDFRjXc+40BAKlkBRBetjUfHvaaiVsKNRoFUyt7mJ9Z9oiR37Z7Wm/60EU9 w2GdBRR89M02/JSg64C6E2rNlgb++GAFsvWjI= 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=dEQhj8v5DCRQ19KMvKbq8aOaFwvFmTUEqvu88SLsAFt92RPEuaD3l4TnhDaPHfuzP8 eaQzZImnt8OTKdT6vIq36JkE5pVAyS5rPAdj20FC1tUx/ZyaL9gAFvXRrbe7TzY2bwIC 0MjgnT0PE3ey+E1fegE7ZDWjPCGVb25SIgXgI= MIME-Version: 1.0 Received: by 10.229.73.135 with SMTP id q7mr5309055qcj.41.1273711995300; Wed, 12 May 2010 17:53:15 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Wed, 12 May 2010 17:53:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 May 2010 17:53:15 -0700 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: James Snell To: Peter Keane Cc: Bob Wyman , Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4D0rGxR070840 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: So the key question is: what are the main algorithms we need to provide attributes for? - James On Wed, May 12, 2010 at 2:41 PM, Peter Keane wrote: > On Wed, May 12, 2010 at 4:10 PM, James Snell wrote: >> >> On Wed, May 12, 2010 at 12:53 PM, Bob Wyman wrote: >>> James, thanks for updating and revising this draft! >>> I would strongly encourage you to make the markup more expressive and >>> flexible by supporting "a generic hash attribute with an internal structure >>> for specifying algorithm and value". Actually, I would suggest that you >>> extend this a bit further to include a specification of the encoding for the >>> hash value.Thus, I would suggest the following pattern: >>> >>> hash_algorithm.encoding.hash_value >>> >> >> Hmm... for me, this immediately starts screaming overkill. I'd almost >> prefer to go the route of defining individual attributes for each hash >> algorithm... e.g. >> >>  md5="..." >>  sha256="..." >> >> Each using the basic hex encoding. >> >> The spec can define a handful of these for the most common hash >> algorithms and establish the pattern. New attributes for new >> algorithms can be added later. > > +1 >> >> Just seems simpler. >> >>> Alternatively, you could define a single, required hash_value encoding. >>> (Which wouldn't be too bad a thing to do.) Clearly, there should be a >>> registry of hash_algorithms as well as encodings (if supported). >>> In your blog post, you mention that clients might tend to rely on the value >>> returned by the Content-MD5 header. While this may be reasonable for HEAD >>> requests, clients should probably not trust the remote server when doing >>> GETs; they would be well advised to recompute the hash to ensure that the >>> remote server isn't lying about the hash (there are quite a number of >>> useful, but often deceitful, reasons why this might happen). Also, please >>> note that it should be possible to include a hash value which uses a >>> different hashing algorithm and encoding than is used by the Content-MD5 >>> implementation. Thus, for any particular web resource, we might have quite a >>> number of possible hash/encoding combinations and, in some cases, even have >>> two hashes available for a single GET (i.e. The Content-MD5 header value and >>> perhaps an SHA1/base64 hash specified in the link.) You might make a note >>> about some of these odd cases in your security considerations section. >>> bob wyman >>> On Wed, May 12, 2010 at 12:42 PM, James Snell wrote: >>>> >>>> Updated the Link Extensions Draft... >>>> >>>>  http://www.snellspace.com/wp/2010/05/atom-link-extensions/ >>>> >>>>  http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-03.txt >>>> >>>> - James >>>> >>>> On Tue, May 4, 2010 at 10:54 AM, Bob Wyman wrote: >>>> > I find that I have a real need for the "md5" Link rel mechanism defined >>>> > in >>>> > James Snell's old Atom Link Extensions draft or something functionally >>>> > equivalent. Basically, what I need to do is ensure that the "src" >>>> > attribute >>>> > on an atom.content element is pointing to a known version of a resource >>>> > rather than simply to any resource that has the same URL as in the src >>>> > attribute. I'm then going to sign the Atom entry that contains this "by >>>> > ref" >>>> > content element. >>>> > I've looked at the HTML5 RelExtentions Wiki but don't see anything there >>>> > that looks like it does the job. >>>> > Has anyone else needed hashed links in Atom? If so, what approach did >>>> > you >>>> > use to provide them? Is anyone aware of plans to introduce an "md5" or >>>> > equivalent attribute to the HTML5 list? >>>> > bob wyman >>>> > >>>> >>>> >>>> >>>> -- >>>> - James Snell >>>>  http://www.snellspace.com >>>>  jasnell@gmail.com >>> >>> >> >> >> >> -- >> - James Snell >>  http://www.snellspace.com >>  jasnell@gmail.com >> >> > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Wed May 12 20:57:22 2010 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 E86743A6992 for ; Wed, 12 May 2010 20:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.564 X-Spam-Level: X-Spam-Status: No, score=0.564 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DRUGS_MUSCLE=0.01, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBVPWaVDAReS for ; Wed, 12 May 2010 20:57:22 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 29DD33A6834 for ; Wed, 12 May 2010 20:57:21 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4D3p4rs078773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 20:51:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4D3p4pl078772; Wed, 12 May 2010 20:51:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4D3p3Go078765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 12 May 2010 20:51:04 -0700 (MST) (envelope-from rsalz@us.ibm.com) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o4D3d7A7029821 for ; Wed, 12 May 2010 23:39:07 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o4D3oxJG1376262 for ; Wed, 12 May 2010 23:51:02 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o4D3owNW005056 for ; Wed, 12 May 2010 23:50:59 -0400 Received: from D27ML602.RCHLAND.IBM.COM (d27ml602.rchland.ibm.com [9.10.229.17]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o4D3owjJ005050; Wed, 12 May 2010 23:50:58 -0400 In-Reply-To: References: To: James Snell Cc: Atom-Syntax MIME-Version: 1.0 Subject: Re: Link Extensions. Need "md5" or some kind of hash. X-KeepSent: 8D87FFBD:96E5765F-85257722:001410D7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Richard Salz Message-ID: Date: Wed, 12 May 2010 23:50:57 -0400 X-MIMETrack: Serialize by Router on d27ml602/27/M/IBM(Release 8.5.1FP2|March 17, 2010) at 05/12/2010 10:50:58 PM, Serialize complete at 05/12/2010 10:50:58 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > So the key question is: what are the main algorithms we need to > provide attributes for? This is a hard question to answer -- especially for hash/digest algorithms which tend to fall more rapidly than vetted crypto algorithms. It's more verbose, but I strongly recommend using a pair of attributes to represent algorithm/value. Use the URI's defined in the latest XML DSIG document, perhaps with the "trick" that relative URI's ar a shorthand for the xmldsig namespace. /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ From owner-atom-syntax@mail.imc.org Wed May 12 22:47:01 2010 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 9F6F03A6A36 for ; Wed, 12 May 2010 22:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQFMzrYgEp8s for ; Wed, 12 May 2010 22:46:53 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 8E8013A6A50 for ; Wed, 12 May 2010 22:46:11 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4D5fZeh085280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 22:41:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4D5fZPa085279; Wed, 12 May 2010 22:41:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4D5fYug085274 for ; Wed, 12 May 2010 22:41:35 -0700 (MST) (envelope-from peter.krantz@gmail.com) Received: by wyb39 with SMTP id 39so605134wyb.16 for ; Wed, 12 May 2010 22:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=SmtJ56TaGyqLh6DMrWcaG+esXyHHV2pMIrcYoBR92/M=; b=GIqw/qQsCqq8niJQw5jrKTcqIxayjzHujEJZIh/D3zlzObRUryNfaCTQwhQCgOQ57F UzD1Uw1brU8bF0OIdGnBBbE3TFO/yleKKd1knJ/oggb1SetpeSad3KtZpqG0uiNwVO50 coJseRM/rbFt+1X5CDJyUzTRh02lpsQiUcWZA= 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; b=evPQFLgsES/bVktIqBtBOvyMBGuQrPT5zUTO69pjRtcuueZNkcSl6jD0m7YInzvpCy jgWSsMihBKFc4ydWHulUT6Ldr+nRdMYD0xfaS1hw5S50x8QsQ3iCU7cMra+PgFiLQXW4 6k8uVvXzrvHfeVlx/5AYGbOFulE/eGh0f5I3M= MIME-Version: 1.0 Received: by 10.216.181.195 with SMTP id l45mr4586172wem.156.1273729292865; Wed, 12 May 2010 22:41:32 -0700 (PDT) Received: by 10.216.35.207 with HTTP; Wed, 12 May 2010 22:41:32 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 May 2010 07:41:32 +0200 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Peter Krantz To: Richard Salz Cc: James Snell , Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, May 13, 2010 at 05:50, Richard Salz wrote: > > It's more verbose, but I strongly recommend using a pair of attributes to > represent algorithm/value. > Yahoo has used the following construct in their Media RSS format [1]: "This is the hash of the binary media file. It can appear multiple times as long as each instance is a different algo. It has 1 optional attribute. dfdec888b72151965a34b4b59031290a algo indicates the algorithm used to create the hash. Possible values are 'md5' and 'sha-1'. Default value is 'md5'. It is an optional attribute." And the Metalink draft [2] is using this: a97fcf6ba9358f8a6f62beee4421863d3e52b080 [1]: http://video.search.yahoo.com/mrss [2]: http://tools.ietf.org/html/draft-bryan-metalink-28#section-4.2.4 Regards, Peter Krantz From owner-atom-syntax@mail.imc.org Wed May 12 22:47:51 2010 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 ABF963A6A6D for ; Wed, 12 May 2010 22:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.229 X-Spam-Level: * X-Spam-Status: No, score=1.229 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-alNkjlpbgF for ; Wed, 12 May 2010 22:47:50 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 77D3F3A6A36 for ; Wed, 12 May 2010 22:47:06 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4D5dLxJ085180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 22:39:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4D5dKkr085177; Wed, 12 May 2010 22:39:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.221.179]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4D5dKiR085171 for ; Wed, 12 May 2010 22:39:20 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk9 with SMTP id 9so1161780qyk.2 for ; Wed, 12 May 2010 22:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u+fAnu5eGZ7G/RJqrSG9FhlDJ+vgwTtcAWVkwQd2WgE=; b=tTJ8ig7gaSE/sls82k2b0vlCKZv5kMZM+o5mh5mMOnVUzQzP44PCGMyZtVCtu4hH1Y tqa5vKsXWDrD/NL+0PE8ZxSvs1ZiPlebnlpH32WDBAFkV4c8HMjMTiwfyA+aiXnns0aD 7B4t5try8+5qzVr26YodmNsDAQDtRQII8G2k8= 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=FZEnzmBbdkYKkzkVg1F/maPT47c+1be0MZLymWpZJLoFYYPDLpozpTr6tUpqRE32yq exOmsDPVRcbROHG/58MlXmo8hFRfEcrAMktV+2k0k1BVr5fGZNhFqlQHT3ZEmdTTByT6 tx3Kxe7UpZEv3KxEpqmqUTytbLL14WUYOofdI= MIME-Version: 1.0 Received: by 10.229.223.130 with SMTP id ik2mr1307165qcb.107.1273729158866; Wed, 12 May 2010 22:39:18 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Wed, 12 May 2010 22:39:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 May 2010 22:39:18 -0700 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: James Snell To: Peter Keane Cc: Bob Wyman , Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4D5dKiR085173 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Updated draft... http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-04.txt - James On Wed, May 12, 2010 at 5:53 PM, James Snell wrote: > So the key question is: what are the main algorithms we need to > provide attributes for? > > - James > > On Wed, May 12, 2010 at 2:41 PM, Peter Keane wrote: >> On Wed, May 12, 2010 at 4:10 PM, James Snell wrote: >>> >>> On Wed, May 12, 2010 at 12:53 PM, Bob Wyman wrote: >>>> James, thanks for updating and revising this draft! >>>> I would strongly encourage you to make the markup more expressive and >>>> flexible by supporting "a generic hash attribute with an internal structure >>>> for specifying algorithm and value". Actually, I would suggest that you >>>> extend this a bit further to include a specification of the encoding for the >>>> hash value.Thus, I would suggest the following pattern: >>>> >>>> hash_algorithm.encoding.hash_value >>>> >>> >>> Hmm... for me, this immediately starts screaming overkill. I'd almost >>> prefer to go the route of defining individual attributes for each hash >>> algorithm... e.g. >>> >>>  md5="..." >>>  sha256="..." >>> >>> Each using the basic hex encoding. >>> >>> The spec can define a handful of these for the most common hash >>> algorithms and establish the pattern. New attributes for new >>> algorithms can be added later. >> >> +1 >>> >>> Just seems simpler. >>> >>>> Alternatively, you could define a single, required hash_value encoding. >>>> (Which wouldn't be too bad a thing to do.) Clearly, there should be a >>>> registry of hash_algorithms as well as encodings (if supported). >>>> In your blog post, you mention that clients might tend to rely on the value >>>> returned by the Content-MD5 header. While this may be reasonable for HEAD >>>> requests, clients should probably not trust the remote server when doing >>>> GETs; they would be well advised to recompute the hash to ensure that the >>>> remote server isn't lying about the hash (there are quite a number of >>>> useful, but often deceitful, reasons why this might happen). Also, please >>>> note that it should be possible to include a hash value which uses a >>>> different hashing algorithm and encoding than is used by the Content-MD5 >>>> implementation. Thus, for any particular web resource, we might have quite a >>>> number of possible hash/encoding combinations and, in some cases, even have >>>> two hashes available for a single GET (i.e. The Content-MD5 header value and >>>> perhaps an SHA1/base64 hash specified in the link.) You might make a note >>>> about some of these odd cases in your security considerations section. >>>> bob wyman >>>> On Wed, May 12, 2010 at 12:42 PM, James Snell wrote: >>>>> >>>>> Updated the Link Extensions Draft... >>>>> >>>>>  http://www.snellspace.com/wp/2010/05/atom-link-extensions/ >>>>> >>>>>  http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-03.txt >>>>> >>>>> - James >>>>> >>>>> On Tue, May 4, 2010 at 10:54 AM, Bob Wyman wrote: >>>>> > I find that I have a real need for the "md5" Link rel mechanism defined >>>>> > in >>>>> > James Snell's old Atom Link Extensions draft or something functionally >>>>> > equivalent. Basically, what I need to do is ensure that the "src" >>>>> > attribute >>>>> > on an atom.content element is pointing to a known version of a resource >>>>> > rather than simply to any resource that has the same URL as in the src >>>>> > attribute. I'm then going to sign the Atom entry that contains this "by >>>>> > ref" >>>>> > content element. >>>>> > I've looked at the HTML5 RelExtentions Wiki but don't see anything there >>>>> > that looks like it does the job. >>>>> > Has anyone else needed hashed links in Atom? If so, what approach did >>>>> > you >>>>> > use to provide them? Is anyone aware of plans to introduce an "md5" or >>>>> > equivalent attribute to the HTML5 list? >>>>> > bob wyman >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> - James Snell >>>>>  http://www.snellspace.com >>>>>  jasnell@gmail.com >>>> >>>> >>> >>> >>> >>> -- >>> - James Snell >>>  http://www.snellspace.com >>>  jasnell@gmail.com >>> >>> >> > > > > -- > - James Snell >  http://www.snellspace.com >  jasnell@gmail.com > -- - James Snell http://www.snellspace.com jasnell@gmail.com From atompub-archive@megatron.ietf.org Wed May 12 22:54:44 2010 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 BEFAF3A6A62 for ; Wed, 12 May 2010 22:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.414 X-Spam-Level: X-Spam-Status: No, score=-13.414 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_XBL=3.033, 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 v6+MHhtfVY1T for ; Wed, 12 May 2010 22:54:43 -0700 (PDT) Received: from nas01-040.telekom.net.sb (nas01-040.telekom.net.sb [202.1.170.40]) by core3.amsl.com (Postfix) with SMTP id 868E33A6A50 for ; Wed, 12 May 2010 22:53:24 -0700 (PDT) From: RX-Store Subject: Please Read To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100513055327.868E33A6A50@core3.amsl.com> Date: Wed, 12 May 2010 22:53:24 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://rosebreak.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 88192 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 24054 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 41079 is unauthorized. 36624

From atompub-archive@megatron.ietf.org Wed May 12 23:27:37 2010 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 2CDE73A6A36 for ; Wed, 12 May 2010 23:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.865 X-Spam-Level: X-Spam-Status: No, score=-9.865 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_XBL=3.033, RDNS_NONE=0.1, 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 So1koncl-lqd for ; Wed, 12 May 2010 23:27:36 -0700 (PDT) Received: from agisweb.nl (unknown [115.108.121.11]) by core3.amsl.com (Postfix) with SMTP id B0ADF3A69F9 for ; Wed, 12 May 2010 23:27:33 -0700 (PDT) From: RX-Store Subject: New Private Message for atompub-archive@megatron.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100513062734.B0ADF3A69F9@core3.amsl.com> Date: Wed, 12 May 2010 23:27:33 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://rosebreak.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 08264 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 33124 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 90445 is unauthorized. 10241

From owner-atom-syntax@mail.imc.org Wed May 12 23:30:13 2010 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 22D063A6A77 for ; Wed, 12 May 2010 23:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8qnMJi3KpCr for ; Wed, 12 May 2010 23:30:12 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 156F63A6A5D for ; Wed, 12 May 2010 23:30:08 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4D6Jx5e087534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 23:19:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4D6JxMc087533; Wed, 12 May 2010 23:19:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4D6JwqQ087528 for ; Wed, 12 May 2010 23:19:58 -0700 (MST) (envelope-from peter.krantz@gmail.com) Received: by wyb39 with SMTP id 39so616385wyb.16 for ; Wed, 12 May 2010 23:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=eW5U2sJIM0CVlTED3DhKZx/m8lUq7g+dxTmCrFKhT6Y=; b=VZruddBIWNE91OMQBOa+m6pFrPg9ttqqYWySSU/hinog1WF9FbKHhu6YrJEqXGesGb cyUvxlOEuZftWekJARzFe22NqJP0tWNJTi/7NLQOidcTkk+R1wHuNZyF+QeqdkkA3wAf neJDSQhdyxz5yUheI2cjFLGeYxq/C9t0R3GLY= 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; b=i/OSc3CPaXO3y6N4Y+h+KeD7kJRLfLjxjhOQk//jAkgOB+YH0dOyzPpBJoPJU2NRsz ogjY5AWFYxdob2vZUOhLg0qbNzMeKA1lunaBzi44yvuPt1FCWG0T6RL4K1nZOQfLuWN1 E3Ob5+fibQcpLzbPLNK6h1nFsgd/7x7Q3cVRs= MIME-Version: 1.0 Received: by 10.216.160.206 with SMTP id u56mr4840764wek.196.1273731596352; Wed, 12 May 2010 23:19:56 -0700 (PDT) Received: by 10.216.35.207 with HTTP; Wed, 12 May 2010 23:19:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 May 2010 08:19:56 +0200 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Peter Krantz To: James Snell Cc: Peter Keane , Bob Wyman , Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, May 13, 2010 at 07:39, James Snell wrote: > > Updated draft... > Looks good! If I understand this correctly it enables multiple hashes for the same file, e.g. This could enable publishers to provide more information about a file. Does the spec need to say something about how to interpret multiple hashes in case one of them is wrong? Or maybe that is up to the individual use case? Regards, Peter Krantz From atompub-archive@lists.ietf.org Thu May 13 05:47:42 2010 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 503CA3A6B54 for ; Thu, 13 May 2010 05:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.746 X-Spam-Level: X-Spam-Status: No, score=-11.746 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, 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 ayfr1X88Zafg for ; Thu, 13 May 2010 05:47:41 -0700 (PDT) Received: from 33.asp070.com (unknown [189.104.208.71]) by core3.amsl.com (Postfix) with SMTP id 6C33C3A6AA6 for ; Thu, 13 May 2010 05:43:01 -0700 (PDT) From: RX-Store Subject: Special Code for 76% for atompub-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100513124302.6C33C3A6AA6@core3.amsl.com> Date: Thu, 13 May 2010 05:43:01 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://rosebreak.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 16305 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 32348 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 33865 is unauthorized. 59624

From owner-atom-syntax@mail.imc.org Thu May 13 07:41:19 2010 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 EC1243A6B65 for ; Thu, 13 May 2010 07:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STyDcPwwiFwO for ; Thu, 13 May 2010 07:41:19 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 251923A6B5F for ; Thu, 13 May 2010 07:41:19 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4DEa0fq020566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 May 2010 07:36:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4DEa03J020564; Thu, 13 May 2010 07:36:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4DEZvw0020554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 May 2010 07:35:59 -0700 (MST) (envelope-from ddooss@wp.pl) Received: (wp-smtpd smtp.wp.pl 10892 invoked from network); 13 May 2010 16:35:52 +0200 Received: from 87-205-159-240.adsl.inetia.pl (HELO [192.168.1.1]) (ddooss@[87.205.159.240]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 13 May 2010 16:35:52 +0200 Message-ID: <4BEC0E48.3000301@wp.pl> Date: Thu, 13 May 2010 16:35:52 +0200 From: Dominik Tomaszuk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Shredder/3.0.3pre MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Link Extensions. Need "md5" or some kind of hash. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [UbID] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 13.05.2010 07:39, James Snell wrote: > > Updated draft... > > http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-04.txt It is: sha224 = attribute sha224 { sha1-digest } - section 3.4 sha256 = attribute sha256 { sha1-digest } - section 3.5 sha384 = attribute sha384 { sha1-digest } - section 3.6 sha512 = attribute sha512 { sha1-digest } - section 3.7 I think it should be: sha224 = attribute sha224 { sha224-digest } sha256 = attribute sha256 { sha256-digest } sha384 = attribute sha384 { sha384-digest } sha512 = attribute sha512 { sha512-digest } Regards, Dominik Tomaszuk From owner-atom-syntax@mail.imc.org Thu May 13 07:41:35 2010 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 9D4533A6B5F for ; Thu, 13 May 2010 07:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+Th6yDRhyWj for ; Thu, 13 May 2010 07:41:34 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 520043A69A9 for ; Thu, 13 May 2010 07:41:34 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4DEaVaR020611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 May 2010 07:36:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4DEaV7M020610; Thu, 13 May 2010 07:36:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4DEaSGQ020605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 May 2010 07:36:30 -0700 (MST) (envelope-from ddooss@wp.pl) Received: (wp-smtpd smtp.wp.pl 13880 invoked from network); 13 May 2010 16:36:25 +0200 Received: from 87-205-159-240.adsl.inetia.pl (HELO [192.168.1.1]) (ddooss@[87.205.159.240]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 13 May 2010 16:36:25 +0200 Message-ID: <4BEC0E69.5000503@wp.pl> Date: Thu, 13 May 2010 16:36:25 +0200 From: Dominik Tomaszuk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Shredder/3.0.3pre MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Link Extensions. Need "md5" or some kind of hash. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [EXJD] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 13.05.2010 07:39, James Snell wrote: > > Updated draft... > > http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-04.txt What about other hash functions: GOST [1] Whirlpool [2] MD4 [3] CRC32 Also to consider: HAVAL (variant 128/160/192/224/256) [4] Tiger (variant 128/160/192) [5] [1] http://tools.ietf.org/html/rfc5831 [2] ISO/IEC 10118-3:2004 - http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39876 [3] http://tools.ietf.org/html/rfc1320 [4] http://labs.calyptix.com/haval.php [5] http://www.cs.technion.ac.il/~biham/Reports/Tiger/tiger/tiger.html Regards, Dominik Tomaszuk From owner-atom-syntax@mail.imc.org Fri May 14 12:12:45 2010 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 9212028C134 for ; Fri, 14 May 2010 12:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.919 X-Spam-Level: X-Spam-Status: No, score=0.919 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_50=0.001, DRUGS_MUSCLE=0.01, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggjDFgrS8Htm for ; Fri, 14 May 2010 12:12:44 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 4F0F63A6ADC for ; Fri, 14 May 2010 12:12:44 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4EJ6WVE012364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 12:06:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4EJ6WkQ012363; Fri, 14 May 2010 12:06:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4EJ6URo012357 for ; Fri, 14 May 2010 12:06:30 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by vws15 with SMTP id 15so2304563vws.16 for ; Fri, 14 May 2010 12:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mepQWn61dW9Q+oz1lPVFDIC90B5VAkn8G/ClVDflXIA=; b=mgbi4tiOK2EwZPPpHqcFA5ABqrjRO7UzyYw0wvuEdERqHahldK5+uawnAoN8OTQXsI 5DJ6vIzrdbCluNqU63skH/DaiYRRSM/AqPmxX6L450jWH9rkcG5fGDs5m34ZSVZQeAby 366W2wMaJS7YWX1ry9ZL5GNISWhBQh3kR+mD8= 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=ueKT8qMRwAyS/ng5gVPG1HxknqfPWirMmX56i3rKh/H2Y6E1WKceyX/poTf+fx13yy y1Xb6DG1RjYBze4Y8kMDHITPAGhyfsKGn7doAZVbz/R1MfSiiqsXfvxuYlM/4TMOlc66 evuEhyFH2jFLZQOY3Z/H3dbzs0TMg/1pPuBxA= MIME-Version: 1.0 Received: by 10.229.215.137 with SMTP id he9mr450566qcb.131.1273863989376; Fri, 14 May 2010 12:06:29 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Fri, 14 May 2010 12:06:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 May 2010 12:06:29 -0700 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: James Snell To: Richard Salz Cc: Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4EJ6URo012359 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ok, I've been giving this some more thought and I think a hybrid approach works very well. As has been pointed out a number of times in this thread, there are existing elements in other namespaces that provide a algorithm/hash pairing. I think that the Link Extensions Draft can provide a attributes for the most basic hash algorithms and applications that require hash algorithms that are not covered can fall back to the extension elements. e.g. 123...456 This would allow for the most common cases to be easily covered while allowing for the full range of possible cases to be handled as well. - James On Wed, May 12, 2010 at 8:50 PM, Richard Salz wrote: >> So the key question is: what are the main algorithms we need to >> provide attributes for? > > This is a hard question to answer -- especially for hash/digest algorithms > which tend to fall more rapidly than vetted crypto algorithms. > > It's more verbose, but I strongly recommend using a pair of attributes to > represent algorithm/value. Use the URI's defined in the latest XML DSIG > document, perhaps with the "trick" that relative URI's ar a shorthand for > the xmldsig namespace. > >        /r$ > > -- > STSM, WebSphere Appliance Architect > https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Fri May 14 13:32:44 2010 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 2C3DA3A684B for ; Fri, 14 May 2010 13:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9B4l5J-OjIg for ; Fri, 14 May 2010 13:32:43 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 05A9B3A6403 for ; Fri, 14 May 2010 13:32:42 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4EKS9qt016219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 13:28:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4EKS9RY016218; Fri, 14 May 2010 13:28:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4EKS60v016212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 14 May 2010 13:28:08 -0700 (MST) (envelope-from ddooss@wp.pl) Received: (wp-smtpd smtp.wp.pl 22685 invoked from network); 14 May 2010 22:28:03 +0200 Received: from 87-205-159-240.adsl.inetia.pl (HELO [192.168.1.1]) (ddooss@[87.205.159.240]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 14 May 2010 22:28:03 +0200 Message-ID: <4BEDB253.4080703@wp.pl> Date: Fri, 14 May 2010 22:28:03 +0200 From: Dominik Tomaszuk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Shredder/3.0.3pre MIME-Version: 1.0 To: James Snell CC: Richard Salz , Atom-Syntax Subject: Re: Link Extensions. Need "md5" or some kind of hash. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [EbIz] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 14.05.2010 21:06, James Snell wrote: > Ok, I've been giving this some more thought and I think a hybrid > approach works very well. As has been pointed out a number of times in > this thread, there are existing elements in other namespaces that > provide a algorithm/hash pairing. I think that the Link Extensions > Draft can provide a attributes for the most basic hash algorithms and > applications that require hash algorithms that are not covered can > fall back to the extension elements. Which algorithms will be supported by the elements and which by the attributes? Who decides which hash are basic? My proposals: 1. attributes with URN e.g. 2. attributes with CURIE [1] e.g. 3. elements with hash and algorithm e.g. abc..xyz 4. one attribute to one hash Proposal 1 is short. Proposal 2 is my choice, because it is expandable. Proposal 3 and 4 are modification of a hybrid approach (I propose them because I think that it should not be two method to represent hashes in link). [1] http://www.w3.org/TR/curie/ Regards, Dominik Tomaszuk From owner-atom-syntax@mail.imc.org Fri May 14 13:35:46 2010 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 7DF6E3A68BE for ; Fri, 14 May 2010 13:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.582 X-Spam-Level: * X-Spam-Status: No, score=1.582 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_50=0.001, DRUGS_MUSCLE=0.01, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=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 QuAekSi+Eoge for ; Fri, 14 May 2010 13:35:40 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 71DA33A684B for ; Fri, 14 May 2010 13:35:40 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4EKQPij016145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 13:26:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4EKQPou016144; Fri, 14 May 2010 13:26:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4EKQOVZ016138 for ; Fri, 14 May 2010 13:26:24 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by yxe9 with SMTP id 9so1983857yxe.29 for ; Fri, 14 May 2010 13:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=YQ7lmTvQeeBQrkbgTXTU9WFbZWf1hEOH9/3EMtuRLSo=; b=Bjfcgd5wZYXtIQwfqiprjtsUs4Smq8OOcL8GJy7PIsUBEeCfngArN6wlLZc4Y8lSoL sX25sqPPMVOytMWx3h4H39IO8d9HB2eot6O/b0ZocFmy2i1PSSYjyaRZKF0HGmIwzjHY dr/1LT1U6CEuS0AcaUL9O/mj6UBzRrV661H58= 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=FYk3phTMH/PTRnclRI9J/UzW1KVZv2hOsrgwiAQTi47nGVkWCdCYDhYoeMfX4n/Xqp nrsKdRSOOH84t2vpBfTCHOMxk5yra/w1rZZY/4KQZS6iie5MYwLgfIMQTMFCyKy1ywPi vbht7avCgrYhyXFtLmE0Oqc4h3aXFn/fcoVsY= MIME-Version: 1.0 Received: by 10.101.178.25 with SMTP id f25mr2038282anp.198.1273868783870; Fri, 14 May 2010 13:26:23 -0700 (PDT) Received: by 10.100.154.20 with HTTP; Fri, 14 May 2010 13:26:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 May 2010 16:26:23 -0400 X-Google-Sender-Auth: ZVnEaow7uzlaQfw58pUduMKoiL8 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Bob Wyman To: James Snell Cc: Richard Salz , Atom-Syntax Content-Type: multipart/alternative; boundary=001636c9256d5a6a39048693b012 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636c9256d5a6a39048693b012 Content-Type: text/plain; charset=ISO-8859-1 James Snell wrote: > > 123...456 > The alternative approach, which would support both a variety and multiplicity of hashes would look like this: This strikes me as "simpler" than the hybrid approach. Just a few of my concerns with the proposed "hybrid" approach follow: - I like binding the algorithm and value together into a single value since I know of no compelling case for processing one element in isolation of the other. The hash value only makes sense if you know the algorithm and the algorithm is only useful when bound to a specific hash value. Thus, it strikes me as simply introducing syntactic sugar to specify the algorithm using a different XML component than the value. - These values are likely to be stored in databases and otherwise manipulated. In all cases, for the data to be meaningful, people will need to keep the binding between algorithm and hash value. It is likely that storing a single string value is going to be easier for folk than dealing with a multi-part value. Also, consider the effect of parsers... It is likely that in order to transfer a value from an entry into a database field, what you'll need to do is extract both algorithm and hash value from the parse tree and then construct some string that combines them. This would be particularly useful if you want to use the hash value as a database key (a very reasonable thing to do...) You could build and store the string "algo='GOST'>123...455<" or your database might support concatenated fields, or you could build "gost.123...456". I think I would go with the latter. - Defining distinct attributes for each hash algorithm pushes unnecessary syntactical complexity to the global level and thus increases the complexity not only of the specification but also of all applications no matter which algorithms they understand or if they understand any at all. It also makes extending the list of supported algorithms "expensive" since such extensions require modification to the standard rather than just an registry entry.What benefit do we get from having these algorithm types defined at the global syntax level? - The hybrid approach looks very complicated to me. It means that I'll have two very different places in which hash values might found and two very different syntaxes for expressing them. The result is going to be more complex code than would otherwise be the case. What value comes from using the hybrid approach? - One argument for hybrid is that these elements exist already in other specs. I wonder if it isn't possible that those other specs might have approached the problem in a non-optimal fashion. Does it really make sense to import syntax if there isn't a really good case that demonstrates that doing so is the best approach? - I am unaware of any hash algorithms that need anything other than the specification of the algorithm and the value in order to be useful. If there were broadly used algorithms that had more complex meta-data requirements, it would be easier to understand the appeal of the hybrid approach. - I can't think of any reason why it is *useful* to separate the algorithm from the hash value. Can someone enlighten me here? What computation, storage or communication task becomes easier if you have these two separated? bob wyman On Fri, May 14, 2010 at 3:06 PM, James Snell wrote: > > Ok, I've been giving this some more thought and I think a hybrid > approach works very well. As has been pointed out a number of times in > this thread, there are existing elements in other namespaces that > provide a algorithm/hash pairing. I think that the Link Extensions > Draft can provide a attributes for the most basic hash algorithms and > applications that require hash algorithms that are not covered can > fall back to the extension elements. > > e.g. > > > 123...456 > > > This would allow for the most common cases to be easily covered while > allowing for the full range of possible cases to be handled as well. > > - James > > On Wed, May 12, 2010 at 8:50 PM, Richard Salz wrote: > >> So the key question is: what are the main algorithms we need to > >> provide attributes for? > > > > This is a hard question to answer -- especially for hash/digest > algorithms > > which tend to fall more rapidly than vetted crypto algorithms. > > > > It's more verbose, but I strongly recommend using a pair of attributes to > > represent algorithm/value. Use the URI's defined in the latest XML DSIG > > document, perhaps with the "trick" that relative URI's ar a shorthand for > > the xmldsig namespace. > > > > /r$ > > > > -- > > STSM, WebSphere Appliance Architect > > https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ > > > > > > > > -- > - James Snell > http://www.snellspace.com > jasnell@gmail.com > > --001636c9256d5a6a39048693b012 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
James Snell=A0<jasnell@gmail.com>=A0wrote:
> <link href= =3D"foo" md5=3D"abc...xyz">
> =A0<media:has= h algo=3D"GOST">123...456</media:hash>
> </link>

The alternative approach, which = would support both a variety and=A0multiplicity of hashes=A0would look like= this:

<link href=3D"foo" hash=3D"gost= :123123..., md5:0928402948..., sha256:098078097..."/>

This strikes me as "simpler" than the hybrid = approach. Just a few of my concerns with the proposed "hybrid" ap= proach follow:
  • I like binding the algorithm and value tog= ether into a single value since I know of no compelling case for processing= one element in isolation of the other. The hash value only makes sense if = you know the algorithm and the algorithm is only useful when bound to a spe= cific hash value. Thus, it strikes me as simply introducing syntactic sugar= to specify the algorithm using a different XML component than the value.
  • These values are likely to be stored in databases and otherwise manipul= ated. In all cases, for the data to be meaningful, people will need to keep= the binding between algorithm and hash value. It is likely that storing a = single string value is going to be easier for folk than dealing with a mult= i-part value. Also, consider the effect of parsers... It is likely that in = order to transfer a value from an entry into a database field, what you'= ;ll need to do is extract both algorithm and hash value from the parse tree= and then construct some string that combines them. This would be particula= rly useful if you want to use the hash value as a database key (a very reas= onable thing to do...) You could build and store the string "algo=3D&#= 39;GOST'>123...455<" or your database might support concaten= ated fields, or you could build "gost.123...456". I think I would= go with the latter.
  • Defining distinct attributes for each hash algorithm pushes unnecessary= syntactical complexity to the global level and thus increases the complexi= ty not only of the specification but also of all applications no matter whi= ch algorithms they understand or if they understand any at all. It also mak= es extending the list of supported algorithms "expensive" since s= uch extensions require modification to the standard rather than just an reg= istry entry.What benefit do we get from having these algorithm types define= d at the global syntax level?
  • The hybrid approach looks very complicated to me. It means that I'l= l have two very different places in which hash values might found and two v= ery different syntaxes for expressing them. The result is going to be more = complex code than would otherwise be the case. What value comes from using = the hybrid approach?
  • One argument for hybrid is that these elements exist already in other s= pecs. I wonder if it isn't possible that those other specs might have a= pproached the problem in a non-optimal fashion. Does it really make sense t= o import syntax if there isn't a really good case that demonstrates tha= t doing so is the best approach?
  • I am unaware of any hash algorithms that need anything other than the s= pecification of the algorithm and the value in order to be useful. If there= were broadly used algorithms that had more complex meta-data requirements,= it would be easier to understand the appeal of the hybrid approach.
  • I can't think of any reason why it is *useful* to separate the algo= rithm from the hash value. Can someone enlighten me here? What computation,= storage or communication task becomes easier if you have these two separat= ed?
bob wyman

On Fri, May 14, 201= 0 at 3:06 PM, James Snell <jasnell@gmail.com> wrote:

Ok, I've been giving this some more thought and I think a hybrid
approach works very well. As has been pointed out a number of times in
this thread, there are existing elements in other namespaces that
provide a algorithm/hash pairing. I think that the Link Extensions
Draft can provide a attributes for the most basic hash algorithms and
applications that require hash algorithms that are not covered can
fall back to the extension elements.

e.g.

<link href=3D"foo" md5=3D"abc...xyz">
=A0<media:hash algo=3D"GOST">123...456</media:hash><= br> </link>

This would allow for the most common cases to be easily covered while
allowing for the full range of possible cases to be handled as well.

- James

On Wed, May 12, 2010 at 8:50 PM, Richard Salz <rsalz@us.ibm.com> wrote:
>> So the key question is: what are the main algorithms we need to >> provide attributes for?
>
> This is a hard question to answer -- especially for hash/digest algori= thms
> which tend to fall more rapidly than vetted crypto algorithms.
>
> It's more verbose, but I strongly recommend using a pair of attrib= utes to
> represent algorithm/value. Use the URI's defined in the latest XML= DSIG
> document, perhaps with the "trick" that relative URI's a= r a shorthand for
> the xmldsig namespace.
>
> =A0 =A0 =A0 =A0/r$
>
> --
> STSM, WebSphere Appliance Architect
> https://www.ibm.com/developerworks/mydeveloperworks= /blogs/soma/
>
>



--

--001636c9256d5a6a39048693b012-- From owner-atom-syntax@mail.imc.org Fri May 14 14:03:13 2010 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 8A71F3A6888 for ; Fri, 14 May 2010 14:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 122-YWJqOVmt for ; Fri, 14 May 2010 14:03:12 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CD9283A6811 for ; Fri, 14 May 2010 14:03:12 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4EKx5XI017407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 13:59:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4EKx55K017406; Fri, 14 May 2010 13:59:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4EKx2BD017393 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Fri, 14 May 2010 13:59:04 -0700 (MST) (envelope-from ddooss@wp.pl) Received: (wp-smtpd smtp.wp.pl 27881 invoked from network); 14 May 2010 22:58:59 +0200 Received: from 87-205-159-240.adsl.inetia.pl (HELO [192.168.1.1]) (ddooss@[87.205.159.240]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 14 May 2010 22:58:59 +0200 Message-ID: <4BEDB993.1030203@wp.pl> Date: Fri, 14 May 2010 22:58:59 +0200 From: Dominik Tomaszuk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Shredder/3.0.3pre MIME-Version: 1.0 To: Bob Wyman CC: James Snell , Richard Salz , Atom-Syntax Subject: Re: Link Extensions. Need "md5" or some kind of hash. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [EYLT] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 14.05.2010 22:26, Bob Wyman wrote: > I improve this proposal to 'hash: URI scheme': Regards, Dominik Tomaszuk From owner-atom-syntax@mail.imc.org Fri May 14 14:19:18 2010 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 C9DEF3A68EE for ; Fri, 14 May 2010 14:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.86 X-Spam-Level: X-Spam-Status: No, score=0.86 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_50=0.001, DRUGS_MUSCLE=0.01, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woe89ZmZ6EMc for ; Fri, 14 May 2010 14:19:14 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9FF5A3A67E3 for ; Fri, 14 May 2010 14:19:14 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4ELFU21018129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 14:15:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4ELFURJ018128; Fri, 14 May 2010 14:15:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4ELFTYY018122 for ; Fri, 14 May 2010 14:15:30 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by vws15 with SMTP id 15so2424909vws.16 for ; Fri, 14 May 2010 14:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JpxzDXS1dq9F2yp+9bE2EldlCPPcv2Hu401J4HgchXE=; b=MzBxA/JFFG/yCVFVlLQfPFCqga9Fr7t/8BkF+SQF0wD4qeBcXe0CTUU2xaYsDKXs0D 0VbD5NHa1gu4WbyQrKOl4FjI2JDNKP9zbbxK4uOjdgr8RqvDPXstkqEcMKWaY37B1Fno Y7t5E/FOePv+zM/WErGzBXuAmQS2oqHx+HD3E= 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=QU8trSj6KDfNoeosdRzw9cbgQc6ZuYHq+LJhnhdVPnWXrR8uCCGwPFrCR3mh4aItIu Q+mPnAs3Bixs8doNXzPBw54MpEneOPlJZwCpFqMnxwXXqe4hTdJEh9VqvE3Xif5wSnog jAnbU3JvMBlzfaFf9RAWNxZRXjpyuXKvJMfxY= MIME-Version: 1.0 Received: by 10.229.238.17 with SMTP id kq17mr499484qcb.40.1273871728754; Fri, 14 May 2010 14:15:28 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Fri, 14 May 2010 14:15:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 May 2010 14:15:28 -0700 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: James Snell To: Bob Wyman Cc: Richard Salz , Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4ELFUYY018124 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Good argument Bob... ok... stewing over this a bit more. I generally dislike having to do additional parsing of attribute/element values but there are very good reasons for keeping this as a single "hash" attribute and you make a compelling case. On Fri, May 14, 2010 at 1:26 PM, Bob Wyman wrote: > James Snell  wrote: >> >>  123...456 >> > > The alternative approach, which would support both a variety > and multiplicity of hashes would look like this: > > This strikes me as "simpler" than the hybrid approach. Just a few of my > concerns with the proposed "hybrid" approach follow: > > I like binding the algorithm and value together into a single value since I > know of no compelling case for processing one element in isolation of the > other. The hash value only makes sense if you know the algorithm and the > algorithm is only useful when bound to a specific hash value. Thus, it > strikes me as simply introducing syntactic sugar to specify the algorithm > using a different XML component than the value. > These values are likely to be stored in databases and otherwise manipulated. > In all cases, for the data to be meaningful, people will need to keep the > binding between algorithm and hash value. It is likely that storing a single > string value is going to be easier for folk than dealing with a multi-part > value. Also, consider the effect of parsers... It is likely that in order to > transfer a value from an entry into a database field, what you'll need to do > is extract both algorithm and hash value from the parse tree and then > construct some string that combines them. This would be particularly useful > if you want to use the hash value as a database key (a very reasonable thing > to do...) You could build and store the string "algo='GOST'>123...455<" or > your database might support concatenated fields, or you could build > "gost.123...456". I think I would go with the latter. > Defining distinct attributes for each hash algorithm pushes unnecessary > syntactical complexity to the global level and thus increases the complexity > not only of the specification but also of all applications no matter which > algorithms they understand or if they understand any at all. It also makes > extending the list of supported algorithms "expensive" since such extensions > require modification to the standard rather than just an registry entry.What > benefit do we get from having these algorithm types defined at the global > syntax level? > The hybrid approach looks very complicated to me. It means that I'll have > two very different places in which hash values might found and two very > different syntaxes for expressing them. The result is going to be more > complex code than would otherwise be the case. What value comes from using > the hybrid approach? > One argument for hybrid is that these elements exist already in other specs. > I wonder if it isn't possible that those other specs might have approached > the problem in a non-optimal fashion. Does it really make sense to import > syntax if there isn't a really good case that demonstrates that doing so is > the best approach? > I am unaware of any hash algorithms that need anything other than the > specification of the algorithm and the value in order to be useful. If there > were broadly used algorithms that had more complex meta-data requirements, > it would be easier to understand the appeal of the hybrid approach. > I can't think of any reason why it is *useful* to separate the algorithm > from the hash value. Can someone enlighten me here? What computation, > storage or communication task becomes easier if you have these two > separated? > > bob wyman > On Fri, May 14, 2010 at 3:06 PM, James Snell wrote: >> >> Ok, I've been giving this some more thought and I think a hybrid >> approach works very well. As has been pointed out a number of times in >> this thread, there are existing elements in other namespaces that >> provide a algorithm/hash pairing. I think that the Link Extensions >> Draft can provide a attributes for the most basic hash algorithms and >> applications that require hash algorithms that are not covered can >> fall back to the extension elements. >> >> e.g. >> >> >>  123...456 >> >> >> This would allow for the most common cases to be easily covered while >> allowing for the full range of possible cases to be handled as well. >> >> - James >> >> On Wed, May 12, 2010 at 8:50 PM, Richard Salz wrote: >> >> So the key question is: what are the main algorithms we need to >> >> provide attributes for? >> > >> > This is a hard question to answer -- especially for hash/digest >> > algorithms >> > which tend to fall more rapidly than vetted crypto algorithms. >> > >> > It's more verbose, but I strongly recommend using a pair of attributes >> > to >> > represent algorithm/value. Use the URI's defined in the latest XML DSIG >> > document, perhaps with the "trick" that relative URI's ar a shorthand >> > for >> > the xmldsig namespace. >> > >> >        /r$ >> > >> > -- >> > STSM, WebSphere Appliance Architect >> > https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ >> > >> > >> >> >> >> -- >> - James Snell >>  http://www.snellspace.com >>  jasnell@gmail.com >> > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Fri May 14 14:22:36 2010 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 0F32E3A67E7 for ; Fri, 14 May 2010 14:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.846 X-Spam-Level: * X-Spam-Status: No, score=1.846 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, MISSING_HEADERS=1.292] 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 pIKDws0RjgOX for ; Fri, 14 May 2010 14:22:35 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id BAF3A3A67E3 for ; Fri, 14 May 2010 14:22:34 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4ELIeqU018248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 14:18:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4ELIerP018247; Fri, 14 May 2010 14:18:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4ELIeFX018242 for ; Fri, 14 May 2010 14:18:40 -0700 (MST) (envelope-from mart@degeneration.co.uk) Received: by ywh15 with SMTP id 15so1622373ywh.27 for ; Fri, 14 May 2010 14:18:39 -0700 (PDT) Received: by 10.101.132.8 with SMTP id j8mr1909998ann.117.1273871918907; Fri, 14 May 2010 14:18:38 -0700 (PDT) Received: from [192.168.64.227] ([204.9.180.30]) by mx.google.com with ESMTPS id a18sm2505312anl.13.2010.05.14.14.18.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 May 2010 14:18:38 -0700 (PDT) Message-ID: <4BEDBE2B.2050001@degeneration.co.uk> Date: Fri, 14 May 2010 14:18:35 -0700 From: Martin Atkins User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 CC: Atom-Syntax Subject: Re: Link Extensions. Need "md5" or some kind of hash. References: 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: On 05/14/2010 01:26 PM, Bob Wyman wrote: > James Snell > wrote: > > > > 123...456 > > > > The alternative approach, which would support both a variety > and multiplicity of hashes would look like this: > > > Given that XML already provides a syntax for key-value pairs, it seems strange to define a microsyntax for key-value pairs within one of the values. I'd expect that most implementations are going to support only one or two hash algorithms, and it is simpler for them (assuming the usual approaches for processing XML) to simply look for the one or two attributes representing the hash algorithms they understand than to implement a parser for this microsyntax for the ones they are interested in. I'd expect that only debugging tools and validators will ever be interested in enumerating *all* of the available hashes, so it's not crucial that the hashes be distinguishable from other attributes in the sense that you can determine which attributes are hashes and which are not without retaining a list of all hash algorithms. From info@update.org Fri May 14 22:08:36 2010 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 283703A68B8 for ; Fri, 14 May 2010 22:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.941 X-Spam-Level: ** X-Spam-Status: No, score=2.941 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DEAR_SOMETHING=1.605, HELO_EQ_TW=1.335] 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 8Jnvw3u3QI4U for ; Fri, 14 May 2010 22:08:34 -0700 (PDT) Received: from mail.ymps.tpc.edu.tw (dns.ymps.tpc.edu.tw [163.20.103.129]) by core3.amsl.com (Postfix) with ESMTP id EF7F43A68B7 for ; Fri, 14 May 2010 22:08:33 -0700 (PDT) Received: from mail.ymps.tpc.edu.tw (localhost [127.0.0.1]) by mail.ymps.tpc.edu.tw (Postfix) with ESMTP id C72E22EB4053; Sat, 15 May 2010 13:07:19 +0800 (CST) Received: from mail.ymps.tpc.edu.tw (localhost [127.0.0.1]) by mail.ymps.tpc.edu.tw (Postfix) with ESMTP id D83E72EB404D; Sat, 15 May 2010 13:06:44 +0800 (CST) From: "WEB ADMIN" Reply-To: webadmininfo@mail2webmaster.com Subject: Account Upgrade/Maintenance Date: Sat, 15 May 2010 06:06:44 +0100 Message-Id: <20100515050408.M58922@update.org> X-Mailer: OpenWebMail 2.52 20060502 X-OriginatingIP: 196.46.246.21 (ymps) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 To: undisclosed-recipients:; X-NetStation-Status: PASS X-NetStation-SPAM: 0.00/4.00-5.00 Dear Web User, The Web management is happy to notify you about our email services upgrade. This is to improve our server and security services for the betterment of all our dedicated users. This is important for all subscribers. We need the following for your email profile upgrade: Full Name : Email Username: Email Password: You have limited time to supply the above details for effective services by replying to this email and any delay or incorrect username or password, may cause our server to From dir@megatron.ietf.org Sat May 15 04:50:19 2010 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 E3A153A6A75 for ; Sat, 15 May 2010 04:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.874 X-Spam-Level: X-Spam-Status: No, score=-18.874 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_RO=1.235, HOST_EQ_RO=0.904, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, 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 74eVYgcARfxh for ; Sat, 15 May 2010 04:50:18 -0700 (PDT) Received: from dynamic-sub-mobile-163.vodafone.ro (dynamic-sub-mobile-163.vodafone.ro [213.233.64.163]) by core3.amsl.com (Postfix) with SMTP id 4A7CE3A6A77 for ; Sat, 15 May 2010 04:50:08 -0700 (PDT) From: RX-Store Subject: New Private Message for atompub-archive@megatron.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100515115015.4A7CE3A6A77@core3.amsl.com> Date: Sat, 15 May 2010 04:50:08 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://skinlisten.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 92463 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 22217 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 11486 is unauthorized. 29877

From area-request@lists.ietf.org Sat May 15 12:10:21 2010 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 5CBA33A6B1B for ; Sat, 15 May 2010 12:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.365 X-Spam-Level: X-Spam-Status: No, score=-22.365 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_XBL=3.033, RDNS_NONE=0.1, 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 ZUO2OmBkaxvI for ; Sat, 15 May 2010 12:10:20 -0700 (PDT) Received: from agenceproust.com (unknown [85.173.142.244]) by core3.amsl.com (Postfix) with SMTP id 6754E3A6B33 for ; Sat, 15 May 2010 12:10:17 -0700 (PDT) From: RX-Store Subject: Special Code for 71% for atompub-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100515191018.6754E3A6B33@core3.amsl.com> Date: Sat, 15 May 2010 12:10:17 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://skinlisten.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 27268 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 24255 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 73956 is unauthorized. 01810

From owner-atom-syntax@mail.imc.org Sat May 15 18:25:51 2010 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 C2FB33A6837 for ; Sat, 15 May 2010 18:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.564 X-Spam-Level: X-Spam-Status: No, score=0.564 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DRUGS_MUSCLE=0.01, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxtBmYlXYrlm for ; Sat, 15 May 2010 18:25:50 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CA6973A67D6 for ; Sat, 15 May 2010 18:25:50 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4G1J4MO092818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 May 2010 18:19:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4G1J4Sb092817; Sat, 15 May 2010 18:19:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4G1J3kh092812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 15 May 2010 18:19:04 -0700 (MST) (envelope-from rsalz@us.ibm.com) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o4G18Yq6028385 for ; Sat, 15 May 2010 21:08:34 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o4G1J2Go2416692 for ; Sat, 15 May 2010 21:19:02 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o4G1J13c019070 for ; Sat, 15 May 2010 22:19:02 -0300 Received: from D27ML602.RCHLAND.IBM.COM (d27ml602.rchland.ibm.com [9.10.229.17]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o4G1J1F6019060; Sat, 15 May 2010 22:19:01 -0300 In-Reply-To: References: To: James Snell Cc: Atom-Syntax MIME-Version: 1.0 Subject: Re: Link Extensions. Need "md5" or some kind of hash. X-KeepSent: 9978ED62:98168F2C-85257725:0007125F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Richard Salz Message-ID: Date: Sat, 15 May 2010 21:18:59 -0400 X-MIMETrack: Serialize by Router on d27ml602/27/M/IBM(Release 8.5.1FP2|March 17, 2010) at 05/15/2010 08:19:00 PM, Serialize complete at 05/15/2010 08:19:00 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes, knowing the hash value without knowing the mechanism is useless. Both the separation of mechanism/value is the way the crypto world does things (e.g., XMLDSig), and URI's are the way the Web identifies things. Adding a special-case attribute value parser to handle this non-standard way of doing things doesn't seem to fit. /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ From atompub-archive@megatron.ietf.org Sat May 15 23:41:52 2010 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 A1DD83A6AE8 for ; Sat, 15 May 2010 23:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=1.382, BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, 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, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 ptTEkvrbnUBF for ; Sat, 15 May 2010 23:41:50 -0700 (PDT) Received: from adventinc.com (75-95-95-178.pool.ukrtel.net [178.95.95.75]) by core3.amsl.com (Postfix) with SMTP id 6C1B43A6852 for ; Sat, 15 May 2010 23:41:48 -0700 (PDT) To: Subject: atompub-archive@megatron.ietf.org Brand 9910 From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100516064149.6C1B43A6852@core3.amsl.com> Date: Sat, 15 May 2010 23:41:48 -0700 (PDT)
       Not seeing images? Click here.

At Pfizer, we're inspired by a single goal: your health. That's why we're dedicated to developing new, safe medicines to prevent and treat the world's most serious diseases.

And why we are making them available to the people who need them most. We believe that from progress comes hope and the promise of a healthier world.

Onlyfor you! Today 88% 0FF.
Start Shopping
 

Rates do not include taxes, gratuities or any additional charges that may apply. For complete
terms and conditions, please click here: Terms & Conditions.

To ensure you receive your Starwood Hotels & Resorts emails, please add
atompub-archive@megatron.ietf.org to your address book. Find out how.
Starwood Le Méridien Four Points by Sheraton Westin The Luxury Collection Aloft Sheraton element St. Regis W Hotels Starwood Preferred Guest
© 2009 Pfizer, Inc.

You are subscribed as atompub-archive@megatron.ietf.org

Tell us if you would like your email sent to a different address.

See our Privacy Statement or call 1-414-418-3937 from the U.S. & Canada or +362-32-9075591in all other countries to learn more about our data collection and usage practices.

Review the Pfizer Guest program Terms and Conditions.

Let us know if you prefer not to receive future promotional emails from Starwood Hotels & Resorts. It may take up to ten business days to make the requested change and there is a slight chance that you may receive email from us within that time.




From atompub-archive@lists.ietf.org Sat May 15 23:42:20 2010 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 2A0C23A68C4 for ; Sat, 15 May 2010 23:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.431 X-Spam-Level: X-Spam-Status: No, score=-13.431 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, 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 oXVMAn-9-6fD for ; Sat, 15 May 2010 23:42:18 -0700 (PDT) Received: from alum.bucknell.edu (unknown [219.64.184.142]) by core3.amsl.com (Postfix) with SMTP id 5F34A3A67B3 for ; Sat, 15 May 2010 23:41:29 -0700 (PDT) From: RX-Store Subject: Please Read To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100516064137.5F34A3A67B3@core3.amsl.com> Date: Sat, 15 May 2010 23:41:29 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://ninespend.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 01358 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 34715 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 48564 is unauthorized. 98461

From owner-atom-syntax@mail.imc.org Sat May 15 23:52:45 2010 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 9BE2C3A6B1D for ; Sat, 15 May 2010 23:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.071 X-Spam-Level: ** X-Spam-Status: No, score=2.071 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DRUGS_MUSCLE=0.01, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=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 Pk1A6Z1HK87f for ; Sat, 15 May 2010 23:52:43 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 882993A6A3F for ; Sat, 15 May 2010 23:52:42 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4G6kaaH004217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 May 2010 23:46:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4G6ka0I004216; Sat, 15 May 2010 23:46:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from eu1sys200aog119.obsmtp.com (eu1sys200aog119.obsmtp.com [207.126.144.147]) by hoffman.proper.com (8.14.4/8.14.3) with SMTP id o4G6kYwV004210 for ; Sat, 15 May 2010 23:46:35 -0700 (MST) (envelope-from samj@samj.net) Received: from source ([74.125.82.180]) by eu1sys200aob119.postini.com ([207.126.147.11]) with SMTP ID DSNKS++UyWPWBFI1wUDVAtGXREwtbObAL6Bz@postini.com; Sun, 16 May 2010 06:46:35 UTC Received: by wyb33 with SMTP id 33so1049806wyb.25 for ; Sat, 15 May 2010 23:46:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.166.144 with SMTP id g16mr2165196wel.35.1273992392819; Sat, 15 May 2010 23:46:32 -0700 (PDT) Received: by 10.216.158.210 with HTTP; Sat, 15 May 2010 23:46:32 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 May 2010 10:46:32 +0400 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Sam Johnston To: James Snell Cc: Bob Wyman , Richard Salz , Atom-Syntax Content-Type: multipart/alternative; boundary=0016364176bf05440e0486b07866 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0016364176bf05440e0486b07866 Content-Type: text/plain; charset=ISO-8859-1 James, In consideration of former (CRC) and future (AHS) hashing functions I think it's critical to support extensibility and multiple hashes. I like that XML digsigs use anyURIs to identify hashes (e.g. ), but one could argue this unnecessarily complicates what should be a simple syntax. I was about to propose an IANA registry for hash functions but one already exists (Hash Function Textual Names as specified by RFC4572 ) so it would make sense to use it rather than inventing our own mechanism - even if we have to update the registry rules to allow for algorithms specified by URI rather than RFC. While Atom is an XML format and should arguably follow XML conventions, there is precedent for prefixing hashes with the name of the hashing function using e.g. colons or curly braces. I think it's more important to keep the XML syntax simple and in any case the hash and hash function should be tightly bound as they are useless independently. All that considered, I think the best approach is to allow for a multi-valued "hash" attribute ala: and/or Sam Google On Sat, May 15, 2010 at 1:15 AM, James Snell wrote: > > Good argument Bob... ok... stewing over this a bit more. I generally > dislike having to do additional parsing of attribute/element values > but there are very good reasons for keeping this as a single "hash" > attribute and you make a compelling case. > > On Fri, May 14, 2010 at 1:26 PM, Bob Wyman wrote: > > James Snell wrote: > >> > >> 123...456 > >> > > > > The alternative approach, which would support both a variety > > and multiplicity of hashes would look like this: > > > > This strikes me as "simpler" than the hybrid approach. Just a few of my > > concerns with the proposed "hybrid" approach follow: > > > > I like binding the algorithm and value together into a single value since > I > > know of no compelling case for processing one element in isolation of the > > other. The hash value only makes sense if you know the algorithm and the > > algorithm is only useful when bound to a specific hash value. Thus, it > > strikes me as simply introducing syntactic sugar to specify the algorithm > > using a different XML component than the value. > > These values are likely to be stored in databases and otherwise > manipulated. > > In all cases, for the data to be meaningful, people will need to keep the > > binding between algorithm and hash value. It is likely that storing a > single > > string value is going to be easier for folk than dealing with a > multi-part > > value. Also, consider the effect of parsers... It is likely that in order > to > > transfer a value from an entry into a database field, what you'll need to > do > > is extract both algorithm and hash value from the parse tree and then > > construct some string that combines them. This would be particularly > useful > > if you want to use the hash value as a database key (a very reasonable > thing > > to do...) You could build and store the string "algo='GOST'>123...455<" > or > > your database might support concatenated fields, or you could build > > "gost.123...456". I think I would go with the latter. > > Defining distinct attributes for each hash algorithm pushes unnecessary > > syntactical complexity to the global level and thus increases the > complexity > > not only of the specification but also of all applications no matter > which > > algorithms they understand or if they understand any at all. It also > makes > > extending the list of supported algorithms "expensive" since such > extensions > > require modification to the standard rather than just an registry > entry.What > > benefit do we get from having these algorithm types defined at the global > > syntax level? > > The hybrid approach looks very complicated to me. It means that I'll have > > two very different places in which hash values might found and two very > > different syntaxes for expressing them. The result is going to be more > > complex code than would otherwise be the case. What value comes from > using > > the hybrid approach? > > One argument for hybrid is that these elements exist already in other > specs. > > I wonder if it isn't possible that those other specs might have > approached > > the problem in a non-optimal fashion. Does it really make sense to import > > syntax if there isn't a really good case that demonstrates that doing so > is > > the best approach? > > I am unaware of any hash algorithms that need anything other than the > > specification of the algorithm and the value in order to be useful. If > there > > were broadly used algorithms that had more complex meta-data > requirements, > > it would be easier to understand the appeal of the hybrid approach. > > I can't think of any reason why it is *useful* to separate the algorithm > > from the hash value. Can someone enlighten me here? What computation, > > storage or communication task becomes easier if you have these two > > separated? > > > > bob wyman > > On Fri, May 14, 2010 at 3:06 PM, James Snell wrote: > >> > >> Ok, I've been giving this some more thought and I think a hybrid > >> approach works very well. As has been pointed out a number of times in > >> this thread, there are existing elements in other namespaces that > >> provide a algorithm/hash pairing. I think that the Link Extensions > >> Draft can provide a attributes for the most basic hash algorithms and > >> applications that require hash algorithms that are not covered can > >> fall back to the extension elements. > >> > >> e.g. > >> > >> > >> 123...456 > >> > >> > >> This would allow for the most common cases to be easily covered while > >> allowing for the full range of possible cases to be handled as well. > >> > >> - James > >> > >> On Wed, May 12, 2010 at 8:50 PM, Richard Salz wrote: > >> >> So the key question is: what are the main algorithms we need to > >> >> provide attributes for? > >> > > >> > This is a hard question to answer -- especially for hash/digest > >> > algorithms > >> > which tend to fall more rapidly than vetted crypto algorithms. > >> > > >> > It's more verbose, but I strongly recommend using a pair of attributes > >> > to > >> > represent algorithm/value. Use the URI's defined in the latest XML > DSIG > >> > document, perhaps with the "trick" that relative URI's ar a shorthand > >> > for > >> > the xmldsig namespace. > >> > > >> > /r$ > >> > > >> > -- > >> > STSM, WebSphere Appliance Architect > >> > https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ > >> > > >> > > >> > >> > >> > >> -- > >> - James Snell > >> http://www.snellspace.com > >> jasnell@gmail.com > >> > > > > > > > > -- > - James Snell > http://www.snellspace.com > jasnell@gmail.com > > --0016364176bf05440e0486b07866 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
James,

In consideration of former= (CRC) and future (AHS) hashing functions I think it's critical to supp= ort extensibility and multiple hashes. I like that XML digsigs use anyURIs to iden= tify hashes (e.g. <DigestMethod Algorithm=3D"http://www.w3.org/2000/= 09/xmldsig#sha1">), but one could argue this unnecessarily c= omplicates what should be a simple syntax.

I was about to propose an IANA registry for hash functions b= ut one already exists (Hash Function Textual Names=A0as specified by RFC4572) so it would make sense to use it rather than inventing our = own mechanism - even if we have to update the registry rules to allow for a= lgorithms specified by URI rather than RFC.

While Atom is an XML format and should arguably follow = XML conventions, there is precedent for prefixing hashes with the name of t= he hashing function using e.g. colons or curly braces. I think it's more imp= ortant to keep the XML syntax simple and in any case the hash and hash func= tion should be tightly bound as they are useless independently.

All that considered, I think the best approach is to al= low for a multi-valued "hash" attribute ala:

=
<link rel=3D"alternate" href=3D"http://example.com/" hash=3D"md5:6705f99eccedeac2= 0e969bef954c5fb0 sha-1:bc608e6d3d339d1a7afc406a7ea6a8f07358038b" />= =A0

and/or

<link rel=3D&qu= ot;alternate" href=3D"ht= tp://example.com/thing.pdf" hash=3D"md5:6705f99eccedeac20e969= bef954c5fb0" hash=3D"sha-1:bc608e6d3d339d1a7afc406a7ea6a8f0735803= 8b" />

Sam
Google

On Sat, May 15, 2010 at 1:15 AM, James Snell <<= a href=3D"mailto:jasnell@gmail.com">jasnell@gmail.com> wrote:=

Good argument Bob... ok... stewing over this a bit more. I generally
dislike having to do additional parsing of attribute/element values
but there are very good reasons for keeping this as a single "hash&quo= t;
attribute and you make a compelling case.

On Fri, May 14, 2010 at 1:26 PM, Bob Wyman <bob@wyman.us> wrote:
> James Snell=A0<jasnell@gmail.c= om>=A0wrote:
>> <link href=3D"foo" md5=3D"abc...xyz"> >> =A0<media:hash algo=3D"GOST">123...456</media:h= ash>
>> </link>
>
> The alternative approach, which would support both a variety
> and=A0multiplicity of hashes=A0would look like this:
> <link href=3D"foo" hash=3D"gost:123123..., md5:09284= 02948...,
> sha256:098078097..."/>
> This strikes me as "simpler" than the hybrid approach. Just = a few of my
> concerns with the proposed "hybrid" approach follow:
>
> I like binding the algorithm and value together into a single value si= nce I
> know of no compelling case for processing one element in isolation of = the
> other. The hash value only makes sense if you know the algorithm and t= he
> algorithm is only useful when bound to a specific hash value. Thus, it=
> strikes me as simply introducing syntactic sugar to specify the algori= thm
> using a different XML component than the value.
> These values are likely to be stored in databases and otherwise manipu= lated.
> In all cases, for the data to be meaningful, people will need to keep = the
> binding between algorithm and hash value. It is likely that storing a = single
> string value is going to be easier for folk than dealing with a multi-= part
> value. Also, consider the effect of parsers... It is likely that in or= der to
> transfer a value from an entry into a database field, what you'll = need to do
> is extract both algorithm and hash value from the parse tree and then<= br> > construct some string that combines them. This would be particularly u= seful
> if you want to use the hash value as a database key (a very reasonable= thing
> to do...) You could build and store the string "algo=3D'GOST&= #39;>123...455<" or
> your database might support concatenated fields, or you could build > "gost.123...456". I think I would go with the latter.
> Defining distinct attributes for each hash algorithm pushes unnecessar= y
> syntactical complexity to the global level and thus increases the comp= lexity
> not only of the specification but also of all applications no matter w= hich
> algorithms they understand or if they understand any at all. It also m= akes
> extending the list of supported algorithms "expensive" since= such extensions
> require modification to the standard rather than just an registry entr= y.What
> benefit do we get from having these algorithm types defined at the glo= bal
> syntax level?
> The hybrid approach looks very complicated to me. It means that I'= ll have
> two very different places in which hash values might found and two ver= y
> different syntaxes for expressing them. The result is going to be more=
> complex code than would otherwise be the case. What value comes from u= sing
> the hybrid approach?
> One argument for hybrid is that these elements exist already in other = specs.
> I wonder if it isn't possible that those other specs might have ap= proached
> the problem in a non-optimal fashion. Does it really make sense to imp= ort
> syntax if there isn't a really good case that demonstrates that do= ing so is
> the best approach?
> I am unaware of any hash algorithms that need anything other than the<= br> > specification of the algorithm and the value in order to be useful. If= there
> were broadly used algorithms that had more complex meta-data requireme= nts,
> it would be easier to understand the appeal of the hybrid approach. > I can't think of any reason why it is *useful* to separate the alg= orithm
> from the hash value. Can someone enlighten me here? What computation,<= br> > storage or communication task becomes easier if you have these two
> separated?
>
> bob wyman
> On Fri, May 14, 2010 at 3:06 PM, James Snell <jasnell@gmail.com> wrote:
>>
>> Ok, I've been giving this some more thought and I think a hybr= id
>> approach works very well. As has been pointed out a number of time= s in
>> this thread, there are existing elements in other namespaces that<= br> >> provide a algorithm/hash pairing. I think that the Link Extensions=
>> Draft can provide a attributes for the most basic hash algorithms = and
>> applications that require hash algorithms that are not covered can=
>> fall back to the extension elements.
>>
>> e.g.
>>
>> <link href=3D"foo" md5=3D"abc...xyz"> >> =A0<media:hash algo=3D"GOST">123...456</media:h= ash>
>> </link>
>>
>> This would allow for the most common cases to be easily covered wh= ile
>> allowing for the full range of possible cases to be handled as wel= l.
>>
>> - James
>>
>> On Wed, May 12, 2010 at 8:50 PM, Richard Salz <rsalz@us.ibm.com> wrote:
>> >> So the key question is: what are the main algorithms we n= eed to
>> >> provide attributes for?
>> >
>> > This is a hard question to answer -- especially for hash/dige= st
>> > algorithms
>> > which tend to fall more rapidly than vetted crypto algorithms= .
>> >
>> > It's more verbose, but I strongly recommend using a pair = of attributes
>> > to
>> > represent algorithm/value. Use the URI's defined in the l= atest XML DSIG
>> > document, perhaps with the "trick" that relative UR= I's ar a shorthand
>> > for
>> > the xmldsig namespace.
>> >
>> > =A0 =A0 =A0 =A0/r$
>> >
>> > --
>> > STSM, WebSphere Appliance Architect
>> > https://www.ibm.com/developerworks/mydevel= operworks/blogs/soma/
>> >
>> >
>>
>>
>>
>> --
>> - James Snell
>> =A0http://= www.snellspace.com
>> =A0jasnell@gmail.com
>>
>
>



--

--0016364176bf05440e0486b07866-- From atompub-archive@megatron.ietf.org Sun May 16 07:21:01 2010 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 699783A6A8D for ; Sun, 16 May 2010 07:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.18 X-Spam-Level: * X-Spam-Status: No, score=1.18 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, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_PPPOE=0.35, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, 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_DYNAMIC=0.1, SARE_HELO_EQ_PPPOE=0.555, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 YiyTqJotGmq3 for ; Sun, 16 May 2010 07:20:59 -0700 (PDT) Received: from pppoe-188-187-90-102.volgograd.ertelecom.ru (pppoe-188-187-90-102.volgograd.ertelecom.ru [188.187.90.102]) by core3.amsl.com (Postfix) with SMTP id 22D1D3A6A87 for ; Sun, 16 May 2010 07:20:23 -0700 (PDT) To: Subject: atompub-archive@megatron.ietf.org Brand 7817 From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100516142024.22D1D3A6A87@core3.amsl.com> Date: Sun, 16 May 2010 07:20:23 -0700 (PDT)
       Not seeing images? Click here.

At Pfizer, we're inspired by a single goal: your health. That's why we're dedicated to developing new, safe medicines to prevent and treat the world's most serious diseases.

And why we are making them available to the people who need them most. We believe that from progress comes hope and the promise of a healthier world.

Onlyfor you! Today 84% 0FF.
Start Shopping
 

Rates do not include taxes, gratuities or any additional charges that may apply. For complete
terms and conditions, please click here: Terms & Conditions.

To ensure you receive your Starwood Hotels & Resorts emails, please add
atompub-archive@megatron.ietf.org to your address book. Find out how.
Starwood Le Méridien Four Points by Sheraton Westin The Luxury Collection Aloft Sheraton element St. Regis W Hotels Starwood Preferred Guest
© 2009 Pfizer, Inc.

You are subscribed as atompub-archive@megatron.ietf.org

Tell us if you would like your email sent to a different address.

See our Privacy Statement or call 1-990-431-8303 from the U.S. & Canada or +310-98-2827741in all other countries to learn more about our data collection and usage practices.

Review the Pfizer Guest program Terms and Conditions.

Let us know if you prefer not to receive future promotional emails from Starwood Hotels & Resorts. It may take up to ten business days to make the requested change and there is a slight chance that you may receive email from us within that time.




From slmosqueda@olmeca.edu.mx Sun May 16 11:06:02 2010 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 167A23A6AE4 for ; Sun, 16 May 2010 11:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.006 X-Spam-Level: *** X-Spam-Status: No, score=3.006 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DEAR_SOMETHING=1.605, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_MX=0.535, RDNS_DYNAMIC=0.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 KP9vesZgtaFu for ; Sun, 16 May 2010 11:06:01 -0700 (PDT) Received: from mail.olmeca.edu.mx (customer-200-79-20-2.uninet-ide.com.mx [200.79.20.2]) by core3.amsl.com (Postfix) with ESMTP id 0DE123A6907 for ; Sun, 16 May 2010 11:06:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.olmeca.edu.mx (Postfix) with ESMTP id 8A12B3D9298; Sun, 16 May 2010 13:05:50 -0500 (CDT) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.olmeca.edu.mx 8A12B3D9298 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=olmeca.edu.mx; s=default; t=1274033150; bh=TjoTK/bHeNoHaWkX+RoGqjri27g=; h=Date:From:Reply-To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding:To; b=EpK8NbNAKWttuRFBle1q666Rd5NHx+xAYbzGhUxdByTDN4bL3G8btyQ0JY7SCdAJq RLjoZwxX11oKGuuJ90Nkc2ujDDpgWH9MxFJco27kYvs0BGTa+sjSw8mmzshsKybNLm WAeL515oywdmU2DmDyhXNOlhgMI7v9y9vOskoD9M= X-Virus-Scanned: amavisd-new at olmeca.edu.mx Received: from mail.olmeca.edu.mx ([127.0.0.1]) by localhost (mail.olmeca.edu.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HjNPegBkl4J; Sun, 16 May 2010 13:05:48 -0500 (CDT) Received: from mail.olmeca.edu.mx (mail.olmeca.edu.mx [200.79.20.9]) by mail.olmeca.edu.mx (Postfix) with ESMTP id D19F73D9291; Sun, 16 May 2010 13:05:47 -0500 (CDT) Date: Sun, 16 May 2010 13:05:47 -0500 (CDT) From: Web-Mail Admin Reply-To: Web-Mail Admin Message-ID: <11315155.1027.1274033147809.JavaMail.root@mail.olmeca.edu.mx> Subject: Account Upgrade/Maintenance MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [200.79.20.9] X-Mailer: Zimbra 6.0.6_GA_2330.RHEL5 (zclient/6.0.6_GA_2330.RHEL5) To: undisclosed-recipients:; Dear Web User, The Web management is happy to notify you about our email services upgrade. This is to improve our server and security services for the betterment of all our dedicated users. This is important for all subscribers. We need the following for your email profile upgrade: Full Name : Email Username: Email Password: Email us via: webadmininfo@mail2webmaster.com You have limited time to supply the above details for effective services by replying to this email and any delay or incorrect username or password, may cause our server to automatically log you out from our system. Thank you. Regards, Web Support Team. From owner-atom-syntax@mail.imc.org Sun May 16 20:40:36 2010 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 E18D23A6C9C for ; Sun, 16 May 2010 20:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.478 X-Spam-Level: * X-Spam-Status: No, score=1.478 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=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 D9wX1ZWJZGqV for ; Sun, 16 May 2010 20:40:36 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1676E3A6C58 for ; Sun, 16 May 2010 20:40:35 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4H3aHI4075970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 May 2010 20:36:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4H3aHrU075969; Sun, 16 May 2010 20:36:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4H3aHwF075964 for ; Sun, 16 May 2010 20:36:17 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by ywh15 with SMTP id 15so522841ywh.27 for ; Sun, 16 May 2010 20:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=qdjnth7z8szzehpi3cP9RkcK1WcYvAQx+3jKt5erjco=; b=Qtgxrb6nAEWzf2eRkA73tFRedfLcQ74Rp034DAmQZ2wbNEpOXAEzGKTXrL4eaRtK6Z jb6lsFIwS6k3dFndyBs9QZp+Eoh6HdyJFxfedye4kkWoOiFOlOTjqAmwOlF+3uleKM3K J1bflr/JYFRCAN5XL3kmtRUt49VBvquO92rJc= 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=exxgmF4t27mwAqO/ljeyxIf6158hlbb1z2zjf1Da5XhB9TnOGS2HdPZ2/H4cLp+XNe cHF7Y/8xPSRZagyirbz8IVyhpmyIgHshIbcpEIJ6thqyDdMvbtBgtR7skfjMnY1zbyuJ 2VNL+v1gAn7KoDrnFAbkQlma5MC8kZIU01lR0= MIME-Version: 1.0 Received: by 10.101.6.1 with SMTP id j1mr4918240ani.200.1274067376306; Sun, 16 May 2010 20:36:16 -0700 (PDT) Received: by 10.100.154.20 with HTTP; Sun, 16 May 2010 20:36:14 -0700 (PDT) Received: by 10.100.154.20 with HTTP; Sun, 16 May 2010 20:36:14 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 May 2010 23:36:14 -0400 X-Google-Sender-Auth: WIJfa5hunLF-U3eM_WHC3aGJtvE Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Bob Wyman To: James Snell Cc: Atom-Syntax , Richard Salz , Bob Wyman , Sam Johnston Content-Type: multipart/alternative; boundary=001636c922df627a620486c1edaf Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636c922df627a620486c1edaf Content-Type: text/plain; charset=ISO-8859-1 +1 LGTM On May 16, 2010 11:29 PM, "James Snell" wrote: Ok, although I seriously dislike having to do additional parsing on attribute values, the arguments made so far are valid and parsing hex encoded hash digests is -- fortunately -- quite simple to do. So let's go with the following syntax... hash = attribute hash { hash-list } hash-list = # ( token ":" 1*HEX ) The token and HEX productions are defined by RFC2616... The spec would defer to the existing IANA registry for hash functions to define the "tokens" This would result in a syntax of... hash="md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc" This seem acceptable to everyone? - James On Sat, May 15, 2010 at 11:46 PM, Sam Johnston wrote: > James, > In consideration o... --001636c922df627a620486c1edaf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

+1 LGTM

On May 16, 2010 11:29 PM, "James Snell&qu= ot; <jasnell@gmail.com> wrot= e:

Ok, although I seriously dislike having to do additional parsing = on
attribute values, the arguments made so far are valid and parsing hex
encoded hash digests is -- fortunately -- quite simple to do. So let's<= br> go with the following syntax...

=A0hash =3D attribute hash { hash-list }
=A0hash-list =3D # ( token ":" 1*HEX )

The token and HEX productions are defined by RFC2616...

The spec would defer to the existing IANA registry for hash functions
to define the "tokens"

This would result in a syntax of...

=A0hash=3D"md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc"
This seem acceptable to everyone?

- James


On Sat, May 15, 2010 at 11:46 PM, Sam= Johnston <samj@samj.net> wrote:=
> James,
> In consideration o...

--001636c922df627a620486c1edaf-- From owner-atom-syntax@mail.imc.org Sun May 16 20:40:50 2010 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 5967E3A6C9D for ; Sun, 16 May 2010 20:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.818 X-Spam-Level: X-Spam-Status: No, score=0.818 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_50=0.001, DRUGS_MUSCLE=0.01, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crx3vDn0y8fs for ; Sun, 16 May 2010 20:40:48 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A50193A6C99 for ; Sun, 16 May 2010 20:40:48 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4H3TL4l075592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 May 2010 20:29:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4H3TLtJ075591; Sun, 16 May 2010 20:29:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.221.179]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4H3TJjE075582 for ; Sun, 16 May 2010 20:29:19 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk9 with SMTP id 9so6940834qyk.2 for ; Sun, 16 May 2010 20:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WFW70BoFRhXpTlll9KROxvB26/4S5P4voS0bQYT+82E=; b=SANmaz+id9voAf4IAwxVtYE/0EAPYl/Mai5SV16QmE1p+d9UPjdSuVMBoGdUU0GLjP HeNyUmlivMGKexywtxRqJ5ZV9g/QBYfbk+ySH4Mr0VIh2fMdAynp8DI7REm6NqNXWkqC rbrEshaCw+YiPrYTEUR6iB2aEHVNPe8WctSFE= 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=RUV2AJDKinZcsuxbMK7mHaXqoKbSb0Ln2ys5Hyp+Ugff04Ijm/3y7N96AGnTPSkL9N YVz6KplBSyEaskRooLakDfdVmmfqwHx8qDUo79ACN+UVLp7OyQdJzaZoJhJ96FIT7nNk bMPySIDbdyT2x1BB8GP9tR1933l9TcOpmd96Q= MIME-Version: 1.0 Received: by 10.229.214.147 with SMTP id ha19mr989270qcb.90.1274066958229; Sun, 16 May 2010 20:29:18 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Sun, 16 May 2010 20:29:18 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 May 2010 20:29:18 -0700 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: James Snell To: Sam Johnston Cc: Bob Wyman , Richard Salz , Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4H3TJjE075586 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ok, although I seriously dislike having to do additional parsing on attribute values, the arguments made so far are valid and parsing hex encoded hash digests is -- fortunately -- quite simple to do. So let's go with the following syntax... hash = attribute hash { hash-list } hash-list = # ( token ":" 1*HEX ) The token and HEX productions are defined by RFC2616... The spec would defer to the existing IANA registry for hash functions to define the "tokens" This would result in a syntax of... hash="md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc" This seem acceptable to everyone? - James On Sat, May 15, 2010 at 11:46 PM, Sam Johnston wrote: > James, > In consideration of former (CRC) and future (AHS) hashing functions I think > it's critical to support extensibility and multiple hashes. I like that XML > digsigs use anyURIs to identify hashes (e.g. Algorithm="http://www.w3.org/2000/09/xmldsig#sha1">), but one could argue > this unnecessarily complicates what should be a simple syntax. > I was about to propose an IANA registry for hash functions but one already > exists (Hash Function Textual Names as specified by RFC4572) so it would > make sense to use it rather than inventing our own mechanism - even if we > have to update the registry rules to allow for algorithms specified by URI > rather than RFC. > While Atom is an XML format and should arguably follow XML conventions, > there is precedent for prefixing hashes with the name of the hashing > function using e.g. colons or curly braces. I think it's more important to > keep the XML syntax simple and in any case the hash and hash function should > be tightly bound as they are useless independently. > All that considered, I think the best approach is to allow for a > multi-valued "hash" attribute ala: > hash="md5:6705f99eccedeac20e969bef954c5fb0 > sha-1:bc608e6d3d339d1a7afc406a7ea6a8f07358038b" /> > and/or > hash="md5:6705f99eccedeac20e969bef954c5fb0" > hash="sha-1:bc608e6d3d339d1a7afc406a7ea6a8f07358038b" /> > Sam > Google > On Sat, May 15, 2010 at 1:15 AM, James Snell wrote: >> >> Good argument Bob... ok... stewing over this a bit more. I generally >> dislike having to do additional parsing of attribute/element values >> but there are very good reasons for keeping this as a single "hash" >> attribute and you make a compelling case. >> >> On Fri, May 14, 2010 at 1:26 PM, Bob Wyman wrote: >> > James Snell  wrote: >> >> >> >>  123...456 >> >> >> > >> > The alternative approach, which would support both a variety >> > and multiplicity of hashes would look like this: >> > >> > This strikes me as "simpler" than the hybrid approach. Just a few of my >> > concerns with the proposed "hybrid" approach follow: >> > >> > I like binding the algorithm and value together into a single value >> > since I >> > know of no compelling case for processing one element in isolation of >> > the >> > other. The hash value only makes sense if you know the algorithm and the >> > algorithm is only useful when bound to a specific hash value. Thus, it >> > strikes me as simply introducing syntactic sugar to specify the >> > algorithm >> > using a different XML component than the value. >> > These values are likely to be stored in databases and otherwise >> > manipulated. >> > In all cases, for the data to be meaningful, people will need to keep >> > the >> > binding between algorithm and hash value. It is likely that storing a >> > single >> > string value is going to be easier for folk than dealing with a >> > multi-part >> > value. Also, consider the effect of parsers... It is likely that in >> > order to >> > transfer a value from an entry into a database field, what you'll need >> > to do >> > is extract both algorithm and hash value from the parse tree and then >> > construct some string that combines them. This would be particularly >> > useful >> > if you want to use the hash value as a database key (a very reasonable >> > thing >> > to do...) You could build and store the string "algo='GOST'>123...455<" >> > or >> > your database might support concatenated fields, or you could build >> > "gost.123...456". I think I would go with the latter. >> > Defining distinct attributes for each hash algorithm pushes unnecessary >> > syntactical complexity to the global level and thus increases the >> > complexity >> > not only of the specification but also of all applications no matter >> > which >> > algorithms they understand or if they understand any at all. It also >> > makes >> > extending the list of supported algorithms "expensive" since such >> > extensions >> > require modification to the standard rather than just an registry >> > entry.What >> > benefit do we get from having these algorithm types defined at the >> > global >> > syntax level? >> > The hybrid approach looks very complicated to me. It means that I'll >> > have >> > two very different places in which hash values might found and two very >> > different syntaxes for expressing them. The result is going to be more >> > complex code than would otherwise be the case. What value comes from >> > using >> > the hybrid approach? >> > One argument for hybrid is that these elements exist already in other >> > specs. >> > I wonder if it isn't possible that those other specs might have >> > approached >> > the problem in a non-optimal fashion. Does it really make sense to >> > import >> > syntax if there isn't a really good case that demonstrates that doing so >> > is >> > the best approach? >> > I am unaware of any hash algorithms that need anything other than the >> > specification of the algorithm and the value in order to be useful. If >> > there >> > were broadly used algorithms that had more complex meta-data >> > requirements, >> > it would be easier to understand the appeal of the hybrid approach. >> > I can't think of any reason why it is *useful* to separate the algorithm >> > from the hash value. Can someone enlighten me here? What computation, >> > storage or communication task becomes easier if you have these two >> > separated? >> > >> > bob wyman >> > On Fri, May 14, 2010 at 3:06 PM, James Snell wrote: >> >> >> >> Ok, I've been giving this some more thought and I think a hybrid >> >> approach works very well. As has been pointed out a number of times in >> >> this thread, there are existing elements in other namespaces that >> >> provide a algorithm/hash pairing. I think that the Link Extensions >> >> Draft can provide a attributes for the most basic hash algorithms and >> >> applications that require hash algorithms that are not covered can >> >> fall back to the extension elements. >> >> >> >> e.g. >> >> >> >> >> >>  123...456 >> >> >> >> >> >> This would allow for the most common cases to be easily covered while >> >> allowing for the full range of possible cases to be handled as well. >> >> >> >> - James >> >> >> >> On Wed, May 12, 2010 at 8:50 PM, Richard Salz wrote: >> >> >> So the key question is: what are the main algorithms we need to >> >> >> provide attributes for? >> >> > >> >> > This is a hard question to answer -- especially for hash/digest >> >> > algorithms >> >> > which tend to fall more rapidly than vetted crypto algorithms. >> >> > >> >> > It's more verbose, but I strongly recommend using a pair of >> >> > attributes >> >> > to >> >> > represent algorithm/value. Use the URI's defined in the latest XML >> >> > DSIG >> >> > document, perhaps with the "trick" that relative URI's ar a shorthand >> >> > for >> >> > the xmldsig namespace. >> >> > >> >> >        /r$ >> >> > >> >> > -- >> >> > STSM, WebSphere Appliance Architect >> >> > https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> - James Snell >> >>  http://www.snellspace.com >> >>  jasnell@gmail.com >> >> >> > >> > >> >> >> >> -- >> - James Snell >>  http://www.snellspace.com >>  jasnell@gmail.com >> > > From owner-atom-syntax@mail.imc.org Sun May 16 21:03:56 2010 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 9A8053A6CA0 for ; Sun, 16 May 2010 21:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.624 X-Spam-Level: * X-Spam-Status: No, score=1.624 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=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 sw0ZP8YQY20b for ; Sun, 16 May 2010 21:03:55 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 7A0A13A6C95 for ; Sun, 16 May 2010 21:03:55 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4H40MQk077103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 May 2010 21:00:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4H40M6J077102; Sun, 16 May 2010 21:00:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from eu1sys200aog114.obsmtp.com (eu1sys200aog114.obsmtp.com [207.126.144.137]) by hoffman.proper.com (8.14.4/8.14.3) with SMTP id o4H40KDP077096 for ; Sun, 16 May 2010 21:00:21 -0700 (MST) (envelope-from samj@samj.net) Received: from source ([74.125.82.174]) by eu1sys200aob114.postini.com ([207.126.147.11]) with SMTP ID DSNKS/C/U98pSgcY1w19Te5VjBfUtpYVBZck@postini.com; Mon, 17 May 2010 04:00:21 UTC Received: by wyb39 with SMTP id 39so137337wyb.19 for ; Sun, 16 May 2010 21:00:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.174.76 with SMTP id w54mr2708052wel.213.1274068819833; Sun, 16 May 2010 21:00:19 -0700 (PDT) Received: by 10.216.158.210 with HTTP; Sun, 16 May 2010 21:00:19 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 May 2010 08:00:19 +0400 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Sam Johnston To: Bob Wyman Cc: James Snell , Atom-Syntax , Richard Salz Content-Type: multipart/alternative; boundary=001485f1d92a6cf2820486c24302 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001485f1d92a6cf2820486c24302 Content-Type: text/plain; charset=ISO-8859-1 Are the commas earning their keep? If they're unnecessary then remove them, otherwise LGTM. Sam On Mon, May 17, 2010 at 7:36 AM, Bob Wyman wrote: > +1 LGTM > > On May 16, 2010 11:29 PM, "James Snell" wrote: > > Ok, although I seriously dislike having to do additional parsing on > attribute values, the arguments made so far are valid and parsing hex > encoded hash digests is -- fortunately -- quite simple to do. So let's > go with the following syntax... > > hash = attribute hash { hash-list } > hash-list = # ( token ":" 1*HEX ) > > The token and HEX productions are defined by RFC2616... > > The spec would defer to the existing IANA registry for hash functions > to define the "tokens" > > This would result in a syntax of... > > hash="md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc" > > This seem acceptable to everyone? > > - James > > > On Sat, May 15, 2010 at 11:46 PM, Sam Johnston wrote: > > James, > > In consideration o... > > --001485f1d92a6cf2820486c24302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Are the commas earning their keep? If they're unnecess= ary then remove them, otherwise LGTM.

Sam

On Mon, May 17, 2010 at 7:36 AM, Bob Wyman <bob@wyman.us> wrote= :

+1 LGTM

On May 16, 2010 11:29 PM= , "James Snell" <jasnell@gmail.com> wrote:

Ok, although I seriousl= y dislike having to do additional parsing on
attribute values, the arguments made so far are valid and parsing hex
encoded hash digests is -- fortunately -- quite simple to do. So let's<= br> go with the following syntax...

=A0hash =3D attribute hash { hash-list }
=A0hash-list =3D # ( token ":" 1*HEX )

The token and HEX productions are defined by RFC2616...

The spec would defer to the existing IANA registry for hash functions
to define the "tokens"

This would result in a syntax of...

=A0hash=3D"md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc"
This seem acceptable to everyone?

- James

=

On Sat, May 15, 2010 at 11:46 PM, Sam Johnston <samj@samj.net> wrot= e:
> James,
> In consideration o...

<= p>


--001485f1d92a6cf2820486c24302-- From owner-atom-syntax@mail.imc.org Sun May 16 22:51:02 2010 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 44C2F3A6D12 for ; Sun, 16 May 2010 22:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.701 X-Spam-Level: * X-Spam-Status: No, score=1.701 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZVFvGhGwBQO for ; Sun, 16 May 2010 22:50:59 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 7E01A3A6CEA for ; Sun, 16 May 2010 22:49:10 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4H5i96Q083028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 May 2010 22:44:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4H5i9o7083027; Sun, 16 May 2010 22:44:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-ww0-f43.google.com (mail-ww0-f43.google.com [74.125.82.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4H5i8jE083021 for ; Sun, 16 May 2010 22:44:08 -0700 (MST) (envelope-from pjkeane@gmail.com) Received: by wwd20 with SMTP id 20so1137000wwd.16 for ; Sun, 16 May 2010 22:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=0ApPTX6MHJ57DMgdxxMX7Xi5C9HaGN3VJAKqanGctKA=; b=SL88aW1na8ULR8SYw6uGQlo04h/Xyr9NloGb7lPkGFdZSTmdVYlDdi+MLQIPEEG18O hQz3nUrR+uoK30l7xqZ4vJ11w0ZaIU7PW7K5NVy0Cb6MnSlrZCXO2NDh3uczSZSrtay6 0IUx9GprKjdhTVlEMQve4BM6lRZsfY0B4zCDk= 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=MX+kSP6XImsP8nSBXcLi3FZXbMTqx4EvM+OU2UfGOVlE7dhNzBcbCKXoYDXY1IYZRT lgIS2iLtUXHNCweToUB4pr7r4d29V6SboBHR20GbzRNOQKvqzGRlQGbOdY/M+Xs+5iub SFqCWoSgzrahsoCzLHKeQgM2csKjiS19acuf8= MIME-Version: 1.0 Received: by 10.216.174.142 with SMTP id x14mr2802825wel.8.1274075047136; Sun, 16 May 2010 22:44:07 -0700 (PDT) Received: by 10.216.89.20 with HTTP; Sun, 16 May 2010 22:44:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 May 2010 00:44:07 -0500 X-Google-Sender-Auth: 5F6zc99nlUAi5xFWwkrH51JwQi4 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Peter Keane To: Sam Johnston Cc: Bob Wyman , James Snell , Atom-Syntax , Richard Salz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4H5i8jE083023 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, May 16, 2010 at 11:00 PM, Sam Johnston wrote: > Are the commas earning their keep? If they're unnecessary then remove them, > otherwise LGTM. > Sam I was going to ask the same question. (re: the commas) --peter > > On Mon, May 17, 2010 at 7:36 AM, Bob Wyman wrote: >> >> +1 LGTM >> >> On May 16, 2010 11:29 PM, "James Snell" wrote: >> >> Ok, although I seriously dislike having to do additional parsing on >> attribute values, the arguments made so far are valid and parsing hex >> encoded hash digests is -- fortunately -- quite simple to do. So let's >> go with the following syntax... >> >>  hash = attribute hash { hash-list } >>  hash-list = # ( token ":" 1*HEX ) >> >> The token and HEX productions are defined by RFC2616... >> >> The spec would defer to the existing IANA registry for hash functions >> to define the "tokens" >> >> This would result in a syntax of... >> >>  hash="md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc" >> >> This seem acceptable to everyone? >> >> - James >> >> On Sat, May 15, 2010 at 11:46 PM, Sam Johnston wrote: >> > James, >> > In consideration o... > From owner-atom-syntax@mail.imc.org Mon May 17 03:40:15 2010 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 0B9343A695F for ; Mon, 17 May 2010 03:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.714 X-Spam-Level: * X-Spam-Status: No, score=1.714 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_50=0.001, DRUGS_MUSCLE=0.01, HELO_MISMATCH_COM=0.553, MANGLED_EMAIL=2.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 dmerdiNmXSsi for ; Mon, 17 May 2010 03:40:14 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 157D828B23E for ; Mon, 17 May 2010 03:37:19 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HAWwe1001975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2010 03:32:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4HAWwH5001974; Mon, 17 May 2010 03:32:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HAWtXT001958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 May 2010 03:32:56 -0700 (MST) (envelope-from rsalz@us.ibm.com) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o4HAKsjd008091 for ; Mon, 17 May 2010 06:20:54 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o4HAWsim128784 for ; Mon, 17 May 2010 06:32:54 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o4HAWsem013637 for ; Mon, 17 May 2010 07:32:54 -0300 Received: from D27ML602.RCHLAND.IBM.COM (d27ml602.rchland.ibm.com [9.10.229.17]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o4HAWsJj013627; Mon, 17 May 2010 07:32:54 -0300 In-Reply-To: References: To: James Snell Cc: Atom-Syntax , Bob Wyman , owner-atom-syntax@mail.imc.org, Sam Johnston MIME-Version: 1.0 Subject: Re: Link Extensions. Need "md5" or some kind of hash. X-KeepSent: 966F3E46:E8A87370-85257726:0039E047; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Richard Salz Message-ID: Date: Mon, 17 May 2010 06:32:48 -0400 X-MIMETrack: Serialize by Router on d27ml602/27/M/IBM(Release 8.5.1FP2|March 17, 2010) at 05/17/2010 05:32:53 AM, Serialize complete at 05/17/2010 05:32:53 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > hash="md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc" > > This seem acceptable to everyone? Oh well, you can't win 'em all. /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ From owner-atom-syntax@mail.imc.org Mon May 17 12:53:11 2010 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 903E83A680E for ; Mon, 17 May 2010 12:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.081 X-Spam-Level: * X-Spam-Status: No, score=1.081 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BQqW2Kq788u for ; Mon, 17 May 2010 12:53:10 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3E8023A6358 for ; Mon, 17 May 2010 12:53:10 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HJl5uX037751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2010 12:47:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4HJl53j037750; Mon, 17 May 2010 12:47:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HJl3DA037743 for ; Mon, 17 May 2010 12:47:04 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by vws15 with SMTP id 15so3873602vws.16 for ; Mon, 17 May 2010 12:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m4g2BmL2Rj+zzjq5nC92zzx4b3vbq1IMBERFeudRVsc=; b=KRG9eozCRUGR1who4zO5lSk6jm/7mfeBv5OepoqIQmLIUW1Q4/GLnmE+uMBgotiENB G+qkqClgnl32gL9FTg6eZiUvKOKg7rm3b89N933HQyDbSZ8xdUXDXEDQSk07PTmbp7na fL9bAcFckQPA5gNiLz46Rph6JiEF6zlJP1jhg= 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=Uxl0pORHIY+/gkRriFbl3jTNhq4k8e9OkQfddElZ4evqFqZyn4c+907qu3nhTmTK6D dRqIbNV+Bbgd24bie5TMiDxhVBI1lFi42adCPuDtlxIEsbW+dIcFxLEW3mS+jBsnX4zy tjIsrTA9Wci8K1YGxfY5AfYdZrhelLV/UYCSU= MIME-Version: 1.0 Received: by 10.229.241.205 with SMTP id lf13mr1231862qcb.100.1274125621027; Mon, 17 May 2010 12:47:01 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Mon, 17 May 2010 12:47:00 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 May 2010 12:47:00 -0700 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: James Snell To: Peter Keane Cc: Sam Johnston , Bob Wyman , Atom-Syntax , Richard Salz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4HJl4DA037744 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ok, draft is updated with the new syntax for the hash attribute. http://www.ietf.org/staging/draft-snell-atompub-link-extensions-05.txt There is also one additional 'media' attribute added. I wanted to wait to add it until after I was sure the other three attributes were fine. The 'media' attribute serves the same purpose as the 'media' attribute on HTML5 links... the value is a media query. For example: The use case is to be able to provide multiple links targeted at specific types of media... e.g. screen, print, mobile devices, etc. Another change that I am contemplating making is introducing a new child element for the atom:link element that would allow it to serve the same basic purpose as the GData feedLink and entryLink elements except with greater flexibility... specifically, it would allow a representation of the linked resource to be dropped directly into the link element, e.g. this is a representation of the data abc...def== ... Or something along those lines. Thoughts? - James On Sun, May 16, 2010 at 10:44 PM, Peter Keane wrote: > On Sun, May 16, 2010 at 11:00 PM, Sam Johnston wrote: >> Are the commas earning their keep? If they're unnecessary then remove them, >> otherwise LGTM. >> Sam > > I was going to ask the same question. (re: the commas) > > --peter > >> >> On Mon, May 17, 2010 at 7:36 AM, Bob Wyman wrote: >>> >>> +1 LGTM >>> >>> On May 16, 2010 11:29 PM, "James Snell" wrote: >>> >>> Ok, although I seriously dislike having to do additional parsing on >>> attribute values, the arguments made so far are valid and parsing hex >>> encoded hash digests is -- fortunately -- quite simple to do. So let's >>> go with the following syntax... >>> >>>  hash = attribute hash { hash-list } >>>  hash-list = # ( token ":" 1*HEX ) >>> >>> The token and HEX productions are defined by RFC2616... >>> >>> The spec would defer to the existing IANA registry for hash functions >>> to define the "tokens" >>> >>> This would result in a syntax of... >>> >>>  hash="md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc" >>> >>> This seem acceptable to everyone? >>> >>> - James >>> >>> On Sat, May 15, 2010 at 11:46 PM, Sam Johnston wrote: >>> > James, >>> > In consideration o... >> > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Mon May 17 13:25:39 2010 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 69AE128C0F7 for ; Mon, 17 May 2010 13:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.482 X-Spam-Level: * X-Spam-Status: No, score=1.482 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 utg+wmqtTgjL for ; Mon, 17 May 2010 13:25:37 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3A8CF3A6B35 for ; Mon, 17 May 2010 13:24:25 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HKJ1Gf039652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2010 13:19:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4HKJ1vv039651; Mon, 17 May 2010 13:19:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-gw0-f43.google.com (mail-gw0-f43.google.com [74.125.83.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HKJ0Ql039646 for ; Mon, 17 May 2010 13:19:01 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by gwj18 with SMTP id 18so2490524gwj.16 for ; Mon, 17 May 2010 13:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=9ERjL5RtXV7N37sLbMZFigSlR1izPpjEjwKKE9x6QkY=; b=P6cB+TOI6kfTwADXKM6YD7bmATVO1uqusnzYrk73rXApjrbU+ISDdMKgQToO+B8ODT gbmaYaZWSfIEfqFcP8PI4HURxeyrfF2zfQQgtZnyBkw2H9HTKRwLxr7UBuhg1hSuLb/k C4OQPws95b44ReviXUr5D3YUp/9zvV17WyQco= 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=ikvXbvssZxtZdLe2aH0PU9zWpQP7FOyWozDEGhBTFxkLRBWN4gglJd5whcRfo3aDo/ rDOGeybFYJ9QVrN846v61Mx4CJGqru9JaRTLx44IU2LS4vcq6q4mO7ffSFEsgTYZzBP0 IYfd/6EQTB2z0uargnV99dJrRxZFLav7iRhjM= MIME-Version: 1.0 Received: by 10.101.133.38 with SMTP id k38mr6981959ann.162.1274127539774; Mon, 17 May 2010 13:18:59 -0700 (PDT) Received: by 10.100.154.20 with HTTP; Mon, 17 May 2010 13:18:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 May 2010 16:18:59 -0400 X-Google-Sender-Auth: qizvHHPubB3-2iUY1DWJyyaZmK4 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Bob Wyman To: James Snell Cc: Peter Keane , Sam Johnston , Atom-Syntax , Richard Salz Content-Type: multipart/alternative; boundary=0016e68ee2bd6826230486cfef7d Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0016e68ee2bd6826230486cfef7d Content-Type: text/plain; charset=ISO-8859-1 I'm curious about the vigor with which you seem to be denying the utility of hash functions in integrity checking when you write: hash attribute values MUST be considered to be strictly advisory and cannot be used reliably as an end-to-end integrity check. I am, of course, aware of the limitations of both hash functions and end-to-end links, but it seems to me that the real risk here is limited to false-negatives. (i.e. If hash values don't match, I can't really be sure that I haven't linked to the correct resource.) However, it seems like the risk of false-positives is no greater than in any other hash-based system. (i.e. if the hash values do match, then I've can be reasonably, but not completely, assured of integrity.) I think I understand the standard issues. Is there something more exotic that I'm missing? bob wyman On Mon, May 17, 2010 at 3:47 PM, James Snell wrote: > Ok, draft is updated with the new syntax for the hash attribute. > > http://www.ietf.org/staging/draft-snell-atompub-link-extensions-05.txt > > There is also one additional 'media' attribute added. I wanted to wait > to add it until after I was sure the other three attributes were fine. > The 'media' attribute serves the same purpose as the 'media' attribute > on HTML5 links... the value is a media query. For example: > > > > The use case is to be able to provide multiple links targeted at > specific types of media... e.g. screen, print, mobile devices, etc. > > Another change that I am contemplating making is introducing a new > child element for the atom:link element that would allow it to serve > the same basic purpose as the GData feedLink and entryLink elements > except with greater flexibility... specifically, it would allow a > representation of the linked resource to be dropped directly into the > link element, e.g. > > > this is a representation of the data > > > > abc...def== > > > > > ... > > > > Or something along those lines. > > Thoughts? > > - James > > On Sun, May 16, 2010 at 10:44 PM, Peter Keane > wrote: > > On Sun, May 16, 2010 at 11:00 PM, Sam Johnston wrote: > >> Are the commas earning their keep? If they're unnecessary then remove > them, > >> otherwise LGTM. > >> Sam > > > > I was going to ask the same question. (re: the commas) > > > > --peter > > > >> > >> On Mon, May 17, 2010 at 7:36 AM, Bob Wyman wrote: > >>> > >>> +1 LGTM > >>> > >>> On May 16, 2010 11:29 PM, "James Snell" wrote: > >>> > >>> Ok, although I seriously dislike having to do additional parsing on > >>> attribute values, the arguments made so far are valid and parsing hex > >>> encoded hash digests is -- fortunately -- quite simple to do. So let's > >>> go with the following syntax... > >>> > >>> hash = attribute hash { hash-list } > >>> hash-list = # ( token ":" 1*HEX ) > >>> > >>> The token and HEX productions are defined by RFC2616... > >>> > >>> The spec would defer to the existing IANA registry for hash functions > >>> to define the "tokens" > >>> > >>> This would result in a syntax of... > >>> > >>> hash="md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc" > >>> > >>> This seem acceptable to everyone? > >>> > >>> - James > >>> > >>> On Sat, May 15, 2010 at 11:46 PM, Sam Johnston wrote: > >>> > James, > >>> > In consideration o... > >> > > > > > > -- > - James Snell > http://www.snellspace.com > jasnell@gmail.com > --0016e68ee2bd6826230486cfef7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm curious about the vigor with which you seem to be denying the utili= ty of hash functions in integrity checking when you write:
hash =
attribute values MUST be considered to be strictly advisory and cannot be u=
sed reliably as an end-to-end integrity check.
I am, of course, aware of the limitations of= both hash functions and end-to-end links, but it seems to me that the real= risk here is limited to false-negatives. (i.e. If hash values don't ma= tch, I can't really be sure that I haven't linked to the correct re= source.) However, it seems like the risk of false-positives is no greater t= han in any other hash-based system. (i.e. if the hash values do match, then= I've can be reasonably, but not completely, assured of integrity.)=A0<= /div>
I think I understand the standard issues. Is there something more exot= ic that I'm missing?

bob wyman

<= br>
On Mon, May 17, 2010 at 3:47 PM, James Snell = <jasnell@gmail.co= m> wrote:
Ok, draft is updated with the new syntax fo= r the hash attribute.

=A0http://www.ietf.org/staging/draft-snell-atomp= ub-link-extensions-05.txt

There is also one additional 'media' attribute added. I wanted to w= ait
to add it until after I was sure the other three attributes were fine.
The 'media' attribute serves the same purpose as the 'media'= ; attribute
on HTML5 links... the value is a media query. For example:

=A0<link href=3D"foo" media=3D"handheld and (min-width = =3D 20cm)" />

The use case is to be able to provide multiple links targeted at
specific types of media... e.g. screen, print, mobile devices, etc.

Another change that I am contemplating making is introducing a new
child element for the atom:link element that would allow it to serve
the same basic purpose as the GData feedLink and entryLink elements
except with greater flexibility... specifically, it would allow a
representation of the linked resource to be dropped directly into the
link element, e.g.

<link rel=3D"alternate" href=3D"foo" type=3D"te= xt/plain">
=A0<data type=3D"text">this is a representation of the dat= a</data>
</link>

<link rel=3D"alternate" href=3D"foo" type=3D"im= age/jpeg">
=A0<data type=3D"encoded">abc...def=3D=3D</data> <= ;!-- base64 -->
</link>

<link rel=3D"alternate" href=3D"foo" type=3D"ap= plication/atom+xml">
=A0<data type=3D"markup">
=A0 =A0<feed>...</feed>
=A0</data>
</link>

Or something along those lines.

Thoughts?

- James

On Sun, May 16, 2010 at 10:44 PM, Peter Keane <pkeane@mail.utexas.edu> wrote:
> On Sun, May 16, 2010 at 11:00 PM, Sam Johnston <samj@samj.net> wrote:
>> Are the commas earning their keep? If they're unnecessary then= remove them,
>> otherwise LGTM.
>> Sam
>
> I was going to ask the same question. (re: the commas)
>
> --peter
>
>>
>> On Mon, May 17, 2010 at 7:36 AM, Bob Wyman <bob@wyman.us> wrote:
>>>
>>> +1 LGTM
>>>
>>> On May 16, 2010 11:29 PM, "James Snell" <jasnell@gmail.com> wrote:
>>>
>>> Ok, although I seriously dislike having to do additional parsi= ng on
>>> attribute values, the arguments made so far are valid and pars= ing hex
>>> encoded hash digests is -- fortunately -- quite simple to do. = So let's
>>> go with the following syntax...
>>>
>>> =A0hash =3D attribute hash { hash-list }
>>> =A0hash-list =3D # ( token ":" 1*HEX )
>>>
>>> The token and HEX productions are defined by RFC2616...
>>>
>>> The spec would defer to the existing IANA registry for hash fu= nctions
>>> to define the "tokens"
>>>
>>> This would result in a syntax of...
>>>
>>> =A0hash=3D"md5:abc...xyz, sha-1:123...567, sha-512:xyz...= abc"
>>>
>>> This seem acceptable to everyone?
>>>
>>> - James
>>>
>>> On Sat, May 15, 2010 at 11:46 PM, Sam Johnston <samj@samj.net> wrote:
>>> > James,
>>> > In consideration o...
>>
>



--

--0016e68ee2bd6826230486cfef7d-- From owner-atom-syntax@mail.imc.org Mon May 17 13:45:41 2010 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 EE60E28C132 for ; Mon, 17 May 2010 13:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.089 X-Spam-Level: * X-Spam-Status: No, score=1.089 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeHl40soC7Mu for ; Mon, 17 May 2010 13:45:40 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A259A28C0F7 for ; Mon, 17 May 2010 13:45:39 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HKfcjT041665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2010 13:41:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4HKfcoF041664; Mon, 17 May 2010 13:41:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HKfawk041658 for ; Mon, 17 May 2010 13:41:36 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by vws15 with SMTP id 15so3935599vws.16 for ; Mon, 17 May 2010 13:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=s1D2+tp8BZD+rgBbL+/jmDv0KzQoxcTTKErM5Y05JOA=; b=mNJ7Ro3QjZ13FSWcLRsqQ8eBgX3sJ2hCfFCb2i3aDliM9WawOy9oFQhZ8UwEMQhkIO zPNRWmCDempsD9xGPQfuqgWtKTtIz0KYIJfzDTCRqnspeJ5sO9dhl0I2NZQb7+7P5z7Y K/BUdtuBJqIcRnoIt0AoV+f3ANL2NYgOUpVeM= 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=rhFxT9l3h2OUsfTGycDOs7+//4BG6W00Y2K674VcT3u974h8WDqjG/7++NQUj/qcDd wtWT9U/mLgq0ZR+x1eNt9k2XanaA4g30ibTnUeVXb+c1Zq7vJr709s8Ylh7qccXhgAU/ isCI7KY2JFGKv22Yi3Rr4Ws8RtiEXDOnEhfCM= MIME-Version: 1.0 Received: by 10.229.227.10 with SMTP id iy10mr1255789qcb.48.1274128894981; Mon, 17 May 2010 13:41:34 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Mon, 17 May 2010 13:41:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 May 2010 13:41:34 -0700 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: James Snell To: Bob Wyman Cc: Peter Keane , Sam Johnston , Atom-Syntax , Richard Salz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4HKfawk041660 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The key challenge is that the digests contained in the atom:link cannot be viewed as being authoritative and only reflect a point-in-time value that may only be true for the producer of the Atom feed. There are many factors which influence whether the same hash value can be generated for the linked resource. If the hash-value happens to match... fantastic. If the hash-value doesn't match, then the feed consumer knows that they need to do more work to figure out what happened... including performing a more authoritative check of the resource. On Mon, May 17, 2010 at 1:18 PM, Bob Wyman wrote: > I'm curious about the vigor with which you seem to be denying the utility of > hash functions in integrity checking when you write: > > hash attribute values MUST be considered to be strictly advisory and cannot > be used reliably as an end-to-end integrity check. > > I am, of course, aware of the limitations of both hash functions and > end-to-end links, but it seems to me that the real risk here is limited to > false-negatives. (i.e. If hash values don't match, I can't really be sure > that I haven't linked to the correct resource.) However, it seems like the > risk of false-positives is no greater than in any other hash-based system. > (i.e. if the hash values do match, then I've can be reasonably, but not > completely, assured of integrity.) > I think I understand the standard issues. Is there something more exotic > that I'm missing? > bob wyman > > On Mon, May 17, 2010 at 3:47 PM, James Snell wrote: >> >> Ok, draft is updated with the new syntax for the hash attribute. >> >>  http://www.ietf.org/staging/draft-snell-atompub-link-extensions-05.txt >> >> There is also one additional 'media' attribute added. I wanted to wait >> to add it until after I was sure the other three attributes were fine. >> The 'media' attribute serves the same purpose as the 'media' attribute >> on HTML5 links... the value is a media query. For example: >> >>   >> >> The use case is to be able to provide multiple links targeted at >> specific types of media... e.g. screen, print, mobile devices, etc. >> >> Another change that I am contemplating making is introducing a new >> child element for the atom:link element that would allow it to serve >> the same basic purpose as the GData feedLink and entryLink elements >> except with greater flexibility... specifically, it would allow a >> representation of the linked resource to be dropped directly into the >> link element, e.g. >> >> >>  this is a representation of the data >> >> >> >>  abc...def== >> >> >> >>   >>    ... >>   >> >> >> Or something along those lines. >> >> Thoughts? >> >> - James >> >> On Sun, May 16, 2010 at 10:44 PM, Peter Keane >> wrote: >> > On Sun, May 16, 2010 at 11:00 PM, Sam Johnston wrote: >> >> Are the commas earning their keep? If they're unnecessary then remove >> >> them, >> >> otherwise LGTM. >> >> Sam >> > >> > I was going to ask the same question. (re: the commas) >> > >> > --peter >> > >> >> >> >> On Mon, May 17, 2010 at 7:36 AM, Bob Wyman wrote: >> >>> >> >>> +1 LGTM >> >>> >> >>> On May 16, 2010 11:29 PM, "James Snell" wrote: >> >>> >> >>> Ok, although I seriously dislike having to do additional parsing on >> >>> attribute values, the arguments made so far are valid and parsing hex >> >>> encoded hash digests is -- fortunately -- quite simple to do. So let's >> >>> go with the following syntax... >> >>> >> >>>  hash = attribute hash { hash-list } >> >>>  hash-list = # ( token ":" 1*HEX ) >> >>> >> >>> The token and HEX productions are defined by RFC2616... >> >>> >> >>> The spec would defer to the existing IANA registry for hash functions >> >>> to define the "tokens" >> >>> >> >>> This would result in a syntax of... >> >>> >> >>>  hash="md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc" >> >>> >> >>> This seem acceptable to everyone? >> >>> >> >>> - James >> >>> >> >>> On Sat, May 15, 2010 at 11:46 PM, Sam Johnston wrote: >> >>> > James, >> >>> > In consideration o... >> >> >> > >> >> >> >> -- >> - James Snell >>  http://www.snellspace.com >>  jasnell@gmail.com > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Mon May 17 14:06:23 2010 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 815D128C148 for ; Mon, 17 May 2010 14:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.718 X-Spam-Level: * X-Spam-Status: No, score=1.718 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 RQYRVkBfWdL0 for ; Mon, 17 May 2010 14:06:21 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 884803A698F for ; Mon, 17 May 2010 14:06:20 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HL08wu042739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2010 14:00:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4HL08ST042738; Mon, 17 May 2010 14:00:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-gy0-f171.google.com (mail-gy0-f171.google.com [209.85.160.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HL07Av042730 for ; Mon, 17 May 2010 14:00:07 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by gyf3 with SMTP id 3so2360290gyf.16 for ; Mon, 17 May 2010 14:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=P8jg0/sU53D4AUSApsHB77dyv3nGDTiU9msT8VarVMs=; b=YuPL9nfFxdkBDz6IEqgWaZmVrVF13fOpYRxLhASyi7noRAkfY5bu3zxwNrM1hZJnBn 414RMhJEXGH5P6qoyCzymYnTx4k/zpFCi41rt+ODwwqaumc7A6h4n39KLxkw2dNx1uX9 a18C60ay8noupN8IqR+aj5QyDhj2hF86sjZaQ= 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=buyHI+yRDUdRRAfjO2UPzGROdy+/tPmniWydytrBojuJ8EOHJ8rALyhPOep/49xpQJ m2NzeRFn2tLIsva+2Lz4+YCS1ehoxKlCTN58JcGPWyoIf0XhY+SS0401ptaXghi3E8YI NWVu/EMXbcUe0s+sgTwJpTn0LIFlV/vSWOf7M= MIME-Version: 1.0 Received: by 10.100.243.25 with SMTP id q25mr6679130anh.165.1274130006312; Mon, 17 May 2010 14:00:06 -0700 (PDT) Received: by 10.100.154.20 with HTTP; Mon, 17 May 2010 14:00:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 May 2010 17:00:06 -0400 X-Google-Sender-Auth: Of3mjyDTK2f28xqGkp260O94XHU Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: Bob Wyman To: James Snell Cc: Peter Keane , Sam Johnston , Atom-Syntax , Richard Salz Content-Type: multipart/alternative; boundary=001636c927b26c8e2e0486d0822b Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636c927b26c8e2e0486d0822b Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 17, 2010 at 4:41 PM, James Snell wrote: > The key challenge is that the digests contained in the atom:link > cannot be viewed as being authoritative and only reflect a > point-in-time value that may only be true for the producer of the Atom > feed. Actually, for the applications that I'm most interested in at the moment, such "point-in-time" values are exactly what I want. I want to be able to point to a specific version of a resource and say that if you read something that I did not, then you're not looking at the same version of the document that I saw. The best example would be something like a contract, petition or poll that I might "sign" by-reference. My signature would only be "valid" if the resource linked to is exactly the same as it was at the point in time when I generated the hash value that I later included in a signed Atom entry. bob wyman > There are many factors which influence whether the same hash > value can be generated for the linked resource. If the hash-value > happens to match... fantastic. If the hash-value doesn't match, then > the feed consumer knows that they need to do more work to figure out > what happened... including performing a more authoritative check of > the resource. > > > On Mon, May 17, 2010 at 1:18 PM, Bob Wyman wrote: > > I'm curious about the vigor with which you seem to be denying the utility > of > > hash functions in integrity checking when you write: > > > > hash attribute values MUST be considered to be strictly advisory and > cannot > > be used reliably as an end-to-end integrity check. > > > > I am, of course, aware of the limitations of both hash functions and > > end-to-end links, but it seems to me that the real risk here is limited > to > > false-negatives. (i.e. If hash values don't match, I can't really be sure > > that I haven't linked to the correct resource.) However, it seems like > the > > risk of false-positives is no greater than in any other hash-based > system. > > (i.e. if the hash values do match, then I've can be reasonably, but not > > completely, assured of integrity.) > > I think I understand the standard issues. Is there something more exotic > > that I'm missing? > > bob wyman > > > > On Mon, May 17, 2010 at 3:47 PM, James Snell wrote: > >> > >> Ok, draft is updated with the new syntax for the hash attribute. > >> > >> http://www.ietf.org/staging/draft-snell-atompub-link-extensions-05.txt > >> > >> There is also one additional 'media' attribute added. I wanted to wait > >> to add it until after I was sure the other three attributes were fine. > >> The 'media' attribute serves the same purpose as the 'media' attribute > >> on HTML5 links... the value is a media query. For example: > >> > >> > >> > >> The use case is to be able to provide multiple links targeted at > >> specific types of media... e.g. screen, print, mobile devices, etc. > >> > >> Another change that I am contemplating making is introducing a new > >> child element for the atom:link element that would allow it to serve > >> the same basic purpose as the GData feedLink and entryLink elements > >> except with greater flexibility... specifically, it would allow a > >> representation of the linked resource to be dropped directly into the > >> link element, e.g. > >> > >> > >> this is a representation of the data > >> > >> > >> > >> abc...def== > >> > >> > >> > >> > >> ... > >> > >> > >> > >> Or something along those lines. > >> > >> Thoughts? > >> > >> - James > >> > >> On Sun, May 16, 2010 at 10:44 PM, Peter Keane > >> wrote: > >> > On Sun, May 16, 2010 at 11:00 PM, Sam Johnston wrote: > >> >> Are the commas earning their keep? If they're unnecessary then remove > >> >> them, > >> >> otherwise LGTM. > >> >> Sam > >> > > >> > I was going to ask the same question. (re: the commas) > >> > > >> > --peter > >> > > >> >> > >> >> On Mon, May 17, 2010 at 7:36 AM, Bob Wyman wrote: > >> >>> > >> >>> +1 LGTM > >> >>> > >> >>> On May 16, 2010 11:29 PM, "James Snell" wrote: > >> >>> > >> >>> Ok, although I seriously dislike having to do additional parsing on > >> >>> attribute values, the arguments made so far are valid and parsing > hex > >> >>> encoded hash digests is -- fortunately -- quite simple to do. So > let's > >> >>> go with the following syntax... > >> >>> > >> >>> hash = attribute hash { hash-list } > >> >>> hash-list = # ( token ":" 1*HEX ) > >> >>> > >> >>> The token and HEX productions are defined by RFC2616... > >> >>> > >> >>> The spec would defer to the existing IANA registry for hash > functions > >> >>> to define the "tokens" > >> >>> > >> >>> This would result in a syntax of... > >> >>> > >> >>> hash="md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc" > >> >>> > >> >>> This seem acceptable to everyone? > >> >>> > >> >>> - James > >> >>> > >> >>> On Sat, May 15, 2010 at 11:46 PM, Sam Johnston > wrote: > >> >>> > James, > >> >>> > In consideration o... > >> >> > >> > > >> > >> > >> > >> -- > >> - James Snell > >> http://www.snellspace.com > >> jasnell@gmail.com > > > > > > > > -- > - James Snell > http://www.snellspace.com > jasnell@gmail.com > --001636c927b26c8e2e0486d0822b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, May 17, 2010 at 4:41 PM, James S= nell <jasnell@gma= il.com> wrote:
The key challenge is that the digests contained in the atom:link
cannot be viewed as being authoritative and only reflect a
point-in-time value that may only be true for the producer of the Atom
feed.
Actually, for the applications that I'm most int= erested in at the moment, such "point-in-time" values are exactly= what I want. I want to be able to point to a specific version of a resourc= e and say that if you read something that I did not, then you're not lo= oking at the same version of the document that I saw. The best example woul= d be something like a contract,=A0petition or poll=A0that I might "sig= n" by-reference. My signature would only be "valid" if the r= esource linked to is exactly the same as it was at the point in time when I= generated the hash value that I later included in a signed Atom entry.

bob wyman

=A0
There are many factors which influence whether the sa= me hash
value can be generated for the linked resource. If the hash-value
happens to match... fantastic. If the hash-value doesn't match, then the feed consumer knows that they need to do more work to figure out
what happened... including performing a more authoritative check of
the resource.


On Mon, May 17, 2010 at 1:18 PM, Bob Wyman <bob@wyman.us> wrote:
> I'm curious about the vigor with which you seem to be denying the = utility of
> hash functions in integrity checking when you write:
>
> hash attribute values MUST be considered to be strictly advisory and c= annot
> be used reliably as an end-to-end integrity check.
>
> I am, of course, aware of the limitations of both hash functions and > end-to-end links, but it seems to me that the real risk here is limite= d to
> false-negatives. (i.e. If hash values don't match, I can't rea= lly be sure
> that I haven't linked to the correct resource.) However, it seems = like the
> risk of false-positives is no greater than in any other hash-based sys= tem.
> (i.e. if the hash values do match, then I've can be reasonably, bu= t not
> completely, assured of integrity.)
> I think I understand the standard issues. Is there something more exot= ic
> that I'm missing?
> bob wyman
>
> On Mon, May 17, 2010 at 3:47 PM, James Snell <jasnell@gmail.com> wrote:
>>
>> Ok, draft is updated with the new syntax for the hash attribute. >>
>> =A0http://www.ietf.org/staging/draft-sne= ll-atompub-link-extensions-05.txt
>>
>> There is also one additional 'media' attribute added. I wa= nted to wait
>> to add it until after I was sure the other three attributes were f= ine.
>> The 'media' attribute serves the same purpose as the '= media' attribute
>> on HTML5 links... the value is a media query. For example:
>>
>> =A0<link href=3D"foo" media=3D"handheld and (min= -width =3D 20cm)" />
>>
>> The use case is to be able to provide multiple links targeted at >> specific types of media... e.g. screen, print, mobile devices, etc= .
>>
>> Another change that I am contemplating making is introducing a new=
>> child element for the atom:link element that would allow it to ser= ve
>> the same basic purpose as the GData feedLink and entryLink element= s
>> except with greater flexibility... specifically, it would allow a<= br> >> representation of the linked resource to be dropped directly into = the
>> link element, e.g.
>>
>> <link rel=3D"alternate" href=3D"foo" type= =3D"text/plain">
>> =A0<data type=3D"text">this is a representation of= the data</data>
>> </link>
>>
>> <link rel=3D"alternate" href=3D"foo" type= =3D"image/jpeg">
>> =A0<data type=3D"encoded">abc...def=3D=3D</data= > <!-- base64 -->
>> </link>
>>
>> <link rel=3D"alternate" href=3D"foo" type= =3D"application/atom+xml">
>> =A0<data type=3D"markup">
>> =A0 =A0<feed>...</feed>
>> =A0</data>
>> </link>
>>
>> Or something along those lines.
>>
>> Thoughts?
>>
>> - James
>>
>> On Sun, May 16, 2010 at 10:44 PM, Peter Keane <pkeane@mail.utexas.edu>
>> wrote:
>> > On Sun, May 16, 2010 at 11:00 PM, Sam Johnston <samj@samj.net> wrote:
>> >> Are the commas earning their keep? If they're unneces= sary then remove
>> >> them,
>> >> otherwise LGTM.
>> >> Sam
>> >
>> > I was going to ask the same question. (re: the commas)
>> >
>> > --peter
>> >
>> >>
>> >> On Mon, May 17, 2010 at 7:36 AM, Bob Wyman <bob@wyman.us> wrote:
>> >>>
>> >>> +1 LGTM
>> >>>
>> >>> On May 16, 2010 11:29 PM, "James Snell" <= ;jasnell@gmail.com> wrote:
>> >>>
>> >>> Ok, although I seriously dislike having to do additio= nal parsing on
>> >>> attribute values, the arguments made so far are valid= and parsing hex
>> >>> encoded hash digests is -- fortunately -- quite simpl= e to do. So let's
>> >>> go with the following syntax...
>> >>>
>> >>> =A0hash =3D attribute hash { hash-list }
>> >>> =A0hash-list =3D # ( token ":" 1*HEX )
>> >>>
>> >>> The token and HEX productions are defined by RFC2616.= ..
>> >>>
>> >>> The spec would defer to the existing IANA registry fo= r hash functions
>> >>> to define the "tokens"
>> >>>
>> >>> This would result in a syntax of...
>> >>>
>> >>> =A0hash=3D"md5:abc...xyz, sha-1:123...567, sha-5= 12:xyz...abc"
>> >>>
>> >>> This seem acceptable to everyone?
>> >>>
>> >>> - James
>> >>>
>> >>> On Sat, May 15, 2010 at 11:46 PM, Sam Johnston <samj@samj.net> wrote:
>> >>> > James,
>> >>> > In consideration o...
>> >>
>> >
>>
>>
>>
>> --
>> - James Snell
>> =A0http://= www.snellspace.com
>> =A0jasnell@gmail.com
>
>



--

--001636c927b26c8e2e0486d0822b-- From atompub-archive@megatron.ietf.org Mon May 17 14:09:21 2010 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 1DFEF28C140 for ; Mon, 17 May 2010 14:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.63 X-Spam-Level: X-Spam-Status: No, score=-9.63 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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, 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 h1bx0ASKhFdA for ; Mon, 17 May 2010 14:09:15 -0700 (PDT) Received: from chello089076081230.chello.pl (chello089076081230.chello.pl [89.76.81.230]) by core3.amsl.com (Postfix) with SMTP id 5CBFD3A6AEE for ; Mon, 17 May 2010 14:09:13 -0700 (PDT) From: RX-Store Subject: Your Future Order with 79% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100517210914.5CBFD3A6AEE@core3.amsl.com> Date: Mon, 17 May 2010 14:09:13 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://barrecord.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 30031 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 02423 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 04841 is unauthorized. 85089

From owner-atom-syntax@mail.imc.org Mon May 17 14:16:05 2010 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 DD5893A69DC for ; Mon, 17 May 2010 14:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8D1a0kkoGff for ; Mon, 17 May 2010 14:16:05 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CEC5F3A6AE7 for ; Mon, 17 May 2010 14:15:43 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HLCjdZ043527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2010 14:12:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4HLCji4043526; Mon, 17 May 2010 14:12:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HLChpX043521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 May 2010 14:12:45 -0700 (MST) (envelope-from ddooss@wp.pl) Received: (wp-smtpd smtp.wp.pl 13104 invoked from network); 17 May 2010 23:12:42 +0200 Received: from 87-205-159-240.adsl.inetia.pl (HELO [192.168.1.1]) (ddooss@[87.205.159.240]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 17 May 2010 23:12:42 +0200 Message-ID: <4BF1B149.90501@wp.pl> Date: Mon, 17 May 2010 23:12:41 +0200 From: Dominik Tomaszuk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Shredder/3.0.3pre MIME-Version: 1.0 To: James Snell CC: Atom-Syntax Subject: Re: Link Extensions. Need "md5" or some kind of hash. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0U00000 [QSId] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 17.05.2010 21:47, James Snell wrote: > The 'media' attribute serves the same purpose as the 'media' attribute > on HTML5 links... the value is a media query. I propose 'langhref' attribute (equivalent to HTML5 'langhref'). This attribute specifies the primary language of the resource designated by href. It is purely advisory. The value must be a valid BCP 47 [1] language tag. [1] http://www.ietf.org/rfc/bcp/bcp47.txt Regards, Dominik Tomaszuk From owner-atom-syntax@mail.imc.org Mon May 17 14:16:10 2010 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 3A5A43A69BD for ; Mon, 17 May 2010 14:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBbPMJxajWdW for ; Mon, 17 May 2010 14:16:09 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CEC0C3A6A65 for ; Mon, 17 May 2010 14:15:43 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HLBgSD043490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2010 14:11:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4HLBgkQ043489; Mon, 17 May 2010 14:11:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HLBeJc043480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 May 2010 14:11:42 -0700 (MST) (envelope-from ddooss@wp.pl) Received: (wp-smtpd smtp.wp.pl 25393 invoked from network); 17 May 2010 23:11:34 +0200 Received: from 87-205-159-240.adsl.inetia.pl (HELO [192.168.1.1]) (ddooss@[87.205.159.240]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 17 May 2010 23:11:34 +0200 Message-ID: <4BF1B105.4090105@wp.pl> Date: Mon, 17 May 2010 23:11:33 +0200 From: Dominik Tomaszuk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Shredder/3.0.3pre MIME-Version: 1.0 To: James Snell CC: Atom-Syntax Subject: Re: Link Extensions. Need "md5" or some kind of hash. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [ARLd] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 17.05.2010 21:47, James Snell wrote: > > this is a representation of the data > It can be used with XInclude, e.g. > > > > ... > > Or > > abc...def== > There are many methods of encoding. It should be declare Base16, Base32, or Base64 [1]. [1] http://www.ietf.org/rfc/rfc3548.txt Regards, Dominik Tomaszuk From agentx-archive@lists.ietf.org Mon May 17 14:28:09 2010 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 911433A6B64 for ; Mon, 17 May 2010 14:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.043 X-Spam-Level: X-Spam-Status: No, score=-10.043 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, 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 wq+9BLacSfvF for ; Mon, 17 May 2010 14:28:02 -0700 (PDT) Received: from afc34.nl (unknown [206.248.119.74]) by core3.amsl.com (Postfix) with SMTP id 7D1C83A68F9 for ; Mon, 17 May 2010 14:27:55 -0700 (PDT) From: RX-Store Subject: Electronic Discount Code 76% for atompub-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100517212759.7D1C83A68F9@core3.amsl.com> Date: Mon, 17 May 2010 14:27:55 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://othermight.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 43620 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 84747 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 51404 is unauthorized. 61853

From owner-atom-syntax@mail.imc.org Mon May 17 15:06:34 2010 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 70B213A6880 for ; Mon, 17 May 2010 15:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.795 X-Spam-Level: X-Spam-Status: No, score=0.795 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpdHGGQl9hia for ; Mon, 17 May 2010 15:06:33 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 851163A687A for ; Mon, 17 May 2010 15:06:30 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HM1Btb046445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2010 15:01:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4HM1Bcg046444; Mon, 17 May 2010 15:01:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.221.179]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HM1Av2046438 for ; Mon, 17 May 2010 15:01:10 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk9 with SMTP id 9so8308586qyk.2 for ; Mon, 17 May 2010 15:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=KdMN1jsSpcl5xGGByXuC6glOex2VmjlYfytMPJY/kuE=; b=q1T2OoQ2dyrBIQff+bBdosJPyAocgTl9xWKITeyDJZe6TtGd+YfgBMKSUeGVPV2XH8 C0xGt3SggljumgsEp8p4jdCt9xZza4md1938JeSWM36xi5yPE48nCx4nYCiE1HZAJiMC GFLUje7JVet3x4/5YIKpEIb/F8MlK4kcTMMFU= 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; b=wsOpRddKJ1UaMzk98azzDIGAZ4kJ9h5UWvXN7lZRgdYzk7SiZZFlJKD4EdtkZDmKk5 SCbQ1D85DqlZDWtAM1XBevrbfUN7dBVnouN3PGsB9P+cKslLnAF/vFcIM1K+5LDltDow NGlmSIqap3A8Sgxzbr84jmuCJ5R7pzTYKOVQs= MIME-Version: 1.0 Received: by 10.224.110.11 with SMTP id l11mr3200000qap.334.1274133669118; Mon, 17 May 2010 15:01:09 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Mon, 17 May 2010 15:01:08 -0700 (PDT) In-Reply-To: <4BF1B149.90501@wp.pl> References: <4BF1B149.90501@wp.pl> Date: Mon, 17 May 2010 15:01:08 -0700 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: James Snell To: Dominik Tomaszuk Cc: Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: atom:link already has an hreflang attribute for this purpose. On Mon, May 17, 2010 at 2:12 PM, Dominik Tomaszuk wrote: > On 17.05.2010 21:47, James Snell wrote: >> >> The 'media' attribute serves the same purpose as the 'media' attribute >> on HTML5 links... the value is a media query. > > I propose 'langhref' attribute (equivalent to HTML5 'langhref'). This > attribute specifies the primary language of the resource designated by href. > It is purely advisory. The value must be a valid BCP 47 [1] language tag. > > [1] http://www.ietf.org/rfc/bcp/bcp47.txt > > Regards, > > Dominik Tomaszuk > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Mon May 17 16:22:53 2010 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 B90153A6B30 for ; Mon, 17 May 2010 16:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.074 X-Spam-Level: * X-Spam-Status: No, score=1.074 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TwhAYWWBgxn for ; Mon, 17 May 2010 16:22:50 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 815773A6B37 for ; Mon, 17 May 2010 16:22:25 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HNGSWk049793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2010 16:16:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4HNGSbX049792; Mon, 17 May 2010 16:16:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.221.179]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HNGQq6049785 for ; Mon, 17 May 2010 16:16:26 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk9 with SMTP id 9so8410310qyk.2 for ; Mon, 17 May 2010 16:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TPlJXDrMBt11LrntA8JrgVSm6eiqgYApc4xtyZqkwYs=; b=Cxy+V2mWuzkpgYfsdGB/kJwndCEEgJ56XVjXucQDlWhvsxHnOcLZckr5/b3q51IsCf ndZXm5Zkfu2M8fRZ7l/yXpL71KUTaYra0Jl3kIf6jyiplaEnF4+CoRRGUft3XrdkyJ+m xFTpsB1n6ITMvdBLSU+9pM/KCahz56CVOHTzA= 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=FNvKZNGnXVJIIXbRkGkdfGcQRcMJLqqUBE027O4g9wV6ZAScp1dAcpDVNQwEPhgIev gZvpgNx7lcNnHR1uhKTn9OJTnOXOLV35BKnMIT6fyZeeAX5RjZ0MTmJ97Knn/3HRHPtT tiXhQUE+CJjIv/yUpOuhOzZEsFz7K1n8eg0vE= MIME-Version: 1.0 Received: by 10.229.242.65 with SMTP id lh1mr446600qcb.151.1274138185047; Mon, 17 May 2010 16:16:25 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Mon, 17 May 2010 16:16:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 May 2010 16:16:24 -0700 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: James Snell To: Bob Wyman Cc: Peter Keane , Sam Johnston , Atom-Syntax , Richard Salz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4HNGRq6049786 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Right, that point-in-time quality is what makes this attribute most useful... it does not, however, make this a reliable integrity check. The attribute allows a feed producer to describe the state of the resource at the time the link was created... which is definitely something that has been missing to this point. This becomes even more important when combined with digital signature scenarios. That said however, it has to be acknowledged that these hash digests simply are not authoritative enough to be used as a reliable integrity check for the resource at the time a consumer may retrieve it. On Mon, May 17, 2010 at 2:00 PM, Bob Wyman wrote: > > > On Mon, May 17, 2010 at 4:41 PM, James Snell wrote: >> >> The key challenge is that the digests contained in the atom:link >> cannot be viewed as being authoritative and only reflect a >> point-in-time value that may only be true for the producer of the Atom >> feed. > > Actually, for the applications that I'm most interested in at the moment, > such "point-in-time" values are exactly what I want. I want to be able to > point to a specific version of a resource and say that if you read something > that I did not, then you're not looking at the same version of the document > that I saw. The best example would be something like a contract, petition or > poll that I might "sign" by-reference. My signature would only be "valid" if > the resource linked to is exactly the same as it was at the point in time > when I generated the hash value that I later included in a signed Atom > entry. > bob wyman > >> >> There are many factors which influence whether the same hash >> value can be generated for the linked resource. If the hash-value >> happens to match... fantastic. If the hash-value doesn't match, then >> the feed consumer knows that they need to do more work to figure out >> what happened... including performing a more authoritative check of >> the resource. >> >> >> On Mon, May 17, 2010 at 1:18 PM, Bob Wyman wrote: >> > I'm curious about the vigor with which you seem to be denying the >> > utility of >> > hash functions in integrity checking when you write: >> > >> > hash attribute values MUST be considered to be strictly advisory and >> > cannot >> > be used reliably as an end-to-end integrity check. >> > >> > I am, of course, aware of the limitations of both hash functions and >> > end-to-end links, but it seems to me that the real risk here is limited >> > to >> > false-negatives. (i.e. If hash values don't match, I can't really be >> > sure >> > that I haven't linked to the correct resource.) However, it seems like >> > the >> > risk of false-positives is no greater than in any other hash-based >> > system. >> > (i.e. if the hash values do match, then I've can be reasonably, but not >> > completely, assured of integrity.) >> > I think I understand the standard issues. Is there something more exotic >> > that I'm missing? >> > bob wyman >> > >> > On Mon, May 17, 2010 at 3:47 PM, James Snell wrote: >> >> >> >> Ok, draft is updated with the new syntax for the hash attribute. >> >> >> >>  http://www.ietf.org/staging/draft-snell-atompub-link-extensions-05.txt >> >> >> >> There is also one additional 'media' attribute added. I wanted to wait >> >> to add it until after I was sure the other three attributes were fine. >> >> The 'media' attribute serves the same purpose as the 'media' attribute >> >> on HTML5 links... the value is a media query. For example: >> >> >> >>   >> >> >> >> The use case is to be able to provide multiple links targeted at >> >> specific types of media... e.g. screen, print, mobile devices, etc. >> >> >> >> Another change that I am contemplating making is introducing a new >> >> child element for the atom:link element that would allow it to serve >> >> the same basic purpose as the GData feedLink and entryLink elements >> >> except with greater flexibility... specifically, it would allow a >> >> representation of the linked resource to be dropped directly into the >> >> link element, e.g. >> >> >> >> >> >>  this is a representation of the data >> >> >> >> >> >> >> >>  abc...def== >> >> >> >> >> >> >> >>   >> >>    ... >> >>   >> >> >> >> >> >> Or something along those lines. >> >> >> >> Thoughts? >> >> >> >> - James >> >> >> >> On Sun, May 16, 2010 at 10:44 PM, Peter Keane >> >> wrote: >> >> > On Sun, May 16, 2010 at 11:00 PM, Sam Johnston wrote: >> >> >> Are the commas earning their keep? If they're unnecessary then >> >> >> remove >> >> >> them, >> >> >> otherwise LGTM. >> >> >> Sam >> >> > >> >> > I was going to ask the same question. (re: the commas) >> >> > >> >> > --peter >> >> > >> >> >> >> >> >> On Mon, May 17, 2010 at 7:36 AM, Bob Wyman wrote: >> >> >>> >> >> >>> +1 LGTM >> >> >>> >> >> >>> On May 16, 2010 11:29 PM, "James Snell" wrote: >> >> >>> >> >> >>> Ok, although I seriously dislike having to do additional parsing on >> >> >>> attribute values, the arguments made so far are valid and parsing >> >> >>> hex >> >> >>> encoded hash digests is -- fortunately -- quite simple to do. So >> >> >>> let's >> >> >>> go with the following syntax... >> >> >>> >> >> >>>  hash = attribute hash { hash-list } >> >> >>>  hash-list = # ( token ":" 1*HEX ) >> >> >>> >> >> >>> The token and HEX productions are defined by RFC2616... >> >> >>> >> >> >>> The spec would defer to the existing IANA registry for hash >> >> >>> functions >> >> >>> to define the "tokens" >> >> >>> >> >> >>> This would result in a syntax of... >> >> >>> >> >> >>>  hash="md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc" >> >> >>> >> >> >>> This seem acceptable to everyone? >> >> >>> >> >> >>> - James >> >> >>> >> >> >>> On Sat, May 15, 2010 at 11:46 PM, Sam Johnston >> >> >>> wrote: >> >> >>> > James, >> >> >>> > In consideration o... >> >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> - James Snell >> >>  http://www.snellspace.com >> >>  jasnell@gmail.com >> > >> > >> >> >> >> -- >> - James Snell >>  http://www.snellspace.com >>  jasnell@gmail.com > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From area-request@lists.ietf.org Mon May 17 19:50:18 2010 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 9A4DD3A68EA for ; Mon, 17 May 2010 19:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.855 X-Spam-Level: X-Spam-Status: No, score=-14.855 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_ALMOST_IP=1.889, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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, 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 QQzzl-mh5l-E for ; Mon, 17 May 2010 19:50:12 -0700 (PDT) Received: from aeronimbus.com (adsl-3-235-36.mia.bellsouth.net [65.3.235.36]) by core3.amsl.com (Postfix) with SMTP id D113B28C0F7 for ; Mon, 17 May 2010 19:50:04 -0700 (PDT) From: RX-Store Subject: Special Discount 73% for atompub-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100518025007.D113B28C0F7@core3.amsl.com> Date: Mon, 17 May 2010 19:50:04 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://othermight.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 67448 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 58547 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 02450 is unauthorized. 82855

From atompub-archive@megatron.ietf.org Tue May 18 00:34:52 2010 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 A610F3A6845 for ; Tue, 18 May 2010 00:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.946 X-Spam-Level: X-Spam-Status: No, score=-12.946 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_XBL=3.033, RDNS_NONE=0.1, 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 CcEJ5tQoO4hs for ; Tue, 18 May 2010 00:34:46 -0700 (PDT) Received: from airmalta.com.mt (unknown [119.92.86.11]) by core3.amsl.com (Postfix) with SMTP id 353773A6823 for ; Tue, 18 May 2010 00:34:36 -0700 (PDT) From: RX-Store Subject: Please Read To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100518073440.353773A6823@core3.amsl.com> Date: Tue, 18 May 2010 00:34:36 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://barrecord.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 24801 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 12272 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 75640 is unauthorized. 95118

From owner-atom-syntax@mail.imc.org Tue May 18 01:44:47 2010 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 C39C33A6C9E for ; Tue, 18 May 2010 01:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.904 X-Spam-Level: * X-Spam-Status: No, score=1.904 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, J_CHICKENPOX_53=0.6, 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 gKmD3S7SGnq8 for ; Tue, 18 May 2010 01:44:43 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E380228C1C3 for ; Tue, 18 May 2010 01:35:53 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4I8O4Wd078121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 01:24:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4I8O4po078120; Tue, 18 May 2010 01:24:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4I8O1ZS078115 for ; Tue, 18 May 2010 01:24:02 -0700 (MST) (envelope-from lindstream@gmail.com) Received: by wye20 with SMTP id 20so2036135wye.16 for ; Tue, 18 May 2010 01:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Che4+yi4jeTBBkWzCx34FwXcXpMC2S/umXPY5JNAlyM=; b=RaTuEs/rE7CgyPwOf7KX7Oo8/rSehhlcw+h8v3LZZ2fSrGcBfThX+bzYg6HgkvC0o7 xtSN2qc9gKUZBWbrsM8ucLlFrvBxfj0Xhlpkh24KmLoqS7R5l96B4hr047603x69Zp7k IQWWV9yp3Tdd/k7JzzW9kbc166XG5v9gV7oZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Rw2WlKLUbwaR40kFobAs0VMuLI1kYMW9NSTucAcsULVWCo6fcFwFJWJtj6x14Da9Wq yZ5uscJIvWzPyE0cyZWTlBTbIKWijcv64ie1LRReKLKvArHs3kAdNAHGjFB1PBu1f2gn 19vuzchhjj3AKIwLnXplrmUJxmeVctRkHVHlc= Received: by 10.216.93.19 with SMTP id k19mr3924830wef.5.1274171040236; Tue, 18 May 2010 01:24:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.19.85 with HTTP; Tue, 18 May 2010 01:23:40 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?Niklas_Lindstr=F6m?= Date: Tue, 18 May 2010 10:23:40 +0200 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. To: James Snell Cc: Peter Keane , Sam Johnston , Bob Wyman , Atom-Syntax , Richard Salz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4I8O2ZS078116 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi James, On Mon, May 17, 2010 at 9:47 PM, James Snell wrote: > > Ok, draft is updated with the new syntax for the hash attribute. > >  http://www.ietf.org/staging/draft-snell-atompub-link-extensions-05.txt +1. Looks good. (I like the whitespace-separation too, much better than comma+opt. space.) Just a thought though. I think using the null-namespace is good, and that this updating of the Atom syntax seems very reasonable. But does the informational status of the RFC warrant such an addition to the syntax? I mean, since it seems like a very authoritative thing to do to Atom spec. > There is also one additional 'media' attribute added. I wanted to wait > to add it until after I was sure the other three attributes were fine. > The 'media' attribute serves the same purpose as the 'media' attribute > on HTML5 links... the value is a media query. For example: > >   Sounds quite good (as long as it is aligned to the HTML5 variant -- and if that one is stable). If this won't slow down the progress to an RFC I'm all for it. > The use case is to be able to provide multiple links targeted at > specific types of media... e.g. screen, print, mobile devices, etc. > > Another change that I am contemplating making is introducing a new > child element for the atom:link element that would allow it to serve > the same basic purpose as the GData feedLink and entryLink elements > except with greater flexibility... specifically, it would allow a > representation of the linked resource to be dropped directly into the > link element, e.g. > > >  this is a representation of the data > > > >  abc...def== > > > >   >    ... >   > > > Or something along those lines. I do think that this is a good idea. However, could it perhaps be better as a separate I-D (link-content-embedding or something)? While I agree that it's about link extensions, the current scope is around attributes around which I think we have reached a general consensus. I suspect that this new element might take longer to iron out and reach the same level of agreement with? (Since there have been similar propositions over the years.) Again, I'm mostly just after getting the link-extensions to an RFC state as soon as possible. (Especially since we use the older, namespaced md5-attribute in our system today, and I would prefer to defer support for this new version (null-namespace, hash) until the I-D becomes an RFC.) Thanks again for revitalising this! Best regards, Niklas From owner-atom-syntax@mail.imc.org Tue May 18 05:32:46 2010 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 6555B3A6BD2 for ; Tue, 18 May 2010 05:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_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 NFQ2H3517LTp for ; Tue, 18 May 2010 05:32:45 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id EB7F03A6C31 for ; Tue, 18 May 2010 05:31:51 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4ICQ9gG094082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 05:26:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4ICQ9h1094081; Tue, 18 May 2010 05:26:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4ICQ8oX094076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 May 2010 05:26:08 -0700 (MST) (envelope-from colm.divilly@oracle.com) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4ICPvJ9023765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 May 2010 12:25:58 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4IAIWxn022405; Tue, 18 May 2010 12:25:55 GMT Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 274956381274185453; Tue, 18 May 2010 05:24:13 -0700 Received: from [192.168.1.5] (/194.125.117.177) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 May 2010 05:23:27 -0700 Message-ID: <4BF286BB.7090708@oracle.com> Date: Tue, 18 May 2010 13:23:23 +0100 From: Colm Divilly User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: James Snell CC: nrmehtais@gmail.com, Atom-Syntax Subject: Atom Inlining (Was Link Extensions. Need "md5" or some kind of hash.) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090208.4BF2875E.006D:SCFMA4539811,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: James Snell wrote: > Another change that I am contemplating making is introducing a new > child element for the atom:link element that would allow it to serve > the same basic purpose as the GData feedLink and entryLink elements > except with greater flexibility... specifically, it would allow a > representation of the linked resource to be dropped directly into the > link element, e.g. > > > this is a representation of the data > > > > abc...def== > > > > > ... > > > > Or something along those lines. > > Thoughts? > > +1, I think this is really important, Whenever I am designing resources, I am always finding myself having to make a choice about whether to inline related content in the resource or include a hyper link to the related content. Having a consistent pattern for doing this would be beneficial. As an aside, if this approach was possible, then one could re-imagine the atom:content element as simply .... Nikunj Mehta has an unpublished draft of Atom Inline Extensions that proposes the same as what you propose [1] (the last published draft restricted the inline content types to atom resources only [2]), Nikunj care to weigh in? There was some discussion about this a while back: [3] [1] http://atom-ext.googlecode.com/svn-history/r9/trunk/draft-mehta-atom-inline.xml [2] http://tools.ietf.org/html/draft-mehta-atom-inline-01#section-2.1.1 [3] http://www.imc.org/atom-syntax/mail-archive/threads.html#21203 From owner-atom-syntax@mail.imc.org Tue May 18 08:28:20 2010 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 2CA433A6A2F for ; Tue, 18 May 2010 08:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.23 X-Spam-Level: * X-Spam-Status: No, score=1.23 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_53=0.6, 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 mIA6mk4mJhGi for ; Tue, 18 May 2010 08:28:18 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 699FC3A6BA1 for ; Tue, 18 May 2010 08:26:03 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4IFKGr2006616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 08:20:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4IFKGLT006615; Tue, 18 May 2010 08:20:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-gy0-f171.google.com (mail-gy0-f171.google.com [209.85.160.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4IFKFmg006610 for ; Tue, 18 May 2010 08:20:16 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by gyf3 with SMTP id 3so2762503gyf.16 for ; Tue, 18 May 2010 08:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7euupMmgR+P+Kk8hDsKeJOHLT2Cu2n1CDZxYdzFOjTE=; b=yB77ff164oXyNwSDzAPADQKtA2GxyRWRTgit1UMl5pl4iRKEvGQua7naLM4iHeMBd9 9iNMqkGcsPUb76dIMbqcCJTQVFpULn5ZZHRHeEVeCzbFLvyePcC6Gl5t4DXnkzEt2OTR HsJPckuiI65i2fgJa8p4y6Abm16OEPB09iEW8= 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=Yi8+8xUNAgqqrR68TirttGkeNRJRSGwjALz68Eqy4EWp/nBVUtvUPZi+BJPitwDO1M uRs98xYhifLA94tk+KEORD9TPiVVSwf0q/Qr5iShGc3Pj9wVyx+dUcwBMtLihMZuIYUC LaiftfQM5cR0HAxrMbYwIaYqFppaTcM4GLnVQ= MIME-Version: 1.0 Received: by 10.229.225.72 with SMTP id ir8mr1500533qcb.73.1274196013198; Tue, 18 May 2010 08:20:13 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Tue, 18 May 2010 08:20:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 May 2010 08:20:12 -0700 Message-ID: Subject: Re: Link Extensions. Need "md5" or some kind of hash. From: James Snell To: =?ISO-8859-1?Q?Niklas_Lindstr=F6m?= Cc: Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4IFKGmg006611 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 2010/5/18 Niklas Lindström : > Hi James, > > On Mon, May 17, 2010 at 9:47 PM, James Snell wrote: >> >> Ok, draft is updated with the new syntax for the hash attribute. >> >>  http://www.ietf.org/staging/draft-snell-atompub-link-extensions-05.txt > > +1. Looks good. (I like the whitespace-separation too, much better > than comma+opt. space.) > > Just a thought though. I think using the null-namespace is good, and > that this updating of the Atom syntax seems very reasonable. But does > the informational status of the RFC warrant such an addition to the > syntax? I mean, since it seems like a very authoritative thing to do > to Atom spec. > Eventually, yes, this should eventually make it into the standards track... for now, however, informational is appropriate. Once I'm sure the spec is complete, I'll check overall consensus on moving it to the standards track. > >> There is also one additional 'media' attribute added. I wanted to wait >> to add it until after I was sure the other three attributes were fine. >> The 'media' attribute serves the same purpose as the 'media' attribute >> on HTML5 links... the value is a media query. For example: >> >>   > > Sounds quite good (as long as it is aligned to the HTML5 variant -- > and if that one is stable). If this won't slow down the progress to an > RFC I'm all for it. > Yes, I modeled this directly off the HTML5 media attribute and intend to track that effort. HTML5 currently defers to the Media Queries specification which seems to be somewhat stable at the moment. > [snip] > I do think that this is a good idea. However, could it perhaps be > better as a separate I-D (link-content-embedding or something)? While > I agree that it's about link extensions, the current scope is around > attributes around which I think we have reached a general consensus. I > suspect that this new element might take longer to iron out and reach > the same level of agreement with? (Since there have been similar > propositions over the years.) Again, I'm mostly just after getting the > link-extensions to an RFC state as soon as possible. > > (Especially since we use the older, namespaced md5-attribute in our > system today, and I would prefer to defer support for this new version > (null-namespace, hash) until the I-D becomes an RFC.) > Yes, I agree that this would be better served by a separate I-D. The link extensions draft as it currently exists should be just about complete as it is... at least in terms of technical definition. I need to fill out additional bits such as the security concerns, etc, but I think there are enough heads nodding in the right direction to move forward on the rest. > > Thanks again for revitalising this! > > Best regards, > Niklas > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Tue May 18 12:56:39 2010 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 2E8233A6B15 for ; Tue, 18 May 2010 12:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.397 X-Spam-Level: * X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, 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 kRKPm5ECUhm7 for ; Tue, 18 May 2010 12:56:37 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 87A693A6AA5 for ; Tue, 18 May 2010 12:56:37 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4IJo4fS024011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 12:50:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4IJo4Y8024010; Tue, 18 May 2010 12:50:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4IJo4OA024005 for ; Tue, 18 May 2010 12:50:04 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk11 with SMTP id 11so3067360qyk.13 for ; Tue, 18 May 2010 12:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=X90YItDHVjKX2E76ZaGM6sefxpaBT5PcniQvJE2b9uU=; b=bBkGmdncAAD1R7cqpVlRaCC/EEsI8ACuYpxNkttFo0BuZZxmodGJQh8oADVM3H96tK 9vv0DCsJgujIrY5bxOyMyoYa7zOtPYcoxdgdBnc2dVpt+wzzL7HDLmpHQBtn6P7Buw7A +PQyjfhtS8p6GeiYpKfR3RfPFZCMbTdK/2+J4= 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=C3LuRXUsj3x9F8GlCF4lX7TlNCG5sLJpgdSRXKxgZH0euIwi6m30G88+DPCbWxw2Ct N2sR6/dHUwQjpWjE9ijs1jvy1upaCx+1OGAQtdPoyPYOM/dLM6TKWWJecHPSLp2fMTIe AlCaE8dzPWb0SKZ1PNC1G/HXeVAr5oIqMNZmQ= MIME-Version: 1.0 Received: by 10.224.27.150 with SMTP id i22mr3931033qac.183.1274212202851; Tue, 18 May 2010 12:50:02 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Tue, 18 May 2010 12:50:02 -0700 (PDT) In-Reply-To: <1B899E67-A684-4120-8925-754CEB27241D@o-micron.com> References: <4BF286BB.7090708@oracle.com> <1B899E67-A684-4120-8925-754CEB27241D@o-micron.com> Date: Tue, 18 May 2010 12:50:02 -0700 Message-ID: Subject: Re: Atom Inlining (Was Link Extensions. Need "md5" or some kind of hash.) From: James Snell To: Nikunj Mehta Cc: Colm Divilly , nrmehtais@gmail.com, Atom-Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4IJo4OA024006 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Non-Atom type support, I think, is definitely important. I also urge you to consider defining the element so that it is a part of the Atom namespace. Explosion and management of extension namespaces is going to become a significant problem as time goes on, we need to establish good practices for it now. On Tue, May 18, 2010 at 12:46 PM, Nikunj Mehta wrote: > I can brush up the I-D and add the non-Atom type support, which was contemplated but waiting for more interest to be put in. > > Nikunj > On May 18, 2010, at 5:23 AM, Colm Divilly wrote: > >> James Snell wrote: >>> Another change that I am contemplating making is introducing a new >>> child element for the atom:link element that would allow it to serve >>> the same basic purpose as the GData feedLink and entryLink elements >>> except with greater flexibility... specifically, it would allow a >>> representation of the linked resource to be dropped directly into the >>> link element, e.g. >>> >>> >>>  this is a representation of the data >>> >>> >>> >>>  abc...def== >>> >>> >>> >>>   >>>    ... >>>   >>> >>> >>> Or something along those lines. >>> >>> Thoughts? >>> >>> >> +1, I think this is really important, Whenever I am designing resources, I am always finding myself having to make a choice about whether to inline related content in the resource or include a hyper link to the related content. Having a consistent pattern for doing this would be beneficial. >> >> As an aside, if this approach was possible, then one could re-imagine the atom:content element as simply .... >> >> Nikunj Mehta has an unpublished draft of Atom Inline Extensions that proposes the same as what you propose [1] (the last published draft restricted the inline content types to atom resources only [2]),  Nikunj care to weigh in? >> >> There was some discussion about this a while back: [3] >> >> [1] http://atom-ext.googlecode.com/svn-history/r9/trunk/draft-mehta-atom-inline.xml >> [2] http://tools.ietf.org/html/draft-mehta-atom-inline-01#section-2.1.1 >> [3] http://www.imc.org/atom-syntax/mail-archive/threads.html#21203 >> > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Tue May 18 16:02:14 2010 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 08F7D3A6A08 for ; Tue, 18 May 2010 16:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydq9PWIv8Glr for ; Tue, 18 May 2010 16:02:12 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C8A763A6A77 for ; Tue, 18 May 2010 16:02:12 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4IMmldI033135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 15:48:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4IMml42033134; Tue, 18 May 2010 15:48:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4IMmkCJ033129 for ; Tue, 18 May 2010 15:48:46 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk11 with SMTP id 11so3325183qyk.13 for ; Tue, 18 May 2010 15:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=kK/H1c159O69stgjoa20v+w4aBs68VsZlOCFZk8ZRow=; b=HJIk7IeiOc7848phyJEFy/EJEmc6CBID1AIt98aVnUWI1GnNdaV7BXGV8fHJs6R1jj G4TK3K7AqnA3L4VT3uCwPFhuBudoYVJ9aPlFCt7mjFsCwMrWh3eQAAA4pAWyFaH834Lr P5fJO8QMJktcVmVYHhLrRw1JU82yWPgFNWdhk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=szoYlU8Td5xMYOSEuMERFFSUrdP3q65J7Q6kdHpcPWjbZ6Q3uI/Svp/6HgQ0Ci3Vy6 UmUGh7c97nydp/csc7jQbFogiNPl9GwhVcsW4z7CfI0mFhk8I4WneXI2LbeInRblzOf7 jjSrA2N0IJeJ4JWd7WuOcO0JXNHu00Neyp92E= MIME-Version: 1.0 Received: by 10.224.79.66 with SMTP id o2mr4189993qak.349.1274222922514; Tue, 18 May 2010 15:48:42 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Tue, 18 May 2010 15:48:41 -0700 (PDT) Date: Tue, 18 May 2010 15:48:41 -0700 Message-ID: Subject: Atom Tombstones From: James Snell To: Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ok, so I've resurrected the Atom Tombstones draft... there are places where this is has already been implemented and it's time to go ahead and finish it up. I have made a number of backwards compatible changes, such as allowing for any number of atom:link elements. I also intend to allow a at:deleted-entry element to contain an atom:source element to allow the deleted-entry to be copied from feed to feed. I want to wrap this up completely so I want to send out one last call for comments before I publish what I hope is the final draft before taking that next step towards and RFC. -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Tue May 18 23:16:40 2010 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 EE4AF3A6A90 for ; Tue, 18 May 2010 23:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.145 X-Spam-Level: * X-Spam-Status: No, score=1.145 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCUN1tlWOJvP for ; Tue, 18 May 2010 23:16:39 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3D1B63A6949 for ; Tue, 18 May 2010 23:16:37 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4J6AZRt051685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 23:10:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4J6AYQt051684; Tue, 18 May 2010 23:10:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.221.179]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4J6AXiu051679 for ; Tue, 18 May 2010 23:10:34 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk9 with SMTP id 9so10829272qyk.2 for ; Tue, 18 May 2010 23:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=kbtTNy8MoYlqRCM4mpMRM87JpH5XFrWU3rkooSnLpyQ=; b=PXHH815r07xdE/Ai2pDzqlrmPcYTvMMcrZptt9EPhg+pJe6tCLrCIwgH32rVpBuMfD kvtKaFW4O+D426WO3tKrvFF+rtyJahPKLW6S9TxEmE+NX/8ph0P3fKmqgYP5DLK3U12N LeiLgdKqwD1bOLqCZeX0w9tOPiisbvdMq4D08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YVMDojjmrS8SOFQ0Wj9UFW1JRyU+C1/t/KNI0g0BUGmp0PiPmwrbTg73PXQW2nLWEx Ff4t/KkLq2CEsN77NPNvBMxWvWWHGl4OQ+DRgKRqMagg9YlKiHudEMHX9MegrgZtgcW7 RnPR5xuhcnVZJgS6+PPUgEhCgi5VUzXiSXlJU= MIME-Version: 1.0 Received: by 10.229.241.139 with SMTP id le11mr1169440qcb.72.1274249433392; Tue, 18 May 2010 23:10:33 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Tue, 18 May 2010 23:10:33 -0700 (PDT) Date: Tue, 18 May 2010 23:10:33 -0700 Message-ID: Subject: Tombstones Update From: James Snell To: Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Another backwards compatible update... explicitly allowing for an optional atom:source element as a child of at:deleted-entry. http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-08.txt - James From owner-atom-syntax@mail.imc.org Tue May 18 23:33:44 2010 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 14F133A677D for ; Tue, 18 May 2010 23:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHeiD5M773DA for ; Tue, 18 May 2010 23:33:43 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9FD753A689E for ; Tue, 18 May 2010 23:33:42 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4J6TAs9052332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 23:29:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4J6T9Mb052330; Tue, 18 May 2010 23:29:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-gw0-f43.google.com (mail-gw0-f43.google.com [74.125.83.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4J6T959052325 for ; Tue, 18 May 2010 23:29:09 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by gwj18 with SMTP id 18so3321554gwj.16 for ; Tue, 18 May 2010 23:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=5szYDraiRVOZIqkVor5jLHUKXzoC4ZQ1Ga11e7iTw3Q=; b=HIpsfGWHthZD6kqehx0ljZBpyPLQ7MyhpYYcTl1IKVWAWKaD4VOQrtC4pDIXuFPBO/ mL3i6MX3QH1skP6rK6l41EAVKLiskHotTLSOJyKbPDGyp2gptPqtLFrHAEb4M7aSfgfW kT6dJJzXUi7ZGbidzZPplrGxwB0sVnE8x34Q0= 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=EDG02rqD3IckNHXQoG85RU6+ECAjQBkDiJyy8ocR+FwEbJBiQ7ZwuFCMQYqZILm+K9 jP+GAwOf4dB6FQSJNmgp+KJgdJqXM+612yVflS9kZxMv2pxTW70s6AeZGckIX9CPSMpD 5j54DGPtyShMuYoon4lts5fGfL3ipnRTV4XJk= MIME-Version: 1.0 Received: by 10.101.134.6 with SMTP id l6mr10073008ann.50.1274250547975; Tue, 18 May 2010 23:29:07 -0700 (PDT) Received: by 10.100.154.20 with HTTP; Tue, 18 May 2010 23:29:07 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 May 2010 02:29:07 -0400 X-Google-Sender-Auth: U5WDrW9wmtXNCsA_2OcuOlC9aRA Message-ID: Subject: Re: Tombstones Update From: Bob Wyman To: James Snell Cc: Atom Syntax Content-Type: multipart/alternative; boundary=001636c5bf504485c10486ec9378 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636c5bf504485c10486ec9378 Content-Type: text/plain; charset=ISO-8859-1 Can an at:delete-entry be signed in the same way that an Atom entry can be? Should I be concerned about an unsigned at:delete-entry which tells me to delete a signed entry? bob wyman On Wed, May 19, 2010 at 2:10 AM, James Snell wrote: > > Another backwards compatible update... explicitly allowing for an > optional atom:source element as a child of at:deleted-entry. > > http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-08.txt > > - James > > --001636c5bf504485c10486ec9378 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can an at:delete-entry be signed in the same way that an Atom entry can be?=

Should I be concerned about an unsigned at:delete-entry= which tells me to delete a signed entry?

bob wyman

On Wed, May 19, 2010 at 2:10 AM, James Snell= <jasnell@gmail.c= om> wrote:

Another backwards compatible update... explicitly allowing for an
optional atom:source element as a child of at:deleted-entry.

http://www.ietf.org/internet-drafts/draft-snel= l-atompub-tombstones-08.txt

- James


--001636c5bf504485c10486ec9378-- From owner-atom-syntax@mail.imc.org Tue May 18 23:44:07 2010 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 1277C3A6B18 for ; Tue, 18 May 2010 23:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.146 X-Spam-Level: * X-Spam-Status: No, score=1.146 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5LqFd5nqNjh for ; Tue, 18 May 2010 23:44:06 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id F270F3A6ADB for ; Tue, 18 May 2010 23:44:05 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4J6dpnG052891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 23:39:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4J6dpL5052890; Tue, 18 May 2010 23:39:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.221.179]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4J6doD0052885 for ; Tue, 18 May 2010 23:39:50 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk9 with SMTP id 9so10860456qyk.2 for ; Tue, 18 May 2010 23:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=pZ5+XazDOiEnbenGzArNSHbBqGQYMX8gPfVSw26WYAI=; b=UgchkcMbNBfQInWsIsMNz5kACGTMKudwzudglTD8VQl+qp3PCdTEvZISUcpQJPktOY qUKAqO1rtIH+eLOaBNAJSn1899QNODit2b3h7666Gv5z+nzJ1WCgodi1tDeH49jiXnDQ 4yTJDvzfOSl61+TYVGI+vY0omEnHrbZ99Qz/4= 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; b=l4AKFAPyzNhAhiWESc2dHx6DwWt8PreDAmiTMvgWatKw6/9KzJpX4AetgG4F+AhmW5 PaPvWSQtgRDMjbmYdX4paJJmCDyUoPQ9m337ErzCnnOeVOdYSGrhvBlC2JnF1/IYT1Px t5jUoqMfxcMyzGUI9CxMH6elEqZQWYUkL+yx8= MIME-Version: 1.0 Received: by 10.229.225.72 with SMTP id ir8mr1717872qcb.73.1274251189597; Tue, 18 May 2010 23:39:49 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Tue, 18 May 2010 23:39:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 May 2010 23:39:49 -0700 Message-ID: Subject: Re: Tombstones Update From: James Snell To: Bob Wyman Cc: Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Very good question. Short answer is obviously yes it can be, but calling that out explicitly in the spec is a good idea. There are likely several concerns with this that would need to be considered... such as what if both the entry and deleted-entry include valid signatures but have been signed with different keys... - James On Tue, May 18, 2010 at 11:29 PM, Bob Wyman wrote: > Can an at:delete-entry be signed in the same way that an Atom entry can be? > Should I be concerned about an unsigned at:delete-entry which tells me to > delete a signed entry? > bob wyman > > On Wed, May 19, 2010 at 2:10 AM, James Snell wrote: >> >> Another backwards compatible update... explicitly allowing for an >> optional atom:source element as a child of at:deleted-entry. >> >> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-08.txt >> >> - James >> > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Wed May 19 00:00:24 2010 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 2A6733A6B18 for ; Wed, 19 May 2010 00:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.929 X-Spam-Level: * X-Spam-Status: No, score=1.929 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOjetBsd4uLH for ; Wed, 19 May 2010 00:00:20 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3B4C23A6A5B for ; Wed, 19 May 2010 00:00:19 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4J6uAx2053680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 23:56:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4J6uAeR053679; Tue, 18 May 2010 23:56:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-gw0-f43.google.com (mail-gw0-f43.google.com [74.125.83.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4J6u9q6053674 for ; Tue, 18 May 2010 23:56:09 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by gwj18 with SMTP id 18so3327461gwj.16 for ; Tue, 18 May 2010 23:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=KY+0hi+h8ZGLmHdO9FJ30+lLROXzp0pOBOqpuMPvPUw=; b=ufbkgDMtzUYV/eycw9INFFwca8zxK/6KkL45jbN9Mxkn9hyI4iYnLEa/eyJuvbQVFp 0Gw+pLYVNw4irQ1cshzAh0H3cMNMAaE16f6KmT/HUCHem/BOFPPTPEW71IPPQWaZmW99 fpKdFHNqL/mVfweGh0OGQePvgd0TfQMgMIT3Y= 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=bDRpj0cGtmzaQ/VBNnjSvgYesFV855MLVZUS54asxtAETPaXETvowOtsH719XzN8Fx 2vCo/3l77kELNAzfjCpWu15MtrNFYwLSAK16O/BXxXegwc1+yzc99j9iGGUgX7xmDONh bWEv9KITOhBnET/fZdjjKoVWNsDi6A2SJQyjg= MIME-Version: 1.0 Received: by 10.101.133.16 with SMTP id k16mr9816824ann.96.1274252168615; Tue, 18 May 2010 23:56:08 -0700 (PDT) Received: by 10.100.154.20 with HTTP; Tue, 18 May 2010 23:56:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 May 2010 02:56:08 -0400 X-Google-Sender-Auth: 3pHfPfXhTFKdCY63NF4woahmPkI Message-ID: Subject: Re: Tombstones Update From: Bob Wyman To: James Snell Cc: Atom Syntax Content-Type: multipart/alternative; boundary=0016e68fcfa8dd574a0486ecf3a8 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0016e68fcfa8dd574a0486ecf3a8 Content-Type: text/plain; charset=ISO-8859-1 Your definition of the atom:source element is looser than that found in 4.2.11 of RFC4287 in that it doesn't specify which elements of a feed's metadata "SHOULD" be preserved and it also doesn't prohibit modification of an atom:source element which exists within a deleted-entry that is being copied. (i.e. in Atom you only "MAY" insert an atom:source if there isn't already one present in the entry.) Do you really intend to loosen the rules for atom:source? If not, then why not just incorporate 4.2.11 by reference in the same way you do for Atom specified elements like atom:link? bob wyman On Wed, May 19, 2010 at 2:10 AM, James Snell wrote: > > Another backwards compatible update... explicitly allowing for an > optional atom:source element as a child of at:deleted-entry. > > http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-08.txt > > - James > > --0016e68fcfa8dd574a0486ecf3a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Your definition of the atom:source element is looser than that found = in 4.2.11 of RFC4287 in that it doesn't specify which elements of a fee= d's metadata "SHOULD" be preserved and it also doesn't pr= ohibit modification of an atom:source element which exists within a deleted= -entry that is being copied. (i.e. in Atom you only "MAY" insert = an atom:source if there isn't already one present in the entry.) Do you= really intend to loosen the rules for atom:source? If not, then why not ju= st incorporate 4.2.11 by reference in the same way you do for Atom specifie= d elements like atom:link?

bob wyman

On Wed, May 19, 2010 at 2:10 AM, James Snell <= ;jasnell@gmail.com> wrot= e:

Another backwards compatible update... explicitly allowing for an
optional atom:source element as a child of at:deleted-entry.

http://www.ietf.org/internet-drafts/draft-snel= l-atompub-tombstones-08.txt

- James


--0016e68fcfa8dd574a0486ecf3a8-- From owner-atom-syntax@mail.imc.org Wed May 19 02:27:44 2010 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 E052228C131 for ; Wed, 19 May 2010 02:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2 X-Spam-Level: ** X-Spam-Status: No, score=2 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRXAbRqcZa+N for ; Wed, 19 May 2010 02:27:40 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 794F63A6BE3 for ; Wed, 19 May 2010 02:21:16 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4J9Fgpi060947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 02:15:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4J9Fgr9060946; Wed, 19 May 2010 02:15:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from eu1sys200aog116.obsmtp.com (eu1sys200aog116.obsmtp.com [207.126.144.141]) by hoffman.proper.com (8.14.4/8.14.3) with SMTP id o4J9FdxG060938 for ; Wed, 19 May 2010 02:15:41 -0700 (MST) (envelope-from samj@samj.net) Received: from source ([74.125.82.47]) by eu1sys200aob116.postini.com ([207.126.147.11]) with SMTP ID DSNKS/OsOkl8xvobjpE5bwSn0DDt01hULa6U@postini.com; Wed, 19 May 2010 09:15:41 UTC Received: by mail-ww0-f47.google.com with SMTP id 17so397069wwi.20 for ; Wed, 19 May 2010 02:15:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.90.133 with SMTP id e5mr4939422wef.78.1274260538004; Wed, 19 May 2010 02:15:38 -0700 (PDT) Received: by 10.216.158.210 with HTTP; Wed, 19 May 2010 02:15:37 -0700 (PDT) Received: by 10.216.158.210 with HTTP; Wed, 19 May 2010 02:15:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 May 2010 13:15:37 +0400 Message-ID: Subject: Re: Atom Tombstones From: Sam Johnston To: James Snell Cc: Atom Syntax Content-Type: multipart/alternative; boundary=0016e6dab052b813ff0486eee6cb Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0016e6dab052b813ff0486eee6cb Content-Type: text/plain; charset=ISO-8859-1 James, Can this be simplified and done in the atom namespace or does it warrant its own? Sam On 19 May 2010 01:09, "James Snell" wrote: > > Ok, so I've resurrected the Atom Tombstones draft... there are places > where this is has already been implemented and it's time to go ahead > and finish it up. I have made a number of backwards compatible > changes, such as allowing for any number of atom:link elements. I also > intend to allow a at:deleted-entry element to contain an atom:source > element to allow the deleted-entry to be copied from feed to feed. I > want to wrap this up completely so I want to send out one last call > for comments before I publish what I hope is the final draft before > taking that next step towards and RFC. > > -- > - James Snell > http://www.snellspace.com > jasnell@gmail.com > --0016e6dab052b813ff0486eee6cb Content-Type: text/html; charset=ISO-8859-1

James,

Can this be simplified and done in the atom namespace or does it warrant its own?

Sam

On 19 May 2010 01:09, "James Snell" <jasnell@gmail.com> wrote:
>
> Ok, so I've resurrected the Atom Tombstones draft... there are places
> where this is has already been implemented and it's time to go ahead
> and finish it up. I have made a number of backwards compatible
> changes, such as allowing for any number of atom:link elements. I also
> intend to allow a at:deleted-entry element to contain an atom:source
> element to allow the deleted-entry to be copied from feed to feed. I
> want to wrap this up completely so I want to send out one last call
> for comments before I publish what I hope is the final draft before
> taking that next step towards and RFC.
>
> --
> - James Snell
> http://www.snellspace.com
> jasnell@gmail.com
>

--0016e6dab052b813ff0486eee6cb-- From owner-atom-syntax@mail.imc.org Wed May 19 06:09:49 2010 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 70D443A6B99 for ; Wed, 19 May 2010 06:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.176 X-Spam-Level: * X-Spam-Status: No, score=1.176 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RogYEh7713LT for ; Wed, 19 May 2010 06:09:48 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id F230F3A6BC4 for ; Wed, 19 May 2010 06:08:45 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4JD38RF075983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 06:03:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4JD38CK075982; Wed, 19 May 2010 06:03:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-yw0-f198.google.com (mail-yw0-f198.google.com [209.85.211.198]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4JD37jt075976 for ; Wed, 19 May 2010 06:03:07 -0700 (MST) (envelope-from ed.summers@gmail.com) Received: by ywh36 with SMTP id 36so3582824ywh.4 for ; Wed, 19 May 2010 06:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Cpyvb0D2RVlLCxO+E++9YL/el4TIR38HvHhx8LfUcDo=; b=JXmCoFfiBHJuAWq/FaIL5tjVpIh6jS3qrHpHarnrR9hq5qSxFEL8i5BVcy9PeG4cmH Z4es0o0TI8ehpoREWxNcCw3/ov1f6OjLI0OpX41FWYb6p+IJSGjVm4mmlqQQHLMCG5OW 3EHVX4LdBhHR7MRV3TW07rNHb0bOAloHawlFQ= 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:content-type; b=OaoqVsqyF/CpYmZnOR8THggCFaRCD7dFfrggs6w0aalqE48NviRiFGQy2ORZzuE6OS rgdd0erS9daNb3kg3+VWGb2on+AjdUDA6VSoP/RyIebcqVOJdCM2g7+Fec80ZpWyV0X0 lbtbnLTphcaLmtPGtJLeMxdmI3hplduNweSnQ= MIME-Version: 1.0 Received: by 10.150.2.1 with SMTP id 1mr9831900ybb.65.1274274183284; Wed, 19 May 2010 06:03:03 -0700 (PDT) Received: by 10.151.143.19 with HTTP; Wed, 19 May 2010 06:03:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 May 2010 09:03:01 -0400 X-Google-Sender-Auth: d5ysNDnduNgH6TYW52pXOxliQ7w Message-ID: Subject: Re: Atom Tombstones From: Ed Summers To: Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for your efforts James. I think tombstones is really important for offering RESTful data synchronization services in the digital repository space where OAI-PMH has traditionally been used. I have been using Tombstones at the Library of Congress. Having the draft make it to RFC will be very helpful in promoting the use of Atom within the digital preservation community. //Ed [1] http://www.openarchives.org/OAI/openarchivesprotocol.html From owner-atom-syntax@mail.imc.org Wed May 19 08:10:35 2010 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 798113A69F6 for ; Wed, 19 May 2010 08:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.446 X-Spam-Level: * X-Spam-Status: No, score=1.446 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb8Vcvu7DFOt for ; Wed, 19 May 2010 08:10:34 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 35BE63A69EF for ; Wed, 19 May 2010 08:10:31 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4JF4PeU083613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 08:04:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4JF4P6j083612; Wed, 19 May 2010 08:04:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4JF4Ngl083606 for ; Wed, 19 May 2010 08:04:24 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by vws3 with SMTP id 3so1167817vws.16 for ; Wed, 19 May 2010 08:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qzo6rJpSoZ0LPj5qhx0XdCCLO4G85l72H5N97MaNpOo=; b=P5hES8jnWHEnunF/MSvxt8C+Ba9eEtPDOnYtz+8yQMCkXiJNdecw0xnMDinIPAbTRw MUTqF5tbs42n3SFdXsMW/zXFro9tgAWE+7LKJiwhzkrHeyv4b9Vfn5hSc/qZ7cCbFxIa YoItpgbZeb5Gm/C1CDI/oxi2vxxiHzG4cqEQU= 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; b=KUMPl7VlwLLk77Z/o1qec3tr4Db0tbUJiyGvkk7arNgmlPFx54KxbAtRr8m05OgYWQ ZxWorl+9vcDzIF/1LZ9S0IU+i09+E39+p2ak0jT+n9ubbVYrng0k8js3K7vu6fPV5n3i KbaU8C/G7i/dcDtQLbV1loDneP6yk5zRrujb8= MIME-Version: 1.0 Received: by 10.229.214.147 with SMTP id ha19mr1845168qcb.90.1274281458868; Wed, 19 May 2010 08:04:18 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Wed, 19 May 2010 08:04:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 May 2010 08:04:18 -0700 Message-ID: Subject: Re: Atom Tombstones From: James Snell To: Sam Johnston Cc: Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sam, had I defined this extension today, I likely would have strongly considered putting it into the Atom namespace. As it is, however, there is already deployed code that is using the extension in the namespace defined and it doesn't make sense to break that now. On Wed, May 19, 2010 at 2:15 AM, Sam Johnston wrote: > James, > > Can this be simplified and done in the atom namespace or does it warrant its > own? > > Sam > > On 19 May 2010 01:09, "James Snell" wrote: >> >> Ok, so I've resurrected the Atom Tombstones draft... there are places >> where this is has already been implemented and it's time to go ahead >> and finish it up. I have made a number of backwards compatible >> changes, such as allowing for any number of atom:link elements. I also >> intend to allow a at:deleted-entry element to contain an atom:source >> element to allow the deleted-entry to be copied from feed to feed. I >> want to wrap this up completely so I want to send out one last call >> for comments before I publish what I hope is the final draft before >> taking that next step towards and RFC. >> >> -- >> - James Snell >> http://www.snellspace.com >> jasnell@gmail.com >> > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Wed May 19 12:00:47 2010 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 ED91B3A6C8F for ; Wed, 19 May 2010 12:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_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 4XmsDHdA+JY8 for ; Wed, 19 May 2010 12:00:46 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 09F753A6972 for ; Wed, 19 May 2010 11:53:13 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4JIkTli097454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 11:46:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4JIkTZC097453; Wed, 19 May 2010 11:46:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4JIkSFr097447 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 19 May 2010 11:46:29 -0700 (MST) (envelope-from Pablo.Castro@microsoft.com) Received: from TK5EX14CASC131.redmond.corp.microsoft.com (157.54.52.38) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 May 2010 11:46:27 -0700 Received: from TK5EX14MBXC128.redmond.corp.microsoft.com ([169.254.7.44]) by TK5EX14CASC131.redmond.corp.microsoft.com ([157.54.52.38]) with mapi; Wed, 19 May 2010 11:46:17 -0700 From: Pablo Castro To: James Snell , Nikunj Mehta CC: Colm Divilly , "nrmehtais@gmail.com" , Atom-Syntax Subject: RE: Atom Inlining (Was Link Extensions. Need "md5" or some kind of hash.) Thread-Topic: Atom Inlining (Was Link Extensions. Need "md5" or some kind of hash.) Thread-Index: AQHK9sR0R7cbr/BJOEmq7Yum+rzMZpJZGBew Date: Wed, 19 May 2010 18:46:10 +0000 Message-ID: References: <4BF286BB.7090708@oracle.com> <1B899E67-A684-4120-8925-754CEB27241D@o-micron.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4JIkTFq097449 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: +1. We've been doing a very similar thing in OData (Astoria) for a while. We've used as custom element () in a custom namespace inside for now because there wasn't anything standard. For example (trimmed down version, full version here: http://odata.netflix.com/catalog/Titles?$top=2&$expand=Cast&$filter=ReleaseYear eq 1980): http://odata.netflix.com/catalog/Titles('13WZu') Metropolitan Opera: G. Puccini: Manon Lescaut Conducted by James Levine, the Metropolitan Opera presents Puccini's "Manon Lescaut." In this opera, directed by Gian Carlo Menotti, the title character (<a href="http://www.netflix.com/RoleDisplay/Renata_Scotto/83647">Renata Scotto</a>) escapes from a French convent and runs away with a poor student, the Chevalier des Grieux (a young <a href="http://www.netflix.com/RoleDisplay/Pl_cido_Domingo/30005475">Placido Domingo</a>). Manon eventually leaves des Grieux for a wealthy elderly lover; however, her heart is torn when des Grieux catches up with her. 2009-10-07T05:06:22Z 2010-05-19T18:42:18Z Cast http://odata.netflix.com/catalog/Titles('13WZu')/Cast 2010-05-19T18:42:18Z http://odata.netflix.com/catalog/People(83647) Renata Scotto 2010-05-19T18:42:18Z 83647 Renata Scotto http://odata.netflix.com/catalog/People(30005475) Plácido Domingo 2010-05-19T18:42:18Z 30005475 Plácido Domingo 13WZu Conducted by James Levine, the Metropolitan Opera presents Puccini's "Manon Lescaut." In this opera, directed by Gian Carlo Menotti, the title character (<a href="http://www.netflix.com/RoleDisplay/Renata_Scotto/83647">Renata Scotto</a>) escapes from a French convent and runs away with a poor student, the Chevalier des Grieux (a young <a href="http://www.netflix.com/RoleDisplay/Pl_cido_Domingo/30005475">Placido Domingo</a>). Manon eventually leaves des Grieux for a wealthy elderly lover; however, her heart is torn when des Grieux catches up with her. 8040 3.3 1980 http://www.netflix.com/Movie/Metropolitan_Opera_G._Puccini_Manon_Lescaut/5616554 NR Movie Metropolitan Opera: Puccini Metropolitan Opera: G. Puccini: Manon Lescaut http://movi.es/13WZu http://api.netflix.com/catalog/titles/movies/5616554 http://cdn-4.nflximg.com/us/boxshots/tiny/5616554.jpg http://cdn-4.nflximg.com/us/boxshots/small/5616554.jpg http://cdn-4.nflximg.com/us/boxshots/large/5616554.jpg false false false false -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of James Snell Sent: Tuesday, May 18, 2010 12:50 PM To: Nikunj Mehta Cc: Colm Divilly; nrmehtais@gmail.com; Atom-Syntax Subject: Re: Atom Inlining (Was Link Extensions. Need "md5" or some kind of hash.) Non-Atom type support, I think, is definitely important. I also urge you to consider defining the element so that it is a part of the Atom namespace. Explosion and management of extension namespaces is going to become a significant problem as time goes on, we need to establish good practices for it now. On Tue, May 18, 2010 at 12:46 PM, Nikunj Mehta wrote: > I can brush up the I-D and add the non-Atom type support, which was contemplated but waiting for more interest to be put in. > > Nikunj > On May 18, 2010, at 5:23 AM, Colm Divilly wrote: > >> James Snell wrote: >>> Another change that I am contemplating making is introducing a new >>> child element for the atom:link element that would allow it to serve >>> the same basic purpose as the GData feedLink and entryLink elements >>> except with greater flexibility... specifically, it would allow a >>> representation of the linked resource to be dropped directly into the >>> link element, e.g. >>> >>> >>>  this is a representation of the data >>> >>> >>> >>>  abc...def== >>> >>> >>> >>>   >>>    ... >>>   >>> >>> >>> Or something along those lines. >>> >>> Thoughts? >>> >>> >> +1, I think this is really important, Whenever I am designing resources, I am always finding myself having to make a choice about whether to inline related content in the resource or include a hyper link to the related content. Having a consistent pattern for doing this would be beneficial. >> >> As an aside, if this approach was possible, then one could re-imagine the atom:content element as simply .... >> >> Nikunj Mehta has an unpublished draft of Atom Inline Extensions that proposes the same as what you propose [1] (the last published draft restricted the inline content types to atom resources only [2]),  Nikunj care to weigh in? >> >> There was some discussion about this a while back: [3] >> >> [1] http://atom-ext.googlecode.com/svn-history/r9/trunk/draft-mehta-atom-inline.xml >> [2] http://tools.ietf.org/html/draft-mehta-atom-inline-01#section-2.1.1 >> [3] http://www.imc.org/atom-syntax/mail-archive/threads.html#21203 >> > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From agentx-archive@lists.ietf.org Wed May 19 12:05:01 2010 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 6E37B3A6CF7 for ; Wed, 19 May 2010 12:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.582 X-Spam-Level: X-Spam-Status: No, score=-7.582 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, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_XBL=3.033, RDNS_DYNAMIC=0.1, 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 kkHWzY2AzjMh for ; Wed, 19 May 2010 12:04:59 -0700 (PDT) Received: from ppp-110-168-104-152.revip5.asianet.co.th (ppp-124-122-136-5.revip2.asianet.co.th [124.122.136.5]) by core3.amsl.com (Postfix) with SMTP id E2A683A6A73 for ; Wed, 19 May 2010 11:58:12 -0700 (PDT) From: RX-Store Subject: Special Discount 77% for atompub-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100519185814.E2A683A6A73@core3.amsl.com> Date: Wed, 19 May 2010 11:58:12 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://seemcreamy.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 62424 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 02860 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 17938 is unauthorized. 14892

From archive@lists.ietf.org Wed May 19 19:52:30 2010 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 1E1263A685C for ; Wed, 19 May 2010 19:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.294 X-Spam-Level: X-Spam-Status: No, score=-15.294 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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, RDNS_DYNAMIC=0.1, 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 kNy4UU0qD3q3 for ; Wed, 19 May 2010 19:52:29 -0700 (PDT) Received: from triband-mum-120.63.5.92.mtnl.net.in (triband-mum-120.63.5.92.mtnl.net.in [120.63.5.92]) by core3.amsl.com (Postfix) with SMTP id CA6613A6B96 for ; Wed, 19 May 2010 19:52:24 -0700 (PDT) From: RX-Store Subject: New Private Message for atompub-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100520025227.CA6613A6B96@core3.amsl.com> Date: Wed, 19 May 2010 19:52:24 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://setopen.ru/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 34889 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 13549 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 07676 is unauthorized. 19088

From atompub-archive@megatron.ietf.org Wed May 19 20:02:39 2010 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 7451B3A6AE0 for ; Wed, 19 May 2010 20:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.529 X-Spam-Level: X-Spam-Status: No, score=-30.529 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_IT=0.635, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_NONE=0.1, URIBL_AB_SURBL=10, 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 V6b+frULGFvk for ; Wed, 19 May 2010 20:02:38 -0700 (PDT) Received: from agemont.it (unknown [201.244.119.17]) by core3.amsl.com (Postfix) with SMTP id 1DCD43A6BD0 for ; Wed, 19 May 2010 20:02:35 -0700 (PDT) From: RX-Store Subject: Special Code for 74% for atompub-archive@megatron.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100520030236.1DCD43A6BD0@core3.amsl.com> Date: Wed, 19 May 2010 20:02:35 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://musichappen.ru/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 85498 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 58495 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 53058 is unauthorized. 30841

From owner-atom-syntax@mail.imc.org Wed May 19 20:04:25 2010 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 B73463A6AA4 for ; Wed, 19 May 2010 20:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.019 X-Spam-Level: ** X-Spam-Status: No, score=2.019 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9LNUob10b4x for ; Wed, 19 May 2010 20:04:24 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1AF333A6A77 for ; Wed, 19 May 2010 20:04:22 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4K2wl8E020903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 19:58:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4K2wloZ020902; Wed, 19 May 2010 19:58:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-gw0-f43.google.com (mail-gw0-f43.google.com [74.125.83.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4K2wk80020896 for ; Wed, 19 May 2010 19:58:46 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by gwj18 with SMTP id 18so4046001gwj.16 for ; Wed, 19 May 2010 19:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=kwq8GV7m9vhG9OEk1cufvLm1qU82Fz8IMCoGfzJeb1Q=; b=UARNMTCFVaggZ/bS1ufhcwt+k/QwOO8OgP02jy9tbO7XqYNJWs+vQBpHT7rGRcx70F K0KAJHDAA1Ciz+bL1nhct0IMz2G8j/3olQNd/FAgTq4N4ZZoXLVhlYd+bH3TDEIUUSRp B0+TOsNAqQ0sMJPQgatM+9c2/S1morkcn1Ae8= 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=eYj88eVY9yL4cFdxQig93Cia4Ut8QeEi4WVh5qetlekzy+k/EjZvDZDz2Qtnr6bm2X qvdG89x0M6rzXoRiZ/PxKBKWryj8+1QyJHBINhB/o8HWiVwm2uqAz6OnwlgzdE53SfgZ Rh20fSi4L/71IoAxo6GOrglN/ukxeeJe1KpDo= MIME-Version: 1.0 Received: by 10.101.7.29 with SMTP id k29mr11773472ani.16.1274324325479; Wed, 19 May 2010 19:58:45 -0700 (PDT) Received: by 10.100.154.20 with HTTP; Wed, 19 May 2010 19:58:45 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 May 2010 22:58:45 -0400 X-Google-Sender-Auth: jSPlJbWbh0TbG37psZZZ6H_HHPE Message-ID: Subject: Re: Tombstones Update From: Bob Wyman To: James Snell Cc: Atom Syntax Content-Type: multipart/alternative; boundary=001636c92898bfb4c70486fdc019 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636c92898bfb4c70486fdc019 Content-Type: text/plain; charset=ISO-8859-1 In Atom, both Entry Documents and Feed Documents are "top-level" objects. An entry may be contained within a Feed Document, but it need not be. This is an important characteristic of Atom and one that distinguishes it from previous, legacy syndication formats. This attribute of Atom makes it particularly well suited for use in applications that rely on combining entries from multiple sources as well as applications that provide real-time delivery of data. However, the deleted-entry that you define in the tombstone draft is defined as only existing within Feed Documents. This represents a significant and unfortunate departure from the base Atom RFC. I would strongly encourage you to ensure that deleted-entry is symmetrical with atom:entry and that it is available in all contexts (i.e. both within and without a Feed Document) that an Atom entry is. Just as we can have Entry Documents, we should be able to have Deleted-entry Documents. bob wyman On Wed, May 19, 2010 at 2:10 AM, James Snell wrote: > > Another backwards compatible update... explicitly allowing for an > optional atom:source element as a child of at:deleted-entry. > > http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-08.txt > > - James > > --001636c92898bfb4c70486fdc019 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In Atom, both Entry Documents and Feed Documents are "top-level" = objects. An entry may be contained within a Feed Document, but it need not = be. This is an important characteristic of Atom and one that distinguishes = it from previous, legacy syndication formats. This attribute of Atom makes = it particularly well suited for use in applications that rely on combining = entries from multiple sources as well as applications that provide real-tim= e delivery of data.

However, the deleted-entry that you define in the tombstone = draft is defined as only existing within Feed Documents. This represents a = significant and unfortunate departure from the base Atom RFC.

I would strongly encourage you to ensure that deleted-entry = is symmetrical with atom:entry and that it is available in all contexts (i.= e. both within and without a Feed Document) that an Atom entry is. Just as = we can have Entry Documents, we should be able to have Deleted-entry Docume= nts.

bob wyman

On W= ed, May 19, 2010 at 2:10 AM, James Snell <jasnell@gmail.com> wrote:

Another backwards compatible update... explicitly allowing for an
optional atom:source element as a child of at:deleted-entry.

http://www.ietf.org/internet-drafts/draft-snel= l-atompub-tombstones-08.txt

- James


--001636c92898bfb4c70486fdc019-- From owner-atom-syntax@mail.imc.org Wed May 19 20:22:32 2010 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 56D123A6C2F for ; Wed, 19 May 2010 20:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.463 X-Spam-Level: * X-Spam-Status: No, score=1.463 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NaTcpKcUlJy for ; Wed, 19 May 2010 20:22:29 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6311D3A6BF9 for ; Wed, 19 May 2010 20:22:00 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4K3HJgj021673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 20:17:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4K3HJGa021672; Wed, 19 May 2010 20:17:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.221.179]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4K3HIn7021667 for ; Wed, 19 May 2010 20:17:18 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk9 with SMTP id 9so12493359qyk.2 for ; Wed, 19 May 2010 20:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4QDtrNPP1vDfLiXg+2cto7cPJiXCphHlQgz0czUc1Hs=; b=RkktLyYR4pybWdneP30KTSHABnyxqii2ZqrRkJ3wL5HrcgsP5DdrIiDVZAM8XADrWH MxMo69ZOYAablbHmzwfYJpFCmF2BCnCYFJbeFZWO9KiYTR/HBmCxEV2dJVTBIvHO3d33 2D/bouXZJyfKDyzo2HX1877RHWQax1uEUkmyk= 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; b=o+HTfiB5jXq3T2p2mCA/z5QoRX2d28mFvPm14+XLSMA2ORshYzSoCdR3nbq1/Lbvuw kNQuC6qWhOkY2ovWCHcPW84ZTwMtpfRTJdozQZG+sLMHgWs8kYWaXrujNcSZwBN07eC9 HAyjw/7zoxbSV1Mb0SNBpKtkXIvx/wWetChs4= MIME-Version: 1.0 Received: by 10.229.227.194 with SMTP id jb2mr44515qcb.162.1274325437526; Wed, 19 May 2010 20:17:17 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Wed, 19 May 2010 20:17:17 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 May 2010 20:17:17 -0700 Message-ID: Subject: Re: Tombstones Update From: James Snell To: Bob Wyman Cc: Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Heh, Bob... you and I seriously need to get into the same room with a whiteboard sometime.. lol.. Ok, first about your previous comment about atom:source... yes, the intention is for it to be identical to the use within atom:entry so I will tighten that up in the spec... As for standalone deleted entry documents... I definitely can think of a few generally interesting potential use cases... the key question is whether they are compelling. - James On Wed, May 19, 2010 at 7:58 PM, Bob Wyman wrote: > In Atom, both Entry Documents and Feed Documents are "top-level" objects. An > entry may be contained within a Feed Document, but it need not be. This is > an important characteristic of Atom and one that distinguishes it from > previous, legacy syndication formats. This attribute of Atom makes it > particularly well suited for use in applications that rely on combining > entries from multiple sources as well as applications that provide real-time > delivery of data. > However, the deleted-entry that you define in the tombstone draft is defined > as only existing within Feed Documents. This represents a significant and > unfortunate departure from the base Atom RFC. > I would strongly encourage you to ensure that deleted-entry is symmetrical > with atom:entry and that it is available in all contexts (i.e. both within > and without a Feed Document) that an Atom entry is. Just as we can have > Entry Documents, we should be able to have Deleted-entry Documents. > bob wyman > On Wed, May 19, 2010 at 2:10 AM, James Snell wrote: >> >> Another backwards compatible update... explicitly allowing for an >> optional atom:source element as a child of at:deleted-entry. >> >> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-08.txt >> >> - James >> > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Wed May 19 20:41:39 2010 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 7D75E3A6C2B for ; Wed, 19 May 2010 20:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.028 X-Spam-Level: ** X-Spam-Status: No, score=2.028 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6Zptxk02E+v for ; Wed, 19 May 2010 20:41:37 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 272D83A6BEE for ; Wed, 19 May 2010 20:41:37 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4K3aDCH022381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 20:36:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4K3aDx4022380; Wed, 19 May 2010 20:36:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-yw0-f198.google.com (mail-yw0-f198.google.com [209.85.211.198]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4K3aD4Q022374 for ; Wed, 19 May 2010 20:36:13 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by ywh36 with SMTP id 36so4191540ywh.4 for ; Wed, 19 May 2010 20:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=ng88u8Lo710irT8NUmBqQRLQkRG2Dk2DJLWrp2LBp3I=; b=bWTtSfg/oeBnL1qRYJDezIZPLJvLjrbuxmI3ZPgMEvwaKVYWWOmgwaDGtjhcTPkN3Q fIt3DAu1LDHNfyTM1IIL7cjuNEQUhU/KiV4oo28dwQfVPwHPzaBDJMwQCoHmqsoZBfFa /nerwuIenUUgwrVLbdJYEvOR/BcFz4hsaH1AQ= 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=mfgMkISUHBjVvKkK4qeQzGxnPyIedXTNFp5oTzef+sFHlCOHlfxWJ0T+m3EdxG+SGJ t72Bl2fbkvYYLuC0Jlo/Ds7gFZhEsH8B9DYpets1YSy6fz08CRAmuZ0i7jgwMZZmvhLe DReY35GEkQm2txiEMYEZqYPIdOwvPbK/sQHXk= MIME-Version: 1.0 Received: by 10.101.106.1 with SMTP id i1mr10764673anm.240.1274326572487; Wed, 19 May 2010 20:36:12 -0700 (PDT) Received: by 10.100.154.20 with HTTP; Wed, 19 May 2010 20:36:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 May 2010 23:36:12 -0400 X-Google-Sender-Auth: 0or-Jz9lNYtdL7Wjsw8aQp9rj7I Message-ID: Subject: Re: Tombstones Update From: Bob Wyman To: James Snell Cc: Atom Syntax Content-Type: multipart/alternative; boundary=001636c5bf16ae55b10486fe4652 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636c5bf16ae55b10486fe4652 Content-Type: text/plain; charset=ISO-8859-1 James Snell wrote: > As for standalone deleted entry documents... > the key question is > whether they are compelling. An example... "Atom over XMPP" calls for publishing streams of Atom Entry Documents over XMPP. Because there was no mechanism defined for deleting in Atom itself, "Atom over XMPP" ended up defining a "retract" message for that purpose. It would be more natural to use a tombstone. But, the general question is: Atom format permits my application to publish only Entry Documents. However, if I do that, and if a delete-entry can only exist as an element of a Feed Document, how do I tell anyone about a deleted-entry? Would I need to modify my protocol to support Feed Documents simply as a means to transport deleted-entries? Doesn't seem right. bob wyman On Wed, May 19, 2010 at 11:17 PM, James Snell wrote: > Heh, Bob... you and I seriously need to get into the same room with a > whiteboard sometime.. lol.. > > Ok, first about your previous comment about atom:source... yes, the > intention is for it to be identical to the use within atom:entry so I > will tighten that up in the spec... > > As for standalone deleted entry documents... I definitely can think of > a few generally interesting potential use cases... the key question is > whether they are compelling. > > - James > > On Wed, May 19, 2010 at 7:58 PM, Bob Wyman wrote: > > In Atom, both Entry Documents and Feed Documents are "top-level" objects. > An > > entry may be contained within a Feed Document, but it need not be. This > is > > an important characteristic of Atom and one that distinguishes it from > > previous, legacy syndication formats. This attribute of Atom makes it > > particularly well suited for use in applications that rely on combining > > entries from multiple sources as well as applications that provide > real-time > > delivery of data. > > However, the deleted-entry that you define in the tombstone draft is > defined > > as only existing within Feed Documents. This represents a significant and > > unfortunate departure from the base Atom RFC. > > I would strongly encourage you to ensure that deleted-entry is > symmetrical > > with atom:entry and that it is available in all contexts (i.e. both > within > > and without a Feed Document) that an Atom entry is. Just as we can have > > Entry Documents, we should be able to have Deleted-entry Documents. > > bob wyman > > On Wed, May 19, 2010 at 2:10 AM, James Snell wrote: > >> > >> Another backwards compatible update... explicitly allowing for an > >> optional atom:source element as a child of at:deleted-entry. > >> > >> > http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-08.txt > >> > >> - James > >> > > > > > > > > -- > - James Snell > http://www.snellspace.com > jasnell@gmail.com > --001636c5bf16ae55b10486fe4652 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable James Snell=A0<jasnell@gmail.com>=A0wrote:
>=A0= As for standalone deleted entry documents...
>=A0the key quest= ion is
> whether they are compelling.

An example... "Atom over XMPP" calls = for publishing streams of Atom Entry Documents over XMPP. Because there was= no mechanism defined for deleting in Atom itself, "Atom over XMPP&quo= t; ended up defining a "retract" message for that purpose. It wou= ld be more natural to use a tombstone.=A0

But, the general question is: Atom format permits my ap= plication to publish only Entry Documents. However, if I do that, and if a = delete-entry can only exist as an element of a Feed Document, how do I tell= anyone about a deleted-entry? Would I need to modify my protocol to suppor= t Feed Documents simply as a means to transport deleted-entries? Doesn'= t seem right.

bob wyman

On W= ed, May 19, 2010 at 11:17 PM, James Snell <jasnell@gmail.com> wrote:
Heh, Bob... you and I seriously need to get into the same room with a
whiteboard sometime.. lol..

Ok, first about your previous comment about atom:source... yes, the
intention is for it to be identical to the use within atom:entry so I
will tighten that up in the spec...

As for standalone deleted entry documents... I definitely can think of
a few generally interesting potential use cases... the key question is
whether they are compelling.

- James

On Wed, May 19, 2010 at 7:58 PM, Bob Wyman <bob@wyman.us> wrote:
> In Atom, both Entry Documents and Feed Documents are "top-level&q= uot; objects. An
> entry may be contained within a Feed Document, but it need not be. Thi= s is
> an important characteristic of Atom and one that distinguishes it from=
> previous, legacy syndication formats. This attribute of Atom makes it<= br> > particularly well suited for use in applications that rely on combinin= g
> entries from multiple sources as well as applications that provide rea= l-time
> delivery of data.
> However, the deleted-entry that you define in the tombstone draft is d= efined
> as only existing within Feed Documents. This represents a significant = and
> unfortunate departure from the base Atom RFC.
> I would strongly encourage you to ensure that deleted-entry is symmetr= ical
> with atom:entry and that it is available in all contexts (i.e. both wi= thin
> and without a Feed Document) that an Atom entry is. Just as we can hav= e
> Entry Documents, we should be able to have Deleted-entry Documents. > bob wyman
> On Wed, May 19, 2010 at 2:10 AM, James Snell <jasnell@gmail.com> wrote:
>>
>> Another backwards compatible update... explicitly allowing for an<= br> >> optional atom:source element as a child of at:deleted-entry.
>>
>> http://www.ietf.org/internet-drafts/d= raft-snell-atompub-tombstones-08.txt
>>
>> - James
>>
>
>




--001636c5bf16ae55b10486fe4652-- From owner-atom-syntax@mail.imc.org Thu May 20 00:00:43 2010 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 429683A6CE0 for ; Thu, 20 May 2010 00:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.176 X-Spam-Level: **** X-Spam-Status: No, score=4.176 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2MU54N8C2Es for ; Thu, 20 May 2010 00:00:39 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 793C93A6CC3 for ; Thu, 20 May 2010 00:00:39 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4K6s8ei032156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 23:54:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4K6s8rQ032155; Wed, 19 May 2010 23:54:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-gw0-f43.google.com (mail-gw0-f43.google.com [74.125.83.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4K6s7C2032150 for ; Wed, 19 May 2010 23:54:07 -0700 (MST) (envelope-from ed.summers@gmail.com) Received: by gwj18 with SMTP id 18so4128652gwj.16 for ; Wed, 19 May 2010 23:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=jczWXeXf2VXsrgmQ5MypJ8lv7zvc81Lc5L0H/y913mQ=; b=gsZ66jiGArtaEV3NjpxFNl4xon++NDD/opEpeYo2N9UC9jXnsRz+bAMpSCeder5SqR fF0w8+yHpxuUFGntvpHASyHTRVtAlGNUjK7WMEVFnFx5ytAH+vcs42uFg4SGFmcSyAn9 2o4PpWDWhyRERhfJXE+evGV32Q02H5fuD0or4= 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=XmB/Scqb68jc+lGSdVeUYXwdD5iUbgMXkDPBRiDpyYMf8qJKXwF2OJS6fsPfBT3U90 PtvKy3B6O7d/Z6MRhezQ5I4MO0O8XG5bNyTKTVVJzXVELiOfDfIGBTM9a7tF+5EYvBl0 Qr305FHxu7B5V+zSVKIBIuxJD2tvxF0DKZ3Wo= MIME-Version: 1.0 Received: by 10.151.18.10 with SMTP id v10mr1150592ybi.51.1274338446597; Wed, 19 May 2010 23:54:06 -0700 (PDT) Received: by 10.151.143.19 with HTTP; Wed, 19 May 2010 23:54:06 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 May 2010 02:54:06 -0400 X-Google-Sender-Auth: BIYUBRBoRMPAb_W4wnHAtuP6glU Message-ID: Subject: Re: Tombstones Update From: Ed Summers To: Bob Wyman Cc: James Snell , Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, May 19, 2010 at 10:58 PM, Bob Wyman wrote:. > I would strongly encourage you to ensure that deleted-entry is symmetrical > with atom:entry and that it is available in all contexts (i.e. both within > and without a Feed Document) that an Atom entry is. Just as we can have > Entry Documents, we should be able to have Deleted-entry Documents. +1 I could well imagine wanting to return a Tombstone as the message body for a 403 Gone response for a resource that I know has been deleted. I guess I had been reading the following pretty liberally: """ The at:deleted-entry element MAY appear as a child of atom:feed to represent an Atom Entry that has been removed from a feed. deletedEntry = element at:deleted-entry { atomCommonAttributes, attribute ref { atomUri }, attribute when { atomDateConstruct }, ( element at:by { atomPersonConstruct}?, & element at:comment {atomTextConstruct}?, & element atom:link*, & element atom:source?, & extensionElement* ) } """ Does the MAY prevent at:deleted-entry being used outside the context of a atom:feed? //Ed [1] http://tools.ietf.org/html/rfc2616#section-10.4.11 From owner-atom-syntax@mail.imc.org Thu May 20 01:18:56 2010 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 7EA573A6B4E for ; Thu, 20 May 2010 01:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.654 X-Spam-Level: ** X-Spam-Status: No, score=2.654 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zjb1k7dJwDTl for ; Thu, 20 May 2010 01:18:55 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 8F7673A6D27 for ; Thu, 20 May 2010 01:16:26 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4K8BHlL036217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 May 2010 01:11:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4K8BHx7036216; Thu, 20 May 2010 01:11:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4K8BFXr036211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 May 2010 01:11:16 -0700 (MST) (envelope-from colm.divilly@oracle.com) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4K8BCom029310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 May 2010 08:11:14 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4K7PGxk016700; Thu, 20 May 2010 08:11:10 GMT Received: from abhmt015.oracle.com by acsmt354.oracle.com with ESMTP id 283662721274343035; Thu, 20 May 2010 01:10:35 -0700 Received: from [192.168.1.4] (/78.16.172.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 01:10:34 -0700 References: Message-Id: <700FC45C-B38A-452E-8591-91CB9F473ED5@oracle.com> From: Colm Divilly To: Ed Summers In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPod Mail (7D11) Mime-Version: 1.0 (iPod Mail 7D11) Subject: Re: Tombstones Update Date: Thu, 20 May 2010 09:10:36 +0100 Cc: Bob Wyman , James Snell , Atom Syntax X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090204.4BF4EEA2.0175:SCFMA4539811,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: +1 On May 20, 2010, at 7:54 AM, Ed Summers wrote: > > On Wed, May 19, 2010 at 10:58 PM, Bob Wyman wrote:. >> I would strongly encourage you to ensure that deleted-entry is >> symmetrical >> with atom:entry and that it is available in all contexts (i.e. both >> within >> and without a Feed Document) that an Atom entry is. Just as we can >> have >> Entry Documents, we should be able to have Deleted-entry Documents. > > +1 > > I could well imagine wanting to return a Tombstone as the message body > for a 403 Gone response for a resource that I know has been deleted. I > guess I had been reading the following pretty liberally: > > """ > The at:deleted-entry element MAY appear as a child of atom:feed to > represent an Atom Entry that has been removed from a feed. > > deletedEntry = element at:deleted-entry { > atomCommonAttributes, > attribute ref { atomUri }, > attribute when { atomDateConstruct }, > ( element at:by { atomPersonConstruct}?, > & element at:comment {atomTextConstruct}?, > & element atom:link*, > & element atom:source?, > & extensionElement* ) > } > """ > > Does the MAY prevent at:deleted-entry being used outside the context > of a atom:feed? > > //Ed > > [1] http://tools.ietf.org/html/rfc2616#section-10.4.11 > From owner-atom-syntax@mail.imc.org Thu May 20 03:27:39 2010 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 419CB3A67FC for ; Thu, 20 May 2010 03:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.254 X-Spam-Level: ** X-Spam-Status: No, score=2.254 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, 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 UWJeLwEuKzP4 for ; Thu, 20 May 2010 03:27:38 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 03D683A68A8 for ; Thu, 20 May 2010 03:26:36 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4KAM367044731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 May 2010 03:22:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4KAM3Zo044730; Thu, 20 May 2010 03:22:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4KAM1Ds044723 for ; Thu, 20 May 2010 03:22:02 -0700 (MST) (envelope-from lindstream@gmail.com) Received: by wyb29 with SMTP id 29so1264965wyb.16 for ; Thu, 20 May 2010 03:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=rEuphSQFfDIMpRYO1g3nAtork9kZcpgpDiuYDgqLAYc=; b=vi0TSvsOCDEVzymZgGHD5LEFcd1L8UigzDEnMGGnDjvzUp1rhFlGaIn9MaHxLFs/Rl tVjoCYIPEQRdL1lh+ctvx4qtkWKXuFO6GaceeE1PKcpwwRWP+9csVNJDcuxgo/3h78bu mnq9/makto3UENDwqCy8P+7Y5UPYUqASrcoVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=EzB9l9OxV58KgvIipXqd5nHIwZ2f0EjLhj8fE8Pr/JalFv6zQ+h3/UEvzEYTRBZmDR V0FVhGmStZEH/ymE0+ssxPRTBOwT6AO2owS+NoXygrLlbWLiib2QN96GVGPPsAYkytGW F4RupBvd8oSN1dNeyF6Q5P6HZz7ZYigs1qbyw= Received: by 10.216.159.20 with SMTP id r20mr5927761wek.62.1274350917447; Thu, 20 May 2010 03:21:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.19.85 with HTTP; Thu, 20 May 2010 03:21:37 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?Niklas_Lindstr=F6m?= Date: Thu, 20 May 2010 12:21:37 +0200 Message-ID: Subject: Re: Tombstones Update To: Ed Summers Cc: Bob Wyman , James Snell , Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, May 20, 2010 at 8:54 AM, Ed Summers wrote: > > On Wed, May 19, 2010 at 10:58 PM, Bob Wyman wrote:. >> I would strongly encourage you to ensure that deleted-entry is symmetrical >> with atom:entry and that it is available in all contexts (i.e. both within >> and without a Feed Document) that an Atom entry is. Just as we can have >> Entry Documents, we should be able to have Deleted-entry Documents. > > +1 > > I could well imagine wanting to return a Tombstone as the message body > for a 403 Gone response for a resource that I know has been deleted. +1 from me as well. Apart from the use cases already mentioned (XMPP, 403 representations), I see potential for using deleted-entry documents in our system (the swedish legal information system). I'm currently using entry documents internally in our "depot", both as manifests and to represent the collected source entries ("via" entries). Having deleted-entry documents there as well would be very beneficial. (In fact, this was a primary motive for my wish for allowing atom:source in at:deleted-entry elements. Which I'm very happy to see in the latest draft -- thanks James!) Two points come to mind if this is done: * What would the mime-type for deleted-entry documents be? A new "application/atom+xml;type=deleted-entry"? * For good measure, making sure that this doesn't lead to a pattern of PUT:ing deleted-entry docs instead of using DELETE... ;) Best regards, Niklas From atompub-archive@megatron.ietf.org Thu May 20 04:05:49 2010 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 D24893A6929 for ; Thu, 20 May 2010 04:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.216 X-Spam-Level: X-Spam-Status: No, score=-13.216 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_24=1.552, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, 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 gMELo0lyix7M for ; Thu, 20 May 2010 04:05:48 -0700 (PDT) Received: from afo.net (unknown [190.25.225.66]) by core3.amsl.com (Postfix) with SMTP id E0DB93A68E0 for ; Thu, 20 May 2010 04:05:47 -0700 (PDT) From: RX-Store Subject: Your Future Order with 77% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100520110547.E0DB93A68E0@core3.amsl.com> Date: Thu, 20 May 2010 04:05:47 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://meace.ru/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 69918 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 78262 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 59543 is unauthorized. 65263

From atompub-archive@megatron.ietf.org Thu May 20 04:56:08 2010 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 99D9D3A6B5C for ; Thu, 20 May 2010 04:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.797 X-Spam-Level: X-Spam-Status: No, score=-10.797 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, 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 NNAQsMvrGtxf for ; Thu, 20 May 2010 04:56:07 -0700 (PDT) Received: from acc.co.jp (unknown [94.181.37.118]) by core3.amsl.com (Postfix) with SMTP id 6D22E3A6B54 for ; Thu, 20 May 2010 04:56:05 -0700 (PDT) From: RX-Store Subject: Special Discount 71% for atompub-archive@megatron.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100520115606.6D22E3A6B54@core3.amsl.com> Date: Thu, 20 May 2010 04:56:05 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://setopen.ru/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 18783 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 62001 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 60852 is unauthorized. 54273

From area-request@lists.ietf.org Thu May 20 06:43:01 2010 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 D12953A6B1C for ; Thu, 20 May 2010 06:43:01 -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_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, HOST_EQ_BROADBND=1.118, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 cHFHPQDXq9PU for ; Thu, 20 May 2010 06:43:00 -0700 (PDT) Received: from 212-178-0-62.broadband.tenet.odessa.ua (212-178-0-62.broadband.tenet.odessa.ua [212.178.0.62]) by core3.amsl.com (Postfix) with SMTP id 713083A67F7 for ; Thu, 20 May 2010 06:42:38 -0700 (PDT) From: RX-Store Subject: Your Future Order with 76% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100520134239.713083A67F7@core3.amsl.com> Date: Thu, 20 May 2010 06:42:38 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://musichappen.ru/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 28654 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 83239 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 64934 is unauthorized. 51387

From atompub-archive@megatron.ietf.org Thu May 20 06:51:03 2010 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 2856A3A6C10 for ; Thu, 20 May 2010 06:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.679 X-Spam-Level: X-Spam-Status: No, score=-43.679 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_JP_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 3nQUBaGmxSKi for ; Thu, 20 May 2010 06:51:01 -0700 (PDT) Received: from abril.com.br (unknown [95.78.106.98]) by core3.amsl.com (Postfix) with SMTP id 6D3053A6BFE for ; Thu, 20 May 2010 06:50:58 -0700 (PDT) From: RX-Store Subject: Your Discount Code on Amazon for atompub-archive@megatron.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100520135059.6D3053A6BFE@core3.amsl.com> Date: Thu, 20 May 2010 06:50:58 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://voiceslick.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 25346 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 36869 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 15752 is unauthorized. 20813

From owner-atom-syntax@mail.imc.org Thu May 20 08:11:46 2010 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 7D8DF3A6B48 for ; Thu, 20 May 2010 08:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.928 X-Spam-Level: * X-Spam-Status: No, score=1.928 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, 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 vxXKiMrvUiOt for ; Thu, 20 May 2010 08:11:45 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 087323A6BBC for ; Thu, 20 May 2010 08:11:40 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4KF3q2l063652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 May 2010 08:03:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4KF3qkJ063651; Thu, 20 May 2010 08:03:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4KF3oI6063646 for ; Thu, 20 May 2010 08:03:51 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by vws3 with SMTP id 3so2089786vws.16 for ; Thu, 20 May 2010 08:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=No8mNPk3tEcVlzUuNSJMpLk3shscqGjwfpwwVX79rXU=; b=vCh2+0DoEzHf4vZzEnGz0QbnFfMaD2tt2qVN4Dpo/oP95j1pVOxHkp3y9uuAqBr77V R8edC9lrc73y9VGCnNjfRhkt9pIj/0kNoZHiDvhK7hqzsG+ILA8HiCikjleCcKJYbwlP DBa20mMTXbV0pFeHm2los3KOfMSNHeaVujmDg= 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=muLG2Tw8Hs5xBzej2B2si8WUF82V2vCCuCnVcBHgSaT40U7GH0Gktk/Yyd1ev6qFDu XaWq1S62Ekh3A09IdWk+9VV14Y68A9iiGufrnJUpwa0YNKg4boYZCpRuLFvs1XBlqkXO hSb4Haf3r3h1VGCNXlcafVszWqoGCSalYDlNM= MIME-Version: 1.0 Received: by 10.229.242.12 with SMTP id lg12mr50280qcb.82.1274367830129; Thu, 20 May 2010 08:03:50 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Thu, 20 May 2010 08:03:50 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 May 2010 08:03:50 -0700 Message-ID: Subject: Re: Tombstones Update From: James Snell To: =?ISO-8859-1?Q?Niklas_Lindstr=F6m?= Cc: Ed Summers , Bob Wyman , Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4KF3pI6063647 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 2010/5/20 Niklas Lindström : > On Thu, May 20, 2010 at 8:54 AM, Ed Summers wrote: >> >> On Wed, May 19, 2010 at 10:58 PM, Bob Wyman wrote:. >>> I would strongly encourage you to ensure that deleted-entry is symmetrical >>> with atom:entry and that it is available in all contexts (i.e. both within >>> and without a Feed Document) that an Atom entry is. Just as we can have >>> Entry Documents, we should be able to have Deleted-entry Documents. >> >> +1 >> >> I could well imagine wanting to return a Tombstone as the message body >> for a 403 Gone response for a resource that I know has been deleted. > > +1 from me as well. > Ok, looks like we've got quite a bit good support for standalone docs.. I'll add that in. > Apart from the use cases already mentioned (XMPP, 403 > representations), I see potential for using deleted-entry documents in > our system (the swedish legal information system). I'm currently using > entry documents internally in our "depot", both as manifests and to > represent the collected source entries ("via" entries). Having > deleted-entry documents there as well would be very beneficial. > > (In fact, this was a primary motive for my wish for allowing > atom:source in at:deleted-entry elements. Which I'm very happy to see > in the latest draft -- thanks James!) > No prob. Thanks for the great feedback and input. > Two points come to mind if this is done: > > * What would the mime-type for deleted-entry documents be? A new > "application/atom+xml;type=deleted-entry"? Putting these under the application/atom+xml media type would likely cause badness. I'm thinking something like application/atomdeleted+xml. > * For good measure, making sure that this doesn't lead to a pattern of > PUT:ing deleted-entry docs instead of using DELETE... ;) > Yeah, this is a concern of mine also. Need to make sure people don't go there. > Best regards, > Niklas > -- - James Snell http://www.snellspace.com jasnell@gmail.com From agentx-archive@lists.ietf.org Thu May 20 10:46:19 2010 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 5A1793A6965 for ; Thu, 20 May 2010 10:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.008 X-Spam-Level: X-Spam-Status: No, score=-16.008 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889, HELO_DYNAMIC_SPLIT_IP=3.493, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_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 R2rotmMsjIcZ for ; Thu, 20 May 2010 10:46:18 -0700 (PDT) Received: from 195.Red-79-149-121.staticIP.rima-tde.net (195.Red-79-149-121.staticIP.rima-tde.net [79.149.121.195]) by core3.amsl.com (Postfix) with SMTP id 0FBA23A6950 for ; Thu, 20 May 2010 10:46:14 -0700 (PDT) From: RX-Store Subject: Electronic Discount Code 77% for atompub-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100520174615.0FBA23A6950@core3.amsl.com> Date: Thu, 20 May 2010 10:46:14 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://nationheat.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 47169 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 97873 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 16400 is unauthorized. 32429

From owner-atom-syntax@mail.imc.org Thu May 20 17:12:30 2010 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 DCBC53A69EE for ; Thu, 20 May 2010 17:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.454 X-Spam-Level: * X-Spam-Status: No, score=1.454 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 YwCOpDIt48hd for ; Thu, 20 May 2010 17:12:29 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6B3D83A6A2A for ; Thu, 20 May 2010 17:12:10 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4L06vTq093547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 May 2010 17:06:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4L06vRc093546; Thu, 20 May 2010 17:06:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4L06uvj093541 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 20 May 2010 17:06:57 -0700 (MST) (envelope-from Pablo.Castro@microsoft.com) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 May 2010 17:06:55 -0700 Received: from TK5EX14MBXC128.redmond.corp.microsoft.com ([169.254.7.44]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi; Thu, 20 May 2010 17:06:55 -0700 From: Pablo Castro To: "atom-syntax@imc.org" Subject: Next page links at the end of a feed Thread-Topic: Next page links at the end of a feed Thread-Index: Acr4eYRcZK8hh1zRRTO/fg5M+KmaGQ== Date: Fri, 21 May 2010 00:06:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F753B2C401114141B426DB383C8885E04DAD2481TK5EX14MBXC128r_" MIME-Version: 1.0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --_000_F753B2C401114141B426DB383C8885E04DAD2481TK5EX14MBXC128r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We are running into a conflict between compliance and efficiency in OData (= Astoria) and I wanted to bring it up in case we're not the first ones to ru= n into this. The Atom spec requires all the atom:link elements in a feed to come before = the actual entries (section 4.1.1 of the RFC). The problem is that in order= to compute the continuation token that will go in the href of the next lin= k we need to "see" the last entry we'll put on the wire when returning a pa= rtial collection. The requirement of having the link before the entries wou= ld force us to buffer all the entries, compute the next link, write the lin= k and then write the entries. In order to allow for a fully streaming serve= r implementation, it would be great if it were acceptable for the next link= to show up after the entries, at the end of a feed. Has anybody else run into this? At this point I'm not sure if existing clie= nts would choke when seeing a link in a different place. Is there a way we = could change this assuming folks see this as a reasonable thing to relax? Thanks -pablo --_000_F753B2C401114141B426DB383C8885E04DAD2481TK5EX14MBXC128r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are runnin= g into a conflict between compliance and efficiency in OData (Astoria) and = I wanted to bring it up in case we're not the first ones to run into this.<= o:p>

 

The Atom spec requires all the atom:link elements in a feed to come= before the actual entries (section 4.1.1 of the RFC). The problem is that = in order to compute the continuation token that will go in the href of the = next link we need to "see" the last entry we'll put on the wire w= hen returning a partial collection. The requirement of having the link befo= re the entries would force us to buffer all the entries, compute the next l= ink, write the link and then write the entries. In order to allow for a ful= ly streaming server implementation, it would be great if it were acceptable= for the next link to show up after the entries, at the end of a feed.=

 

Has anybody else run into this? At this point I'm not sure if existing = clients would choke when seeing a link in a different place. Is there a way= we could change this assuming folks see this as a reasonable thing to rela= x?

 

Thanks

-pablo

 

= --_000_F753B2C401114141B426DB383C8885E04DAD2481TK5EX14MBXC128r_-- From owner-atom-syntax@mail.imc.org Fri May 21 03:24:08 2010 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 6C7303A8569 for ; Fri, 21 May 2010 03:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.753 X-Spam-Level: *** X-Spam-Status: No, score=3.753 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_MISMATCH_COM=0.553, 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 LxsMUpV+BMEG for ; Fri, 21 May 2010 03:24:07 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2CD993A85A7 for ; Thu, 20 May 2010 23:58:44 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4L6rRAl011490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 May 2010 23:53:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4L6rRdC011489; Thu, 20 May 2010 23:53:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from spaceymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4L6rQAG011482 for ; Thu, 20 May 2010 23:53:27 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.1.100] (eth5126.nsw.adsl.internode.on.net [150.101.116.5]) by spaceymail-a1.g.dreamhost.com (Postfix) with ESMTP id 2EF4C8092F for ; Thu, 20 May 2010 23:53:25 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 21 May 2010 16:53:22 +1000 Subject: Re: Next page links at the end of a feed From: eric scheid To: "atom-syntax@imc.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 21/5/10 10:06 AM, "Pablo Castro" wrote: > The Atom spec requires all the atom:link elements in a feed to come before the > actual entries (section 4.1.1 of the RFC). Really? The only time the spec references the question of significance of order of child elements (eg. atom:entry in atom:feed, child elements of atom:entry, child elements in a Person construct, etc) it is quite clear that no significance is assigned. In context of RFCs, the "exception proves the rule" doctrine does not apply. Note too that the RELAX NG expressions in the spec are _informative_ only, and not _normative_. "Some sections of this specification are illustrated with fragments of a non-normative RELAX NG Compact schema. However, the text of this specification provides the definition of conformance." Since the _text_ spells out no MAY SHOULD MUST specification for the order of child elements of atom:feed at all, this means there is no such requirement in effect. Feel free to to put your atom:link elements following your atom:entry elements. e. From owner-atom-syntax@mail.imc.org Fri May 21 05:06:45 2010 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 6DD5F3A7D3D for ; Fri, 21 May 2010 05:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.515 X-Spam-Level: * X-Spam-Status: No, score=1.515 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, 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 7oZJUIEbBKmE for ; Fri, 21 May 2010 05:06:44 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E009C3A9C37 for ; Fri, 21 May 2010 00:51:40 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4L7kZFd014638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2010 00:46:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4L7kZmE014637; Fri, 21 May 2010 00:46:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.221.179]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4L7kY4j014632 for ; Fri, 21 May 2010 00:46:35 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk9 with SMTP id 9so1175728qyk.2 for ; Fri, 21 May 2010 00:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=89mMTmD0hDUdRujOWa9XyPMPqEOgdGi7Xu5wfuzEvao=; b=RycgBdUp3voFEvcBzWR9E+5Rzr8AkFZZArohRBGp3Stvedkaza4Z+kdYyCvdL7CoWr V4gK1jvIdeQzdVHErVm6vUm6WBYnPaH2OYJS+OmjTrIpe63HhrmFsuo4wBDnE/fwq/lc TEmeqizr0ZsqFx7sRiCVQ+y7qAKLLQK2MVspM= 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=cy/IZLaD3ojPYlp32zYkfjBcBr/xC7R2QV0buyuPAjaDw8HH7piuWIpyuauqX9bmrb 8Jp/94+lpk+Xq1xZwajqnt+oLV9pxuIPlRwkyrKIGIGN7sb8YTGrM+vp/Pqrya5P8zSV x5iBGziv54iBpMGe7wSn0zaBMGKkaClWkv01s= MIME-Version: 1.0 Received: by 10.224.30.135 with SMTP id u7mr896380qac.197.1274427993775; Fri, 21 May 2010 00:46:33 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Fri, 21 May 2010 00:46:33 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 May 2010 00:46:33 -0700 Message-ID: Subject: Re: Next page links at the end of a feed From: James Snell To: eric scheid Cc: "atom-syntax@imc.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4L7kZ4j014633 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hmmm... from Section 4.1.1.... "Its element children consist of metadata elements followed by zero or more atom:entry child elements." This is pretty clear. The entries are expected to come last. On Thu, May 20, 2010 at 11:53 PM, eric scheid wrote: > > On 21/5/10 10:06 AM, "Pablo Castro" wrote: > >> The Atom spec requires all the atom:link elements in a feed to come before the >> actual entries (section 4.1.1 of the RFC). > > Really? > > The only time the spec references the question of significance of order of > child elements (eg. atom:entry in atom:feed, child elements of atom:entry, > child elements in a Person construct, etc) it is quite clear that no > significance is assigned. > > In context of RFCs, the "exception proves the rule" doctrine does not apply. > > Note too that the RELAX NG expressions in the spec are _informative_ only, > and not _normative_. > >   "Some sections of this specification are illustrated with fragments of >    a non-normative RELAX NG Compact schema. However, the text of this >    specification provides the definition of conformance." > > Since the _text_ spells out no MAY SHOULD MUST specification for the order > of child elements of atom:feed at all, this means there is no such > requirement in effect. > > Feel free to to put your atom:link elements following your atom:entry > elements. > > e. > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Fri May 21 13:35:35 2010 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 3DB063A700C for ; Fri, 21 May 2010 13:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.377 X-Spam-Level: * X-Spam-Status: No, score=1.377 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 nT1bvKhj63j3 for ; Fri, 21 May 2010 13:35:34 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D67063A6D1E for ; Fri, 21 May 2010 07:34:52 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4LESYkc039174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2010 07:28:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4LESYC7039173; Fri, 21 May 2010 07:28:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.221.179]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4LESXa4039167 for ; Fri, 21 May 2010 07:28:33 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk9 with SMTP id 9so1651821qyk.2 for ; Fri, 21 May 2010 07:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:received :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=9tu2kB3GpXEbuSfBNsytIlo5T57etsVZTITgCr1ViDw=; b=JlbfhZ6u7Jcg5lGyhO+A6pBOrL/qqBmtYoA3YL0GLhoObpmmnFtapHzT0TUtW6IOss gRTAJ+HbRuy51jlYA4lb07Rddv/eXL+0LYL3vSMZqiEKJ5EetPm/Sub940YXMedISJay vlup0uVj2YOKUad9yExz2pqSUYjBTm+PddRjg= 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; b=N7iJ+Vr3QZUfqgeAEQiPHeAsYQ90C13DsdS7vDpRYcGiWqhTHaq5mdftwY0zd2to+9 bDlNdqhOIsmxcR91IJ1SvsOzQZNlkXBa4kzUSQoWHKMdDSDebKTPZMh/UVOt4aOurTqw xBhxH71rkpCc4hRiwLQBSp2v9S9Q1YN6QcN5E= MIME-Version: 1.0 Received: by 10.224.75.206 with SMTP id z14mr1196865qaj.24.1274452112067; Fri, 21 May 2010 07:28:32 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Fri, 21 May 2010 07:28:31 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Fri, 21 May 2010 07:28:31 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 May 2010 07:28:31 -0700 Message-ID: Subject: Re: Tombstones Update From: James Snell To: =?ISO-8859-1?Q?Niklas_Lindstr=F6m?= Cc: Ed Summers , Bob Wyman , Atom Syntax Content-Type: multipart/alternative; boundary=001485eba7066c4f3404871b81c6 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001485eba7066c4f3404871b81c6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-09.txt Quite a few important updates. On May 20, 2010 8:03 AM, "James Snell" wrote: 2010/5/20 Niklas Lindstr=F6m : > On Thu, May 20, 2010 at 8:54 AM, Ed Summers wrote: >> >> On Wed, May 19, 2010 at 1... Ok, looks like we've got quite a bit good support for standalone docs.. I'll add that in. > Apart from the use cases already mentioned (XMPP, 403 > representations), I see potential for usi... No prob. Thanks for the great feedback and input. > Two points come to mind if this is done: > > * What would the mime-type for deleted-entry documen... Putting these under the application/atom+xml media type would likely cause badness. I'm thinking something like application/atomdeleted+xml. > * For good measure, making sure that this doesn't lead to a pattern of > PUT:ing deleted-entry do... Yeah, this is a concern of mine also. Need to make sure people don't go there. > Best regards, > Niklas > -- - James Snell http://www.snellspace.com jasnell@gmail.com --001485eba7066c4f3404871b81c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

http://www.ietf.org/internet-drafts/draft-snell-atompub-tombs= tones-09.txt

Quite a few important updates.

On May 20, 2010 8:03 AM, "James Snell&quo= t; <jasnell@gmail.com> wrote= :

2010/5/20 Niklas Lindstr=F6m <lindstream@gmail.com>:

> On Thu, May 20, 2010 at 8:54 AM, Ed Summers= <ehs@pobox.com> wrote:
>&= gt;
>> On Wed, May 19, 2010 at 1...

Ok, looks like we= 9;ve got quite a bit good support for standalone
docs.. I'll add that in.


> Apart from the use cases already mentio= ned (XMPP, 403
> representations), I see potential for usi...<= /p>No prob. Thanks for the great feedback and input.


> Two points come to mind if this is done= :
>
> * What would the mime-type for deleted-entry documen...

Putting these under the application/atom+xml media type would like= ly
cause badness. I'm thinking something like
application/atomdeleted+xml.


> * For good measure, making sure that th= is doesn't lead to a pattern of
> PUT:ing deleted-entry do...

Yeah, this is a concern of mine also. Need to make sure people don&#= 39;t go there.

> Best regards,
> Niklas
>



--

- James Snell
http://www.snellspace.com
jasnell@gmail.com

--001485eba7066c4f3404871b81c6-- From atompub-archive@megatron.ietf.org Fri May 21 17:28:32 2010 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 B43CD3A6855 for ; Fri, 21 May 2010 17:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.488 X-Spam-Level: X-Spam-Status: No, score=-11.488 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, 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 sbKBod-aVmEz for ; Fri, 21 May 2010 17:28:31 -0700 (PDT) Received: from amd.com (unknown [95.179.25.97]) by core3.amsl.com (Postfix) with SMTP id 334363A6875 for ; Fri, 21 May 2010 17:28:26 -0700 (PDT) From: RX-Store Subject: Special Discount 75% for atompub-archive@megatron.ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100522002830.334363A6875@core3.amsl.com> Date: Fri, 21 May 2010 17:28:26 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://necksame.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 86178 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 17066 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 76656 is unauthorized. 06353

From atompub-archive@lists.ietf.org Sat May 22 02:31:34 2010 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 A57BE3A6BF7 for ; Sat, 22 May 2010 02:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 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_DYNAMIC=1.144, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 M1BSUBj5CrMG for ; Sat, 22 May 2010 02:31:33 -0700 (PDT) Received: from 109-167-36-18.dynamic.peoplenet.ua (109-167-36-18.dynamic.peoplenet.ua [109.167.36.18]) by core3.amsl.com (Postfix) with SMTP id 7817B3A6BF1 for ; Sat, 22 May 2010 02:31:19 -0700 (PDT) From: RX-Store Subject: Your Discount Code on Amazon for atompub-archive@lists.ietf.org To: MIME-Version: 1.0 Content-Type: text/html X-Antivirus: avast! (VPS 100227-2, 27.02.2010), Outbound message X-Antivirus-Status: Clean Message-Id: <20100522093120.7817B3A6BF1@core3.amsl.com> Date: Sat, 22 May 2010 02:31:19 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://necksame.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 75859 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 22332 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 56973 is unauthorized. 90495

From atompub-archive@lists.ietf.org Sat May 22 13:10:36 2010 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 AAB893A684E for ; Sat, 22 May 2010 13:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.092 X-Spam-Level: X-Spam-Status: No, score=-17.092 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HTML_IMAGE_ONLY_24=1.552, 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, 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 gruiXv1N2Cjo for ; Sat, 22 May 2010 13:10:33 -0700 (PDT) Received: from clnt-69-127.mytrinity.com.ua (clnt-69-127.mytrinity.com.ua [217.67.69.127]) by core3.amsl.com (Postfix) with SMTP id BA9833A6802 for ; Sat, 22 May 2010 13:10:32 -0700 (PDT) From: RX-Store Subject: Your Future Order with 79% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100522201032.BA9833A6802@core3.amsl.com> Date: Sat, 22 May 2010 13:10:32 -0700 (PDT)
Delivery department work across the Globe.
Please click here if the e-mail below is not displayed correctly.

This feature will help you stay in touch with friends and family. We will continually work to add new services over time.
http://letternoun.com/ Stay Connected with Family and Friends!

ABRA LLC. All Rights Reserved
ABRA Inc. does not authorize the use of its proprietary computers and computer network (the 79524 Network") to accept, transmit or distribute unsolicited bulk e-mail sent from the Internet to ASDuuq members. In addition, Internet e-mail sent, or caused to be sent, to or through the 07145 that makes use of or contains invalid or forged headers, invalid or non-existent domain names or other means of deceptive addressing will be deemed to be counterfeit. Any attempt to send or cause such counterfeit e-mail to be sent to or through the 11227 is unauthorized. 04925

From owner-atom-syntax@mail.imc.org Mon May 24 07:35:38 2010 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 A74B03A6837 for ; Mon, 24 May 2010 07:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.978 X-Spam-Level: ** X-Spam-Status: No, score=2.978 tagged_above=-999 required=5 tests=[AWL=-1.199, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=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 38RGSICVwfai for ; Mon, 24 May 2010 07:35:33 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 0B7493A67F2 for ; Mon, 24 May 2010 07:35:29 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OESulN020907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 07:28:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4OESuVI020906; Mon, 24 May 2010 07:28:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.211.194]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OEStfD020900 for ; Mon, 24 May 2010 07:28:55 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by ywh32 with SMTP id 32so2301698ywh.5 for ; Mon, 24 May 2010 07:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=P4GorSNuvGwZr7Ft/zuzXYsf7xxXwDxujJZfNTwG6m0=; b=IZ/i+meVwQ9PxSNNuUXwuS+oQ4r72GHmGwtlLMHYKq6eNx/irdxWWcffUNJN7oV+Gj Km0KsNB+jE6xiUARfS8fexiu2N52HMT79dYKEZWgjiOvckXZpqI2oJf0vFzG+57NDaBv TUXzL9QB83cxH+vPvmgWaeJp1cWWg6xJCqhOM= 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=tlf59DNEJmJu1NGRpE99SfawpoLqivxHyqVs+RkC3MLYjsr8r+bcfEa7a2tJR60/Hy Cu8mPO1J7W6thu5TSeCUMrmix7fPd/ddm2iLtdQ0hwNPvCtf9nZyYsb/ivraAsavA9we V3Er69AMpwI4kTpaE2ls6gM/mLcYzI7Hbg/h0= MIME-Version: 1.0 Received: by 10.101.158.39 with SMTP id k39mr6829643ano.203.1274711332580; Mon, 24 May 2010 07:28:52 -0700 (PDT) Received: by 10.100.154.20 with HTTP; Mon, 24 May 2010 07:28:52 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 May 2010 10:28:52 -0400 X-Google-Sender-Auth: xKFMUrH5uJ6nufedSIds_7lpnCs Message-ID: Subject: Re: Tombstones Update From: Bob Wyman To: James Snell Cc: =?ISO-8859-1?Q?Niklas_Lindstr=F6m?= , Ed Summers , Atom Syntax Content-Type: multipart/alternative; boundary=0016e68ea0ad2b6d20048757dc98 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0016e68ea0ad2b6d20048757dc98 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The Tombstone draft is coming along nicely, however, I can't help wondering... Since it appears that a deleted-entry is so much like a normal entry, why isn't it just an extended atom:entry with some additional elemen= t or attribute flagging it as deleted? There are a number of "deletion" use cases, some of which already have support in the base Atom Format specification. For instance, since Atom defines "replacement," (i.e. publish an entry with the same atom:id as one previously published but with a later atom:updated date), there is already = a crude method for asking that content be removed from aggregators. However, this tends to encouraging people to publish entries that have titles of "Deleted," content of "Deleted." Etc. Not particularly elegant -- but it works, sort of. I'm afraid that if deleted-entry is introduced into the system, what we'll see is that during some arbitrarily long transition period while we wait fo= r people to modify their software to support deleted-entry, people who really want to purge the network of some late night blog post will tend to publish both a "Deleted" replacement entry as well as a deleted-entry... They would do this since it is potentially going to be a long time (perhaps infinite) before deleted-entry is widely implemented and just publishing a normal entry has much the same effect (but not completely) of publishing a deleted-entry. If, on the other hand, the definition of entry was extended to permit a "deleted" flag or attribute, then we'd find that applications would have implicit support for entry deletion without needing to write any more code. Certainly, applications that understood what a deletion actually meant and that understood the extra fields like when, by and comment, would be able t= o do interesting things based on that understanding. I'm also concerned that the utility of the deleted-entry mechanism is limited to only those systems that rely on "topic-based" filtering -- i.e. following a specific feed and consuming all of its content. We would need some entirely different mechanism to support content-based filtering -- i.e= . extracting entries based on their content (presence of words, phrases, etc.). Deleted-entry can't help a content-based system since unless such systems maintain cumbersome logs of all atom:ids that are published and who they were published to. The problem is that since a deleted-entry contains virtually none of the data contained in the entry deleted, any topic-based filtering can't figure out who might have previously received a copy of the now-deleted entry. Of course, the easiest way to delete things in a content-based system would be to republish the original entry (with all its content) and mark the entr= y as "deleted." This will work in, but not all applications, since in some applications, one does not wish to republish the data that is being deleted= . However, in at least some applications, where one can trust that consumers are paying attention to the deleted flag, it is acceptable to republish the now out-of-date data. If a deleted-entry is so much like an entry, why can't it just be one? (wit= h some extra metadata). bob wyman 2010/5/21 James Snell > http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-09.txt > > Quite a few important updates. > > On May 20, 2010 8:03 AM, "James Snell" wrote: > > 2010/5/20 Niklas Lindstr=F6m : > > > On Thu, May 20, 2010 at 8:54 AM, Ed Summers wrote: > >> > >> On Wed, May 19, 2010 at 1... > > Ok, looks like we've got quite a bit good support for standalone > docs.. I'll add that in. > > > > Apart from the use cases already mentioned (XMPP, 403 > > representations), I see potential for usi... > > No prob. Thanks for the great feedback and input. > > > > Two points come to mind if this is done: > > > > * What would the mime-type for deleted-entry documen... > > Putting these under the application/atom+xml media type would likely > cause badness. I'm thinking something like > application/atomdeleted+xml. > > > > * For good measure, making sure that this doesn't lead to a pattern of > > PUT:ing deleted-entry do... > > Yeah, this is a concern of mine also. Need to make sure people don't go > there. > > > Best regards, > > Niklas > > > > > > -- > > - James Snell > http://www.snellspace.com > jasnell@gmail.com > > --0016e68ea0ad2b6d20048757dc98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The Tombstone draft is coming along nicely, however, I can't help wonde= ring... Since it appears that a deleted-entry is so much like a normal entr= y, why isn't it just an extended atom:entry with some additional elemen= t or attribute flagging it as deleted?

There are a number of "deletion" use cases, some o= f which already have support in the base Atom Format specification. For ins= tance, since Atom defines "replacement," (i.e. publish an entry w= ith the same atom:id as one previously published but with a later atom:upda= ted date), there is already a crude method for asking that content be remov= ed from aggregators. However, this tends to encouraging people to publish e= ntries that have titles of "Deleted," content of "Deleted.&q= uot; Etc. Not particularly elegant -- but it works, sort of.=A0

I'm afraid that if deleted-entry is introduced into= the system, what we'll see is that during some arbitrarily long transi= tion period while we wait for people to modify their software to support de= leted-entry, people who really want to purge the network of some late night= blog post will tend to publish both a "Deleted" replacement entr= y as well as a deleted-entry... They would do this since it is potentially = going to be a long time (perhaps infinite) before deleted-entry is widely i= mplemented and just publishing a normal entry has much the same effect (but= not completely) of publishing a deleted-entry.

If, on the other hand, the definition of entry was exte= nded to permit a "deleted" flag or attribute, then we'd find = that applications would have implicit support for entry deletion without ne= eding to write any more code. Certainly, applications that understood what = a deletion actually meant and that understood the extra fields like when, b= y and comment, would be able to do interesting things based on that underst= anding.

I'm also concerned that the utility of the deleted-= entry mechanism is limited to only those systems that rely on "topic-b= ased" filtering -- i.e. following a specific feed and consuming all of= its content. We would need some entirely different mechanism to support co= ntent-based filtering -- i.e. extracting entries based on their content (pr= esence of words, phrases, etc.). Deleted-entry can't help a content-bas= ed system since unless such systems maintain cumbersome logs of all atom:id= s that are published and who they were published to. The problem is that si= nce a deleted-entry contains virtually none of the data contained in the en= try deleted, any topic-based filtering can't figure out who might have = previously received a copy of the now-deleted entry.=A0

Of course, the easiest way to delete things in a conten= t-based system would be to republish the original entry (with all its conte= nt) and mark the entry as "deleted." This will work in, but not a= ll applications, since in some applications, one does not wish to republish= the data that is being deleted. However, in at least some applications, wh= ere one can trust that consumers are paying attention to the deleted flag, = it is acceptable to republish the now out-of-date data.

If a deleted-entry is so much like an entry, why can= 9;t it just be one? (with some extra metadata).

bo= b wyman

2010/5/21 James Snell <jasnell@gmail.com>

http://www.= ietf.org/internet-drafts/draft-snell-atompub-tombstones-09.txt

Quite a few important updates.

On May 20, 2010 8:03 AM,= "James Snell" <jasnell@gmail.com> wrote:

2010/5/20 Niklas Lindstr= =F6m <lindstre= am@gmail.com>:

> On Thu, May 20, 2010 at 8:54 AM, Ed Summers <ehs@pobox.com> wrote:
>= ;>
>> On Wed, May 19, 2010 at 1...

= Ok, looks like we've got quite a bit good support for standalone
docs.. I'll add that in.


> Apart from the use cases already mentioned (XMPP, 403
> representations), I see potential for usi...

No prob. Thanks for the great feedback and input.


> Two points come to mind if this is done:
>
> * What would the mime-type for deleted-entry documen...

Putting these under the application/atom+xml media type w= ould likely
cause badness. I'm thinking something like
application/atomdeleted+xml.


> * For good measure, making sure that this doesn't l= ead to a pattern of
> PUT:ing deleted-entry do...

=
Yeah, this is a concern of mine also. Need to make sure people don't go= there.

> Best regards,
> Niklas
>



--

- James Snell
http://www.snellspace.com
jasnell@gmail.com


--0016e68ea0ad2b6d20048757dc98-- From owner-atom-syntax@mail.imc.org Mon May 24 11:38:56 2010 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 844193A716C for ; Mon, 24 May 2010 11:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.154 X-Spam-Level: * X-Spam-Status: No, score=1.154 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_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 UgOm4ZMGd+fD for ; Mon, 24 May 2010 11:38:55 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6E4733A6F69 for ; Mon, 24 May 2010 11:34:40 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OIT254034014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 11:29:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4OIT2Rb034013; Mon, 24 May 2010 11:29:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.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 hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OIT2r0034008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 May 2010 11:29:02 -0700 (MST) (envelope-from dret@berkeley.edu) Received: from [128.32.226.221] (dhcp221.ISchool.Berkeley.EDU [128.32.226.221]) (authenticated bits=0) by smtp.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id o4OISuHc016007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 May 2010 11:29:00 -0700 Message-ID: <4BFAC569.5050107@berkeley.edu> Date: Mon, 24 May 2010 11:28:57 -0700 From: Erik Wilde User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Tombstones Update References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 128.32.78.13 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hello. Bob Wyman wrote: > The Tombstone draft is coming along nicely, however, I can't help > wondering... Since it appears that a deleted-entry is so much like a > normal entry, why isn't it just an extended atom:entry with some > additional element or attribute flagging it as deleted? i think this is a great approach of looking at what "deletion" means, in a way it's just another "update". however, there probably are two major problems with this approach: - it is not backwards-compatible with prior versions of the draft, and it seems that the draft already has seen some adoption. if the goal is to not break these early implementations, then moving from deleted-entry to entry is not an option, i am afraid. - atom disallows extensions to change the semantics of any standard atom elements. whether additional metadata changing the semantics of an "updated" entry to a "deleted" entry is such a change in semantics is a question of perspective. one could say that "deleted" is different from "updated", or one could say that it's just a special case. http://tools.ietf.org/html/rfc4287#section-4.2.15 just says that 'The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant', which i think could be seen as covering the case of deletion of an entry as well. personally, i think that having an entry/@deleted would be quite a bit more elegant and consistent than having a deleted-entry (there is no updated-entry, after all...), but that still does not solve the problem of breaking early adopters' code. but for me, the most important thing is to have something in feeds that covers the CRUD's D, so i am very glad to see the tombstone draft moving along again, whatever it will end up defining. 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 May 24 12:12:56 2010 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 EC3453A6824 for ; Mon, 24 May 2010 12:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.928 X-Spam-Level: * X-Spam-Status: No, score=1.928 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 MBVv1B4UhCQw for ; Mon, 24 May 2010 12:12:53 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 4711B3A6830 for ; Mon, 24 May 2010 12:12:51 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OJ8vlA035999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 12:08:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4OJ8vVv035998; Mon, 24 May 2010 12:08:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.211.194]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OJ8uSP035993 for ; Mon, 24 May 2010 12:08:56 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by ywh32 with SMTP id 32so2520545ywh.5 for ; Mon, 24 May 2010 12:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=YmpD8GzeM8FNrnkQ4WhjHOyW7hDqMK73P2LM5CtO+R4=; b=qmAMCCwDv8chdjahaoLxlo5ZVUzbygTNbrbTbd4YIZQ+UkYLoBa9h3/CGx2jMxpbdh wmrBc1m9ya/DPqGiziYcuE7v9Tk5gY6/6mCjJIKxY9Qa6lOLcua73rNFfFrkQMf3WtMe Dm2fUY9mcPdvOqjwewfDWdRHGx4VDa5aOslHk= 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=ECEH+rQQZdc50FmJx+9VcRdeC0J/EkolA/+5nXCmJGSmFZUaCccZPNYNA7pxxdjdPs nW5EgQ1gH9Vr7LAzeV3dSWjBLCX4x2yuC66lJzJXBcXbpx6T8amJRwBBpGQJBa0aHEv2 sudvWgbU4kgywk465qx4VUdiq7wQQ3VVVZti8= MIME-Version: 1.0 Received: by 10.101.129.17 with SMTP id g17mr6949272ann.101.1274728135128; Mon, 24 May 2010 12:08:55 -0700 (PDT) Received: by 10.100.154.20 with HTTP; Mon, 24 May 2010 12:08:53 -0700 (PDT) In-Reply-To: <4BFAC569.5050107@berkeley.edu> References: <4BFAC569.5050107@berkeley.edu> Date: Mon, 24 May 2010 15:08:53 -0400 X-Google-Sender-Auth: DyK0d4LAtbpYYZvoOiSJKTLYwaY Message-ID: Subject: Re: Tombstones Update From: Bob Wyman To: Erik Wilde Cc: Atom Syntax Content-Type: multipart/alternative; boundary=001636ed6abdadf53304875bc550 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636ed6abdadf53304875bc550 Content-Type: text/plain; charset=ISO-8859-1 Erik, I don't think we would have to go as far as changing the semantics of any standard atom elements. Rather, what I'm suggesting is that "delete" is really just a bit of an extension to what the existing replace means. In other words, if you understand the "delete" flag, however, it is encoded, you would do a delete, if not, then you would simply do a replace as per the existing spec. This would be properly backwards-compatible. I would, of course, regret breaking any early-adopter code. However, I suggest that there is a much larger population of long-ago-adopters who wrote Atom code potentially years ago and would, if deleted-entry became accepted, have to consider rewriting or at least modifying their code. One of the risks of being an early adopter is that things may change, however, people who wrote code to the published spec should be granted the right to expect that things will be more stable. The only downside I can see in extending the existing entry is that the resulting tombstones would be a bit less bit-efficient than desirable. (i.e. they would, in most cases, probably end up having empty required elements -- such as atom:title.) bob wyman On Mon, May 24, 2010 at 2:28 PM, Erik Wilde wrote: > > hello. > > > Bob Wyman wrote: > >> The Tombstone draft is coming along nicely, however, I can't help >> wondering... Since it appears that a deleted-entry is so much like a normal >> entry, why isn't it just an extended atom:entry with some additional element >> or attribute flagging it as deleted? >> > > i think this is a great approach of looking at what "deletion" means, in a > way it's just another "update". however, there probably are two major > problems with this approach: > > - it is not backwards-compatible with prior versions of the draft, and it > seems that the draft already has seen some adoption. if the goal is to not > break these early implementations, then moving from deleted-entry to entry > is not an option, i am afraid. > > - atom disallows extensions to change the semantics of any standard atom > elements. whether additional metadata changing the semantics of an "updated" > entry to a "deleted" entry is such a change in semantics is a question of > perspective. one could say that "deleted" is different from "updated", or > one could say that it's just a special case. > http://tools.ietf.org/html/rfc4287#section-4.2.15 just says that 'The > "atom:updated" element is a Date construct indicating the most recent > instant in time when an entry or feed was modified in a way the publisher > considers significant', which i think could be seen as covering the case of > deletion of an entry as well. > > personally, i think that having an entry/@deleted would be quite a bit more > elegant and consistent than having a deleted-entry (there is no > updated-entry, after all...), but that still does not solve the problem of > breaking early adopters' code. but for me, the most important thing is to > have something in feeds that covers the CRUD's D, so i am very glad to see > the tombstone draft moving along again, whatever it will end up defining. > > cheers, > > erik wilde tel:+1-510-6432253 - fax:+1-510-6425814 > dret@berkeley.edu - http://dret.net/netdret > UC Berkeley - School of Information (ISchool) > > --001636ed6abdadf53304875bc550 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Erik,
I don't think we would have to go as far as changing the sema= ntics of any standard atom elements. Rather, what I'm suggesting is tha= t "delete" is really just a bit of an extension to what the exist= ing replace means. In other words, if you understand the "delete"= flag, however, it is encoded, you would do a delete, if not, then you woul= d simply do a replace as per the existing spec. This would be properly back= wards-compatible.

I would, of course, regret breaking any early-adopter c= ode. However, I suggest that there is a much larger population of long-ago-= adopters who wrote Atom code potentially years ago and would, if deleted-en= try became accepted, have to consider rewriting or at least modifying their= code. One of the risks of being an early adopter is that things may change= , however, people who wrote code to the published spec should be granted th= e right to expect that things will be more stable.

The only downside I can see in extending the existing e= ntry is that the resulting tombstones would be a bit less bit-efficient tha= n desirable. (i.e. they would, in most cases, probably end up having empty = required elements -- such as atom:title.)

bob wyman

On M= on, May 24, 2010 at 2:28 PM, Erik Wilde <dret@berkeley.edu> wrote:

hello.


Bob Wyman wrote:
The Tombstone draft is coming along nicely, however, I can't help wonde= ring... Since it appears that a deleted-entry is so much like a normal entr= y, why isn't it just an extended atom:entry with some additional elemen= t or attribute flagging it as deleted?

i think this is a great approach of looking at what "deletion" me= ans, in a way it's just another "update". however, there prob= ably are two major problems with this approach:

- it is not backwards-compatible with prior versions of the draft, and it s= eems that the draft already has seen some adoption. if the goal is to not b= reak these early implementations, then moving from deleted-entry to entry i= s not an option, i am afraid.

- atom disallows extensions to change the semantics of any standard atom el= ements. whether additional metadata changing the semantics of an "upda= ted" entry to a "deleted" entry is such a change in semantic= s is a question of perspective. one could say that "deleted" is d= ifferent from "updated", or one could say that it's just a sp= ecial case. http://tools.ietf.org/html/rfc4287#section-4.2.15 just= says that 'The "atom:updated" element is a Date construct in= dicating the most recent instant in time when an entry or feed was modified= in a way the publisher considers significant', which i think could be = seen as covering the case of deletion of an entry as well.

personally, i think that having an entry/@deleted would be quite a bit more= elegant and consistent than having a deleted-entry (there is no updated-en= try, after all...), but that still does not solve the problem of breaking e= arly adopters' code. but for me, the most important thing is to have so= mething in feeds that covers the CRUD's D, so i am very glad to see the= tombstone draft moving along again, whatever it will end up defining.

cheers,

erik wilde =A0 tel:+1-510-6432253 - fax:+1-510-6425814
=A0 =A0 =A0 dret@be= rkeley.edu =A0- =A0http://dret.net/netdret
=A0 =A0 =A0 UC Berkeley - School of Information (ISchool)


--001636ed6abdadf53304875bc550-- From owner-atom-syntax@mail.imc.org Mon May 24 12:35:07 2010 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 0D1A13A7049 for ; Mon, 24 May 2010 12:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.896 X-Spam-Level: * X-Spam-Status: No, score=1.896 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, 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 L6tSxr-E5D9U for ; Mon, 24 May 2010 12:35:05 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 409963A7120 for ; Mon, 24 May 2010 12:33:54 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OJSl1D036882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 12:28:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4OJSlvD036881; Mon, 24 May 2010 12:28:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OJSj9l036874 for ; Mon, 24 May 2010 12:28:46 -0700 (MST) (envelope-from pjkeane@gmail.com) Received: by wyf28 with SMTP id 28so1239404wyf.16 for ; Mon, 24 May 2010 12:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=4dU3h+Z9VncJRSHUsS4yQ8LfuxWANu8yFn1h3roSTrc=; b=wxNpqrWCBwlLSWaG0BbXadFgjTUyBiTh233cLK9Om4v4dzuHg0BeuLFyvcx8oHN/BJ NIX/kxjyZBTLbglrwvqre8h2tnokGaE1EHsNLh7LKwwn13G/MQWhRpZHHLxzBznVqeBg q965WEoT4DXrn7dncqhVD9IGJq3TaFlxDiyfQ= 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=EVazA2m0Cp3QauE5mcSKlluQTrKKbut1zRxXPqBQekVXor1KgCglnOZlKLh3cf2fhq EemnHGPnbtKUwuaZdHjLDs89gD/IvB/+AbJt1wgr7srpWKOWm3JSSyjZiqwyWPsP0vgw DnFU/+Z/CGLiWi8cIEx7d+VBKznAyyPWJ40F4= MIME-Version: 1.0 Received: by 10.216.90.19 with SMTP id d19mr3915693wef.166.1274729324945; Mon, 24 May 2010 12:28:44 -0700 (PDT) Received: by 10.216.89.20 with HTTP; Mon, 24 May 2010 12:28:44 -0700 (PDT) In-Reply-To: References: <4BFAC569.5050107@berkeley.edu> Date: Mon, 24 May 2010 14:28:44 -0500 X-Google-Sender-Auth: qbNfAZUFDgKoIOlX1ZdDMrtXftg Message-ID: Subject: Re: Tombstones Update From: Peter Keane To: Bob Wyman Cc: Erik Wilde , Atom Syntax Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4OJSl9l036877 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi All- For what it is worth, there was a fairly in-depth conversation about tombstones back in Dec 2007. James Snell (and others) put forth strong arguments against it just being another atom:entry (I was among those, at the time, advocating for atom:entry, but I have come around to the lighter option mainly for practical (not aesthetic) reasons). The thread begins here, and may be worth perusing (follow links to follow-ups): http://www.imc.org/atom-syntax/mail-archive/msg20050.html --Peter On Mon, May 24, 2010 at 2:08 PM, Bob Wyman wrote: > Erik, > I don't think we would have to go as far as changing the semantics of any > standard atom elements. Rather, what I'm suggesting is that "delete" is > really just a bit of an extension to what the existing replace means. In > other words, if you understand the "delete" flag, however, it is encoded, > you would do a delete, if not, then you would simply do a replace as per the > existing spec. This would be properly backwards-compatible. > I would, of course, regret breaking any early-adopter code. However, I > suggest that there is a much larger population of long-ago-adopters who > wrote Atom code potentially years ago and would, if deleted-entry became > accepted, have to consider rewriting or at least modifying their code. One > of the risks of being an early adopter is that things may change, however, > people who wrote code to the published spec should be granted the right to > expect that things will be more stable. > The only downside I can see in extending the existing entry is that the > resulting tombstones would be a bit less bit-efficient than desirable. (i.e. > they would, in most cases, probably end up having empty required elements -- > such as atom:title.) > bob wyman > On Mon, May 24, 2010 at 2:28 PM, Erik Wilde wrote: >> >> hello. >> >> Bob Wyman wrote: >>> >>> The Tombstone draft is coming along nicely, however, I can't help >>> wondering... Since it appears that a deleted-entry is so much like a normal >>> entry, why isn't it just an extended atom:entry with some additional element >>> or attribute flagging it as deleted? >> >> i think this is a great approach of looking at what "deletion" means, in a >> way it's just another "update". however, there probably are two major >> problems with this approach: >> >> - it is not backwards-compatible with prior versions of the draft, and it >> seems that the draft already has seen some adoption. if the goal is to not >> break these early implementations, then moving from deleted-entry to entry >> is not an option, i am afraid. >> >> - atom disallows extensions to change the semantics of any standard atom >> elements. whether additional metadata changing the semantics of an "updated" >> entry to a "deleted" entry is such a change in semantics is a question of >> perspective. one could say that "deleted" is different from "updated", or >> one could say that it's just a special case. >> http://tools.ietf.org/html/rfc4287#section-4.2.15 just says that 'The >> "atom:updated" element is a Date construct indicating the most recent >> instant in time when an entry or feed was modified in a way the publisher >> considers significant', which i think could be seen as covering the case of >> deletion of an entry as well. >> >> personally, i think that having an entry/@deleted would be quite a bit >> more elegant and consistent than having a deleted-entry (there is no >> updated-entry, after all...), but that still does not solve the problem of >> breaking early adopters' code. but for me, the most important thing is to >> have something in feeds that covers the CRUD's D, so i am very glad to see >> the tombstone draft moving along again, whatever it will end up defining. >> >> 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 May 24 12:36:53 2010 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 D914E3A6812 for ; Mon, 24 May 2010 12:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.876 X-Spam-Level: * X-Spam-Status: No, score=1.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, 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 WLuQd0vVaGjd for ; Mon, 24 May 2010 12:36:52 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 79E723A6E64 for ; Mon, 24 May 2010 12:36:52 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OJWAUv037032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 12:32:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4OJWAbJ037031; Mon, 24 May 2010 12:32:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-ww0-f43.google.com (mail-ww0-f43.google.com [74.125.82.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OJW9xS037026 for ; Mon, 24 May 2010 12:32:09 -0700 (MST) (envelope-from pjkeane@gmail.com) Received: by wwi17 with SMTP id 17so214176wwi.16 for ; Mon, 24 May 2010 12:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=niFLI9csoOwKEkFbXj3gVe0Eond3p/ohUDVrVBicW8g=; b=BI0qvwE/2DhIbWhYtoVfxFoNUvJdqmi4j28DFQ5mWJAa3smaXujEKLEyeyW2tF86L6 s6LEu1zuAQblRKtazVedYoLwqJ8E9W38Jh1qFsIKy4xP8n97UYHnRvE3KsNJKtK7pw/Y BJ2wW1ez/6H8wx7/z1EH373OC96tT5j52hGNs= 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=cf3Jwa0co2NI020huiuiviZNoDZNOyyLRYsiMHNhVZLOG5dI3tqgHPnK/vm81lx1un MpGDzLCc4gfplRoubUWdGZAgTf1FMVMh31aVpryxDJD9uqy3ukkGRuAY48GIEzZHQAei 9vQ58tC0xPluVtrTsvjg4f6GfPmOJZaFiZMI0= MIME-Version: 1.0 Received: by 10.216.161.131 with SMTP id w3mr3940654wek.109.1274729527871; Mon, 24 May 2010 12:32:07 -0700 (PDT) Received: by 10.216.89.20 with HTTP; Mon, 24 May 2010 12:32:07 -0700 (PDT) In-Reply-To: References: <4BFAC569.5050107@berkeley.edu> Date: Mon, 24 May 2010 14:32:07 -0500 X-Google-Sender-Auth: x0gxgkSDRIwqisCGfk5eIqSIM7A Message-ID: Subject: Re: Tombstones Update From: Peter Keane To: Bob Wyman Cc: Erik Wilde , Atom Syntax Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4OJWAxS037027 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A bit farther into that thread: http://www.imc.org/atom-syntax/mail-archive/msg20111.html --peter On Mon, May 24, 2010 at 2:28 PM, Peter Keane wrote: > Hi All- > > For what it is worth, there was a fairly in-depth conversation about > tombstones back in Dec 2007.  James Snell (and others) put forth > strong arguments against it just being another atom:entry (I was among > those, at the time, advocating for atom:entry, but I have come around > to the lighter option mainly for practical (not aesthetic) reasons). > > The thread begins here, and may be worth perusing (follow links to follow-ups): > > http://www.imc.org/atom-syntax/mail-archive/msg20050.html > > --Peter > > > On Mon, May 24, 2010 at 2:08 PM, Bob Wyman wrote: >> Erik, >> I don't think we would have to go as far as changing the semantics of any >> standard atom elements. Rather, what I'm suggesting is that "delete" is >> really just a bit of an extension to what the existing replace means. In >> other words, if you understand the "delete" flag, however, it is encoded, >> you would do a delete, if not, then you would simply do a replace as per the >> existing spec. This would be properly backwards-compatible. >> I would, of course, regret breaking any early-adopter code. However, I >> suggest that there is a much larger population of long-ago-adopters who >> wrote Atom code potentially years ago and would, if deleted-entry became >> accepted, have to consider rewriting or at least modifying their code. One >> of the risks of being an early adopter is that things may change, however, >> people who wrote code to the published spec should be granted the right to >> expect that things will be more stable. >> The only downside I can see in extending the existing entry is that the >> resulting tombstones would be a bit less bit-efficient than desirable. (i.e. >> they would, in most cases, probably end up having empty required elements -- >> such as atom:title.) >> bob wyman >> On Mon, May 24, 2010 at 2:28 PM, Erik Wilde wrote: >>> >>> hello. >>> >>> Bob Wyman wrote: >>>> >>>> The Tombstone draft is coming along nicely, however, I can't help >>>> wondering... Since it appears that a deleted-entry is so much like a normal >>>> entry, why isn't it just an extended atom:entry with some additional element >>>> or attribute flagging it as deleted? >>> >>> i think this is a great approach of looking at what "deletion" means, in a >>> way it's just another "update". however, there probably are two major >>> problems with this approach: >>> >>> - it is not backwards-compatible with prior versions of the draft, and it >>> seems that the draft already has seen some adoption. if the goal is to not >>> break these early implementations, then moving from deleted-entry to entry >>> is not an option, i am afraid. >>> >>> - atom disallows extensions to change the semantics of any standard atom >>> elements. whether additional metadata changing the semantics of an "updated" >>> entry to a "deleted" entry is such a change in semantics is a question of >>> perspective. one could say that "deleted" is different from "updated", or >>> one could say that it's just a special case. >>> http://tools.ietf.org/html/rfc4287#section-4.2.15 just says that 'The >>> "atom:updated" element is a Date construct indicating the most recent >>> instant in time when an entry or feed was modified in a way the publisher >>> considers significant', which i think could be seen as covering the case of >>> deletion of an entry as well. >>> >>> personally, i think that having an entry/@deleted would be quite a bit >>> more elegant and consistent than having a deleted-entry (there is no >>> updated-entry, after all...), but that still does not solve the problem of >>> breaking early adopters' code. but for me, the most important thing is to >>> have something in feeds that covers the CRUD's D, so i am very glad to see >>> the tombstone draft moving along again, whatever it will end up defining. >>> >>> 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 May 24 13:00:23 2010 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 1854F3A6C88 for ; Mon, 24 May 2010 13:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.23 X-Spam-Level: * X-Spam-Status: No, score=1.23 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, 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 UUEgYKTpK5mg for ; Mon, 24 May 2010 13:00:21 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 94A673A6FA4 for ; Mon, 24 May 2010 13:00:21 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OJtBHH038310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 12:55:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4OJtBoS038309; Mon, 24 May 2010 12:55:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OJtA8P038304 for ; Mon, 24 May 2010 12:55:11 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk11 with SMTP id 11so6317043qyk.13 for ; Mon, 24 May 2010 12:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=34gy8FznIj4bOheB0TG//PESil868SS/C29ASDPjOZc=; b=I5XFRvWgae/kK11+FPC1lJXuc64HMA9CHmfhSzXK8STRxvKNrveJZlJZwJOEIxwpL8 kGolFiiF7h/vZy3oEN4NUGVN8CjgqmsRCNow4abGvYX84phzcID1+7Jab8z/tCfsPR2S YcLbcG1pRNreckpHJXQyzSisSXhqI82nLGKT8= 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=U06gav4droWptkHNjlSPlFGQ1yjaSoYm3BZXXzz59PyQB5P45oS0eAfH4dU0VA1ac+ XlFtLB1+MqW0Uy4YevKywdBQD+6rCEFBzhKtb3qqMuTDeK4xSTy4e9X5GZW7nFcA7OM6 iEo6i5v9XYoEha2dDrnJh0w8uOV5zKXXnXuJc= MIME-Version: 1.0 Received: by 10.224.86.231 with SMTP id t39mr3336073qal.297.1274730907574; Mon, 24 May 2010 12:55:07 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Mon, 24 May 2010 12:55:07 -0700 (PDT) In-Reply-To: References: <4BFAC569.5050107@berkeley.edu> Date: Mon, 24 May 2010 12:55:07 -0700 Message-ID: Subject: Re: Tombstones Update From: James Snell To: Peter Keane Cc: Bob Wyman , Erik Wilde , Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4OJtB8P038305 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The fundamental argument for at:deleted-entry is that Atom processors that do not understand Tombstones would see anything along the lines of ... or whatever as any other entry. Further, many systems that currently do not support the notion of a soft-delete typically do not keep around enough metadata about the deleted entry to meet the minimum content requirements of an atom:entry. The title, the content, etc would likely either have to be blanked out or set to something like "DELETED", etc. The challenge with this is that any given feed could contain any number of tombstones and entries mixed together... users of non-tombstone aware clients could potentially see a bunch of useless "DELETED" entries that serve no purpose whatsoever. With the at:deleted-entry approach, unaware clients will have a better user experience and aware clients can still do the right thing. With the entry/@deleted approach, unaware clients get suboptimal results. With either approach, processors that want to be aware of tombstones have to do the same amount of work to implement support. On Mon, May 24, 2010 at 12:32 PM, Peter Keane wrote: > > A bit farther into that thread: > > http://www.imc.org/atom-syntax/mail-archive/msg20111.html > > --peter > > On Mon, May 24, 2010 at 2:28 PM, Peter Keane wrote: >> Hi All- >> >> For what it is worth, there was a fairly in-depth conversation about >> tombstones back in Dec 2007.  James Snell (and others) put forth >> strong arguments against it just being another atom:entry (I was among >> those, at the time, advocating for atom:entry, but I have come around >> to the lighter option mainly for practical (not aesthetic) reasons). >> >> The thread begins here, and may be worth perusing (follow links to follow-ups): >> >> http://www.imc.org/atom-syntax/mail-archive/msg20050.html >> >> --Peter >> >> >> On Mon, May 24, 2010 at 2:08 PM, Bob Wyman wrote: >>> Erik, >>> I don't think we would have to go as far as changing the semantics of any >>> standard atom elements. Rather, what I'm suggesting is that "delete" is >>> really just a bit of an extension to what the existing replace means. In >>> other words, if you understand the "delete" flag, however, it is encoded, >>> you would do a delete, if not, then you would simply do a replace as per the >>> existing spec. This would be properly backwards-compatible. >>> I would, of course, regret breaking any early-adopter code. However, I >>> suggest that there is a much larger population of long-ago-adopters who >>> wrote Atom code potentially years ago and would, if deleted-entry became >>> accepted, have to consider rewriting or at least modifying their code. One >>> of the risks of being an early adopter is that things may change, however, >>> people who wrote code to the published spec should be granted the right to >>> expect that things will be more stable. >>> The only downside I can see in extending the existing entry is that the >>> resulting tombstones would be a bit less bit-efficient than desirable. (i.e. >>> they would, in most cases, probably end up having empty required elements -- >>> such as atom:title.) >>> bob wyman >>> On Mon, May 24, 2010 at 2:28 PM, Erik Wilde wrote: >>>> >>>> hello. >>>> >>>> Bob Wyman wrote: >>>>> >>>>> The Tombstone draft is coming along nicely, however, I can't help >>>>> wondering... Since it appears that a deleted-entry is so much like a normal >>>>> entry, why isn't it just an extended atom:entry with some additional element >>>>> or attribute flagging it as deleted? >>>> >>>> i think this is a great approach of looking at what "deletion" means, in a >>>> way it's just another "update". however, there probably are two major >>>> problems with this approach: >>>> >>>> - it is not backwards-compatible with prior versions of the draft, and it >>>> seems that the draft already has seen some adoption. if the goal is to not >>>> break these early implementations, then moving from deleted-entry to entry >>>> is not an option, i am afraid. >>>> >>>> - atom disallows extensions to change the semantics of any standard atom >>>> elements. whether additional metadata changing the semantics of an "updated" >>>> entry to a "deleted" entry is such a change in semantics is a question of >>>> perspective. one could say that "deleted" is different from "updated", or >>>> one could say that it's just a special case. >>>> http://tools.ietf.org/html/rfc4287#section-4.2.15 just says that 'The >>>> "atom:updated" element is a Date construct indicating the most recent >>>> instant in time when an entry or feed was modified in a way the publisher >>>> considers significant', which i think could be seen as covering the case of >>>> deletion of an entry as well. >>>> >>>> personally, i think that having an entry/@deleted would be quite a bit >>>> more elegant and consistent than having a deleted-entry (there is no >>>> updated-entry, after all...), but that still does not solve the problem of >>>> breaking early adopters' code. but for me, the most important thing is to >>>> have something in feeds that covers the CRUD's D, so i am very glad to see >>>> the tombstone draft moving along again, whatever it will end up defining. >>>> >>>> cheers, >>>> >>>> erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814 >>>>       dret@berkeley.edu  -  http://dret.net/netdret >>>>       UC Berkeley - School of Information (ISchool) >>>> >>> >>> >> > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Mon May 24 13:21:42 2010 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 972FA3A6841 for ; Mon, 24 May 2010 13:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.779 X-Spam-Level: * X-Spam-Status: No, score=1.779 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 hSdB+pZIR2xP for ; Mon, 24 May 2010 13:21:40 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 64D5D3A67CC for ; Mon, 24 May 2010 13:21:40 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OKGOGV039492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 13:16:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4OKGOZN039491; Mon, 24 May 2010 13:16:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-gw0-f43.google.com (mail-gw0-f43.google.com [74.125.83.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OKGLLV039486 for ; Mon, 24 May 2010 13:16:23 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by gwb1 with SMTP id 1so1674741gwb.16 for ; Mon, 24 May 2010 13:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=LAo3qW2vYJ+CtJez8STkgT0EK+hTQRlZ0H36QjPlCE0=; b=oYfYB5iWMQo5ugYrrUCsE2fayrCFLGfKRvjH0YcyhYRSDMtEZ5+m3N6DnD6ELIjjT/ 7U8K5zJSqU2oTr+fbhWbcgfNfU6TOPasbXE9yluWMThA4rJzEtZ4a8elZmemh4Q3xS7C xhnhk8svjjCFSFZOF3uiQ/EZaTtvKjoPwETwY= 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=xQ0lYzq7aViAQHbWXJzRCzufnSgGZXebjpzqWO2/2XvycQPWi7BzvsLMfuQ4/pbzqt dvywwp2w2m7UC1vYB5cDkoGXqXcqjZYlOYGVvNWYYhm0JJt+OaYgc//fMEuD+BF3h2jK pMY0RFRbxkyTzCFzJTVMYnIdVXB8gOjU4N+UU= MIME-Version: 1.0 Received: by 10.101.178.34 with SMTP id f34mr7194174anp.176.1274732180587; Mon, 24 May 2010 13:16:20 -0700 (PDT) Received: by 10.100.154.20 with HTTP; Mon, 24 May 2010 13:16:20 -0700 (PDT) In-Reply-To: References: <4BFAC569.5050107@berkeley.edu> Date: Mon, 24 May 2010 16:16:20 -0400 X-Google-Sender-Auth: e2puJf8dxj9AMIeKxbJz4d30cR8 Message-ID: Subject: Re: Tombstones Update From: Bob Wyman To: James Snell Cc: Peter Keane , Erik Wilde , Atom Syntax Content-Type: multipart/alternative; boundary=001636c92b0dcec9f004875cb677 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636c92b0dcec9f004875cb677 Content-Type: text/plain; charset=ISO-8859-1 It might be good to include the reason for *not* reusing atom:entry in non-normative text. I imagine that many folk will ask this question. I realize that achieving perfection is sometimes not possible... Nonetheless, I'd like to point out again that if deleted-entry doesn't support all the fields that entry does, then it becomes impossible to support a variety of applications that rely on content-based rather than topic-based routing. bob wyman On Mon, May 24, 2010 at 3:55 PM, James Snell wrote: > The fundamental argument for at:deleted-entry is that Atom processors > that do not understand Tombstones would see anything along the lines > of ... or whatever as any other > entry. Further, many systems that currently do not support the notion > of a soft-delete typically do not keep around enough metadata about > the deleted entry to meet the minimum content requirements of an > atom:entry. The title, the content, etc would likely either have to be > blanked out or set to something like "DELETED", etc. The challenge > with this is that any given feed could contain any number of > tombstones and entries mixed together... users of non-tombstone aware > clients could potentially see a bunch of useless "DELETED" entries > that serve no purpose whatsoever. With the at:deleted-entry approach, > unaware clients will have a better user experience and aware clients > can still do the right thing. With the entry/@deleted approach, > unaware clients get suboptimal results. With either approach, > processors that want to be aware of tombstones have to do the same > amount of work to implement support. > > On Mon, May 24, 2010 at 12:32 PM, Peter Keane > wrote: > > > > A bit farther into that thread: > > > > http://www.imc.org/atom-syntax/mail-archive/msg20111.html > > > > --peter > > > > On Mon, May 24, 2010 at 2:28 PM, Peter Keane > wrote: > >> Hi All- > >> > >> For what it is worth, there was a fairly in-depth conversation about > >> tombstones back in Dec 2007. James Snell (and others) put forth > >> strong arguments against it just being another atom:entry (I was among > >> those, at the time, advocating for atom:entry, but I have come around > >> to the lighter option mainly for practical (not aesthetic) reasons). > >> > >> The thread begins here, and may be worth perusing (follow links to > follow-ups): > >> > >> http://www.imc.org/atom-syntax/mail-archive/msg20050.html > >> > >> --Peter > >> > >> > >> On Mon, May 24, 2010 at 2:08 PM, Bob Wyman wrote: > >>> Erik, > >>> I don't think we would have to go as far as changing the semantics of > any > >>> standard atom elements. Rather, what I'm suggesting is that "delete" is > >>> really just a bit of an extension to what the existing replace means. > In > >>> other words, if you understand the "delete" flag, however, it is > encoded, > >>> you would do a delete, if not, then you would simply do a replace as > per the > >>> existing spec. This would be properly backwards-compatible. > >>> I would, of course, regret breaking any early-adopter code. However, I > >>> suggest that there is a much larger population of long-ago-adopters who > >>> wrote Atom code potentially years ago and would, if deleted-entry > became > >>> accepted, have to consider rewriting or at least modifying their code. > One > >>> of the risks of being an early adopter is that things may change, > however, > >>> people who wrote code to the published spec should be granted the right > to > >>> expect that things will be more stable. > >>> The only downside I can see in extending the existing entry is that the > >>> resulting tombstones would be a bit less bit-efficient than desirable. > (i.e. > >>> they would, in most cases, probably end up having empty required > elements -- > >>> such as atom:title.) > >>> bob wyman > >>> On Mon, May 24, 2010 at 2:28 PM, Erik Wilde wrote: > >>>> > >>>> hello. > >>>> > >>>> Bob Wyman wrote: > >>>>> > >>>>> The Tombstone draft is coming along nicely, however, I can't help > >>>>> wondering... Since it appears that a deleted-entry is so much like a > normal > >>>>> entry, why isn't it just an extended atom:entry with some additional > element > >>>>> or attribute flagging it as deleted? > >>>> > >>>> i think this is a great approach of looking at what "deletion" means, > in a > >>>> way it's just another "update". however, there probably are two major > >>>> problems with this approach: > >>>> > >>>> - it is not backwards-compatible with prior versions of the draft, and > it > >>>> seems that the draft already has seen some adoption. if the goal is to > not > >>>> break these early implementations, then moving from deleted-entry to > entry > >>>> is not an option, i am afraid. > >>>> > >>>> - atom disallows extensions to change the semantics of any standard > atom > >>>> elements. whether additional metadata changing the semantics of an > "updated" > >>>> entry to a "deleted" entry is such a change in semantics is a question > of > >>>> perspective. one could say that "deleted" is different from "updated", > or > >>>> one could say that it's just a special case. > >>>> http://tools.ietf.org/html/rfc4287#section-4.2.15 just says that 'The > >>>> "atom:updated" element is a Date construct indicating the most recent > >>>> instant in time when an entry or feed was modified in a way the > publisher > >>>> considers significant', which i think could be seen as covering the > case of > >>>> deletion of an entry as well. > >>>> > >>>> personally, i think that having an entry/@deleted would be quite a bit > >>>> more elegant and consistent than having a deleted-entry (there is no > >>>> updated-entry, after all...), but that still does not solve the > problem of > >>>> breaking early adopters' code. but for me, the most important thing is > to > >>>> have something in feeds that covers the CRUD's D, so i am very glad to > see > >>>> the tombstone draft moving along again, whatever it will end up > defining. > >>>> > >>>> cheers, > >>>> > >>>> erik wilde tel:+1-510-6432253 - fax:+1-510-6425814 > >>>> dret@berkeley.edu - http://dret.net/netdret > >>>> UC Berkeley - School of Information (ISchool) > >>>> > >>> > >>> > >> > > > > > > > > -- > - James Snell > http://www.snellspace.com > jasnell@gmail.com > --001636c92b0dcec9f004875cb677 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It might be good to include the reason for *not* reusing atom:entry in non-= normative text. I imagine that many folk will ask this question.

I realize that achieving perfection is sometimes not possible... N= onetheless, I'd like to point out again that if deleted-entry doesn'= ;t support all the fields that entry does, then it becomes impossible to su= pport a variety of applications that rely on content-based rather than topi= c-based routing.

bob wyman

On Mon, May= 24, 2010 at 3:55 PM, James Snell <jasnell@gmail.com> wrote:
The fundamental argument for at:deleted-entry is that Atom processors
that do not understand Tombstones would see anything along the lines
of <entry at:deleted=3D"true">...</entry> or whatever= as any other
entry. Further, many systems that currently do not support the notion
of a soft-delete typically do not keep around enough metadata about
the deleted entry to meet the minimum content requirements of an
atom:entry. The title, the content, etc would likely either have to be
blanked out or set to something like "DELETED", etc. The challeng= e
with this is that any given feed could contain any number of
tombstones and entries mixed together... users of non-tombstone aware
clients could potentially see a bunch of useless "DELETED" entrie= s
that serve no purpose whatsoever. =A0With the at:deleted-entry approach, unaware clients will have a better user experience and aware clients
can still do the right thing. With the entry/@deleted approach,
unaware clients get suboptimal results. With either approach,
processors that want to be aware of tombstones have to do the same
amount of work to implement support.

On Mon, May 24, 2010 at 12:32 PM, Peter Keane <pkeane@mail.utexas.edu> wrote:
>
> A bit farther into that thread:
>
> http://www.imc.org/atom-syntax/mail-archive/msg20111.html=
>
> --peter
>
> On Mon, May 24, 2010 at 2:28 PM, Peter Keane <pkeane@mail.utexas.edu> wrote:
>> Hi All-
>>
>> For what it is worth, there was a fairly in-depth conversation abo= ut
>> tombstones back in Dec 2007. =A0James Snell (and others) put forth=
>> strong arguments against it just being another atom:entry (I was a= mong
>> those, at the time, advocating for atom:entry, but I have come aro= und
>> to the lighter option mainly for practical (not aesthetic) reasons= ).
>>
>> The thread begins here, and may be worth perusing (follow links to= follow-ups):
>>
>> http://www.imc.org/atom-syntax/mail-archive/msg20050.= html
>>
>> --Peter
>>
>>
>> On Mon, May 24, 2010 at 2:08 PM, Bob Wyman <bob@wyman.us> wrote:
>>> Erik,
>>> I don't think we would have to go as far as changing the s= emantics of any
>>> standard atom elements. Rather, what I'm suggesting is tha= t "delete" is
>>> really just a bit of an extension to what the existing replace= means. In
>>> other words, if you understand the "delete" flag, ho= wever, it is encoded,
>>> you would do a delete, if not, then you would simply do a repl= ace as per the
>>> existing spec. This would be properly backwards-compatible. >>> I would, of course, regret breaking any early-adopter code. Ho= wever, I
>>> suggest that there is a much larger population of long-ago-ado= pters who
>>> wrote Atom code potentially years ago and would, if deleted-en= try became
>>> accepted, have to consider rewriting or at least modifying the= ir code. One
>>> of the risks of being an early adopter is that things may chan= ge, however,
>>> people who wrote code to the published spec should be granted = the right to
>>> expect that things will be more stable.
>>> The only downside I can see in extending the existing entry is= that the
>>> resulting tombstones would be a bit less bit-efficient than de= sirable. (i.e.
>>> they would, in most cases, probably end up having empty requir= ed elements --
>>> such as atom:title.)
>>> bob wyman
>>> On Mon, May 24, 2010 at 2:28 PM, Erik Wilde <dret@berkeley.edu> wrote:
>>>>
>>>> hello.
>>>>
>>>> Bob Wyman wrote:
>>>>>
>>>>> The Tombstone draft is coming along nicely, however, I= can't help
>>>>> wondering... Since it appears that a deleted-entry is = so much like a normal
>>>>> entry, why isn't it just an extended atom:entry wi= th some additional element
>>>>> or attribute flagging it as deleted?
>>>>
>>>> i think this is a great approach of looking at what "= deletion" means, in a
>>>> way it's just another "update". however, the= re probably are two major
>>>> problems with this approach:
>>>>
>>>> - it is not backwards-compatible with prior versions of th= e draft, and it
>>>> seems that the draft already has seen some adoption. if th= e goal is to not
>>>> break these early implementations, then moving from delete= d-entry to entry
>>>> is not an option, i am afraid.
>>>>
>>>> - atom disallows extensions to change the semantics of any= standard atom
>>>> elements. whether additional metadata changing the semanti= cs of an "updated"
>>>> entry to a "deleted" entry is such a change in s= emantics is a question of
>>>> perspective. one could say that "deleted" is dif= ferent from "updated", or
>>>> one could say that it's just a special case.
>>>> http://tools.ietf.org/html/rfc4287#section-4.2.15= just says that 'The
>>>> "atom:updated" element is a Date construct indic= ating the most recent
>>>> instant in time when an entry or feed was modified in a wa= y the publisher
>>>> considers significant', which i think could be seen as= covering the case of
>>>> deletion of an entry as well.
>>>>
>>>> personally, i think that having an entry/@deleted would be= quite a bit
>>>> more elegant and consistent than having a deleted-entry (t= here is no
>>>> updated-entry, after all...), but that still does not solv= e the problem of
>>>> breaking early adopters' code. but for me, the most im= portant thing is to
>>>> have something in feeds that covers the CRUD's D, so i= am very glad to see
>>>> the tombstone draft moving along again, whatever it will e= nd up defining.
>>>>
>>>> cheers,
>>>>
>>>> erik wilde =A0 tel:+1-510-6432253 - fax:+1-510-6425814
>>>> =A0 =A0 =A0 dret@berk= eley.edu =A0- =A0= http://dret.net/netdret
>>>> =A0 =A0 =A0 UC Berkeley - School of Information (ISchool)<= br> >>>>
>>>
>>>
>>
>
>



--

--001636c92b0dcec9f004875cb677-- From owner-atom-syntax@mail.imc.org Mon May 24 13:41:36 2010 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 1557D3A6F1F for ; Mon, 24 May 2010 13:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.226 X-Spam-Level: * X-Spam-Status: No, score=1.226 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, 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 JCguqCmpbd+2 for ; Mon, 24 May 2010 13:41:34 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 21C4F3A67EC for ; Mon, 24 May 2010 13:41:34 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OKahNO040346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 13:36:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4OKahmo040345; Mon, 24 May 2010 13:36:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OKagnS040340 for ; Mon, 24 May 2010 13:36:43 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk11 with SMTP id 11so6376624qyk.13 for ; Mon, 24 May 2010 13:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6E1cl3pgoOqIpDhFuODPgJltiKQd6+v6IbTZ4AHoI+4=; b=I4/ZRWc7FcBaiy5paK4Cc2k98cJbHIRaOECIbvB/rlikb6iAzpCYSvw4/QokrxVlHM i/FgAtNW3GViF2dcvUvOyAoHY//4OGl51LzLnSFJJu88P0u/AJ+1aKL9O8Mjrlwo2xrr QR1jO1n5RXnmFPwSbHENBoLZMCH1T+KMEE28w= 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=H7N1IUfeCwrrDDqOjgqHgMunlejZQX4w3+v7EYV4p4eu2HTD6qrV7aD+aLLJBGyDI6 DGM1QBIckmP9fBZquTiV9IS0Nyw3pNaa4Owy0NHmB/GOx8G4ynX5tKcPUcsyujEGKhC6 X6p82wnRduGowKlPwO2ezyxAbFyFbSb0T89hQ= MIME-Version: 1.0 Received: by 10.224.44.158 with SMTP id a30mr3499875qaf.138.1274733402093; Mon, 24 May 2010 13:36:42 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Mon, 24 May 2010 13:36:41 -0700 (PDT) In-Reply-To: References: <4BFAC569.5050107@berkeley.edu> Date: Mon, 24 May 2010 13:36:41 -0700 Message-ID: Subject: Re: Tombstones Update From: James Snell To: Bob Wyman Cc: Peter Keane , Erik Wilde , Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4OKahnS040341 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Well, there is a definite reason why I allow at:deleted-entry to contain extension elements.. one could easily do something like: ... the entry title the entry content ... Because of the extension model, at:deleted-entry can contain all of the atom:entry children, the exact semantics, however, is undefined by the base tombstone spec. A content-based application could define the necessary semantics and things would just work. On Mon, May 24, 2010 at 1:16 PM, Bob Wyman wrote: > It might be good to include the reason for *not* reusing atom:entry in > non-normative text. I imagine that many folk will ask this question. > I realize that achieving perfection is sometimes not possible... > Nonetheless, I'd like to point out again that if deleted-entry doesn't > support all the fields that entry does, then it becomes impossible to > support a variety of applications that rely on content-based rather than > topic-based routing. > bob wyman > > On Mon, May 24, 2010 at 3:55 PM, James Snell wrote: >> >> The fundamental argument for at:deleted-entry is that Atom processors >> that do not understand Tombstones would see anything along the lines >> of ... or whatever as any other >> entry. Further, many systems that currently do not support the notion >> of a soft-delete typically do not keep around enough metadata about >> the deleted entry to meet the minimum content requirements of an >> atom:entry. The title, the content, etc would likely either have to be >> blanked out or set to something like "DELETED", etc. The challenge >> with this is that any given feed could contain any number of >> tombstones and entries mixed together... users of non-tombstone aware >> clients could potentially see a bunch of useless "DELETED" entries >> that serve no purpose whatsoever.  With the at:deleted-entry approach, >> unaware clients will have a better user experience and aware clients >> can still do the right thing. With the entry/@deleted approach, >> unaware clients get suboptimal results. With either approach, >> processors that want to be aware of tombstones have to do the same >> amount of work to implement support. >> >> On Mon, May 24, 2010 at 12:32 PM, Peter Keane >> wrote: >> > >> > A bit farther into that thread: >> > >> > http://www.imc.org/atom-syntax/mail-archive/msg20111.html >> > >> > --peter >> > >> > On Mon, May 24, 2010 at 2:28 PM, Peter Keane >> > wrote: >> >> Hi All- >> >> >> >> For what it is worth, there was a fairly in-depth conversation about >> >> tombstones back in Dec 2007.  James Snell (and others) put forth >> >> strong arguments against it just being another atom:entry (I was among >> >> those, at the time, advocating for atom:entry, but I have come around >> >> to the lighter option mainly for practical (not aesthetic) reasons). >> >> >> >> The thread begins here, and may be worth perusing (follow links to >> >> follow-ups): >> >> >> >> http://www.imc.org/atom-syntax/mail-archive/msg20050.html >> >> >> >> --Peter >> >> >> >> >> >> On Mon, May 24, 2010 at 2:08 PM, Bob Wyman wrote: >> >>> Erik, >> >>> I don't think we would have to go as far as changing the semantics of >> >>> any >> >>> standard atom elements. Rather, what I'm suggesting is that "delete" >> >>> is >> >>> really just a bit of an extension to what the existing replace means. >> >>> In >> >>> other words, if you understand the "delete" flag, however, it is >> >>> encoded, >> >>> you would do a delete, if not, then you would simply do a replace as >> >>> per the >> >>> existing spec. This would be properly backwards-compatible. >> >>> I would, of course, regret breaking any early-adopter code. However, I >> >>> suggest that there is a much larger population of long-ago-adopters >> >>> who >> >>> wrote Atom code potentially years ago and would, if deleted-entry >> >>> became >> >>> accepted, have to consider rewriting or at least modifying their code. >> >>> One >> >>> of the risks of being an early adopter is that things may change, >> >>> however, >> >>> people who wrote code to the published spec should be granted the >> >>> right to >> >>> expect that things will be more stable. >> >>> The only downside I can see in extending the existing entry is that >> >>> the >> >>> resulting tombstones would be a bit less bit-efficient than desirable. >> >>> (i.e. >> >>> they would, in most cases, probably end up having empty required >> >>> elements -- >> >>> such as atom:title.) >> >>> bob wyman >> >>> On Mon, May 24, 2010 at 2:28 PM, Erik Wilde wrote: >> >>>> >> >>>> hello. >> >>>> >> >>>> Bob Wyman wrote: >> >>>>> >> >>>>> The Tombstone draft is coming along nicely, however, I can't help >> >>>>> wondering... Since it appears that a deleted-entry is so much like a >> >>>>> normal >> >>>>> entry, why isn't it just an extended atom:entry with some additional >> >>>>> element >> >>>>> or attribute flagging it as deleted? >> >>>> >> >>>> i think this is a great approach of looking at what "deletion" means, >> >>>> in a >> >>>> way it's just another "update". however, there probably are two major >> >>>> problems with this approach: >> >>>> >> >>>> - it is not backwards-compatible with prior versions of the draft, >> >>>> and it >> >>>> seems that the draft already has seen some adoption. if the goal is >> >>>> to not >> >>>> break these early implementations, then moving from deleted-entry to >> >>>> entry >> >>>> is not an option, i am afraid. >> >>>> >> >>>> - atom disallows extensions to change the semantics of any standard >> >>>> atom >> >>>> elements. whether additional metadata changing the semantics of an >> >>>> "updated" >> >>>> entry to a "deleted" entry is such a change in semantics is a >> >>>> question of >> >>>> perspective. one could say that "deleted" is different from >> >>>> "updated", or >> >>>> one could say that it's just a special case. >> >>>> http://tools.ietf.org/html/rfc4287#section-4.2.15 just says that 'The >> >>>> "atom:updated" element is a Date construct indicating the most recent >> >>>> instant in time when an entry or feed was modified in a way the >> >>>> publisher >> >>>> considers significant', which i think could be seen as covering the >> >>>> case of >> >>>> deletion of an entry as well. >> >>>> >> >>>> personally, i think that having an entry/@deleted would be quite a >> >>>> bit >> >>>> more elegant and consistent than having a deleted-entry (there is no >> >>>> updated-entry, after all...), but that still does not solve the >> >>>> problem of >> >>>> breaking early adopters' code. but for me, the most important thing >> >>>> is to >> >>>> have something in feeds that covers the CRUD's D, so i am very glad >> >>>> to see >> >>>> the tombstone draft moving along again, whatever it will end up >> >>>> defining. >> >>>> >> >>>> cheers, >> >>>> >> >>>> erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814 >> >>>>       dret@berkeley.edu  -  http://dret.net/netdret >> >>>>       UC Berkeley - School of Information (ISchool) >> >>>> >> >>> >> >>> >> >> >> > >> > >> >> >> >> -- >> - James Snell >>  http://www.snellspace.com >>  jasnell@gmail.com > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Mon May 24 15:51:48 2010 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 B9BCD3A688B for ; Mon, 24 May 2010 15:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.623 X-Spam-Level: X-Spam-Status: No, score=-97.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=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 HvC+ikqnUw1G for ; Mon, 24 May 2010 15:51:47 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1F1973A6CF4 for ; Mon, 24 May 2010 15:51:47 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OMhKBN045372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 15:43:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4OMhKTc045371; Mon, 24 May 2010 15:43:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-pw0-f43.google.com (mail-pw0-f43.google.com [209.85.160.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OMhJvI045366 for ; Mon, 24 May 2010 15:43:20 -0700 (MST) (envelope-from john@johnpanzer.com) Received: by pwi1 with SMTP id 1so405502pwi.16 for ; Mon, 24 May 2010 15:43:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.67.26 with SMTP id p26mr3840524wfa.67.1274740999032; Mon, 24 May 2010 15:43:19 -0700 (PDT) Received: by 10.142.49.21 with HTTP; Mon, 24 May 2010 15:43:18 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 May 2010 15:43:18 -0700 X-Google-Sender-Auth: Rjcq_RiP3eFI_GbV3NJGSDp7mDY Message-ID: Subject: Re: Tombstones Update From: John Panzer To: Bob Wyman Cc: James Snell , Atom Syntax Content-Type: multipart/alternative; boundary=001636e0a5ac6d8f6504875ec438 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636e0a5ac6d8f6504875ec438 Content-Type: text/plain; charset=ISO-8859-1 Note that Salmon (http://salmon-protocol.org) also needs standalone (signed) deleted entry documents. Its security model allows for changing of keysm -- e.g., if the original was compromised -- as long as both keys are bound to the same author/uri. On Wed, May 19, 2010 at 8:36 PM, Bob Wyman wrote: > James Snell wrote: > > As for standalone deleted entry documents... > > the key question is > > whether they are compelling. > > An example... "Atom over XMPP" > calls for publishing streams of Atom Entry Documents over XMPP. Because > there was no mechanism defined for deleting in Atom itself, "Atom over XMPP" > ended up defining a "retract" message for that purpose. It would be more > natural to use a tombstone. > > But, the general question is: Atom format permits my application to publish > only Entry Documents. However, if I do that, and if a delete-entry can only > exist as an element of a Feed Document, how do I tell anyone about a > deleted-entry? Would I need to modify my protocol to support Feed Documents > simply as a means to transport deleted-entries? Doesn't seem right. > > bob wyman > > On Wed, May 19, 2010 at 11:17 PM, James Snell wrote: > >> Heh, Bob... you and I seriously need to get into the same room with a >> whiteboard sometime.. lol.. >> >> Ok, first about your previous comment about atom:source... yes, the >> intention is for it to be identical to the use within atom:entry so I >> will tighten that up in the spec... >> >> As for standalone deleted entry documents... I definitely can think of >> a few generally interesting potential use cases... the key question is >> whether they are compelling. >> >> - James >> >> On Wed, May 19, 2010 at 7:58 PM, Bob Wyman wrote: >> > In Atom, both Entry Documents and Feed Documents are "top-level" >> objects. An >> > entry may be contained within a Feed Document, but it need not be. This >> is >> > an important characteristic of Atom and one that distinguishes it from >> > previous, legacy syndication formats. This attribute of Atom makes it >> > particularly well suited for use in applications that rely on combining >> > entries from multiple sources as well as applications that provide >> real-time >> > delivery of data. >> > However, the deleted-entry that you define in the tombstone draft is >> defined >> > as only existing within Feed Documents. This represents a significant >> and >> > unfortunate departure from the base Atom RFC. >> > I would strongly encourage you to ensure that deleted-entry is >> symmetrical >> > with atom:entry and that it is available in all contexts (i.e. both >> within >> > and without a Feed Document) that an Atom entry is. Just as we can have >> > Entry Documents, we should be able to have Deleted-entry Documents. >> > bob wyman >> > On Wed, May 19, 2010 at 2:10 AM, James Snell wrote: >> >> >> >> Another backwards compatible update... explicitly allowing for an >> >> optional atom:source element as a child of at:deleted-entry. >> >> >> >> >> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-08.txt >> >> >> >> - James >> >> >> > >> > >> >> >> >> -- >> - James Snell >> http://www.snellspace.com >> jasnell@gmail.com >> > > --001636e0a5ac6d8f6504875ec438 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Note that Salmon (http://salmon-prot= ocol.org) also needs standalone (signed) deleted entry documents. =A0It= s security model allows for changing of keysm -- e.g., if the original was = compromised -- as long as both keys are bound to the same author/uri.

On Wed, May 19, 2010 at 8:36 PM, Bob Wyman <= span dir=3D"ltr"><bob@wyman.us> wrote:
James Snell=A0<jasnell@gmail.com>=A0wrote:=
>=A0As for standalone deleted entry documen= ts...
>=A0the key question is
> whether they are = compelling.

An example... "Atom ov= er XMPP" calls for publishing streams of Atom Entry Documents over= XMPP. Because there was no mechanism defined for deleting in Atom itself, = "Atom over XMPP" ended up defining a "retract" message = for that purpose. It would be more natural to use a tombstone.=A0

But, the general question is: Atom format permits my ap= plication to publish only Entry Documents. However, if I do that, and if a = delete-entry can only exist as an element of a Feed Document, how do I tell= anyone about a deleted-entry? Would I need to modify my protocol to suppor= t Feed Documents simply as a means to transport deleted-entries? Doesn'= t seem right.

bob wyman

On Wed, May 19= , 2010 at 11:17 PM, James Snell <jasnell@gmail.com> wrote:
Heh, Bob... you and I seriously need to get into the same room with a
whiteboard sometime.. lol..

Ok, first about your previous comment about atom:source... yes, the
intention is for it to be identical to the use within atom:entry so I
will tighten that up in the spec...

As for standalone deleted entry documents... I definitely can think of
a few generally interesting potential use cases... the key question is
whether they are compelling.

- James

On Wed, May 19, 2010 at 7:58 PM, Bob Wyman <bob@wyman.us> wrote:
> In Atom, both Entry Documents and Feed Documents are "top-level&q= uot; objects. An
> entry may be contained within a Feed Document, but it need not be. Thi= s is
> an important characteristic of Atom and one that distinguishes it from=
> previous, legacy syndication formats. This attribute of Atom makes it<= br> > particularly well suited for use in applications that rely on combinin= g
> entries from multiple sources as well as applications that provide rea= l-time
> delivery of data.
> However, the deleted-entry that you define in the tombstone draft is d= efined
> as only existing within Feed Documents. This represents a significant = and
> unfortunate departure from the base Atom RFC.
> I would strongly encourage you to ensure that deleted-entry is symmetr= ical
> with atom:entry and that it is available in all contexts (i.e. both wi= thin
> and without a Feed Document) that an Atom entry is. Just as we can hav= e
> Entry Documents, we should be able to have Deleted-entry Documents. > bob wyman
> On Wed, May 19, 2010 at 2:10 AM, James Snell <jasnell@gmail.com> wrote:
>>
>> Another backwards compatible update... explicitly allowing for an<= br> >> optional atom:source element as a child of at:deleted-entry.
>>
>> http://www.ietf.org/internet-drafts/d= raft-snell-atompub-tombstones-08.txt
>>
>> - James
>>
>
>





--001636e0a5ac6d8f6504875ec438-- From owner-atom-syntax@mail.imc.org Mon May 24 15:55:19 2010 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 22EB23A6D90 for ; Mon, 24 May 2010 15:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.523 X-Spam-Level: * X-Spam-Status: No, score=1.523 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmzFpwKztOJf for ; Mon, 24 May 2010 15:55:18 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E3EDB3A6F68 for ; Mon, 24 May 2010 15:55:17 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OMpESS045662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 15:51:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4OMpE3t045661; Mon, 24 May 2010 15:51:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OMpDE9045656 for ; Mon, 24 May 2010 15:51:14 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk11 with SMTP id 11so6569143qyk.13 for ; Mon, 24 May 2010 15:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=06+63cQggcH0N+IWIDkKJ7rARlm7RNdXvQt3r1n2pmQ=; b=hQmAloEP7lqR45CFwQN557CZiM9ZkkFAv1CND0XimzyL2st9THCN2HMVLBFCkDzTUe zvBaCMwPgbhAvYXMoMLp6UZm0kycBGkV3kJgPhAxpALxl9M9Xs1p+o2ADZ4zuATGTBr7 LXHVvvlgzBFfmvAVs+VhZB3+tLD5HQB9M8Rn0= 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=I31LoNih4QmObXaHqqUfk+xpDKO99UAeBos3ByySpNgXC9KXtvNQx8IpCjkX8mGJFj obeIcOjNR/X3PYQTrnX27EDVM0w7wxSq6RkWg6i7+QEIjpEg8blFiv20bma2DKUVCs7T fTXQ3jjdEKksZC/vPffJJ+rgvbBEwoegc42xA= MIME-Version: 1.0 Received: by 10.229.225.72 with SMTP id ir8mr1286264qcb.73.1274741473271; Mon, 24 May 2010 15:51:13 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Mon, 24 May 2010 15:51:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 May 2010 15:51:13 -0700 Message-ID: Subject: Re: Tombstones Update From: James Snell To: John Panzer Cc: Bob Wyman , Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4OMpEE9045657 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes, I wanted to be careful about dictating any kind of behavior if the keys ended up being different because there are legitimate reasons why they would be (e.g. if an editor deletes an entry created be a different author). Applications just need to be aware of the potential risks involved. Ironically, the greater risk is deletion with a compromised key. On Mon, May 24, 2010 at 3:43 PM, John Panzer wrote: > Note that Salmon (http://salmon-protocol.org) also needs standalone (signed) > deleted entry documents.  Its security model allows for changing of keysm -- > e.g., if the original was compromised -- as long as both keys are bound to > the same author/uri. > > On Wed, May 19, 2010 at 8:36 PM, Bob Wyman wrote: >> >> James Snell  wrote: >> > As for standalone deleted entry documents... >> > the key question is >> > whether they are compelling. >> >> An example... "Atom over XMPP" calls for publishing streams of Atom Entry >> Documents over XMPP. Because there was no mechanism defined for deleting in >> Atom itself, "Atom over XMPP" ended up defining a "retract" message for that >> purpose. It would be more natural to use a tombstone. >> But, the general question is: Atom format permits my application to >> publish only Entry Documents. However, if I do that, and if a delete-entry >> can only exist as an element of a Feed Document, how do I tell anyone about >> a deleted-entry? Would I need to modify my protocol to support Feed >> Documents simply as a means to transport deleted-entries? Doesn't seem >> right. >> bob wyman >> On Wed, May 19, 2010 at 11:17 PM, James Snell wrote: >>> >>> Heh, Bob... you and I seriously need to get into the same room with a >>> whiteboard sometime.. lol.. >>> >>> Ok, first about your previous comment about atom:source... yes, the >>> intention is for it to be identical to the use within atom:entry so I >>> will tighten that up in the spec... >>> >>> As for standalone deleted entry documents... I definitely can think of >>> a few generally interesting potential use cases... the key question is >>> whether they are compelling. >>> >>> - James >>> >>> On Wed, May 19, 2010 at 7:58 PM, Bob Wyman wrote: >>> > In Atom, both Entry Documents and Feed Documents are "top-level" >>> > objects. An >>> > entry may be contained within a Feed Document, but it need not be. This >>> > is >>> > an important characteristic of Atom and one that distinguishes it from >>> > previous, legacy syndication formats. This attribute of Atom makes it >>> > particularly well suited for use in applications that rely on combining >>> > entries from multiple sources as well as applications that provide >>> > real-time >>> > delivery of data. >>> > However, the deleted-entry that you define in the tombstone draft is >>> > defined >>> > as only existing within Feed Documents. This represents a significant >>> > and >>> > unfortunate departure from the base Atom RFC. >>> > I would strongly encourage you to ensure that deleted-entry is >>> > symmetrical >>> > with atom:entry and that it is available in all contexts (i.e. both >>> > within >>> > and without a Feed Document) that an Atom entry is. Just as we can have >>> > Entry Documents, we should be able to have Deleted-entry Documents. >>> > bob wyman >>> > On Wed, May 19, 2010 at 2:10 AM, James Snell wrote: >>> >> >>> >> Another backwards compatible update... explicitly allowing for an >>> >> optional atom:source element as a child of at:deleted-entry. >>> >> >>> >> >>> >> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-08.txt >>> >> >>> >> - James >>> >> >>> > >>> > >>> >>> >>> >>> -- >>> - James Snell >>>  http://www.snellspace.com >>>  jasnell@gmail.com >> > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Mon May 24 16:17:36 2010 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 9D2323A6CCE for ; Mon, 24 May 2010 16:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.533 X-Spam-Level: * X-Spam-Status: No, score=1.533 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jepjqp4FxnNZ for ; Mon, 24 May 2010 16:17:35 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6BCCF3A7041 for ; Mon, 24 May 2010 16:17:06 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4ONChvZ046577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 16:12:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4ONChAl046576; Mon, 24 May 2010 16:12:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4ONCgnx046571 for ; Mon, 24 May 2010 16:12:42 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by qyk11 with SMTP id 11so6599230qyk.13 for ; Mon, 24 May 2010 16:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=U8qBwfVjz4cZoIE6RLBeWWnxwrB25rBSSvhyvGmXdOg=; b=heqoY2Nz7IM3bPXbnx7V3CBV1GpH8rD6RY1Dz2LloZ32vMlpgrFKoWCyapciA6jet4 6oTPdqX4tBj0My1BtIjYcOSFkcecIgCqEhsracovZUcq8BFxydj4QC447gacvRFL5HAE UFdXMOYynj067UrbHoh72QIWxw8JCupvNS/Fs= 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=vKUO3U5fhx/ovmEKErPlofLBB5Q0vCmOc+stH0NDw3yGyqs1/nTDmCTvF02g80nBLH u6/VzlwyvDnbzCknYM8sIK9jrBUmCFekyrpk7TR2mGRynb3M3giXxEp1f02BgMu4PBx7 9cL/tKNZh0/v/xTXbSEJmXt71bpnDmohYMjJw= MIME-Version: 1.0 Received: by 10.229.184.138 with SMTP id ck10mr1285487qcb.130.1274742761629; Mon, 24 May 2010 16:12:41 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Mon, 24 May 2010 16:12:41 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 May 2010 16:12:41 -0700 Message-ID: Subject: Re: Tombstones Update From: James Snell To: John Panzer Cc: Bob Wyman , Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4ONChnx046572 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One additional comment, because of the extension model allowed by the tombstone, it would also be possible for a publisher to include the complete atom:entry as a child of the at:deleted-entry to address the scenarios that Bob has brought up... e.g. ... ... ... - James On Mon, May 24, 2010 at 3:51 PM, James Snell wrote: > Yes, I wanted to be careful about dictating any kind of behavior if > the keys ended up being different because there are legitimate reasons > why they would be (e.g. if an editor deletes an entry created be a > different author). Applications just need to be aware of the potential > risks involved.  Ironically, the greater risk is deletion with a > compromised key. > > On Mon, May 24, 2010 at 3:43 PM, John Panzer wrote: >> Note that Salmon (http://salmon-protocol.org) also needs standalone (signed) >> deleted entry documents.  Its security model allows for changing of keysm -- >> e.g., if the original was compromised -- as long as both keys are bound to >> the same author/uri. >> >> On Wed, May 19, 2010 at 8:36 PM, Bob Wyman wrote: >>> >>> James Snell  wrote: >>> > As for standalone deleted entry documents... >>> > the key question is >>> > whether they are compelling. >>> >>> An example... "Atom over XMPP" calls for publishing streams of Atom Entry >>> Documents over XMPP. Because there was no mechanism defined for deleting in >>> Atom itself, "Atom over XMPP" ended up defining a "retract" message for that >>> purpose. It would be more natural to use a tombstone. >>> But, the general question is: Atom format permits my application to >>> publish only Entry Documents. However, if I do that, and if a delete-entry >>> can only exist as an element of a Feed Document, how do I tell anyone about >>> a deleted-entry? Would I need to modify my protocol to support Feed >>> Documents simply as a means to transport deleted-entries? Doesn't seem >>> right. >>> bob wyman >>> On Wed, May 19, 2010 at 11:17 PM, James Snell wrote: >>>> >>>> Heh, Bob... you and I seriously need to get into the same room with a >>>> whiteboard sometime.. lol.. >>>> >>>> Ok, first about your previous comment about atom:source... yes, the >>>> intention is for it to be identical to the use within atom:entry so I >>>> will tighten that up in the spec... >>>> >>>> As for standalone deleted entry documents... I definitely can think of >>>> a few generally interesting potential use cases... the key question is >>>> whether they are compelling. >>>> >>>> - James >>>> >>>> On Wed, May 19, 2010 at 7:58 PM, Bob Wyman wrote: >>>> > In Atom, both Entry Documents and Feed Documents are "top-level" >>>> > objects. An >>>> > entry may be contained within a Feed Document, but it need not be. This >>>> > is >>>> > an important characteristic of Atom and one that distinguishes it from >>>> > previous, legacy syndication formats. This attribute of Atom makes it >>>> > particularly well suited for use in applications that rely on combining >>>> > entries from multiple sources as well as applications that provide >>>> > real-time >>>> > delivery of data. >>>> > However, the deleted-entry that you define in the tombstone draft is >>>> > defined >>>> > as only existing within Feed Documents. This represents a significant >>>> > and >>>> > unfortunate departure from the base Atom RFC. >>>> > I would strongly encourage you to ensure that deleted-entry is >>>> > symmetrical >>>> > with atom:entry and that it is available in all contexts (i.e. both >>>> > within >>>> > and without a Feed Document) that an Atom entry is. Just as we can have >>>> > Entry Documents, we should be able to have Deleted-entry Documents. >>>> > bob wyman >>>> > On Wed, May 19, 2010 at 2:10 AM, James Snell wrote: >>>> >> >>>> >> Another backwards compatible update... explicitly allowing for an >>>> >> optional atom:source element as a child of at:deleted-entry. >>>> >> >>>> >> >>>> >> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-08.txt >>>> >> >>>> >> - James >>>> >> >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> - James Snell >>>>  http://www.snellspace.com >>>>  jasnell@gmail.com >>> >> >> > > > > -- > - James Snell >  http://www.snellspace.com >  jasnell@gmail.com > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Mon May 24 16:59:03 2010 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 45EBE3A6D10 for ; Mon, 24 May 2010 16:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.377 X-Spam-Level: ** X-Spam-Status: No, score=2.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZBDuugUy8L4 for ; Mon, 24 May 2010 16:59:01 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6B5E83A657C for ; Mon, 24 May 2010 16:59:01 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4ONpsgT048070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 16:51:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4ONps2W048069; Mon, 24 May 2010 16:51:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from eu1sys200aog111.obsmtp.com (eu1sys200aog111.obsmtp.com [207.126.144.131]) by hoffman.proper.com (8.14.4/8.14.3) with SMTP id o4ONpoTt048062 for ; Mon, 24 May 2010 16:51:51 -0700 (MST) (envelope-from samj@samj.net) Received: from source ([209.85.222.180]) by eu1sys200aob111.postini.com ([207.126.147.11]) with SMTP ID DSNKS/sRFVNYlbEBU58FAPrnKcm2t9K9gC6Z@postini.com; Mon, 24 May 2010 23:51:52 UTC Received: by pzk10 with SMTP id 10so2640709pzk.20 for ; Mon, 24 May 2010 16:51:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.6.33 with SMTP id 33mr4255472wff.135.1274745108578; Mon, 24 May 2010 16:51:48 -0700 (PDT) Received: by 10.114.103.9 with HTTP; Mon, 24 May 2010 16:51:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 May 2010 01:51:48 +0200 Message-ID: Subject: Re: Tombstones Update From: Sam Johnston To: James Snell Cc: John Panzer , Bob Wyman , Atom Syntax Content-Type: multipart/alternative; boundary=00504502b17260413e04875fb9eb Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --00504502b17260413e04875fb9eb Content-Type: text/plain; charset=ISO-8859-1 James et al, I have to admit that this all sounds rather complicated. I'm already having stiff resistance to adoption of Atom in other standards because of [unfounded] perceived complexity and would rather not give the critics justification. >From what I understand of the requirements I tend to agree with Bob in that atom:entry should contain a "deleted" attribute or entry, possibly specifying the deletion time. As tombstones are almost always the exception rather than the rule I don't see "deleted" placeholder text being a huge problem and it allows publishers some flexibility in leaving some/all of the content in place in an interoperable fashion (e.g. avoiding the need to extend deleted-entry with atom:entry or its children). In any case I'm not the first to suggestthat you can always exclude the tombstones by default and enabling them with a query parameter. I do think this draft runs the risk of being widely implemented, and in its current form will add non-negligible complexity to most client and server code bases; in contrast ignoring entries with a "deleted" attribute/element is a trivial change. If it's well justified and there's a strong consensus then fine, but implementors of draft specifications know what they're getting themselves into so I don't see this as a strong case to keep the status quo. Sam Google On Tue, May 25, 2010 at 1:12 AM, James Snell wrote: > > One additional comment, because of the extension model allowed by the > tombstone, it would also be possible for a publisher to include the > complete atom:entry as a child of the at:deleted-entry to address the > scenarios that Bob has brought up... e.g. > > > ... > > ... > > ... > > > - James > > On Mon, May 24, 2010 at 3:51 PM, James Snell wrote: > > Yes, I wanted to be careful about dictating any kind of behavior if > > the keys ended up being different because there are legitimate reasons > > why they would be (e.g. if an editor deletes an entry created be a > > different author). Applications just need to be aware of the potential > > risks involved. Ironically, the greater risk is deletion with a > > compromised key. > > > > On Mon, May 24, 2010 at 3:43 PM, John Panzer wrote: > >> Note that Salmon (http://salmon-protocol.org) also needs standalone > (signed) > >> deleted entry documents. Its security model allows for changing of > keysm -- > >> e.g., if the original was compromised -- as long as both keys are bound > to > >> the same author/uri. > >> > >> On Wed, May 19, 2010 at 8:36 PM, Bob Wyman wrote: > >>> > >>> James Snell wrote: > >>> > As for standalone deleted entry documents... > >>> > the key question is > >>> > whether they are compelling. > >>> > >>> An example... "Atom over XMPP" calls for publishing streams of Atom > Entry > >>> Documents over XMPP. Because there was no mechanism defined for > deleting in > >>> Atom itself, "Atom over XMPP" ended up defining a "retract" message for > that > >>> purpose. It would be more natural to use a tombstone. > >>> But, the general question is: Atom format permits my application to > >>> publish only Entry Documents. However, if I do that, and if a > delete-entry > >>> can only exist as an element of a Feed Document, how do I tell anyone > about > >>> a deleted-entry? Would I need to modify my protocol to support Feed > >>> Documents simply as a means to transport deleted-entries? Doesn't seem > >>> right. > >>> bob wyman > >>> On Wed, May 19, 2010 at 11:17 PM, James Snell > wrote: > >>>> > >>>> Heh, Bob... you and I seriously need to get into the same room with a > >>>> whiteboard sometime.. lol.. > >>>> > >>>> Ok, first about your previous comment about atom:source... yes, the > >>>> intention is for it to be identical to the use within atom:entry so I > >>>> will tighten that up in the spec... > >>>> > >>>> As for standalone deleted entry documents... I definitely can think of > >>>> a few generally interesting potential use cases... the key question is > >>>> whether they are compelling. > >>>> > >>>> - James > >>>> > >>>> On Wed, May 19, 2010 at 7:58 PM, Bob Wyman wrote: > >>>> > In Atom, both Entry Documents and Feed Documents are "top-level" > >>>> > objects. An > >>>> > entry may be contained within a Feed Document, but it need not be. > This > >>>> > is > >>>> > an important characteristic of Atom and one that distinguishes it > from > >>>> > previous, legacy syndication formats. This attribute of Atom makes > it > >>>> > particularly well suited for use in applications that rely on > combining > >>>> > entries from multiple sources as well as applications that provide > >>>> > real-time > >>>> > delivery of data. > >>>> > However, the deleted-entry that you define in the tombstone draft is > >>>> > defined > >>>> > as only existing within Feed Documents. This represents a > significant > >>>> > and > >>>> > unfortunate departure from the base Atom RFC. > >>>> > I would strongly encourage you to ensure that deleted-entry is > >>>> > symmetrical > >>>> > with atom:entry and that it is available in all contexts (i.e. both > >>>> > within > >>>> > and without a Feed Document) that an Atom entry is. Just as we can > have > >>>> > Entry Documents, we should be able to have Deleted-entry Documents. > >>>> > bob wyman > >>>> > On Wed, May 19, 2010 at 2:10 AM, James Snell > wrote: > >>>> >> > >>>> >> Another backwards compatible update... explicitly allowing for an > >>>> >> optional atom:source element as a child of at:deleted-entry. > >>>> >> > >>>> >> > >>>> >> > http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-08.txt > >>>> >> > >>>> >> - James > >>>> >> > >>>> > > >>>> > > >>>> > >>>> > >>>> > >>>> -- > >>>> - James Snell > >>>> http://www.snellspace.com > >>>> jasnell@gmail.com > >>> > >> > >> > > > > > > > > -- > > - James Snell > > http://www.snellspace.com > > jasnell@gmail.com > > > > > > -- > - James Snell > http://www.snellspace.com > jasnell@gmail.com > > --00504502b17260413e04875fb9eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable James et al,

I have to admit that this all sounds rather= complicated. I'm already having stiff resistance to adoption of Atom i= n other standards because of [unfounded] perceived complexity and would rat= her not give the critics justification.

From what I understand of the requirements I tend to ag= ree with Bob in that atom:entry should contain a "deleted" attrib= ute or entry, possibly specifying the deletion time. As tombstones are almo= st always the exception rather than the rule I don't see "deleted&= quot; placeholder text being a huge problem and it allows publishers some f= lexibility in leaving some/all of the content in place in an interoperable = fashion (e.g. avoiding the need to extend deleted-entry with atom:entry or = its children). In any case I'm not the first to suggest that you can alw= ays exclude the tombstones by default and enabling them with a query parame= ter.

I do think this draft runs the risk of being widely imp= lemented, and in its current form will add non-negligible complexity to mos= t client and server code bases; in contrast ignoring entries with a "d= eleted" attribute/element is a trivial change. If it's well justif= ied and there's a strong consensus then fine, but implementors of draft= specifications know what they're getting themselves into so I don'= t see this as a strong case to keep the status quo.

Sam
Google

= On Tue, May 25, 2010 at 1:12 AM, James Snell <jasnell@gmail.com> wrote:

One additional comment, because of the extension model allowed by the
tombstone, it would also be possible for a publisher to include the
complete atom:entry as a child of the at:deleted-entry to address the
scenarios that Bob has brought up... e.g.

<at:deleted-entry>
=A0...
=A0<atom:entry>
=A0 =A0...
=A0</atom:entry>
=A0...
</at:deleted-entry>

- James

On Mon, May 24, 2010 at 3:51 PM, James Snell <jasnell@gmail.com> wrote:
> Yes, I wanted to be careful about dictating any kind of behavior if > the keys ended up being different because there are legitimate reasons=
> why they would be (e.g. if an editor deletes an entry created be a
> different author). Applications just need to be aware of the potential=
> risks involved. =A0Ironically, the greater risk is deletion with a
> compromised key.
>
> On Mon, May 24, 2010 at 3:43 PM, John Panzer <jpanzer@acm.org> wrote:
>> Note that Salmon (http://salmon-protocol.org) also needs standalone (signed)
>> deleted entry documents. =A0Its security model allows for changing= of keysm --
>> e.g., if the original was compromised -- as long as both keys are = bound to
>> the same author/uri.
>>
>> On Wed, May 19, 2010 at 8:36 PM, Bob Wyman <bob@wyman.us> wrote:
>>>
>>> James Snell=A0<jasnell= @gmail.com>=A0wrote:
>>> >=A0As for standalone deleted entry documents...
>>> >=A0the key question is
>>> > whether they are compelling.
>>>
>>> An example... "Atom over XMPP" calls for publishing = streams of Atom Entry
>>> Documents over XMPP. Because there was no mechanism defined fo= r deleting in
>>> Atom itself, "Atom over XMPP" ended up defining a &q= uot;retract" message for that
>>> purpose. It would be more natural to use a tombstone.
>>> But, the general question is: Atom format permits my applicati= on to
>>> publish only Entry Documents. However, if I do that, and if a = delete-entry
>>> can only exist as an element of a Feed Document, how do I tell= anyone about
>>> a deleted-entry? Would I need to modify my protocol to support= Feed
>>> Documents simply as a means to transport deleted-entries? Does= n't seem
>>> right.
>>> bob wyman
>>> On Wed, May 19, 2010 at 11:17 PM, James Snell <jasnell@gmail.com> wrote:
>>>>
>>>> Heh, Bob... you and I seriously need to get into the same = room with a
>>>> whiteboard sometime.. lol..
>>>>
>>>> Ok, first about your previous comment about atom:source...= yes, the
>>>> intention is for it to be identical to the use within atom= :entry so I
>>>> will tighten that up in the spec...
>>>>
>>>> As for standalone deleted entry documents... I definitely = can think of
>>>> a few generally interesting potential use cases... the key= question is
>>>> whether they are compelling.
>>>>
>>>> - James
>>>>
>>>> On Wed, May 19, 2010 at 7:58 PM, Bob Wyman <bob@wyman.us> wrote:
>>>> > In Atom, both Entry Documents and Feed Documents are = "top-level"
>>>> > objects. An
>>>> > entry may be contained within a Feed Document, but it= need not be. This
>>>> > is
>>>> > an important characteristic of Atom and one that dist= inguishes it from
>>>> > previous, legacy syndication formats. This attribute = of Atom makes it
>>>> > particularly well suited for use in applications that= rely on combining
>>>> > entries from multiple sources as well as applications= that provide
>>>> > real-time
>>>> > delivery of data.
>>>> > However, the deleted-entry that you define in the tom= bstone draft is
>>>> > defined
>>>> > as only existing within Feed Documents. This represen= ts a significant
>>>> > and
>>>> > unfortunate departure from the base Atom RFC.
>>>> > I would strongly encourage you to ensure that deleted= -entry is
>>>> > symmetrical
>>>> > with atom:entry and that it is available in all conte= xts (i.e. both
>>>> > within
>>>> > and without a Feed Document) that an Atom entry is. J= ust as we can have
>>>> > Entry Documents, we should be able to have Deleted-en= try Documents.
>>>> > bob wyman
>>>> > On Wed, May 19, 2010 at 2:10 AM, James Snell <jasnell@gmail.com> wrote:
>>>> >>
>>>> >> Another backwards compatible update... explicitly= allowing for an
>>>> >> optional atom:source element as a child of at:del= eted-entry.
>>>> >>
>>>> >>
>>>> >> http://www.ietf.org/= internet-drafts/draft-snell-atompub-tombstones-08.txt
>>>> >>
>>>> >> - James
>>>> >>
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> - James Snell
>>>> =A0http://www.snellspace.com
>>>> =A0jasnell@gmail.com<= /a>
>>>
>>
>>
>
>
>
> --
> - James Snell
> =A0http://www.= snellspace.com
> =A0jasnell@gmail.com
>



--

--00504502b17260413e04875fb9eb-- From owner-atom-syntax@mail.imc.org Mon May 24 18:00:25 2010 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 B05A63A689D for ; Mon, 24 May 2010 18:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.841 X-Spam-Level: * X-Spam-Status: No, score=1.841 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=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 N2P+9BuL-tul for ; Mon, 24 May 2010 18:00:24 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1C40B3A684C for ; Mon, 24 May 2010 18:00:23 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4P0rmdC050571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 17:53:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4P0rmFe050570; Mon, 24 May 2010 17:53:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4P0rlZF050565 for ; Mon, 24 May 2010 17:53:47 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by vws19 with SMTP id 19so934043vws.16 for ; Mon, 24 May 2010 17:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ee3owDFMf8DHTMokCqHQbWoZzTlUCDzlRs+rqVPEzjE=; b=gDP4Boji8XTVLzbktFD4a+kBLnk69Yz7lG1AJ62OosqvQR3QXrhqv8EMpb5Yr3aqok bNwqndZRPAsCc9HyA0LEbNOGYD0++pIkwJH2f+YUogTNEd+GxiyQTe2eOQaNYEOXhSbD tr0xSzOEDTKk7OFWBncKd9MATLDWs7Asir4P0= 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=mGd6gLI9xEnyIMywUPcNIFcC1F87chF9TSOUGHmA8e60//JeXWJUUnhOGky4Kf5dSH qJt1b8wXf2WrevUfzZSRzteySv8mbsPHauMQTkp9J+z5Em8g6FFWxuq4wDvBOjKGLpwu w4iguLtMgcuKQCBwype6YbVGpnCBUDH9BqUG4= MIME-Version: 1.0 Received: by 10.229.231.132 with SMTP id jq4mr1296927qcb.152.1274748826416; Mon, 24 May 2010 17:53:46 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Mon, 24 May 2010 17:53:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 May 2010 17:53:46 -0700 Message-ID: Subject: Re: Tombstones Update From: James Snell To: Sam Johnston Cc: John Panzer , Bob Wyman , Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4P0rmZF050566 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: For the overwhelming majority of Atom clients, there's nothing easier than ignoring an extension element they don't understand and not having to worry about phantom atom:entry elements that represent deleted content.... it doesn't take any effort at all to ignore an atom:entry that doesn't exist ;-) ... 1. Simple example A xyz ... 2. Simple example B abc xyz Given these two choices, ordinary clients that do not know anything about tombstones will, correctly, only see one entry in Example A... but will see two entries in Example B.. one that doesn't really exist and whose title, author, updated, alternate link and summary/content won't necessarily actually exist or provide any useful information to the client whatsoever. For clients that support tombstones, looking for at:deleted-entry vs atom:entry/@deleted is actually fairly trivial... Using atom:entry/@deleted however still leads to an unnatural mapping of atom:entry for the most common tombstone cases because the values for atom:title, alternate links, atom:summary or atom:content just might not exist. An implementation only needs to worry about extension elements in at:deleted-entry when they have specific use cases that call for them. Not really all that complicated :-D On Mon, May 24, 2010 at 4:51 PM, Sam Johnston wrote: > James et al, > I have to admit that this all sounds rather complicated. I'm already having > stiff resistance to adoption of Atom in other standards because of > [unfounded] perceived complexity and would rather not give the critics > justification. > From what I understand of the requirements I tend to agree with Bob in that > atom:entry should contain a "deleted" attribute or entry, possibly > specifying the deletion time. As tombstones are almost always the exception > rather than the rule I don't see "deleted" placeholder text being a huge > problem and it allows publishers some flexibility in leaving some/all of the > content in place in an interoperable fashion (e.g. avoiding the need to > extend deleted-entry with atom:entry or its children). In any case I'm not > the first to suggest that you can always exclude the tombstones by default > and enabling them with a query parameter. > I do think this draft runs the risk of being widely implemented, and in its > current form will add non-negligible complexity to most client and server > code bases; in contrast ignoring entries with a "deleted" attribute/element > is a trivial change. If it's well justified and there's a strong consensus > then fine, but implementors of draft specifications know what they're > getting themselves into so I don't see this as a strong case to keep the > status quo. > Sam > Google > On Tue, May 25, 2010 at 1:12 AM, James Snell wrote: >> >> One additional comment, because of the extension model allowed by the >> tombstone, it would also be possible for a publisher to include the >> complete atom:entry as a child of the at:deleted-entry to address the >> scenarios that Bob has brought up... e.g. >> >> >>  ... >>   >>    ... >>   >>  ... >> >> >> - James >> >> On Mon, May 24, 2010 at 3:51 PM, James Snell wrote: >> > Yes, I wanted to be careful about dictating any kind of behavior if >> > the keys ended up being different because there are legitimate reasons >> > why they would be (e.g. if an editor deletes an entry created be a >> > different author). Applications just need to be aware of the potential >> > risks involved.  Ironically, the greater risk is deletion with a >> > compromised key. >> > >> > On Mon, May 24, 2010 at 3:43 PM, John Panzer wrote: >> >> Note that Salmon (http://salmon-protocol.org) also needs standalone >> >> (signed) >> >> deleted entry documents.  Its security model allows for changing of >> >> keysm -- >> >> e.g., if the original was compromised -- as long as both keys are bound >> >> to >> >> the same author/uri. >> >> >> >> On Wed, May 19, 2010 at 8:36 PM, Bob Wyman wrote: >> >>> >> >>> James Snell  wrote: >> >>> > As for standalone deleted entry documents... >> >>> > the key question is >> >>> > whether they are compelling. >> >>> >> >>> An example... "Atom over XMPP" calls for publishing streams of Atom >> >>> Entry >> >>> Documents over XMPP. Because there was no mechanism defined for >> >>> deleting in >> >>> Atom itself, "Atom over XMPP" ended up defining a "retract" message >> >>> for that >> >>> purpose. It would be more natural to use a tombstone. >> >>> But, the general question is: Atom format permits my application to >> >>> publish only Entry Documents. However, if I do that, and if a >> >>> delete-entry >> >>> can only exist as an element of a Feed Document, how do I tell anyone >> >>> about >> >>> a deleted-entry? Would I need to modify my protocol to support Feed >> >>> Documents simply as a means to transport deleted-entries? Doesn't seem >> >>> right. >> >>> bob wyman >> >>> On Wed, May 19, 2010 at 11:17 PM, James Snell >> >>> wrote: >> >>>> >> >>>> Heh, Bob... you and I seriously need to get into the same room with a >> >>>> whiteboard sometime.. lol.. >> >>>> >> >>>> Ok, first about your previous comment about atom:source... yes, the >> >>>> intention is for it to be identical to the use within atom:entry so I >> >>>> will tighten that up in the spec... >> >>>> >> >>>> As for standalone deleted entry documents... I definitely can think >> >>>> of >> >>>> a few generally interesting potential use cases... the key question >> >>>> is >> >>>> whether they are compelling. >> >>>> >> >>>> - James >> >>>> >> >>>> On Wed, May 19, 2010 at 7:58 PM, Bob Wyman wrote: >> >>>> > In Atom, both Entry Documents and Feed Documents are "top-level" >> >>>> > objects. An >> >>>> > entry may be contained within a Feed Document, but it need not be. >> >>>> > This >> >>>> > is >> >>>> > an important characteristic of Atom and one that distinguishes it >> >>>> > from >> >>>> > previous, legacy syndication formats. This attribute of Atom makes >> >>>> > it >> >>>> > particularly well suited for use in applications that rely on >> >>>> > combining >> >>>> > entries from multiple sources as well as applications that provide >> >>>> > real-time >> >>>> > delivery of data. >> >>>> > However, the deleted-entry that you define in the tombstone draft >> >>>> > is >> >>>> > defined >> >>>> > as only existing within Feed Documents. This represents a >> >>>> > significant >> >>>> > and >> >>>> > unfortunate departure from the base Atom RFC. >> >>>> > I would strongly encourage you to ensure that deleted-entry is >> >>>> > symmetrical >> >>>> > with atom:entry and that it is available in all contexts (i.e. both >> >>>> > within >> >>>> > and without a Feed Document) that an Atom entry is. Just as we can >> >>>> > have >> >>>> > Entry Documents, we should be able to have Deleted-entry Documents. >> >>>> > bob wyman >> >>>> > On Wed, May 19, 2010 at 2:10 AM, James Snell >> >>>> > wrote: >> >>>> >> >> >>>> >> Another backwards compatible update... explicitly allowing for an >> >>>> >> optional atom:source element as a child of at:deleted-entry. >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-08.txt >> >>>> >> >> >>>> >> - James >> >>>> >> >> >>>> > >> >>>> > >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> - James Snell >> >>>>  http://www.snellspace.com >> >>>>  jasnell@gmail.com >> >>> >> >> >> >> >> > >> > >> > >> > -- >> > - James Snell >> >  http://www.snellspace.com >> >  jasnell@gmail.com >> > >> >> >> >> -- >> - James Snell >>  http://www.snellspace.com >>  jasnell@gmail.com >> > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Tue May 25 12:14:52 2010 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 2A59B3A69EA for ; Tue, 25 May 2010 12:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.154 X-Spam-Level: * X-Spam-Status: No, score=1.154 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_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 YWE4NX4wIGXs for ; Tue, 25 May 2010 12:14:50 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3A0633A69D6 for ; Tue, 25 May 2010 12:14:43 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4PJ7e4H011162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2010 12:07:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4PJ7edb011161; Tue, 25 May 2010 12:07:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4PJ7cKR011155 for ; Tue, 25 May 2010 12:07:39 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by vws19 with SMTP id 19so1672677vws.16 for ; Tue, 25 May 2010 12:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=4oUUsNLueCgQ0euLBjT/8nxmoK7ivn5cpdtCJD8kDHU=; b=dyff3RCs6G6kYjCe3xydLIlBViDY47hR2JIkJY1i5NFOi/B4FwJPjnQjNV5szZP/mP /zap8riSsgP0X0y3080+fyvSXy9K1niaKIJCtokLW74q7ob8gV3RNy8KMyK9rED0DOvm E0ZCplc8aYbFSau16dCzcrZCxaARgF/GFTdyA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FQ0bTKxsus5kfsagwukhNB/zkexcqQCDFIRpRt6vhrA/HfMnDPi0tt3Jto4GafZ2tW goE6zaNrZ5ujwfegdqHpV3TNXbjhutwVEMpd4VSGiynmJdgj7tK36FuvqG1mJoddccOm OXUuipY6arukl3l3gcR/AdNrLrbpP02mBn9qA= MIME-Version: 1.0 Received: by 10.229.248.197 with SMTP id mh5mr1620129qcb.32.1274814457850; Tue, 25 May 2010 12:07:37 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Tue, 25 May 2010 12:07:37 -0700 (PDT) Date: Tue, 25 May 2010 12:07:37 -0700 Message-ID: Subject: Security Considerations for Link Extensions From: James Snell To: Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ok, so I'm working on finishing up the basic link extensions draft. The Security Considerations are currently TBD. I wanted to take a moment to solicit input on appropriate security considerations for these optional, advisory extension attributes. One in particular... hash digest are often used as a simple means of verifying that data has not been modified while in transit.. hash digests contained within an atom:link cannot be used for that purpose. Rather, the hash attribute is used to express the state of the linked resource at a given point in time so that a feed consumer can detect whether or not the resource has been modified since the link was created. Other than that, there really shouldn't be any further security concerns with regards to the link extensions.. but I welcome being corrected on that :-) Thoughts? -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Tue May 25 12:57:42 2010 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 0E01F3A6A4F for ; Tue, 25 May 2010 12:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.777 X-Spam-Level: * X-Spam-Status: No, score=1.777 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 Bra-e1riV7lI for ; Tue, 25 May 2010 12:57:40 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id BDD773A6A48 for ; Tue, 25 May 2010 12:57:40 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4PJqbZU014087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2010 12:52:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4PJqbX7014086; Tue, 25 May 2010 12:52:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-gy0-f171.google.com (mail-gy0-f171.google.com [209.85.160.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4PJqa4w014081 for ; Tue, 25 May 2010 12:52:36 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by gyf3 with SMTP id 3so2239570gyf.16 for ; Tue, 25 May 2010 12:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=+WCUgcqcvk3Tc72ljFEFVlY7PFGe/6ZR7TFpFlb33fA=; b=PTLvwmi0u+ZZyMouWX6YMEPoDbqHFzGGTvNRls1O62jZ2g5eIfuxIxEPRa2ne9uoj3 oktLE44w6BaXP3vPE/cL8bTbAWBMhA4LfJ1Y/uP8Csy4C0BeTCLm3JnOM4P0S45uTY2j KeZX3Fzk/G5+KGU3VYB2FLYFTD86pwA2OhLKI= 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=ZIpxXvOF7kHTtdQ6ktSEy9fWzDkr+71JgyQvySb/WDcRT64hXyjvrp31M4zQ2HeTf8 vG5HTfFyBgQLVytCxKad+snUIJQEtjHVFnzY6p1SO925d/hrGsFc4pkhF312iNEsIQ+O XfUINwk4Qjseh3bOalB00t3eGOVLgmAiGJQog= MIME-Version: 1.0 Received: by 10.101.135.17 with SMTP id m17mr9157531ann.57.1274817154122; Tue, 25 May 2010 12:52:34 -0700 (PDT) Received: by 10.100.154.20 with HTTP; Tue, 25 May 2010 12:52:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 May 2010 15:52:34 -0400 X-Google-Sender-Auth: J8K8bnvg0ncCM2al7ZKzZz9wtHQ Message-ID: Subject: Re: Security Considerations for Link Extensions From: Bob Wyman To: James Snell Cc: Atom Syntax Content-Type: multipart/alternative; boundary=001636c5c297a007210487707f8c Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --001636c5c297a007210487707f8c Content-Type: text/plain; charset=ISO-8859-1 The way you describe the utility of the hash, you make it sound like it is somehow "inadequate" for the traditional use of hashes. But, that's not really relevant here. This is a use of a hash for a different purpose than the hashes we normally use in link integrity checking. I would suggest that you focus on the utility of this style of hash rather than emphasizing the things that it doesn't even attempt to do. BTW: I realize that this may be totally unnecessary, however, I can't help thinking that a "last-accessed-on" attribute to show when the link was last accessed and thus when the hash was generated might be useful... In nothing else, there is a good bit of precedence in things like formal standards for citing web resources that typically require that a "last-accessed" date be provided. I'm not willing to invest a great deal in fighting for this. I just thought I would mention it. bob wyman On Tue, May 25, 2010 at 3:07 PM, James Snell wrote: > > Ok, so I'm working on finishing up the basic link extensions draft. > The Security Considerations are currently TBD. I wanted to take a > moment to solicit input on appropriate security considerations for > these optional, advisory extension attributes. > > One in particular... hash digest are often used as a simple means of > verifying that data has not been modified while in transit.. hash > digests contained within an atom:link cannot be used for that purpose. > Rather, the hash attribute is used to express the state of the linked > resource at a given point in time so that a feed consumer can detect > whether or not the resource has been modified since the link was > created. > > Other than that, there really shouldn't be any further security > concerns with regards to the link extensions.. but I welcome being > corrected on that :-) Thoughts? > > -- > - James Snell > http://www.snellspace.com > jasnell@gmail.com > > --001636c5c297a007210487707f8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The way you describe the utility of the hash, you make it sound like it is = somehow "inadequate" for the traditional use of hashes. But, that= 's not really relevant here. This is a use of a hash for a different pu= rpose than the hashes we normally use in link integrity checking. I would s= uggest that you focus on the utility of this style of hash rather than emph= asizing the things that it doesn't even attempt to do.

BTW: I realize that this may be totally unnecessary, however= , I can't help thinking that a "last-accessed-on" attribute t= o show when the link was last accessed and thus when the hash was generated= might be useful... In nothing else, there is a good bit of precedence in t= hings like formal standards for citing web resources that typically require= that a "last-accessed" date be provided. I'm not willing to = invest a great deal in fighting for this. I just thought I would mention it= .

bob wyman

On Tue, May= 25, 2010 at 3:07 PM, James Snell <jasnell@gmail.com> wrote:

Ok, so I'm working on finishing up the basic link extensions draft.
The Security Considerations are currently TBD. I wanted to take a
moment to solicit input on appropriate security considerations for
these optional, advisory extension attributes.

One in particular... hash digest are often used as a simple means of
verifying that data has not been modified while in transit.. hash
digests contained within an atom:link cannot be used for that purpose.
Rather, the hash attribute is used to express the state of the linked
resource at a given point in time so that a feed consumer can detect
whether or not the resource has been modified since the link was
created.

Other than that, there really shouldn't be any further security
concerns with regards to the link extensions.. but I welcome being
corrected on that :-) Thoughts?

--
- James Snell
=A0http://www.snel= lspace.com
=A0jasnell@gmail.com


--001636c5c297a007210487707f8c-- From owner-atom-syntax@mail.imc.org Tue May 25 13:32:42 2010 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 39AB53A6A82 for ; Tue, 25 May 2010 13:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.154 X-Spam-Level: * X-Spam-Status: No, score=1.154 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_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 kMOrPJnL-bQY for ; Tue, 25 May 2010 13:32:41 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1132D3A69DA for ; Tue, 25 May 2010 13:32:40 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4PKRKD7016145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2010 13:27:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4PKRK6Q016144; Tue, 25 May 2010 13:27:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4PKRJps016139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 May 2010 13:27:20 -0700 (MST) (envelope-from colm.divilly@oracle.com) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4PKRDlB025455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 May 2010 20:27:16 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4PKRBk1017129; Tue, 25 May 2010 20:27:12 GMT Received: from abhmt020.oracle.com by acsmt355.oracle.com with ESMTP id 297400481274819147; Tue, 25 May 2010 13:25:47 -0700 Received: from [192.168.1.4] (/194.125.54.36) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 May 2010 13:25:47 -0700 Message-ID: <4BFC3247.80909@oracle.com> Date: Tue, 25 May 2010 21:25:43 +0100 From: Colm Divilly User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: James Snell CC: Atom Syntax Subject: Re: Security Considerations for Link Extensions References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090204.4BFC32A4.0177:SCFMA922111,ss=1,fgs=0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: James Snell wrote: > Ok, so I'm working on finishing up the basic link extensions draft. > The Security Considerations are currently TBD. I wanted to take a > moment to solicit input on appropriate security considerations for > these optional, advisory extension attributes. > > One in particular... hash digest are often used as a simple means of > verifying that data has not been modified while in transit.. hash > digests contained within an atom:link cannot be used for that purpose. > Rather, the hash attribute is used to express the state of the linked > resource at a given point in time so that a feed consumer can detect > whether or not the resource has been modified since the link was > created. > > That sounds more like an Entity Tag (which are often but not always generated using hashes), so do we really mean an Entity Tag or is there a reason to restrict this to just using hashes ? > Other than that, there really shouldn't be any further security > concerns with regards to the link extensions.. but I welcome being > corrected on that :-) Thoughts? > > From owner-atom-syntax@mail.imc.org Tue May 25 15:06:44 2010 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 57C693A7001 for ; Tue, 25 May 2010 15:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, 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 pZreO6pAVDlL for ; Tue, 25 May 2010 15:06:42 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1B5EA3A753B for ; Tue, 25 May 2010 14:10:41 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4PL63iV018301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2010 14:06:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4PL63Oo018300; Tue, 25 May 2010 14:06:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4PL62eA018295 for ; Tue, 25 May 2010 14:06:02 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by vws19 with SMTP id 19so1810940vws.16 for ; Tue, 25 May 2010 14:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lAUXPCK+8XQBXjrZQpq7kesSk6UjY0l8T2LvZyG/qo8=; b=jPvH+/MQbcJwFz+H+8nOZlJyUFrkcf0Nk8lxtp38X+wfk2ouZq6ynKOcmlhN5ZU0/8 35xqXSo6YohKaWyfCP/KRcq6J6sXxj+0uJJM+csqO5dhaRfhIKPSpjhwS1YVCqw01Cbl e8Cp5XbMtivCcjdw9UPZl1DARNOG5SBsg4yH8= 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=DFIy2Xe3VPd1B2ZLaDlBtO1Y1LOg/uBaRYd4QTuW9vV6EsO69rasQkj0vpSKJEswCh t7LIrKrPXc3I6b41X2LewtRPUYUdwAVvSJ5z8c5uUEVOVCvB30wfhZxU3shabrdxiRgk y90cFV8oYiTyfsBrg5Igo/3jtw0EDNjKnfx0I= MIME-Version: 1.0 Received: by 10.229.190.14 with SMTP id dg14mr1678424qcb.49.1274821561733; Tue, 25 May 2010 14:06:01 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Tue, 25 May 2010 14:06:01 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 May 2010 14:06:01 -0700 Message-ID: Subject: Re: Security Considerations for Link Extensions From: James Snell To: Bob Wyman Cc: Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4PL63eA018296 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've been considering either an "accessed" attribute or specifying terms that indicate that atom:updated element be used as the point-in-time for the links for atom:entry and atom:feed. The when attribute would serve the same purpose for at:deleted-entry and I assume that other containers for atom:link could specify their own relevant time. And you make an excellent point on focusing on the specific utility of the attributes. Are there are security concerns you can think of relating to the specific use cases for these attributes? On Tue, May 25, 2010 at 12:52 PM, Bob Wyman wrote: > The way you describe the utility of the hash, you make it sound like it is > somehow "inadequate" for the traditional use of hashes. But, that's not > really relevant here. This is a use of a hash for a different purpose than > the hashes we normally use in link integrity checking. I would suggest that > you focus on the utility of this style of hash rather than emphasizing the > things that it doesn't even attempt to do. > BTW: I realize that this may be totally unnecessary, however, I can't help > thinking that a "last-accessed-on" attribute to show when the link was last > accessed and thus when the hash was generated might be useful... In nothing > else, there is a good bit of precedence in things like formal standards for > citing web resources that typically require that a "last-accessed" date be > provided. I'm not willing to invest a great deal in fighting for this. I > just thought I would mention it. > bob wyman > > On Tue, May 25, 2010 at 3:07 PM, James Snell wrote: >> >> Ok, so I'm working on finishing up the basic link extensions draft. >> The Security Considerations are currently TBD. I wanted to take a >> moment to solicit input on appropriate security considerations for >> these optional, advisory extension attributes. >> >> One in particular... hash digest are often used as a simple means of >> verifying that data has not been modified while in transit.. hash >> digests contained within an atom:link cannot be used for that purpose. >> Rather, the hash attribute is used to express the state of the linked >> resource at a given point in time so that a feed consumer can detect >> whether or not the resource has been modified since the link was >> created. >> >> Other than that, there really shouldn't be any further security >> concerns with regards to the link extensions.. but I welcome being >> corrected on that :-) Thoughts? >> >> -- >> - James Snell >>  http://www.snellspace.com >>  jasnell@gmail.com >> > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Tue May 25 17:42:59 2010 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 085D03A67A4 for ; Tue, 25 May 2010 17:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.977 X-Spam-Level: ** X-Spam-Status: No, score=2.977 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 ZzA2dXrXnFkE for ; Tue, 25 May 2010 17:42:55 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 760B33A6ED4 for ; Tue, 25 May 2010 16:34:52 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4PNTv1Q025556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2010 16:29:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4PNTvGe025555; Tue, 25 May 2010 16:29:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-pv0-f171.google.com (mail-pv0-f171.google.com [74.125.83.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4PNTuAa025550 for ; Tue, 25 May 2010 16:29:57 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by pvb32 with SMTP id 32so572182pvb.16 for ; Tue, 25 May 2010 16:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=NvDP+ilmDrRn1Sz+LIC6b673JJFEqGYgA7AgJdLujVM=; b=rnz0dOwryI2wLSVNxuki++kydWFXfaqdBbSTmjWf32qq5i11Z+CBpHECxAk82yq94+ dgPPbCGJ1yAhjig46yAj5Tsp4R6I85rXSkq2vPx8zXkYTwJEbhNx0FMqRwexfbvfBGnK hL+OCvbZYOt7a9A93JPWdFnVq2Bavo31WWd2E= 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=Urn31xJ357ZW7C9GFdeIFD9ks58TYarKb/WvOJdy/ghMWATMRd2i7DPA8nZ2gdk/bL iaayvmx2nL9uDDgkvhxKga10p7Kel/atkhLbehUI76EQhWc5sPMI6YmBqsZAtYqRypOY 9seicO8RMPz8o7KylIuN/b75P2vQ4PpvXvvEQ= MIME-Version: 1.0 Received: by 10.115.65.14 with SMTP id s14mr6791441wak.209.1274830196166; Tue, 25 May 2010 16:29:56 -0700 (PDT) Received: by 10.115.18.16 with HTTP; Tue, 25 May 2010 16:29:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 May 2010 19:29:55 -0400 X-Google-Sender-Auth: ov2f0Op7ny_GeXlY3EuEfWZVKv4 Message-ID: Subject: Re: Security Considerations for Link Extensions From: Bob Wyman To: James Snell Cc: Atom Syntax Content-Type: multipart/alternative; boundary=0016e64cae16fde7ce04877388ef Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0016e64cae16fde7ce04877388ef Content-Type: text/plain; charset=ISO-8859-1 I'm a bit worried about a potential "security" concern if people overuse the hash attribute. This is something that really should only be used when you really need to refer to a specific version of a resource -- and it should be a resource that you expect to be stable for a useful period of time. My concern is that people will tend to think that it is "cool" to add in more metadata on links and thus will just hash all kinds of stuff -- because they can. The result will be a large number of "broken" hashes and a sense that since most hashes are broken, the fact that a hash is broken is simply not interesting... At that point, various social engineering operations become possible. We really should consider discouraging people from using the hash attribute unless it is really necessary and unless they actually expect that the resource they are hashing *should* be stable for a usefully long period of time. bob wyman On Tue, May 25, 2010 at 5:06 PM, James Snell wrote: > I've been considering either an "accessed" attribute or specifying > terms that indicate that atom:updated element be used as the > point-in-time for the links for atom:entry and atom:feed. The when > attribute would serve the same purpose for at:deleted-entry and I > assume that other containers for atom:link could specify their own > relevant time. And you make an excellent point on focusing on the > specific utility of the attributes. Are there are security concerns > you can think of relating to the specific use cases for these > attributes? > > On Tue, May 25, 2010 at 12:52 PM, Bob Wyman wrote: > > The way you describe the utility of the hash, you make it sound like it > is > > somehow "inadequate" for the traditional use of hashes. But, that's not > > really relevant here. This is a use of a hash for a different purpose > than > > the hashes we normally use in link integrity checking. I would suggest > that > > you focus on the utility of this style of hash rather than emphasizing > the > > things that it doesn't even attempt to do. > > BTW: I realize that this may be totally unnecessary, however, I can't > help > > thinking that a "last-accessed-on" attribute to show when the link was > last > > accessed and thus when the hash was generated might be useful... In > nothing > > else, there is a good bit of precedence in things like formal standards > for > > citing web resources that typically require that a "last-accessed" date > be > > provided. I'm not willing to invest a great deal in fighting for this. I > > just thought I would mention it. > > bob wyman > > > > On Tue, May 25, 2010 at 3:07 PM, James Snell wrote: > >> > >> Ok, so I'm working on finishing up the basic link extensions draft. > >> The Security Considerations are currently TBD. I wanted to take a > >> moment to solicit input on appropriate security considerations for > >> these optional, advisory extension attributes. > >> > >> One in particular... hash digest are often used as a simple means of > >> verifying that data has not been modified while in transit.. hash > >> digests contained within an atom:link cannot be used for that purpose. > >> Rather, the hash attribute is used to express the state of the linked > >> resource at a given point in time so that a feed consumer can detect > >> whether or not the resource has been modified since the link was > >> created. > >> > >> Other than that, there really shouldn't be any further security > >> concerns with regards to the link extensions.. but I welcome being > >> corrected on that :-) Thoughts? > >> > >> -- > >> - James Snell > >> http://www.snellspace.com > >> jasnell@gmail.com > >> > > > > > > > > -- > - James Snell > http://www.snellspace.com > jasnell@gmail.com > --0016e64cae16fde7ce04877388ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm a bit worried about a potential "security" concern if peo= ple overuse the hash attribute. This is something that really should only b= e used when you really need to refer to a specific version of a resource --= and it should be a resource that you expect to be stable for a useful peri= od of time. My concern is that people will tend to think that it is "c= ool" to add in more metadata on links and thus will just hash all kind= s of stuff -- because they can. The result will be a large number of "= broken" hashes and a sense that since most hashes are broken, the fact= that a hash is broken is simply not interesting... At that point, various = social engineering operations become possible.

We really should consider discouraging people from using the= hash attribute unless it is really necessary and unless they actually expe= ct that the resource they are hashing *should* be stable for a usefully lon= g period of time.

bob wyman

On Tue, May= 25, 2010 at 5:06 PM, James Snell <jasnell@gmail.com> wrote:
I've been considering either an "accessed" attribute or speci= fying
terms that indicate that atom:updated element be used as the
point-in-time for the links for atom:entry and atom:feed. The when
attribute would serve the same purpose for at:deleted-entry and I
assume that other containers for atom:link could specify their own
relevant time. And you make an excellent point on focusing on the
specific utility of the attributes. Are there are security concerns
you can think of relating to the specific use cases for these
attributes?

On Tue, May 25, 2010 at 12:52 PM, Bob Wyman <bob@wyman.us> wrote:
> The way you describe the utility of the hash, you make it sound like i= t is
> somehow "inadequate" for the traditional use of hashes. But,= that's not
> really relevant here. This is a use of a hash for a different purpose = than
> the hashes we normally use in link integrity checking. I would suggest= that
> you focus on the utility of this style of hash rather than emphasizing= the
> things that it doesn't even attempt to do.
> BTW: I realize that this may be totally unnecessary, however, I can= 9;t help
> thinking that a "last-accessed-on" attribute to show when th= e link was last
> accessed and thus when the hash was generated might be useful... In no= thing
> else, there is a good bit of precedence in things like formal standard= s for
> citing web resources that typically require that a "last-accessed= " date be
> provided. I'm not willing to invest a great deal in fighting for t= his. I
> just thought I would mention it.
> bob wyman
>
> On Tue, May 25, 2010 at 3:07 PM, James Snell <jasnell@gmail.com> wrote:
>>
>> Ok, so I'm working on finishing up the basic link extensions d= raft.
>> The Security Considerations are currently TBD. I wanted to take a<= br> >> moment to solicit input on appropriate security considerations for=
>> these optional, advisory extension attributes.
>>
>> One in particular... hash digest are often used as a simple means = of
>> verifying that data has not been modified while in transit.. hash<= br> >> digests contained within an atom:link cannot be used for that purp= ose.
>> Rather, the hash attribute is used to express the state of the lin= ked
>> resource at a given point in time so that a feed consumer can dete= ct
>> whether or not the resource has been modified since the link was >> created.
>>
>> Other than that, there really shouldn't be any further securit= y
>> concerns with regards to the link extensions.. but I welcome being=
>> corrected on that :-) Thoughts?
>>
>> --
>> - James Snell
>> =A0http://= www.snellspace.com
>> =A0jasnell@gmail.com
>>
>
>



--

--0016e64cae16fde7ce04877388ef-- From owner-atom-syntax@mail.imc.org Tue May 25 17:43:21 2010 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 7D0CF3A6952 for ; Tue, 25 May 2010 17:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.054 X-Spam-Level: ** X-Spam-Status: No, score=2.054 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, 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 2HxIwyB1PXz4 for ; Tue, 25 May 2010 17:43:20 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 725843A6F02 for ; Tue, 25 May 2010 16:39:29 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4PNaBCC040000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2010 16:36:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4PNaB62039999; Tue, 25 May 2010 16:36:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4PNaAVc039994 for ; Tue, 25 May 2010 16:36:10 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by vws19 with SMTP id 19so1919129vws.16 for ; Tue, 25 May 2010 16:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QyQS3TqsipzFHO+L/3dgm/0kxhCJNn2JeL/qeSaOXOc=; b=xRu7neicgM+LLhB3f68voqRDR8+23auitc4UPVd/eiwZa/YALfaowvu7h8sCMC6lNk I0pc6rH7wRiQC34pwRUN+wvZucIqE6CylBCLaIgNJoUVfHlq2pVVzEUxnCemrumP6YKA A5mpFqAA7onzvhgWCpLiTPDyDKH+nxJL65xtA= 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=dRTa2EhIu/UyIDiITvnSI7LwU8xEw/qm3x0z0lNyqp1+Q/0tQcABz1LbTAkzqhwGBf Z5mIxr/c3xhnyhxUqiR4UEbNjRR0N4tCfnDu+sk4on5sMcxhgZ7iLtl1JYeIMHwmYvgy bu1X5EcayByUocGQJ/Buv47mJhrHjqwYCU7CU= MIME-Version: 1.0 Received: by 10.229.186.138 with SMTP id cs10mr1717532qcb.34.1274830569851; Tue, 25 May 2010 16:36:09 -0700 (PDT) Received: by 10.229.105.20 with HTTP; Tue, 25 May 2010 16:36:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 May 2010 16:36:09 -0700 Message-ID: Subject: Re: Security Considerations for Link Extensions From: James Snell To: Bob Wyman Cc: Atom Syntax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o4PNaBVc039995 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sounds good.. interested in working up some text for that ;-) On Tue, May 25, 2010 at 4:29 PM, Bob Wyman wrote: > I'm a bit worried about a potential "security" concern if people overuse the > hash attribute. This is something that really should only be used when you > really need to refer to a specific version of a resource -- and it should be > a resource that you expect to be stable for a useful period of time. My > concern is that people will tend to think that it is "cool" to add in more > metadata on links and thus will just hash all kinds of stuff -- because they > can. The result will be a large number of "broken" hashes and a sense that > since most hashes are broken, the fact that a hash is broken is simply not > interesting... At that point, various social engineering operations become > possible. > We really should consider discouraging people from using the hash attribute > unless it is really necessary and unless they actually expect that the > resource they are hashing *should* be stable for a usefully long period of > time. > bob wyman > > On Tue, May 25, 2010 at 5:06 PM, James Snell wrote: >> >> I've been considering either an "accessed" attribute or specifying >> terms that indicate that atom:updated element be used as the >> point-in-time for the links for atom:entry and atom:feed. The when >> attribute would serve the same purpose for at:deleted-entry and I >> assume that other containers for atom:link could specify their own >> relevant time. And you make an excellent point on focusing on the >> specific utility of the attributes. Are there are security concerns >> you can think of relating to the specific use cases for these >> attributes? >> >> On Tue, May 25, 2010 at 12:52 PM, Bob Wyman wrote: >> > The way you describe the utility of the hash, you make it sound like it >> > is >> > somehow "inadequate" for the traditional use of hashes. But, that's not >> > really relevant here. This is a use of a hash for a different purpose >> > than >> > the hashes we normally use in link integrity checking. I would suggest >> > that >> > you focus on the utility of this style of hash rather than emphasizing >> > the >> > things that it doesn't even attempt to do. >> > BTW: I realize that this may be totally unnecessary, however, I can't >> > help >> > thinking that a "last-accessed-on" attribute to show when the link was >> > last >> > accessed and thus when the hash was generated might be useful... In >> > nothing >> > else, there is a good bit of precedence in things like formal standards >> > for >> > citing web resources that typically require that a "last-accessed" date >> > be >> > provided. I'm not willing to invest a great deal in fighting for this. I >> > just thought I would mention it. >> > bob wyman >> > >> > On Tue, May 25, 2010 at 3:07 PM, James Snell wrote: >> >> >> >> Ok, so I'm working on finishing up the basic link extensions draft. >> >> The Security Considerations are currently TBD. I wanted to take a >> >> moment to solicit input on appropriate security considerations for >> >> these optional, advisory extension attributes. >> >> >> >> One in particular... hash digest are often used as a simple means of >> >> verifying that data has not been modified while in transit.. hash >> >> digests contained within an atom:link cannot be used for that purpose. >> >> Rather, the hash attribute is used to express the state of the linked >> >> resource at a given point in time so that a feed consumer can detect >> >> whether or not the resource has been modified since the link was >> >> created. >> >> >> >> Other than that, there really shouldn't be any further security >> >> concerns with regards to the link extensions.. but I welcome being >> >> corrected on that :-) Thoughts? >> >> >> >> -- >> >> - James Snell >> >>  http://www.snellspace.com >> >>  jasnell@gmail.com >> >> >> > >> > >> >> >> >> -- >> - James Snell >>  http://www.snellspace.com >>  jasnell@gmail.com > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From atompub-archive@megatron.ietf.org Wed May 26 00:10:15 2010 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 A29993A6858 for ; Wed, 26 May 2010 00:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.513 X-Spam-Level: X-Spam-Status: No, score=-13.513 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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_NONE=0.1, 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 s-u-yz8FFjpH for ; Wed, 26 May 2010 00:10:07 -0700 (PDT) Received: from adventinfosoft.com (unknown [94.181.9.232]) by core3.amsl.com (Postfix) with SMTP id D277F3A6861 for ; Wed, 26 May 2010 00:10:06 -0700 (PDT) From: RX-Store To: Subject: 78% Discount. Best sale. MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100526071006.D277F3A6861@core3.amsl.com> Date: Wed, 26 May 2010 00:10:06 -0700 (PDT)
Click here to view as a web page.

To atompub-archive@megatron.ietf.org | Privacy Policy | Contact Us

Copyright 2010 All rights reserved.
From atompub-archive@megatron.ietf.org Wed May 26 05:59:55 2010 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 E23343A691D for ; Wed, 26 May 2010 05:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.889 X-Spam-Level: X-Spam-Status: No, score=-28.889 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 3cykzGI6Fkua for ; Wed, 26 May 2010 05:59:49 -0700 (PDT) Received: from 110.221.c10008-a53.dsl-dynamic.vsi.ru (108.219.c10008-a53.dsl-dynamic.vsi.ru [77.45.219.108]) by core3.amsl.com (Postfix) with SMTP id 206353A68C3 for ; Wed, 26 May 2010 05:59:47 -0700 (PDT) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20100526125948.206353A68C3@core3.amsl.com> Date: Wed, 26 May 2010 05:59:47 -0700 (PDT)
Click here to view as a web page.

To atompub-archive@megatron.ietf.org | Privacy Policy | Contact Us

Copyright 2010 All rights reserved.
From atompub-archive@megatron.ietf.org Wed May 26 06:52:18 2010 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 3C0413A692D for ; Wed, 26 May 2010 06:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.417 X-Spam-Level: X-Spam-Status: No, score=-27.417 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=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_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 6cwpjU6E3koQ for ; Wed, 26 May 2010 06:52:11 -0700 (PDT) Received: from aegon-cnooc.com (unknown [72.252.1.4]) by core3.amsl.com (Postfix) with SMTP id E1F7A3A67A2 for ; Wed, 26 May 2010 06:52:09 -0700 (PDT) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20100526135209.E1F7A3A67A2@core3.amsl.com> Date: Wed, 26 May 2010 06:52:09 -0700 (PDT)
Click here to view as a web page.

To atompub-archive@megatron.ietf.org | Privacy Policy | Contact Us

Copyright 2010 All rights reserved.
From atompub-archive@megatron.ietf.org Wed May 26 09:36:32 2010 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 628F63A688C for ; Wed, 26 May 2010 09:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.354 X-Spam-Level: X-Spam-Status: No, score=-13.354 tagged_above=-999 required=5 tests=[BAYES_60=1, 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_RU=0.595, HOST_EQ_BROADBND=1.118, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=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, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 n3TCvMOBO8VT for ; Wed, 26 May 2010 09:36:29 -0700 (PDT) Received: from 78-106-48-251.broadband.corbina.ru (78-106-48-251.broadband.corbina.ru [78.106.48.251]) by core3.amsl.com (Postfix) with SMTP id A2FA73A6862 for ; Wed, 26 May 2010 09:36:27 -0700 (PDT) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20100526163628.A2FA73A6862@core3.amsl.com> Date: Wed, 26 May 2010 09:36:27 -0700 (PDT)
Click here to view as a web page.

To atompub-archive@megatron.ietf.org | Privacy Policy | Contact Us

Copyright 2010 All rights reserved.
From owner-atom-syntax@mail.imc.org Thu May 27 09:40:20 2010 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 E22643A6819 for ; Thu, 27 May 2010 09:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=-2.648, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKjAO3WCENiP for ; Thu, 27 May 2010 09:40:20 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 155833A67B4 for ; Thu, 27 May 2010 09:40:16 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4RGXxOd099421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 May 2010 09:33:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4RGXx7L099417; Thu, 27 May 2010 09:33:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.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 hoffman.proper.com (8.14.4/8.14.3) with SMTP id o4RGXvig099405 for ; Thu, 27 May 2010 09:33:57 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 27 May 2010 16:33:55 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.116]) [217.91.35.233] by mail.gmx.net (mp002) with SMTP; 27 May 2010 18:33:55 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19rv5osrv1rexnBsPwFZiN9lqW3Qw9sNU/9P31h+Q u2ddl+3ayIMTXp Message-ID: <4BFE9EE9.1040404@gmx.de> Date: Thu, 27 May 2010 18:33:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Atom-syntax Syntax'" CC: Tim Bray , Paul Hoffman / IMC Subject: Re: Change Proposal to HTML WG to fix the algorithm for generating Atom feeds from HTML content References: <0DA742E8-D6BA-4AB1-95D7-23D96495885D@apple.com> <4BBBA3D3.9060001@gmx.de> <4BBBA4E2.3090408@gmx.de> In-Reply-To: <4BBBA4E2.3090408@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 06.04.2010 23:17, Julian Reschke wrote: > > FYI: > > this relates to an HTML-WG discussion about the algorithm to create Atom > feeds from HTML (). > > See and > for more context on how we > got here. > > Best regards, Julian > ... In the meantime, the HTML WG has decided to drop this part of the spec. See . Best regards, Julian From owner-atom-syntax@mail.imc.org Thu May 27 13:17:59 2010 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 AA63A3A672E for ; Thu, 27 May 2010 13:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.854 X-Spam-Level: X-Spam-Status: No, score=0.854 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, 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 RVqNkUbSf3kt for ; Thu, 27 May 2010 13:17:57 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 753493A698F for ; Thu, 27 May 2010 13:17:08 -0700 (PDT) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4RKC3Rd012272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 May 2010 13:12:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o4RKC3c6012271; Thu, 27 May 2010 13:12:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4RKC1DI012265 for ; Thu, 27 May 2010 13:12:02 -0700 (MST) (envelope-from asbjornu@gmail.com) Received: by fxm13 with SMTP id 13so397915fxm.16 for ; Thu, 27 May 2010 13:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:content-type:to:cc :subject:references:date:mime-version:content-transfer-encoding:from :message-id:in-reply-to:user-agent; bh=shS6pjnaEIrgpZZO7EFLjjM7RYcYPmRm+Zp+bHUT0ng=; b=OYoLouw5w4YIjDiK+aX6Os3EWiqyFj50gnrpai/gcK/zRsx2UkHhdzM73jGdLG51ZE LOoAT5Nzr6WiHHvJuEqn0B+VrhGkuP9D9CoAYCigYVFzWmRUqiyfJhVL/dWrbdZSjPsB axIUQCCXzNXqi9z16E5nptaFJbKA183EnnIow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:content-type:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; b=qhnpCYBqDSUDRS0+c+Gsm3kM5ZbiHKK5RLWuvHKScpKZN8adPQxJ/x3euTB1likbPr bMi8PV3XMBuW80YtNH9Lqr4EGqGDT9CypCFX6jsYIIomVCN8mD0qYgSDVRj0CskJIMv/ M8K//7V4WQhV0WdKrSFiakIngSggncGb7XL+4= Received: by 10.223.56.206 with SMTP id z14mr178831fag.97.1274991120754; Thu, 27 May 2010 13:12:00 -0700 (PDT) Received: from au-book.local (235.84-48-116.nextgentel.com [84.48.116.235]) by mx.google.com with ESMTPS id u12sm7157481fah.4.2010.05.27.13.11.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 May 2010 13:11:58 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes To: "James Holderness" , "Julian Reschke" Cc: "Atom-syntax Syntax'" Subject: Re: Change Proposal to HTML WG to fix the algorithm for generating Atom feeds from HTML content References: <0DA742E8-D6BA-4AB1-95D7-23D96495885D@apple.com> <4BBBA3D3.9060001@gmx.de> <4BBBA4E2.3090408@gmx.de> <4BBC3F5A.1000207@gmx.de> Date: Thu, 27 May 2010 22:11:56 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Message-ID: In-Reply-To: <4BBC3F5A.1000207@gmx.de> User-Agent: Opera Mail/10.54 (MacIntel) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 07 Apr 2010 10:16:26 +0200, Julian Reschke wrote: > I think the reason that was presented is that people prefer to publish > just HTML instead of HTML + a feed. Should be somewhere in the WHATWG > archives. > > Personally, I don't buy that. HTML pages that qualify as material for > news feeds are usually generated from a different source, such as a > database of news entries, or actually a feed document (this is how I do > it). Publishing both is simple, and actually saves bandwidth for those > just needing the Atom version. This what I'm thinking as well. If there's no back-end store and all you have is text of some sort stored in the file system, 99 out of 100 times I'd choose to store Atom documents in the file system and transform these to HTML with XSLT rather than the other way around, especially when the algorithm defined to do so is so ridiculous as it is. >> Frankly I'd toss the whole thing out. Then again, I'd say the same for a >> good deal of HTML5. > > Same here. +1. -- Asbjørn Ulsberg -=|=- asbjorn@ulsberg.no «He's a loathsome offensive brute, yet I can't look away» From VanLiereC@District279.org Thu May 27 19:47:34 2010 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 21A503A67DB for ; Thu, 27 May 2010 19:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.819 X-Spam-Level: ** X-Spam-Status: No, score=2.819 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 SUu8jPdYtL6w for ; Thu, 27 May 2010 19:47:15 -0700 (PDT) Received: from mail.district279.org (owa.osseo.k12.mn.us [206.131.38.18]) by core3.amsl.com (Postfix) with ESMTP id 446513A69E8 for ; Thu, 27 May 2010 19:47:05 -0700 (PDT) Received: from escexc03.core.oas.ld ([10.3.12.41]) by mail.district279.org with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 May 2010 21:46:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAFE10.0774104D" Subject: Your mailbox is almost full. Date: Thu, 27 May 2010 21:46:53 -0500 Message-ID: <4504B98D9C460C47BC93BE525DBC546A108BEED7@escexc03.core.oas.ld> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your mailbox is almost full. Thread-Index: Acr+EAc66qlRgL+2QMOBho1ShpInWQ== From: "Van Liere, Carla (WVR)" To: X-OriginalArrivalTime: 28 May 2010 02:46:53.0392 (UTC) FILETIME=[07999D00:01CAFE10] This is a multi-part message in MIME format. ------_=_NextPart_001_01CAFE10.0774104D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your mailbox is almost full. 20GB =20 23GB Current size =20 Maximum size Your Web-mail Quota Has Exceeded The Set Quota/Limit Which Is 20GB. You Are Currently Running On 23GB Due To Hidden Files And Folder On Your = Mailbox. Please Click the Link Below To Validate Your Mailbox And Increase Your = Quota. CLICK HERE: =20 Failure To Click This Link And Validate Your Quota May Result In Loss Of = Important Information In Your Mailbox/Or Cause Limited Access To It. Thanks HELP DESK =20 ------_=_NextPart_001_01CAFE10.0774104D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=

Your = mailbox is almost full.

=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=

20GB

=0A=

 

=0A=

23GB

=0A=

Current size

=0A=

 

=0A=

Maximum size

=0A=

Your = Web-mail Quota Has Exceeded The Set Quota/Limit Which Is 20GB.
You = Are Currently Running On 23GB Due To Hidden Files And Folder On Your = Mailbox.
Please Click the Link Below To Validate Your Mailbox And = Increase Your Quota.

=0A=

CLICK = HERE:

=0A=

Failure To = Click This Link And Validate Your Quota May Result In Loss Of Important = Information In Your Mailbox/Or Cause Limited Access To = It.
Thanks
HELP DESK

=0A=

 

------_=_NextPart_001_01CAFE10.0774104D-- From atompub-archive@megatron.ietf.org Fri May 28 14:54:34 2010 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 9BC183A672E for ; Fri, 28 May 2010 14:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.596 X-Spam-Level: X-Spam-Status: No, score=-18.596 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_IMAGE_ONLY_20=1.546, 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, 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 CY1u3c5VAAr4 for ; Fri, 28 May 2010 14:54:31 -0700 (PDT) Received: from reversionness-crayon.volia.net (reversionness-crayon.volia.net [77.123.123.241]) by core3.amsl.com (Postfix) with SMTP id 999163A6879 for ; Fri, 28 May 2010 14:54:29 -0700 (PDT) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20100528215429.999163A6879@core3.amsl.com> Date: Fri, 28 May 2010 14:54:29 -0700 (PDT)
Click here to view as a web page.

To atompub-archive@megatron.ietf.org | Privacy Policy | Contact Us

Copyright 2010 All rights reserved.
From atompub-archive@megatron.ietf.org Fri May 28 15:03:45 2010 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 EFB683A68C2 for ; Fri, 28 May 2010 15:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.425 X-Spam-Level: X-Spam-Status: No, score=-5.425 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_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_20=1.546, 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_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 rLQ-bFmz7eje for ; Fri, 28 May 2010 15:03:44 -0700 (PDT) Received: from 123-27-112-92.pool.ukrtel.net (60-103-113-92.pool.ukrtel.net [92.113.103.60]) by core3.amsl.com (Postfix) with SMTP id 3A5AF3A6866 for ; Fri, 28 May 2010 15:03:42 -0700 (PDT) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20100528220343.3A5AF3A6866@core3.amsl.com> Date: Fri, 28 May 2010 15:03:42 -0700 (PDT)
Click here to view as a web page.

To atompub-archive@megatron.ietf.org | Privacy Policy | Contact Us

Copyright 2010 All rights reserved.
From atompub-archive@megatron.ietf.org Fri May 28 15:42:56 2010 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 CEE213A695E for ; Fri, 28 May 2010 15:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.627 X-Spam-Level: X-Spam-Status: No, score=0.627 tagged_above=-999 required=5 tests=[BAYES_60=1, 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_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_20=1.546, 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_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 owWylonY6DYq for ; Fri, 28 May 2010 15:42:49 -0700 (PDT) Received: from 77-254-157-6.adsl.inetia.pl (77-254-157-6.adsl.inetia.pl [77.254.157.6]) by core3.amsl.com (Postfix) with SMTP id C1E6E3A6866 for ; Fri, 28 May 2010 15:42:48 -0700 (PDT) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20100528224248.C1E6E3A6866@core3.amsl.com> Date: Fri, 28 May 2010 15:42:48 -0700 (PDT)
Click here to view as a web page.

To atompub-archive@megatron.ietf.org | Privacy Policy | Contact Us

Copyright 2010 All rights reserved.
From atompub-archive@megatron.ietf.org Fri May 28 15:47:53 2010 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 789653A696C for ; Fri, 28 May 2010 15:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.209 X-Spam-Level: X-Spam-Status: No, score=-9.209 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, HTML_IMAGE_ONLY_20=1.546, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, RELAY_IS_221=2.222, 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 DCVcoVITV7AN for ; Fri, 28 May 2010 15:47:52 -0700 (PDT) Received: from sp2-c810-189.spacelan.ne.jp (sp2-c810-189.spacelan.ne.jp [221.133.108.189]) by core3.amsl.com (Postfix) with SMTP id 0B7823A6866 for ; Fri, 28 May 2010 15:47:50 -0700 (PDT) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20100528224751.0B7823A6866@core3.amsl.com> Date: Fri, 28 May 2010 15:47:50 -0700 (PDT)
Click here to view as a web page.

To atompub-archive@megatron.ietf.org | Privacy Policy | Contact Us

Copyright 2010 All rights reserved.
From frassine2@stefanofrassine.191.it Fri May 28 17:05:30 2010 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 11F0E28C102 for ; Fri, 28 May 2010 17:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.686 X-Spam-Level: * X-Spam-Status: No, score=1.686 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_BIZ=0.288, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 e6W4vaYE7Y+i for ; Fri, 28 May 2010 17:05:29 -0700 (PDT) Received: from smtpout038D.attiva.biz (smtpout038D.attiva.biz [88.44.63.38]) by core3.amsl.com (Postfix) with ESMTP id 0466028C0F9 for ; Fri, 28 May 2010 17:05:28 -0700 (PDT) Received: from FBCMST13V03.fbc.local ([192.168.183.14]) by smtpout038D.attiva.biz with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 May 2010 02:05:16 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAFEC2.94FAB65B" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: Your mailbox is almost full. Date: Sat, 29 May 2010 02:05:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your mailbox is almost full. Thread-Index: Acr+wpQv24rCqrcLTamHC/XJMLvndA== From: "frassine2" To: X-OriginalArrivalTime: 29 May 2010 00:05:16.0242 (UTC) FILETIME=[9E0FB320:01CAFEC2] This is a multi-part message in MIME format. ------_=_NextPart_001_01CAFEC2.94FAB65B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your mailbox is almost full. 20GB 23GB=09 Current size Maximum size=09 Your Webmail Quota Has Exceeded The Set Quota/Limit Which Is 20GB. You Are Currently Running On 23GB Due To Hidden Files And Folder On Your = Mailbox. Please Click the Link Below To Validate Your Mailbox And Increase Your = Quota. =20 CLICK HERE: =20 Failure To Click This Link And Validate Your Quota May Result In Loss Of = Important Information In Your Mailbox/Or Cause Limited Access To It. Thanks HELP DESK ------_=_NextPart_001_01CAFEC2.94FAB65B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
Your mailbox is almost = full.
=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
20GB 23GB
Current = size Maximum = size
=0A=
=0A=
Your Webmail Quota Has Exceeded The Set = Quota/Limit Which Is 20GB.
You Are Currently Running On 23GB Due To = Hidden Files And Folder On Your Mailbox.
Please Click the Link Below = To Validate Your Mailbox And Increase Your Quota.
=0A=
 
=0A= =0A=
Failure To Click This Link And Validate Your Quota May Result In = Loss Of Important Information In Your Mailbox/Or Cause Limited Access To = It.
Thanks
HELP = DESK
------_=_NextPart_001_01CAFEC2.94FAB65B-- From atompub-archive@megatron.ietf.org Sat May 29 18:48:19 2010 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 B0CF53A69A6 for ; Sat, 29 May 2010 18:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.854 X-Spam-Level: X-Spam-Status: No, score=-34.854 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 xKOlv2iOWm+h for ; Sat, 29 May 2010 18:48:18 -0700 (PDT) Received: from acta-assistance.com (unknown [195.58.251.92]) by core3.amsl.com (Postfix) with SMTP id 6AB723A690B for ; Sat, 29 May 2010 18:48:15 -0700 (PDT) To: Subject: 0rder #364530 From: Antoinette Tomlinson MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 100505-0, 05.05.2010), Outbound message X-Antivirus-Status: Clean Message-Id: <20100530014816.6AB723A690B@core3.amsl.com> Date: Sat, 29 May 2010 18:48:15 -0700 (PDT)
Tell a friend · Download latest version See this email as a webpage

Hello!

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2010. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

Ottho Heldringstraat 5, 67981 AZ Amsterdam, The Netherlands
From atompub-archive@megatron.ietf.org Sun May 30 10:06:35 2010 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 04B923A681B for ; Sun, 30 May 2010 10:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.211 X-Spam-Level: X-Spam-Status: No, score=-24.211 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, HOST_EQ_STATIC=1.172, 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_XBL=3.033, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 NQeUCh0bVUS7 for ; Sun, 30 May 2010 10:06:32 -0700 (PDT) Received: from 93-127-79-235.static.vega-ua.net (93-127-79-235.static.vega-ua.net [93.127.79.235]) by core3.amsl.com (Postfix) with SMTP id B6A163A659A for ; Sun, 30 May 2010 10:06:29 -0700 (PDT) To: Subject: RE: Q&A Doctor Lavonne From: Pearlie Hammer MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 100405-1, 05.04.2010), Outbound message X-Antivirus-Status: Clean Message-Id: <20100530170629.B6A163A659A@core3.amsl.com> Date: Sun, 30 May 2010 10:06:29 -0700 (PDT)
Tell a friend · Download latest version See this email as a webpage

Hello!

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2010. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

Ottho Heldringstraat 5, 03834 AZ Amsterdam, The Netherlands
From albergob3@albergobelvedere.191.it Mon May 31 04:31:25 2010 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 892EF3A67F7 for ; Mon, 31 May 2010 04:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_BIZ=0.288, HTML_MESSAGE=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 nSu1ktadosDu for ; Mon, 31 May 2010 04:31:23 -0700 (PDT) Received: from smtpout087B.attiva.biz (smtpout087B.attiva.biz [85.33.31.87]) by core3.amsl.com (Postfix) with ESMTP id 5CBFA3A69A3 for ; Mon, 31 May 2010 04:31:23 -0700 (PDT) Received: from FBCMST02V03.fbc.local ([192.168.30.77]) by smtpout087B.attiva.biz with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 13:31:04 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB00B4.BE21F7C9" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: Your mailbox is almost full. Date: Mon, 31 May 2010 13:30:59 +0200 Message-ID: <186DA0D229D09841AE31532E96C842CD03EA209E@FBCMST02V03.fbc.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your mailbox is almost full. Thread-Index: AcsAtL2EXFs9LnSqSZSXw52kqlX52g== From: "albergob3" To: X-OriginalArrivalTime: 31 May 2010 11:31:04.0778 (UTC) FILETIME=[C15382A0:01CB00B4] This is a multi-part message in MIME format. ------_=_NextPart_001_01CB00B4.BE21F7C9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your Webmail Quota Has Exceeded The Set Quota/Limit Which Is 20GB. You Are Currently Running On 23GB Due To Hidden Files And Folder On Your = Mailbox. Please Click the Link Below To Validate Your Mailbox And Increase Your = Quota. =20 CLICK HERE: http://upgradees02.eb2a.com/feedback/feedback.html or copy = link to your browser. Failure To Click This Link And Validate Your Quota May Result In Loss Of = Important Information In Your Mailbox/Or Cause Limited Access To It. Thanks HELP DESK ------_=_NextPart_001_01CB00B4.BE21F7C9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your mailbox is almost full.

Your Webmail Quota Has Exceeded The Set Quota/Limit = Which Is 20GB.
You Are Currently Running On 23GB Due To Hidden Files And Folder On Your = Mailbox.
Please Click the Link Below To Validate Your Mailbox And Increase Your = Quota.

CLICK HERE: http://upgrad= ees02.eb2a.com/feedback/feedback.html  or copy link to your = browser.

Failure To Click This Link And Validate Your Quota May Result In Loss Of = Important Information In Your Mailbox/Or Cause Limited Access To It.
Thanks
HELP DESK

------_=_NextPart_001_01CB00B4.BE21F7C9--