From pwg-announce-bounces@pwg.org Fri Jul 2 14:05:43 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2873A680C for ; Fri, 2 Jul 2010 14:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Mr-noaQJ0Fhx for ; Fri, 2 Jul 2010 14:05:41 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id AB53C3A6784 for ; Fri, 2 Jul 2010 14:05:41 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 8AC79791A9; Fri, 2 Jul 2010 17:05:42 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by pwg.org (Postfix) with ESMTP id 95C0D791A1 for ; Fri, 2 Jul 2010 17:05:38 -0400 (EDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta04.westchester.pa.mail.comcast.net with comcast id d6vC1e00A1ZXKqc5495fS6; Fri, 02 Jul 2010 21:05:39 +0000 Received: from sz0026.wc.mail.comcast.net ([76.96.58.74]) by omta21.westchester.pa.mail.comcast.net with comcast id d95e1e00F1c5Ti43h95eSy; Fri, 02 Jul 2010 21:05:39 +0000 Date: Fri, 2 Jul 2010 21:05:38 +0000 (UTC) From: wamwagner@comcast.net To: pwg-announce@pwg.org Message-ID: <442723392.10286.1278104738927.JavaMail.root@sz0026a.westchester.pa.mail.comcast.net> In-Reply-To: <1022123727.4553341276227225965.JavaMail.root@sz0026a.westchester.pa.mail.comcast.net> MIME-Version: 1.0 X-Originating-IP: [76.209.130.39] X-Mailer: Zimbra 6.0.5_GA_2364.RHEL5_64 (ZimbraWebClient - FF3.0 (Win)/6.0.5_GA_2324.RHEL5_64) X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [Pwg-Announce] Last Call - MFD Service Model Requirements X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0056157857==" Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 8AC79791A9.ABEDA X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org --===============0056157857== Content-Type: multipart/alternative; boundary="----=_Part_10285_825696558.1278104738927" ------=_Part_10285_825696558.1278104738927 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit This is a reminder that the MFD Service Model Requirements document is in PWG last call, and that this last call nominally expires next week. Although this is a requirements document rather than a specification, failure to satisfy the PWG process on this document will act to stall progress on the multiple MFD Service specifications now being worked on. We sincerely request that members provide comments on this document or, if there are no comments, a simple statement that the document has been read. Many thanks, The MFD Working Group ----- Original Message ----- From: wamwagner@comcast.net To: pwg-announce@pwg.org Sent: Thursday, June 10, 2010 11:33:45 PM Subject: [Pwg-Announce] Last Call - MFD Service Model Requirements All, This is an announcement to begin the Last Call process for the "Multifunction Device Service Model Requirements" statement. This document is a "clear statement of requirements for the standard to be produced" and is required by the PWG Process (ftp://ftp.pwg.org/pub/pwg/general/pwg-process-30.pdf) in conjunction with generating a standard. There will be, in fact, some ten MFD Service Model standards. Two of these have had the requirements statements incorporated in the standard and have already been advanced to PWG Candidate Standard. The MFD Working Group has decided that an integrated requirements statement would not only be more efficient, but would best reflect the consistent approach to modeling the different MFD imaging and ancillary services. The Last Call will close on Friday July 9. Please review this document, accessible at ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdreq10-20100609 and provide your comments (or statement of no comments) to the MFD mail list (mfd@pwg.org). As identified in the PWG Process Document, the "requirements statement is important as it leads to a clear, common understanding of the goals, provides a guide for developing the standard, and can be used as a final test to measure the completeness of the resulting specification." All comments will be addressed and resolved prior to the statement being put up for ballot. Note that PWG approval of this requirements statement is required before the remaining MFD specifications can be approved. Thanks, Bill Wagner/Peter Zehler -- This message has been scanned for viruses and dangerous content by MailScanner , and is believed to be clean. _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_Part_10285_825696558.1278104738927 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Arial; font-size: 12pt; color: #000000'>This is a= reminder that the MFD Service Model Requirements document is in PWG last c= all, and that this last call nominally expires next week. Although this is = a requirements document rather than a specification, failure to satisfy the= PWG process on this document will act to stall progress on the multiple MF= D Service specifications now being worked on. We sincerely request that mem= bers provide comments on this document or, if there are no comments, a simp= le statement that the document has been read.

Many thanks,

Th= e MFD Working Group


----- Original Message -----
From: wamwag= ner@comcast.net
To: pwg-announce@pwg.org
Sent: Thursday, June 10, 201= 0 11:33:45 PM
Subject: [Pwg-Announce] Last Call - MFD Service Model Requ= irements


All,

Th= is is an announcement to begin the Last Call process for the "Multifunction= Device Service Model Requirements"   statement. This  document i= s a "clear statement of requirements for the standard to be produced" = and is required by the PWG Process (ftp://ftp.pwg.org/pub/pwg/general/pwg-= process-30.pdf) in conjunction with generating a standard. There will be, i= n fact, some ten MFD Service Model standards. Two of these have had the req= uirements statements incorporated in the standard and have already been adv= anced to PWG Candidate Standard. The MFD Working Group has decided that an = integrated requirements statement would not only be more efficient, but wou= ld best reflect the consistent approach to modeling the different MFD imagi= ng and ancillary services.  The Last Call will close on Friday July 9.=

Please review this document, accessible at&nb= sp; ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdreq10-20100609 and provide your = comments (or  statement of no comments) to the MFD mail list (mfd@pwg.= org). As identified in the  PWG Process Document,  the "requireme= nts statement is important as it leads to a clear, common understanding of = the goals, provides a guide for developing the standard, and can be used as= a final test to measure the completeness of the resulting specification." = All comments will be addressed and resolved prior to the statement being pu= t up for ballot. Note that PWG approval of this requirements statement is r= equired before the remaining MFD specifications can be approved.
 <= /div>
Thanks,


Bill Wagner/Peter Zehler

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
pwg-announce mailing= list
pwg-announce@pwg.org
https://www.pwg.org/mailman/listinfo/pwg-a= nnounce

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_Part_10285_825696558.1278104738927-- --===============0056157857== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce --===============0056157857==-- From menswearmf62@buyathread.com Wed Jul 7 18:39:33 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3FA3A69ED; Wed, 7 Jul 2010 18:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT2=0.001, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, MORE_SEX=1.183, 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, SARE_ADULT2=1.42, SARE_RECV_SPAM_DOMN0b=1.666, STOX_REPLY_TYPE=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, 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 AVG1KYXkIl7Q; Wed, 7 Jul 2010 18:39:31 -0700 (PDT) Received: from 118-168-185-84.dynamic.hinet.net (118-168-185-84.dynamic.hinet.net [118.168.185.84]) by core3.amsl.com (Postfix) with ESMTP id D02A73A699D; Wed, 7 Jul 2010 18:39:30 -0700 (PDT) Message-ID: <000d01cb1e3e$698c7750$6400a8c0@menswearmf62> From: To: Subject: Get Harder, More Frequent Erections! Date: Thu, 8 Jul 2010 09:39:31 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam: Not detected ManXtenz Pills contain a patented combination of the very best male potency ingredients, many used for centuries to increase male sexual appetite, interest, and responsiveness! It includes two trademarked ingredients, Sustanol and Testostogen, that give what we like to call "the extra kick." Together, they create a powerful calibration designed to increase your body's natural production of nitric oxide, promote the dilation of blood vessels, producing harder, faster, longer erections, relax the muscle that allows blood to flow into the penis, and increase your testosterone production! Plus, it helps increase your feelings of pleasure by harnessing the power of L-Dopa, the natural amino acid that's used by your body to synthesize dopamine! http://plantsmoke.ru/?521451772phszzedmtv=ncr&9532 From pwg-announce-bounces@pwg.org Thu Jul 8 11:34:08 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED21D3A6B2C for ; Thu, 8 Jul 2010 11:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.998 X-Spam-Level: X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, 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 gJr76fYwbuhX for ; Thu, 8 Jul 2010 11:34:05 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 63BF33A6B38 for ; Thu, 8 Jul 2010 11:34:04 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 573D4791B2; Thu, 8 Jul 2010 14:33:53 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by pwg.org (Postfix) with ESMTP id AC8B4791A1 for ; Thu, 8 Jul 2010 14:33:46 -0400 (EDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 72463A2A88FD for ; Thu, 8 Jul 2010 11:33:45 -0700 (PDT) X-AuditID: 11807130-b7cd0ae00000795d-71-4c361a086bcd Received: from [17.151.124.111] (Unknown_Domain [17.151.124.111]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 83.9D.31069.90A163C4; Thu, 8 Jul 2010 11:33:45 -0700 (PDT) From: Michael Sweet Date: Thu, 8 Jul 2010 11:33:44 -0700 To: pwg-announce@pwg.org Message-Id: <4C747263-84C7-4902-83AA-D971D528D857@apple.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAQAAAZE= X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [Pwg-Announce] Reminder - NEW SURVEY: August 2010 Face-to-Face Meeting Page X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1125478158==" Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 573D4791B2.AC4C6 X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org --===============1125478158== Content-Type: multipart/alternative; boundary=Apple-Mail-9--340886227 --Apple-Mail-9--340886227 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, Just a friendly reminder that we have a new survey form for the August 2010= face-to-face meeting - please visit the page below and indicate which days= you will be attending or calling in so that MPI Tech can plan accordingly: http://www.surveymonkey.com/s/JDSZPXG ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Apple-Mail-9--340886227 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All,

Just a = friendly reminder that we have a new survey form for the August 2010 face-t= o-face meeting - please visit the page below and indicate which days you wi= ll be attending or calling in so that MPI Tech can plan accordingly:
   http:= //www.surveymonkey.com/s/JDSZPXG

___________________= _____________________________________________________
Michael Swe= et, Senior Printing System Engineer, PWG Chair





--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Apple-Mail-9--340886227-- --===============1125478158== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce --===============1125478158==-- From pwg-announce-bounces@pwg.org Fri Jul 9 10:11:00 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF633A69F6 for ; Fri, 9 Jul 2010 10:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 429H9cxIdlev for ; Fri, 9 Jul 2010 10:10:58 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 2156D3A69E3 for ; Fri, 9 Jul 2010 10:10:58 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 86AFD79257; Fri, 9 Jul 2010 13:10:56 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-gw.okidata.com (mail-gw.okidata.com [207.77.135.74]) by pwg.org (Postfix) with ESMTP id 3F93E79254; Fri, 9 Jul 2010 13:10:52 -0400 (EDT) In-Reply-To: <442723392.10286.1278104738927.JavaMail.root@sz0026a.westchester.pa.mail.comcast.net> To: wamwagner@comcast.net Subject: Re: [Pwg-Announce] Last Call - MFD Service Model Requirements MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.5.6 CCH4 June 18, 2008 Message-ID: From: Nancy.Chen@okidata.com Date: Fri, 9 Jul 2010 13:10:50 -0400 X-MIMETrack: Serialize by Router on ODA-SMTP-MTA/OKIDATA/OKI_DATA_CORP/OKI_ELECTRIC/US(Release 6.5.6FP3|March 27, 2008) at 07/09/2010 01:10:52 PM Content-Type: multipart/mixed; boundary="=_mixed 005E5FFB8525775B_=" X-pwg-MailScanner: Found to be clean, Found to be clean Cc: pwg-announce@pwg.org, pwg-announce-bounces@pwg.org X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 86AFD79257.AD8DD X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org --=_mixed 005E5FFB8525775B_= Content-Type: multipart/alternative; boundary="=_alternative 005E60028525775B_=" --=_alternative 005E60028525775B_= Content-Type: text/plain; charset="US-ASCII" Hi Bill, Here are some additional comments I have, some of which might overlap with Jerry's: Line 113-117 Table of Content Please resolve all the "ERROR! BOOKMARK NOT DEFINED " Terminology Section: DocumentData - the definition uses the term "Digital Document" which should also be defined in this section. JobTicket - should be removed, it's redundant here because JobTicket has all detailed definition for a JobTicket. Element (first occurrence) - should be removed. The second occurrence of this term has more detail and is consistent with what's in the current "MFD Overall" Section 5.2, first paragraph, line 383: Second sentence: Remove the first, duplicated "the" and replace with "of". Section 5.3.4.3, Processing Step 5: Remove "the" from "a the". Section 6.3.1, line 625: Remove "on" from "on in". Section 6.3.2, line 630: Is the "System" referring to the MFD System Object and Service, or simply the entire MFD system? If it's the MFD System Object and Servcie, we agreed in the last meeting that System object does not have job-oriented function. Let's change "Each Service and the System" to "Each Service in the System". Section 6.3.3, requirement #2: Remove "the" from "the a". Section 9, the 2nd sentence: I think it's better to change it to: "Future MFD services should consider the local site security policies for 1) the use of industry standard security protocols (e.g. WS-Security), 2) compliance to Industry securitiy standards for Imanging and Hardcopy Devices, in providing the desire level of MFD operational and information security. Regards, -Nancy -------------------------------------------------------------------------------------------------- Nancy Chen, PWG Vice-Chair Principal Engineer Solutions and Technology Oki Data 2000 Bishops Gate Blvd. Mt. Laurel, NJ 08054 Phone: (856)222-7006 Email: Nancy.Chen@okidata.com wamwagner@comcast.net Sent by: pwg-announce-bounces@pwg.org 07/02/2010 05:05 PM To pwg-announce@pwg.org cc Subject [Pwg-Announce] Last Call - MFD Service Model Requirements This is a reminder that the MFD Service Model Requirements document is in PWG last call, and that this last call nominally expires next week. Although this is a requirements document rather than a specification, failure to satisfy the PWG process on this document will act to stall progress on the multiple MFD Service specifications now being worked on. We sincerely request that members provide comments on this document or, if there are no comments, a simple statement that the document has been read. Many thanks, The MFD Working Group ----- Original Message ----- From: wamwagner@comcast.net To: pwg-announce@pwg.org Sent: Thursday, June 10, 2010 11:33:45 PM Subject: [Pwg-Announce] Last Call - MFD Service Model Requirements All, This is an announcement to begin the Last Call process for the "Multifunction Device Service Model Requirements" statement. This document is a "clear statement of requirements for the standard to be produced" and is required by the PWG Process ( ftp://ftp.pwg.org/pub/pwg/general/pwg-process-30.pdf) in conjunction with generating a standard. There will be, in fact, some ten MFD Service Model standards. Two of these have had the requirements statements incorporated in the standard and have already been advanced to PWG Candidate Standard. The MFD Working Group has decided that an integrated requirements statement would not only be more efficient, but would best reflect the consistent approach to modeling the different MFD imaging and ancillary services. The Last Call will close on Friday July 9. Please review this document, accessible at ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdreq10-20100609 and provide your comments (or statement of no comments) to the MFD mail list (mfd@pwg.org). As identified in the PWG Process Document, the "requirements statement is important as it leads to a clear, common understanding of the goals, provides a guide for developing the standard, and can be used as a final test to measure the completeness of the resulting specification." All comments will be addressed and resolved prior to the statement being put up for ballot. Note that PWG approval of this requirements statement is required before the remaining MFD specifications can be approved. Thanks, Bill Wagner/Peter Zehler -- This message has been scanned for viruses and dangerous content by MailScanner , and is believed to be clean. _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --=_alternative 005E60028525775B_= Content-Type: text/html; charset="US-ASCII"
Hi Bill,

Here are some additional comments I have, some of which might overlap with Jerry's:

Line 113-117 Table of Content
        Please resolve all the "ERROR! BOOKMARK NOT DEFINED "

Terminology Section:
        <service>DocumentData
                -  the definition uses the term "Digital Document" which should also be defined in this section.
        JobTicket
                - should be removed, it's redundant here because <service>JobTicket has all detailed definition for a JobTicket.
        Element (first occurrence)
                - should be removed. The second occurrence of this term has more detail and is consistent with what's in the current "MFD Overall"

Section 5.2, first paragraph, line 383:
        Second sentence: Remove the first, duplicated "the" and replace with "of".

Section 5.3.4.3, Processing Step 5:
        Remove "the" from "a the".

Section 6.3.1, line 625:
        Remove "on" from "on in".

Section 6.3.2, line 630:
        Is the "System" referring to the MFD System Object and Service, or simply the entire MFD system? If it's the MFD System Object and Servcie, we agreed in the last meeting that System object does not have job-oriented function. Let's change "Each Service and the System" to "Each Service in the System".

Section 6.3.3, requirement #2:
        Remove "the" from "the a".

Section 9, the 2nd sentence:
        I think it's better to change it to: "Future MFD services should consider the local site security policies for

        1) the use of industry standard security protocols (e.g. WS-Security),
        2) compliance to Industry securitiy standards for Imanging and Hardcopy Devices,
       
        in providing the desire level of MFD operational and information security.

Regards,
-Nancy
--------------------------------------------------------------------------------------------------
Nancy Chen, PWG Vice-Chair
Principal Engineer
Solutions and Technology
Oki Data
2000 Bishops Gate Blvd.
Mt. Laurel, NJ 08054
Phone: (856)222-7006
Email: Nancy.Chen@okidata.com




wamwagner@comcast.net
Sent by: pwg-announce-bounces@pwg.org

07/02/2010 05:05 PM

To
pwg-announce@pwg.org
cc
Subject
[Pwg-Announce] Last Call - MFD Service Model Requirements




This is a reminder that the MFD Service Model Requirements document is in PWG last call, and that this last call nominally expires next week. Although this is a requirements document rather than a specification, failure to satisfy the PWG process on this document will act to stall progress on the multiple MFD Service specifications now being worked on. We sincerely request that members provide comments on this document or, if there are no comments, a simple statement that the document has been read.

Many thanks,

The MFD Working Group


----- Original Message -----
From: wamwagner@comcast.net
To: pwg-announce@pwg.org
Sent: Thursday, June 10, 2010 11:33:45 PM
Subject: [Pwg-Announce] Last Call - MFD Service Model Requirements



All,


This is an announcement to begin the Last Call process for the "Multifunction Device Service Model Requirements" statement. This document is a "clear statement of requirements for the standard to be produced" and is required by the PWG Process (ftp://ftp.pwg.org/pub/pwg/general/pwg-process-30.pdf) in conjunction with generating a standard. There will be, in fact, some ten MFD Service Model standards. Two of these have had the requirements statements incorporated in the standard and have already been advanced to PWG Candidate Standard. The MFD Working Group has decided that an integrated requirements statement would not only be more efficient, but would best reflect the consistent approach to modeling the different MFD imaging and ancillary services. The Last Call will close on Friday July 9.



Please review this document, accessible at ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdreq10-20100609 and provide your comments (or statement of no comments) to the MFD mail list (mfd@pwg.org). As identified in the PWG Process Document, the "requirements statement is important as it leads to a clear, common understanding of the goals, provides a guide for developing the standard, and can be used as a final test to measure the completeness of the resulting specification." All comments will be addressed and resolved prior to the statement being put up for ballot. Note that PWG approval of this requirements statement is required before the remaining MFD specifications can be approved.

Thanks,

Bill Wagner/Peter Zehler

--
This message has been scanned for viruses and
dangerous content by MailScanner , and is
believed to be clean.
_______________________________________________
pwg-announce mailing list
pwg-announce@pwg.org
https://www.pwg.org/mailman/listinfo/pwg-announce

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



_______________________________________________
pwg-announce mailing list
pwg-announce@pwg.org
https://www.pwg.org/mailman/listinfo/pwg-announce



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --=_alternative 005E60028525775B_=-- --=_mixed 005E5FFB8525775B_= Content-Type: text/html; name="C.htm" Content-Disposition: attachment; filename="C.htm" Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Arial; font-size: 12pt; color: #000000'>This is a= reminder that the MFD Service Model Requirements document is in PWG last c= all, and that this last call nominally expires next week. Although this is = a requirements document rather than a specification, failure to satisfy the= PWG process on this document will act to stall progress on the multiple MF= D Service specifications now being worked on. We sincerely request that mem= bers provide comments on this document or, if there are no comments, a simp= le statement that the document has been read.

Many thanks,

Th= e MFD Working Group


----- Original Message -----
From: wamwag= ner@comcast.net
To: pwg-announce@pwg.org
Sent: Thursday, June 10, 201= 0 11:33:45 PM
Subject: [Pwg-Announce] Last Call - MFD Service Model Requ= irements


All,

Th= is is an announcement to begin the Last Call process for the "Multifunction= Device Service Model Requirements"   statement. This  document i= s a "clear statement of requirements for the standard to be produced" = and is required by the PWG Process (ftp://ftp.pwg.org/pub/pwg/general/pwg-= process-30.pdf) in conjunction with generating a standard. There will be, i= n fact, some ten MFD Service Model standards. Two of these have had the req= uirements statements incorporated in the standard and have already been adv= anced to PWG Candidate Standard. The MFD Working Group has decided that an = integrated requirements statement would not only be more efficient, but wou= ld best reflect the consistent approach to modeling the different MFD imagi= ng and ancillary services.  The Last Call will close on Friday July 9.=

Please review this document, accessible at&nb= sp; ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdreq10-20100609 and provide your = comments (or  statement of no comments) to the MFD mail list (mfd@pwg.= org). As identified in the  PWG Process Document,  the "requireme= nts statement is important as it leads to a clear, common understanding of = the goals, provides a guide for developing the standard, and can be used as= a final test to measure the completeness of the resulting specification." = All comments will be addressed and resolved prior to the statement being pu= t up for ballot. Note that PWG approval of this requirements statement is r= equired before the remaining MFD specifications can be approved.
 <= /div>
Thanks,


Bill Wagner/Peter Zehler

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
pwg-announce mailing= list
pwg-announce@pwg.org
https://www.pwg.org/mailman/listinfo/pwg-a= nnounce

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. = --=_mixed 005E5FFB8525775B_= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce --=_mixed 005E5FFB8525775B_=-- From ipp-bounces@pwg.org Mon Jul 12 12:55:48 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B52B3A680B for ; Mon, 12 Jul 2010 12:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 cz1Z9UFV4iPP for ; Mon, 12 Jul 2010 12:55:47 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 651E93A6BA3 for ; Mon, 12 Jul 2010 12:55:47 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 0CC4179295; Mon, 12 Jul 2010 15:55:45 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-vw0-f46.google.com (mail-vw0-f46.google.com [209.85.212.46]) by pwg.org (Postfix) with ESMTP id 7074879294 for ; Mon, 12 Jul 2010 15:55:39 -0400 (EDT) Received: by vws5 with SMTP id 5so5050478vws.5 for ; Mon, 12 Jul 2010 12:55: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:content-transfer-encoding; bh=aAcvMZkq2ZcZJJ+88Hbsb5DgKhERuVftFJ3YX1OPcWI=; b=PjfK0GIcu1gMsCBgJwDFs7VYK6Av/43+fXSpLZRFUUVuMZAlLwyYyZzVfweFzJ/j1F e7beuP/v0jZK1aVNiNT5Gi2CItYokTDE4vl+KNAFJuCMgKWzrYbmSnriiiRLyaW+wQ5D FymOVX+Z7w+Pl+vYeFL1FojVXLXd0L0rzUeuk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=giIOMeAsiQ5Ryj7xs7x+0PhCYtZbxo4XKswdXk6OmELOpNK3VskekXdA6hHsi1KvLG EEBnSAEwqJnc3Xmf3QJNyZ0oyZbNzmuFDswETRrRb4SHDKJ+IAh0nAIJsos160wZKikM 8A9hGSDOApa7wtSKIy/I2xEQlJJaBfxFy10Cg= MIME-Version: 1.0 Received: by 10.220.169.14 with SMTP id w14mr7199115vcy.17.1278964538211; Mon, 12 Jul 2010 12:55:38 -0700 (PDT) Received: by 10.220.182.13 with HTTP; Mon, 12 Jul 2010 12:55:38 -0700 (PDT) Date: Mon, 12 Jul 2010 15:55:38 -0400 Message-ID: From: Ira McDonald To: ipp@pwg.org, Michael R Sweet , Paul Tykodi , Ira McDonald , Tom Hastings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] IPP Agenda - 4pm EDT Monday 12 July 2010 (5 minutes!) X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 0CC4179295.A8CA0 X-pwg-MailScanner-From: ipp-bounces@pwg.org EEK! - Reminder of our next IPP WG call TODAY! Monday 12 July - 1-2pm PDT / 4-5pm EDT Call-in toll-free number (US/Canada): 1-866-469-3239 Call-in toll number (US/Canada): 1-650-429-3300 (Primary) Call-in toll number (US/Canada): 1-408-856-9570 (Backup) Attendee Access Code: *******# Attendee ID Code: # (empty) If you need the Attendee Access code, please email me a request. *** Main Objective - review updated IPP/2.0 SE *** Agenda: (1) PWG IP Policy and Minute Taker - Mike? (2) Approve IPP minutes from last meeting - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20100621.pdf (3) Review of IPP Version 2.0 Second Edition (Ira) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100527-rev.pdf (4) Status of PWG Formal Vote on IPP Everywhere Charter (Mike/Ira) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeverywhere-charter-20100610.pdf (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-clea= n.pdf (6) Next Steps - IPP Everywhere Charter Formal Vote - approval by PWG SC - IPP WG - Monday 26 July - IPP JPS2 into PWG Last Call? Cheers, - Ira (IPP co-editor) Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - TCG Hardcopy WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com winter: =A0 579 Park Place=A0 Saline, MI=A0 48176 =A0 734-944-0094 summer: =A0 PO Box 221=A0 Grand Marais, MI 49839 =A0 906-494-2434 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Mon Jul 12 13:07:30 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F853A67F7 for ; Mon, 12 Jul 2010 13:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lyg364DgHFja for ; Mon, 12 Jul 2010 13:07:28 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 2FEA73A6C56 for ; Mon, 12 Jul 2010 13:07:18 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id BA4AD792A2; Mon, 12 Jul 2010 16:07:22 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-vw0-f46.google.com (mail-vw0-f46.google.com [209.85.212.46]) by pwg.org (Postfix) with ESMTP id 7E4EF7929A for ; Mon, 12 Jul 2010 16:07:17 -0400 (EDT) Received: by vws5 with SMTP id 5so5064032vws.5 for ; Mon, 12 Jul 2010 13:07: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:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=8WrD8dUUWvDU+DZVJDxc1CF1KKFXI56daARIvgxrwwA=; b=u3RL561Yb3JtobBIiDYlJ37mUEjZfYZKtp+/ApojZ+pNfzsbOZDlP6VK69G/d1uAsX WrniDF/5nMjs3x1LVzhjjuN/L6rv7Uim86q5FLqGGWexpHDomrzn5qVwKKRR8hP0J4G6 +Zk4SEbX/+5dDZcYoQ4nLYLFjjxaUoKeKT2z4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=OGxaPKgNeyXh6/tGjdSNnYRly2BuZvK2qgR6xWJttTZ5TsOK+2clj5XiIA7pG0gYoF FszeUYnxLmPS0FxhHE/SmfOo00eWhhm7K2mvU1IKyaY6dG5KXbqE2ZhfjffK+rkcIMr/ Nca6gsEWLHcUCNYMxLSBFdle3vchFk99BGroE= MIME-Version: 1.0 Received: by 10.220.88.152 with SMTP id a24mr7175841vcm.129.1278965236714; Mon, 12 Jul 2010 13:07:16 -0700 (PDT) Received: by 10.220.182.13 with HTTP; Mon, 12 Jul 2010 13:07:16 -0700 (PDT) Date: Mon, 12 Jul 2010 16:07:16 -0400 Message-ID: From: Ira McDonald To: ipp@pwg.org, Michael R Sweet , Paul Tykodi , Ira McDonald , Tom Hastings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] CANCELED - IPP Agenda - 4pm EDT Monday 12 July 2010 (5 minutes!) X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: BA4AD792A2.A8FA0 X-pwg-MailScanner-From: ipp-bounces@pwg.org Hi, My apologies for failing to send the agenda last week. Since only Glen Petrie dialed in, we decided to cancel. We'll meet next week - agenda to follow momentarily. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - TCG Hardcopy WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com winter: =A0 579 Park Place=A0 Saline, MI=A0 48176 =A0 734-944-0094 summer: =A0 PO Box 221=A0 Grand Marais, MI 49839 =A0 906-494-2434 On Mon, Jul 12, 2010 at 3:55 PM, Ira McDonald wro= te: > EEK! - Reminder of our next IPP WG call TODAY! > > =A0Monday 12 July - 1-2pm PDT / 4-5pm EDT > > =A0Call-in toll-free number (US/Canada): 1-866-469-3239 > =A0Call-in toll number (US/Canada): 1-650-429-3300 (Primary) > =A0Call-in toll number (US/Canada): 1-408-856-9570 (Backup) > > =A0Attendee Access Code: *******# > =A0Attendee ID Code: # (empty) > > If you need the Attendee Access code, please email me a request. > > > *** Main Objective - review updated IPP/2.0 SE *** > > Agenda: > > (1) PWG IP Policy and Minute Taker > =A0- Mike? > > (2) Approve IPP minutes from last meeting > =A0- ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20100621= .pdf > > (3) Review of IPP Version 2.0 Second Edition (Ira) > =A0- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100527-rev.pdf > > (4) Status of PWG Formal Vote on IPP Everywhere Charter (Mike/Ira) > =A0- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeverywhere-charter-20100610.p= df > > (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July > =A0- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-= clean.pdf > > (6) Next Steps > =A0- IPP Everywhere Charter Formal Vote - approval by PWG SC > =A0- IPP WG - Monday 26 July > =A0- IPP JPS2 into PWG Last Call? > > Cheers, > - Ira (IPP co-editor) > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Co-Chair - TCG Hardcopy WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music/High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto:blueroofmusic@gmail.com > winter: > =A0 579 Park Place=A0 Saline, MI=A0 48176 > =A0 734-944-0094 > summer: > =A0 PO Box 221=A0 Grand Marais, MI 49839 > =A0 906-494-2434 > --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Mon Jul 12 13:12:17 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F3E3A6829 for ; Mon, 12 Jul 2010 13:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJbSMVWtJ+EK for ; Mon, 12 Jul 2010 13:12:15 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 67E5A3A680B for ; Mon, 12 Jul 2010 13:12:15 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 48A92792A9; Mon, 12 Jul 2010 16:12:13 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-vw0-f46.google.com (mail-vw0-f46.google.com [209.85.212.46]) by pwg.org (Postfix) with ESMTP id DD8AE7929A for ; Mon, 12 Jul 2010 16:12:07 -0400 (EDT) Received: by vws5 with SMTP id 5so5069622vws.5 for ; Mon, 12 Jul 2010 13:12:07 -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:content-transfer-encoding; bh=dQejyN/RChJx6wdiukXb41S46AfO4mSCGtc9g4wv8rA=; b=oJF/rKa1DMuqCKBC8fFvs/0CwQUHBYpdeEz2FNQhMgs3aeI8yUH29cYiC2oxQyzcoz F5swnfZGp4k2M6uacuYkUmSZu90Kf8voOUuhYxfZ+gt/4+zCsKba6wstJQzrnUijWv5j MiRE4+bNFsIHdU7/lapVdYpwYT962tmZ4ORCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=m7D4JvWCsYSc/v3t5hbYQiFAQn715Uyyw76fdjbnEFyyHh3aJcIfvbfqoj0VRkX00z U71Tq7FjMqcfMfM3NqnxAAVpGzVkMlXsWyiyWfn8UWSpjzgBtb+nfiTMCxNogC6EjU3h Kh0XsnAjVlZNb5IQuY9VRdZlWoh9FQimihrZM= MIME-Version: 1.0 Received: by 10.220.157.141 with SMTP id b13mr7059096vcx.167.1278965526611; Mon, 12 Jul 2010 13:12:06 -0700 (PDT) Received: by 10.220.182.13 with HTTP; Mon, 12 Jul 2010 13:12:06 -0700 (PDT) Date: Mon, 12 Jul 2010 16:12:06 -0400 Message-ID: From: Ira McDonald To: ipp@pwg.org, Michael R Sweet , Paul Tykodi , Tom Hastings , Ira McDonald Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] IPP Agenda - 4pm EDT Monday 19 July 2010 X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 48A92792A9.A9860 X-pwg-MailScanner-From: ipp-bounces@pwg.org Hi, [rescheduled from 12 July - apologies for missing agenda posting] Reminder of our next IPP WG call: Monday 19 July - 1-2pm PDT / 4-5pm EDT Call-in toll-free number (US/Canada): 1-866-469-3239 Call-in toll number (US/Canada): 1-650-429-3300 (Primary) Call-in toll number (US/Canada): 1-408-856-9570 (Backup) Attendee Access Code: *******# Attendee ID Code: # (empty) If you need the Attendee Access code, please email me a request. *** Main Objective - move IPP JPS2 into PWG Last Call *** Agenda: (1) PWG IP Policy and Minute Taker - Mike? (2) Approve IPP minutes from last meeting - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20100621.pdf (3) Status of IPP Version 2.0 Second Edition (Ira) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100527-rev.pdf (or later draft if available) (4) Status of PWG Formal Vote on IPP Everywhere Charter (Mike/Ira) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeverywhere-charter-20100610.pdf (ended Monday 12 July 2010) (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-clea= n.pdf (ended Monday 12 July 2010) (6) Next Steps - IPP WG - Monday 26 July - IPP JPS2 into PWG Last Call? Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - TCG Hardcopy WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com winter: =A0 579 Park Place=A0 Saline, MI=A0 48176 =A0 734-944-0094 summer: =A0 PO Box 221=A0 Grand Marais, MI 49839 =A0 906-494-2434 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Mon Jul 12 13:17:17 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3163F3A6C2E for ; Mon, 12 Jul 2010 13:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 5ImtCxzFudYn for ; Mon, 12 Jul 2010 13:17:16 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 8CABB3A6C85 for ; Mon, 12 Jul 2010 13:16:51 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id DF308792C2; Mon, 12 Jul 2010 16:16:56 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by pwg.org (Postfix) with ESMTP id 0CBF2792A9 for ; Mon, 12 Jul 2010 16:16:52 -0400 (EDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 991C79D2BF52; Mon, 12 Jul 2010 13:16:52 -0700 (PDT) X-AuditID: 11807134-b7b53ae000005755-c8-4c3b78340c1b Received: from da0704a-dhcp86.apple.com (da0704a-dhcp86.apple.com [17.197.43.86]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 27.94.22357.4387B3C4; Mon, 12 Jul 2010 13:16:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Michael Sweet In-Reply-To: Date: Mon, 12 Jul 2010 13:16:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ira McDonald X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAQAAAZE= X-pwg-MailScanner: Found to be clean, Found to be clean Cc: ipp@pwg.org Subject: [IPP] Re: CANCELED - IPP Agenda - 4pm EDT Monday 12 July 2010 (5 minutes!) X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: DF308792C2.A9873 X-pwg-MailScanner-From: ipp-bounces@pwg.org Yeah, for some reason I had the next meeting on my calendar for July 19th..= . I've updated the Google calendar accordingly... On Jul 12, 2010, at 1:07 PM, Ira McDonald wrote: > Hi, >=20 > My apologies for failing to send the agenda last week. > Since only Glen Petrie dialed in, we decided to cancel. >=20 > We'll meet next week - agenda to follow momentarily. >=20 > Cheers, > - Ira >=20 > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Co-Chair - TCG Hardcopy WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music/High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto:blueroofmusic@gmail.com > winter: > 579 Park Place Saline, MI 48176 > 734-944-0094 > summer: > PO Box 221 Grand Marais, MI 49839 > 906-494-2434 >=20 >=20 >=20 > On Mon, Jul 12, 2010 at 3:55 PM, Ira McDonald w= rote: >> EEK! - Reminder of our next IPP WG call TODAY! >>=20 >> Monday 12 July - 1-2pm PDT / 4-5pm EDT >>=20 >> Call-in toll-free number (US/Canada): 1-866-469-3239 >> Call-in toll number (US/Canada): 1-650-429-3300 (Primary) >> Call-in toll number (US/Canada): 1-408-856-9570 (Backup) >>=20 >> Attendee Access Code: *******# >> Attendee ID Code: # (empty) >>=20 >> If you need the Attendee Access code, please email me a request. >>=20 >>=20 >> *** Main Objective - review updated IPP/2.0 SE *** >>=20 >> Agenda: >>=20 >> (1) PWG IP Policy and Minute Taker >> - Mike? >>=20 >> (2) Approve IPP minutes from last meeting >> - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20100621.= pdf >>=20 >> (3) Review of IPP Version 2.0 Second Edition (Ira) >> - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100527-rev.pdf >>=20 >> (4) Status of PWG Formal Vote on IPP Everywhere Charter (Mike/Ira) >> - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeverywhere-charter-20100610.pdf >>=20 >> (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July >> - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-c= lean.pdf >>=20 >> (6) Next Steps >> - IPP Everywhere Charter Formal Vote - approval by PWG SC >> - IPP WG - Monday 26 July >> - IPP JPS2 into PWG Last Call? >>=20 >> Cheers, >> - Ira (IPP co-editor) >> Ira McDonald (Musician / Software Architect) >> Chair - Linux Foundation Open Printing WG >> Co-Chair - TCG Hardcopy WG >> IETF Designated Expert - IPP & Printer MIB >> Blue Roof Music/High North Inc >> http://sites.google.com/site/blueroofmusic >> http://sites.google.com/site/highnorthinc >> mailto:blueroofmusic@gmail.com >> winter: >> 579 Park Place Saline, MI 48176 >> 734-944-0094 >> summer: >> PO Box 221 Grand Marais, MI 49839 >> 906-494-2434 >>=20 ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Mon Jul 12 13:22:00 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EB813A69FC for ; Mon, 12 Jul 2010 13:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwtJxlJPdiJD for ; Mon, 12 Jul 2010 13:21:59 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 3992D3A68DC for ; Mon, 12 Jul 2010 13:21:56 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 9B54D792CD; Mon, 12 Jul 2010 16:21:58 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-vw0-f46.google.com (mail-vw0-f46.google.com [209.85.212.46]) by pwg.org (Postfix) with ESMTP id 36AA1792CD for ; Mon, 12 Jul 2010 16:21:54 -0400 (EDT) Received: by vws5 with SMTP id 5so5081076vws.5 for ; Mon, 12 Jul 2010 13:21:54 -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=11Xj/pwZRvcClOB2vIjgUVPWoDWlGgJ9ugwwgegwyRk=; b=WvoqKWc8Klf3Tg4gjT7tDdMjLg17dp2l3wNKxFMbniAmcdVdFba97kThw/Z0Dr0Xlx TOGGL/ZZKzv2qFTrdBhF+Yve4ziQkx8gruK9LiwBuVoHkl/KRgzc+6BbfyurgYSS5yqT 0unYM45bCpCSayC7v0HtVwXBMTN1Tm3U6kUhM= 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=CyimiJ2Nx9BPhg8kCwDaKNcr2D1pYzPs4Tq0rfKnUL6wNXu8w2A4SkfmxSSaIQNGwq u9WZmdi1vspJ2F1G4Y/XewnGwZbtam9msya3wqhHpWFpeXKwx7/bi5x5m9U/qUiIg7Ox 56QWEy1AopqxZooPCf/BYn4ZTrdcHlDqPLqnA= MIME-Version: 1.0 Received: by 10.220.124.40 with SMTP id s40mr7238222vcr.42.1278966114165; Mon, 12 Jul 2010 13:21:54 -0700 (PDT) Received: by 10.220.182.13 with HTTP; Mon, 12 Jul 2010 13:21:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Jul 2010 16:21:54 -0400 Message-ID: From: Ira McDonald To: Michael Sweet , Ira McDonald Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-pwg-MailScanner: Found to be clean, Found to be clean Cc: ipp@pwg.org Subject: [IPP] Re: CANCELED - IPP Agenda - 4pm EDT Monday 12 July 2010 (5 minutes!) X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 9B54D792CD.A8EF5 X-pwg-MailScanner-From: ipp-bounces@pwg.org Hi Mike, Thanks for updating the Google PWG calendar. I was just going to do so. A later starting date for PWG Last Call of IPP JPS2 (to span August PWG F2F) is probably better anyway. I'll try to get out an updated IPP/2.0 SE draft by next Monday. I'm also close to a PWG-only draft of IPPS URL Scheme I-D. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - TCG Hardcopy WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com winter: =A0 579 Park Place=A0 Saline, MI=A0 48176 =A0 734-944-0094 summer: =A0 PO Box 221=A0 Grand Marais, MI 49839 =A0 906-494-2434 On Mon, Jul 12, 2010 at 4:16 PM, Michael Sweet wrote: > Yeah, for some reason I had the next meeting on my calendar for July 19th= ... =A0I've updated the Google calendar accordingly... > > On Jul 12, 2010, at 1:07 PM, Ira McDonald wrote: > >> Hi, >> >> My apologies for failing to send the agenda last week. >> Since only Glen Petrie dialed in, we decided to cancel. >> >> We'll meet next week - agenda to follow momentarily. >> >> Cheers, >> - Ira >> >> Ira McDonald (Musician / Software Architect) >> Chair - Linux Foundation Open Printing WG >> Co-Chair - TCG Hardcopy WG >> IETF Designated Expert - IPP & Printer MIB >> Blue Roof Music/High North Inc >> http://sites.google.com/site/blueroofmusic >> http://sites.google.com/site/highnorthinc >> mailto:blueroofmusic@gmail.com >> winter: >> =A0 579 Park Place =A0Saline, MI =A048176 >> =A0 734-944-0094 >> summer: >> =A0 PO Box 221 =A0Grand Marais, MI 49839 >> =A0 906-494-2434 >> >> >> >> On Mon, Jul 12, 2010 at 3:55 PM, Ira McDonald = wrote: >>> EEK! - Reminder of our next IPP WG call TODAY! >>> >>> =A0Monday 12 July - 1-2pm PDT / 4-5pm EDT >>> >>> =A0Call-in toll-free number (US/Canada): 1-866-469-3239 >>> =A0Call-in toll number (US/Canada): 1-650-429-3300 (Primary) >>> =A0Call-in toll number (US/Canada): 1-408-856-9570 (Backup) >>> >>> =A0Attendee Access Code: *******# >>> =A0Attendee ID Code: # (empty) >>> >>> If you need the Attendee Access code, please email me a request. >>> >>> >>> *** Main Objective - review updated IPP/2.0 SE *** >>> >>> Agenda: >>> >>> (1) PWG IP Policy and Minute Taker >>> =A0- Mike? >>> >>> (2) Approve IPP minutes from last meeting >>> =A0- ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-201006= 21.pdf >>> >>> (3) Review of IPP Version 2.0 Second Edition (Ira) >>> =A0- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100527-rev.pdf >>> >>> (4) Status of PWG Formal Vote on IPP Everywhere Charter (Mike/Ira) >>> =A0- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeverywhere-charter-20100610= .pdf >>> >>> (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July >>> =A0- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-2010060= 6-clean.pdf >>> >>> (6) Next Steps >>> =A0- IPP Everywhere Charter Formal Vote - approval by PWG SC >>> =A0- IPP WG - Monday 26 July >>> =A0- IPP JPS2 into PWG Last Call? >>> >>> Cheers, >>> - Ira (IPP co-editor) >>> Ira McDonald (Musician / Software Architect) >>> Chair - Linux Foundation Open Printing WG >>> Co-Chair - TCG Hardcopy WG >>> IETF Designated Expert - IPP & Printer MIB >>> Blue Roof Music/High North Inc >>> http://sites.google.com/site/blueroofmusic >>> http://sites.google.com/site/highnorthinc >>> mailto:blueroofmusic@gmail.com >>> winter: >>> =A0 579 Park Place =A0Saline, MI =A048176 >>> =A0 734-944-0094 >>> summer: >>> =A0 PO Box 221 =A0Grand Marais, MI 49839 >>> =A0 906-494-2434 >>> > > ________________________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > > > > --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ZHPeng@ntu.edu.sg Wed Jul 14 18:32:32 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4313A69F0 for ; Wed, 14 Jul 2010 18:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, 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 ATVkM9WIiLTw for ; Wed, 14 Jul 2010 18:32:32 -0700 (PDT) Received: from exsmtp3.ntu.edu.sg (exsmtp3.ntu.edu.sg [155.69.5.168]) by core3.amsl.com (Postfix) with ESMTP id 681D03A69D8 for ; Wed, 14 Jul 2010 18:32:30 -0700 (PDT) Received: from EXCHHUB2.staff.main.ntu.edu.sg (155.69.24.24) by EXSMTP3.staff.main.ntu.edu.sg (155.69.5.168) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 15 Jul 2010 09:32:39 +0800 Received: from EXCHANGE31.staff.main.ntu.edu.sg ([fe80::c4ae:393c:56a9:4a7f]) by EXCHHUB2.staff.main.ntu.edu.sg ([2002:9b45:1818::9b45:1818]) with mapi; Thu, 15 Jul 2010 09:32:34 +0800 From: Peng Zhihong Date: Thu, 15 Jul 2010 09:32:33 +0800 Subject: Dear Brethren Thread-Topic: Dear Brethren Thread-Index: AQHLI72Z2yMgcOgA50GBbN12CGbMUg== Message-ID: Accept-Language: en-US, en-SG Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-SG Content-Type: multipart/alternative; boundary="_000_CB3ABCBF601D514CBC6CD9BCC99EC1F4191A586569EXCHANGE31sta_" MIME-Version: 1.0 To: Undisclosed recipients:; --_000_CB3ABCBF601D514CBC6CD9BCC99EC1F4191A586569EXCHANGE31sta_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Although, I am not comfortable discussing the content of my mail on the int= ernet owing to lots of unsolicited/Spam mails on the net these days. Anyway my message = is that I have made up my mind to will my late Husband's funds to you so that you ca= n use it for charity duties and good work to humanity in your country. The amount is 4= million Dollars. Please get back to me on my personal and secured email address fo= r further information. My secured email is: zhihongh2@gmail.com God bless you. Mrs. Zhihong Hannah Peng. --_000_CB3ABCBF601D514CBC6CD9BCC99EC1F4191A586569EXCHANGE31sta_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Althoug= h, I am not comfortable discussing the content of my mail on the internet o= wing
to lots= of unsolicited/Spam mails on the net these days. Anyway my message is that= I
have ma= de up my mind to will my late Husband's funds  to you so that you can = use it for
charity=   duties and good work to humanity  in your country. The amount i= s 4million
Dollars= . Please get back to me on my personal and secured email  address for = further
informa= tion.
My secured email is: zhihongh2@gmail= .com
God ble= ss you.
Mrs. Zhihong Hannah Peng.
=  
--_000_CB3ABCBF601D514CBC6CD9BCC99EC1F4191A586569EXCHANGE31sta_-- From pwg-announce-bounces@pwg.org Fri Jul 16 22:56:49 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D5F3A6853 for ; Fri, 16 Jul 2010 22:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 dZDjDazxGDD6 for ; Fri, 16 Jul 2010 22:56:47 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 50E463A66B4 for ; Fri, 16 Jul 2010 22:56:47 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 50F6F792B8; Sat, 17 Jul 2010 01:56:50 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by pwg.org (Postfix) with ESMTP id E748F792A7 for ; Sat, 17 Jul 2010 01:56:45 -0400 (EDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o6H5ujGI016990 for ; Sat, 17 Jul 2010 01:56:45 -0400 Authentication-Results: cm-omr8 smtp.user=ptykodi; auth=pass (LOGIN) Received: from [65.96.244.16] ([65.96.244.16:33739] helo=TCSLAPTOP01) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 15/23-13312-A16414C4; Sat, 17 Jul 2010 01:56:45 -0400 From: "Paul Tykodi" To: Date: Sat, 17 Jul 2010 01:56:41 -0400 Organization: Tykodi Consulting Services LLC Message-ID: <93F70333CCA54C8FA5116E111E44C89F@TCSLAPTOP01> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: AcsldNCvrA7cxGkFRL6sin4ax31w1w== X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [Pwg-Announce] PWG approved IPP Everywhere Project Charter (12 July 2010) X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ptykodi@tykodi.com List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 50F6F792B8.ABB4E X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org Greetings, I am pleased to announce that the IPP Everywhere Project Charter has been formally approved and is now archived at: ftp://ftp.pwg.org/pub/pwg/ipp/charter/ch-ippeverywhere-charter-20100712.pdf The voting results were: 12 - YES 1 - NO without Strong Objection 2 - ABSTAIN Best Regards, - Paul Tykodi (PWG Secretary) ------------------------------------ Tykodi Consulting Services LLC Paul Tykodi Principal Consultant ptykodi@tykodi.com 3 Lowell Ave. Dover, NH 03820-2705 tel: (603) 343-1820 ------------------------------------ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce From ipp-bounces@pwg.org Sun Jul 18 09:05:50 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDBFA3A6809 for ; Sun, 18 Jul 2010 09:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=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 ftken9qQDpIK for ; Sun, 18 Jul 2010 09:05:49 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 5BB233A6979 for ; Sun, 18 Jul 2010 09:05:49 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 616EC7922D; Sun, 18 Jul 2010 12:05:53 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-vw0-f46.google.com (mail-vw0-f46.google.com [209.85.212.46]) by pwg.org (Postfix) with ESMTP id 17240791A1 for ; Sun, 18 Jul 2010 12:05:48 -0400 (EDT) Received: by vws5 with SMTP id 5so4214028vws.5 for ; Sun, 18 Jul 2010 09:05:48 -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:content-type :content-transfer-encoding; bh=Stan36QOKyO4xcd6ebA6sXG+YYpbDe9yvjDFeJlmb8I=; b=h4JmnyDPGLJXgFlZUOaK3IzEj5T4XuLe4k0cvVZGGIUEB3RFGuJsReEfvm2jOqHaUC 9fFPKl6y1FY3XFm578UmcmC1eLj/ECQTd5Fof5fyHJacgDEBYLqK5B9j5lxisk2+UnUl 8IR30X5JQaszM/18uZmE5kk13r4lKavxEcNd0= 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 :content-type:content-transfer-encoding; b=f8r4byc2BoZFwlwBSlgVaPibEWz43z1vMxXQ5JnuOvgJezY/AMjg+bW4Nqe0tr9Bwi zwzkGnF5uz96C+c1Wf8WwtjzekBKoyCjznal8X5o3YHe7Bd0IN1GvlloRrCe+ez+J0NB Y+qhHowomZRs2ePFA8vM3IHpxx4IrVl6fusj4= MIME-Version: 1.0 Received: by 10.220.122.71 with SMTP id k7mr1978572vcr.117.1279469147719; Sun, 18 Jul 2010 09:05:47 -0700 (PDT) Received: by 10.220.78.25 with HTTP; Sun, 18 Jul 2010 09:05:47 -0700 (PDT) In-Reply-To: References: Date: Sun, 18 Jul 2010 12:05:47 -0400 Message-ID: From: Ira McDonald To: ipp@pwg.org, Michael R Sweet , Paul Tykodi , Tom Hastings , Ira McDonald Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] Re: IPP Agenda - 4pm EDT Monday 19 July 2010 X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 616EC7922D.A9133 X-pwg-MailScanner-From: ipp-bounces@pwg.org Hi, REMINDER of tomorrow's IPP WG telecon Cheers, - Ira On Mon, Jul 12, 2010 at 4:12 PM, Ira McDonald wro= te: > Hi, > > [rescheduled from 12 July - apologies for missing agenda posting] > > Reminder of our next IPP WG call: > > =A0Monday 19 July - 1-2pm PDT / 4-5pm EDT > > =A0Call-in toll-free number (US/Canada): 1-866-469-3239 > =A0Call-in toll number (US/Canada): 1-650-429-3300 (Primary) > =A0Call-in toll number (US/Canada): 1-408-856-9570 (Backup) > > =A0Attendee Access Code: *******# > =A0Attendee ID Code: # (empty) > > If you need the Attendee Access code, please email me a request. > > > *** Main Objective - move IPP JPS2 into PWG Last Call *** > > Agenda: > > (1) PWG IP Policy and Minute Taker > =A0- Mike? > > (2) Approve IPP minutes from last meeting > =A0- ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20100621= .pdf > > (3) Status of IPP Version 2.0 Second Edition (Ira) > =A0- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100527-rev.pdf > =A0 (or later draft if available) > > (4) Status of PWG Formal Vote on IPP Everywhere Charter (Mike/Ira) > =A0- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeverywhere-charter-20100610.p= df > =A0 (ended Monday 12 July 2010) > > (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July > =A0- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-= clean.pdf > =A0 (ended Monday 12 July 2010) > > (6) Next Steps > =A0- IPP WG - Monday 26 July > =A0- IPP JPS2 into PWG Last Call? > > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Co-Chair - TCG Hardcopy WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music/High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto:blueroofmusic@gmail.com > winter: > =A0 579 Park Place=A0 Saline, MI=A0 48176 > =A0 734-944-0094 > summer: > =A0 PO Box 221=A0 Grand Marais, MI 49839 > =A0 906-494-2434 > --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Sun Jul 18 12:56:41 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1303F3A67EC for ; Sun, 18 Jul 2010 12:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 1OBIBmEI3cl1 for ; Sun, 18 Jul 2010 12:56:26 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id BEAAC3A684F for ; Sun, 18 Jul 2010 12:56:25 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 7B2F579254; Sun, 18 Jul 2010 15:56:17 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by pwg.org (Postfix) with ESMTP id 54B7979251 for ; Sun, 18 Jul 2010 15:56:07 -0400 (EDT) Received: from FamilyRoom ([unknown] [173.60.208.25]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L5R006MVRCSZ0H1@vms173003.mailsrvcs.net> for ipp@pwg.org; Sun, 18 Jul 2010 14:55:47 -0500 (CDT) From: "Tom Hastings" To: , "'Michael R Sweet'" , "'Paul Tykodi'" , "'Ira McDonald'" References: Date: Sun, 18 Jul 2010 12:55:40 -0700 Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="----=_NextPart_000_0084_01CB2678.89476680" X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-index: Acsmkxcchw5KazPoQxemxyenFdQB9AAFWo5Q In-reply-to: X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Gary Brown , Daniel Manchala , Daniel Bell Subject: [IPP] Toward resolving Apple's IPP WG Last Call comment on changing the units for "font-size-requested" from points to decipoints X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tom.hastings@alum.mit.edu List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 7B2F579254.AC49E X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. ------=_NextPart_000_0084_01CB2678.89476680 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0085_01CB2678.89476680" ------=_NextPart_001_0085_01CB2678.89476680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Since the font, highlighting, and indentation will be smashed when this mail message is turned to plain text, I've attached a 47 KB .pdf which is much more readable, complete with line numbers to make it easier to discuss at the telecon. For the IPP WG telecon, tomorrow, Monday, July 19, here is input for the agenda topic: > (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July > - > ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-cl > ean.pdf > (ended Monday 12 July 2010) > > (6) Next Steps > - IPP WG - Monday 26 July > - IPP JPS2 into PWG Last Call? Apple had made the following IPP WG Last Call comment: 2. The "font-size-requested" attribute uses points as the units, however it should probably use a higher-precision unit (at least decipoints, or 1/720th of an inch) to avoid issues with getting common fixed-width font spacing right (e.g. 17 characters per inch with a standard Courier font would need a point size of 5.293...) [And apologies for the late notice on this - I haven't read through the older material in a while...] I had the action item to contact Xerox about whether or not it had implemented the "font-size-requested" based on the draft submitted to the PWG in 2002. I had suggested the following possible alternatives to Xerox: If Xerox hasn't really implemented the "font-size-requested" Job Template attribute, Xerox should just agree to make the units be decipoints. However, if Xerox has implemented the "font-size-requested" Job Template attribute, what should the PWG do? Alternatives: 1. Xerox could argue that for real printing, the font size is specified in the document data, NOT in the IPP protocol. In the document data, the size of the font can be specified in finer units than points. So as the description says, this attribute is only used with 'text/plain', or 'text/html' (when there is no font size specified in the html), so the need for higher precision is not really needed. 2. Xerox could change its implementation. 3. Xerox could keep its implementation and ignore the PWG IPP standard in this respect. 4. Xerox could make it an installation option or configurable setting whether the Printer uses points or decipoints for this attribute. 5. Add a Printer attribute to the PWG spec that says what the units are for "font-size-requested", say, "font-size-requested-units" (type2 keyword) = 'points', 'decipoints'. If "font-size-requested-units" is NOT supported, clients MUST assume the units are: 'decipoints'. 6. Add a Printer attribute to the PWG spec that says what the units are for "font-size-requested", say, "font-size-requested-units" (type2 keyword) = 'points', 'decipoints'. If "font-size-requested-units" is NOT supported, clients MUST assume the units are: 'points'. Any other suggestions? The IPP WG Last Call comment period has been extended from June 21 (today), to Friday July 9, so we have a little time to decide what to do and what to recommend to the PWG. Thanks, Tom Dan Bell responded that Xerox had a long standing implementation and would be unlikely to change its implementation. He indicated his alternatives in order of decreasing desirability, including adding an additional suggestion #3 below: Tom, Thanks for the insights. Xerox HAS implemented support for "font-size-requested", and it's been in existence for a long time. I don't know how extensively it's used, but it's there. I would say it's highly unlikely that Xerox would be willing to change its long-time existing implementation at this point. For the proposed options of adding a "font-size-requested-units" attribute, another option would be to make it a job-template attribute and have it passed in the job along with "font-size-requested". Then a "font-size-requested-units-supported" attribute could advertise what the printer supports. And if a job is submitted with no "font-size-requested-units" then either the device assumes it's points, or uses the "font-size-requested-units-default" value. In my opinion the acceptable options, in order of preference, would be: 1. Xerox could argue that for real printing, the font size is specified in the document data, NOT in the IPP protocol. In the document data, the size of the font can be specified in finer units than points. So as the description says, this attribute is only used with 'text/plain', or 'text/html' (when there is no font size specified in the html), so the need for higher precision is not really needed. 2. Add a Printer attribute to the PWG spec that says what the units are for "font-size-requested", say, "font-size-requested-units" (type2 keyword) = 'points', 'decipoints'. If "font-size-requested-units" is NOT supported, clients MUST assume the units are: 'points'. 3. Add a Job template attribute to the PWG spec that what the units are for "font-size-requested" for the job, say, "font-size-requested-units" (type2 keyword) = 'points', 'decipoints'. If "font-size-requested-units-supported" is NOT supported on the Printer, clients MUST assume the units are: 'points'. If the job does not contain "font-size-requested-units", the Printer's default value is used. 4. Xerox could keep its implementation and ignore the PWG IPP standard in this respect. To further support alternative #1, I urge the IPP WG to remember that the very few "xxx-requested" Job Template attributes are ones that request the Printer to do something, as long as the document data is silent on that feature. If the document data does specify something, then the document data takes precedence. The "font-size-requested" is one of the 3 Job Template attributes whose precedence is lower than the document data. Others are "font-name-requested" [JPS2] and "orientation-requested" [RFC2911]. So the question is how likely is it that an application generates document data in which it can supply font size in the data but fails to do so? Or how likely is it that a user (1) received such a document or (2) received a plain text document from somewhere that the user wants to specify the font to a size more precisely than one point? Here is the current full text of the "font-size-requested" Job Template attribute which clearly describes these lower precedence attributes which are intended only for text/plain and text/html document formats or situations where the application could not or did not include the font size in the document data: 7.3 font-size-requested (integer (1:MAX)) 7.3.1 font-size-requested-default (integer (1:MAX)) 7.3.2 font-size-requested-supported (1setOf rangeOfInteger (1:MAX)) The OPTIONAL "font-size-requested" Job Template attribute enables an IPP client to specify what default font size the printer MUST use to print a job if the document data is in a format that does not have inherent font information (e.g., 'text/plain'). For document formats which have inherent font information (such as PostScript), this attribute will be ignored and will NOT override that information. For some document formats (such as 'application/postscript'), the desired default font size of the print-stream pages is specified within the document data. This information is generated by a device driver prior to the submission of the print job. Other document formats (such as 'text/plain') do not include the notion of desired font size within the document data. In the latter case it is possible for the Printer object to bind the desired font size to the document data after it has been submitted. It is expected that a Printer object would only support "font-size-requested" for some document formats (e.g., 'text/plain' or 'text/html') but not others (e.g., 'application/postscript'). This PDL-dependent behavior is no different than any other Job Template attribute since a Printer object may support or not support any Job Template attribute based on the document format supplied by the client. However, a special mention is made here since it is very likely that a Printer object will support "font-size-requested" for only a subset of the supported document formats. The "font-size-requested" units are points, equivalent to 1/72nd of an inch. This attribute can be specified as a Document Override that affects the Input-Document. The use of this attribute on a Page override basis is not supported since changing the font characteristics can affect the pagination. NOTE: The use of the "xxx-requested" pattern for attribute names indicates that the value of the attribute is to be used ONLY in the case when a value for the attribute is not contained within the source document. This value will override the printer's default value but will not override the source document's value. See the description of the "orientation-requested" Job Template attribute in [RFC2911]. At the meeting tomorrow and/or on the mail list, the IPP WG needs to consider the alternatives for resolving Apple's IPP WG Last Call comment. Thanks, Tom -----Original Message----- From: Ira McDonald [mailto:blueroofmusic@gmail.com] Sent: Sunday, July 18, 2010 09:06 To: ipp@pwg.org; Michael R Sweet; Paul Tykodi; Tom Hastings; Ira McDonald Subject: Re: IPP Agenda - 4pm EDT Monday 19 July 2010 Hi, REMINDER of tomorrow's IPP WG telecon Cheers, - Ira On Mon, Jul 12, 2010 at 4:12 PM, Ira McDonald wrote: > Hi, > > [rescheduled from 12 July - apologies for missing agenda posting] > > Reminder of our next IPP WG call: > > Monday 19 July - 1-2pm PDT / 4-5pm EDT > > Call-in toll-free number (US/Canada): 1-866-469-3239 > Call-in toll number (US/Canada): 1-650-429-3300 (Primary) > Call-in toll number (US/Canada): 1-408-856-9570 (Backup) > > Attendee Access Code: *******# > Attendee ID Code: # (empty) > > If you need the Attendee Access code, please email me a request. > > > *** Main Objective - move IPP JPS2 into PWG Last Call *** > > Agenda: > > (1) PWG IP Policy and Minute Taker > - Mike? > > (2) Approve IPP minutes from last meeting > - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20100621.pdf > > (3) Status of IPP Version 2.0 Second Edition (Ira) > - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100527-rev.pdf > (or later draft if available) > > (4) Status of PWG Formal Vote on IPP Everywhere Charter (Mike/Ira) > - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeverywhere-charter-20100610.pdf > (ended Monday 12 July 2010) > > (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July > - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-clean.pd f > (ended Monday 12 July 2010) > > (6) Next Steps > - IPP WG - Monday 26 July > - IPP JPS2 into PWG Last Call? > > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Co-Chair - TCG Hardcopy WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music/High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto:blueroofmusic@gmail.com > winter: > 579 Park Place Saline, MI 48176 > 734-944-0094 > summer: > PO Box 221 Grand Marais, MI 49839 > 906-494-2434 > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_NextPart_001_0085_01CB2678.89476680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since the font, highlighting, and indentation will be smashed when this mail message is tur= ned to plain text, I’ve attached a 47 KB .pdf which is much more readable, complete with line numbers to make it easier to discuss at the telecon.

 

For the IPP WG tele= con, tomorrow, Monday, July 19, here is input for the agenda topic:

 

> (5) Status of IPP WG Last Call on IPP JPS2 = (Tom) - ends Monday 12 July

>  -

> ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-cl=

> ean.pdf

>   (ended Monday 12 July 2010)

> 

> (6) Next Steps

>  - IPP WG - Monday 26 July<= /span>

>  - IPP JPS2 into PWG Last Call?

 

Apple had made the following IPP WG Last Call comment:

 

2. The "font-size-requested" attribute= uses points as the units, however it should probably use a higher-precision unit= (at least decipoints, or 1/720th of an inch) to avoid issues with getting common fixed-width font spacing right (e.g. 17 characters per inch with a standard Courier font would need a point size of 5.293...) [And apologies for the la= te notice on this - I haven't read through the older material in a while...]

 

 

I had the action it= em to contact Xerox about whether or not it had implemented the “font-size-= requested” based on the draft submitted to the PWG in 2002.  I had suggested the following possible alternatives to Xerox:

 

If Xerox hasn’t really implemented the “font-size-requested”= Job Template attribute, Xerox should just agree to make the units be decipoints= .

<= o:p> 

H= owever, if Xerox has implemented the “font-size-requested” Job Template attribute, what should the PWG do?  Alternatives:

<= o:p> 

1.      = Xerox could argue that for real printing, the font size is specified in the document data, NOT in the IPP protocol. = In the document data, the size of the font can be specified in finer units than points.  So as the description says, this attribute is only used with ‘text/plain’, or ‘text/html’ (when there is no font size specified in the html), so the need for higher precision is not really needed. =

<= o:p> 

2.      = Xerox could change its implementation.=

<= o:p> 

3.      = Xerox could keep its implementation and ignore the PWG IPP standard in this respect. <= o:p>

<= o:p> 

4.      = Xerox could make it an installation option or configurable setting whether the Printer uses points or decipoints for this attribute.

 

5.      = Add a Printer attribute to the PWG spec that = says what the units are for “font-size-requested”, say, “font-size-requested-units” (type2 keyword) =3D ‘points&#= 8217;, ‘decipoints’.  If “font-size-requested-units” = is NOT supported, clients MUST assume the units are: ‘decipoints’.=

<= o:p> 

6.      = Add a Printer attribute to the PWG spec that = says what the units are for “font-size-requested”, say, “font-size-requested-units” (type2 keyword) =3D ‘points&#= 8217;, ‘decipoints’.  If “font-size-requested-units” = is NOT supported, clients MUST assume the units are: ‘points’.

 

A= ny other suggestions?<= /font>

 

The IPP WG Last Call comment period has been extended from June 21 (today), to Friday July 9, so we have a little time = to decide what to do and what to recommend to the PWG.

 

Thanks,<= /span>

Tom

 

 

 

Dan Bell responded = that Xerox had a long standing implementation and would be unlikely to change its implementation.  He indicated his alternatives in order of decreasing = desirability, including adding an additional suggestion #3 below:

 

Tom,

 

Thanks for the insi= ghts.

 

Xerox HAS implement= ed support for “font-size-requested”, and it’s been in exist= ence for a long time.  I don’t know how extensively it’s used, = but it’s there.

 

I would say it̵= 7;s highly unlikely that Xerox would be willing to change its long-time existing implementation at this point.

 

For the proposed op= tions of adding a “font-size-requested-units” attribute, another opti= on would be to make it a job-template attribute and have it passed in the job along with “font-size-requested”.  Then a “font-size-requested-units-supported” attribute could advertise what the printer supports.  And if a job is submitted with no “font-size-requested-units” then either the device assumes it’s points, or uses the “font-size-requested-units-defaultR= 21; value.

 

In my opinion the acceptable options, in order of preference, would be:

 

1.      = Xerox could argue that for real printing, the font size is specified in the document data, NOT in the IPP protocol. = In the document data, the size of the font can be specified in finer units than points.  So as the description says, this attribute is only used with ‘text/plain’, or ‘text/html’ (when there is no font size specified in the html), so the need for higher precision is not really needed. =

2.      = Add a Printer attribute to the PWG spec that = says what the units are for “font-size-requested”, say, “font-size-requested-units” (type2 keyword) =3D ‘points&#= 8217;, ‘decipoints’.  If “font-size-requested-units” = is NOT supported, clients MUST assume the units are: ‘points’.

3.      = Add a Job template attribute to the PWG spec that what the units are for “font-size-requested” for the job, = say, “font-size-requested-units” (type2 keyword) =3D ‘points&#= 8217;, ‘decipoints’.  If “font-size-requested-units-support= ed” is NOT supported on the Printer, clients MUST assume the units are: ‘points’.  If the job does not contain “font-size-requested-units”, the Printer’s default value = is used.

4.      = Xerox could keep its implementation and ignore the PWG IPP standard in this respect. <= o:p>

 

 

 

To further support alternative #1, I urge the IPP WG to remember that the very few “xxx-= requested” Job Template attributes are ones that request the Printer to do something, = as long as the document data is silent on that feature.  If the document = data does specify something, then the document data takes precedence.  The = “font-size-requested” is one of the 3 Job Template attributes whose precedence is lower than the document data.  = Others are “font-name-requested” [JPS2] and “orientation-request= ed” [RFC2911]. 

 

So the question is = how likely is it that an application generates document data in which it can su= pply font size in the data but fails to do so?

Or how likely is it= that a user (1) received such a document or (2) received a plain text document f= rom somewhere that the user wants to specify the font to a size more precisely = than one point?

 

Here is the current= full text of the “font-size-requested” Job Template attribute which clearly describes these lower precedence attributes which are intended only= for text/plain and text/html document formats or situations where the applicati= on could not or did not include the font size in the document data:

7.3             font-size-requested  (integer (1:MAX))

7.3.1       font-size-requested-defaul= t  (integer (1:MAX))

7.3.2       font-size-requested-suppor= ted  (1setOf rangeOfInteger (1:MAX))

The OPTIONAL "font-size-requested" Job Template attribute enables an IPP client to specify what default font size = the printer MUST use to print a job if the document data is in a format that do= es not have inherent font information (e.g., ‘text/plain’).  = For document formats which have inherent font information (such as PostScript), this attribute will be ignored and will NOT override that information.=

For some document formats (such as 'application/postscript'), the desired default font size of the print-stream pages is specified within the document data.  This information is generated by a device driver prior to the submission of the print job.  Other document formats (such as 'text/plain') do not include the notion of desired font size within the document data.  In the latter case it is possible for the Printer object to bind the desired font size to the docume= nt data after it has been submitted.  It is expected that a Printer object would only support "font-size-requested" for some document formats (e.g., 'text/plain' or 'text/html') but not others (e.g., 'application/postscript').  This PDL-dependent behavior is no different than any other Job Template attribute since a Printer object may support or= not support any Job Template attribute based on the document format supplied by= the client.  However, a special mention is made here since it is very like= ly that a Printer object will support "font-size-requested" for only= a subset of the supported document formats.

The “font-size-requested” units are points, equivalent to 1/72nd of an inch.

This attribute can be specified as a Document Ov= erride that affects the Input-Document.  The use of this attribute on a Page override basis is not supported since changing the font characteristics can affect the pagination.

NOTE:  The use of the “xxx-requested&= #8221; pattern for attribute names indicates that the value of the attribute is to= be used ONLY in the case when a value for the attribute is not contained within the source document.  This value will override the printer’s def= ault value but will not override the source document’s value.  See the description of the “orientation-requested” Job Template attribu= te in [RFC2911].

At the meeting tomo= rrow and/or on the mail list, the IPP WG needs to consider the alternatives for resolving Apple’s IPP WG Last Call comment.<= /p>

 

Thanks,<= /span>

Tom

 

 

 

-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic@gmail.com]
Sent: Sunday, July 18, 2010 09:06
To: ipp@pwg.org; Michael R Sweet; Paul Tykodi; Tom Hastings; Ira McDonald
Subject: Re: IPP Agenda - 4pm EDT Monday 19 July 2010

 

Hi,

 

REMINDER of tomorrow's IPP WG telecon

 

Cheers,

- Ira

 

On Mon, Jul 12, 2010 at 4:12 PM, Ira McDonald <blueroofmusic@gma= il.com> wrote:

> Hi,

> 

> [rescheduled from 12 July - apologies for missing agenda posti= ng]

> 

> Reminder of our next IPP WG call:

> 

>  Monday 19 July - 1-2pm PDT / 4-5pm EDT=

> 

>  Call-in toll-free number (US/Canada): 1-866-469-3239

>  Call-in toll number (US/Canada): 1-650-429-3300 (Primary= )

>  Call-in toll number (US/Canada): 1-408-856-9570 (Backup)=

> 

>  Attendee Access Code: *******#<= /p>

>  Attendee ID Code: # (empty)

> 

> If you need the Attendee Access code, please email me a reques= t.

> 

> 

> *** Main Objective - move IPP JPS2 into PWG Last Call ***=

> 

> Agenda:

> 

> (1) PWG IP Policy and Minute Taker

>  - Mike?

> 

> (2) Approve IPP minutes from last meeting

>  - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20100621.pdf

> 

> (3) Status of IPP Version 2.0 Second Edition (Ira)<= /span>

>  - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100527-rev= .pdf

>   (or later draft if available)<= /p>

> 

> (4) Status of PWG Formal Vote on IPP Everywhere Charter (Mike/= Ira)

>  - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeverywhere-char= ter-20100610.pdf

>   (ended Monday 12 July 2010)

> 

> (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday= 12 July

>  - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-clean.p= df

>   (ended Monday 12 July 2010)

> 

> (6) Next Steps

>  - IPP WG - Monday 26 July

>  - IPP JPS2 into PWG Last Call?<= /p>

> 

> Ira McDonald (Musician / Software Architect)=

> Chair - Linux Foundation Open Printing WG

> Co-Chair - TCG Hardcopy WG

> IETF Designated Expert - IPP & Printer MIB

> Blue Roof Music/High North Inc

> http://sites.google.com/site/blueroofmusic

> http://sites.google.com/site/highnorthinc

> mailto:blueroofmusic@gmail.com

> winter:

>   579 Pa= rk Place  Saline, MI  48176

>   734-944-0094

> summer:

>   PO Box 221  Grand Marais, MI 49839

>   906-494-2434

> 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_NextPart_001_0085_01CB2678.89476680-- ------=_NextPart_000_0084_01CB2678.89476680 Content-Type: application/pdf; name="Toward-resolving-Apples-JSP2-comment-on-units-for-font-size-requested.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Toward-resolving-Apples-JSP2-comment-on-units-for-font-size-requested.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVy IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nNVd3XLdOHK+11Oc2pucUzWiCZAA SVclW7NTycTenYl3rdSmarIXsiTLnsiSbFn+e4udzAMH4A+6AX44IGnx7GQ8 VYZ5gEaz0f2h0Q2Abzd5JuQmt3+Gwtmbo0d/qTaXd0ft481fvu8L7y6P3h7V WWH/ax/w8tmbzR9OTMNmY8icvDzKs6ap86b9TWwqYf7ZqE2VN5n5+c3RT9t/ 25VZU1ai2b7eHctMFaqptldUvNgVmVBV3Wwf08PN7jjPyqoui2Z7YstCV0rp 7Y0tN6rKZb39uMszLUUj1PbU0Xi3k1mhm7zYnu+Ohalb6e2xe0a/Uq93pl5W lVoNxHUpiMFCbz+wx6/p8XVP33B1uWuyXEtpuzquMq1yIbbftuxJJavtLaNw izsZ81NUjPGn5qF5qk1nz3fHKsuNPMvtMyrKnmxd1X0zUzhzRPmrvdkdF1nZ FFSgzq9Zvfc9d7UiipzONeryHlRggtOqHuja4t3ubydPj6RuMqWUUaCTc6Mw jtZL1Gs3hHWpE/VSb0LDzlj7sjvWWa2FVINMGjWMqSgG/TGtSWJvWT/3pBJI v9iL08/nrH3WaX1TFsJ7zt/rzPG1aYV3LJsi07nopLcVu5OfjXUKYYw2L8lA K9VbqCoCCzV02ib7DVo3Kiup+rEsDXnV9L3Kqb0GZP715OjPR12NHn3ENPQx PTVZo1lPMmS4NnLSHQQ9NzLLdVOWZqzLrBKFMZhrY56VkKWVqBnfPBfajpo1 M4NAhr3c/K21sb33VHzlGsGaLzsrFaU1OFuzkHnV99QWe1JFLrbfULMN76Aj WxeM1UsiwH6/cr+/ti9QqEpJvyrr1vEVCqD9/ZKoftNXNbQYW6fwbc6puME9 OLKs6kVEMo7A6UheloX+JWOS3RDfH62ZyVo3dc+LHa+rofmVe9TZjzTN8rwa wOcF8XzBqTs+7jptkWZiMvgppCkbpGY8swqv4FtjsTGucTMmzZhyBrpjX5Jx syHlM5xbA66U4JxzaZGQHH3W6IK/rrK25ZVOuWqhd2GjtY/V4AXvicC7dubL hWy4ElxAhRsRK3TnSfjibJ/eUrNeY3SufBm1SlOY3lUxKI2nh7KqDAJVtpqD t4dxrsoqhLZtMRl4qc3qyGsKuuyQl43ehcPOTwS47HcMiE+o+MvuuLYDltfG JWtVrRYYh09dV+/52COEseA/y05PoWKVpE0VrPDH3XFjlTuX2z+42Yj9nlEP nQ6WuuYcsKmFtepBoy4VfwdC4PDtIEz3dmdxAVv7vS+uMbhtdgYHS1l7wMJw mlnrRWc/ssrqohnsh3XrVXUETuGosKcvwnmxm6NbNdDR2Za9DeOWvYMHBz7Z cH4C6OajOgEd08RXUFncZEVtMMqxNmx6uIfv8gIqOZN3En9vEiN+ah+aNVu1 /R/DjFH3qmjGs2iLs92LqVJySD4IdjpwMjY7FTupzerYqdvleYudBJiEZ3cE nWTAVJGNpjeEgVsaTOznDkN9UOjgg2lT+3BgQZVjyA2NYp8XHfMJDJfYrK7I zWUm0PI48glbo884I2vqlBu0rZqsU9RmdZ0q66xCXT2wFKgbPVkKMdZWkEJR UUTquDQGbWfYm6TpwLUfMKInpL7PaK5/xuZ6A5Ol4WT7V9O9ymqdl9vvbbxB l2Y5H+nUU3/f3sl9wSsib8pDpsU84AHEpfSnbWPoVS5qLhz2+8ddY+C+MK+J +/rBPDUvL1UV8Nj2q4X0J/NjWZgppam2n3eiykRpHG88bT+lieregwcz55SF aUYEGDeCqjYRKXWuvdET4daDGKuwl8JYjKxqAu8rmNhv4RSO4RSHGsZKbL26 GPQiN8JbuqGlsLf+dxVOU4vTG/iaJAbmij0mzteF7QERjMs+Fa9ckz5oJook 7kjNI15Jplz1ejJTYQ9xppoiU20ToToo/BcbAlZVYfFpKP331hUVPdyBms9d 6b0rnYJn9650B6jcuNJL8OsTV3oGSlTvr11JNIVF1dHPfwIM9syUdTXwaltv qPgdFU+peAWLrNkNFa9hhSdUfAaLrO7Ttqhrs4JgFZ5TUcJmwyDa8glk7Q2r vOM0rMkVuTaaIigkj/q4gO95TsU72OyHlKTOodg/Q2JivyBkL7/26T0cuM9U t3v3pIl2xmNmkakG2jeYbp550btF2EKpdAx/3fsWAy6xPkSfX7Dzf75Ted4R mPBmjsj0l1ONWTmW8ZcjECAAuXWlx670CJT2t83As4+udAnqETS9A/UehfSY kpmHL+IVqWMLPpfU+hEVX1PxFhZZ3Y/QeBIVJDfrZG8/Q6t9Aeu+g3SZhTO4 veDNAPSw3z9BAgwBcvhqHyBE1LCuBMRwF15R73/qdXEGUCgJPb3RctvhRivm GC0RmWG0tWiJxoz2Akyv13sN73xktFJPlQJjhktBzpKCIzJDCtoseHRMCi3/ Y9Ewd+oCyOYc/HoOyPwAQAlRIfl/BlSEK0nw61NXIhQbz5TUxILXHIshP2Oy wjOJ86EuZg21IzJjqJVZUIChnsQ0a8uZLmcx7YjMYNq4KHk9ybPX9BB59j8C rfwEJtf9awFqS3Y/rACmWzt7KS5NNUuajsgMaRYqiwrTM3bkhc1ctxQlWLZ0 G4pWggICAA1+HUHBYq95GEaSJh9FPWsUBxozBtFG3VYfxKfg1+dA0tTiNRi5 92BcN4DyPpUBK122EnuYpe7vZ489DQIf+2rW2A80podelCi8GHuSTVff57Oe xWfQ6YohbZWLjtlvXZT51oWmb11SJwwcd4HrIAXpp5nOUYR7CBIXsXwsDoXi bCeui6OaLPFD78Ki1ywLzrZCXbs0+iXsywvYD/Lj8fohw5mM1/+ppZ8bNMHb gHAE9ztKDZ/yd927ByeasR42IrFin2o3M1/V1JvxVpU+82r+H0Ku62XKQo3l 5tXMMq+OwnQQKBvzajNAgOr/5DbVzo6LjDuNMyqMX1JWddZQp6NlE6H7iSu9 Am4W1fvdaHmFvYVhzvFcDYrS0jT1ZdSd1+Qd4OYtWE5cjOakeDyAhTJ+Byet U0iBFXEgggUt7lM8bGDdO1gXhztZXOQGsoPjIh4xEBcZT+5Bv4zWq2mv1gaZ ryGPmLFvumJVW0dA57lNPU3xBwJ1XxbGICITbUxXblsa2Q7ZBEUCSYM/gGek 6cibQ0sjMifU72ipHQkA3AIOxpE4cvusr8c0Hfnu89QbGx57ytSMqc4lrOCF /Zw7ycJkOJzImp3B3u7g02RG5h6ZWNIUIvkWDEus8hV8IWzRHoU5NsbUXS4N khGRiTamdCb7TlFg6wxYDOn1DfgVrY7Inr4BdoJi9igARkH5ypVo7s3Dfpn+ +gEwplsvU8aClQ/PBWejfv0QWgzsb1JMfAjrtrjPmDhPcXkHiwxAYpMiMLKP sAc8eTFuLmFn2AvA8r0c0bXz2BkU5BtYjKHKHCtlBiOXxjeJyEQrLcv2R9sp eYdkcxToG4ekPafvI2hMZk8GO7KbyW4pnkYJMijEhaBl72jH/UM8Y6Vxnyli BqllkASLlVewAkaCU/gap7DZe7JzNPGmrfR2wDsdIbAQzlizhUDguSJzLI8Z gVwapCciEy2vKDLdR0FJndHmmf3x3HfgVzKU74Bp3YO2ZCj7vdtJpsqGpfCy 2wwlcSgZTzdMdS5gETfDnunCNdiGzAb7lV8gZ3grEHYOFEcHYHgsvdZQsYCY gosRj+EnKn4L5eDJVzWN1eZJhsV0XC7N1xCRiYYlbSyt65TMBLmWV+AZbelA JoH2rCGTQKaD5kAUriGuRvvnmHL5jicbK6Zm2O85G9GKKyp2UjEQY6eQbb/C O8eewKd4cvsAWWdM/tMe2+2nqf37SlhnGFTwu7+D0mMYh/2IeSGaOTMaswG5 NMVGRCYanugjusjC0BIQWcmbuPZH2r4GLa4AZbSQ3IC2o5mLjQmRsVaH1+5J FP4bmcS0nJkTrFyaMespTA+VFwbk9fRIuavu8zgrWzbqcgKXdT0roE/1fT5n pR3CTlfM6hWVdvw+gZkjnLH7qpsLiFB7omR87t5m1PafvPfOlOIjLCyDOOGE oZf0AgdIbOrvffgKNt8XvgIj9V90NAcf52Dd2GPKYxn1x02HjN9N+szG9CP+ +DD/cGS21cB+9sKnlRwzTaQCG7abCLfjCxfwz+wN2OEPfOyejnnMOFuLrxsY X6YR6Ng5nf+LJaETNzz8L4luzoUex/AkrZPiF3cmiR1LZm3wkaK3UL286xeC NHN7knZQGZkVuTtlzcbmV3sCzqBPO/OteOgWQFqxNKdKRNaHYF0Oe5VeAKxl h3BpRwXfMgGO216znxdtjWCjx1SFYRLTVWyxd8FpXnYgnAEzxHDP1AJjt4g7 B80nvDTbmCHtaTxZpjdhwBN17HdJT3NedIjJKmRQfuxE3RMAyQux8Q4eZrzk RYRXeHtJ7PaKh9+Mwy/SGW/F8e87wDcNsZ7YicAb+IoeoA5kX3CmaAJJnGq8 AtMadgWu+SgyxO+kUtUDttsbYj64u2/GY9SdlO8UpsikO1rqXUbDBuAAeEz4 VixNvzsa66Ox6XJY1478t+DoNgHuJxL+oXY3cUaLpSlXIjJjSVTKrKxnLIlc fZ/RWVmnsNNWqGIjOlmKzeujug0a6o2sCm3eSzebxnod2mjGxdHLTu6ZckNg il+pMTYgURS5e7cnEMweaDnwCsJDO8ky5PhlV9hidBdg7L4bcM1bf8Dd1OzP t0u89mKT+cjHDq4PYOf+9/nYvU+ZnFuSN3ys7mP7KDz2sbsb3+pMShYIZN62 K95/9az7K1yBPYUbOF9AIZ0YHrR5rmVkXQSXUPgmFjwMuC4rGvUU9hIIWeOJ l4kJd4ZvcLB2F1jcsB4JLM67kKjVQ3y/3g3k6cpdM+Sp7AFmWIZCxdLsIhFB COvQVZemkfFCDoKuxnaGrOnPFBm6R2sjDHj4bkAMg8kN5XiF4W1UD6+kkiUH h4XwxTx1FoziSyfH4l0wbeBruPBCz7/oZbhRiwzxlus/uFQDB0uYAWUEret6 RkxtiqU5QSISuJwrqHleeUdk1xKL68YXy6yMDeR1jBKlQRKjHvUhUEI2yu3v /fduRVhVwulow24OYuu1dg1V5UpFfDF8yRAZ3UFdvFHkYbrnZQMmrGb30MaS J8Y2/z/6XeH9j2Zma7S78Xt+lPPB/C4ULfD8rmH+eFi3C3lNvts1vAN3uxKp hpjblUhAjDjvL2PEHheK1PwWPC6OOcXSlCkR2YulhZIG53J1ECyt3dnJ5GV0 S+KmbJjYiP4eukis+C3B6lUi6+eF1NiNYUiFWbYRTgct9j7md5SvqVIk+mJp gtvRWN1nkVWxusPS9+HLY1YifcwlhYxknm+kMOZUCPNma9uWtEsn4VZp7HpA zys+1o31VeqvciTCDLZ3beFgPcn7pllfl5BW8jbVGOojx2nqDYP7olhgnmSM 3UKykeULvDrRoQmTB444xFLrycRHFzFqv++yiZ2hRZm2lI8UjlLqxsgW+W7h WJ+h7MhLRDp5u3kqizYvY4l8BcYsvqc68IeNjyxkxDHBd4GzuqehWqx/z/SA lAxayqUpbyISx8tc25WxQdW18dKsMWXZuGX8j3To/j/IsWCuM1whxbRq+gom cmy/x2blpxUTMI0jSSFYE3b5EwPATJZwmPC5jgRuY89sov1EFnMBUO0zoHCl Mg9Xh1v+K4Fu+ccA6Z7hkWdCwEv9OWo0dfUbvC6TPhMN1uo5n5KZCOx2XTVw XtXs4b4vnwQX7nuKeQAgZJhRLk02E5EoEIpGN2b9doAkowXConaBu9FEG+Ac dhZjwWRXZCuhIHabVvmkau4LHAfsh50nMfC5ze14gXnkyyY/NjEHHnGkiFkP dC9v4UsmvzOFzNe7vLzzGFVW0iftWNU5MOp4wdKakr1DYSQUt0l+yST1nSa8 P9fttoFXst/DcZvzqSz4HZFXB0Y4Bgbl0m0fRCSOcLXx8gqpxEEQTmoXTvt7 IsDzKdhv/YgDDdjIcIohxz2kPRPYWGLLUacgX8HwK2gSLFxP3iCxyXiz54EH jrosRxndczzBGUbNvvrjA3gX+DznqAW5vLBfH53s39ECGLnGMW/I/9LLwgXu GN4XCh9nh4CqGE+cVMWewYRpLPT2sW2z0amxWyJvyC/EH4vaJ5sWN5ln6ZvY IfeKc+Apl+5NIyJxNK2qaiOMRA+CpkINkWT4nTa2LTb5wZHkAjf8PIz3Uadh DwQ9nHGqJ/Q+PSBBuDl/o5v3rU7oNFxDjfaUO6HymVHjvUeZ7VFRM35u1NxO zOggF3kDWqxlIqRN5dK9RVFOHz4vkR9AIjmQx6zNJWMuA7hQtTamrNaPs0nT T0P7c8fHEv6heQm/KZsj8SeC8eEFGBocr3LB/L7S+bFYMpJOOCACaRwR7R3e NJwTgEQK1GQlu+GKVi7dgBTn9cGxRNR5ZAvYw4rFdeOLZdZeAshrACpG762S HAZUdMM2m/02QWW0STOc2293+z2UPaGy8TatOIg40FofRPC2oIlfWbdkLzlZ lHFLrhf71VxRZrpxSc4JZ/OOm/YqcrMKrvX2e7O8K6XyDwOyfEibrKnyRrAS Xv9gkWKJ4Oz4OVxgwsTxhBjc/rhX323ZqqxrNSe0zyJXGV9gxVBKSWWtnOw5 PasoWaMma8EnQ5py6caZOK8PP6uoarxaXEEsrhtfLLP2z0Beg1nFoLbxIw40 q5Sa1iK/zUkF31uPp5qUZ4qj7xjOUagpCXNgFbx3p1w8T4FCeF7KA8wlc2jh kIR3QX2XBLbb+MrNeO8MDODhjU3eiXcHspEDwPahDj5P7aUXEptv0bhdQmks vtAjIcQ5H2yl2ZTNROxk8uiylEKXOmCB4ntuJkqmZrzZcP2wIMMZtXQ7jaMR h06R26BgUR0iKCiK/iOsXjaWRQeDT1mEGhU6uEnb3H+yyAsKfkWCeOEWwmXe 19IU6PSd9BOChWVGozklVFiN6q9lNIOGqaUbLyJcPrwLZtPnB4h3uG58mcxK 1UJefRxpRIvEZqzF+ocErBdm1HkIWKiUG0ZfC2KAkNx87K38BgIj6xphg2uU nPTmmbLDRm87Q6LjCdfU4F3TiSDms50Zb1HuOW4xfEtozrpwwjYfJLGpO1QK kenaXUYypIb8TDHPYKOcDe62e9oolQ4i7DtIa5EaH1vFWpOMc8yZjuYflGs/ pLT3oJx1xyLXgK3pOXnYsDChSkSimFdb/bGYJ4r1D5naCTTPXZQhdnkagobw NNG+u63aWr9Oyd1zq3DXc3wDN8j9w+6XG25ymCsit2BFmHoOe1tm1/joJt9S w3ig5PAtxGfp7sDLtfv8GYg1+0vCz26XClvcYbRgKsL3d7Au/tm8r6qEv1Xy 72wDIgrXwjAllldkoxToKur6j/Ro9p0C4RHRX3bHtW2U173/0S442dKSFZ9Q kW0+Och6kqGHWppEJyJRVKzMrNt7gutf0GF4qenLWg+DM8yx+xKcyJx6hSWD GGSoYxQ+ILiEW2yDuNGPBALJUy74Jr9bWMSIkjzbjucfZsYuaAi3xF33kFhm ku4tjLlYTmN+2LlPSv4nieO5izthaeC93p6MwNH6pLP+VVezLPAoh9AYmyIe cyhbH6mYRaulu1vqOpU00LJqccp+eMGecT8AVBnJleEG4/g8xdd8XxGdoikz GdgRjbbfDB/YTEd2hFlgjxqspBUkPLV03wbg889H/wey7/iVZW5kc3RyZWFt CmVuZG9iago2IDAgb2JqCjU3NzMKZW5kb2JqCjE3IDAgb2JqCjw8L0xlbmd0 aCAxOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nNVd247d thV9n68Q0JdzgIwiUjcyQFA0vaQ2mjQXBy2Q9GHGMx43sWfGcZzbX6TNB5e6 cW9Ki6KoOZLTJAjkY4mktsjFvddeJF8lWSpkkjX/DhdPX569+1md3Lw+634u k88+tJff3py9OlNp3vzT3s2vn75MPnhiHhYi0amukifPzrJUa5XVXckiEZlK apGltfnLl2eH5Pjk67M/Pzn7tCvfVrSsGp2YFts6dF9FIcwfdcmq+fJQHs/N TWVVS3moj2WW/evJ466dKs0K1s6yL6TMx4WwtprX6JooZJYlZVN1noky0YV5 qBLJt9dnz7awnaySSutUFt1LVUfTNpHLrD6k5jIvK9MK08zz5qZaqcMfjnma VbooDld0K7s0twph/lDowwX89RNbwLfH8zLNMiH14d/HorlVF4dbeug7euia fmVPJV0LqyzndX1Hv7JLp7Lz2vxcl/JwSY+9CVWcwHLv4EuyG563v+alyj2F fXIUZSoKWRz+cTwvylRVWXH40Fg8rYqybt5SyLSQShxeNw3PMpnrwz0VxUp9 Sjfg1j6ne7HF2GOstovjucxNG3R9+OnYdHOZi7RStelCT65MrzG3Cp1mdVuv NcIPx6bLFObKqdaaA1fb/arLkj91Da3MPtktFdv1JVk47/UaWuYCdiv8mZ5R vXfwMXbvf+lX/Njt2Pi5+e9wTo+x9vbdtcrKw89HUZuuYq66NsrKDM7z9ots BHgcGzjgqRjAo0L8gGeskeQiV5sDXlEkpuem5of2pfB3fwVxgd3QfB/ev66p /zEw/JUKf8c7xviQ+Kn7wNLcbrvNg/pVC9+z/Ur7epV9xpjI3GBMqKJN1FeF AfUK1rZuUP8Kx+FXB/qZteEn+8L3EJxlh3FSmolKDRjHiv2G4O6af7uymdjM 8z8YuEylqrTyQAXrIl8dYcvfN+9rxkQ39w7t/sUagbWb1UBGuoUoy+z1HzML m6fyUccEVV3Bj/sU9CM2J92hLzcFvaqs3Eadq+ahTPXOR14VVW+V9l52+Ygu h6FQK3ODrGsz4OstIZGhB4dEHQWJthA/JFaibnzAbBdIrKu0f6fTgAxz6X5u BkadlTP44oXg9t43cJROIXhHZLGdHjsWHxMC/J08uSem1spUVkmPn8VaeA8v MZzMGaG9xJMPG8Mvhtcha1xza3V4WKQylwMe+pwr22M+MpcGQbO8PnxB5vi8 cf/rTAuPNS6OaAJxbGRKNW5lfXhpSi1MYaUIu+k+X9LeENk5Jk02s4GQzUdp xqrKCz4zvMcRbAeAorFcMXzKovBpKMMPT6WUiYlKGmjaBaGqIlXdW/1ioWVu yplEk+4HdCYbWavOMtiywnwzxZrQGWW2xSoDT2z1wck0/IOLqA/ua+nJqZrK VCl3MIqtxrWKjLIKaqsdB8rENU3vN9GbaWGldxkKjQXNOw4sFPExt12Qnhu3 1oYRDKXu+FCwII1xEUe17bBhOHlDI+5mUZDEiBfsTrQP/J4m72TT0JZZkXeQ PKqD2EK2Hzd5No2iNzCLrcY1SxFlFtRWO25yc09SNsF+Ue8zfzTmE8q67cz1 6AbAyOFhnf4RJ+qGoUZXRM75yDv7+N8g9zYeI+yBP3ZekypK/sALO7nR1cip 46NrcJJyujQf83o8/DJZeVqBmcYJd9tYkFWLGWFMP2IX+pLXi/z/W1gFu+FH TkAgpuaWt7d1cQudFkoMLq7jTNunMCfIDHKHPFT21GPo8N9CO7PHJP0q4A0u 28GAH1FTDqUrdSqN99pwEQPTgwkoH/FtKcy/NA5wVRSVmnaR0kxIzI5T2svM XCzCf0wsCzPTi/bXQtYlfkrT7PHOzrwAAxgOnGUUcNpCtp9PsnoIE/oRKKqq /6zNaGaf/QdCItw3n/PPam/4vsEi/ADODRGikQvPnBXW++jOazgyHa9juJVh YVxex/56NUaipqM/demOKwuoOGvB2EFfOiZm6Nl72eDGjb/wIB9uZBfyG/fX ZnkWJI/YpxoxR5UZ/rwxPTrk2kcrunPYwCTgmN/3Oss/7AKqgGUw5xN2aecT tLCzJd7Q+OVwU0XBzVDG5mhT6nKHSNjW4tokKj3vbenpbaIKG6JCl/QCdvFv Grxp/cae18u3DpV4Q6u1WUAqZHvD1tKGdsywvWNmwGWAkWJju7F2VGtTBVSI pZ1y38vXQ8WVaG+gZwINtfd/aQbLSs5wWumChpZZWqmIhtr73YZGcV3TShc0 NNdO7w021N7vNjSKfhpXarupGLqpeOhwse8na9veP3UeSl2LHoEoe9c5ht1U WMrDBzYQvrZ//YJYHhihTtI9zUMtnOGspjO5o0BwOuU3gIhJrqDq5Z/Hc914 IJnknqUT3TkBpusFo3qwR3IB3VYy2B101m5gWa9hoOtz9+YzszfQ5fm3Vf2Y sgd/kLlljCR4gTJIQbfNaTf61SbccM/AsrMFbi7K1A/5xjJnb4MLcFgKdAOO 8EG+zREVTG8cB7u914ryszjF99yGJSxfxVJdmMId3sQ4sxTE4+z9HjE2R6l6 LWdLhWyPqiZSGBwAGIfeM9ikiHb4bRKwukC8YNAQnKBumMLYjfWfv3oCfwYM INU2wZjm7592UicU5VIojbHyOSoPZmGdQdPMQDg1zuD81h0Wk7ZZ3Pneynuw xgmJA27h69z1sbX5QZUDmDrqIDTL4ZwMC66fwS8YlO9g9QWmZ5fOGEp46oVl sRawOYshq7UnoTFPzDdEZq0qSyOKwiNqQt/FEUEMZb6Z6cuTt0fz+AUs4Iq/ EpBqTWb3FmIvuu5iXk2WeuguTs/aAXcZjtVrk0JUyPa4mxU2iUUu7BW76oyu HaLRn6h0cffCPg0dXMamomypPkG2tM+O2nt/R50oh5hzyTHFXkJ3s5NtG++n 1630o2jL3sW+Vr2WOadClgd1hc7Tolge1NH9bkOjOLdxpRvyIIUStr2zPEi+ H5fE21Sv5eiokO1t2Og6IEd6WrPYalyzRFFs/rae3iylSqc9azl1uXJlRYyk D/qmI20qm75ZeWOtWLrX2CCj1mvpQlvG9l2gqLcfFl0dX5pxsJKV9LTy9NbI y7ToQ1OHRBpGxDIOiUVcJO36nOlNQOg1iSdHQhFAxOR1mIiZpdiQIOzexnET yXITYGHF8m5LrJYthXGDvBipek8dYdeuo89UKrV14YOWDq4eiknoQiUzrQLx aXBQJOp0HBT9wOAmga/7IwoIMZ+JhTssfotctzcItZ1QCwVgLyzxtYCU3T4W 40Cj1qZAqJDtgdGE50NuKUKWkU66fO7GPI/gmMAqCNYPqc9jEBp4WOm4DdP4 KHPUtc89t1ow93d/z+q4qc9iw0FIRfXCKCb/bbniVQCA2OvXcKD5FpkggtxZ YT2KLKXxILPSSk1WoZWT8QlQaNOOtr1zx8aBWpsRpEK2H7eNimV7vTFV45ol itL3t/X0ZskyG6g9gl2+B4i6RDklh3WZcascfaZV8wPnzztAggw6jn0GgaWG qwjewBmQEe5U/Dcj9d9UuSkPvsiuraQSclm+1jPGR172FN1ogwKL2SOtKSX/ kB9z2UNXmercZkWDoj/AZoN0YDAlG5S0TXJ/PbEfcGGwnjK8qcJIxDnSg09Y 7rFnPfEMeP7Lu8JvnScZJt938OIYjKi1jDoVsjns5UoP1MTmgee6ZCaWAMxt MrI8uRi1ztA2Yy/Pgn0btZY+t2Vs35Pq7XWgfR2uPaJYek8rT2+NqrLRHFs8 QWmn1Tyo7Yas8+LZES8wf93N3yh7iZcVMvmWZ9iiqWc81FiBk4y2sZ1PWnVF PsO6PO1vllvqxAImXM+tWMC/IQKiTUbm2nJbhBXbcC0IEVkn9BFh6BXuYGHB 0DCBn/weFrZQlVargNLMRgXdGqldPRGOQGptQo4K2R4xy8LG0ZcWJoln9y37 QOOfeSUXdtUeY4BCiSXsXWBU+Rrm8y9D3jD2oaC7NaeuGrfmpCN1eV23ofnE v5JsluV19EA0aQzKGWOeATuZ5bx7jQAhJm5tQOkVsw3g1wBKLo8TKHG9Wx5r BalpHIy6os5xW9nSzl03H9sS7xh+qLWZdipke7wrSHQCtfOv7NWJ9qoLUu+T jP80LxTAgZN7W5wfX7vhlDXLgg3tYvwrNDLn/KtGzYmHjZNstcXe9z6iSlVm F6/7topCWI27QeRsMawcpzdbOV3gRaATV8kvysfqS5g1wTlph0ACk0H0Jqfj 3evYr76JYQfHjwGLWis3oUK2B8JcWMqMdPPhXYTRUJ3d4YYNrECMjLvPVDOE 0gTOzj3zThG9GBZ5L3A4ka4a1jCOxzH6sFIYSQtBbYGixO+ZjMqaeCbtr/3+ dCJPRY3w7ySTzQBvK3dQPeWEM+otswE9m3D6xsbE80GayRF4IFwPfUZ3TAJN hgOVrAms3h2gkkGPXqtEo0K2h0qZDYwwid7JY/zeFUE+XbRPx2ur3WQdDNP6 YwyJzFY+YFc/LELoxvdoU5rJ5o+NRg2rHHx6gyAH+3YoxQ4NVVpndrfOhQjU FsDG1ikoxSUINPJ48eKhZ9DDg/laVsOvkNkjZ/AC+ZUYj3fL59Do1WsFXraM 7bHGtH/zfE5Xh2uPKOGMp5Unt4bUtWVTmTyEr57n7GNeGb/BeE79Hly5IxS7 g54ox0EAjpgIWklKsXHWThLjmcJhxdHovOSj07qjtODTl0ka8NhZiTnPdTGs wlmCkCw1uFd7TL4AO+pDpC7Skk7PwNj8DLpTk3vbpZ9BPSyeFn05ifEn056w BMuD+92OG8pwU5TkI02vFY5RIdsjgyo9lOFpzWKrcc0SJSyBbXX3f5ay0kku zCvucESRrAtLVbDND/ERRZPVF+ORM7P8Yrx95sS7mMj2EOqxum5gWZhLWnBQ DwKVmGUTwdXe5AMFFQSekx0AYGOZFUbpmOnJefPO6zVfvrJeLw4UMLnhdarH Xwmqy9jf91vZoG/tnJoxlPIMFR1kSqDxfWLoQHDCSNI72FgQ8FlJXjNLt03o dhTBfOcV7Gvs3otxt9htt3wOLXqteooK8eOlqJsTjsz/dtgsX1bS8hUf0yKE 4FkUMMZeGfI+oh7Id0622IwDfgzTeKObMVgTdrkTA8BMxzVHzmCMwAqvOVk4 fjzR/wio5gZQ76kHNDI+XO0c0toUaVPkQYAMJOODbvCcccdbGyylS0avy6yP Jc9BPxZbYSGwNxl1di4R/TgnqGsxj251OuYOQMgwQ6+VTVIhfiDM6tr43cZ7 3AMISzFQKZN5dgRzwezQLKs12mxoTGn6XLtAz3wAExqEwM+blRN4K+Hg5uwr 0RFTqngzInJwVkrv0OidHmQpyrQorbAyyCH4hOOzp0HFaa1g9hwpa6PcUwTO DGDgPnO2zJhlgMt0RuPU9y4AR1ig1+ocbRleeBNaySQ39+0Cb0U2PhIJd5Af RxqgdznGjAjwTkoI0cb+6Dk/MMClTQ4YXNXg53A0sEwU+YHUTNY2fk4Cl28g J2AlhRo8TTYURDpLj4OhL3aLWnzLmuPWbFI8IvRFTrHPD7L3sq3wo0PbKbI/ nL/Ge7owH5y6Cj+I039Y61SXtGxW7IJjpge/hfabs834rEvfbgY7AOmAOnqt fLIvwQ+iSlWJMLbcBUSlskQy+26hhbJBfxFHtaOowVXeDLrziLVufuUO3r4A h0s+XhDkRuddhVvYmZ1+HejtwdP48qxqzkihz3YIHseXZxo9stX4YB1KrxXW wbaORkmts+aE2HIXCl5UNq8g+ddCFDxp2648iIZiDbaxODFGYX1fIE/2sEUP TVy3UscaPLElZiYLHTpCB5HFkBULItTlDPo0uMpFWlGek2lpowW0s3FYIACd W+A2WvkQjN+Cjt22e1i1WdVZUVBl4Hi/NRV52YMVAwfh6ONWauWoQD/6GXhI 8uYUwT18hKz0L8JoP9CCTcAil2H4vVBwdpr0nNi266odLngd9LKxJrJyM/9C hS1XsLqH6Nk2kK9zD5Fa9jy6NLOWAtGWs7s/+3ZDvIWlGFiGwiMVVsX75n3L Wrh83y+MRUNJPpijxfbyhPygquCe47YfzfGbk8SyDYKcRrFTnLsbCifzyC4f wTBqy4DJwiNDDx88Rqn7qEA/PJa60eaJbA94FDq3uYOTrecanL21y7kQfTqL xzvCTIAx/pjgIJiz9S0PQ5fBpSsLtnZDKTawgZFDonXgWKQyt9qM4D5CHx3t 8TJfkDnarVDrTAuPNbxreslG4HTWoAMfzHZHdo5JkzuCiBE5bJp4j8PZ9mjF B7MPraK0t1TgDFplJjxX+5wG3QCWkkMugJjo+GxbA1zt53TmoQB/IcwXVKwJ YfpCqAw8sdXnJ9P4vn6UxBK1evTxi6w2U1U5lRKmpX259vIEPEazRKx9OXZQ wmlJDDuwH4/0KXg5/wn2egikBNfmH0eLQx7GerAbgso0JhxqzmoyMV74ePUT 0x7Dhs1lASYsD31h7TUxuC5Lb6UB4med1/F/zV54FzVthXgDJPjwLko73Zfm R7vclCF1PdW/nBrtmnmu1JaK3ou3WNmfYrytub10ZjxWH1k5xPY4sD0xhTIM 3BPsNe8La1Yt2Rv00wbNEquffltsCvroPg5lKGs9h2IbFuRQIumKKYdi3cSd ZM4W4xgQ+GAuSvJMBfqRTooyyUUxzU9tgXRFbSlocun9VBRP8DxAZkesWErZ qwSiD9McY1nsFjvhRGxMYF88jqf1TwynXha8mukYtoeoa0Q/xExocGeY3y5x gxeTPlxX84llYXqm39X4TbjkFubwVg974yCDCR8ORimeqUA/DgqhcZ5+CxzM K8s1tzhHMSMBGt7BY4aj+shcmo8sy7pl40TRjFjNDiZaxMYN20eMGbjc5+fF MXCog58yUHoPonY4xTKVs4UyLMHNg4JziWM5sA3iQzchxGtegntmBLdnxfyy bw5EFEdAPrhFQvTtJN35SPdBWZS4mQr0Q5l57UQoPU26bwFlBhwGInqr4DUm yTNSK7dlB/P1MUoVj+ppFj/YG7GHQmflnHKHlZhtVQJ+RWjxgrMQoUO1IpVl TqiGXDnffpZbjk3WdX1jM0oxSwV6x6aWjcUaTYzafpFpw6Qbj7qHn2Ji7Le6 Jn9CGbhbOeMNTEKn6/g3tWKJxAlX36VCba+MWf45dwzG5HgV9Pbrzge8OSIE xAGIz2vr2PMiNR7jMDQXgN+5bmj+vD3N/fChgZJClu4eMcztoRCErnBwhU2K LYJ9QHz8T2g/Gd9asXmI66stpJMCjslusJAr5RGVD7NK2W72YYdzOB9ZSgWe 2ApKCWZ8SBolrPa2+qQAqXRfW7bd2dHWQhmYacRa6SVusRhaLB5qmeHwdZ1t qcUfbGNr8VsnSnnla/Xp7VOrLbcLGuxja/HbJ0rrgVr96dn/AD+SOXxlbmRz dHJlYW0KZW5kb2JqCjE4IDAgb2JqCjU1MzgKZW5kb2JqCjIyIDAgb2JqCjw8 L0xlbmd0aCAyMyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nOVd25Idt3V951dMOQ85p8rTavS99ZJSbEehSpZkiS47JemB5IgjOtQMOUPS sv7CiT84QF+wN4C1G8C5jJREUlHNPt0AGthY2Fj7gjcXZaGqi9L8u148/+HR B1/2F9f3j8zf1MWXHy8Xd9eP3jwaitr8Mz3Jr5//cPGvT/SLSl2MxdhdPHnx qCzGcSj7uVR10Sv997HV/y+LXj/ww6Ovd0/2l6oretVVu9u9vq2qpt9d6Ku6 7bqy3r3Qvyt9uxl37+zvd/vLtihLVY27t/To9/b379CTrND7/WW/FFdXZb97 DS9v6RJXuJRYl2r3lJ59pQvXt/u24s9+Bwu7obushLf0zS+psPd7/VZfti0v 62J5VP/+T3RX0eWvYXMfUw2sW97BNl7TXVBxA4Zg49nH9OwX+8tR/1GbjxqV fkhVRVMNaven/bdPPnlUVaoYqkELzpMrLScf7y+7omva3mkxq/rWvN8PJD3m O9lnsPb8sL+sGl1tq/Td9S128xn8CixK+OOdwfQHQH4N99k08N0YtKYaC9U0 1e5ve9Xrq7IV5g1766/70XytO+z/TR/2oxG3sqxqdKnaZndJz+K+fUOX7+CH 3VO5cyfUXdvxB67o8h/7y8ZASN0s7Z2e/YRKuJ2+sm6HWg/aJDV1U3RjtUrN xb7qe11Cb3773ZNHf5iArFwRrUxDtPFCA6OFs3FBs7oN0UztL/VDbddXlXNd 79uyNG2Y4HEoyobBY7sU2NZ+gbr9T/5C7T49EnfjWFRNgMTLrNAdvM6KekVG A6qv9o0ZobFZ5NzcC6DOw3H4JLtk0sQw7xmUprdQtidQD2r0p64zxRh4WDm6 4VJr7/qFHzjtpTlj6wnmTFl14ZQJ0cR2yDaa6C4lxHW6vFlG54Z/wozDdVH1 64TKwUPWqewBNr1v4Vjc8+mNMRv1Mvtw+DXX1JpwTfTkhTWBPbAs7E6zcAU5 pSaMHes7WwVrw3Mq912sw278vpsQlYErG55AmqcHnu4DqeqHpctbvRrdLzhc 6ibVD4nDHMskHG5ycJgKPD8OD32hb05tX8REdd3SqwZoCXIJXW8WaZBQ4RY8 uQVh5smnJGG4UKxXYODD+iR7reBVII30Maw4QY/ypqLu8l5AnufeXoCteFvz xu+XK4vWuC+exsHQPoC1pYt5Ymldr2/WecV+fr1H4MGwgVCRdeWiO9YtH4Cz ITDblcyVDSprMFlh0muoE/MQ1D6QiKBYEjamxdPYV7AH/lM3ZzTSGKg6Vioe AFkZOknI2mYhqy3w/Mjad8XSdFJgAzQyN58T7tLNK3vFcRe+YuWmgGLBLpmm HV3y2eaMTVusgSwiZDa+bJ82qa5Mp/5pnvIVNXk80bZO4DvcDR3pjIzkWNEC q0jO10YmOHs2XDFMzzhoMSu4TTHUVlXBe/A6vKu78hMIlM+Chpl6w+2VSzow /H5l+wMDCP5yvHRLW6y1hmdw74Erc0bHdgJxCt9DcGVv4YazL8fC9xyWcAVF 4Sb2mqC0PiygEihJeNpl4ela3pFwWrVROO2aYlyaTjopaZp/1QJdVEPfKwaY d3tdkf2WtQa9rxzKdqQtgrwloqmQrs1iRXBjC3oyRdBWGV3+C4IHvFJ8Tqxn dJ9450H+gVTI8QsOJrUDbarq3NekhWfeTlbFMFhZSWQWExYit7u/pstPSPEi xuQrQ1lXVMq3waDNtgCksF7FehubG16upENUBiUDwor0AceVOgAJK7/tdout CYTuOQGWwZSEsH0WwtoCz6+x6jqrYW47E8gvCVn/zfRi1zTdsPsN3a0sQI72 SlmoVPYeE9pN/JnvnnOQ2IdKgzRkDZIt8PyD1CjM0Z+4i2w1cheNWV0ktfsM XVSXlo/7ykBoNzYNNvLCBR+aEd5YgX4HHvQ3IWzXc0uQ57AIHlAabcZfPdly yzB00XSGxjG7MeMvFbhu4quGwyKpT39bd2RbzQG/5BgDJNOEfZY9gGkWtqw5 9nJ7l7YttOgwHfzpwl+pohmsWVdYqdB+jzXFMUljyw1aS6O7Kbz9PIp174zV 9BScEeoHTrOx322XLjLajQMm59g3fL+XJ4VntWMNcIY3Mmj3Xodp3UpVoihN 06grWz05oD3B2iNekM6B5caxczzA3o7BHofpil2XWZBtCzw/ZKsBmyF88ki5 Vl6ATTfo54izDntSmhAIrpiMOfbidEvGU39yuCaX0PiL9kVB641+Jps4+U// Ml0qVQ1n1rjY+EqyqbJk0xZ4ftks+5UzWXfFGh2wEZqE69bqCzNNVffpy3XN OQz2ZNJy7WH0OZdr7ME1tYOtjqanlkeboep33+yo65i/2Df7oEdlR6rncx1g 8rz3fgl3v6ZUf0kIVla8Kq2aRF2oXgH+SOZ3TmbkwZt19mm8e6sjujckMGlN 5o5h9oMwzwCs9s0occ62LEG/QKQba+CPkIfJGx9ZocLj47gxNI5WcEecw+1C +HdFq6xLy1pDVT2MfkA4JkFwlQXBa3lnR+B2bIshUA5uka8Y4SbB7vcWiqF7 bshGBtaaCLF6oFONh5mLo6Pk6OTr1mb/h7dOrGUb3mMbCgLThxMs+lWt+7mr sTdojok8lfUNunydW2XdrXMLfx0Go3v+YQvp+ZP9GNxWhg4YkY+3OEHjpLON N9pCU09bFdj1kfV9hdZWWmCiNk/HZx2CN9KgJ6WzHLv2zFwsgw0J8LLcY215 5we8ocF84ok7yFYj91CW45rY7jN0UV9ZgvLfse0PuFpA9ZitKQdRg7797i5m 2cDTYiv2xOPt6Ao32NOJBE3+1m4W81zcEBLkG++mvYDnLRJD4U3DkcWfxXJX amWrtXxfnuUOKbX/gDu+VE8Mz/3mpJ4YaG92ek+MqfMTOL5l7KTNFKLw6Gux aydrdmzVw84ZbJxZtUxBf7koEa0uul1lBofjPLDLBgc6CaSzfOCowPODdKcs JRmh4BgIQ16O+3yEzIoQd4f2m2mEwhUfekT0+y9gLZNhMrucGBFaf6RYE8lQ IGwGAqLdlD01c/7FuAhjrJDUVsDGY20cd5HThzOXropusPvfK1hXsGZMhozY tMeLTjRSJEoefMCVXWBwEjgLLBbp3hn+Wj5ry9Emsi0We4CtMNTwPFYELFY5 sR3YVHK374vZFsOYEGfyzJhcFXVpPXAeGn0Zgknom+UxRwWeH32b0ZLuZP2W A5OD2I8gosJ1hwtMqC46kyEmBK0Jt0vJCxmrdQf63DGBYjPYUbU8Kt74ZU64 idWpwLbvzwHGdT/37C3vfAwxXYZx8AbOyi1NfoMUZlW8tNEcunIIxbYGtv+X muD3yuivkYGGx5Y4rKs9LHuEtx0g7jm2HB4SFTlZ7I6w8ad9YmJk3aTff3gc IaNqCZTaUjFAmrEvCr4MwCTwzXKmCxtQ9bAFqhwu2orYkX6aVb3Ss7UwGler xaTf1VoOxqZv5rlY62aXZi+t1ystPFMYalmorm91F9+w67fTE0PT6a3s+uw9 VfByqaDutCDOH9qoCd2mJ3r2lp7sWoyarrW/6vffsKresWv2CKvtrS1s+V0P mRFK81qnh9d8mmlO1w788pud0Qlqvftb22vu3rD35oInh0xb7jX7nd2mz3Br WApQUzcPGpU/NNOia3VX736/vxyKruy18v/Rvir13bHb/dls6Cq9sgzG3rW8 vlyZ/p7pRhK7S70VUnVvSQJJyLKcAUluEoSsGauiiQgZu9vrh2vbJYvktWVd 6HL+b0nelPJhGcErLDYv1t+f0r137NFXJExWGEVpXn7/BQiz0sLclI0nzNOi PWhwHW0M5pZg152R7Com2FkunCSrKYLd6c/IF+zq/5Vg31th4HL7Wri+ZdfU TCSaSfhtBdK+dk+XrDBbwef7SzMeNU08ViA1iM3GG63oD201oLmie/3zSWpr Pco1qaK28Mc//1SstQz3Q2+motJzUcu4u65Mb5XdAOZf3xZN36P5Vx/qj0dT ap1/8h5wmoJ1t9q/gsBPj2vFkT9fWOdp9v5j+OhnxEN9ZN/6FFbwK9PtVd+p 08WVuvmpzhde0nhxgPbyV+ZZ1Wh96CS2AaTxnyBMExsHppWlqQvyaBKsBFGW Em2/nY0K8qN4xr8rDDnCntGSz7gdpq10X9gCsVT9EpkigMFOyclnUOfn50sw LMTqXTG63hWM9optoRgGSBiU5Xdpy0uEIGNQmatnAZp+bOUGs3EFOwt70EJT adTAmksWbCHPAUSA4BqiDDVa8UhhiXlfqX1s+Pi9/r3s+n5o1O6PZLD7yk4H hjubrklyFLXklBxxemGE0Urzdp3VAnD/Y9/Tv1B6JAswM6pMpgMYtnCwxRtJ 5kMTNxFfXCGrQYy+ipQqWVh6I19VLXL4yB7A7m65HoehE1G4I7yR4C7Lx9GW lwh3qi6GBW4pgQdx7xtJ43K4VuyQ6Hs+h+SsgSw25Dnke1RWExDVm3FTaiQ/ bsOH91uEb2w6SRQ9jOhCXcPdpXGCqGt4d00k1Dq4+XcWtoS9ccJUSpK1MVSL nGiRkG7/r71R4vRWynH2jiaFYUG9kh3hIUFvA2f6Ug3xwXdAb03telxAWj+4 OGWnBcyQmodYDDIkyMryUqQCEzGrNPvZuQEoisr3ng5B4tixlV4Tg7swSPgN Y17hWyhBaUQSUYLlcDZzhnlYsLdatWKzl0eTFTptTHC+GtZKUtVcz6Vwh/Ya fiXHgl/HtR7mzjBDVVe0teUxorux1ByrI9fQol4v2OvMFkX7Ye7fYF/BblxQ IbrmgoAWZCz4UuhL1OEDfxZ9jf3A5YKV/hm9wXiYRZ2vKq5usfZLKZ1XPzjH JW7deuBNWB7MMZSRYC7L1ZgKTIO5eiyLYcsVDeYJ/vlByMmUkdLT/EOlns7y F6QCE3u6r4t6sdoGukUkNT7I+lhLSu1mMiXfYSkzl1KqEuIP66pu+Nq9sH6Y tSHqJxtN5PvPBgmU3qr0rrMLugQ8Fw6lj+dHsJcfQD9LZ2Gbvf90zTVKwOB5 5+asbuzb3YUOjWqOQ3vUj5haJq0JiA7N47OAw+EpFKtQVbaLqUl8sOn+4rrw Mce+6Pb+0KWD44kEaFkueFRgIqB1auVQYSZPuDJsmC6wYoQ93xnQYEaNPYvP y5DDwv1fIrF/7M0XaFmU9KFtHQdTpBnxv0ck3TtozzqTlXoDr1AGwRzKLj9d 66Qtx5KWQnovWVE5BacSa+E1lDF8/kFOFp2p82ePYoZGzyYjSlONvWNEscDl 0J05uESwIMFSlnOaLS8RldpypTpRruD37ozdCFe4cuTBNTygjApYfZNIfqDd YmopakLLMaYsOpZnDjBqKAPUIALQiClc4aMSv5n8N1f1iNpL8KoOUlMwy4h9 h+2Go1nwnSyg3gd0W8Hq5wLfHF09HdowSmmdfVX3pXQhq56Up7hX/ZCELzTB JXzJ8ku05SXiSz1YYnLRsmsQO2Omhx9jukljGyMETHvEBnqpz3jBuXlLIkR0 nj1le2s/ISbZkRmYSHSIjFQGePCjQTPNljAMNpDU+hwIws2+39t0s/EdDat3 DrE1rlLWyfCkHvhbGbTVGkJSdipBlQxx88AQg4c2+aJgLkd/RMPMLpkTzJGB ClpNemXpQGynxSl47/y8u1HUY7AjwV6W1yoVmIh7WrdfmUp2zALRg/dbdlaY cgsAjb/3koiTy351OqFoURBClBMSk3OcIN5RkV/gCT1VsIpiNRjsKiVlhMGq JLIIIHgAQKcrrEdAXZ2CR1oaEIDupGFh08L5g50QRkh6+S8cQbum4kAVuLf4 dxmpxV6TQM0+wBi0t9bMX/FzBnI2lwyF3HPEDnQepgITYVC11oyAjCQ+gDlG tsj2PtyooakPd2rYvoiVlJz1MRev2Tf+ONNmCAcwUkUNhyfNzOgcu+iC9VZA P14uQu+V42Hb0+kaF2ggCZ6YOWDddmxmDnD2dig+OO9gZtuabDf3Wv8XT4jj gnWqq7v9roOPxrUl0HflARrDEwnQsjyRqcBEQCsba0YIRiRqlty2Jx5qlWyy VrZDjZLsW1Z35ZM4wKE2MnucnI/qkDQbmwobqxXviPHYOo1d6bNqtPRZQrMR ULMPh6k3BJslXkyxb4zDICCBiyaPzT3Vx+HHRi1CxzpONjlUGJu7Enhk+fVS gWngUY1VEXBhpAy99q58vsvj4bfM7LInSIKZ/TKgNQWDuqll06DuU28HHi3I HI99DYo2kb+d7YLjWC0RY/6qhpMxYZWLEWqY8AoS9PtfgjVZRxEDCUfJsQpR dhh/YnYyPLUxCwpDG/CZuQc6b2KGADu5SaFaG5Y4d1WLbipxjyZE3GXoLGzW S6iT5Zpry0sEnUGtBoAwc6Cb9jgIDjQT/BTBgfYytESZSS0tVEjswjgqiXWP JjdkdzdOlQ88MgSCEsjRCckox/pkJTm+FUH7D6YbrRnFh2IoUeBmSqIgl8TI 1ibOtXOKI0bOfEcrlBthq+dTWaJJFEQoymLtc0hM2NiOCnrXbh0dwvZhS/rN JNwi4JBwK8vX1paXiFvdaCn8Z1Yzkgn0nN38gf4AcpalExy8mbovQ5FxrKxp rBMgAAgpDFrGDoiCN8xBbC7M7xU9N3I9VrNsbFiBxNTZu0uG52aCZtsqIoyY oiZ5uG+7huJjrg475Z6VBfMt5hDbG6do+qMR0ybXagfHDWLLmL3hwcmQ7FC/ Tg4TEkxlOapTgYk41Q6WY4f5D93z1hNsfkiK5fP03qPocUbSouN+SLuLn/I3 8Z5a4lk5kWkePd7if5cOlhxdQ5PUyJoau4KyLEmIjBSe0/PDkw3w/Pww0kC2 +OHQjgH54egSGRl3icZfP1KSzIhG/Qx+2Xd7T/iX8POo3/vMHJq5Zo8JPK0H PAcqCSmzPOCpwESkbDpL3jOkpKSwByr90dOjznpg+sHBW06Uz8yMTdleE7Vz 1pnSaGY5DlOBiaNZjZZNzUgMdfz57N62/6d1XUrAKisnSWmb4jKGD3Ow6OdY F6D1+YCT7jF9a1sXs8kyqMI6rNRLoIb3MObr1cIp6BIHewhCThKIqK8IO++P mXx6qqLat21nBb+b8g2uQtx260zqWwNfVd1YWLwxsjSq1nCivARhGtSDnsKN MxNyXCmjR87CsXQi/exb2QGevNESfmQ5BlOBifih1GZeOdlrIv98kq3zESIk o29qwclupOBwd6IfGxVlHIC3zkeUkwTgjelvSaE9lx8V8/2Pbanv7EnJY2dx w+qk2HpDhkTJroDbh1jCqMUDbxBwh+dEamAHWwbvgfXWV+L1QKrG9EgjDqTt spzDFwquwaJLbK/DFEBCNrAcbVbBuKnmUAdfW14iepU2rIJ8P3KCdk4Fb8ca UfBBfWmb9cnu6oSORqg+pqfMtEVVViIagOjtaKp/5taM42bSwx4lYyqigCXL xuoN0vc2vOHg3b83jhtuvfBzsQaBPbNxMgGsrjD3DBhuew2bmMMPH5juJ/oR fkzoHPIZgPyG2y5ZX7Drm3sQSBgamAd4JQzkag915bXlpQGeGiiiAgY0RO32 qesrcVVpvgPR8MenG9I6M4sR6jJ6Vku29s17UxrNLD9GKjBxOHtldz2fUU7V MAeQWdp/Z8H+QzguUQcePEThae+RBeqkB0xODtf2j0XuTpzvGZOcmD5A+3pJ FYj44+CpmMOers5JY9FQZF5uVi6su4buI7ZZN/DLscKakbUA+jdF89VE64p6 MkXZjUBcl0yzrm1n2jKxFeoVRYhgEfz5kqxwVJFgLcvDkgpMhLV2tKwoTMUV ZwmQk3tUcmVtPieKLBUmI3Q3Tqj/Kb32HyiNOc7uGohKtk0f6+G4G8kUj2vI yTS8TU46mVe2p1EDmOppouaFQEa0o+PBNbLRO+XOhg0v3j86ocbb3LQkzhat SCic2DiEW+yBLRleXsMynAN3DG0kuMty7aQCE+GuGSyJyyxqxEjg88TT0ric yFR2sM+3hKjk8OC4yFj0oqSqEshYR/GIGV/kLTZZzEN4ixxsPTIRPvYSoazP GB2OOkHBS6uQANJ0zGM64SPFuBzgv4H42FuIbg8kJOcAL4YdEnhl+XdSgYng RYeK/FKxy50VvuCGIuuleMEBTdg3kRI0s7ewUp+gYdhixXQt+CD7SMJMT98N klohMjFv/75qZ0rZFJ/iTn7FLuyOnnoETyOlhBOT5szHaJ8hXjaVKrDPOo7r trZnUBLC4I9m+2QoOUnLwZCDjxFqD3XVVHnHCCk61uPn2RtiXuZrevRL2q6x nMe/obsVlTBSa5g/BLv8NtDBMvhJfAJKe6irmHJPQDnjceWq7C2zSmfIJfDJ c2+uM1hwtraLhpsmMXC19kb7GiIjpgZYVZimY5fsAToNHZv9Az7MSNYHsAWS Q2XEczxHh8XJ9LhWBpQxkHUaQ6iUt3meZ21l1xktQ0O3vc485jZP7wg4/QmN lrndn/RcbYuhK5vdx8S9YDUSr+4M6aNkI/aJeg6XghtYLtc5UWuiqTU3x9eg jKMZLaPGvPmitLUU27wUBfXrVYlsnXw6jPaUwtbYCnbwkeUROGWgJOFplrMm FXh2QB07S+kGeg6bgq7uTurw++2QiGuLu0yWP9ITzYiqBrPN/PNmt88EQNbW nUm8rglfUC3xqbw6637qy6iBUd9ZlNXM1u4goMf0BF35PmfukrBGF+a4YQWr /pmkm0mIJNxZnoS2vLPL9tA4dNuZ+sfWIvdPlqsSavUfHv0Pf7fjqGVuZHN0 cmVhbQplbmRvYmoKMjMgMCBvYmoKNjUyMQplbmRvYmoKMzEgMCBvYmoKPDwv TGVuZ3RoIDMyIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic 7V1dc9zEEn33r9gqHtilYlnS6DPc4nJJQiAF3JAYeAh5cPwVE6/t2A7B/x7t enf6SDozmla8udyqkAc62pmenpnunu4zLeXtJI6SdBIv/qyJ/fnWzrNycny1 tfhbMnn2eEVcHm+93aois/hv2RLp/fnkm92mY5JM6qguJrtHW3FU11Vc3nJN JmXS/L3Om//HUdk0mG+9mO7OtpMiKpMinb6eNY+TNCune5Y6s9Sb2XYZxXFS FNMrIe81v5u8MHEyncxe7j7ZerS79fNS2ngtdhwmdj1pZm9lrlcim7wvcjLb bhrlRZmm0wLoeJbH8UKG5RpUUZzBGuQrhrnpMmwE3/1D5L775S7qOkqz3nKf z5I0KitTT+ez7TSL4jLb7BqiHK41TDRrKAw3v4ZVGTUP+0Pd8RLZYdxLlKqW qCN308cMzrUsorrVZ0Bo294ttFEJ3RMgQOgij4pMIbRt7xY6UwndEyBA6DyL zMqrbM+2TZSXJguk0mL6X/vw0lInljomz84stWepU0tNLPWjpQ4tdUWoPTLa oQg4Yk63Hmhw92DhXLuXq3bPMlTsXpYuGyyE+JZsxbml5pa6Txb7e9J3z7sp +5Z6SEbzb/IB4fyiK2lSG+h8Qthck4Flcq+6PbKqnL4T3odCXgp5TskjIUE6 YHYl5ImQ+0J+vSSLqq7Watphtkc5nAoZUb7nlNnLpQabuIjyOmkUZveg0Y/J ehmCNRyUy6XhhUrDLUOFhpskKqpbIZ4Tl3BG1IFpuPR9R/qKRorK3VjqHuH3 hPA7JX2lR2KpSnaKsU4tFZPOMekRi4bXwvu+kLGQxZpMQ9UAdsClBqVKDSxD hRqkcZRWNoD02L2siviMC0J9TZ69J2dJREa7JO2+9LpLkUUc52vm6ESz2aH4 zKvZ70UNwLsBeS3kl0JOhHxKHRI4ulPabVfIG3F0b6ibOqCOjouzSznMsS1x dN/RSVzRZQARzoQ8pt24jN/Tc2SPtv2R+vCH4pjPqTjA7JQsZLAhgw25DLlS GbJlqDDkRqyOMxcHKmf2H8QgxHL8rv4Z6esPep4SStr9h1h77wCCHWGxU1Ya CDaFd0a8UEu/LfmopzAdC+F6xjUKjBCU64YyS4SsaYMnQ56C803xeCJmnODv WlVfa5lLz2uVnt9yC1fyvO6mvH5xpX1b4nIstNMXIEDoqojMSojvyMG1DlWC MyRk6JqVCmwRhopZlfmSafBW2PZuoVXwR1+AAKELY5EB8WaPSFwhPuwnSz0k PVjgIPHMEfmVZVdz8uySUPKrRFSf987UUc74N0s9lmgHvAqc7RD4nNKnPI+y bjLU2eBuuVRGBT4JQ4XK5GkHPRgQ2rZ3C60Cn/oCBAidJVG8ikge2I19TU7Z Q6JlokZ61wQDu2avAm+EoWL2aW0TKxYb+ECZ8JnCIK6ZqpJ4YaiYaVJFGh+8 bu4WWZVw9oYPkDgubwUQgPOMbJE4YoZ96XEDhhakXn5KsKCdbF4ThhKR3vcK Y+GkErNGiDzv0ajvztIl8drLZDM8XWoN8S8hX9FuLcSQRKkfDTvsJqabwA7L Kp1+hetUxPHiljPI0awtxmWyqtRyxS3cYLM6tyG0BB0sJBGl76eHwW4Vh3NN WJVjCEPFnKssylaO8itiyncSxeMgSWs7R+YmwlAx09LYqBxnGjQB6OuagCoN EYaKCRSJvbxnW/WCqCy79+qhh612AkCww4W1EwmOvEYzJz0gQe8dC4MnXQ8h B4Sk46PBvV1Q73VKn4KvBK8I4f8VHe2IMrukbed0iCtK2gZpG2l039R05n5M JzEI6kyGVm8kMPpS5hNoh2ACLjtUZdbCUGGHeWzTHrUjgb6uCajyPGGomICp bebCHAkDP8V42TX8AelxSTj74QL59Z2XyxkZ7a+eBm4EGoDQh4eIQNq7s2Dt hn1xKYcqnxaGCuVIy4joRpD80tUlviohtvwU0idF5IxmlvHK+qE/7fJf5rIU q/7w46tda9IfpPWzHJc91L/VWbRcMD2O+O/Qp5loMRytOT0RRt06BFuHbK1L u1QghOWn0K44XxSXjjMO6OuSX4VICMPwCZja2JRjwD4ES2PlN6dMJdnJ4AeD BxiyeJLheexoEIsTq3hF+rID5vep6OkvQj6ntvKAHgkcS+Dh1e8zcmjw+7OW EUINSEHIVtuMtq2xLYkijTSFqzZDGYSZAWqgywxUWb4wVJhBlXqS3n+CGWxO pxvyF0vJBfqOe8YfS51BL+F4iWlbUGdQzJq2NZSMKUmLQdAdAE4J+RxkOhxT g7Y3bKWCzQc012U+KsxIGCrMpyESJxDxyXw2az4pgibcJEChK+nGTw4wNX5y 1LRtOc58vqFThqwKCr4A375gyxNsM6CuSctORqKPwlBhM3lNwbugCUBf1wRU 6KMwVEwgq6LMCRq0jF6Kna4JxepuGX7AwjvhvE8of5E/c0rnXgn61tc8/CKE WqAGX0hvTn6mVmTYApceqNAvYajQA1N6wKOPpAcC5zz88P1t9f3M4/sBNm2d IRdkdjeiCCM8Fqyxa6NVKKEwVGx0mo8FgqCrS3wVjmX5KaRPsih3ZrqoQQyJ vCEa9I60Y0ik/4pENIRdvgTZTlsN78CJLpR0v8fbfQ3B8VBenw3M+GX+rfEs 7995hRWvvz6kzOCp626bBCi8IH0+NBi/ILmk3d7SsIavNGxztN6g0JtWVHuX 6akwWGGosL3YjIbJsK9rAiqYTxiGTyCtk6gaeVWMfV0TUOF8wlAxgSr23ur7 gxgGkrPX6Fh+JrVO+kJ84fynx4E5QHJWV+pjk2EZ0VNK8vp0aACAYEq78RtQ MPBz2g2G+E3Ix7TtD0Oe8hq7Ee/H8Ut+pQXjDoS3oaEOaqrLXFR4oDBUmEtR U0AjaALQ1zUBFSIjDBUTyMuo8tzoBr1+Yvi1l7quCYVJWzn2yHxbGCpWJCto uho0AejrmoAq3xaGigk00njiV8Cj5A5ynWm0WsoFYO9y2xERs4txecZwt/6r iY22sPvSPa/S+d96ZEAeL9Xnr/+Bd3tDu9nQLdh5yR659ESVj1t+CjVJDcvS wGTXD9mhyZb5DfEQ/1b7ABHLtTKqBNbyU6xMktIMMEh86OuSX5XBCkPFBOLE fmhmwAVIMQB1AeL+2VvMrFYvKHIyQ9U0nqIhyIQMR4UYcucpMFwksbz+AOKX gAjJkjz/429C306vW0R+vJYs2Gpgx11qp8rehGG42iVVTZOfQJdyRDZVdE0g tx1C+ftG5NmHvG2/Q/hBcv7K2xDek4eCRigLgND/gpLQlteA9i2lo3UcPvDJ sNRQkOFPIVNRVrj8aeE7JHk4o00H8ojW9dIdzr3Ft/VqsCXZC8H80xYtDtAt 6q5pF/E6EnHCrB4NzmX1KshDGCqsvqwa9Rh3WmJf1wRUkIcwVEygKD2X0q3T 0vhPS7nVFS/E3neS44sdVf5S19AT9Neexhv++uIJGZjhM9bMS9Tk1hWuJZ/3 BndDvryGnFcBHogvApPnheN8COCLlzOuF8PYpfRMezijgrm0XIVUCEOFlue5 J9H/dDhv4HB+TzV7oEHrKBocjZ1V2sOM6Dg0zSmvkg7GbzAgVNjAEQhq7bIt FYgmDBW2lWVRWFUTPVWYPktDwUrYUeKvPTogvwoXZpfS94S068ExsL+GQ/09 8Re2xd92BZ3R33zDHqQttG0kdGj5KdTAGAa8BUkvXV3Sq3BDy08hfZrYr5gO hEHylvb/LAwKxSa/7QUELWOYEwFZKeCvXbEWWjwIIQ6GIJqLJAiDbi1uGQbx D0lCpSicMa+pvNxpw8AP2AnR/3xchxdfHP4mI0Zi8No9nH4cdt2hK8nf7B8R toFBuIxSBdIKQ4VVJrGnGuVT2NYa+P8mbOPRkc6WiVEOWHXqwGc+1JbvGD3h bTcQOoJpuexbddUgDMPtGz4JPyZ0DK3m8t+U3c17jMrX8EG3DcEZDPmmzMK+ QSX0QSKstmvHVZczne/vh2x4VdrPGmuDROjqkl6F8Vt+4dKXBcX6iGbm8vCf DpX1K2VaP6/qZBafiNgj0rDcaWRlzJ3GiyMLjzAWG/wCLr5xQkuE+Dc1Br8g wUtGN/VhUb4Q4R8WDfU+YDwu+1Wh9ZbfVP5Jjp+3/gYMxrn7ZW5kc3RyZWFt CmVuZG9iagozMiAwIG9iagozMDk4CmVuZG9iagozNiAwIG9iago8PC9MZW5n dGggMzcgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzVWk1z 2zYQvetX8NSRZ2KInyCZQ9o6TZx48uHamsmh6aGRP1PLTmSldv99SVvCW5EP DNZ1D40PeSaxD8DuwwJY+msUmySN4vZnDWbz0eSgjE6vR3ePo4PdFVicjr6O KpO1/+4eSDybRzvTxjDJotrUNpqejGJT11Vc3rMmUZk0v9dF839i8iqazke/ jZ9tbWemKLN8HK1Qah3Mx9u91/n4xKGlQ18ceurQhKBhW0Oe3Th0StpdObQg 7SaE79s9Sups/Gmw4arjvCrXjK3NBPAc8AuFou0N4FFwg3Tt/qDePgNe9ebY abugvJdbv0/3RllsTVEnjWKmR41Alnh/TAnE01tAYZYAxnRqfwGmgBVtmxIy 3sUGtMNP2y7auU8O6qhZhG7p1KuVkxX9ldOMpGlU2DJN2/4dLreKOL4nS5Jm hca5WIrFirDIuoTNApt+Dlu+cWzS+zHMnFovHDp26A+HLgeX2FFved7lgCCH YCw+f1Qqf6z5wt1hq8qEJTOgj2PirkvikGPyDDRvSR5iLAjE34QlcSglb/e6 mQvBbiXMCEETdztps5lYAB+3sALCAi687Qt4rQm441MEvCxNkfYjHjR8YSvH L3GsGr8jVEzA2nar90h2Q50WD7dIy3dEqLdki4XFIXkLW+SEa20mkJPyeTZR edYRKjxb5KbKH3yyee3QPkFo98GhXdYJo36cVIGVbcnbgVQh+MIjKpzpi2iq iqgjVEQ0bwZt//OI7pG3h8TtsDgnYVySIEeEeUg/+fhNVwxtpr4mncDkObK7 sLmg8Ed1yhch8OkgU+nAESp0kKUmIToImoCw9U0gV03AESomkMam8p5TpFIX 3fh7Esn68Ncsgl8GswtokA3YcUbsO+gFqQQSPO+NQT5jx050MiHPDrvDb3V6 AiguE+KeJJTOryMR4M+07QzwDPCcdnxMzUSDB5ylhCR8uixUunSECl3G9UAx wKWWBp2RCCPqi56tZyd8Q4whFMjtlti+JDr/RljYfrok/bLVgt7eOySuzkIH l1Rq+1Rq59Rs+b0Gp7SLD4C7atGJePtEZ1Wic4ThoivqygwcgJ/3ArShpUeX 5JRQs535FekOnUB0s9745dGaHez6J4LgY5rwpS+eqpKE41OEs7KmHogn9rYX xOcviQU2NFxO2P6DWh/b7tgVh218GNVtN15iyW8Eu3cKy8ss7ATayRFiWf/w mPmEF+sE71vA14A72nwiY+/Tn6oEBEKFAMuClgTWaMchnICwbxwTiwOyhIFO iIX+yISj0CvSTqT+M9LdOzIsJs+ebXtJEAEX6pmpYy/c7ou9qhoEQkXsbW5S 751fOmBJUOiHCxZJll7QznQj6dES3vZquG1QQMN2lbluqG3sBbf4/iC+E4i7 ovhYwvPJFYXi6D7vktmqrtZD7CSy2XqQwVufCP3mbfSB1TwQKvRXpAM1p/+1 /tpDyKPqryMkoT9+/+rnwE7KEqITqlx+j/dfJT0Rb5/oVIVOECpElycDZTEZ F3YwvujGZSOmEOInYsG2zQVhYZvlnLD01CKC0jz8ieg0dHIGSU9c2YVk5urY C7f7Yq8qiYJQEfssNunAjf2GOIXVKFn81rEPv32Iwfg8oioOglDhkaQaqK15 vgEWDpUO1aTdPlEbHPbnoMUFsZ31AuAZ4CExvhiMLSL6hPCxA38qbwQC5oAV oPjMXgJaSRakGREun2ZU9VgQKjQTlybsuwIQhJI5lMME17+699rTMCaobxy+ GjEpn2NVBUXHF+7XvLZDpR2ke2wBc4IeJTmJsfjcoSp1OT6FO6p8oDTi0RkS yHvyFpdZ7LGsWJoSlAx3vEu8zsr5w38MwfIk26mhhSc0CfEKBc9SNU1YGWkQ mqVk5HzqURXWQKiQT5kZG/ZBGwgJBEnFwgTZJycmNE2lxISmwEDXiln5XKuq GYFQ4Vqb0rpB0ASErW8CqsIHCNcT4ANwg88rY8WOt51ZEzdX62j1V3ubnzYf eBvudvJiOvq1+fkHmSaYc2VuZHN0cmVhbQplbmRvYmoKMzcgMCBvYmoKMTUw NwplbmRvYmoKNCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2 MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTQgMCBSCi9Gb250IDE1 IDAgUgo+PgovQ29udGVudHMgNSAwIFIKPj4KZW5kb2JqCjE2IDAgb2JqCjw8 L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9Q YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSAxOSAwIFIKL0ZvbnQgMjAgMCBSCj4+Ci9Db250ZW50cyAx NyAwIFIKPj4KZW5kb2JqCjIxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv eCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyOCAwIFIK L0ZvbnQgMjkgMCBSCj4+Ci9Db250ZW50cyAyMiAwIFIKPj4KZW5kb2JqCjMw IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9S b3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE RiAvVGV4dF0KL0V4dEdTdGF0ZSAzMyAwIFIKL0ZvbnQgMzQgMCBSCj4+Ci9D b250ZW50cyAzMSAwIFIKPj4KZW5kb2JqCjM1IDAgb2JqCjw8L1R5cGUvUGFn ZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAw IFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSAzOCAwIFIKL0ZvbnQgMzkgMCBSCj4+Ci9Db250ZW50cyAzNiAwIFIKPj4K ZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNCAwIFIK MTYgMCBSCjIxIDAgUgozMCAwIFIKMzUgMCBSCl0gL0NvdW50IDUKL1JvdGF0 ZSAwPj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMg MyAwIFIKPj4KZW5kb2JqCjcgMCBvYmoKPDwvVHlwZS9FeHRHU3RhdGUKL09Q TSAxPj5lbmRvYmoKMTQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTUg MCBvYmoKPDwvUjEzCjEzIDAgUi9SOQo5IDAgUi9SMTEKMTEgMCBSPj4KZW5k b2JqCjE5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjIwIDAgb2JqCjw8 L1IxMwoxMyAwIFIvUjkKOSAwIFIvUjExCjExIDAgUj4+CmVuZG9iagoyOCAw IG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoyOSAwIG9iago8PC9SMTMKMTMg MCBSL1IyNQoyNSAwIFIvUjI3CjI3IDAgUi9SOQo5IDAgUi9SMTEKMTEgMCBS Pj4KZW5kb2JqCjMzIDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjM0IDAg b2JqCjw8L1IxMwoxMyAwIFIvUjkKOSAwIFIvUjExCjExIDAgUj4+CmVuZG9i agozOCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagozOSAwIG9iago8PC9S MTMKMTMgMCBSL1I5CjkgMCBSL1IxMQoxMSAwIFI+PgplbmRvYmoKNDAgMCBv YmoKPDwvU3VidHlwZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCA0MSAwIFI+PnN0cmVhbQp4nH1YCVgUV7YubLqqIrjRFotoFRoUcYnGHVdw AUXBFUVRIiIqCkIUZF+a7mYr1t4EhcY1CgaFUIgrcZeJGo2IS8YliY5JHGei ySSn8i7z3rvVjXRPvpf3+dl03b517z3n/Oc//7l2hH0Pws7Ojp4Tl7gjOmqH 9H2M6G4nDuwhDpLxKFj82+9j5IMI3wnbexU52vGOMt7Rft/AwZSTGNkP2vpA Sl9CZmeXXLxnTlx8yo7ozVsSPIaHLFvlPXLkKOvIhz4+Ph4bUt794jE3amf0 5u0ew/CXXVExcfGxUdsTpnnMwbNjYqIjPTbHpMRv2ekRsXFj1EbptZURMVHb PPyjY6Lj4+N2eQyf4+0xbuzYD0fjj3HB0bEbEnd6BMVtj/NY5LEsanNiTMSO /xgkCCJokV/K9sig2alxG4PnxEctnvvxpiXzdmz237llWUBC9PL5iVtXLNi1 LSQwKSZiZXLshlXDvUd4jBo95IP3x4z9cNi4meNnTfCdGDZp8ropPlOnTfci iNHEEGINsZiYS3xAvE+EEUuIecQYwpNYSvgTY4mhxDIigPiQGEYsJ+YTXsQK YgExnhhOhBCBxATCm1hJLCQmEiOIVcQiYhIxkgglgojZxGRiNRFMzCGmEO8R PQkHwo7oRfQmZEQfwp7oS/QjnAiKUBAc0Z/wIBhiMOFMTCdcCFdiJuFGDCDc iYHEIGILEYyjiV9YStywm2l3ucfUHs2yD2RJshb70falclqeKb9HDifzKJJK ph7QofS194Lea+2Z1fN/HNIcaceNjpd6JfRCvdf2PtvHsU9In8a+U/tW9X3b L7TfbqdBTrsUrKK1/4j+hv7fMqOZQ8wRpo350Zlznun8k8sglzyXG65xro/d Rri1Dhg7IN/dw13nfnXggoF5A08NGjWocdA/2JFsMlshvu4tvuYFMVGwg6nN UNskg42iiblPVuu0FZUqbQqHQsiUHHVGpl5dzT3oTJwlPWVmSE9iAKwjqzSG zAy1MpVFE1AtZV4MvAQ4LdjpYANMg00y0ReWMJeRl9zmVRhLmnTaygqVNpnb RKLVokmO1pMpKryPTvrZkUQBnYnyGDJFid8wSEMjyWo9fiMHH2k6eQG85FAm MCiLBAJOy/eQeGcU3CxWCXatMAN8YIoMjjvPRZ5ypMDbqjIz9Sq8SAa2S1dR odKlcIEk6MUqeaV1WSQjUy0HrOIukWgieoamwDP55zYzKDJZhWfo1CbOvCU2 9rkQLziBkwCHml0UD2GaOJHxlSyRZlVz9eh5OJlsWdXEgYvV7HAoJ48JBuNe I604deCTWkOD+2e8SX0g+fCuih18LI34aMpqfQ+yynKIVC4atOSjeVfHB21O WrSUxYdIE6AQhuFTPBNcFA3iVtGRiTi+siaYp9GAkaOQK+r/4xhwuXWr5ngr 94lpbzVfQeuV+hxVQWGOig0NW7hzDp7ZY9b9f4HsQQf0eNoesbKUU9xJLS5X V7rv1upNnKLhJaW4U63WZ7GKhnR1TgrXjZp2QeyDQfM1zGDgQ/hVru9M9LWJ s7fVedFi4iHpqaJSehpOojHoDfoQ3siHS1HOyJTsPNSZGG11sfS2wfx2Mucn JupIGI9+lVvcjo2OwpjtK0GtSJDhL0yIDVqukS877jz7cv3ZyXXctbrDDfx5 +qnfFyNYZLRudpEUUBQDUTCFunc5fGlQ8EeTOOSFDjGQBt5UG1+vPpbcsGv/ Zn4zHbR89VzWvPEG6IuB5yRtfAK7O1mMwwFHv4wik7U5FZXYWexFKKXQRfSD fLPY8zWFnZaRiT3GKk4txwkCV+AHuTlmop3ZeT3x2S+IcxjkNNQL9UH93g4H jKa3/4Te0N/rH6g/t8H+X0+mvj988lRPz8mP37559vhnzvz+DgHeCmBfs6/G 6UwziE2R0NtFkSmmiG+Y0dYAXERKck37sk9n4RA7jMA7cIpW1Of1MHB4cO34 V2dYRca4V1R3iBSZK0gUB2+ZN4+meuKZXtOmenvNwLs+evxPtjvkPwtwR5CJ Bc6iqZ7qDijylnAu8YSJ6+iMJNFVsUg+mEy1eLuKuyiF1hYYVcbu0EaScLWz qMsvWsHuC7z8DrGUWXtq8cEF/Hx+8cfhYRHr4ubxwfQUCrlDH9QHBt5oO3jm HHv44O4q3kAbc3RKVW6BSsOGLAz92B9b29PrLfTi7lLg8LfXIHvxeGVwCVuU Vq6q4OlKraGKA3uqSt3FXRbygA8EeCRlMzZQxLF9DZ44tqMkEyRUSSZUheAn TCYGFV4gBKMZk0kOJhNvKCHPLLgU+5Cnoe+P34MDp3gMDqNfor6+ofH+K1nw v8S8feDnPWaar/fw6fdfvfq645+WMMJsAUYIduJeCGP40wU16ce2PJ3WOhIb 0N9rDOqNnH/zBPeX4Hi23pBjyNHkFeSquchtsxODeETw025n/EoL9qYf7l55 zb/mO5bsHUt3O7FVECeYwXWPQRzqgVyQD/IB/Bc4GAT24AITwBcRwKDBGGRA f49I5IkGjUIUkiNyNFDgAR7f4z+0Ndsl2H9nyTbbYMaR4PwGLzmEu0TBkGFg j5xZFGetG/Wk0JnIiInwPnWRb0g/vkXYcHAxv5KeTQ0ZP3zUH93fJsDvOM8w nF+LH8FzRvH4ZlhI3Ux31GfkWOSAHP4+Bno/ulx76zSHSoZTqRZyN8dD8cpk iUgyp3i9Uqy6YB7pgtloUvEYBcRjbJvjMNxrBo7Do46fuHc8bgebsGmlmD4h zIbzw9rI86eO39on5BUcZs9qeL6Yp3fjbfQaXWYxF1Pur43i6Q8XrpzNBU+g uqn+O/Tc24bJ/kpWGbqIHy3pqhzLBCixuPQJ3tcH0hiYTgL5vOOHHyffHcKh ozZU1Zloy24ZZLdViCUhzR5KIIh6dGt5gP+cZRO4LqJa/I3EkWaq8mz+TUhq clGcx9tgfvMMJ1N0OZW7dfpqFlyoapU+K0OFOSoceUIUpWiF095kqlZZISUK C1ynH/UnJ1FkiCEwgazW6DPTNRLJnccB+pJ659EYvPscnEl3IEZiSVpKnixz Kt1Hz0eanyypdBuzgc5Yma1L5ZA/fEwqGt5Aj1MHTrnv52uyDyZo1SUF5ZLX Dbux11MruY/3JRq286H8krgPptB/gM8XAvwNs2EvCT5B8B2Gz621q+pmuyP7 0aMRjagfR4J9+4W6W2c4xFABK0ICWPQeaUURRbbyJ6qON9Qeq6jjBRovMvwi pXjVjQczjGbEM686MIxm+X4w2g/DqKPjR+6PdcmzGfo3yWwdXlFhdXhmZrfD 4UtvKrVcWVlZbvF2yJ95+w9xt5QBnMtjoJ+ZtZJOwfEzLgqjOFdkmC114XuW 8bTC33t2WOC26u1HUrgjqUfUHerL6sPqwxmH06t28Am0wrgycOOESfMaTrNa SuG/W2XAJT5QIkVuCn5O1qoqWUVhhVZn4oxU86Zzqbcww8mfXX74aVJ9zH5u 274o42LteL2mOLECr7WrIruqakDz5WMdDz6P/aiMVQxJK9aqdrtXaA0YK8av KMUQXA8zWYUxKwfvYPFYVxUz++yQlAi4go2yGn2x07TOkkgSbsDVKgnCQUca Ky7d+KTqMu/WxO/H2unQO+0UTlnZycXqtXDM00/mXx0THJEQHGqpaDjpIbVL SZjDVcrgTR5saVnxHE2kr1iJIJb0gcFxJxa1fH/szFn+Jv3NlLtYTxT9aZLO tL7qS0KpPaTCaKr9dsjiwKmh3l3kv0iARqnciQ5NMlwCopg90ln37DZHeKVE oFnpZhs4NIJc8fFm1SpcGDzHP4WB3D2Kv3bkZktTY0NL1VX+Od++oSyUTi3H ICs3VLMvKVOeLj1dg4tbBhV+YkX1Aj6QX5IQHhG6NtaPn0P7UWjcr0NhStuX 1fVXu0TkL9gLY5plsBrnKjhQJk3XAsjBz8prHWg/6dsW9sM3QDYeNaiMytz8 gjw1u2HnvNTlPO0f8WkrBzUQZ9UU77jgJ+hhB8dwfO9JVDDexlE90XM0waaa /LeFK83kO5EMF58yWWpVCreMwmjczR4izWi8gpWVLpPtyoGpoIGxcYLT90JK C1xtcVEMEZeKlYzCKESEVy9xHzI9YEJE9cb6BK428UTWV1l3M2s0h9KPpFZt 47fQfvNCPsCYH8v7tebfKtyLWZ2ncXJiJpJTyTrV7kq8HXuUUhjDhGs777iD 47d3XrcmtEQd5GJMcbqZFUGGndr4qp1V6bV8LX2z7fyTR23hi0vN2C9XV7hX lOuquZ8pqU8ye/OPNIEhLy7AHIHSQmwwO9jqg3Vi4kEJFZLMwqhwsJbViygK HYKoCza/9rSKsIOdieFkkuqdlzlrFqyENPKdhnxuKRCfNEe8dVEkiAudH1g7 DUVytOiIWdsm+JWk4tTi5Ytj57uHRgrnOLg0ytqkXMS/Tr+w6q+3rh+5eJnt bsikwIuDsZWDcWXtHE4FrAlbwKL+Nl0ZQ768cfMHTlyK6q1AAyXOxMzuwFew B8jK7sBnsDYNCExrBh8MrPuCJDF8ZlNp+uzdleU4akB2rkUklWKR5tXsPZjW mTjExs2l5H/i1KxxLCA1MRaXdTm23apkMUUnIs4qC6Hdykl4XFpoH4BgVwsR wMAGGbxwhqmio7zJhr1HWvF+m8RNx3N5Eom84bn8prVDtJ0kkDC901H+LpnA SdL94NaMu5FFaBAEuyg6YQ7MZ043QgCaJ48nFf9lPZ+L5XxKbGU4iSJhPe7U XORnSEWndS9n6177SeSH23XRYZTVUxc6TSutM15Z4CNqBLs3lmYgD/ur3nxp sEddniyxVYpKk47dtReX+pfkuHnzxo/z/+oFCy87/qNlSMnBs8wSEc9C9t+O BznInj8He7Z7BywHz0g5gnf4u821xDmpKEjXBRgq49Hv5IzAoKmr1+4/HcqC M2VS67LS1apkFnlT7Qtad97k6Z+/eWKW3O9i4wObwEcmBjk/xaGptglND6ud 50l/dG8c6OSh5ESkmwP35J//3xNN5DMcnVbyBRhfIqMlTGKhuapZ0PRGorzu 2wXo2Wn6fyjvXW7OFcBVcMIAv2aRw6niZOe/26Rn+gqoIe8GfP7BpsCMlBVs dq5Gw2fTSl2Osbi0qKiUfXTgiPYET987v3UNN5dasiemfB0uH/0mLpnAKc7N +mLVD3evHb7Sxp6yn79opXQJ4B9e33rj7snfWs5qlCcsvhILLBc5frBeBjXO V0iIEk3yOgmkFXtUlkgnqbv46BGJQjoT5fkkChYT5Q/Nzf6enPIUM5KVZjhU c3Xd9yZOrbAYTcGB6AOT0SQJwy/gCWxnYDKMk2tJxcNqCzrx+3ZWDjpDokHI GQ0AZ/lpc65Umo8hs3pTS+L1xqFFOA9ySMULqwh3s2Z7AIlzYASMQSPkgTaZ 7GqdkWN7v9PeBDObIt+AHf6Q5Kw9rmF+Vnlfj553X1tUmS9rjF35Fo0jpBCu NB47dNy9vi46kkN3Omz67TPS743Xag/gMB2v2xrFKcpRu+2Ez6LhOHlt7bml G7buWr2RTTy77cB6PoLfnhIdRv/xGgD6CADNLli+T7FIqO5LAFKR2WmyKS+v XpCK1rlnrke3u0Ov12+gH/Qd9Rr18Vuxbe5qDvz/wvz0cOr73tN8Rgyf/uTN m68fdyWOOLjmmWC3B8LAF8Jk0Me5jQRa9ARZpyfmrb9gYNRYL3jQUGuCfksu 64xHduJAeRBO8s6By8V4+VMbcvW01rQaye2wv00mfoiNUPJqdWr8XNRjI3qP 9+I9P33/NrI/EKVX6nm6Qq83lhYWF5Rx86Bf7Bv+N/632l++gt7FZUXFfClt zNFns+a1/iKDJXitbGVOdh5fUJLLfYX6HfWS+meP2Pf9Ue/8XL6Az6Oz9TlG g1b7SRV7F+w+g578T/zP2/4VAPYJjUq9kpfcbU7mY2Igg9xOaoryi/J4N6VS lZ2ty9EVcqWF4Bbhg+w1ysJ8Ps8NlzajrqzUqGMfg+wJkukzSwq0vJvRoDOW 52nzy7mpuGF2a95TVl7OG93waZX56sKCXBa5rZcDixlMn5mhzkmWTJB23gie zFxUUpiPF891S6/I2luhLa0xsjAUqiS+wYrCTizAPWQ3djqHWpMGTxAfYzIa hv1Qj8pLduiV1bxbNa83lByqh3LXz53NowZlle0ofit9nx2chfeYjbFxUZtr Yz/jDGRj3ZHGxpgjUdKisLQZ+uGS+TUmaBZE5jtr/kwm98KOoiq1MYN3y+Q1 6sLUNLTLdRi5B49qi4xKQ7Y0ru4a97WetZ3MQf3kk6364AmZinbIVVSWIcdY odVXFbF7IVH+E5lmHi3EKxkxGnT6Kk4af2S9lfElt0E/RlptGKmDfpKbxF2/ 92JKdMUlfBltUOqUOer8DA2L/vrvRXnqwlwcNqUhx2AoK6vQSo5Pb7IDubkv ENPgFwbGzwICyZBsFiLQeNYLa+gHiAAZyB4AAeNY9O0rhr9Rffvo6YP1n1Y3 8818fcr+6Np1pgB+IT2O4hcmB8SuS4yOTorAKby1Zmf99tMpt/kbtJlo7OBT rL3viyKDgpek5eWqeSU+jFJXoivhS1lwbZZ3ViDO5kq43eaOgu2uGdMESBGc Xgm1mAjSxUHOj6yzlpLxzfs+qT5T2ep2zDq6iFSGpa1P2oRk4O+6tVV5iD9A n2xsOHnApErex9ZVYZiV8zoMUIMyT1OQr2FzNAmVu8oTeLf5y0MCt5dln/Lj /JNWrcJNheLcuLv+z0437Gs5yiY0MAkbtyVu4engVa23rrZ8dmF3173EL05i kLCpyUVRBi4CU0JdOfvF1eff0Yr1uA70qjl6fcCLiU9GBC2PC9vEJu/MjOVT aJwbBmO5trKU3XP9Rsttnr7/5WL/8OS40WM4lI12ypdQiiXioAekyXINkcwq yrZIdxDiISwhOydBel5xbkk+76bhNXn52AbXgvxCzAS8ukyjywURrXZFIlqj ysvN5VVufH5RfjH+51qswVnKY6AUlZbQZjBAk+Ak+gjJ5hsNBI+ZoqKSoiLc Y39z/XBj65UB38360mvV6rTYSDYpLSOFV9KYN4y6kpLdera2/pzpMk8/vBa2 cH3cxogUbpcyrXANT6dmd6FecefV0wXTZ81aMGbF8poTazl1WV6JhqeVOUpl 5u6M+lSuNf5s5jncfFM/Pvnp9tq2Gcckd6b/JK7CGHVr/q0J+uHu9T4UMdDv alML30G/nNM2OHSbOm4Rq8rP0ijz6QCq+9JHoD4/XKc7xdPPrq8NXLb6I0St 4fDPlkuIanYz6sVE70qOid2XVM8dIesP7Dtal2CK7url+gvwrSRtRGec9c4w g0H9x9po6gVkd91eA/3PWSXbGpGdTKLkTlf5WgoOCgxKJzGt/So/KIE3SIDp AizBxrwn/F0Ad7z0bEx59Vju6CqNam1WMQd11MuAO2OR3Afn4GgWTaL4udXB J1Y2hJ7ceZ2nOx4cq5NSWl3IZ2dziWmRmev51fwWU3xj7KnUK/x1GiZQ4Hrj h5e3z632Z8OooUV+wfxkeu7VkEcGQ1FxDdtsn5mfWZjN00sjj5+/fuXkI84S 9SdNMGMfj9nTsxn24QIQLF5nQEPWWKxM4tAJ3BNn4upRVlZSvptt3tdibMKe vRo0bsj82d5LQw62hHEabW4xDmd2To4yszL92C7u/NbzaRdwOB2++Rs4gb3v 46EfbVLtCpW2RH2F3weYN7QwwnXmlY3qHPTvGBhkfR5FWg7ZKtj94zNJKIMH 5DIFpsJK3sDfrGo70nLu/qPTD3kTbyrQ5+pySwvLeNqo1RtNW/auDwzcsW4V 57toy0Qe0TSa8xT1hp6vH3wDxNtZz8bODYn0iWRLQ5hDLcbqPXuPnWjah2XK 3SsLpk9cNt8vIPTM03guT88XaQ5I6SE2meWuhIkNYjODJnQaCvMKNXy+m7mw lpXtKWNhklglv9lJz6KScEeH27ka9ji0UF02k916+dgUZoRVEgD7ewxmuO7n 110m1+DWVS7ESC10LKaTF6ID3GIUD9sbapvbBryY+mDkyKmzxgUfi/hqE6t4 MTt646oFA0Y8m/7zz8++fn1r44XZn7K+sBfPf3B9xdzA4FW+vsGf3/qq7dJ9 DjXYK148vbHM129+8DSfhW33O25cedKFha2Yp3s0w9lGmbgEOpmilOI0XoWJ PSjuozDf6WGz+GQ+pVRZpirLK8qVsleVmXIi7eTNm4dOX+A6vjj+LQ/v0TB7 CvRGPUfMnISIoQ8nv2y/0PRYYDWXmJ0fZaekp23bHLlrE0/PW3br62+v3Oy4 3frR5MNcaQ5fWJ5gpiFwheng+udlWQkX8Pj2TZtqt1vGjzY0xBy1lOtG6cUs nFfz/lNK6Etr9BYpMRsO/9nb7VDGiBNRRllBWUEJ71bOa0uLy4tLXHGzUYJ5 sjyvXFmGfoPVroA/DGWlZbhs8CWFJQX4v2t+uboUg4HPK8jNp9/JkSyLHCl9 J0d0hlKL8EiqESfW4Ca3poY82VNwOOnoKDj2Ioj/Be0zJDcKZW5kc3RyZWFt CmVuZG9iago0MSAwIG9iago2MzYzCmVuZG9iago0MiAwIG9iago8PC9TdWJ0 eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQzIDAgUj4+ c3RyZWFtCnicY2RgYWJgZGQU8kjNKUstyUxO1PVPysksLE0FiWr9kGb8IcP0 Q5a5u+TniZ+5rLIMPnPe8HbzMHfzsMz7ySH0fbrg9x7+760CDMyMjBVTFjrn F1QWZaZnlChohAaFa2pr6yBEDC0tLRWSKmEyCi6pxZnpeQpqQEZZak5+QW5q Xom1gjNQdU5OZrJCek5lQUaxQmJKSmoKSFtYYk5qtoJbZk5mQUF+mYKGs6aC kYGBoS6QMPLLzE0qLVYITswrVvBRCEpNL81JLFLwLEkEGoQix8DAwJqfWlSe w8AQwODGEMwQweDLwAYMAQYWhmyGm4yijF6Mid9X8f04UHLjh84NxtuPv195 zPxD5Md6Ub1uy8QIxzjvrN9M3WYcv5lv2H9neX19043DcjtPrfnO2P2o+0D5 voy1mWviZgd2c9TZiV7dFm0VUOVVECmf6haa7tbN4RK/9/aROWeX7ZXfcP7w hrPdHGBrvntc/m5wg/E+xKbj3+tE++ZM2T1ha/cyydcW134zmJgneUTKxfik /WbrtuoOXRSyKW1d5vbqI93febo/XV31nYHDnC3dLSzdo5vDJm7PgwU9U/tn yc+9LLr0+dXTd7o5Lu2Idmjsaumsluf7/rB7wQ+nxxnzhYQXfPf4sUD0N/Of Baz32Y5+X8IqfGDpd75LJ74ztc99IFHX29zT0B3YHVfo68IhvGDOXVa+n2lA veXzGX8cEPs+58cCVgO23xF/dBp+6LAqsf0O/KNTAWQZsG0Gmvea7Xv4D7Pp f8xY+b4XdS/46TKf8fvxn7mi5my/9f/mAq3jK1n0Y8H8777zfRax3eR6zH1z Ag8PAwMA9M4RVAplbmRzdHJlYW0KZW5kb2JqCjQzIDAgb2JqCjYzMwplbmRv YmoKNDQgMCBvYmoKPDwvU3VidHlwZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVj b2RlL0xlbmd0aCA0NSAwIFI+PnN0cmVhbQp4nFVVaVQUVxZ+BVR1iQhiUy6g 3YVHQEBwjbLEY0RpECVkNIqCiqxNKw2ETSBqEDVGHhq3iBOVRsUNFCGQOSgu oBOdIGuOUZMZPZPJmKCJkah4q8/FnHkFY3Lyp069++763e/exxE7G8JxnFN4 clpeco4pMd4vJCMtSRVNUtw4ZayNMs6WYrr1sLWAH0cWHe4ZRh1sqYPdybFD mkfAt85wyAkKhxNbjssvKZuXkVmQZTKm5sgTly6O9vb1nfSHZGpgYKCcUPD6 Rp6fnG0ypsue7CcvOS0j05ycnhMsz2PaaWmmRNmYVpCZmi3HJyUlJ6lmy+LT ktfJBlOaKTMzI0+eOM9bnjZlylQ/9pn2tsmckJstL4lPz5YXyWr+f5IQQvRz 05dHFmYkZSZHvZeSZczOMeUuSIuf6C37+U+dNn1WECHjSRQJJP4klrxDQslf iIFMIYtJGFlCwsm7ZCmJIMuID4kkIWQIsScccSROZATREhcymrgRmYFI7Mhs UkQukpeczJm4f9h42JTYPLddarvbtt0uwu4O78S/wa/nd/NnhDlCrlAt1AjX hK+Ffk205r44XJwJVY7WFFoBI8BZWWDhlB3gJTWhFw/+Au62mnkMErDslZkH P+ESMPEGcJZwsfAY6nhHBWiF4gdD0y0jWkGGOJBHaRtblVqpv5Yd72m09241 ft5588zahTr8jkl+08DQBZ2oCYnJjErUaRu/0ThaJ9MK63wWd5YiSpALVh5D BHTFregCW3k0CJCFv2Fhvy0PIQLoYQ/IuIcHg+Bo/XrQsh18FH/wsYU0pU2C Uf1tPPgIICltfH8b+FjNmKdBl/57OFq5x2POKzO7dVQ+osBDB/CcEqemG4A8 7BTQgh088soS4PGkBo5Ah1piDtP8hWnWsAL2gmwLLcoFCQM9kcNQNPQigSAI eAYczIWFE1/ibH0p8tK9ywZ3z+jQt+Ys73727Er3Xf2AoyF+FcpkGAIzLCNO M29FKl4bFO+RILM0ZSwTUltWVoZTESVvHI6zQo7OPR+t116Krm03tbt10IuV Nc0i2ivDpK8uGiZ4x4aFhsZ2/fK0qbtbdZ/NHP8IQ1gvvnjtuxFiWHUovyph khrhXFRTRicVYeRP4AgBd3PvGi/rtfeuGMPPRbiF0dh0U5QI9hmDzmMMhtDY zt7epi7VeXPOSxjfA04vOaUC8qTSMrqb7qUtWy5vqjM+mXEDOZbz5Elohwtw 7iN38INhT7r6qvSoEwrXJGUtp4l03eH1ZzZZPjy+44q4s0faf7+m4UtaQ6sL LRkH1+/J25UiOlrLc8BF2Q0uXD3rqCfrqOJqLZA86CxTZHhEaIoHZWGQq53Q ZmgNu7/2OX1O759t7Wzt+KyPPqMgpPwa0b2wK6h6PBVL0UUCp2+8cBp6B3mi Aw4L7mVJ+f2zF4b9GapTv0OlTGRQBTPK3li74ky4G470RUcMnHN0zvkY/fnl HaZbtJNePn32hoiMCBpto7WE6eIBJAyvsPGDzXiNF3zH5mJ6z+Pn3EOVMO3K CSmgWThV9tcTZYdKdpTpXmje25lamk9F/9VxU/QRc/zv9oeDrIQ/0DgqY5jp GNAPjtQobe3v41Sv0Xbdb2i4/+knJR+V62C8Zkvph3Q7XUiXxJtDRG1tHzMG TH/4ghX3w0Bx55jVJhgzSvsvZRLzEqDR/nwrftWpSDd08UVnDMY3v0c7GNNa V37jqj5EExGzOnRZ6tGGIh16CKXxh9LPm/+WerPwAWPMrEe3Qatnfq4xH7iH Fd19NcTLe3l4yIJVHU9+vfBV5wBJwAZegM2IJhY3AtzQWS2gV9mp2Eg7QJje hR6MJuNmGtDWeCCtPE9fnn+4+GohBEeP1vbUFJUV5bquTVofYUzfW1ag23Bg 24Ftp5m68DHa/ycSAugd+vdD9dX11ccv02bando4vwJDr4xOKtu8jx4Vz1Rb Lum0vR30bHZpjMgaoIT3cA8Gp/WENBs82Hh5GPy78N/CzMb4H6sqd+2r1D3R bNyxpWQzFVOKDzTp4SJbR1DF4N9uuQXOXIdqnTgwPyr+gtVsx5ywmoSBWR7q qyoOzNrA3stX6kYqtUzjB0aOhavjw6LM1W06eMqsHTQ4tD0MNLcvnbxZr9Pm LxyMoy6vVnVxmaxmCX0GN9Pri8Ho6oXMLtSYDF5+KqMV8AOsjYJxatCKw1LW sa2f0lMiNGvA5q3r6ImecyLRuVgHbsLe68eOdFGx5WSBsaD4/Q1b9PmbKTUU Ldk8Wi6Ifpf60FUHkyszRW3juqqL+U1uN+m1E5euiNp8mrFr88H3RZgk4Gww S9rGoMRV81emV9Z/ftTyRZmuaX/t3j07D+0bw4C2rrBwEKcmqsG5saij6EfR vwl1wM7iU8EdEkxgR8GLguc5EPpgjfjayhFXSqCBuU2go+BHwT8WdMjOopfQ hwnn0I6iF0VPEwruqFpVMUNIBDcOrsBjCSvRDSoHEANPDtaCJwMRPQfWezPr YmrPSxajWMWxWNko9W9kW3aFvyZ3VsgadGSjp1HV2KNXAALbOK6wimkq+9XX rVk4UnfU8vwuOD0830J/EmGc3/fojV5vzECfbXRLaZEOXI8J39ZeuPVl3Zr5 s7PScAra6tAhMGXRVhwlKnmD3XKAzEewkrUL+tijNWRgGMAM3dIlur/k+DZR 23Nx05mEaNfIuNVvLzDW3d6uw7FCKY7vmQZsUMD35/+C7oGxJfgzvba3veFk Y5sr2E+/g+OCwjKiE3UZqZti6SLxAxipKa3bVb73yMGq6vIGKl6vNr0zP8EY oP/g/zjcZFxWKq0rpP7tjL19wppVM1HKiIyZkOWfj74iuAsHIec2vAVvQpza GoYm5KuI8io3D/0Bq3LY7jXAOceUWgvMtsQeE8DeHtyHgv1+Bwdw/8RhGCH/ A/KVvpIKZW5kc3RyZWFtCmVuZG9iago0NSAwIG9iagoyMTg0CmVuZG9iago0 NiAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUv TGVuZ3RoIDQ3IDAgUj4+c3RyZWFtCnicZVd5VFPXuj8xJOc4YSU9hWBNuLa1 tk5otUq1TuBQpco8qBhRAgTIwBAgIYEEwrghQAIEAoQ5YRJEZgVnFKdaZxxa yr22tWrrbd99bx/WZt33Tux67/3RtbKycnL2+fb37e/3+32/w8AcZmEMBmNe gEgsTFzpJxWHS+zXK6hFDOr9WdRiJkCS6eppL9ZizLuWOR/MY4J5DvXvLyx0 ojYuhD8vgKPvYEwGo+fGd55SmSJBFBWd5LYs0C/4k+XLV/z/P2s8PDzcjin+ 946blzBRFCVxW0r/SBbGSWVioSRpk5snvTouTnTcLSpOIYtOdAuPiBBG2B8L Co8TxrrtEsWJZDJpstsyz0/c1rq7r1lJf63d5LZfLhYmSFe4iSSRIokoSeEW LolwOyAWRoW7icMjhPYAXmJRUoLCbZ27SPJ/T+8XiY/JE93eluy2X+rh5u3m J4ySx4Un/PUOhmHLtkuOK6URMmF8pE9C1K7EJJG/PCB5b0pcuNht5Sr3NWs/ W7f+8w0bPb7AsCXYAcwLO4T5YDsxX2wX5oftxtZg/tge7GMsAAvE9mLrsCBs PRaMLcdCsK+xHdh+jIE5YguwhZgTxsHexUjsPcwZc8G4mCu2CPuEbhHmgAmx R4zVjATG2VmbZp1hujLLmW8cIh3GWE1sJ3YH+9+4L/5PIoxonz17tu/sH+cs mXNxbsJc+dzsubVz/z3Pa555/pL5wfNvO25xjHH8dUHYAgPUO05HAgsM7aP+ VseYDrKQR/Ta8ugHqIi66ZLCRhEzGfvQ0oy0Q/ncVHjQgh9KqbSZ9FUllfxh OJsFzey+5SaZIR6ouSBBmRVUQKRCIz6TDstJiEMbJJCN5UjlATPlepHxdBJ6 TTKrqSVkqb68sAIQtjLVQT4qxIGfRh2SS6hgtBkPKVaZQDcBT+BnhhpMnYAY aYr7io+EOPBOV4baF0WY8YMlGSYwQkAF/ovg0vawOOW+3bwnuK7ooEKkCUjj OlI+2nsUq5XRPMGklkB38tDOqEQ/QLjvewrxPy7efdZdqYks55fKjdJaRT3g tjRYGi/tPL3hYEhK1DF+qEC6G2wm0HtPVkHmUG91ezfP2mSxtl0h6LigjXJt Y1Cfw0Wkolgbmp2WruSqlaLMEEAgHhs2UJ+wzOgNnofmsGrZZffN5quAgDw2 ssx8wlJR83H6MLQ2aq2N0fojrPqRCfXUURK9574c8dCiF0uhE3R69Z+QB51X v0Tv8tOl5OSV5WgxYh3ZvS0isqk3mS89l3YH3CVenr52l2ePdY5ytTGsUzBl kglfa0n48TlWNa4oyAd5gIjKqhjmUzfwnKJDymjtPiU3DTcWlgIjIE6WaY/x kTsu7JBVHKczx1chFlqC3n24Ds661FN3+gR/Hw4ZDkCny9BqFCkJWgkgNgY8 hQsga+TBo/Mjh4P49OZIXKOshb4dlONVp4eTUD7lzFGVUYvJskIDKAPECYP2 MH8mGueMgGCNxiebUOIcFcypZW8rTK8A1wm4Bu+KadL20wc052foAD+C7+x8 /qm/ICFQwJ/As4sCk6PTA5Rc+Ok2su1S9/CDka2IQMyD2zwP+3W38ew9/hZK OiDezaBWwI3koa1HJfuAHzjaKrms6NF15o8TcJyddVPbmtAh7g6rDwah4LBC KDp8TOYFPOhu3VsP8ZcPr0Csn4cewxVkxeMTJ8fBOGiSVq4j/iwP+o1TTrbE OqemKZg26cx5BmeoL0nOa2uYuCxiEVq4HDmgD5HTrbW/jF1sOTPIRz448Feo vHIIJdRU4QGmLCPoJzjPqJcafAf6ngSJuenaLHlqTEYciAOy8pS62Nbkm+AW wXkN55x/8MO19pg9PEc4RfPl4w7GH3RPr1FBJFoACfaYpb2nvkorqeVVx5u0 NYBotNQ2dgtaDnwdJAuL58cLsqIKNhEesd+hb9hghybD006VSjPuoddUgIcE /AY60uA7T1O9oReOnky1OL35HaZBhjO99RE4SLbk1xS0gMfgQvlA09WO7nFw C/Sre2StxwfX2VYCugZUk8p+kFWuBZ7EzE4cbMjSbtXRbO+04Jv1qipwn6CS HeiTMRiscNG1wx9+6hOK8BR1YVHSnwXBN78yHk0yDZQrWaUvKzQBorksTcBH ehyE6nT7MuhsdWZ8t15pBpcJKMc7BkatpWU52gpetboiuxIQTeYaW2dynShc kuR1kP8zjeogeVS6TyrX3irJZXi9GcacKrE52e5Ivoc7J6xWZw6iYigX8tQW PAWo9CkGudFFVi4riaergau2e7p7W4W3YvipCoUyOydGkp4CUkCyKaMvheAg r2BZTKRr0GPBy4ePW/rP8XraazpAD7h2uH+7HpGlLkFFCWWgGtR1dlmNZQWG Aj2w5FcWlIKToNfcbu20mbvAKGjNaVR3EEg340p26p5mjwDip870KN+tEYj1 mW/rYKOhsn+Uz4El8AV5xdY13N6iFFfzaqNNYSCC8JdEhx0Iv/mK92fPxvse 1sH1PXTXfvvdmfMvKhGmkVCVhGdsUqg20QT+CCawbSWlVh58nw1ZoEFVs4Zo ZnNe58EPWDM2unHZlWqw823jNmrSt+b82bgtxeoqcI+AEvgR/gzUqExf0Ljn ahvS6qk1dekNTmevQY87zpwaeBt+Q3JW5ML3WRp2fn6mrqAgF3CzgbZIU0Jw aoxyeXH8os1+IZ7+Hcd/OMQfi+lKqUkEcVxBrDREFFfZkMpLbs5sTL9MpLE5 3si9EjeUFxeZaI2oym/MpgNk26y5tYsmbozdGU3sPNDNR9gNabWqGVi5ve22 4cttorWNNIjaabGb18G4Q7PCSLNiKU2K8gJ9Nk+XmZ2p0woDjh5Ky9XosnUg B+QV5uvzifPoAntD29ErIz1N5zp56RXJCUqtHHAjVdbrfHjqnzgdkiba9d8Z L+mQnnYhXh3AUtEaaSqqLCwD3Ka3AFXhwFOr2WWnk9aMf1WSVW4/MoiHwGRS lpQklTYk2VobG1ptSY0SWhXPp9cnd1Ff18PlfU53p6D6n86cEcp/eiOZzM5N 0miUQAuUxUpjZFWkMRYcBQJljCQ6ThEOgsGmQX/o4HNPeO5Ys7AsvSQZJBIc 1Z7QsB1rvS9Cx1BeEpsz0oaiWQ3sQoupygwqQE2uRdej6s3qpSUUf/7kj+8C biKXu/wlY+GD4AJxsb/n2lB/alQXrz22Kr7ahwaEfWKMUWSNusrp7iTcRSva EJU4SuawwzT0qICvcM4EWqtkX8szaUEogTJwIM1RqzUyeVyGGBARsSf6+Zwh +AQtVeNn8qpUIIxAJfjmMyH3T56qtlp5AwOsjXhx/mhdd8XZKpqXEFioX/sZ 0PA7ExqmMXImDwefazQb7fAbsuAexepKu24YL+CQDRoUjWgW0cTOhltYM+Ps bLSF9jRNkNFogQ7ArsfUbjODirfrIV/F7sgza0Eq0OZrc7XLkMnlI1iWXZVX Bcq4oLbC0KUnzChEhffkG7TDH8J5qNelKFuv02eVKkqzSkEpMFSaT8J34QOX 1tulhja9HfbqHuq/LQzoRefaTo2S4H5FxbNSwoJ6U/Hvsis0YAcxcxw/kpEc r842Nut42q60alpJZPIkWXifeAxi4/fgQj5tpt6meZtOU4Wf0JXrgBKoshM1 sjUowWUDTFIOAwAquaChwnDaQCcpUOEnc02aukBDqiG1VOGODrksg1W55fnl oJwL6k3GE8X0qj0qvDHfqG0IgYvQSxeT2KguBSXAWGlqoeemzuUnpKmKLM4u BVwDKCmr7qUNxG8utf36kjp6iz9hzvh1kmmZZpKl7IpCUyFtATrK1fR0jsdB oDrdO4cGt8aMexdnlIOLBPULnlsUrBRqdynfWqkxyqXJ6eQ/dv0DfvDMmfOC 2n+LVKozclSASNJVDfJhMA7O5bSqmuTdRy0+tLhOrNx+0DupLqWxqb6uobig pMDAzy8rMAIDYe1o6B2xSgJ5+3G06mtl1lEhwXkhT1GLYly9BwXjg33158Z5 JcG1yX3gBF18Vw+BVtNTMy4nMzkjUS3NTAZEtPTEAL8YB1f6uuH8QcJx2kJz ePE5xtQk9LZ/mBbaX1bqjXZ/2VKWdoiPSu01qvwL6BoTzHhQkaoCnCJgFw6K jOUGQ3PjQE0XIAYbonfykZge3xqNn53rSWbcr1BVA64RsARvG+isHQbE5VrZ Rj6Kov1qVpavjl4kNePxReKi9FpwiguP4XBOxNUtviHxvoE8xWWRNRAIgFS9 0Zt4SFvTkFTamqq4jrThhlMw6DrjFO2RvWHBdbo/erjwDSlOiI+TNCe0trc0 t7bHt4jtDkvdMu3Uwmh6BStf2Rm0kQwA4crIaF9/IcIBmg0QoxPNPu1/UnA2 cQycBQM13V1jF3sgAeB8Aoa7w78hZ15ePDk5RNs7IRIK3NavF/wXjIDRQ5A5 xX9rzBlQNMWEg3RstMedpcZNJRXFxUW1hprickDUl6li+TOhOIjJSkrLVGWq 88Ltx9hqxjcXppWDMwT12u5owSOq8QED/jTFpKRwMZleEumXnnkEcFEWG26G Xs9fnHoEHnPffDHxQUCw/HgkL1akilV61ee49P7a3fEtICYv+234MmzVhrV8 tAv5sjIoV3tUauaqE7z3RHjPmXMeroTfk1dAY35TJsGpvyY/5bfLdYPf3u2y FENTJE9cqzQoaTSq1MnRA/I7E09a+k7zT/e1jIFvwNm005L2lIZUk8BCcM5/ e7r55AXXZ/surQ4VKGOjeGKZKl5+wJzr0nd/qPM6IG4OCbyjVFEJCXyxWKra nWjXHVAPl96gvqxjwGH6dSKOnrwfUb4CNvpmxpe1D55Amybgpt9xtOcGiXRs qIOv7G881NMnDDh9hwm/op6SMIRdDYqL9Iae5y6ZBlWyNieZPhwhGzGQlrbq BSCfm1OcZ+zo1aX38SAeef5rsIxYvn/blylKQ4OYF9uYVE4jX6LOSBCeTnw4 ec96dpQ/PFR/GTwC91KHQ0cFg36NaE69PVm1jXIYZpx4AYt/ZFJ+09tIxNb6 pu4IQdgWH8QGyBWss342ENojuJB4jZ4a70y9pMXi3R3PEC5I1gm9+Va4nJYU DK5pIdAxdIqcGvVEC9GsiP07Pwv8Ba4+a7TVmfn11e1lXW81OaueuveAQQVO f0rOsNk+6OOarIHbtZUXAReK2ejgzAvWTTaMnl7CepvatKPN6dKjnQ+g9NuA R86c53CAwknOxG/nu/pvu37nefVjxPhij/tei+Rfq3mc5wjzkMftdv30yW7I gvMmbv0xIRpB83/kKT4k7wc3RQF/Yu+RI3u3hoz9/UZD/9hp3sgEHWvtWNTw Jdexob7rtwcEu/ykR/yEvJw8AHLz7OlC7QDlYGO0/Qx1r5lX5CR0qLxouT3y H4/G4TsALiKgx2o4G5Fo7tqlaBFyvPcFxC72V/ed5x1DGxDTDa2IJ+AVOE2C lNxMTaY0MTI9ChBbDz2Ecy9XX61v4dfUNVe0AuLvQ+vRZj6tuxrIhIWQyYDv U4K/Ehwhh7+SPqWOCqqDAXXstjk/zG0zzpv3Q+28+Rj2PyLicGgKZW5kc3Ry ZWFtCmVuZG9iago0NyAwIG9iago0MTU2CmVuZG9iago0OCAwIG9iago8PC9T dWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQ5IDAg Uj4+c3RyZWFtCnicdVcJWBTHtu5x6EUEFCYNCjqDoAKKgIi7gCIIEhZFQdlU FARkFZEtYNxioqUxMaDEGEFQRBIVcAdU3DcUiMQw4CAykIxLriaYe3puje/e 6iE3uXn3vY8Zurumqvqc/z/nP6cklMEgSiKRGPrFJWfFZSaujhGfHAUriTBy kDBKmotT/zFFm0uPogIO/miMjKTIyKBsJP/ETFhlCreHQs4wSiqR5Ow+MC8t PTcjMT4h09o+NGSpw4QJjn+OTJoxY4b1qtx//2LtHbc+MT7Vehy5yYpLTktP iUvNnGU9j8xOTk5cbR2fnJuesN46JjY2LlZcFhaTHJdkPT8xOTE9PS3L2n6e g7Wri8ukieSfa1BiyqoN660Xx6Sutw6wDomL35Ack/GXQYqiAgPm5qauXhbo lZcWGx40Lz0u2HvdmoU+GfHz1yeE+GYmLvbbsHbJgqykUP/s5Jj3c1JWLd1r 72DtONHGydbZZZLrF5M93aYURk6dFj1j5ud27hQ1kbKhIqhgypuaQTlRtlQk tZDyoWZSztQYahE1n3KhxlIhlC81iRpHLab8KDtqCbWAmkzZU6GUP+VGOVBh 1PvUFGo8tZQKoKZSE6hlVCDlRTlS4VQQNY+aTnHUYMqQklDGlAklpYZSBtQw ypQyo2RUIvUeZU3xlDmVTc2mLKjhlAdlSVlRc6kESk4FETLJZDl54VdUp8RO EiPZN8huUMCgzwe9kSqk/tJqgyEGaw1u0lI6gi6klYyE8WLaGIFdzZZzZtx2 7gr3dHDS4KLBLYaDDe0M3Q1XGhYatg0xHeI9JGJIv5G90XKji8bDjBcYJxuX G3cYq0wkJjITH5Mwk8sm7UMnDl009MxQ7bC8YR2mJqaJptWmD808zZLMdpgJ svdkbrIQWSpUmQiNSKVlSySdGinM1abwTu9ShHAV1jEmWmdUChFKwaVEIqRC Gv8Yp9H9DC7UptDYiMHF71LovzHtkEbDF0oe5zNgBN20ifAJTlVp3yNrhgul PB6rc8SWgiPtyoCPrixp+sY1OQUJaMSHqGB37h5uDntwy8GPD6MKVFl4+Kuj hw4c/uosFGhNhotmlQqL2hJKzFrbPZ7Cp10WsjOtZEPZt7rSp3CWlbX9/Xrr swdnVwfI8T+7BGu2x//6OPfwFK9oueyMmiVmZLYLju2Sqh6pkARv+I8vb/o2 uzK+IaDSC3F4tDM2wF7Yvc8abMC04zG8V6SYxhRMWxnjjTjnJY9hGFhcVf7Y en6VV5FCD4TWm3hkJRjysBOAxlIGL8S1OBhqaUwzsB0D3qczpIHcR8ENiMQ3 aGAJhN8PrHysFvaqpUKCOcQIQOtArU3BPIsT3g3FydqhNObfpagFYGC1Dmjx dSrYo4J8lVmHBjo0QRoLmdBhDiqmBV0+VHuWk709VVNy5YYlUq9udDrFyYQH VSevfm+JGrPr4k7EnQz/yoe42MBo8EMe8sGPvYIqtx3JOZr9ZQpajWILktdl Z+SkbltKJvnhZzzsgWz2Ajq+6fB6svPhzP1J8ZYo4cOkDZkb1qdsWo44giVq E0zaJEIwIUBn5QUXGPxAZ0TPETzasJKF+4Ix4b1xAPBTPdDYI4Ujwike27na YG/srbYBB7DrewtzYIFbP56g2OXBP7/ugc3x0EXuzk4h7SADsxtKjULcRLmk VAhQgkeJ2dEeuEJozxe2krCcjsuZhMbFx0TXRrpiCZ6lkDVgnx4sgdGPLlU0 XZDL8ud/z+I8IYbvuzELm4o/Gy+aNdk56AmYgMmdJz/K/yAS6jRSwQJqeagQ gvVkxhIC14rEsgyc0JGxWg1rol0zMP0HtSBXS7WWxIzJOg2jMxU09DiRMTUj GOvU9FtC9JpMlfBKJanXSLXjBcSngpuzErshBzQ7OTR4wbx4W4QNETaqHtPi fX3Ro/QXCOaj1y8PQyg3gdkavjkxPzUlODDRnXg31hk48IdgNbAw+ta13LTj ioqMA8n7Qjk9PMJ4JUmKq2JSXO6xkH17FafyT+Eocz60YX0z4sCqFyRAwGkD 7ykwCCu8Q5ICY0lOdHiwsibIC+B/uj0Tm+IhQTNdJi/qhKEw9GanWo98O/g1 g1u75MwzqVAEG3nU+VF9fm3is1lXHIhZ4yaSlJmD5/w4GuzAqKsZmFKSMpnz o+L9UBhaXp52Pvv4tuM7r3C7m/m9r27de4o41T3fKTvQjp07SAodGsCnRiMc INiP0ObyOA7bYCecg3OAXGGNuqPi0i1Fx8M6oBEM4eBDrICJeK18hgG4/oKN cAD2tiEXJ+xsS5TGD/z6ycVJIbKkEu6qJL0aYaRG2msOJxgIABrkkA1Z2ADk OFCBTzCad1a8cBfmsDDmh/E4CAd4OuAxiv+A9Pdwaxe2EkRlF7R5c31YWfu1 2IXH51th+SRME8HweGYD8rZLR2/UKnAVi8dpZ/G9JNjMsNEfkWZ8R/WTwgSq iHz5NoNVm0TdJYV9JHHcVMzJkq9r9n6Kdh6St7A5ezbtykOcR/SKOQpXH99W XVSXENXDDqjuGRUUqiQ/aqD3lZQ4c5eHXOYGunCw9uT504fq0EMORs1sx2Pk +Oq7FA0jWBlAIYSxvY2Rs2aFRboqBiTkUxUUqCR9RNffh25eGK3SjYYCwUWl 200kvkSl82JM4Bkx00tNvG8hAWUhq24RJbZSlNgjLHp8qOF0JSdrOXroyOc3 d3HdbMHubbs2oVC0KinSnZNVvyAy24hTW8FUzHyySWUPnCG7PBFcyDaerOzV 3ZhllX5WeMQkzGGPKWU+58IVtSuur7uGHqCLx+oecOks8t6yMit1Q/LK3GUo DiUWZX6dc2Drl9uruKlMoX37QhiKlOjhkRNnT9cfeIBgKEc29ycb45xAvq/R E1tg01DPyS5L9BJyXdlLCAWC3/2/uA5vVPgNcd1apSsQ8fqjONT1wBZSH/wF E37nr743sTGJc5PZAeNnnI2FYSkKZc7NgrIsFDciImKt1/K44sNZ8o0HPjqw vZqbzOzBxs2LYBRJuOFPm94oV5yzPaKYdcj3q9TDqHpE/bmq5oenUpfslv9e xx6BZ4mktYuUMWkrUZF3KV2khIkFrKJiS36JvDyvKAOt4QYKmTrg2ti5yzPf j5DD8QENgotiPTDTaAD3zXxlIXsLQUCkfRvTVb16kkIm7PRHy79YUZwyAugy JqF829Edr3aCUc6p2SeIoKtOf3u5yxLMZrdgWznu1ceLtQER/Q2kLhzfWpZ9 JKt4LVrBTVkRay/X52lAKdSqoEJldl4jbFQRAdaGCzyPb8yAjGyGqKr5hIl4 xFy/irqV8sgrqT2ojwPfX8AQnEDaGTKxRP6CWQf22KAbz0KuaF5mSNQ0n0hM I2zB4UwYhV0g/G8d1R3fEcEuG0/fIkFYldkmjG+WdJNE2UsCZwqMmY7HePt+ p7Nmwk6lNJWU7P7smLyV3fTJxp0fIC5+c1G1AvAz1gQyCLbZJRBYInlI1o4n a6frSrsYbYrBNJunYgNDROeN0qxevUADP6t9NWJ2a4T9/E6wdejCswnbbvYz 8HDXusUvMxSwIJKW9f60/uyaEEsUm7U6eUNqdvSmhWg2Cj2UcDb9mw9P7rpA iN/lV7yicvUl36fxIEU96LuSulMNtVVN6B7qW/zAvgK/3zBc1j65POnYdcvv mxp+Bq4pzHGXfIBHEpb1JZKu54Ih0cB6Epm4W6NNccLNuiHQTBqv59AtplRm W7jol1lTF+whipQjZJkLpdPxJVZ2wXqxj9uCmNP35AI7XWfPujUt/qW9oaKl QS7L8RIBwanfa0fqEWkloSaW61fs0ry8ZZ8gtCtP7s0W7fhsZzHinjfUfKfQ GrMQYzDdpovRJ42WUUngS5Iyf9da8bBVpWuZAdveWWkYvZiJdfD1cymEkfCd SCwVk0iPvgRqzCFaKKUnMthe546tBXdyCwG6UvrfU0RzbhKCRot1XIz9lcyT TvDB1fSvDKm6L0m1W0BbMzgDZ9D6SqqVl0i6NXqUGsgaXSHr4B2MB4euKD6S II8/lleNrnFCoRMZx/a/OcNc8IRBz2GcXCjUN35KrU2J5OALWEeceSauL2LR oo/W5mXkpiXmrUGcT2xdt6LO8X0WGyrngCnIOjrATC6cH8g20Sfhsjk46X2y 1TmOIe3rWMZO52hNbpwZcCSuPWfeCM6/6ZxpfRCK4DQ/lYIjedm0dykk9AiJ rT5tgku72dkeKNaT+E0DqSo7tnyMtlulfnDgqALusBrfS5j3DNgQmyBfn745 ZcdS7imz935NpRJxj8+mhSs2sCghK3/BVmyYn/tx0sagjOQo5MvJchwfBP/2 oLHs6i3552FH119FB1Hx7oq9pEaDL4/StuZlZCYmr/ogAnH+cVWN16qP9RYr 1Pu/3nOsmPujBeog2MyBL3gYQv6KxNZ1EIMbBW+4BJf07f0/dTQt0CQoNeyf VF+Ach684XORbDMcgs0ghHZkYB4uwoG4hH7BwAiIBgscTb8aaH5/b+GfQrr4 sZA16GOSlBcVK3vyw7U7zXdPxvnJ8TtxQHy8cyp2gfgojGKfh15x8InJWhgh T74eU+6LfFD0uuUBnKzhe/avfeLVLrhCOqH8q3plffyQlTUEnW5MbbMCeR/p A7zAY8pbLJ+3LH1hrAIqWRiHS3nNQBMU+Ncm6B/eA+Bo880hkBxzbBlsqevF M4Ve2o7BU8ntKHJry0AwOfv8wsA04SXM1r0kQbBOG14iua+R3ic22NazuxYV pCds5+LY2599exF1cm9Ibj4Tp7Q9kcImMscOWwRgf4QnIex6D/u/JuJ4jZkM thEwG4EbgskN4K4GG+73ZTDviVSDE/jXYHEP/BFMQuAaAP52YMEtYdTYtoGI Gek28eQI7D4Zi8uqyAfb1fSWSHreSnv6edvbuSyavzE7agexqvXkhWcKMBKN gm2PJFANTTzeMg+2kFwHrU+J5IrmoUZ6RRvOYylbgS3pWqYCLGmQsg/N//eI qA79kp5+KSwmb7HtF2M/uxRCmsGrGcRDU642kPdgEvAyGpsyp2AZ7cnEiw/G vkAxydiLxozvGyYOx9M/MLUQT8Ow/3wY3GzDVIEX/VuzE+Pqy+vnmzLfkBHy 4uxS7TICTi4BFG9+t5m+xsBm7Wb9WaRNUCol5/qguk8Kx4gjC1Bw6pqI6MBM R30h2tqJZeAI41WkbygA+Yafou7L11xaeMwPce4GL+omkNiOjp7o4BT1M4RB WN2LFwp9JdeSszDsV0thv7Cb1+1Wa8MXsclYkp2PR+ZxAWJcoh7hbLtEmNEn FT7t4XWDmcKb31T3XH59dfjfrl5uIwXj1vprMTUxNUu/9kOTkF9SbHBG3KYV O+ZxaubT+s8r95eVnbt4tBFxnbdDPBevjQyIVzgvxfbTVvptxS4jhGSxZau/ sFzTRL4WskYYLazj+1lZYySz88aBYyc+42rY4O1ro9Bsbhwrc4E95v2R7H// os8fKHsM+e1mdWoo7pvfR46YsA6U/D6mehcte/vq0oqprkvCnCdE1f/6kYK0 OyFFaw4mnfJtTXhFWp5xz3vAsi/h0tRK0n08OPrtpe8swWRmG7bCtp7ueMIn cjWz69ye8n2HS2rPl19DnLIuek54bkrsB4r1m5M/DtzJDYBprpS0dyv7eglF XRDJ17Ho/L6DzfceNx+5gB5wMHj6Y3JEHDNnFnaSdzPo4mfH9pcfqj5dStBp vxztG70hNixKsTAMobzMrLRtmSieW8L2OfKTbPsY/f7g0CEEEL46CV+d4MFj DzV4vO2wEVb6s/ixLoR2YuFKB48zGMiAe/QAKD1KcO6RCLMIf+kkbHSDmDCd Of2EOdNw4iDx5MVtf5uxCwMneETVdmYRXPYvKkorXXc69FFyJ8HF9nU/jAdr p5d4ZPjqjSmrFMcggoZ6kTSSVWYNmuXnm8nXQtbdQPa2ZWXd9cx/S4Ws+KH5 /6MhVTjhkbbmkeQ+qaafilEf9D9zIejRGG3Nr8yA/XeUXaXPlJLzvXCOuLCd qG0ecJ4tmELuyCcuJmDF/GyiEzzCQ772PBtQE3I3WSkeGl+9BgUMn6TBMp8l 6UvjFLtg7vWXb9BddC72S1+OSOUUvrtxoaNrsP/MGYHNP6pv3+kZyAjhZ4LW QRGpVDdBxmB3/NF8bB+GC7jnJIGze2EpuEEi96fpYNYlLSNSBkH/mIuD5v36 rmbM76aHKOFuu6SmT7S8EabyBzH3w3ygyAHgu5oz9y60lPQg4MnRMPeHmHux NwKrxMOy1Xg7rMDD+5zgvYcN5dcuKnbiuYsnjEOBaGVtQTMH7wlredVdX2e3 oMApU8Nuvei73fREfzrrh5Z+CQwisrV2QLaEUgO9ekFGEymNrmJe/Z+pA4tF gax/Lq3/Ux5P/yGGwhOQtv7SKhGq4Ddel+Mj5DBjDQauJpllQqnYCwWUMUrD riHKz4yMuguNjCnqX5Q57vEKZW5kc3RyZWFtCmVuZG9iago0OSAwIG9iago0 ODIyCmVuZG9iagoxMyAwIG9iago8PC9CYXNlRm9udC9CT1RPR1orQ291cmll ci9Gb250RGVzY3JpcHRvciAxMiAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIg MzIvTGFzdENoYXIgMTIyL1dpZHRoc1sKNjAwIDAgNjAwIDYwMCAwIDAgNjAw IDYwMCA2MDAgNjAwIDYwMCAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCA2 MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgMCAwIDAgNjAwIDAgNjAwIDAgMAowIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw CjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDBd Ci9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvU3VidHlwZS9UeXBlMT4+CmVu ZG9iagoyNSAwIG9iago8PC9CYXNlRm9udC9BQVBQQVMrSGVsdmV0aWNhLU9i bGlxdWUvRm9udERlc2NyaXB0b3IgMjQgMCBSL1R5cGUvRm9udAovRmlyc3RD aGFyIDEwMS9MYXN0Q2hhciAxMTkvV2lkdGhzWyA1NTYgMCAwIDAgMCAwIDAg MjIyIDAgMCA1NTYKMCAwIDMzMyAwIDAgMCAwIDcyMl0KL0VuY29kaW5nL1dp bkFuc2lFbmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjI3IDAgb2Jq Cjw8L0Jhc2VGb250L1BXRVZQUitIZWx2ZXRpY2EtQm9sZC9Gb250RGVzY3Jp cHRvciAyNiAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIg MTIyL1dpZHRoc1sKMjc4IDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMCAz MzMgMjc4IDAKMCA1NTYgNTU2IDU1NiAwIDAgMCA1NTYgMCAwIDMzMyAwIDAg MCAwIDAKMCA3MjIgMCAwIDAgMCAwIDAgMCAyNzggMCAwIDAgODMzIDAgNzc4 CjAgMCAwIDAgMCAwIDAgMCA2NjcgMCAwIDAgMCAwIDAgMAowIDU1NiAwIDAg NjExIDU1NiAzMzMgNjExIDAgMjc4IDAgMCAyNzggMCA2MTEgNjExCjYxMSA2 MTEgMzg5IDU1NiAzMzMgNjExIDAgMCAwIDAgNTAwXQovRW5jb2RpbmcvV2lu QW5zaUVuY29kaW5nL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKOSAwIG9iago8 PC9CYXNlRm9udC9OQ1RSS08rVGltZXMtUm9tYW4vRm9udERlc2NyaXB0b3Ig OCAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIyL1dp ZHRoc1sKMjUwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDMzMyAyNTAgMAo1 MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMjc4IDAg MCAwIDAgMAowIDcyMiAwIDAgMCAwIDU1NiAwIDAgMCAzODkgMCAwIDAgMCAw CjU1NiAwIDAgNTU2IDYxMSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCA0NDQg MCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDAgMjc4IDAgMCAyNzggNzc4IDUwMCA1 MDAKNTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiAwIDAgNDQ0XQov RW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1N1YnR5cGUvVHlwZTE+PgplbmRv YmoKMTEgMCBvYmoKPDwvQmFzZUZvbnQvSEFHRVdWK0hlbHZldGljYS9Gb250 RGVzY3JpcHRvciAxMCAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMzIvTGFz dENoYXIgMTQ4L1dpZHRoc1sKMjc4IDAgMzU1IDU1NiAwIDAgMCAxOTEgMzMz IDMzMyAwIDAgMjc4IDMzMyAyNzggMjc4CjU1NiA1NTYgNTU2IDU1NiA1NTYg NTU2IDU1NiA1NTYgMCA1NTYgMjc4IDAgMCA1ODQgMCA1NTYKMCA2NjcgNjY3 IDcyMiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCA1MDAgNjY3IDU1NiA4MzMg NzIyIDc3OAo2NjcgMCA3MjIgNjY3IDYxMSA3MjIgMCA5NDQgNjY3IDY2NyAw IDI3OCAwIDI3OCAwIDAKMCA1NTYgNTU2IDUwMCA1NTYgNTU2IDI3OCA1NTYg NTU2IDIyMiAyMjIgNTAwIDIyMiA4MzMgNTU2IDU1Ngo1NTYgNTU2IDMzMyA1 MDAgMjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAgNTAwIDAgMCAwIDAgMAowIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMjIyIDIyMSAzMzMgMzMz XQovRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1N1YnR5cGUvVHlwZTE+Pgpl bmRvYmoKMTIgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFt ZS9CT1RPR1orQ291cmllci9Gb250QkJveFswIC0xODYgNTkzIDY2N10vRmxh Z3MgNQovQXNjZW50IDY2NwovQ2FwSGVpZ2h0IDY2NwovRGVzY2VudCAtMTg2 Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViA4OAovQXZnV2lkdGggNjAwCi9NYXhX aWR0aCA2MDAKL01pc3NpbmdXaWR0aCA2MDAKL0NoYXJTZXQoL3R3by9ML0Ev eS9uL2MvZ3JlYXRlci90aHJlZS9NL0Ivei9vL2QvcXVlc3Rpb24vZm91ci9O L0MvcC9lL2F0L2ZpdmUvTy9EL3EvZi9icmFja2V0bGVmdC9zaXgvUC9FL3Iv Zy9zZXZlbi9GL3MvaC9icmFja2V0cmlnaHQvZWlnaHQvUi9HL3QvaS9uaW5l L1MvSC91L2ovY29sb24vVC9JL3Yvay9zZW1pY29sb24vVS9KL3cvbC9hL2xl c3MvVi94L3F1b3Rlc2luZ2xlL20vYi9XL3BhcmVubGVmdC9wYXJlbnJpZ2h0 L2FzdGVyaXNrL3NwYWNlL2NvbW1hL2h5cGhlbi9xdW90ZWRibC9wZXJpb2Qv bnVtYmVyc2lnbi9zbGFzaC96ZXJvL29uZS9hbXBlcnNhbmQpL0ZvbnRGaWxl MyA0MCAwIFI+PgplbmRvYmoKMjQgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3Jp cHRvci9Gb250TmFtZS9BQVBQQVMrSGVsdmV0aWNhLU9ibGlxdWUvRm9udEJC b3hbMCAtMjMgODIwIDcyOV0vRmxhZ3MgNAovQXNjZW50IDcyOQovQ2FwSGVp Z2h0IDcyOQovRGVzY2VudCAtMjMKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDEy MwovTWlzc2luZ1dpZHRoIDI3OAovQ2hhclNldCgvby9lL3Ivdy9sKS9Gb250 RmlsZTMgNDIgMCBSPj4KZW5kb2JqCjI2IDAgb2JqCjw8L1R5cGUvRm9udERl c2NyaXB0b3IvRm9udE5hbWUvUFdFVlBSK0hlbHZldGljYS1Cb2xkL0ZvbnRC Qm94WzAgLTIxOCA3NzYgNzQxXS9GbGFncyA0Ci9Bc2NlbnQgNzQxCi9DYXBI ZWlnaHQgNzQxCi9EZXNjZW50IC0yMTgKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1W IDExNgovTWlzc2luZ1dpZHRoIDI3OAovQ2hhclNldCgvdHdvL0Evbi9YL3Ro cmVlL00vei9vL2QvcC9lL08vcS9mL3IvZy9zZXZlbi9zL3QvaS91L2NvbG9u L0kvbC9hL3BhcmVubGVmdC9wYXJlbnJpZ2h0L3NwYWNlL2h5cGhlbi9wZXJp b2Qvb25lKS9Gb250RmlsZTMgNDQgMCBSPj4KZW5kb2JqCjggMCBvYmoKPDwv VHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9OQ1RSS08rVGltZXMtUm9t YW4vRm9udEJCb3hbMCAtMjE4IDc3NSA2ODhdL0ZsYWdzIDQKL0FzY2VudCA2 ODgKL0NhcEhlaWdodCA2ODgKL0Rlc2NlbnQgLTIxOAovSXRhbGljQW5nbGUg MAovU3RlbVYgMTE2Ci9NaXNzaW5nV2lkdGggMjUwCi9DaGFyU2V0KC90d28v QS9uL2MvdGhyZWUvei9vL2QvZm91ci9wL2UvZml2ZS9xL2Yvc2l4L1Avci9n L3NldmVuL0Yvcy9laWdodC90L2kvbmluZS9TL3UvY29sb24vVC92L0ovdy9s L2EvbS9zcGFjZS9oeXBoZW4vcGVyaW9kL3plcm8vb25lKS9Gb250RmlsZTMg NDYgMCBSPj4KZW5kb2JqCjEwIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0 b3IvRm9udE5hbWUvSEFHRVdWK0hlbHZldGljYS9Gb250QkJveFstMTggLTIx OCA5MjkgNzQxXS9GbGFncyA0Ci9Bc2NlbnQgNzQxCi9DYXBIZWlnaHQgNzQx Ci9EZXNjZW50IC0yMTgKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDEzOQovTWlz c2luZ1dpZHRoIDI3OAovQ2hhclNldCgvdHdvL0wvQS95L3F1b3RlZGJsbGVm dC9uL2MvWC90aHJlZS9NL0Ivei9vL2QvcXVlc3Rpb24vWS9mb3VyL04vQy9w L2UvZml2ZS9PL0QvcXVvdGVkYmxyaWdodC9xL2YvYnJhY2tldGxlZnQvc2l4 L1AvRS9yL2cvc2V2ZW4vRi9zL2gvYnJhY2tldHJpZ2h0L1IvRy90L2kvbmlu ZS9TL0gvdS9qL2NvbG9uL1QvSS92L2svcXVvdGVsZWZ0L1UvSi93L2wvYS9L L3gvcXVvdGVzaW5nbGUvbS9iL2VxdWFsL1cvcXVvdGVyaWdodC9wYXJlbmxl ZnQvcGFyZW5yaWdodC9zcGFjZS9jb21tYS9oeXBoZW4vcXVvdGVkYmwvcGVy aW9kL251bWJlcnNpZ24vc2xhc2gvemVyby9vbmUpL0ZvbnRGaWxlMyA0OCAw IFI+PgplbmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3Jp cHQgOC4xNSkKL0NyZWF0aW9uRGF0ZShEOjIwMTAwNzE4MTI1MjM3KQovTW9k RGF0ZShEOjIwMTAwNzE4MTI1MjM3KQovVGl0bGUoTWljcm9zb2Z0IFdvcmQg LSBUb3dhcmQtcmVzb2x2aW5nLUFwcGxlcy1KU1AyLWNvbW1lbnQtb24tdW5p dHMtZm9yLWZvbnQtc2l6ZS1yZXF1ZXN0ZWQuZG9jKQovQ3JlYXRvcihQU2Ny aXB0NS5kbGwgVmVyc2lvbiA1LjIuMikKL0F1dGhvcihUb20gSGFzdGluZ3Mp Pj5lbmRvYmoKeHJlZgowIDUwCjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAy MzgxOCAwMDAwMCBuIAowMDAwMDQ3MDgyIDAwMDAwIG4gCjAwMDAwMjM3MjIg MDAwMDAgbiAKMDAwMDAyMjkxNCAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAw IG4gCjAwMDAwMDU4NTggMDAwMDAgbiAKMDAwMDAyMzg2NiAwMDAwMCBuIAow MDAwMDQ2MjA0IDAwMDAwIG4gCjAwMDAwNDQxMzYgMDAwMDAgbiAKMDAwMDA0 NjU0NiAwMDAwMCBuIAowMDAwMDQ0NTUzIDAwMDAwIG4gCjAwMDAwNDUwOTYg MDAwMDAgbiAKMDAwMDA0MzAzMSAwMDAwMCBuIAowMDAwMDIzOTA3IDAwMDAw IG4gCjAwMDAwMjM5MzcgMDAwMDAgbiAKMDAwMDAyMzA3NCAwMDAwMCBuIAow MDAwMDA1ODc4IDAwMDAwIG4gCjAwMDAwMTE0ODggMDAwMDAgbiAKMDAwMDAy Mzk4OSAwMDAwMCBuIAowMDAwMDI0MDE5IDAwMDAwIG4gCjAwMDAwMjMyMzYg MDAwMDAgbiAKMDAwMDAxMTUwOSAwMDAwMCBuIAowMDAwMDE4MTAyIDAwMDAw IG4gCjAwMDAwNDU2NDggMDAwMDAgbiAKMDAwMDA0MzUyMCAwMDAwMCBuIAow MDAwMDQ1ODc3IDAwMDAwIG4gCjAwMDAwNDM3MzIgMDAwMDAgbiAKMDAwMDAy NDA3MSAwMDAwMCBuIAowMDAwMDI0MTAxIDAwMDAwIG4gCjAwMDAwMjMzOTgg MDAwMDAgbiAKMDAwMDAxODEyMyAwMDAwMCBuIAowMDAwMDIxMjkzIDAwMDAw IG4gCjAwMDAwMjQxNzUgMDAwMDAgbiAKMDAwMDAyNDIwNSAwMDAwMCBuIAow MDAwMDIzNTYwIDAwMDAwIG4gCjAwMDAwMjEzMTQgMDAwMDAgbiAKMDAwMDAy Mjg5MyAwMDAwMCBuIAowMDAwMDI0MjU3IDAwMDAwIG4gCjAwMDAwMjQyODcg MDAwMDAgbiAKMDAwMDAyNDMzOSAwMDAwMCBuIAowMDAwMDMwNzg4IDAwMDAw IG4gCjAwMDAwMzA4MDkgMDAwMDAgbiAKMDAwMDAzMTUyOCAwMDAwMCBuIAow MDAwMDMxNTQ4IDAwMDAwIG4gCjAwMDAwMzM4MTggMDAwMDAgbiAKMDAwMDAz MzgzOSAwMDAwMCBuIAowMDAwMDM4MDgxIDAwMDAwIG4gCjAwMDAwMzgxMDIg MDAwMDAgbiAKMDAwMDA0MzAxMCAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXpl IDUwIC9Sb290IDEgMCBSIC9JbmZvIDIgMCBSCi9JRCBbKAycxzF8dLUt3xFN B9pql+opKAycxzF8dLUt3xFNB9pql+opXQo+PgpzdGFydHhyZWYKNDczNDkK JSVFT0YK ------=_NextPart_000_0084_01CB2678.89476680 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp ------=_NextPart_000_0084_01CB2678.89476680-- From ipp-bounces@pwg.org Sun Jul 18 17:10:26 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3753A69B6 for ; Sun, 18 Jul 2010 17:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxcwUZGTnoQI for ; Sun, 18 Jul 2010 17:10:23 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id AAEF93A69B0 for ; Sun, 18 Jul 2010 17:10:23 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id E73A379294; Sun, 18 Jul 2010 20:10:34 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-vw0-f46.google.com (mail-vw0-f46.google.com [209.85.212.46]) by pwg.org (Postfix) with ESMTP id 4714E79265 for ; Sun, 18 Jul 2010 20:10:29 -0400 (EDT) Received: by vws5 with SMTP id 5so4391643vws.5 for ; Sun, 18 Jul 2010 17: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:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=YAZA8VyOeCoI2XyXSqo4qEVI7eA6VeRQiTpBP6tBqpk=; b=uMzxLRo66cvQoVLilOrBctbbeBTYILtNyy5B1gP5bViHdASlTuMbWBzBH4QvZEVFMA N77gc9T2V2o8Q64nvziVdngZFmrMqkuZkQ/jq939Y5PinzEcPQD02OhU8tOCK5M46P5S dsYgp8erK0yrnkgdc01S6gDO7BIhvRASAktw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=RmEWgcfb8qEGcek3dkVRDl0aIXIkLM/LTPcXbpzaDP/RHGY+KA7DVOTgBBTHgI3ErI dl7yR0f7Q10vQ9F3NaTFwuDJTQjzvfOTD0vEYRhD34YXrYbsDEgXDG//RvY44cLOWZgJ /gzEvB6657/tA708qBchAyyz880obxwhvdMTo= MIME-Version: 1.0 Received: by 10.220.161.200 with SMTP id s8mr2662940vcx.76.1279498228714; Sun, 18 Jul 2010 17:10:28 -0700 (PDT) Received: by 10.220.78.25 with HTTP; Sun, 18 Jul 2010 17:10:28 -0700 (PDT) Date: Sun, 18 Jul 2010 20:10:28 -0400 Message-ID: From: Ira McDonald To: ipp@pwg.org, Ira McDonald Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] Prototype Draft of IPP/2.0 Second Edition (18 July 2010) X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: E73A379294.A8B26 X-pwg-MailScanner-From: ipp-bounces@pwg.org Hi, [Based on IPP WG complete review on 21 June - for review at IPP WG meeting on 19 July] I've just posted a Prototype draft of IPP/2.0 Second Edition at: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100718.pdf / doc - clean copy with line numbers ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100718-rev.pdf / doc - redlines from 27 May draft Prototype reports for IPP/2.2 new content already exist so, except for the one new ISSUE in section 6 (see change log below), this spec is ready for final review, working group last call, and PWG Last Call. Comments? Cheers, - Ira ----------------------- Changes made to create 18 July 2010 version (Prototype Draft) Editorial =96 Kept status at Prototype Draft Editorial =96 Added =93(JPS2)=94 to end of all IPP JPS2 references and document title, per IPP WG review Technical =96 Added new Table 1 to section 4 to summarize all IPP spec requirements, per IPP WG review Technical =96 Revised section 4.3 to add missing requirement for TLS/1.2 [RFC5246], per section 10 Editorial =96 Revised Table 3 in section 5.2 IPP/2.0 to correct Resubmit-Job (note 2), per IPP WG review Editorial =96 Revised Table 5 in section 5.4 IPP/2.2 to restore missing last row, per IPP WG review Technical =96 Revised section 6 to add ISSUE about "status-code" and other non-attribute parameters for various IPP conformance levels, per IPP WG review Editorial =96 Revised section 6.3 to recover lost note 3 (buried at end of note 2) and to renumber all following notes in section Editorial =96 Revised tables in sections 6.1, 6.2, 6.3, and 6.4 to clarify operation attributes, per IPP WG review Technical =96 Revised Table 7 in section 6.2 IPP/2.0 and Table 8 in section 6.3 to make =93status-message=94 response attribute RECOMMENDED, per IPP WG review Technical =96 Revised Table 9 in section 6.4 IPP/2.2 to make =93status-mess= age=94 response attribute REQUIRED, per IPP WG review Editorial =96 Revised Table 7 in section 6.2 IPP/2.0 to add explicit OPTION= AL media-ready (note 3), for clarity Editorial =96 Revised Table 8 in section 6.3 IPP/2.2 to add explicit OPTION= AL media-col-ready (note 3), for clarity Editorial =96 Revised Table 9 in section 6.4 IPP/2.2 to add explicit OPTION= AL media-col-ready (note 5), for clarity Technical =96 Revised section 11.1 Normative References to add missing references and update PWG Command Set [PWG5107.2], per lists in section 4 and IPP WG review --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Sun Jul 18 17:26:18 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CDAC3A69AD for ; Sun, 18 Jul 2010 17:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-c5i5-kwQsf for ; Sun, 18 Jul 2010 17:26:16 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 6F47E3A69B0 for ; Sun, 18 Jul 2010 17:26:16 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id E5E9A7929B; Sun, 18 Jul 2010 20:26:25 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-vw0-f46.google.com (mail-vw0-f46.google.com [209.85.212.46]) by pwg.org (Postfix) with ESMTP id 9274279294 for ; Sun, 18 Jul 2010 20:26:21 -0400 (EDT) Received: by vws5 with SMTP id 5so4398975vws.5 for ; Sun, 18 Jul 2010 17:26:21 -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:content-transfer-encoding; bh=a/fon5C81kAzlU6Fx4rqlcCjIz/XwEkTWDatvTTOmGU=; b=IKtkD5yOk/GK6cTzI1AZ1ix+M2mxAiV4mjhBicm+m7nYpKK7KWfkP46pehucZbLm0U kq1qvkIGiOfvDK/dKFhjFq+lq/LpAeKkUiUvWdlJ85d5tbr4/luTmM+1hIXs4NTW4NYV Tsdoob2zSh4Lnkykd5pL0OsMHSHJfj1cTyNmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=YfP3JrD9LSiDNrCTuVdVbz8z7j+s+xIzoU9GJyXHyYvmYUjIVln384zW69AseJ6jJi 2EMfmWGa4tYlMBfTL3i/r+ziGlofJZcvJ0nR9ompN+SADnEjw+cTWSOdw62oxi8lPRiZ u7U6QPQTKfKWwlyZ2tQWhkd98R5yB2lOK2M+I= MIME-Version: 1.0 Received: by 10.220.87.70 with SMTP id v6mr2615845vcl.226.1279499180338; Sun, 18 Jul 2010 17:26:20 -0700 (PDT) Received: by 10.220.78.25 with HTTP; Sun, 18 Jul 2010 17:26:20 -0700 (PDT) Date: Sun, 18 Jul 2010 20:26:20 -0400 Message-ID: From: Ira McDonald To: ipp@pwg.org, Michael R Sweet , Paul Tykodi , Tom Hastings , Ira McDonald Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] REVISED IPP Agenda - 4pm EDT Monday 19 July 2010 X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: E5E9A7929B.A943A X-pwg-MailScanner-From: ipp-bounces@pwg.org Hi, REVISED agenda (new document links) for IPP WG tomorrow: Monday 19 July - 1-2pm PDT / 4-5pm EDT Call-in toll-free number (US/Canada): 1-866-469-3239 Call-in toll number (US/Canada): 1-650-429-3300 (Primary) Call-in toll number (US/Canada): 1-408-856-9570 (Backup) Attendee Access Code: *******# Attendee ID Code: # (empty) If you need the Attendee Access code, please email me a request. *** Main Objective - move IPP JPS2 into PWG Last Call *** Agenda: (1) PWG IP Policy and Minute Taker - Mike? (2) Approve IPP minutes from last meeting - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20100621.pdf (3) Review of IPP Version 2.0 Second Edition (Ira) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100718-rev.pdf (based on IPP WG review on 21 June 2010 - see Ira's release note) (4) Status of PWG Formal Vote on IPP Everywhere Charter (Mike/Ira) - ftp://ftp.pwg.org/pub/pwg/ipp/charter/ch-ippeverywhere-charter-20100712= .pdf (PWG approved on Monday 12 July 2010) (5) Review of IPP WG Last Call on IPP JPS2 (Tom) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v30-20100718.pdf (IPP WG last call ended on Monday 12 July 2010 - see Tom's release note) (6) Next Steps - IPP JPS2 into PWG Last Call? - IPP WG - Monday 26 July - IPP WG and IPP Everywhere sessions at PWG F2F - Thursday 5 August Cheers, - Ira (IPP co-editor) Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - TCG Hardcopy WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com winter: =A0 579 Park Place=A0 Saline, MI=A0 48176 =A0 734-944-0094 summer: =A0 PO Box 221=A0 Grand Marais, MI 49839 =A0 906-494-2434 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Sun Jul 18 17:37:15 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7EF3A68B3 for ; Sun, 18 Jul 2010 17:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 awmU8M3KjahC for ; Sun, 18 Jul 2010 17:36:58 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id D0BA73A6888 for ; Sun, 18 Jul 2010 17:36:57 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id F015A792AD; Sun, 18 Jul 2010 20:36:40 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by pwg.org (Postfix) with ESMTP id C105579294 for ; Sun, 18 Jul 2010 20:36:30 -0400 (EDT) Received: from FamilyRoom ([unknown] [173.60.208.25]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L5S00ABJ4CKW5T3@vms173017.mailsrvcs.net> for ipp@pwg.org; Sun, 18 Jul 2010 19:36:24 -0500 (CDT) From: "Tom Hastings" To: , "'Michael R Sweet'" , "'Paul Tykodi'" , "'Ira McDonald'" Date: Sun, 18 Jul 2010 17:36:19 -0700 Message-id: <8A7AC5E37CBD47739FFCFB03327849CC@FamilyRoom> MIME-version: 1.0 Content-type: multipart/mixed; boundary="----=_NextPart_000_009B_01CB269F.BCC60260" X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-index: Acsm2k5n2AHqgvP7SyqmdDTDN7cMow== X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] {Disarmed} Toward resolving Apple's IPP WG Last Call JPS2 comments 4 thru 7 - for Mon, Jul 19, IPP WG telecon X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tom.hastings@alum.mit.edu List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: F015A792AD.AB542 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. ------=_NextPart_000_009B_01CB269F.BCC60260 Content-Type: multipart/alternative; boundary="----=_NextPart_001_009C_01CB269F.BCC60260" ------=_NextPart_001_009C_01CB269F.BCC60260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For the IPP WG telecon, tomorrow, Monday, July 19, here is 2 or 2 input for the agenda topic: Since the font, highlighting, and indentation will be smashed when this mail message is turned to plain text, I've attached a 63 KB .pdf which is much more readable, complete with line numbers to make it easier to discuss at the telecon. I've also down loaded v30 of JPS2 .doc and .pdf (without hot links). If Pete Zehler can update the .pdf that would be good, but he may be on vacation. So the following 6 documents are in the wd sub-folder for the IPP WG telecon tomorrow, Monday, July 19: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v30-20100718.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v30-20100718.doc and the following two documents that attempt to resolve Apple's IPP WG Last Call comments (same as I attached to this and the previous email): ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JPS2-comments-4-thr u-7.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JPS2-comments-4-thr u-7.doc and: ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JSP2-comment-on-uni ts-for-font-size-requested.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JSP2-comment-on-uni ts-for-font-size-requested.doc (Yes, the S and P are switched in this last file name by mistake). For the IPP WG telecon, tomorrow, Monday, July 19, here is 2 or 2 input for the agenda topic: > (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July > - > ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-cl > ean.pdf > (ended Monday 12 July 2010) > > (6) Next Steps > - IPP WG - Monday 26 July > - IPP JPS2 into PWG Last Call? File: Toward-resolving-Apples-JPS2-comments-4-thru-7.doc From: ipp-bounces@pwg.org on behalf of Michael Sweet [msweet@apple.com] Sent: Monday, June 21, 2010 12:58 To: ipp@pwg.org Subject: [IPP] Apple has reviewed the JPS2 specification and has comments Attachments: ATT02705.txt Comments: 1. The document date is wrong in the headers. TH> Updated to today's date. 2. The "font-size-requested" attribute uses points as the units, however it should probably use a higher-precision unit (at least decipoints, or 1/720th of an inch) to avoid issues with getting common fixed-width font spacing right (e.g. 17 characters per inch with a standard Courier font would need a point size of 5.293...) [And apologies for the late notice on this - I haven't read through the older material in a while...] TH> See separate email thread and attached .pdf more readable version for this issue and possible alternatives for resolution. 3. Question: do we need the PWG process reference at the beginning of section 3? Do we need to explain why we organize our standards documents this way? TH> Need IPP WG input here. 4. On line 372 of the -rev document you say "these features are useful in the "light production printing" environments, but we don't define what "light production printing" is, just "production printing". TH> Just remove the clause entirely, OK? 5. Line 427 - I think Close-Job is Owner + Operator, per RFC 2911's description of Send-Document and the Close-Job references in JPS2: Access Rights: The authenticated user (see section 8.3) performing this operation must either be the job owner (as determined in the Create-Job operation) or an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return: 'client-error-forbidden', 'client- error-not-authenticated', or 'client-error-not-authorized' as appropriate. TH> Added: Access Rights: The authenticated user (see [RFC2911] section 8.3) performing this operation must either be the job owner (as determined in the Create-Job operation) or an operator or administrator of the Printer object (see [RFC2911] Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return: 'client-error-forbidden', 'client-error-not-authenticated', or 'client-error-not-authorized' as appropriate. 6. Line 567-568: The definition says up to 255 characters for job-password and job-password-supported, but here we say 127 octets. TH> Fixed 7. a: Section 10.5 (job-spooling-supported) - shouldn't this be a 1setOf? b: Also, lines 580-581 basically says that the values are implementation-dependent regardless of whether the attribute is supported or not. :) c: Based on the current description I think we need to specify when the value is 1setOf and when it is not (i.e. a Get-Printer-Attributes request with a document-format would return the value for that format, otherwise you'd get the value for the default format or a 1setOf if the answer can't be made definitively without a format...) d: This will also affect the registration info on line 1073. TH> Apple's 4 suggestions (which I've labeled a thru d) are that a Printer implementation MAY vary the spooling strategy based on the document format. For example, a document format that might have backward references would require the Printer to spool, while one that cannot, the Printer might stream. Therefore, even though there is no way for the client to dictate to the Printer which strategy to use, since there isn't a Job Template attribute to recommend/require the spooling strategy (unless we want to add one), the Printer could support more than one value of "job-spooling-supported", depending on the document format(s) of the document(s) in the submitted job. I've taken a stab at clarifying that "job-spooling-supported" can depend on the document format supplied in the job, as suggested by Apple comment #7: 10.5 job-spooling-supported (1setOf[th1] <> type2 keyword)[th2] <> This attribute indicates whether or not jobs are spooled before the document data is interpreted (RIPped). In other words, this attribute indicates when jobs are processed by the Printer with respect to when the Printer receives and returns responses to Job Creation requests (i.e., Print-Job, Print-URI), receives and returns responses to Document Creation requests (i.e., Send-Document and Send-Uri requests) and "receives" or "fetches" such document data. The value of this attribute returned in a Get-Printer-Attributes response MAY depend on the "document-format" [th3] <> attribute supplied in the Get-Printer-Attributes request (see [RFC2911] Section 3.2.5.1 and 6.2).[th4] <> [th5] <> If the Printer supports this attribute, the value supported depend on implementation. If the Printer does not support this attribute, then the spooling behavior is implementation dependent. The Get-Printer-Supported-Values operation (see description in [RFC3380]) returns a '1setOf type2 keyword' so that all possible values that the implementation is capable of supporting are indicated.[th6] <> The standard keyword values are: Keyword Description 'spool' The Printer starts processing a job until the Printer has (1) accepted and responded to the Job Creation request and all Document Creation requests (for a multi-document job) and (2) has "received" or "fetched" all document data for the job, i.e., spool rather than stream. 'stream' The Printer starts processing a job (1) before the Printer has accepted all Document Creation requests and (2) before the Printer has "received" or "fetched" all document data, i.e., stream rather than spool 'automatic' The Printer chooses whether to process a job before or after the Printer has accepted all Document Creation requests and has "received" or "fetched" all document data, i.e., the Printer MAY spool and/or stream depending on policy and other factors, such as the size of the job, and the document format[th7] <> , including a combination of spooling and streaming. TH> However, I don't think we need to get into the details about Get-Printer-Attributes vs. Get-Printer-Attributes-Supported, since it is now clear that multiple values MAY be returned in either or both operations, depending on implementation. [RFC2911] Section 3.2.5.1 Get-Printer-Attributes goes into gory detail about attributes whose values are affected by "document-format" supplied in the Get-Printer-Attributes requests: "document-format" (mimeMediaType): The client OPTIONALLY supplies this attribute. The Printer object MUST support this attribute. This attribute is useful for a Printer object to determine the set of supported attribute values that relate to the requested document format. The Printer object MUST return the attributes and values that it uses to validate a job on a create or Validate-Job operation in which this document format is supplied. The Printer object SHOULD return only (1) those attributes that are supported for the specified format and (2) the attribute values that are supported for the specified document format. By specifying the document format, the client can get the Printer object to eliminate the attributes and values that are not supported for a specific document format. For example, a Printer object might have multiple interpreters to support both 'application/postscript' (for PostScript) and 'text/plain' (for text) documents. However, for only one of those interpreters might the Printer object be able to support "number-up" with values of '1', '2', and '4'. For the other interpreter it might be able to only support "number-up" with a value of '1'. Thus a client can use the Get-Printer-Attributes operation to obtain the attributes and values that will be used to accept/reject a create job operation. If the Printer object does not distinguish between different sets of supported values for each different document format when validating jobs in the create and Validate-Job operations, it MUST NOT distinguish between different document formats in the Get-Printer-Attributes operation. If the Printer object does distinguish between different sets of supported values for each different document format specified by the client, this specialization applies only to the following Printer object attributes: - Printer attributes that are Job Template attributes ("xxx-default" "xxx-supported", and "xxx-ready" in the Table in Section 4.2), - "pdl-override-supported", - "compression-supported", - "job-k-octets-supported", - "job-impressions-supported, - "job-media-sheets-supported" - "printer-driver-installer", - "color-supported", and - "reference-uri-schemes-supported" The values of all other Printer object attributes (including "document-format-supported") remain invariant with respect to the client supplied document format (except for new Printer description attribute as registered according to section 6.3). If the client omits this "document-format" operation attribute, the Printer object MUST respond as if the attribute had been supplied with the value of the Printer object's "document-format-default" attribute. It is RECOMMENDED that the client always supply a value for "document-format", since the Printer object's "document-format-default" may be 'application/octet-stream', in which case the returned attributes and values are for the union of the document formats that the Printer can automatically sense. For more details, see the description of the 'mimeMediaType' attribute syntax in section 4.1.9. If the client supplies a value for the "document-format" Operation attribute that is not supported by the Printer, i.e., is not among the values of the Printer object's "document-format-supported" attribute, the Printer object MUST reject the operation and return the 'client-error-document-format-not-supported' status code. ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _____ [th1] <> ISSUE: OK to add "1setOf" to "job-spooling-supported" as suggested by Apple's IPP WG Last Call Comment #7a? [th2] <> ISSUE: Comment made during the June 21 telecon: Add: "job-spooling-configured" (type2 keyword). But there is no mention in the minutes. Also with the Apple's Comment #7 suggestion that the spooling strategy could depend on the document-format in the submitted job, configuring for a single strategy wouldn't work. OK NOT to add "job-spooling-configured"? [th3] <> ISSUE: OK to add that the spooling used MAY depend on the document format as suggested by Apple's Comment #7 and allowed by [RFC2911] Section 3.2.5.1 as long as explicitly called out in the definition as indicated in [RFC2911] Section 6.2? [th4] <> ISSUE: OK to add that the spooling used MAY depend on the document format as suggested by Apple's Comment #7c, but refer to RFC 2911 Section 3.2.5.1 for the details about what is returned in Get-Printer-Attributes response depending on whether or not the client supplies "document-format: in the request? [th5] <> ISSUE: OK to remove this sentence as suggested by Apple's Comment #7b? [th6] <> ISSUE: OK to remove this paragraph as suggested by Apple's Comment 7c? [th7] <> ISSUE: OK to add that "document-format" could be an example that causes the Printer to vary the spooling strategy as suggested by Apple's Comment #7c? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_NextPart_001_009C_01CB269F.BCC60260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For the IPP WG tele= con, tomorrow, Monday, July 19, here is 2 or 2 input for the agenda topic:<= /o:p>

 

Since the font, highlighting, and indentation will be smashed when this mail message is tur= ned to plain text, I’ve attached a 63 KB .pdf which is much more readable, complete with line numbers to make it easier to discuss at the telecon.&nbs= p; I’ve also down loaded v30 of JPS2 .doc and .pdf (without hot links).  If Pe= te Zehler can update the .pdf that would be good, but he may be on vacation.&n= bsp; So the following 6 documents are in the wd sub-folder for the IPP WG telecon tomorrow, Monday, July 19:

 

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v30-20100718.p= df

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v30-20100718.d= oc

 

and the following t= wo documents that attempt to resolve Apple’s IPP WG Last Call comments (same as I attached to this and the previous email):

 

ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-= JPS2-comments-4-thru-7.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-= JPS2-comments-4-thru-7.doc

 

and:

 

ftp://ftp.pwg.org/pub/pwg/ipp/wd/T= oward-resolving-Apples-JSP2-comment-on-units-for-font-size-requested.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/wd/T= oward-resolving-Apples-JSP2-comment-on-units-for-font-size-requested.doc

 

(Yes, the S and P a= re switched in this last file name by mistake).

 

 

For the IPP WG tele= con, tomorrow, Monday, July 19, here is 2 or 2 input for the agenda topic:<= /o:p>

 

> (5) Status of IPP WG Last Call on IPP JPS2 = (Tom) - ends Monday 12 July

>  -

> ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-cl=

> ean.pdf

>   (ended Monday 12 July 2010)

> 

> (6) Next Steps

>  - IPP WG - Monday 26 July<= /span>

>  - IPP JPS2 into PWG Last Call?

 

File: Toward-resolving-Apples-JPS2-comments-4-thru-7.d= oc

 =

From: ipp-bounces@pwg.org on behalf of Michael Sweet<= /st1:PersonName> [msweet@apple.com]
Sent: Monday, June 21, 2010 = 12:58
To: ipp@pwg.org
Subject: [IPP] Apple has rev= iewed the JPS2 specification and has comments

Attachments: ATT02705.txt

Comments:

 

1. The document date is wrong in the headers.

TH> Updated to today's date.

 

2. The "font-size-requested" attribute uses points as the units, however it should probably use a higher-precision unit (at least decipoints, or 1/720th of an inch) to avoid issues with getting common fixed-width font spacing right (e.g. 17 characters per inch with a standard Courier font would need a point size of 5.293...) [And apologies for the la= te notice on this - I haven't read through the older material in a while...]

TH> See separate email thread and attached .pdf more readable version for this issue and possible alternatives for resolution.

 

3. Question: do we need the PWG process reference at the beginning = of section 3? Do we need to explain why we organize our standards documents th= is way?

TH> Need IPP WG input here.

 

4. On line 372 of the -rev document you say "these features are useful in the "light production printing" environments, but we do= n't define what "light production printing" is, just "production printing".

TH> Just remove the clause entirely= , OK?

 

5. Line 427 - I think Close-Job is Owner + Operator, per RFC 2911's description of Send-Document and the Close-Job references in JPS2:

 

   Access Rights: The authenticated user = (see section 8.3) performing

   this operation must either be the job owner= (as determined in the

   Create-Job operation) or an operator or administrator of the Printer

   object (see Sections 1 and 8.5).  Otherwise, the IPP object MUST

   reject the operation and return: 'client-error-forbidden', 'client-

   error-not-authenticated', or 'client-error-not-authorized' as

   appropriate.

TH> Added:

Access Rights: The authenticated user = (see [RFC2911] section 8.3) performing this operation must either be the job own= er (as determined in the Create-Job operation) or an operator or administrator= of the Printer object (see [RFC2911] Sections 1 and 8.5).  Otherwise, the= IPP object MUST reject the operation and return: 'client-error-forbidden', 'cli= ent-error-not-authenticated', or 'client-error-not-authorized' as appropriate.  

 

6. Line 567-568: The definition says up to 255 characters for job-password and job-password-supported, but here we say 127 octets.

TH> Fixed

 

7. a: Section 10.5 (job-spooling-supported) - shouldn't this be a 1setOf?

 

b: Also, lines 580-581 basically says that the values are implementation-dependent regardless of whether the attribute is supported or not. :)

 

c: Based on the current description I think we need to specify when= the value is 1setOf and when it is not (i.e. a Get-Printer-Attributes request w= ith a document-format would return the value for that format, otherwise you'd g= et the value for the default format or a 1setOf if the answer can't be made definitively without a format...)

 

d: This will also affect the registration info on line 1073.

 

TH> Apple's 4 suggestions (which I've labeled a thru d) are that= a Printer implementation MAY vary the spooling strategy based on the document format.  For example, a document format that might have backward references would require the Printer to spool, while one that cannot, the Printer might stream.  Therefore, even though there is no way for the client to dictate to the Printer which strategy to use, since there isn't a= Job Template attribute to recommend/require the spooling strategy (unless we wa= nt to add one), the Printer could support more than one value of  "job-spooling-supported", depending on the document format(s) of = the document(s) in the submitted job.

 

I've taken a stab at clarifying that "job-spooling-supported&q= uot; can depend on the document format supplied in the job, as suggested by Apple comment #7:

 

10.5    job-spo= oling-supported  (1setOf<= font size=3D1 color=3Dred>[th1]  ty= pe2 keyword)[th2] 

This attribute indicates whether or not jobs are spooled before the document data is interpreted (RIPped).  In other wo= rds, this attribute indicates when jobs are processed by the Printer with respec= t to when the Printer receives and returns responses to Job Creation requests (i= .e., Print-Job, Print-URI), receives and returns responses to Document Creation requests (i.e., Send-Document and Send-Uri requests) and "receives&quo= t; or "fetches" such document data.

= The value of this attribute returned i= n a Get-Printer-Attributes response MAY depend on the "document-format&quo= t; [th3] = attribute supplied in the Get-Printer-Attributes request (see [RFC2911] Section 3.2.5.1 and 6.2).[th4] =

[th5] If the Printer supports this attrib= ute, the value supported depend on implementation.  If the Printer does not support this attribute, then the spooling behavior is implementation dependent.

The Get-Printer-Supported-Values oper= ation (see description in [RFC3380]) returns a '1setOf type2 keyword' so that all possible values that the implementation is capable of supporting are indica= ted.[th6] =

The standard keyword values are:

Keyword

 

Description

'spool'

 

The Printer starts processing a job until the Printer has (1) accepted and responded to the Job Creation request and all Document Creation requests = (for a multi-document job) and (2) has "received" or "fetched&q= uot; all document data for the job, i.e., spool rather than stream.=

'stream'

 

The Printer starts processing a job (1) before the Printer has accepted all D= ocument Creation requests and (2) before the Printer has "received" or "fetched" all document data, i.e., stream rather than spool

'automatic'

 

The Printer chooses whether to process a job before or after the Printer has accepted all Document Creation requests and has "received" or "fetched" all document data, i.e., the Printer MAY spool and/or stream depending on policy and other factors, such as the size of the job= , and the document format= [th7] , including a combination of spooling and streaming.

 

 

TH> However, I don't think we need to get into the details about Get-Printer-Attributes vs. Get-Printer-Attributes-Supported, since it is now clear that multiple values MAY be returned in either or both operations, depending on implementation.  [RFC2911] Section 3.2.5.1 Get-Printer-At= tributes goes into gory detail about attributes whose values are affected by "document-format" supplied in the Get-Printer-Attributes requests= :

 

"document-format" (mimeMediaType):

The client OPTIONALLY supplies this attribute.&n= bsp; The Printer object MUST support this attribute.  This attribute is useful for a Printer object to determine the set of supported attribute values that relate to the requested document format.  The Printer object MUST return the attributes and values that it uses to validate a job on a create or Validate-Job operation in which this document format is supplied. The Printer object SHOULD return only (1) those attributes that are supported f= or the specified format and (2) the attribute values that are supported for the specified document format.  By specifying the document format, the cli= ent can get the Printer object to eliminate the attributes and values that are = not supported for a specific document format.  For example, a Printer obje= ct might have multiple interpreters to support both 'application/postscript' (= for PostScript) and 'text/plain' (for text) documents.  However, for only = one of those interpreters might the Printer object be able to support "number-up" with values of '1', '2', and '4'.  For the other interpreter it might be able to only support "number-up" with a v= alue of '1'. Thus a client can use the Get-Printer-Attributes operation to obtain the attributes and values that will be used to accept/reject a create job operation.

&nb= sp;

If the Printer object does not distinguish betwe= en different sets of supported values for each different document format when validating jobs in the create and Validate-Job operations, it MUST NOT distinguish between differe= nt document formats in the Get-Printer-Attributes operation. If the Printer ob= ject does distinguish between different sets of supported values for each differ= ent document format specified by the client, this specialization applies only to the following Printer object attributes:

&nb= sp;

<= font size=3D3 face=3D"Times New Roman">- Printer attributes that are Job Template attributes ("xxx-default" "xxx-supported", and "xxx-ready" in the Table in Sectio= n 4.2),

<= font size=3D3 face=3D"Times New Roman">- "pdl-override-supported",

<= font size=3D3 face=3D"Times New Roman">- "compression-supported",

<= font size=3D3 face=3D"Times New Roman">- "job-k-octets-supported",

<= font size=3D3 face=3D"Times New Roman">- "job-impressions-supported,

<= font size=3D3 face=3D"Times New Roman">- "job-media-sheets-supported"

<= font size=3D3 face=3D"Times New Roman">- "printer-driver-installer",

<= font size=3D3 face=3D"Times New Roman">- "color-supported", and

<= font size=3D3 face=3D"Times New Roman">- "reference-uri-schemes-supported"

<= font size=3D3 face=3D"Times New Roman"> 

The values of all other Printer object attributes (including "document-format-supported") remain invariant with res= pect to the client supplied document format (except for new Printer description attribute as registered according to section 6.3).=

&nb= sp;

If the client omits this "document-format&q= uot; operation attribute, the Printer object MUST respond as if the attribute had been supplied with the value of the Printer object's "document-format-default" attribute.  It is RECOMME= NDED that the client always supply a value for "document-format", since the Printer object's "document-format-default" may be 'application/octet-stream', in which case the returned attributes and values are for the union of the document formats that the Printer can automatically sense.  For more details, see the description of the 'mimeMediaType' a= ttribute syntax in section 4.1.9.

&nb= sp;

If the client supplies a value for the "document-format" Operation attribute that is not supported by the Printer, i.e., is not among the values of the Printer object's "docume= nt-format-supported" attribute, the Printer object MUST reject the operation and return the 'client-error-document-format-not-supported' status code.=

 

 

_______________________________________________________= _________________

Michael Sweet<= /st1:PersonName>, Senior Printing System E= ngineer, PWG Chair

 

 =

 


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

 

 

 


 [th1]<= /span>ISSUE: OK= to add "1setOf" to "job-spooling-supported" as suggested by Apple's IPP WG Last Call Comment #7a?

 [th2]<= /span>ISSUE: Co= mment made during the June 21 telecon:

 

Add: "job-spooling-configured" (type2 keyword)= .

 

But there is no mention in the minutes.

 

Also with the Apple's Comment #7 suggestion that the spooling strategy could depend on the document-format in the submitted job, configuring for a single strategy wouldn't work.

 

OK NOT to add "job-spooling-configured"?

 [th3]<= /span>ISSUE: OK= to add that the spooling used MAY depend on the document format as suggested by Apple's Comment #7 and allowed by [RFC2911] Section 3.2.5.1 as long as explicitly called out in the definitio= n as indicated in [RFC2911] Section 6.2?

 [th4]<= /span>ISSUE: OK= to add that the spooling used MAY depend on the document format as suggested by Apple's Comment #7c, but refer to = RFC 2911 Section 3.2.5.1 for the details about what is returned in Get-Printer-Attributes response depending on whether or not the client supp= lies "document-format: in the request?

 [th5]<= /span>ISSUE: OK= to remove this sentence as suggested by Appl= e's Comment #7b?

 [th6]<= /span>ISSUE: OK= to remove this paragraph as suggested by Apple's Comment 7c?

 [th7]<= /span>ISSUE: OK= to add that "document-format" could be an example that causes the Printe= r to vary the spooling strategy as suggested by Apple's Comment #7c?


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_NextPart_001_009C_01CB269F.BCC60260-- ------=_NextPart_000_009B_01CB269F.BCC60260 Content-Type: application/pdf; name="Toward-resolving-Apples-JPS2-comments-4-thru-7.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Toward-resolving-Apples-JPS2-comments-4-thru-7.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVy IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nL1dW3PdNpJ+1684tS8+pzbi4EIQ gB/mstmd2Xg3G8fR1D54/HB0s+y1ZEWR4kl+/TZAAt0gm+SBbcmuctE8JNBo dH99QQP8eSMaqTYi/E0XZ9dHf3hlN29/OZLx/6/+NlzcvT36+cg1OvyJN+j1 2fXm307gRb+RolHeu83J5ZFo4EI4H5+QG2sbZb3ZWCUaqzYn10evt3/dHdum 66yR23e7Y9VIIzu9/YCXFzupGuG93T7fdXDPCr/d7JQRb05eHP3HydGPQN27 o67V0Fe3Md65jXQu/if+K/zm7uIIaEmDEV9nMN433owGc7KTutFSu+3H3bFs vLZ++wmu4Ka3crvPN+92ommVba3dnu+O20YL1bXb492xaYw0ztEHIgOkEO32 l51urJdWkeYJp37NNwknb/rmtbLbt8Pv1kFPiZV/CTetamW3vcVHyWUxFZmo X3bSNG3X+kC0tA2w3G9fZAJe4qz+hE2pnW+sNtLTkZ5hoziq613bKGnh3nXo yHlhae9kUPd9S1YDSdCns97J1DzcbHOT/ZBNF18JFHuht1fY0F1m88NkRqAh 29Mu3LYB2hwMrU1TF95G0s92bdsS2fy6KqSDnCsidKALJ+/7vox1SQfgn0H2 fbwnP18HpFwgx3RNpwsl2MpAD7ymN13jhQB68DU7vNaByPnyNRzGo6GOcI1r 53jmADcyz+yT8AzpUTU8Gw3jsMF3MKYp4vYo09nOFLoXNU4pAFwYWBDl8YiU a4TUBno4OYcWN/Cua1rrWoo8t1ljbinwZMU/zT1i3w/56ia/fUahkABQwsI/ h3dk1yNYeomg7luiuZnOj/nmHeIXPgkj6honTKsJcTfczzgKQtxVvrnHmwRI L4klYzq6zKizyVjz/U42zhhlKIvPVrq8YHsnfRJw/oSG4IIzPvdsA68zqdeh KRA8E5A4CI3SsmlblYTkE3DPtw7Q+YIlkLQ/zKgxxWAGKTLCZIHyM9aJTPRZ HgCVcNsYp9t2+yaSr4Q0MKhA9LFy4Agl0d7qCsXMKlallw7MaNsr5jAZyqQZ iIp5g3fvs9jMa6YCcNAdo5m9ALWmLSQ6XZ1z4vNbFvhvcMZRJF9Eg+skyOQD 0ySKDqFC5Z8laTy1SAQLHxTMK3iPtC3zTXz5OcqHyW87xKNh1sGqGqUHWQWn oWLW8wRWTbuFDrt5p3F2fgGaTSAI5zcxrEDe1A5eJZR0ltxEnVwHyQTbb7MT N/BOg1A6LwfemRreZS5U8Q5e79xEZR7w8hT0W1vRqu17pJuo1Ble3uMDszyH AXZWSIbnr/Ht77JuvkRMJZdvOMgvne/JnI2joKRM6XUW85NnbumTd2M+xEd/ zfP7joVRFrLPqeql9u+juXWq7YCo1Gj/Evjuimrpi2y4CXemQUJvZdNLw6A6 Sbgz0FR6CO+okU2mibeYe860kUdnDH8iCV+/6c2dBBQzWUrOOYSiE1YGdTpa oMzPmaAoW1hyWYRFiU4yH8i6ZOGsahLSdTXamvUuaeuim5vVtfUNeesYXP4u 3O8JsDUElC0diBYafNXBwBJ1I3pPLjFAJxBxhcCCrvHUQJNgNDSF/uksrhgP gYD2DK78JSveCTrr5FIwls4yxtFwqE6k/Z9UYOJNrZKYgB+k0RFyNfOUWV4n KAoQcrCJ3zI2cZB55xS9LCdieJQMkc7DeIilKPqaIWZa64YIGKEKZQBxan2b RAA9GLEzQgxCcxBBo5YPJUgocHx6nmPnDeeQEfG72hU+XkzOkScR+j5y+vSQ hW4OxZhpZJvfs9EDayrfcRJBfkdTR+JB9H+Qpt796cxM0MvGiIS4q7H5CsSz Jv2CWqpw2XaKWl8c5h1JgSVb0owypPUplUX5gZlsVEvEh0mptN77p0pDQaQ5 L86yVpe4UX11FiYVNB5QqE2hQNax/0Rb9UeYVQguu0Km/s65jmPVSC7uVDXm vDh0fpbl+ONsn0PkmG4+28muMXDBqt26LpOYnkp0yve3XjhgshSb9kuT/Yuz JUGAW0cmayIa0AdKvhBLkv/1BJ4KDw1/6wR+PKpDJReGa7tDrJmuJWjU8qEE dbZnhfpapuxfdseiMaZV3qR4Ijh3XGhAPKhj6gamaIwYid8nCTBBl2T4YO3n IkkKiCCF5xOivP6gqtFBkbHyGngPAzRK6paS9Q7Di9PMgAfObrNJIHwS2XMB 9yTYFGOKiCW/gyCHzGft7kLoo0QLjyfxXAnBKow2l/16R1k48j1CT0XSaxof Iv7yedlfR1F2vHlH8sac58P7U8ilK4bHD5h1JekINrq9HaeLLLUTpwTqE+Px Hmn7N2J6Bsg/VgrcM++nyNLWIksPEXWwYkxYG4/IwotutrUTdRrfveIEBJNv rKQN3OxksXyCCsHjBSa+Wd93JtFBEqOfId7kpX9saVi9vIjAJ/HZnNZaSFAw gMsKreIIG0MmDSny4GTlpkcX0Ygur3fc5fVm8iQK7h+wectE84Kj44pqHXae hOeS9silqZgsFjt0FB3s8R87DlzWPMY9h1gs41mHdCK5ATnximDTxBCO0Jyg KC+6lLeIOuDESTVFHVOLOhlB6oAHnFw1eHdvR4A/du35HCaNWxn+kqicWx0j 8Tm3ZkQauix8g2l6ifFDiiqUcnqS/T5fU4JkQmdcM3w7+TDTlHJL10P2a+gx zgOMxP2OSzlz6D6PmakyBR0ndGHpIk1KOWvLrPWhpFqOzJllY5JPSFTgzbO1 +IzLQpA+J3n7/h0GI2cgiZDMDAnzN6V6T1clWGwkOt+CWkrG0+hqdT4rb53O a9noIQvKmj3iV8wv38afiV/Aouu3OwlhXwHIaOrvWI2ezN1oQeuST56NY6RS 7Inyc5TMuZ3p9YEL6ImNChdYX3W/UyCktoSECt+AAAr60Unsi1AvkVGGDtMl 1ktOF8xY4wWIucqLTOgv+PygZmJfeoVos+P8BSzoGFZLpJZkBs95PSJFGlMr /4E6CVP85MWLBRHk0cexoM76JaMIf5wY/jDWrAWIIyihDUjPFCRsLUhkba8D CembASNuGJnlfYGznOAoA5apKLImnmVp4aCRdee+TQ0WHuDAaVGE8t/Rm4tr 2WyUe4Ppj5xcLIEldYQQVYQVi8DADvOO8y8eGFlmPfTDhZHVGTa4oZYz6fY1 m+Q42Gy/YzXhAwd1xEdjFzz2BdYxOE8lKLU/V8rFQBfefLPTWoXUwOOtdWhQ VoUqx610aOGeeKWDIACij6tFH2ZMj7fOISypk19b54jz282UxPEJF8xtXFB7 NOvfBieFzUzwST5yl8RFezZM4Ist0WsokCXRgohAGmU9nn0JhskFHCliK+Rs TpfTdDYqWHGjGs7BP1/2adio8q7HLiUakeNtFiIRr/hU0Tkz4WyakZ/l3uKA 47EW2izmz7jY2NIUyeFOC5sCWU+RpITVA2c81kVpkgspF92UtBstjC8X3TIc KimeqpY+wSEBF8RDX4uHuZWnAMTWm6GQ/zUbeSCesVnbGaEmi1ilex7h8gML AhccNKJh50GEkELdNLKKw6z3FokaVAYSSS76bnQDVHqbDOkBI8H1kj6MklgR l9JvpBIg54+6rqyUCplBlIXFdWUJbT3JujKVTZqUrtOn8agOVQwX7MP8ujKt Ia8kaNTyoQTFisnIDC66JvL9I3ozY+SN+scu0q7UnD5HZ3umyIrNh3GrhtOs SWkYVutDpg4M3/pQ2itBkf93BwyWneq2f0Oa2MQgG2Ut7f4RMzaR9REuyc1p 5RRbf3bGcaYA1t5pUTDUHHHd0+lKIlKxmDzg+mhRg02X3DBwdniymu43Clir XFGnjT4Ev6ZGxnl40bTON//EDv7faSqwQqwxe+uAEAYpaktissrXAUUnGq3G iZkLLvGyXoDFuNvY0j/zz7fUEqYZ2XOLvzdck5g4R8H8jZs6djMAK07TzSKl E3GTSihJGmEuTzptnU1Rs+s6fJizsucJIQF/ZgtSzplMJ1EPWuXao0TbGJfX FdbqXRdKUlpnXUWAQFSG3dr1py/er7ycPTE+lHKhZjD5E+2keeKAgWoqokRt nRo7qscLGADc2vpK0f8ZY+Y4h8Lm9Ol+JttoaBUvyGPUuid8WCsvuGV0mV1R WaqG6atdImjIOSdew6iBr1372E68gDi4I/Oz5MRrKxd3539FGSfygjJeWzE1 HtWhwhp2zR3kxNcWU4xbPpQgAOBh1yAeCsE68T+gwrBOzAfWdefsPWkUAwda 7nOAWzZaYV1fTJiuvczt/mM8kPm9G4NVSzfX924wCv0bYzMfODLQku0xo/Ab x66hmFU5u+pkY6OFj9FXUqjGq7ygNyxjl3UYfBpk4o7Y9WVM1t1gs5203BCJ Tw8SMulyOb9gg3J6+A4VJuYh/Ob1YL7cJToudA3VNdZ2U0CorbTIml2HB3HK x+k3NgY9Z4QVV1M/a/co7TFp+VoZ4kpoN1PWzWonu/OXHfvNWOPLAGBlzx27 tf+UYSdbotWHHMaPcxhLLjgSNCwO2262aJRZXL5kCqtmQP7gJc59rvFnQRHm DURJKeOqNIppaSLGlt+oQ6WYYFpq8fClDa7ie6VgZl2IEzNma7LontdKpMg6 XwcVQuadqWzFwzcok5jzec8ZCTYBODVnUYkL7k7LqlbnswKWFpNx67iUJncN lh55V6KE2NEoMl1crKnVYg79MWJNIj4ou7WL9eyoHi3W1M4P+4kPXq3vT4SR Pk42u1GCBXneOS0WiZMo/UrQl3FNZpwYptCPqElR/0VOgJvo62pVAKlD5HWP H+lk54u2dmafAQlM/gsvywROjn2VhvlsW//Ysa+JYonyshj7KqWeJval8kur JOt0bjyqQ5UHLtr50BdDwdoFtVHDh5LTmbwr2iyHvv8ddLWbzdzwhTcYTlPL PHYXtKW7l8jr33E1goUuLy59/B9nx4bSZjFTfDrR6mL/JUExxJ7TyYDGxReT 8seWKiymz1kfkl0D/9cIsZ0yMyAwU1OfPLE959xNSm7A1bU6iSa7K/GWgV22 gOVV5DrwY/vXlCr8Nt8iz1GFTFeSuXoG1HgBAQAfRrOFkfjkGccTdifY4cUC RZ4Gq5wYXpATjaY2Iizu9dS3oguZmuzmGjdFidpVbtT3Opgweth0/ZpfhyvO 8BhHhQccxVJTdvQZxbOrOl/u1+x1PgNSofTpnVOCLUkxeCt+yd7ln11ZYGYL Z9YSOC/S4bd69VitXE+gt+kcnDn7VLtqiiJUJ3mtbNxCrhgJql2gGbccCQIH xOpQ5zW8JrUaE6R1Ln/ZxARkp1VXXgI4euW7sE0iHBciOhlyQo2KsIdXFxFH QT/CdnTVwRx4CVdd00ngFm3y1e5YA2p6E8q8dBeaD1u+jsF/VZ0J4i9hwM70 OgUEurZNLUHrz8PPuuvXflKb4LrDUIR0hrx+EYkbVvuHB/cDmTY4v0w/zNs3 9LkWQCDsvUo0nKWn9umCNJabAI3XjYyntBJaHvAuMiq/Azrl4de2twXpnbB1 Lt1mXuKGzDx2xhD7LuqIBHDwLkskQEQbjpcVnrCBtO3yzQZvahxX2E3LjOIW n6DjVeCFGh9AxoRUuIr7pJJYkN+vw6lZSlk6ETd9kxaciLfxslUyHYB1qC9N tAFVsXYdCVupU0VlD9HD6DEC+JihkiGxERnB6txHfLLgfdbZQdqMDhUMKmzW UR2V96SnpKFCILQMNKk0NS7mgtLUIUmEeELdBSol9rSslLx2nJIHc5MF6xaa JKN4T8ebFOCUUwDCj0/QugLL3FHIIHQUJCeSqD5nCKFT2CulbXKW9pzRnQJz 4ux16kCFKdopcSpxg77DsGCBqyayv0YFkxag/tUumw5NVCqfyIcnrunftzsV Dqj2hc4QTSrUZzQrKsaG6aUXeZoJzK1JWZ36IrgTgU5d4WzOwDTplggTsmI/ NZHl26mnGbxHwY8ka0fxoYB+GSZOUl2e+ZkY+qlMX0c/EugsZTo3REE0uTD3 vQaGA/yx9vGOUVrC7ZJvU6UntKOpO0ijIIwqZgh8YGUBc3Sh7jjbN5yPMza5 na5VUtQW1NPa1UxspU5VA5IdpqlkGk7xErGd6A/6sbyFSjAdFIz6U7mBi9wA eeunEKyEWMaXfa0pKFpYxkEk7UvWrSRamX/mHVCHd5vMNVN6b0mmmhwIIINJ Uz9gdHCw4f6E71DNC1GbkYpAxTczfhDXTbKXmGAgVH6Hnb/s58ZC5+SS1dEZ 4VnwpUmX30OU21rt4kmGabg/YY8ncSHQeV3rrKIe0JKbSh1MjdSpoOjycS1r OljYyKQiYy72kWRWEF4FF8RqpHZzhiepXWEsid4faCz5aBJ/53WNyD3ntj2w JgMbfc7y5NlOw6NKysw+G8u20qOoVhccpal/7ZJbUpBHLAqa2KndFR19+3LQ QAUCTKJIxo9ATwfJPMfWz6eOTiQ+3322k2FlxZgSHwhz0u9fkTl1OkoUBZW0 dkEUW6nSUqCtOVBJUYuIaqTZVZw746MjG50HGgiSJ+977tqWerx7VPIH+iiJ aMeBk+t4JwaVlKRg8jSSJsnknh8uPGvuZaF5cClk2A2dBOoz9Y4LFQvN46dh ihbFPHB97QcthSGavA95JSFW5mJSSzgPv0+SUESbkd88fGJ+r0rDiJCjgtWu fuZGKvVL5arjNQUjck8s0m1mLVG7wngxvyO/WduFqtxQQqpYiuPCFc/aFVxs 5SmqOJSTeUmnYscA+U4CrsmMV9tGWwee75R1kyoEpXW7abXtV/9pIcKXlvoA xrqWDJAp9VEwx09c6kMZjkJSu4DHjuqzhMTAbdM60xGF1WMh6TryhQy4FkaF 04JAHJTX8XM5+fIinA0oIQoJ8Ui6SS5DdgxaDXj1ateCpZEylhJA4CGcjino LhLkAUDB7zQ2hZb9S6SpLFCRaWQYpmtsa+hnM9LbUcSdUF2slAwd2VhYHWn2 /cKIBTbZALHp5gM+SQhh379hHyXDI5za0+GlXrGpc2yKUPWQXwJGKNHERCG+ dBeW84xyMSkLwmgd3IyHBgJ7vCpm4oJnAKukCqZftgJLcz5fSfSCwKk2rktT eXs9jN3rQV5U/3lCJ9qQUQR01xC0yq3KQ/A4Lkkv0+9vYIj2yw8EWhyHs6Hk iY5jEEJjXDkHiSoiGPf9zPUnFUbBkdG6paHcFLNVDkUBo/rpAkMY5+5xZ0xL H/bL05E6pLTBQeudMd3jcVxrETZYUTpCDgaVIRNyy4k90ZtLFLiP3O/Xu3Bq o+w/s5hmh+j9WwomqdN7vLzKv5P3pwAZHiVzfpvfKoju1doRsCI9FdKDCLUg POD398LjdDsVnmw1lcACWan6Jx/ZapJ5pcVklVYzt/KlVnNJFLPVBDM05Jmu gWTROBW/gxgBPB78nwH8PmP1ZmIKZDzTJSzRe+sYA9SHfOnRu4nMh0dPZ2xd +n3NrBGq3u/ANxat9lQ6T7knye+fInILVSjKjNXKlFCztadmj2hK7CtmjlA9 qAVGXqb377DRqSZrQ/SDtHTO6XSh/vh7wu57xJErrs1hgdKHrzXnQPLbwcQR KpFN++nQ4ilU/dBCkJq4+AJFq5ilxIQNh3FzwIhzQLonFkrLRobNdxzGzGAw C6yEqD1pinpBtcBoSmDEMRNpYLqfIW8Ml9k7kjCBykHowB52pcJBQQkuwW9/ iiADoQfRsrYyKjfyJGDZdvlQ431Gs3OEuCVlLSHyF+pJZTQhM4nt31O0WkYj /P0Sb5YQmpq6YkSS4OLLHEGRnlgEIuSvgSULxu+xUQTAwdEE4KE0j3A39cC6 qgWIseGCaGFulZZf4ZNLi262KgXnNY7nVR8Z6FZDuNCFZKvQKVzQscB4LVzI l08RL4BjEuIeMhaCdj/tjl0jjGtdGS+MvIdxvDBF48J2Tpw/pWQ/c1r2Lt3j Tp4WbTgZA8cMPH80mNEwjBF3F20NNfgTRhlrBhE3/ikYpVxTyobLytzgOMxj B1g+BliEDGrcSaS3KS4TeT+ENLYxTpWOEXE5GA/t0+AODejuxEza4xu29yLo mneAw+/f4eVL1DZEatY5IF714BXHQ2jzTTakZ+TJAZOjPDnHyFN2I4TGeMyp J3EjyGSjH1Fb1kk0/CkciZDk70n+HqOuv+dUIwHTk12QJKU9tX6F5529D4x6 yM3p/E6iKs4lGDu0I/N9yz1aeLRMVpS4DzOJIiavOYN3PCtCp062dFAPnMON fT6nflJiz7Ow38FF74Ow7wOSTxy5pbSq8ZoGPKx7RKii3l0Mu0DTWpuLtY+L 9A8bpaSW0LsixhbZdz4BGuUp+c92rpFWghrxmDXLn4R/BAovuJkmoHc8nr9R xEMuJ96vF4a+T0bwcaUrmjdnnryK+N0FVZyZX8aZKbLmTEBHs+bpinDyG4K+ nxvkSW/CicZC8OgMP7dPHeQh0iE419b85kaeBJsVzPJgTxYFPWj/FAhkKMxL 2bNBpFolSzlnEmEFDqT36+V81NWCnI/yaKykEcT+nQuyCkEOW0vAu6PgjN3z i2t7zqLcshaFpoCWKZ2kmfvQdJzv7yGfiwylA98ZArCRj/PFy0bh+wsoXcxK r3TKP3XOmkg7Kmhtse94VIeu64dHFnaYI0G1lY/jlg8kKHweOfmSXe78620x N4TD4y3mxYfkuAddvnpON6Mm2k6iBupWmLWzr7iPr/Nfvlv7UObhJ7LgblA8 ngK/rs3uFcXNubjFmd9R+5H7nZ7Mh1ef8xm5dLIauDOb/D2ar/VBuYM/q/Ce G+/pWHjCRyrYDwFyH55kv1jGnRy7vuWZ4es6wfn8tM50U52vLaRE5a3Tedel T9CMvrISj0X7Ja7jO6noqed4CgJ7XHDxbch85BHu3OYkm/t0AmmSly2coc87 oezwE0pXTgljcQYHzJ7YS56U+ebM0Rv4cS/cc778yRv2EOJHPrhJ2a6JZryb /caSNNDg0xZzEQFH5aotouTG9OPR/wPDo2SNZW5kc3RyZWFtCmVuZG9iago2 IDAgb2JqCjY3MDkKZW5kb2JqCjE5IDAgb2JqCjw8L0xlbmd0aCAyMCAwIFIv RmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1965PkNnJn3Nn38Nhx d/4PGLsfVOXQ0MQb0Ifb0O55Zcnek1Y7PsfGSB96+jE90nRPa6ZbWv33lwAJ ZIJMFovdXTWSwtoNCV0kQSCR+csnwO+arhWy6eL/cuP06sk/fumal++eiPT3 l58Mjbcvn3z3xLcq/pN+oO3Tq+a3z+BBIRrRtTIE3zy7eNK10Oh8SLeIxrlW umAaJ+GCbZ5dPXm+ebZ96lprnRGbf94+Fa2TWtjN/96q1gZn/abZPrWt74xW m99vXatcp+Xm1fapbIURVm3+sg2tU6bzm/Nt12ppnTWbs63puq+fffbkn549 +eMTqxWMwzYmBN0o59Mf6acuNG/Pn8A480y7R5qpkLJ1lkwU5vHsm344hZpm GIoJHv41jCek3wQd18OHY0Srx4Q3kdpBubDpMrWgF9XYNnRdvKn04oZeLKxO qHrpZ7Xvqneh7Tw+9lSa1mtYkq55dlYNSKwd0KjnPQcEDNbKnhiuvLvd6tYD O2roShpkokcXBu9aE+pRnCAHfwRsbaRQ42E4GXqeccE1XvW8clhehvHZEbn+ tH2qW9VJY6nUnW6FbLsQ3OYW5ZOI6ptC5OsitCDewgNzeg2rjgyZL7co/YY8 k5foqw0841rhfdh8w73oxdByfvN0a+EysMrm3VaYVlvtNjflxjdM6zU7i+ty /WU/IhGg76emNcJ4D50rYErh5Oau3HjDtPA1b/FhQreerk47B2iWb/1q29/r VMFF5YaZGesoWPbjUMJsLgvh8J133CTPyPo8FQDAAoj1wVbY1jhn6eDIe263 kTdl51snQhbly9ITIRyOiDz+otxJJkyun0SeEl2n6Y/IKdgneZwM9HOYe9De i81FzymhU5vfkD4PKuLK6agFiuAQJVCw38HdO7D/EeU4KwEixwi5ciXkcnM6 mL1gPcirnqOgDd2xKVjGQ0mo1pKQm9XhaOhUawbVj0L3EZVpKgvFZgId1Xh/ DD0DCjGY0Ug/RpPwNUWSDOCIaB8iPBCkeF3UKIvgBDQQtxuqc/KdnignRqVw NyJKsXiHyIavJoM8LZdPcJCEBq8TRHup7eZHqk1r/I+dnsCdopXaGLgTgTOT kGhgApyXzDhrBbDzofOthNe7ZL6UO78v4+SndDe/Lr3W6DWNaZWRWdOQnt4W 3cirEkLcq2i/AOcZBRo5D+o1q3zJreRXZCEyfZZSr3Cd3pRXXVMeyqM+I9PP Hd1wJMGXn+2+fDsn3VMXxARxHBeESjdKjV6LnaWXdRY/PG99/3JidhEb9uWI R9OP5FakeMUu2fB9F71ZMDek4QEF8eoC+yTXf0C8u+TWdkbYMru8ZTtdeKiy trg33RYQJf0P0tRJQTDtjmO96k0ZC15xaE6u448rzWinZq1oBiXp4z26gGvh REYXcuc180ryIuo2lkmgEweGO9roh7U5AeutJpzOmUw6KJR2dxSTiUgeir1Z K/bcrA5nMunQzpJQBX1sqzMPh1LQrqUgM6fDEVD5thvs5FMa21gyOlWnjhTc AKNTmdFQf7uNIpRUAIPrVZiRCWPQKAcagBkdZrCYs1dO8de78iKCwBMFNtH+ GEIqnXJGBpnc6cScIlgfB33DgR/RBTMxnvz6T4vFvKSfWHv9W65PojN5QrL2 Pk7/jCwTZ9W+6TUD8JDVxe5kIy03DHEJRfOUlMzaH5TVjxwPVWZAHd8eLfIq Nc8Z4vky8SdYO5w3pNmYzgPDM0umqgRxPY6pSjABEdetRdzSyzpTVYKk2Elc GKWKZdsfCkHH6DI8zfDNK2rpEWTOkDVZ7pFNy1tGDPbEaC1CSr6BhHgJk7D2 FA0G5sufsNJ/i6KGTvoXfdRayTlwYz2n8wkkWuFpxPfjQvNblpL8u/Y2mqmI 5Un3xqqI3O8zIuET3zFdsx41H9El4MOzxiXHRWyg9oxhjUqt5R/nvOzM7NV6 ZuhEEH0z1o+u8vErt4ZhTDLjxRA5ovWAUk+lhGVRzSSL5dcCRZH4dUAhdCt3 +rRk6XBS5FZWU89rk2QQkTvvFdYhzxNPmLpj+xoKS4t7UXpiUy4TNvGhk6Sn DzkgYl1AVlOTN/FyhZDaP6WtrKiD9kHNmiU9I30LnGh4ffCyxMxMUFOkWBXR Y+R7z6WPw2MNESrB9cqPsln72zbUwM0xSGJcIEyx8s0j4qMBzcIsT6h8FHhR YI6g4Yn4EtbiSwGKdfjSSZhIjy/UssvxGR5oPkdm5yNdRAT4G+4VtbomA8xy hTYRL5eEedig+zQZmsQ+W8szyUxmnAOjwEBI75xDNsPO+fLFgvHCa23y6/cc UhEpYBMKGb6krl+Q079SFVME14tTp7yMcbYdkdtK8PKPleQxmIZGJG2hPXq8 oJzRrfZElJiIkg7h6JlgItq2rM/aciB2VgeLKZkQ/fBZGnbHzgXjeCgN11Yw sbM6HA2BXG7wLRFgFsNy2osuZWmPEpbzajRSUim4o75k5JxWRlfWyHUalQUj Dha5tDP/EEHoCzZKd7rGBEOwZhQEHwXENBabaKm901RB5fQ98peVrVnponwn ZzqxBhFbErZUgXU++MEwAedIaI4rKcP4DRZsYJnZgXMyXcxWIjNz0OU7eeSc DBUuhK61lUDsrA4HXdbNEdB16tjY3w+GUm9tEdB0PocjnTGxxntV1bVytASH S8DyVRPFUJ6CMnSpJ/CpHFs4+ZK0GJMVH5kvOB0sd1JxweoJGptkk/BVaU4Z wSWHWpjk+ADMztDZTvAmd1WoRMpIyg2cQ8ET/GyHRtojsDNkv6OHqEsV5x2H 2FUxKvFhpzFaWo/T/ybWBXMmmhm4hA0zfhE3BgDjUt9gOaybowM4zso9zcZC VSu0m+sfoVaIsu40i8haZRaEWnXW1yZZgUXbHTtRTYEGkXFtiQ/2chRwBGrK wYz/w1a03mhwFgn2/Rnd3x0BsHG5EOtJk+ABGzNky2AepVR9XCJY8r58uoKX RoQihGc2izlf6zjKCLLgxUvAUnhogq3KLWch8tjn5Ddho/QALDZjI5sp2x3O nIsTknBFGXJDo864/6nkr2g4hAkkktH/hQvRjjBt0JHjira0YHxdLReprFHJ gJDDDaHRLCqZzh7b2iUSjqi0tgIJezkKKikBim3sqFMuzvmYaSpNbNjE784I d5+DGUXa4uaapUjbQ5M0V6DBjVdaE8WLmHU5M/oMNFyx8vcLWacX3NhOMQP0 bblOzMGhIMhZYjSweZep7UPRYRqHrm685lCqMnt7QDJtR53e+2QzcegJb+yG LaLmEsqvJhpjlaHHxjKIHZdBbVV2njFHqzqe2TL5vnhnmmhjFWyFiCz2aWHA InNyxiLTsGxHtsgIjiD2ra0dxF6Ogn0itMOQ2XIoEphiS7FnSvKY3cLL4LU7 WEek9IQR4t31Mbx+XUor73B+IlxPpWYU9ZspGc9GB4F70tUyINdS1XFlMDWy 8DZJy1k/OLpnQ84JjFeM+rFG4G4Y5mrHdxk+0lRrwLr0+9uqHDZzFF5h867Y AcMW7lFO3V1oSdaNmv4sGiphAQ2lmkFD1fljoyEiC4Lh2rK+0slRsBB43Q0e 9QPLZViARDuydiQzwOJDM+XF+6pbtDj4eFoVIdntfPITZd+6fynBUCIoPLfX ZYcRgmjKrMN+8cRU+MOKPVuwh7J+MiRBTCtNqfHhTSTEl7nAxDT+RK4jULFu /IccbPd3Wp6GlX3LGITL251yuI9dTRbv8O1LW9tPJiDqpdx8lqImLvj6nIEF EJTCgTts/Yw7LEV3bHeYQAqi4NqaRezlGDCoQzwxZJLBIKZcLrHxkg/W4o6O iYBkU7DnvRk/d1VZ77h4FWVxh9hND7kgdh27rQC5kJhQS6FoBOJ/ZKdUeX95 THPeHw6P2fW7P/jewxerUKVPYfjooGcYfMnFJYegqhWj5ZzWCM6hKBv2pKmk 3BUywTU3fLYqG4fH7whhkRKL3NhquH4i2rtVeM+WqTEl0DXUCREaGcxcPkKI nTuNDwB1FDYQ6taWT2IvR4E6r4cjjZ6zkXC0yOKZMFkAqQYmO87msg015A3x l3TA1pzxMw9pGIEZWT8sUi0W1zPnGNzrPJ1oo4LeZcowIzSysc4lE5ONarLl K7MLd8866lLxIqEP2ZlmWvFCN5hjOIwpYf/VVohWyE7seXBS7Ijb6fYoByc5 RVBveZ2HfMXyju/8EE52OXjXyQ4stXhSHAtfnZDHhi8CBVi8tLZKE3s5Cnw5 mc8YOmMwa3ysxShHwXqJpAx7ms1UjhW2/fbdzrmoi3uWcs5i+fCNUYZw7LyT PEvuc5oxARLR884wNZxPBRsV0I+hYO/oQG1b1BTJhF+VP0WS9IkL8IEKduXC G0ftv7q0hHHnWLjd09JUFMhwOV9w0+BL6Zfghox5Blz5wsOMQSpI0ch4rlWF QQ+UTd11EQGKaDI1dCqIY9fQEaRAcFtbPs3N6XDYZrtWzVLQC3NkTx7HQ0m4 toyTndXhaKh9OUHtU0Svvl7OTHeojC1VppJKkJTt0pbnaWSnNjX5MOSLha7Y zPYpa9BNj62qN0VfcCVEy5U9DzrIqzeShHcMaEU1M0w/yOoozUyyx7MI+2hm AN1WzuHh8PqhpwFNbcN9NoJN1p89gmvvY7uWS+FXxrD3KXdiwkUz6lo6P1VO ToJt3Cn3uMpJx/AGwQUOW53YeU7yIbCV4BTdOLASW7lZHQ5blS1HLS0ki0i4 lNQv7srpLjvivKjPHLeyZNqtz+AsGFyL5WxsdTjFn9wTrU3HEZWjFlllsnDo DA7zR45IM5X45PzCKl83rsM5HUIHwNq+HLr9hrN6V9Qxk/5/Xa5nSXF+89F2 CiBWmkaKcXnMQ/fYKDC2JGF+DkCsOHblDRVGBJC1tdDsrA4HIPFAizkSgo4+ tn2bh0MpuLZuk5sT3Cp0Z2FIkwaMXggTgKuUbkQw9t4nDUm56zMBnY817rqT pTxL4NHqHTZblDgz/GoT7DnwfIz1NeyB8IJE2mixpRyZHp1QPhQM3ZQb32Ay jTQrJM+W6XV56OXu3u+wI3wR+8q3FCoxAVWKnSNWBiBtiHBGTOw8uK82W6Uk UDY8aAvfzpWSFqDVcysVR1gmTUZ9i1mgz0tU52IyUgmmbs9moHyTiPmH7qzd PZFg43FUdCJI1FtyLFlhkrROMCA6OYlNfPpb/JHcWnqKKSzTOkD/vPg2BXEl UCmu7Rn+WJ1zTxb1B5iNMyp0tpk24moL20VimuYqyq+Pbdu8fvIn8le+ooFq eCX+dTU8r+H5eEXKrvSWl6nvDf/KV3Jv+NfV8HzpTVtTetPWkt7KX/lK6a38 dTU8n3tTAmBv6A3aGnvDv/KV3Bv+dTU8n3ubHLKmJDkPWMqeMQ8M84QjEefX 1qhiL5t8yImCMRntDT4mhvEVAFZe1IUFvlMm1pW7iEYiHcyt2k6EtH0QLB4J LnEfkADmVi4WxEkRNzwmuVegR5W3tPk2CoSR0dJ+lZ7qvDIA0OkFIabWc+sW Oz0vPzbYE3n8Og7FgG0W3dD8fjLUU8DIrlUm7e1m+88P8ZP6AdDamU6mcsT8 pnNskq4uS/84aDJn0umb9FIv9Mz16/L8m/QmA0KZKWlMIUVsftNP1Xcx+p+f eoHjq2eVnzqhAwTT24R0queI1PHOd0i/mz4sEU8/ECUs8QZf9aaQErSmEq2I PgB2eoZ3kv5fUKrm5y8GUgTaaTVSritCoGqtyKxyr2eEwLlFOAU5EdwAEFsv 65deU04iizLt/qTilCn5yfAzU4uRfEnnsrbcE0aoKDvikayDEexlFYzkgqpK RtMaek7wfMWCN7v5ksWFKV9FiIg5lSxZXxYZ/hRv+GL71Led8dqTt55TNMk/ Rk2cu2qxg6Zq5nGRN1xz0PVmwhDxV5ZfeWwAEwIMQbA1VA0jmVo4bsJFH26B a1wsjanlJTPsJYVOlgsJ73IcfVtewKC88BXK9ygCRrAtLjjpiUUh0tM1Wfjc IpdPcdAnnJSec+QhotvjvZxB+/7lQUv6yAwEk/dkXFlG4LwMpPsbDgFZ2GLn Rposd5M3ESyOFqtzXWfvB0BukotZW1WpaEnlntBjZTkudqqWhcz0EZU8fbG1 0R2TasS52YCYYH2U13Nu9YiUo9VAemJNhaYXnDnEq9Tv1Lwg3H7LIhN55xsO jgiaXHIoeD3hE1csEZk+rMWo7z2oO5VmgkbnlOMJBGbZYSl1SvmcAEMWze+L 9QJ+dlOOgdyNBieUErzwsIMihnDu6o7D9euZ94867XeyEkMVeYJYX7krMtJ3 FBx4Q5fRBhNOidc/w65YQ/NeOEEkFqFibVUi9rIKLYwsKePfJXEVtSJFtJiq vJETQmnPCBlZcCJa3xGVyGj/d6xoT9dubOwQwGk5c6ktgPMha8As4yEhRt+V icGvfOtnOEJi66A6/JDFqVU4kVnyKS7Wvw1q+8vhv58WeyTVhg53sWbQDJr0 aKFabdUULcjIvh/mu8O2YEwnasVwvswqNMl37oEmyIeshmHRhLnznmByD4Qg Ukq/P7YSIUovqxBCYzTm//R6UhqXPVI/8hgL6SqXkcFkXlH/rlgMLD+eTKWu 127RzXZyBoFY0+J+AJThYS0AocWUfRXyI49Af0LPrB+NNGych8r/sD7CiVUe Pbs8BCPQDmDuPBv24AZgMvpRjCwE1TzmJd9rSfEzI9kUfaMVMyfN99cqQ5An /0qd3WUCPEi0iXjRLwauFG19r2CnwlNff7UFkO9sELzyP+VQj+j+75F2LCr+ KvGbNSZMI4C8iRvFgTx1wbkdBETIALkIJEHtfqYuVXxlaHjHyQjbJRn9Yvgs yzoIW0w6eps1jpZukIAo1PeNnpVfW9rBGt4j64+8t7ZeEHvZO6MKXaY8grQy NFJ3ofGSJFXvlc/eh9+BtkYywf0egUzg4+yEt08mwd1UBcO4jHyw66JwHO+d TiNQyswom0lcp++KKDsKnMNQZ9IMKFnc+HmIJaO+42Iz12Pg7WvtsH+ivzFE mmWiAl0mHPRJ1HTGBqmmcDAYxXnMa4zqHJQTWBczccNDV1n6H5fub1nLj9dg xGW84yzbJdNy/zDJG07pvuPCZaT7P2zj4VbxPLiP4U5wLKWUmz+XmVaKLsk7 SjQIXZLoanvz7mRt6ER+WDRXtC+ZkpLVD+S6A5SrrscfrrA7J/rncy4zwU3O ZVaIc7BcJoUchNi1ZYPYy3qIBWCL+AcT7o4BsZ0rH3U9m+CqkNm76n9cDCtN o3bXHITMpB8pmOXrqP0JGKEd8iBnRktBkQHBHodP5JZ0ymL5MNL+mMl9sssj c3gm7zAB8DAKWjI5T1QWxDm+obowv4m8dCY3lb9X5VSJPxJcnEZaQzVSzrYj Y55RC9mXIa4SSXzxCM3GWghPrdIGfFooZ4d3aOUdyZpZCDamg39J3L+zBwTD irgeK65iO/S9pIqQ8le+YqUnV+JfV8PzVnU14MYOC+B2RwFcAkAIuGvLLLGX dVWCqTRHqE4fx6CVwZUU99RKixj7XQHeFeHVBuGMhjRYo4GKId0kULhRW7AF hO33zD60oG03UYyPEXBKlOeInF9ijuf3IKTSik5tfoc/yjKRgJQS5UeBP35d TfTx1zZECKumMRcWKkOqMmCMYc0HxqppWKv6xZJ5g/NBF0sqFasP6SxV5dHm CcuiZlpUA4YE8suPYmuMPdy6SBNayS7LOEW2O6htWccd2a8utBijvIyFiWmd VCePsU7B1NxYAeJiCSaM1OVCS2h7LLRMf+UrQA5yJf41lGAmDTIUQJbe4glZ 2Bv+la/k3vCvq+H53NukzFFqibv5we85Qpkj5STUVGvL2fmFSbcMYxaPqG9A q+WiBlLiczFRHaOax6UIy04XXZk9qg+Y4OGy/cq4yKSrWy46OONzrIjacBmQ ubDNXHWoczNRmyqVMB5pMp93VwTOhbqyTc8aEU0xb/vziGF4rRclF3DHkZxN slXEJ84J8Q05QD3jBnXD/Xg911WdpouVTVM/E+ZHvBvivbGOEL50j+LJaaiL mP/kpVUshyq7Ym0pF3coSFCsK3dU7ZJ+Db4Eij4opYwzysQNXPGdIvTmrjyo MtIAzLpCIcIGuEyf4o8X9PpYl+4ZlVK6ikqBsVhHneIP5DqYzfX1+AOJSkVq xus++Mfsv3SX+5/qOKXxbEEvjuGN0aVCHbe2lJ/w3orslnQybtT5KRTCnXFo t7Pqiil/H6W95zTdCrDNI73dpTWqmNru3Q8mrNz9AH3F8rkqGM7AIoanPsQf p+L8+BZ/3Idlx4y0s7q+UhsT213G4Dh4nuCqumPY7t7GnbCcIISZSscjUFUB EKp6VEuJi3pPxRCgIwE0FJWXfDK+J78BzErkl94cgfwgEPFTnnSiLzieuUyz t7HwDgPB329z6TGZ5658+WAqZOrwaSNyQ2XA5LcS8hKm2DP8PV8XT147E8nn uY4qL2n8LuX1iDqLrBfqrLX7RrCXVTrLpqjIo6RP+OsEi9tSuLiqaoCOEemz trIde1mf0upigNsGhg8O4vTqdJ7AvlUDWWl+stWtDlZWiQg2QgqmfSMHhfCY ZrtQIR7zhePfPMUjA1K0Or1ZMZb7Q9+sRVKchHIPdvFhAIgOwqth9F14fLqB 2hd2hm6gOYc36wPQzXX1m5/TeO+MbbcUxWA3i1WRUi18Pycl/aNTM65Q1IIs NZ12h6NmPBu1evPzzf9Dai6W8sxXEY+KetiNc8S8XuXVM0nNUQ5mur+DyXSH WhMwcyGZbj4BekMkkgmAzIyauZOd1HNsfolVq7/v8VXroRJY0qQAaXpsdqX3 rwnJtqx9xJZ+35avJgRbvuq3VNI0DQmmA7fnjU/hwINNrC689KM4yX5xiM5U cYLOjOIE8QdyXahRnECoKg4h1FycIOrXI8cJiIyiTbF2CwzBmLU2hQgWFgUk +0g2hfLlJN8P4gkXPohQ0o1C8rsMCJZ/nq2Lxdj7jyjyLFDJsXTGh77lUr2k p2r7LRNRQOwhs2PLbdn9ePyeYLZKhq2NIXHY1xixIC9gIyL8dtGqaI/4SRjo ZcoTqzg689CinukLEUMrVdl3w4ceTrjqwbp2hg1YMAU/eziHOOmxcyhC5Rsy ZSyzriFqFC5Jvb9zyx5yccPxz8xCMi+d1u6mLRFztTciwlyCkepEswnEJrg5 MsQSyAn33kOEvayHWO9t4/q6mCOhLJiz+UOvhGXu0HO7GTvWuxJSzJZHYhG8 5Db+nnBd8VXWrC9Ube5fOsyFyQfi8y3re4ogXFmTx7X6ZfI9ywrsXzZgvYy8 kkoArNexHXpDpfyVrwTryJVgh2dkbAfeuBFeK5Lo18dI9BM2RMlbu8VnTMo9 RUCo8u4VWx74urClIhf2NIfJNvHV9sXEEvf8RoKdSleZOnm9+7yjJbn9CCvk 1sXOyHIgK6zdcYO9ZFaQsomf3zL4kPGZEeK7o3S4dnjxv8RQjAbXO85IhNbH o/d+3EoLWtyZfDpbfwRgVGPGpC/Zd60AxyzEbFb6tcQNk1B/FyvIQoxgmF4I Xd9+PbT70tD+nr59+eTfm+v9DrGbm5sEGANnqsyNgMwfH9az6iwlWdpYaYS3 kV/jgXZCps9HleYpNgdSWYXfutMmKhgR6/pENNTiqbuilIu4eNJ2T2qnI/r3 LU/JK4ROBY6q0Z6JFAKNh8uys6Nrz5tYDsD9/2uY6tkCHCtY6HgkfDoqzvXH 0w0Hz5W/rsiRdvHKbntAh3h8Yjz69Sq3lW10cPE9OrYAx1PrFN7uu779Gtp2 uGMYkyot6Ot0GKlyXbo3teN5fukppWMr9hVbp0/6d6hUDda/Obb70cSnhhb0 dfrk4h+AhD2pVKtl8wMoFTDOm29+djO5hLVZ4oZ4tGL/ThnczjXPxwv2V4b3 CF9ooUDK84i6Jo+zK7SI7UyL2B5mqkpL+EwLJbTMtACt0PW0AHETPS1Sa6BF ag+0SO00mvTU0IK+uFX9uc1g1WoCnoW8mqUKEv8qRf/Dlf49XRCZFkoAAgwj iufU9uMUMtMitQdapPYwU3hqeH8QmRbSuEILaexAC2nMQIvUGmiR2gMtUjuN Jj01tNyO1fwZzWDVakqwF8pqxpNBcTXjXwmPFV4Z3iNlpoU0SjfDiLRqhnFC a6BFag+0SO3hrfDU0JIy00KACZNpIcDg62kBjoXtaZFaAy1Se6BFaqfRpKeG FvQ1u5o/oxmsWk0wK0xZzVgMhqs5KQ0TuKCDjzS0g2+GQcUv+/RD7XwmR2oP 5Ejt4cWhtLwr5LAByWF9Jod1ZiBHbGVyxHYmR2z3o4lPDa2wY0F/RjNYt6C9 SZCWMI2rLOjIr3VkNaM5kGlhTaaFtZkWsZVpYS3SIraHt5rSGkyO2NbGFlpo nWkRz/vt+4qtTIv+FOD+zbHdjyY+NbSM3bGaP58ZXNLIgNYOQDnisXB9IMTS E97Brh7us+BGpfvAG5ze9x2MEDSEjnuMr4ZOY/t1eYFIswil3TtA9wk7AMvN e4k6RjpkA6q8dcNGuP+0jV+jCN6qzX8Gz1Z3wejNX0WXxYoO3N2/il+J8EKY zV9vRQuUFnrzX+Jl7ZWwm/8avRhwAYTc/Lfk+HYOmv99G71xDW4iuf43+NRX 8fsd4OZIt/nbbfywjgxy83fxVuOtENAV/NAGV3ycP963BGueFkbZuHGa0uLT +K1va2HYf4rfmAI31sQkOxAgfXf936Kn55QIevNP+OtH5aEmenfOOCH85vP4 wSAtwVP7F7yV3nBL2m/iV/pC+TqTcKnee/gtfQQknguiaTPHmelms4EZez7S wTRB9Pk8q+9ZE7WLfoWXurJVpT+TxVtgG5GG2oU+eWFaCXKW6vXzBG5ZYl2Q X38FvrAx3ptVdMOnvkn8BorY9h956d/7Ijfj3lxwu3Wn+5QtsKlNOY2hT/IM ab6O4hBUl5I/uftrvP4yPw6dg1TJPl8X59/J4bNK/Y03bLPM6G15/Bbndr5V Cpapk5QTMtHVPkwhfRNsX+Bo7QGZQmEd2AnLCXRJeQIVSr7E3wj/vEtfr4m5 pYpAU6Ghb3qRbo1fKotBrQDApGux/RiFtTDCDV39suZkKB/EDkArmfSRhzws 2i0Cyxf4gi8KxjRbFT+l49Tm37dPYV10gCX+ZCs9SFY6imh4+F/xnQUeCOtS 0VhkBWVhmbp+723PEQdiBWlisHk4RbIAKOGKnqjeaZGlK8W38qTJQ0U6rpKq sfBPOkAJqN9/k7mQ5zrfWdOkMMqv83VHSVqav0GQqD4tUZkF4DvsZRbE+/LG WdYsUFIVs0ClHRr5BaaYBX2bmgWPZw3ED+7q92kNvL2nNfB4RgAhwYONAMK4 8aslRsfDBzNwE3YlTFxwi2iSVdIMDkPjdTi8NHe6JCnIVIg0n1G0RvVcpkKu 302V3ZxSZdGcUuhy4bWfsTrmeuEpidfF8hhKF7yaOMUhvGGHQJkoLnRfsfSv MXXxAbvqnXFNGD6YdkgbT4NTMyx6VpB2+EBlXvQ4cxDcmP3KGIuSQEyUyigb yFWbZFOrqbKPpqYSofYC+1CTb241hk4vcB6k02KTEB5C5iVrXdlnsYwaMJPq n682nH2HNskNZczSlMiju/Eg/Uvqw2t37TsA8Z41vq3t/GhnAUOkOZkQwuYH UCg2jAiO1DvLk/tqW35rs3QVRbwkE8qb0DitDz9zEDg7CMVvUSjuUChqAM+y QJb7Ms/4fIGbKOC8Kg4IkRDCWdfovzCAVllLu3XOK0ZSr+fGxIndzJw5xF3g ZhcL68URuNnY4ssS7fwKDdRrXN47nmznxDDPy3MPNgaDvvE2HB7atZgAOzHI icfG8hPKNOGBarmz4UNYdI3evqdDBszioIeRjJRFWPYp0DJb9ClK+9d4r9ub tw2sDojz4XkbFkKWere8qASuXo6b9aIQSs6iBGfUVCjALfsJL0f3NfQOYTfQ WczQAXH7hLDJNHDzko9ALDGJgoXvjqDUorM+BENPqeiPUI/47YloM+EWzhfg LRtC9TOyqpl+nIW2F4MQN54dVmGGU+ofICIwynK6uk+3c+sWS18AHg+P4sIV t+yCki2b5W97u7cTU69tp+RVgnEPws9IDtGdLxhqo41zW79r3zjfN6UDLvKr 41kBe/vWSgXfwEsPHjTVXSifkeeFj1gfF/wiEchiXRSk7BLOTdio8tO5RMUM Ci/EySsNPpX8KszLou2MFcbN7setdu3wUeSlRVfxc1ni8IjbiXII8NhB2g9w i1x+kKjWWe9mxXnOBRt84m8rkxX9+L0sVtmJxg1blQ9JMfDw8pe+P4/jDcGp ULJsNhAe/r9o5mGK6RnwjpSTpNKE2el1wmVnC9Bz8PwTb7SMcyVmh1YSMT0u Dh8sVPGwL39YQOM0AQk3/QZXcyaMD0aZwzA+/VZ9HcZP95XsPr1vCOOrLpgc xk/t1+UFPofxh/ZBwvhgUma5eC9R/P/xvoP4hAC/oES+jHwWjpCoUzH4QY4C qoJU0YYkQf7Vjtpuc3DOUVuRdWex+I5xXvkgLX3qD1uhWxF3NpDgw59JsnbG wSH5/Glc75pVGwtL7wFFrGeMEG1jnaNPZ6Uc3itU2scjOxJn8OC9lgce6Ivt H5K5qISTMXkqd2h3zvhkwk120bt5yTaXgipzPLrELjI0QR4BKbQo2dJcUVFF +usAXhYcvuJln5IKEsPbvyqAjeDNObxMXcAOJL9exJATdoKvmZA6muTVqu8Z PpTOqiaYw4cPlcLdaYtr/pyEWr/Ehfp9tCBsPEuFpMZLTivg9AXb/JrNpxC1 XuVaObdxj2Al3qzywFryI0kI058N/7PYxURcaDodSsCELjjHeZE1YnUyGH6H Zw1pyhcoZ4u9JpGbv1D1z0VkMxlO2VDCbUWypxKUpAA3kHr4eMMpulcnzLt4 CJqRbLIqd0vaZ1VebGozLFsaF6Ur/lUVwZhb56RgibNUTE7pg4c147eNlqoI MUufS8d4dGYZajl6RKPRe6/rc3LvHP7lHwmiVAg4vHYW/7BdIWDOM5zyZYFz a49ZuoWlN3Gngjh8XEzFo8H6pbe49AwUd85huZ6e9/OlNm6fcr10364qfmmk zX5+ar8uLwjZzx/aB/HzwSEsEcP34uj/z/ft6FMK/JI8fQWrWzz9A8Jq5G79 H57+T8nTBxsKPX2aY+o9/Xi5ePoHTEFJH33h//D0f+qevgT1Ugo/D6iF40nF eXPUL97TJ8z4Icdk0tAUclX+xakTtpLvolr7XWnVW56fF1kD6NR4dQQlEqPt g3Fe27itBDuiqrGaKanm7d2pXkXNfs6sFdFgr3jfmbHgFe+wS+Lz504N81tV DE4y5jMIhKu7oqRpaZ3jVi5lDg8BxtFjx7MeOOdNBOJQvWIdbH5/FHmMiNiM q415aS6xXVWWLfrnpJY2u0tzMsz0xWYkrxmbYMb+mPMj8Y5Pik3KbZ3cleWV nQVr0h5BR+hQNnjl3W029ARxzo/KZ7OJyRXzZBoqsg2AGGa3XNyEK22ZQ+nd RboN1yk61AsperJ+lQm6ewdMZUpOQWAukrEj77+sIUSIcUFxBA2hRa44XbYl WQGe2S7M38HjLGsKVuXyU6v0MXweEn9hXZo1pu3cBuKd5dAoDucsay6ziRKN PwZ+xMyCn2wgJ7oGyxgJVe+4LXU7qVptL5opb+N8BZYHP2KTEcuAzod8GZRg zcfvWGSjaMYF/ZaLYISXcp/g2HCfnQ2OCd+fqtR3GkQOjsGDKgfHhvZhgmOw bO8zNva/3ntsDAnwEwiNLUCMM8BFkklexv77y8eob4gfg8gIhGYLsXAJHJTJ fc8GmhZ3O7xaMoX5ANaMP8vhHcHIc273zQlVB2kE8hGCGxzu8FXaCzwBRkBj 7eGLE2WnSxD0lxva4Nyq33DqZl41mHh8aFYNYV419PfZ6X1ZNViDqsEaVA3x aNKsGvr2QVSDCKJ9n6cc/P37Vg2EAD991WCEbcLwyaFDOinCqwID7wv7s9wW i55ANLvT4WV1fbBZT1hkutyyZuhUCUzVEFraUydzMcSdSXG/ALfQBrSAOrzq BxujJDx+YVqAi2tznsAfn/x/ysHscGVuZHN0cmVhbQplbmRvYmoKMjAgMCBv YmoKMTA1MjMKZW5kb2JqCjI4IDAgb2JqCjw8L0xlbmd0aCAyOSAwIFIvRmls dGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1d2ZLlNnIN73bZT/6CG5oH 3etQUQQIEKQe7NBIM7LkGWtreUIh6aG6qqur2rV1q1vLfL0TJIFMkofERW3S RFgzCqF4SRBL5smTiQT4clMWSm9K/79QOL48ePcLt3n+/UF3efPFR0Ph1fOD lwdNUfl/uguyfHy5+e0TelBVG1c4bTdPTg/Kom2b0jbdDWqjKnqg3jjlisZs nlwefLN9e2cKrVtttt/vVNEaa6vtze7QFJUqW7O9hsWLnWqLuq5VeNzq7YZ+ No0pauuLtTa+Ddsnu0OlCls3bnu2o5K2VbV9xjXRrbpQtjZ6+5kv6rps1fbV rqaLqnXb8/imK37oNT9EVdENjbP+Ia0Kp2otK+VODQ8ZaurR8JATz4if+ZkN X7wRz4TGDSOiG7M9js8844tcEZfOacBUWZYmdMjf+JyLm1EzwdUX3Yga3znx /qfyXlUVpqT2veGL4mWip9yYYUaNH7zvnnxyoEuaK6dIap6ckJSIZ864pmdx TET7PvOvr0qaZjmLoNOiTjFm/NAGvvNoNLyusGV/KxWdIin7dhsrUHzrtztU 7RGaPziTN6lmn8jx164pylL5cTxUVU0KYjeHTdE0/WAesSQLoT6BSsECKpQm panzWofZgq2N3RE9u0bitCgEoK5PYhNHQtohgBrd+QHNTEl3SsV6BucbCu41 lHFRP6z1JRffwK6wbL1m2cKicyXHFXRQ3HoB9S3e+WGnesq1hTNtUD0IMqLR l/R8VZRV2VL7w+uvYkkM2sMP+kjwh24IwYfC/JKLb7gIpf01wnWhLKT74QWn /azpspaKAcEFw6wY1jdoAuG4HMb3Cw275QSKGQgKmGMFkog3Els0AgJJ9aje iZldBei5IX3LF1tndTuSvV7yaRxUHSQfIjEP9g/oZ9EV8aINRDYoDeKpU4j0 YuK5gRgPGQ6oVtUUtmrtTEv6LmPzwDyrFzw1Ng7CZAghnwmZvzgXMjLQc0o1 gQnuAEaEI0QATqO8jsYaSE0Gq3ghsCe0SUj7O7D5LCsFnEpxFVcwM7QTfb5G yABtDx4/LDYLY9VpSO1/MUFDsNpdoQEcGbRV23gUB1gITSHHp5NcrevCkeCq uqgHyUW+hMDs2du84B1BGR25FZUjt0LX/+9W/MJuhbQMoX9Jjv10cCfIE43e hOiLwFiIzJhd5jDR0fyHZj+YQzKf4SUnY9DGfZyMQUJWfAxbNLXxRoQ0MtOI fNhRQWdcng2ZOhszphJIs6Sagv4NfVpimoEdPxy9n+tvavrulTE9he16DHUI PkbVNEEhb+mpJ4ngMMlyYKcugm+FID8D/XKqxd7CDBD9xfMo1z/QO6ui9nIn fhc8SdQvdGDkIoBeCfp2v6QQENQFdxGwi0UfY4CWJR9DCPS6l3gymsy5louL D07AAv+xRdkoltuJiEyaKro9gozwVB4rA3YAP4UxI80rw2yMaKWmxrZt63v/ uycHnx+8PKg8A6SH9eaSysb15YuhbOqyK/t7+vLZwZ82V3cLHBtjPcurbd1p 6uUB9ebJi75Bn99LTLo2ZaGnIWlhxYQdei0VN5A/mmpH9KV2Wj4lbmWQYA0d 0UxtSVbsr4pmQizB/sf360xRCN+Pu8O2sIoIw4Kk31YVgNs3Zrrz5yFuLVDd EJauKx30/15Z7ZJFht7sukFOOb5Hsv7IlDLM7K0J8B3t/DSybZtRZPsM+nWj OH0QbfH7Suzd/3yzpDoT877s5iTs6IeRoS6E6oA/PLKimABzrDXq268swg0p 8HxJZQ8KHLq95Bd1trupCeiR7o5CgnMfASLDOWv2nPRN2vfWTmkS1WafQOBI wocWY356CoXx9Qp6TwLbJ9GkYFY68uGC8Zr5cHdhgjDanGSCgDRmMcEgLDlE MA/w7n8F8o9ML95nPP06vmkz0FMy97x0c9fwYVLx3k2KM2TSUbOz+LPQjI73 +YiOKWsierPCq+cHlW2IgJZtu1FlTYyv3rjK/0dtXj07OL2nfAZdVoUmWqo8 cevJ4wlUtRt49Soq4PCUMpXgiYKzPYecb4TMYOUPzzpPNQslQ8XPU2OZG4S4 hvJ9FtE0RS1O4WuPkbWAMscmJOXSvUHVn8FOpYJse8BDH/Yg97GeqydPxJ+R rcGjewoXhnOA6gWy8clVjSMkdUuxwU5T1eZH0hxnq9Z3flb44iOvrXZjqS3e pbRN5cvepfxS/BV/cUr+Qn9dhudd1f2yjgwEkvRcSQptW7WEDPeW8hQgojTd MsUlJ7N4DcaGOWuJDTigc4hZDLEsBfyCYgoExjwxZW6vRko2yDZD0BsIJ3de TeABupbsOQzQ08Sr7kyJx2q6ikIjkAax0QRy5wzQnuq6rqpaN4P6XPqyN7La dWrHf8Vf2tEv7fCLf75telUN2nYfSmZbWww6NltuzFwATFnhgTBapwZoH4Bu 6I3KwA5FDKXQ1B/uWNOG4FTZ+KRM2xDjM5O4l6Vp8+hlmkptrC+W7aZt7gpl a82x5PG41or2fLNtyQwVbeXabbWzZenHopsrIl1lSc3jWtxQi19Dbke1iF71 twxtVvfQZucK3bXZlYWZxg7jPMXBdJV+7MGMDZODaXIHc7l79yiPcTBtUwyE 94mHVUJVq7b/6VvvtFH19t935BG3rm66cGZBulo5+ft17OiPfPGZ95NVn1vT Fq6yZUPXqF/amW6F+tAWVpEj7a1OV6mpYv1U/JhvEFdP4qv4pVex9PZON4SJ kTipuqtSNTQ5DP/+6ll85pxaZ7WqjKjnf2NJvHrUt9gPcQM/L34fhoGc8ZM4 DLhJ1/L3UOdzNHbj3oVbz/kqt2Spfjgk/KowdUP+riL81NETPRH9DDe+7sIm jTa19+mHi6JFF1z8nqTJtZWysvFH3LunYIrfoA4Nj2vbbD+CcxPMvXLbw85a 2NqRQ++KiqQ5SKDrRi40/ioOgngRd/NVR9NVW1aixvf55eIhUXwVbxUj8nS9 c6IbZP6s5zreOmlbRgNVm6qHudqQ1fS4YQas6zAuomBdGUZB9ygoyIjCIGhz QTBU8igYaGqawr7JP8QmDyNvnKcIQWWE1M7Erna1jbNY6UFIHHGQzzq6QcJa D+LgOmKyrrJzvKxVQ5VGZHyfxLU1TaMWJS/emiN6Qdx7VfXEiTvyZd+RSjvx 9A0osfaKVuDOMTRiWzC0w+nxiIWHjiXcImQ+h4ODb5DaFuf8algw8gE6QeZD A4RpEJWKZl2g0T2aza4bNQqaqyMJb8FyiYcu/fSQfPchkeGhC9h/0emb2JUL OEHiBWzNj2D/3iArCAa12v6R3KbGWm0lgn49FPWoV09RpQtoSPdvqpL8mwqi oa3sY3NCgS0Mh3UuHMZaHgUPK7IlA4QL9QUoN5pyceuUDXUPnSCOA3Va/C6m HCvyGZIORllRlcQk8DOiHpAhwSpvcDO6ETHGjlUXaSGitGyCMDSeoJfClnCd PAuQ+TxHRJHBLmBhSy2IyTPCMRAdEmCUQhhxK2yzGLEjyTr3GkbXeAPOo2eK hnycEcJ8ExH4i24dRtGE/Z5N3QeEVUSzyC/SsXbWZQVK30XSJ95CxpOmk1wp LezAcY5c8NRA8KN/CPyqdgH8TFU/NvgJIOEBc7ngF2t5FPDzgaPBia9im4UE 6TgN4qKVF4PaqBlkkIbk00YvgiPamPBXkrQReyyBTyzRxvCuPT0W4ySCMKxc I3hijpfl0wJHHb1IOG4/IxSHMAox53yAv9pjRIC/C8gqk04tmDv8+Nosueru bmWcJMFkz8Awsu++RA4BT10gh92AVul4AHczzf0qY8kTLssF+Ksq99jwJ6CE 4a/Jhb9Yy6PAn19Y6Jt8xPB0yphwCgnhsZ/Rsm3dXN4G7gd0lcX1Z8Q63tod loW1RrcWhv6E6WRtWqcSbqRujLSiU9BzFbVixXzLL8ioYQV37rmuO8sX0PAz RxgNXhidFHFeoMgc3BOBjBBHAPAXDVIfPusjgk1RtyLlP6JrOqRxq1jaQ2Be 6DwEmJegzmlgxGOWCHzyxff8MtwcneimjXalGcfp7qi1plR+o05UWrSopIkQ PnIEkDGEYa/NhT3QpwdDPdO2RbU4gsqUj2Q5jCcWo/Z8I7yKUpTyBnPav0Qz Wl046x9rXEyHSqNxsACsM/v6dSPWu4TFHi985uXljhrVVMYsQjE3lL29b7cQ zUf+aqhXtLUPU1XNJGLJ60eCJMbfxUIaGzboln+7i/DzHo/FsC+WhMHqJq68 IDlQuXIQJ3QvORgWrY2zMeVF9G3BrAQDdRwvLtm3dU9fVPWpz2Kpye54lyj4 0KIlH0fh+ZRNyH9zURiWP5BElIT8svQ1/7yf9fbOzV7mu6SWYo67sBy590LZ ash/2UKuO4ypOMkw5ISDo8nvSIH2G2AiKRAP4TW3JZ5AEjpZKhaRFI5HhYfY LX2BaAaOroiaOAz9FQvBl6HFTzoRqRsRcTnUDTXIuDWt1LlaGfUrSyvrinNk 9iOaqVWZbPmceOxwfSJrRSoln0AoB0mtuz1WZOZMaYX7Ol/cGQcmYDxx3ORg eNJNDmTw2Y58Nucqs0DYoffNU8c/i76fRu2RSztgEei0zz1rSbCbKKbT2Pck NHmE/IJR+Amqbir8dBvVjY8v6i4QUZg+kQrrQG9kxA3mySHQ0iVdrYgdtvJt W8OO3NSriAJZ0GHJNJkpduD1HbjacSoXUMIwsH7d49owCBvsGRq77br3wnIn IDNvdv12oTJIWNOWGiNjejkXDTh0TkUDcAWwKyllGTWwB5CavPyY4g4rTTrP nFTk91hpY+3Ye94z1jFctITsE4dDDanHmQ7HeJgZWnloRpDADgdIeeqNEtlw wJkqt8SZ5sFMQoeGhMmsoUNuLiErehY8mLJQg9s3Sl1BpjCdNAUy+aQVCKUl KwDss6iJHTRM4KKPMBdbDmFOGMvCknYqgy66BtD8PzR3h5yCBVYuAANMlbH7 BaQbsX26p9WRXezv4SQh7xwh+ogl+WGgl+HlCDgKqTWjVFaLaNNJoieQHxxJ bY9vfYFa9XQ3W+M9pCeLxqyyhtz0OtbwLFzwCbaDy4HSFZYI5TwiIKAEpkRh ER8BiABqADD/w2CQNacAbIYGlI2IUX3icaVplLYQyrIzRHzrszJEWEqCyUmt B4wW94BDJ+j2GeoITIUZ+TT90mg31yAMkFzBeRAbPlxbWr8BAJNy0/iiZLnz KF8y6MUDIt1aVvqyqNrVMENuEhmrb5bSq7owubG/acxHcvFK75Hvupq+dWfP UaSxip0MInb4VVwS+4Of7tr36cNRlDD0dIlLCNMJKCXUUASpQop+Bkrvo9qh ThaR4fy83vMOt0JzvP/i/hJ96dlAW5Q2BqofYplO8O0zZK2hKh8hB59zD0ax XqTUe7iurspwYzBG8VRxiLH0Zzis6X5uDlXU4izV91tdzWirK8q47CIGMHAO TR6zACEep9C3WBjPCeZnr9qDoNkRsjQnKxrnW6qnGtcj1rLG9c5BjnqJmAZY ZE8mZQFoXohpBO1K+OwjlYzH+9eRnC4oZyLDScYRQJiBX7+inePgwIJ6wsBS mK91CpGTWhEVua5IUqo1Rc7NBmKdzNHkyq/o1tOA31Q9h0welHB9CmNqqUjd PXI+GOgW6j8xstOFYsDrlxa7gqL8NqYCw+wkjnbKYYwqszqMTlpzuBj2HBGE VNb77Ua+X72jP42ZB/tyaPd4haGxOp029Q6ag4xu4l026UVmlqbwUlETtAUw xXRpWyYbckJVPqgK6X9uWgxrcpb+E6NommxLPl8BmgBAMssrweNTsb+7rABV I1vLS2V4iwJ0n3MiEhlSm5XbGwxzTgL2euoAJjh9zL8pOLFPMoWIa1mbvfZn 72htfoG+g9jqFUA7aDJSTGI1d3w02qEVa8R0ARVHXeTeMGkgXW1B2o+Ej0zQ iOqfBRp16/9z36TheKQTvMQzH/vHpArCUDFXCDWlqMLvQ7jjmnk+xD7R4p+Q Ioz2TIEYgHge7wiDcde8DByI4ZN8gevB7/eHtUS8WIDzZC4O2L16zrlAbG3P UENFN+Uqw+rxE+KZ0Y5ZsEltHIkNILawnw04AM4Wms8JQ7qcm8LHWpmly9bF c17yN557vbmRkLge8oKrf6llcXhCxR1TCkBM6KnAGZC5c4ZaEU8WEZqakQl4 PFjPZsnyJ2L87/LPqMcL6ejBDB/PZnOs/jeDG6/p9hhyEjX5k63b0ljpKYdk WhcDN94+4qAWIpMLjQ9NGsKzZXfyKUgnOkcDwrMtkmpzCJCYblUX1rl6QSl+ QoIDJwmnakz0b8ggGYSstCMqQOPQgJU/LuXmGjIQZMGHsf5o9Q4+ZCa1CNtN Z39i+fYYyvB7mL89Tv+5Yw4IY9JCZmEsLhx41K0SdGGrSJDTBx4BApGKDIP0 ueQaweq6Aoyz8btP0bvhCuB1zAcwRp6HOU9gxIv8e1ogV80N0DjtKPW49IrC DGD/b3/GseDzAU7vSJFrkNrDpdzEP1bJLEWuquJXntnDlnpVWOH+2gU6tncW XGYidc/zMeEIVQ7bUayTy54QrVCHWX4PQf4v81D/XRntPw+7tObPyaxQjcNZ X1QxB/Pv67QXCVunyDazxVXIIL7DFUEzzeswfG38zG1IQHi7kU0K1Y88QvGm gCxTj3CEWhIXiD6gBQIu5ab8RQ3PggV/SqzOjg8uHJQCpAJyguztoh6gboSB vI0fskeuGXRIw+9p6zDZ3rzXot8ChCUCjRDDkAsxogggYJVa/w4ugsU7Cnit DXhcAwDqxmUDYBWyInVJdps3CqNGitdkISAYDZyvl4OGIAiDyZVk+hbtDOBS bo4f63QWEvijfQx/PqktbQVQWemFU/FgjpDc2gK3DQFTfdulHaSJS4s7QHtQ U2+36SPe2e2vt6U2AKboD3k2y9233DBdeIBd9WHBn/oyXyqEyw77pT+6zMgI 6yxYM0yA4lMkK0ve+f6HpqJ8/lqTewhW/7iUm8LH2pmj09pv+69nh3qspqHn 7p6ZrD4tbwxM8K7boOzdd9wEMRqZi/j7BSyGRruUp5LY2AdXkFKB0SPkR+Gj MG/QhL0rJxzk8Yjnb+e9LSSAw5QfAc7B7CeXW1+gAcrIwAZLizlHy01O+2oU f816KeeHS7nJe6y/WVrf1PIAjUOqrU00LDcZafKKPdvlYyGDr/HxKJTIFH3/ VJBw521TFfbPOU5FM9YTDFH0MnVomlzWxqeFTTbI+efhhmcs0CjdiMEKHkYA +TI8oFW8Eh+ejpKMhjBEaYvKRsM5OrEy1HkqVyDmSALhJbFI3PdSHl4PF1Sg eIhlkMdKK2aa4Q+xUWt6nZtkxCqapdi1DwKHY7THZrwjHGtbZ5e1YCHLd311 /QhqJpReeZpLkIql885APCHDDTkB+jzPcfDdf/B9rOuJ8/AgQNiQkX/MLAue /NJHGF1Bvjyr9gozq3QKrJb4wBy0oXOSRfVXXbxjELCd8xq4r2w5JoS3bHLo sKFLwJxzNDQ3TYgVOEvtbRlPB5ptu5vq/S22UirpIP/iG+8mVH56NDPYjQd0 tXLJfct88EwUMnGg0adxf5LYXr6AacCKPx4dCEcDWT7H6pbEYMp1EF5P2MCq TibIwJ1T10GOwPgQIVuCHT6svLl5QayGWcpbNeEQoazdNADP0mf43gpiQ02r X3lZOTf5VmnLv9jnNh4lfMbOK0hF+DgGDk8HMm6Kupqd9Z6X8Xx/GYjoHCHo me19BBjKPF3IpmbKTeprQIquFqVM9Q2KmKW9mirW8XO1S0jtdfKWkD9xf8yE Q8+z6vI8wHVGCbt0d2q+mheO2z90v6qwCMJF7b12rbkWc/X0ptLEslTYjK9U zM9dP8s2mb4Oujh1uHrMZTIMZWXBnWfUuSd3ftmCG13lGXBGDbk9v6xAYi8j QG5CDytzFgSQYIajvO5qwWHi7cIe3v3z/VOh7oVTwFfPncDJ3PLEUbHbh0/l W93VNvB4U063rsyN3DzGNt1OHrQKhZzx4CWPKfnzLuYY5kSqeyAoPR8SNnwe ps85mHx9q9FyjmKX0J+a5fSnCld5IgIvvIADv1yJDv2TAQe5uKc1iLoxAORm 7rAqZwFA/8Xcv4iUvruf3LfXGViEWu+N3h+c7mGJZnElhOcuN9mCZyFn7vwh nWafJRpuWO6K8eQV3cHm32y0wf//jp49SX3hvbXtxpa29l9rd3Xdf0K6+457 /OtSfFw6/R130zYN3esaem4ot+XGtM6/p22pVLu+dExvb8q+fEHlerhjaBM9 NZSoruO+pcZZ193blY3fQVv7UuVLVFdXOj7o3tGVLw66N3flrjXdU0OJ6jo+ OP03GsJ+qCoSvc2PB2rzCf374i+uJ2c0N/EsfWOcohcqsyGHoTv5vpaH3ZPU DvfVxvT36aaZ3/eSWtj6ikgALkOlVL6IL6i7XrSxfHbwp83VrQ7TJ5FdVgHj I6R6U/sPNw7ZD3/V2dC2IVj4a3JJTdmS8/s3HjVrVbqaigRgjSJ79rc7VdBI K7P9O/+z/zR3vf17jypUn9Lbf9gdksaXjor/uCN8s8Yq+fs/8VP/6vFNtcSM /5kqVVq3evsv/k7b1EpRTXShaF38ZMTnt/uuwBoa2MqfJT8aio99LmtdU6u/ 9GletiVe4b9Q5vcBUVO/2h16rPWf//wdX30vPrTx6XYkRORfbD/1Hz8hWt1s /4tvlTe8FuVrj9FttO7KH+V3FK51BJEGXRtZ9B+29x+u4K9qRFnsxMi0ptkQ re1l0c4+0HD38RtEyX+WvuI02dD8s675NLHdRmn/sfp23Gc5Fm+Rp2PJwlnZ w2suHnsbqE3ZfWJ1GBb/OXsf3Wv6IyaGO6/Cz/FV2idJevnWJIGno0GPT73a qZYEv09vDbUezapSfU55WZCu+BkI8y6aJyp9w8WLTvBbVdfUQZ7qWOtTvvXZ mihc8Y+J2W8avWnq5uFnv3HhJLRnPM8/dZzHdS5wvCiG9gYOzTM0NHLwz/ix Iy6+hvpHc6IJd2ptefii7HzPE/ZMXAsP7PF+2NbPWNNfRZE75w5e7SrCGuKi UlGeITEUk7+AE6n5JyPi9CPMv6MWN/Ez0X5UTedKx2n3pJsIqDE+zVq3ZAqM 2m+EBdbxHWLqbiBWxDESkjWag3jnczSHon7ZMJ5PCQtgDp9zMXRXj14gJFe8 Kzmhzpab1tSPMKEqrlx+zxP6hif0+bQ4VoiFARRDdIJn9mk3nn6tn0bOuKLU 9fiG91m9xNQnsORtX0FtaqvdeLwDaHzARv1a2BYiMjX9s7eZmVi034QbHLBi 9fY/5BAIkvN/cKrTC2VuZHN0cmVhbQplbmRvYmoKMjkgMCBvYmoKNjk2Mgpl bmRvYmoKMzMgMCBvYmoKPDwvTGVuZ3RoIDM0IDAgUi9GaWx0ZXIgL0ZsYXRl RGVjb2RlPj4Kc3RyZWFtCnic1V3bjtw2En2fr2jsS7oBDyNSvOl1k2yQAN51 7FnsQ7wIxnPzZO2xMx478d+HaomsonR0YbttZBMgVtiSSFbVqTvl3zaVkGpT tf/Gi4vXJ18/dZubdyf74c3T7/uL+5uT3068qNt/9gP8+uL15u9n4UEpN7IS qmn85uz6pBLhovLN/pbwi6qF3TgVhu3m7PXJz9vTnRXSuKrZbnan0gvtvN4+ 2TlR28Zt73enRhhpvN/e7k5VuFPaensX7hRN7ZrtAw1e7WS4rCodHgKvPE8/ s2fYZZhJOiG9b/hML9JM73eNcLWpPJ7z3a4WrpFOtXNa4Sujs9e/TC8631VC K6ed47+zp87ZRtLuaSZ254+7Uye8l8ps36T3v0gLZXeetXdaawNNrmj+17tT LQJzTL19m556Fd5UC6+0xTRjz2eLRrt6CG81StY6krep6mXy/vfsxxPZNEIp GYTm7DJICZu0o3QtTZheC2+d0dvn245Srt7+LbxShUeN3/6R3vlHmqcfk00v eMa67eV+x1bmxLlOr2R7e8/JxKQoUizMXgljlM+Iw0aX1tTu/VQ5K6xu4uZl ulOlK7czVdXeHABXb6xoqqpFVAKc6wFnZSBWYxjkwsLOfl3Ead0EwdgEDLV/ 7IH6bieN0Fa3RIireAuuSBKZ+GL5uUy39hTSqjHbR0Q4LGAEf3oByQJ/FaZ2 d+U80z0M/YS08zAohdLGsIk+pldiXkM1taQTMkzFjTDMss0TZF4hPTS1EqYT okZ81qK/rmrl2PMXEMfsVW/Sq+72whrQLZz1UVbT++utTncKWpRKsv58lwD4 iB7adAioKytcZecQ4EsRkGR5HQL2lirYIKFmDBUXtrdALCOPasWeJ4R8SCRi EsBgg83f5VBuKi7KZIk+FadRJjKY7pVrUIoRpbWLPHOuXcus1moKeZbIX8Iy H9SUXskzJu5Ej9fB+zC+1ppRCyoIIjVdZVCJT98xDZ/e88UV6gpW1emqKmVV InsJr1wtzJwjyLfxK6JsVIeZNv9f+hmBDqu4KzgaefQlGNe7IJ/MOVnKucSE Es6Fp60/OucYeqBzmnnEA5eww2FkzQQOE5n7Zxrdcja+s4Sz/XtWsDYu/iBu qlJuJsaUcFM34vjMZByEOoqxKEYaEnODe0rJJ5tCLOTrkk3suVkEWeYIxpBj PV/rUr5GFpWwtfaiWmsKIciWg+6h22IlF4FL/lIQX3MHiEW9+zsbiRUDLYTY +jAWJc0d5FdzS243ephnQ+zUpexMrCnhpwrkWGsuoWvzCjnykOAYMvGRZSMX I+IJN5KZuBjvrA32XAnMTClfEolL+CK1UPP6MygtKb2bMGDXcBTfSwRhHL5C +vM9Ys0tikiI2ReJXTA6DSo96GRnlQH2t1TnTgiQq9d6tyH0tgWyYEtlIbG1 RBYqJQyLWdYsrDSZM5xjaWGVb1O7pqmE7a1Bn1twRmZ8ZlmEKLqkoaFifb8D lhkmQ4nP1/P5Way24Zsmkikgf0pplSeU9sCwWMwus5eCNVGC5lcoxRcoqZoR YjGT2qOkJE/NsLp3qqzkcz7f9knX8P9NElWYQGJKB4oBdO+IpDcoO80yaZdA L7ApaZ7MuYwUHbNur+YiwSili5QOhf2ABfv3dMlZG36Ufg7PpakpQmYRnp0P mjgmZ4+V9JnxbwONnu8QpLChYhxiBJ3KSs7mT7kSQuYxiySApcSFlt/b391+ X7ccaUyngAWSwEBUvWV6iGF+oebzwP2y9VljoK8vmB7d52cr164WYHoONrlK ot3NS1enELR3Pp8HWHC2twLIR4BCd4hUJFv6dUoyY8gjEeUvUqbqUd8IXZs5 1JcmNwm/Rai3roN8rHkR6qyzvOSRuYfp8u0CKJgrCpUFu/UOifrvOyWFVTIr NRxWz2VIBw7DJQgd31FB9GJJUfSEaNMLU5WOQfo21wNTdppVlKPoTRjq+U3j qVD1k2ukDvJKuCpB/gZZZHrPlJMTy7UogIN+257inWMFY09a5iE+wpSGHOuo Rb07mRqMLyXQ6yDKoAql01VpmryHbxHijWn/2IPepokFbb0e1tRapIhRFiMs oZG+nttNaeqYlla0IV2HOIGFSCtWVpoGHc6xcmW1DHqqI/UPpDWukdOzXMhN sot9ZmwiJ+zZOM5gtus23TlOhK7oSBmphcFDPF1DWnedf+7l1Ob6OTVrxFjy z7GxTovvsiyqykIbehP3zICeg80uRNk3vWpthPWpLeVuXiNOdhrNB3Cz4SfM l613D4eW2E143HOGuGVVJpJRJJZDX+wGJ33rpDANSJWQHihNmxOii/SADGzu 1MDj3WkjvPRho/8OG210K9LP9mmwxlm1PQv8qAIdBvHQXLEYhWO4pwV7ALEq wtjKeJhlV9YLyLj77Ah9cpQEVmHzLnfNeUvcrIvxAqw4UyrAXSD/Zk3IMqOP +Yq6fpfA+DrZqj6G1NKWxJDr2QEj34n829D0tAWpYdatx24k7fqFHE9xENqD r27kHNpLqyoJt0VgDxGy6/2rkjQe12VR0L/aSStMVpqaNKSHJLqA0I8zXQOX BYZxy8kuKuEBCWOvP0eLfgWxgDvmjtk6Cgwmaz7bcNsZIfBDEk3ocN2mkKrW KaTiUVi68+kuBL46TL/9jjr3vkmD/yJN8TgM+kAHw67CM0F467qR23/Snd+m aJr9/m2yQ0W9xrS59S4sj4SUBekPwmpppY1gVwJW3Rjh+yLGBWU9itxqlPbA 2pVpd3YDtYBClK/NxbJG648LCYZPNwiR5WO90HoSOL9zoLpaSNIt5OUHTQhD vx84J0yrPOpNdEC0SyYaJglgvQdnzA6y2+Mq0yqDmR9hGDnaRzFOzmb6i8yx F1Uza45LC6gE1iKIe52azo9qMaEMRjO3bDDnos9jWEwQw/PtM0GAiPiI4oYX WBuk30kk2KLW+8mM/NiKL6TavkbtKCv6MzuUuzYCi/JKWQSY2oRVG7Zm1tjw 1U55EVBhqC99uq8e0JwZDZhjYfuDwQEmKsxvFp0rIKCHgLaZteWlDQkE2SKg OxWb60cVxL1Vf0Bmjd0KCxCXJcn6gY9ZevoLdKCWHFn5NKM+TgS4/OzYOAcx rvMMcm3A6jAD8hKUXJh1fc8QHm+8paf5yRFAA/r5une5g0whI05cW8h1YYMR bxzZC2sn+qwyj5E5UjEqKXFaIjGyNoxDfPj1ITz58KYNG+ZwX9q4kBBcBHtb ibrHfe8mKWMnIDiOc1c042ANCqUO2uIHZJYW08+LdhE3NkHfn/QJlEgycezn LNBFl/+IKZwFxLOdojw8VCfQ58m6clEHCCMDAaJ34isrAtAI/xF4cO+H2sSp 9XeeO001ribn7jysqo+cH11Ndb1MpOlWxx2EcS9MM1tJK21TILgWgVz7dArr q8C7pjJJsLzPjklhd73LjNR+/dmB/YnJNkeig+tGqOJln9ShmPJ0ZQV91Edw UEWf8N0tNDg70N6wNf3B5Qbk/aF642ApOOI59tTjO2uXn+uMC5HosGeTCtOZ bpqvRpt0VVpbJ5krktTaZgdm1qystE4+nGPlypSOp3L+msXogkwXnGf24wl5 +gu1Ix+W/opOxpsIPOxDrE/1fHL36poUxbA83pnIYDEpz7Wyk3WUh4+kZQnq iVL5+HsIRZ1TX6ZAvgCKxc9vwCYpbmGDE4XSZKQdSntVEs6LlEPYb9N70XdA 7PDmPmufMMw7Qff28H6FUefgfFxOnYP4qxJdf4dyllso7FPDxotMWEBjPa1v iTN5Lmrsf9ObbhCmMorGipWi3jWoDdco0/RhlFxZD2pf3H/d80lr83nqzEv8 jg+V5M3JMwKReue9atNkHOaFMalBMo3UQWnLCiG7SB9UMp0N/L/Mmn8W1dTd 6jw7gfcFW3hLerUAPLMaEltIlMwSMHQZcxUiuaQSjnVkqWZV7KxFKi6+a5Gy fvkYRdn0h6S+dYj/9BxaS1tOCHclaK19k06M4g5F1L1+UI1lOSFN5mT+QM9y On7JMM1q/hSTHxChsC7+MM60yux3dYaNpjGhm38abFZ7guxgkUOPcsix0ZQE daUabd855wtmNy51yI0dF0Yh6Hmzj5hQXREmI3CGA8oXdDfg+QKYghy3wbdN prUBaXDDrsp0AKF5lQ5wTijXPtYeDWaJh1qKSqLkHa2stAI/mGLtwqzJzzCv WFlpyXA4x9dPa7tmaUb3ff0/b38J+so6H/D+S8vlpgmB1CcNBnepH6zUFx+s jTr6O20Q+26w0WY80WcerOwXnb0Vvrot4qskqMd8vU3inUHotNZWOD2LjdKy Ggl5GTa0il3rfwlo7ENATLNlfVJapkibLyNZTV+ifZw2fUuUuEiDL2nwPA1e 0eCrNLghSjxL5PmdBq/S4BUNPqTBRzS4SYPP0ON3NHibBt+Q0N6nQbakJ2nw Hj1+h5Z0S+rkLqHjhibapMFnNPgxDb6jwYc0eEWDr9Pghga/S4N3pE5u0uAt 3XmH3nmVBu9p8BGa6Eka/E836MI2v0fqhD30TXroJQ2eo9XdL4JhSoHQYb/S SgiJdRkaZDNXzp+GLa20tDKyMOXUQiuX9RutWVlpVnY4x8qlKR+CqMKllWaI hnOsXZqrs9Oaa5ZWGg4P51i7NCuTW0fBW3dls3gyfiB2eemlXjytoWzpukln Rs/QZ3WWjleyqjjrfaPuLnqIxUo3KNhhL4UFDzg9bBGdOl41aKTWbXImFdVh eoH36O0DRdngU15ZKpGCYXCY7QMiLYvuefAYlxlr/77GEeViamT0heJlASwN 1kiSygSwdtHtu2RcD8Sugi3LztXnnN7L2T3K4A7D74HIwPB7oaN96RsjuGLU J+6+Ozv56aTbdf+XEch1fxlBM5eKs57T7nG7ACMrrfYf/h4JGEtFsdwm5SbP OSXiz+2u+4OivJKqtU7bkroKq2ls2w8rWydr49r/Vs3m/urk+vh/BYNSuv3Y ENt5lqYGn6EiDQCbVycKpsO8i3Q+qEZQOCXAlOYQ0h7K8KJMOu83OFq6B0ye c8y+Y7j//QOCEaTM0ld90MFWxgL+KR+U+4Q6S4yZWaKzSkNVImbHg71I/3Ty J5x3pDllbmRzdHJlYW0KZW5kb2JqCjM0IDAgb2JqCjM4MTQKZW5kb2JqCjQg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1Jv dGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG IC9UZXh0XQovRXh0R1N0YXRlIDE2IDAgUgovRm9udCAxNyAwIFIKPj4KL0Nv bnRlbnRzIDUgMCBSCj4+CmVuZG9iagoxOCAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUg MjUgMCBSCi9Gb250IDI2IDAgUgo+PgovQ29udGVudHMgMTkgMCBSCj4+CmVu ZG9iagoyNyAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIg NzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9j U2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMzAgMCBSCi9Gb250IDMxIDAg Ugo+PgovQ29udGVudHMgMjggMCBSCj4+CmVuZG9iagozMiAwIG9iago8PC9U eXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFy ZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9F eHRHU3RhdGUgMzcgMCBSCi9Gb250IDM4IDAgUgo+PgovQ29udGVudHMgMzMg MCBSCj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvS2lkcyBb CjQgMCBSCjE4IDAgUgoyNyAwIFIKMzIgMCBSCl0gL0NvdW50IDQKL1JvdGF0 ZSAwPj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMg MyAwIFIKPj4KZW5kb2JqCjcgMCBvYmoKPDwvVHlwZS9FeHRHU3RhdGUKL09Q TSAxPj5lbmRvYmoKMTYgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTcg MCBvYmoKPDwvUjExCjExIDAgUi9SMTMKMTMgMCBSL1IxNQoxNSAwIFIvUjkK OSAwIFI+PgplbmRvYmoKMjUgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoK MjYgMCBvYmoKPDwvUjI0CjI0IDAgUi9SMTEKMTEgMCBSL1IxMwoxMyAwIFIv UjIyCjIyIDAgUj4+CmVuZG9iagozMCAwIG9iago8PC9SNwo3IDAgUj4+CmVu ZG9iagozMSAwIG9iago8PC9SMjQKMjQgMCBSL1IxMQoxMSAwIFIvUjEzCjEz IDAgUj4+CmVuZG9iagozNyAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoz OCAwIG9iago8PC9SMTEKMTEgMCBSL1IxMwoxMyAwIFIvUjM2CjM2IDAgUi9S OQo5IDAgUj4+CmVuZG9iagozOSAwIG9iago8PC9MZW5ndGgxIDEzMTA4L0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDAgMCBSPj5zdHJlYW0KeJztW3t8 VNWd/51777xnMu/JZCaTe+eR5yTMZCaviYG5MJnwhhACTsDIBBIIUCQSUKS4 sFYBQyy01rpWbZW6fnZdKzeTFhN8odiH3bU+WnXryuq21lYlylZkWyGT/d07 NxHow667/Xz2j5wzv3O+5/07v9/v/M65+QAQADDAXqChdenyUASkUB3AZOW6 LV19uXLoAQBy9brrtnOPaY/0YMUbAAyzvm/Dlmee//V8xG8BKG/a8IUb1uf6 W76Gk/p6e7q6X377uB0gcgEr63qxwrg1TwOg68ZyoHfL9p3yertx/vQXtq7r ypXZEQDje1u6dvbp71Kz2P8AVnLXdG3pkfszYqe+rf3bc+XIG2J737aevmMf Otux/z8gP+8pi5Q2xRnFS8w+Zh39KJgAJn4xcSq7M9ud7aDvBieuuZKkySZy HbkJ5ECuJhsk8ADpIpvJ9XBxWATfg6fgdfgl/OdU3QRhiIkUIPoVscKN0uif wr/Dm3AWzhMFMRMX8cNnhW/AIzJ6lYxQKglpYZD6FvyQZLH1G5CABHLzHrWb voUW2/fBjVCD8XME2kAdIldR18N95H4qQaWoU9RDF7cTNSzCvW8jX/3DscRB WBIijaSFtJG1ZIB8SEXJbHgXPoJxlISVsHAcreNtOE0ooiY2soDcSi2mzpMs 2aQcUJiZ314y20YyD3dyFeknvaQXziFeLkkD7QeuAT24gJ1aNwhPo66qiZ5e S2XoRfQu+rcKLZ0BULwELqWJOkuth6OwB27H2AEdpArS8CX4W3ge5X+GXIBy SY73Yo/NGN9k1jE30D8kGVgPK2E95j+FVeQwrINbcX+LSQH1z2CDYepXcD/8 nFxFz4bb6RvIM7hDI9mK/HwNR70Bw3CIeenz6GA6/F8G5nVVoeo0fAcOID1E HmWOKV6B9+FB+DnPt89rbLqiMdZQX1dbE41Uh0MzqiqDFeVlpSXFAb/Py7FF nkK3q8CZ77DbrBazyZhn0Ou0GrVKqWBoikAlEZyJ1FCBKuj2er0dVXLZdWlZ oItNv/UKYLmkk/uyQYWXlT2XlYumyksEsAkt/kSzOPEQtLwjgFUgNgHEVYh1 Ma4kD0p2b/InNwoFie50Gkc0+02c0HImJLMizT2k0yb8iR5tVSUMaXUIdYiw b98QaZlFJEC1JBuHKFAbqioFS1CgipMibRL4g2kE/macCVusn7aMTJwYvLgJ cNgksuYQEZQJQSWty20U+C4BDnJDlScGBkdMsDYd1Hf7u7uuQsl1IY9DQBcn e9tFOSZFSvdyAoOTS4kba7hkLzfgF8WR7E1j6m/GUX+0Hqs1idR+7wm3YME8 KZiDwlzsMXfX2256IOncyInFgYH9nHDfstTFrV4x7ejocCLDA0k/ToiTJTfN wa04Q1WVuT3JAuhObxLX3NQl8pncxA0c7JF4HZR4kLome1ExXZ/Va2Ag2e1P dnd1z8nNnhD4dimD9lUpaYMouuYOuUrugC2M1JJu7vDmhL2wLZUQGfN3Nbtz ap+qScs1WJGcbOREDubjBAK3jhOgLeXHrg1i0tMAA+saJOPxohetXNj66ShB UWzycwMfg0DS/rHTl9Z0yTXKYtPHIMIWf0t6YKDFz7UMpAe6Rib2rvVzJv/A 0MKFA33JNK7amsJRIxPHD7qFlsEOwZTuJY0oe9ECWtpScbfX3DFZbJ0sApoU GpZO2g5KAX/z5QylDO0pL4eCWpHqcKOcUiJuR5zLRUNCw21AHctiE2XU0zAl noQMvV7ROg+O8LAWC8LeZalcmYO17gzwoSDqIy22nJhssa8QW/ZOtkwNT/tx le+C+MyyC+qSqZ/R5LAmexsF4vgzzT25dsGaSNFuqiOHKDctIm0QT3qTkB9E XBYcQCW86BdMQUGROuFu6uBMZvQAovaW+xcuW5XikgNTVpCrkXcq2gGaur+r d0A+SqLR//HahcsnBS5aLB7pgyjxvWs3odHgr2tQdD/eAZPQcs7r9g6Y/RYu FurIWbXpRf9zBB0XujWTQJqkbRHJp+FK8wU6vwEbP/cKl24J/dicIT85sGyI JweWr0qN4suPO9CeylCESqTndAwFsC01ygHwUi01VSuWOLEEC8XTk6HUUpN7 lAfYK7UyUoVUXjdCQKpTT9YRWDdC5epMUh2GKtQsaldNsh34Ju79ZPMnyw1S zSUhJdaozsIgvlJ7QA0U5jyswJstMDGBb3NqqH3N7Hy8jbAbGcfUhCmPdBiJ hjj5GNZIdA5eRGImTpBgRm+oG0VQmSkul4HNmwPDGlMdP0LKMi6XVFE2bDCI FcXDLS1SnmE5qaE44y6Ugd0hA6NZBlq9BHyZ0lIZFBXlwLBWK07jG9brxdw7 nF8g5nQmP1/qQGcKxIWfIfZMESsDrU0C1gyOHZ14mjgyy1fIYMlSGSSTMkgk ZFBengPDgRJxBUemoEBawZFxOGRgNstAk5NHQaa6OgeGKyvFQQUZ1iu3eIpk IDNqGcZpsIsl48zNa8ksWSKD5FwZFJfIQF7JMil5NqPTycAwWSP3YTNWqwxk RllJjKSUkEyExSWVGYtFaqAyZTn9keHScpEZahi5w5xMchnIOJ0yMJrqniB5 RAFmYFEuimGDpGlmGNcV84xGK/VkJgXFZJpmymDBghwYvrJD7BvKaHSScNUZ jUsCmgyfkIE0SAQzwjIorZCBLyAD1+Qom10CtkwgIIOS0hwY1lvrjLPzSBRN OIrmG0VjZokZCH5TGfHrhiXGDNPKimwBz+qcdRPvsux777vY8PvkXZuL/fC0 if0ACc7x5yi8YHjnOZ2+7hxxsWOndazpzKEzFH+67/RTp2l0+8OfmGx1mPON v7fY6n79jot9p9bF8q8jw/F/JS+9Fmdffc3F7n2FvIJZ+rW+16gfP1fB/vi5 WMOPie5HzT+ihDcIDj/2Bp6evpdFyN/ystZaFxhsH9w+ePPgA4PC4LODKv4k qR81sxuRnkZ6CulJpCeQHkd6bKWZPT7qZr+H+Nioi30UaQRpFHlpipvZmUiz kJqREkhz4nZ2NhKPOF5rZiNRGxuttbG1NTa2BvP7aiVOvLU61PS1jY11b15L +Gs11rpDfUIf9eZWwm/F3b54jdTLcY3I+/rD64X1NL9BY6z7Vg8RuqWmK7pF p3Af4e4Q7qDiXyVrDu05RHG3nbiN4jbzmynoJdKvtTfdS+/pIuHV/Oo9q/eu ZhruMbPi+I/u0eP47xN+mAyhZgSbnT1qM7OPIH0H6WGbjv0nWx77EFKwwsz2 VZDKqjy2ymZgv8klWNZWxOLFzXK2Jva7rgD7LVcP63ZF2D2uQy7KZfOxP7TO Y+22EGu1cWzYwltaLYctTJ9lr+VFC22xOVkzEthIqy1t67PR4TwCSvxSw1+I xMlWsoccJU+RF8iHZIJojYDGFYI4bMWPwaP4Sf8CfAgToNVq6lkjZaSpF6gX 6AlqgmbEGo26gmUUFSxFl7B6Q0zBxGgqRiDWqiAjOJtgWQgL2+cIVoL58jlD mkhwodDdNueW227zCF8X3yh7PR0jauyDjx2BfLlDUIu3nAQhKIf+7fjr3y7Q SUGZ7O0SlP7mfrGQJxbyxEJeUjCKBaO/mQi2ZK9gw9rtweD2HeL4HcGpmT5F /SL147xSEMv92HGHmMBF/f4w9PcTbO8HaYaglBCxXqoIThKu/ecm+RxB5DWI tyElXo8qUAJ6AxV4eKOSYgApjHdiK9aFOp8/9TyEMKkOe81eczEmqG/4ZK8C zos5IMBL8iTen3fjl6ARWvig4phSqafz6BGi/hDbFIQlHIQIDfo8jnB0K00Z zayZommzyWyJhTo7o2OxSGcoGuqE+HgkHg2N4WLiat7aSF19XV09IubuC2Wk MfuD5IHycC1DWkiUMLT1I7THZU3nQ7jKncjBKcUHwMGXeYff0Oien7fA3apq z1vpXO3ZyOxya20jE+/idVxvHJk4wpfkmerBkuc2WTzukHuD+3q3ymLRHXdQ IXy6sKNEnWb7WEo6bvk6U72lDznn1F7WQhUU+Iw+1kdRop/D6ahQsNMcDVli sTHcARYgPhbrjIuF6nAw2On11taJu6itKfH7lCqlUuU31wWiHGO3SSUvc+r8 8YOn2res3b011lMTnWfxxIl+N9EQ8+7Dqx4qoa7/6JpnU/2PXNW7tdCRH9aT ZFH89Ks3j3+l46AH971h4j+YEcUZSMBR3l1pCARLZkaaEk2pK9pm9zSsm9Pf oK2swb3qRyZeHcY8gkLgl2oM9ep85H3WTPdIupAUFtYol4ZJOFx+vIbitUSr NR5XakM89te1YOL3rmgkje5Q2OYNu2c2MhrARxMFkDQm2SSl04iS0JrqNaFg VBRFpyU/NobqDHWOoSVLkpASSdnjsZgoFhQMkfbv95WUmqMORzQiC6m0pMTv N19SvEhsEUe+wyFKzu4QETOybMnSV+565PdLAm2nVtftCfrKG8PhfVH+iuZt ZWVVFWwg7avfVldxlYNdTBQHbjmZXLTo9p21PeGqK8jJLd+NxxONAZKoWWTl CuYn5sw1mRmi1FuszY1VMZNF77KZogYS986cURn6yuo9TxXmqUuCpV/ErVdN XGA+ULwEWjDAdXyd3mCoV6psyKReqdIYRkmcWcqsYfYwGGgVTYdUcdVq1WbV F1UKUOkNtJLhQCPdBRaNvh59p9GI7tCg5M2OeqUsxWA0OmbOR4lBKC4KLjoe Mcdi+xUzgsyNpmerw8QvnhAz8ZqjmDIfPJe9c/xa6ktkx3PjP8nuJ6uz95M1 xEGnL3ydnM8q0FJ2oqU8hjzPgBv4xVp1pTHCRGzNTLOtM29FldrQjopWF6BR eL2e0fJyZfGoj5ZswYy24C9mfbwur96X7/X7JPVz6B0gbAyzYUojnwRN7iR0 ikchFBwLTaoeuR+PhKTDIOu8JKfz/MvU7hOVjJuy19XlFM08tnTpktfuffDD Jb7ClljtlkTjvvIiX9AfPVzTdneMo18f31+0PH/zsZYVV5Pfbf/BvLlLSL2P JE1lDrvbU1K0YFbNwnyf1WWkm7O//h1FB6vqR9HnwVqUxM8UY+CDRvgi36TX 5xV49GxBhS6kryxYpdum2lajddGVI+AxeSiPhzZarfmjHUZipBoeraNbaIrW rgRisZR4QdShUWOsB2gyNrFNlCvilcShs4jiGI9ImhyTXFvnWLwT5SCdApRJ dRilAV40/xKqtsZSnzNusz8nh0kJkIuFY1PabbLQmJ9lX81euOlf5q5Y1b5m NSl5bv7tbrdr5+KjTzrm37mm9bb6xauzSzxswOttD5UuD1BVPleiuKiFnH8/ +9LC+SuJ6YlnSXjH1hutyuy/GbwjD4caguVXnMjeGlixct7VhYV2m1E7w7/3 njKusEj07zvQuz6OtqOEbt5H46PxmxRtoyj8XKJHFTSlpgl0A6FSoj/EG2Rk 4sww+hhJOnqNDqWjNqpZNcXIlsLkLCUYRFkERXuBeHzcjCIRzXv/jc8S4iWi 0398fF82Td013sjMZf7x/JXMiPjnf0q8bahiZp10Z5XxBeQkpVCeVKhNGk5D qUBQAr5pOUIT6dCI/jiONwqRbhSzlyrOfpOsFYl6ndx6/l5yK+4vMfFLhR1v jyo4wnsZrbbCpnVXzHRWFy528oUpx5VFNzDbdbvLDf5ePCXmkYmbRV+KN8Ax XoP7ZBZg4hE3W4kgn8ckZOBKKSnZaiAGg612l5IoqXQpKS3lanfgilpDWe78 G+vLykLGEB9aE6Jddnr9DNPZMUk4TaLJiAdISjs7c24TD5GCA7MJvJJ9SAYz 5SOnzEO8NaNmpVhHF2aHsteRg2Rpx5dnR3cWl7jbampubF62f2bD3AVNjYfm Ltg3I7Ko0Ff+hVjLLg+5A59wa8nf2yzGGmv2XmeC46qi8dgzNx98orEhUl3E 8gXZI9Zqs92Be3gwu5N2KW2ohWreqXiSIsonic6oIbQRWHz1oYNQPkwklaOT yx2D6MXqsCPRrvFBanv2MZLM7lTdc/qTJpx3f3YndX5yXuZJFaHleR+emlhx 0bxRnHfs03lrxYeDlzo/PohzPoZz7zytePa0aDc1E79gvsrsgyIohg28v9hQ Y5hNLWVmG5YH+qlddrWrQm+qL27S6cA3S8nc5yROcRHUtJjzBWjITqeZB01B AevSXltqLCXFOhfdV2I6h2aGaovmXB6qSHJ6yM2UsjC1ex1/qB1rTnXU97PP ZL9DmkghoQgzThQNM6p2zp15XXVwfn5xcO6s2A0euqt7fb+yiIRJAbGSedn3 suN/s2Qjy7rdDmulOfum2WM0mqm3tm7ftVE8sfvwxB5BGTogxgcom9VWo01q ++wKk0HdbGXyCDGoiQu2OtNOYtK5DNfk5zZxbgziTfF4zj/hI2zK90iHR/JK duZI9j6d0dIcC6Yi2SPk6pXfXvfwMaqqeT9X4uX8F95W2sZ/Or/t5z/JcaEK MDdBENbyISWnLLVz9lJGZW12ewOgVziLmAKFUx10QZc3X+fSu/Ndzq69ekH/ op7WizI34VHS66sqTVWhKr4qXcVIj4hg59nxiGnMHDuL3Mbj+NwYj4jsXsLt JZzLN8qkV7WbFc8qjcZ4rGzJjOx9KkQNwbZSaS9/t2bDPeU9w1ct2R0Mhajq 5dsCAa+fu/A2Vd3Wj7DMfeFtZt3u+W1ru67uiUTq7tg5Xjwpbdznn5C24vNI 2/6XSVviBoUt2fcp5nG0bx34oZi3W3gNU8TTWr0bri2OFxOnW9kXwDVFU508 LTnTlFJS88cdCfN49qXs+9mx7AukGi3PRsLZu7wedkkktIgrCvjche3Riitd LEdVY6+n8RvQTpxkZvbp7G+6bymr8HrKSw9s2LCnpDQQCARvQFnZJ96jFyge ADekeLtOtHi12sDEtSqF02mLg8apEzXP4TWh03ninqUeSqk1uFRGJavkaFoJ tIk+SuObCn0JuvdQ7q0kfjmE4liO4kOjU+ErqTX7a6PmnJOZ2kzUrlRSNa+e 3LePXE2WZY9Sxry5zYWrLUWxvQ7hR5ThLJmdfepsdtsVKb+/3Kn9L6NZ+puh /y+M3fAWuZt8TO2irfQqKX7p8sgU/Q/jAozXXRZPi1ERmorfVryjjE3Fr0zH 6Tgdp+N0nI7TcTpOx+k4HafjdJyO0/FPR+lbn5L/xZBN/CsjAHEhKRGUtLXO W3YlPWuhjffYHfnOAtdf4V/X/j8ODDRLKSPK54xlYgJTIqZYFv+PQAm0QSvM g2VwJUpuFixECfLgATs4IB+cUAA5gRGwoIwpREowALS3J6sTDcmaaHh7OCz9 ay1yGBR/MVfqS4tn4MzEJRVkshuZIioF/2tSOOEk0p1IG5CqkHYirUXaMUnU b+DkZ5HiSkj8NYk+Ag/KtP/PEXMCaiZJwcK+y0l1fy5nzmCfy4hejjqmP0NP oh7okvVDwtHja4xNH4M7p7hHXn5L+n8pT2zfsPqTzdmUAdT7sK9Gsg8M/w3v NcTuCmVuZHN0cmVhbQplbmRvYmoKNDAgMCBvYmoKNTU4OQplbmRvYmoKNDEg MCBvYmoKPDwvU3VidHlwZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl bmd0aCA0MiAwIFI+PnN0cmVhbQp4nHV5CVwT1/7vxJiZqVXbkk5J0Ca0tXVX tFqh1n1XtIDIKiIqOyHsJCErELYDAcIWAoR933dB3MWtLq271ha9tbtd6O2/ Z+jhvv87wXdv33v3/j8ftmFmzsz5/b7nu5xwiOnTCA6HM9M9VBIYu9RNKgmI tB4vYedw2LnT2De521Dkn44TW3lvEs4V3FlgJhfMnF419y2hDdv4GjvzFXjy VYLL4XR/8sUWaZQ8JjQ4JM5+wQE3z4WLFy/56z8rnJyc7I/I/3nGfmtgbGhw pP17+I+EwAhplCQwMm6t/RZ8dURE6FH74Ah5VEisfcCxY4HHrLd5BEQEhttv D40IjYqSJtgv2LLQfqWDw4ql+MfKtfb74iWBMdIl9qGRQaGRoXFy+4DIY/Yf SwKDA+wlAccCrQNslYTGxcjtVzmERv7r7n2hkiPxsfZTU7bfJ3Wyd7Z3CwyO jwiI+fczBEHsdd4kjzy6d7NCesx735aowI+3Rge5bIsJdt0eG+K2Iy50/874 MPddCeEHdidGBHjskUmOeC5YuNh+ydK3l72z3GHFyvXvb1i1cbXvB2v8HJ0+ nE8QS4m3CR/iY2IrsYx4h/AlXIhtxIfEcmIe4UpsJxyIdwk3YgexgniP2E/s JFYS8wl3YhfxPrGAOEDsJlYRCwkPYg+xmlhEeBLOxAfEYsKL2EtsJtYQSwhv Yh+xhXAkXiJmEDMJDjGLmE1wiVeI6cSrxGuEDcEnxMTrhD3BEG8RbxAfEbaE gFhPCAk7Yg4RQuzDiMCX+hAnOGs57dN402K4Aq4vt3H6vOkmHsXTkgTpT35O HaA+pRfR1S85vJQ7Q/Iy5+WomS/N1MyaMaty1m+zt81+9orPK5dedXhV9erx 12xf67AR2QTZ/Mlfw7//+vLXTzE7GfYN9zfGbO1tA2zTbDNth22vCmiBvcAg qBeSQmdhjfC03Q6703a/zxmeu3LuwbmfzIVv2r9ZK+KLdoqCoGE2C4FF1sP+ arH5edyWH8V+BjczikBVnFIRcsxd7gjoneRmdX6HmJVQ4FZp6aM82oI6ZNRd vUkFttGTLhS/C2xTKTen0TIK395BnoCbebMngoAFevexb1VyJjwszCGDrijk LsphrwkSSXRsUrMHvadJ8s0UyqCPhfJNNDWWGErzTOIh+BIPmsm+xSVRxmig EoIYRYpHFi2DBdSkGhYxkIKNkEaNvNlsBoocZ0+YOayU9WDQHCXZWpaclJ6l z0gVL0JNiIL5+tJ0EygWggqzcSCHNqMjKqo+vVxboIAkyhIYUsySRu+yYKAU AmWcs0Kiio6XqYAeJOfo8mRGRa4C0HGJibFhrTH9N06ch/POiuEydomptbio 1iDEzwdm1u4c5/MxuHWMW8a+zeQbirKLAd1YqPQRo2wKuGlVXum0EoaYKa9c ZQnopGE7deJ4dUkboEdqI3aJUSAFnNUKb+tFx8yUT56mBIzQUE59739+k1+E Ys8O0SMqNcdHHqp1T8JPdNHdZnlNnLoHXPZt6MD4bguOdQO0w57PIfXbuVuP O03aoCJxfnyBtEJeBYT11Zaa89uG1/h4JQYfEXv7S3eAj2j0xqNlkHu8t6yl U9RQa2lovkjP/nMWsExMt3AgZ5CtGOdOfMB+xkx6U8BRo/4INxW2WajNeapS cItmXTAETKa7+RgCvhSKnsxBSWwOD/nIyC/STBqwmZ5cRIF5KpmjHt+nsVDr cxU14FeanU/B3MlhXik5e2I5RlsX7O+FJV0yiw3kjcO08Q8hZcvvKJ9YxMio sbQSLdhkxRXYpFY7ZlhRFQj/Rj4Et6q62jtbK4+DE2BQ3hvRJGmIKtlddtpU VVRbRfM76qrNXX12cPrKUbRJ5ISeMc/BUFqnkuYHXohtOOpsBw4kHDsaFy4/ krIL0D6qwlYx7JuOi83/oMpYaBYNkpC67LtynYf/UjEuNWhm7Zo57AdwDiPP 1Xnrk9QKoUoRmuwFaCQiYTW7kGdGv1AZaAavgiy8YzZfAjQUkcgyuZCnZGdR GB+6RnZlI6fpa1j6NRca2MMMesNhMRKhOd+9B22gzY//BUXQdvkP6HWxWsqM XVyM3kS8Qzs2Hguq7U0QS08nfYYr/sPwlVsi61inWbtGTsNTmDjGhc91DJx/ mldGybMyQQagg1OKh8TsJ1Rajq8iRLdHIUyiCrLzQQGguwp1R8TIgQpsjSo+ it+cWoZ46G30+r1VcNr57srhdvEeCnKmg9RUjU4rT4zRRQLa0f1z+Arkjdy9 f2bkoId4aiVPweMmxsZ+3CMklZGns8pTQCzQpWmSlegdlCBAC2CMtkxfPrXe Sgtbc3JBESjOxkBpk1EnMktVv6C3oC1yF6DNFFil0zmkY4RctFArc1Ql4D4N PSi4ACZc/qq++lSuED9TW6WzPtXGCsr3B235x1lWy7A1FLhU1GUxlRaV5nbn 4sE1Mqo7ozTdnFypKgwGe2n0NTXJsDIe2iAjB0BpSu9BenIvxZf9J1DOpfCo +zAsMShVg6xjFXTq5WB24U4QmFGSYQIvgdQnJGkSQTJQGpT5PmXeBQeBE3CM 2Ou+bW/gMoCmgWXNq0+5Xdr9beDPAPLAz0OXH9Pyik1bd0kcgdAZ7K883O0+ EvE1gFwa7voOvgTfvXA64WivqDXcLLXspq0kJilXVEDXVnb2JZt7YzD+qS1f Wci+yRRmG0EhoNuNuoPiyRCKPwI8tVoXPa2g+EqYVkFuzFYXg6s0XEF1hNXq +jH4ZnwLp8N34avbni3a7x9zwF/8gNLnHEgIUbsrhHDRRqb5fOfQ3ZENiEZc n41bDrp1NouslPIpjGyFVCeHXQIdGd8NhyP3ADdwuCnygrw7tS3zMg0vkynX dE0xrZJOvypP4A0OygNDDx6J2gqc8Eq4vRpSP9y7CIl+EXoIlzDFD9u7LoPL oFZqWkXjNqo62f/VyWmHJLseklz4jwlHBu1Hc9E85Le01eGsq3jU+dmxr/Db e8O50B76/Rz5xP2S2PnTNZ2LMa6nD4EheWf4WZ+WpQC9DFzU2xM9k2MUMXFx ISGH5B7ADxyqCGnxHAr7FVcYjDc+7x+mewZGqs8Begq2si72iZVl/j7OkpBj yy//O+QwYItGvWFKrCJgFwlp8HvblfPXLnY9A8/B15KH7ud2fIo4nehNQPPL UY2MfJRamIwJabyN4Ue0FBf0Pb2WFHpC9PBA32qACIBmHFnz4UGvSFfNKkAf 1WBWedFU6HaZtWmMrbSpfQqTxmz5j+Eku47hP2/wkxQem4NeW4ym4yLYXF/5 /ei5+hODYoT5br9cuTWNVkBtKeVeklIA+mn+Y/YHLbUZfcmA2HS1LiVeFqaJ ABEgqiixMrwp4Rq4TvOfwxln7j650hK2UzQbPsWiNL+V8xtmiStWWXwF0uSo paW7qlQXWSEqiy7RlQO6xlJR0+lf//Fejyi/aHG0f0pw1lraKfwLdIMEm7Wa LVY9MpkpJ4O2GNyj4Q04G9PZGazn1b3wpLWev4zDJGs9n8NDcJCpzyzPqgcP wdmigdpLrZ2XwXXQr+qOajo6uKpxKa7iY1QuI++mFOnAFnpyGwXWpOg2pL7Q lY8MylJwh2YTpuPKGI0NcM6Vg/MWuXgjKlGVnRMnemFOuuBA371KuLpb9sKj xLDfw3WMlPRGxOFY9A6go0gfEJCXakwzZBaDchoCuIz6ApjVJke6BirjyNQj 6UqtSq2QphzEJLgMxpB8RWN+foMIziHxsq1Wlq+g60j+QAZ8hzfZiF/2X97m L2ejYLvIqfrCX37i3B/jGlk7ptRQmF0C6LrCJH8xMlDAOzV1jwYXL9VM7TAo zOACDeOp1oGTDfmFabpiUZmqWG8CdK25vLEtoTI0IDJuq4/4W0zbHvHBaheZ cMrTXIBX62BYT16jTeNnkV/CbQ8aGmz5iA1jBUzPeioRM1GiMb5AEFUUlReN iwuXbdri4NwQeD1MLJPLFfq0sEh1IkgECSWavkSaj7Z6RoUF2Xk89P/h3sP6 /tOi7pbyVtANrhzs32RATL7AIyemEJSByraOhoLCLGOWAVgyTVn5oAv0mlsa 2hrNHeAkaEqrUbXSKHXSjmlL/Vw/Auhv2tTBrhuOId77rk2DNUZT/0kxH+bB 75iLjR1DLfUKSZmoIqTEDxyj90eG+H0ccO1HEV6RaFvFRO9fdDDhit5nEGlY O/jh7zdNneVDvXevd38zRZZ+aC6ch5niBVf4L2x2urhH1BPQmngrdthdcPMj OOswfB+YMUVijckn0dcTo8wAGJJ1RJz1bV0MEA8siHz3qF/QEc84d+AL/MuD Wz2Gw38B8CXwY9NPfUN9g8NVo5glpmB9+f9B1+9sLExiMGwozVq5ci0GzLsY MI15VrjM/b/h8vz/hwvGtqN2ilus2F6fiz3TbRpGwnepx6BcWfIhfpxQV51U xa6oVFfbnLoCnT7DnARvwhsMf0k6nIvjQGZmcmpWVjoQ6oEuR5uHKaggPj43 es5Hbl5b9rcefeIrHg3rSCyPBRFC/3CpV2iEqVomSqhLrlFfoJNIvjNyMFHG otycElyZ0swaPR5A39iQXjHnwSejn52Mbfu4U4yIT6RlyjrQIOxtaRy60By6 skb0ws3OOcu5Mwb3Ye5YAX9k+oeay3sAfbIueJsY+VBgh07tqn9hZw8U6QvA pzT0pX4POPuhS0Dsx34ieIFKM4RqYlL2JwmjUnhJVG62AeQBeqAg5bB4Mhyv JH2yawq+P8JMuebrSvD9U2aQ/c3KKOPjUG1llOMT8y1MoCGxKLIdHYH5ghum 5pK2htZ6Sz8YBgPqrugmmv+gL9Cxfukc/nHUJCPvpRRpwdYXtddpNlolvhnX Pk9tstbemzqfA5PRZR5cTU76sk8Z/oPG4oJe+Nro4aXeCQHBMpFfdIh+ceaU VPXCqxWQWwUX9XJaMULtn3MnvOEfDCqQkwMZJRklKebk/DhwmEYfUOH7orag NfMhCfd93/jN4IhocORKw01wHozIeoKbpWVRdfvoGjIFBvPiSb1MrkoAOpBk kBsPmf0KDmFEHcSeaT46vLBh43kX8Y3tPwbCaeApgK919HbQ0J8CF0tMo3n0 bNiCfd/MVs5nuCUFmM7fw2xelGXQi1KT9cmpukD3w75J6dpUfSpIAxnZmYZM +gw6S65pPnxxpLv2dJtIXZwQo9DFA2GQsuGqGPb8SuEhcaOvjnN+wENusXrS 5e48JbaLJTmm7EIgrJ2iMiUFtui02606oDNTu/JSiqzFhJQXTGCi4uKk0uq4 xqaa6qbGuJpIrHdn1FUJHezeKri4z+bWU6j61ZY/wu7HUp9ApsdptQo8eZym CoJKgwrCwWHgrwiLDImQBwBPsHZwP5zucjvw9JG6wEJ1XgKIpfnKnd5+m1c6 n4OzvUVxJH+kGYXwqslsS0mpGWB2T7ekdit7U3qxZ6CePfrtC/drSHBL/PZo wCA4S5/r775yvF8W3CFqCS+NLnPBy/RFEh0ZhF0Wzh/j8Pw4FwZCxGDDCW4X Fz8wYhPZIqMepBZr/ylPOs066xJusVAb8zGMbtHwCDyPPP/TGWsg+vdRkMeU /R9lmXJVqc2tMbh9zGpgY08yaaSfFnt1+CPFf4BWKsgrGSU64E0jDQWkaSqV Nio+QiMB9LHw9n4x/zh8hN5TUScySpXAj0Z51EcnvO509ZQ1NIgGBniOVG7m ycrO4lOlQtxU9uE4zm+4pwdYPybN4BIXqHaR4xyQl23OMWcXAWFNoQIvw1co sCEjRpuo16lSVEAJdEZFlbxGVZiEo65cER/eG3cWTrt4H74t9prY8J9ajeWY /amfA424jMYJgpnMoMAHWq2jtSzHLZRTrspk1fOCsxQkQbW8Bk2ja0k9XM+b vEzq0XpeLVkLOTUWOB1zLxbTF8GCwoNRVme2Ua1ZgwMfPIlHMiRNOQNc4Dul pjGr1z8po568CIe4uuwOnPyjrRZHjJN/hlkHZECXqUvXLUAlgndhob40oxQU 4ixSbOww4OzvpaS6M426oXlwJuoV5OgNqYaUfHl+Sj7IB0aTuQu+Du8Kmm7m G5sN9As2dCrlfIFlfoLL4JWBS0i3Fal9xZMJFPDMyNhilXm1mUrMPpqDLUyH EDpT0B59bEjPycjJMGQIC3QGPUijk5P1GpFMCSPNpL8hwhJwCi2FHoKmhlvX rww1FQjNuaU52JAVmNFhFdmTVZwOVCAlWaXS4Cw4W8A6Uuk5gZrIFNckoSTF uqeCY8qEhfP3cfiPQS4L2RIGjJeUfVGEi6OUUQ/1ZfFgPo1wSNqRGpgkifLd E7ERbAU+tVHD8tbULmtcuDOF18+teO2UUY/0GK+baXSNQpseO8H1kHOv42aP qLa/cAg8sKqVqpv9b9ygrbhBLexJBtwpLn5sDf+9MuqLF/dOHqUOaRKiVfqC ulSRriOpDJuSqPi4qIA+ySgkLt+Gr1kT5FS3buJuKan21KJUoABKfaw2agWK EayBcYohAIBJCKqLjcNG3Ct/JdWVXqKtPGCUGWX5cgfkK1gAS9OLMotAkRBU lRS05+KrdiqpmswCXbUXnIN+EJRIClT5WG8KTCX1OAelCr5B2tKgXH0+EBpB XmFZLw7bPwsq+g15lfgRL3iQ89MY14L7m08WZ5dk47jcWqTCaSuaAgdUauc0 3GGtmXLO1RSBczT7Pe6FpyJQt10xtRMzygpqbbq+2v4VfOexLf87dt91RqHS pCnxQkotHRRDTBen05qUtfGdhy0u2Kc9WLrJxzmuMrGmtqqyOjcrL8sozizM KgBGuqG1unekIfKAaB+Flu1VpBwOpPnfxSeqQsPsnAf9Lw/2VZ2+LMrzrEjo A+148h3dNFqO80BEWnKCJlYlTU4AdIi0fUCci2WjrxPOGqSn4vPELAtnYq81 rgfIyHMZFVogBUmpURoJmj/JFaDF8JuwOyk1wCwEltIia1wvzi61xnWLjBrB cX1gJcyaHBKYSRjDjrY9Ki4+YRD+tRXw6jiXXTFhy5RkFYFc0JxZkoItZ3yc xN0LbUOrBTCA+hdUuqzALFH/U6O1L/aUOizUOut21x0afkzVV/3X2/c3nt0K YoVApUqVZqUBLdBYd/1GLZRntqrI4TlSQYMAukGXm9fKCm7mCS3ITL1Ypo5m Dmx5A/qZyQiQWBYxiF6HXoIv4UxLQ3NZa7bQjFYqqebMIj1eWRpNfExEml4j VyeqKgXSfnk7MIFSk7E5G8PpqLKQagZl6paD36N5AkQiJ8kRXWpYhlAJ3zVT Uk2eKd9oNlWKH8FXvkH2ufocPdALgTw1PczqHiz4Td48zXk6Bp2tX1wL+zZj MhRY9wPrC5N8xSjfCirl/iwMqhgz5ZGjLAY9NOygQE5BkdFYVzNQ3gHoweoQ 7LUkOAlqtW5W9Y0zU27ZynJwhYZ5VPNAW8UQoC9URDmKUTAF3FJSXFPxRVIz FZ0jyVFXgB4hPELBGccurXf1inY9IJJfCG04APyBVOXoTN+jUnO8ZKFad6U1 aOha2Zevcj4dg4lfceHSiXVMWk6AMirloFoYaTVv+dm5wAjo3sLkAPFkGRXx JOxzKBiH0+A78JUN38/f5xrskyjymN4z3Hn64cl1aDbi+u5x8jxUUyea/efW F+D709EKPh8ZeSoNgy8KJOijdVL0GvpWgATw+8y85OosgzC5Sm/Bql5bU3TW Cr5KGXUhqyi5fW2bk8AedaB57MzUivSpTaXqUuMpA74kU0adSjPLu5bCA5Pt VnwuY9fCVZNreWbyCSwtaoQcOGw5XVx4psiqMCeecuEJ7EQ2+Uqig/y2rgqZ D9BLAPG7Fn71bp9vffzp8JIywdqr0o6oe7E3tPfBL+B30xcNVxqvNHfeHrUO AH2fcrvRNubuieb6rqFbf+uYyhDw9aDn748fORFd7dmqSRJ87twQ0rixdmfx BjAfvKN2jNondZYEb3HFFHoZVEHf6xyYc50Lc2APg6S7oBRFXYdRUHodSWHU LpwqDfjrS/QWc6Pt+GVwiT4Z0nMoJDYuNLxG1plvzM7OFxlzAMjGOpGvTwmX Bh0IElvfzOMqpwcWMc4w6ypeC0sePBl7woWn2S2MsbfsfuEl0CSsllXExcrk cUnmheUrRGjBG//DGfx4+NovjCQmOiKyLqappb6uqSW6XmLdysCv73kO2p2D uys5bDisZeaTldCO9/u5RWQzPMRzJSXoEA8JyZapgwjrwQx3OI1MQHY8RLv/ QYahCN4o2QYjeNAOn7cetFgPOCQSQVcm0XqdHVmFx8ScrKqaeLOSA3txx3aS SP6P7bybJH4JVf2ETT2n9kdo+tFqOxwZdxCgCApx3R+IqKl+ctrQS8P7u/xP xY6CU2CgvLNj9Fw3pAGcRcMAB/gWshVlRDNjxxEPBaJAf/vVq/3/gMdgyHHI fTo1S0wioRgqg9b9qZ0OPBVVklecm5tTYSzPxcpfVagMF1u3xMNS4pKSlcmq jADrQm4yUx9lJxWBEzT7fIqN7rM1dznwm6dcVgrfZNR5QW7q5ENAiFJI+BHc +uy7nvvgofCXDx+84+4ZfzRIFB6qDFdsrUoT9P7U2fopoMcuuK1Z57dszUox 2o5ceRrWDo96uVHHsHlQwbtOTVp/baFYR7R/En9bPwNhJy/ZwNuPAm/b8s/A pfBL5iKoyaxNpvlVV+J73LbbrXHbvSkq0VgbJJJUKIzWTzSUqoSQgfjPHjyq 7xsWD/fVj4Ib4FTScGRLYrWsxN9C8898OlzXddbu8Z7zy739FeHBIkmUMjr+ Y3O6oO/O8bargL523N85WBkcEyOWSKTKHbEY5S4pf7CDzZybzxr+aPmWCzOg I1N8o7y3a3joPAClVa0jpk7QB7rVnXE1IR0uNQcAvXzbXsej5fEtteXltaX6 EmW5WFOaVggK6Nah5pFLJzx2+qndY91F0j0yH51Plr+waDcjiYsNj6yOb26t qW5ujqmL/D/wfO8Tdh3GzNADLhuBg/u7rKs/iW5MuvL2wHa09gFcO06hnZ8w KJWEqfBH3uw/l6p64MsD7KEWDqTH4Kxb7Kxe7sTWO8y6EC/1ThzO1qPZ8FW4 +bvO7y9cFI+M3Gi4g7PGCvgGegUtnO+8aFe02txizM7Lzhdfg0bedlIXGN+n LA4BwsMgJCk01MMjYgM2Rs49PiODww3H20X5/l2RJwD98xPIhQx0Qu/A19Fe 5I8+QMuRJ3KHq9ACePSzk6bB52K0jnViGjPNsZnHMn0VLtEHZcGR8VGADopr O3224mR7t7ixtaOyNnPKAX/+iAMnPuPCXeznDPQiy0BujsHY/UyQbFQm6NIS MO4CScRBuqxMkAUyhWm5GQWtvanqPhGkgs7sBQvoxfs2rktUGKslovCauCLs IyJVmpjA4dh7Y7cbTp0UDx2vugDug9uyIe+T/oNuNWhGlZURkUPdRGEd56v7 mGyQLbOaDEsq7xBPrKJaTKZW0dd1KPgfF2Hw1LJtZKcPcdq/g7lfc1m3iY0M InWuss1eiFjvgkiA7MCqhvcHvLv9z8ZewSV+9ekP2KS9vvkxovwTUgOdxQ1w MbZyBFxRT6MjqId5enIL1o9px/Zte//A93D5qYLGSrO4qqylsMO6k5ORUsXe vsthD2DZmSRJFzS/PGXgZoXpHBBCCYl8Jr/jXSNhyMTbvL8mAdfd57bjScTA 4ImLKDjmKdVWpggR/2MVFaFSR4im5jAxu9Hm/P1td6H0U/f7tvxncIClGP6D n8909N+0+2LLpfmI8+FOh92WyN+Xi/jPEOEUH7HDbtGjHZAHZz64/tuD0BE0 62uRfB5zx7M2GOyndx86tHuD1+jfPqnuHx0WjTzAY60cDR46bzd6vO/qzQH/ 7W7SQ26BorQMANIzrPOCugF2eiOn+VuY+px7MZ6B003nLDdH/n7/MnwVwDk0 dFoOX0IMennle2gOmn37Q0ic6y/rOyM6gtYgrj1aEk3Di3CCAYnpydpkaWyQ OhjQG3zvwZcvlF2qqheXV9YVNwH6b8dXo4+wsLRoMU6zIZcD57L+/64JCE3/ d52AO3/9n3VndmIl61EJ3SvJ5hlPXm4umDnzScXMWQTxvwEtIyA5CmVuZHN0 cmVhbQplbmRvYmoKNDIgMCBvYmoKNzUzNAplbmRvYmoKNDMgMCBvYmoKPDwv U3VidHlwZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0NCAw IFI+PnN0cmVhbQp4nF1XCVxTx/a+MdxFBBTSCwqaRLCKiuzuAsoOZRMEBUVE QEDZBGQrWNe2Olq7aLXWCoIg0iqLaxEUl7pVRSpaggaFkDZu1artuXkT/u9N gq99/f+SX+69k5m553znO985I6KMhlAikcg4MCWjICU/PSlR/+Qg2IiE0UOE MeJinPWvqdpiegwVsu8XU2QiRiZGlaPfUVoIEeZwfjgUjaDEIlHR9r0+2TnF uempafly++jIhRMnT3b4e8Rl5syZ8uXF//1H7puSl56aJR9PbgpSMrJzMlOy 8mfLfcjsjIz0JHlqRnFOWp48MTk5JVm/LCYxI2WV3D89Iz0nJ7tAbu8zUe7q 7Owyhfy4hqVnLl+TJ49KzMqTh8gjU1LXZCTm/mOQoqiAkHnFWUmh3iXZybFh Pjkp4b6rV0T45ab656VFBuSnR61ZuSCoYFV0cGFGYsx7RZnLF9pPlDtMsXW0 c3J2cXXzmrp42vT4GTNnTaCoKZQtFUeFU76UI2VHLaYiKD9qFuVEjaPmU/6U M/UuFUkFUC7UeCqKCqQmUAuoIMqNsqeiqWDKnYqh3qOmUpOohVQINY2aTC2i QilvajrlQMVSYZQPNYMaShlTIsqUMqPE1HDKiBpBmVMWlIR6h5JTltQcyooa SXlSoyhryoZKowJJ6MgkKXnN19R90QTREtHzIRZDFg45OUQtHiEuEHcYORsh o2u0nI6jy+krDMfsZc6yE9l0tosL4TZz1UNdhmYMrR56cahiqM7Y2TjH+Ijx I+M/h+0Y1jTsV5MxJkUm7aacqZdpgWmx6Tem9aa9pq/M4szyza6ZPR8eMbxj hMuIbSPqzG3MA8xTzPstoiyyLbZDnZnQhpRatlx0XyOGedpM3nEgU4hVYh1j pnVCFRCnEJzLRUIWZPP3cDb9msE7tZk0NmHwnoFM+jemC7Jp+ELB41IGTOAR bSZ8jLOU2nfImpFCBY/f1Tlga8GBdmXAT1e5asbaFUVlaWjUB6hse/EObi67 b8O+jw6gGlS788DX1fv3Hvj6BJRpzUbqzaoQ5nemlVt0dHk+hE96rCTHO8iG ku90FQ/hBCvp/PNiR+/NE0khUvzvHkHO9gVfHO8Rm+kdL5UcV7HEjPwuwaFL VNcnFlbBS/6js+u+K6xNbQmp9UYcHuuEjbA39lDLwRbMu+/BO7tk05my6csS fRHntOAejACr84pfOk4t994lM9PeRRVa33LRPZXwuUospFlCogC0DlTaTMyz OG1gOM7QDqcxP5CpEoCBJB3QevSUsEMJpUqLbg10a8I0VhKh2xKUzG10dn/T CU7ypr6x/Nwla6RKanOs5yTCzbqj5+9ao7bC5pQjKUdjv/YjhrYwGnyLh1II ZM+h2k0Hi6oLv8pESSi5LGN1YW5R1qaFZFIg7uVhBxSyp9HhdQfyyM4H8nev SrVGaR+sWpO/Ji9z3VLEEURQp2DWKRLCCYw6G284zeCbOhN6ruDZiRUs/CiY kui1DcJW3wdtfWI4KNTzeIKrLfbFvipbmAgT1G9gLgS5v8aTZds8+ccXPbEl Hj7fw8kxsgskYHFJoZHpN1EsqBBCFOBZblHdB+dI8EqFjYRcM3AVk9YWdUjv 2mhXLMKzZZIW7NeHRTD2TmvNjdNSSan/XRaXCIm8+tJsbK7/23T+bDensAdg BmZXH/wiNfBSHw5o1ogFK2jioUYIp7GYwckY8EoAGrMMHNGRsSYNa6ZdMTj9 Z5UgVYm11sQMN52G0ZkLGnq8PmIqRjDVqeg3hPEr8pXCM6XojEasnSQgPgvc nRTYHU1EczKiw4N8Uu0QNkbYpGHcbd+L8+/kPEHgj148PQDR3GRmY+z69NKs zPDQdA/i3btOwEEwhKuAhbGXLxRnH5bV5O7N+DKaM8AjTFIQap/XU/tsn5Xk u/M4i38I1cyp6Ja8dsSBTT+IgIDTCb5TYQiW+UauCk0mzO72ZCU3oCSE//XK LGyOh4XNcnabfx+Gw/Af7qsMyHdBYDu4d4mO94qFXbCWR/c3nyltSu+dfW4i MWv8FEL8uXjuL2NhApj0tANTQYif778kNRDFoKVV2acKD286vPUct72d//zZ 5esPEae8HjB1C9qydQtJhP2D+DRqhL0E+1HaYh6nYFvsiItwEZArrFB117Re lnXfagYawTAOPsAymIJXSmcagevv2ASHYF9bcnHETnZELwIh8DW5OMr0UVIK 15Sifo0wWiPut4QjDIQADVIohAJsBFIcKsNHGM2ADS9cg7ksjPt5Eg7DIV4T 8TjZ/0D6lm5dwkaCqOS0tmSeHyvpupAccdjfBktdME3S3rPXFqSdrdWXmmS4 jsXjtbP5fkI2C2zyF9NMryp/lZlBHRGhgHaw6RSpesTwJUkcdyVztPybxs8/ QVv3S2+zRTvWbStBnGd8wlyZq19Ah25Jj7Ckjx3UzuNK2KkU/aKB/mdi4sw1 HoqZS+j0vqajp47tb0a3OBgzqwuPk+LzA5kaRrAxgp0Qw/a3LZ49O2axq2xQ Qj5RQplSpCbq/B484oWxSt1YKBOclbrtRKjLlTpvxgx6iZneKuL9bUIoK0nD bb1Q1uqF8iCL7u1vOVbLSW5X7z/42Q/buEds2fZN29ahaLR81WIPTtLwhIhl G87qAHN95pNNavvgONnlgeBMtvFiJc+uJS6qDbTBo1wwhz2nVvqdjJU1JVxc fQHdRN8far7J5bDId8Oygqw1GcuKF6EUlL4r/5uivRu/+rCOm8bstO+KgOFI gW4dPHLi2Jm9NxEM58jmwWRjXBTKq9u8sBU2j/Zyc15gkJCLin4SUCD4/fgP 1+GlEr8krsuVujI9Xn9JfHMfbCAqHyyY8VtfBfyATQnPzeaETJp5IhlGZMoU RT+UVRaglFFxcSu9l6bsOVAgXbt3894PGzg3Zgc2bZ8PY0jCjXx446Ui4aTd Qdns/QFfZx1ADaPOnKxrv1WftWC79G01ugNe5aKOHlKMxB1ERQYye0gh0peh mpoNpeXSqpJduWgFN1iOVCEX3p23NP+9OCkcHtQg+F5fDyw0GsDqWc+sJG8g DIi0b2J6GpJcZBJhazBa+kXCnsxRQFcyaVWbqrc82womRfVzjhBBVx777myP NVjMuY3tpLjfwBe5ERH9NaQuHN5YWXiwYM9KlMBNTUi2lxryNKQCmpRQo7Q4 pRHWKokAa2MFnseXZkJuIUNU1XLyFDxqXmBN8zLp4nNZfUjNQcDvYAyOIL4f OaVc+oRZDfbY6BGejVyRT37kkul+izGNsBWH82EMdobY37obun8igl05ib5M SFiX3ylMahc9IonyOSHOVBg3A4/zDfhJJ2di6jNvlJdv//SQtINd9/Hare8j LnX9rgYZ4F7WDHIJtoXlEFouukXWTiJrZ+gqehhtptF024f6NoSIzkuFxRlV kAaeqwI0+uzWCLv5rWA3sQfPIdF2t5+JR7o2Rz3NlUHQYlrS/2veiRWR1ii5 ICljTVZh/LoINAdF7087kfPtB0e3nSaB3xa4J6E2qTXgYSqIUR/6qby5vqWp 7ga6jtRRN+1r8HstIyVdblWrDl20vnuj5TlwN2Ictul5kN8Zq7fW4kYP7CA6 UyQUWAoVM3ArKzktj/JzD0o8dl0qsDN09qz7jajfu1pqbrdIJUXeejdx1l3t aIOfHYRA+iL8jF1YUrLoY4S2lUh92V1bPt26B3GPWxp/kmlNWUg0mmHbwxhS QcsoRfAVSYQ/tTY8bFTqbs+ETQM2GsYgUfrq9uKxGGIIKacMZD7Wp4YBUxE0 WkK8UEFPYbC9zgPLBQ9yCyG6Cvq/U/Tm/EBgH6uvznpGL2Me3Ac/3EC/Ykgt fUpqWBAtZ3AuzqUN9VErLRc90gjGRP9byBrdTnaibzgeGp2w52CaNPVQSQO6 wAk7Hck4tv/DCeaBFwx5DOOlwk5DU6bQ2paL9j2B1cSZXv36XSyav3llSW5x dnrJCsT5JTc/kjU7vMdiY8VcMAdJdzdYSIVTgzmk90k4awmOBp/sdA7jSGv5 LjNB5yAnN04MOBDXHjMvBac/dE60gVp6cNofisGBvGz6QCYhFAlih1+n4Nxl caIP9hiC+G0LqRVbNnyEPrTJen9vtQyuspqAVsx7haxJTpPm5azP3LKQe8h8 /mNjrQJx905kx8rWsCitoDRoIzYuLf5o1dqw3IwlKICTFDncDP/jZlvl+cvS z2Kq886jfWjP9prPSeWFAB5lbyzJzU/PWP5+HOKCU+raLjQc6t8jU+3+Zseh PdxfjY0w2hI+I122PYOX6gbwSmGAnsDAXtJv/zWlm8A3F77gYRj57NIZ0zCE wW2CL7RCq6E7/7eOpgWaNPMa9m82nIYqHnzhMz0fLHAktoBI2oEBH7wLh+Jy +gkDoyAerHA8/YwxdL1vO/CHkKP/WklaDLQldUXJSh78fOFq+7WjKYFSPKAf 0D9erU8O0j8KY9jH0ecm+iUWRMRJMy4mVgUgPxS/emkIJ2m5y/6zQTzfA+dI C1R63iCp926xkpawY21ZnTYgVZMGwBs8p77BUp9FORHJMqhlYTyu4DWD3U/o P7uff/kOgqMttYRQgp8dg611/XiW0E/ww9PI7Rhya8dAOIHydwamC09hju4p 4UmvNrZc1PlADOuIEROwVQgORtgFYdfrOPgFkbwLjBvYxcEcBO4I3FrAQwW2 3Ntl4PNArMFp/Auwug7BCFwQuIZA8ASw4hYwKmzXQiSK9JDYLQ57uGH9sjry xRMa+8tFfW/Efa95uyvFLPJfW7hkC5fCdhw93SsDEyIYvbDpjgga4AaPN/jA BpLroPUrF53T3NKIz2ljeSxma7A13cTUgDUNYvaW5f8f0avDa1HfazFEkbfY vdZzv7ACItvBux30RCvWhvKeTBpeRGNzph4W0V5Mqv7BNAAoJgN705gJeMmk 4FT6Z6YJUmkY8b8PQ9ttmTrwpv9od2RcA3jDfHPmWzJCXlxYoV1EwCkmgOL1 A+vpCwys1643nDA6BYVCdFINDWoxHCKOBKHwrBVx8aH5DobysvE+loADTFKS bqAMpGt+XfKjdEVrxKFAxHkYPWmeTIgbHz9louOS5xADMc1PnsgM9VlLzqmw WyWG3cJ2XrddpY2dz2ZgUWEpHl3ChehJh/qEE10iYaZaLHzSx+uGMjt/+Lah 7+yL8yN/O3+2k5SBy3kXEhsTGxd+E4hcUOCq5PDclHUJW3w4FfPJmc9qd1dW nvy+ug1x969EekWtXBySKnNaiO2nLwvciJ1HCRkGZVFA5T0o7bJoVsEetb+a nPlgNSj4L5mGbbTkzbPWhGmuC2KcJi8582qzjPQfkbtW7FtVH9CR9oz0IOMf 94G1Oq11Wi1pB25Wf9f6kzWYzerENtjOywNP/liqYrad3FH15YHyplNVFxCn aI6fG1ucmfy+LG99xkehW7lBHCwVoq5HCnU/QbcHFvPNLDr15b726/faD55G NzkYOuMeObONmzsbO0ofMej7Tw/trtrfcKyCONZ1Nj4gfk1yzBJZRAxCJfkF 2ZvyUSq3gFU78C526rcO9inAqU8kzCYw5pDo6YYwMTpL+gFzvOXIPmLVkyvB tu9GhE72XNJ0v4D4uHv+ruyK1cei72TcJz7avXgNk0Du+BSPjk1am7lcdgji aDijL2Q47Y628Y7oR1KNPtGzJuz/5kHYnXHaxldvX3xV0VPRqxCd6oeT5N0f EikqAc7rNqaQB/JLSQxJ8C8kecYjPOwbrxMhjZHXMhT6o9SzFyCDkS4aLPFb kLMwRbYN5l18+hJdQyeTvwrgiI5M5R+1RTi4hgfPmhna/ovqytW+QUYJz4mb +/QuZrkLEgZ74M3+2D4Gl3GPSQIU9sNCcId07m/TwaJHXEmkAML+NQ+H+bwa aBz31vRv70KewqJBHayGreTHSvJKsBGG8pJnnaeq6m9Zg9hdQRTZ3M0Di4Oq Uu8slUpezUpOivCwxpbPXUAO8udq4LuTLs9skmIOviQL751J8A+KS5g3L+7U rfaWU3dluNVI8kp1JWrG9PAol6nhl3p6rlwcPBIqIFIB17pEjWo9cG0wjd+H uZ/9gSJd+U+Nx6+fvl3eh4An57XinxOvJ18KrdOfYG0mTcAyPFLtCO/caqm6 8L1sK54XNXk8CkXLmsraOXhHWMkrrwU4uYeFTp0Wc/mJ+sqNB4Yj02u4/VoE Q4jqrBxUHaHCyCA+EKXXrzOPxWf+Vq9jf2lVfqVQoW9HQioZhXHPMMWnJiaP dpqYUtR/AA7cePgKZW5kc3RyZWFtCmVuZG9iago0NCAwIG9iago0NjgwCmVu ZG9iago0NSAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoIDQ2IDAgUj4+c3RyZWFtCnicVZMLTFNXGIDPpdzrzeyq o2u0oO3dZpxODIhLOvA9CKsT0KGgVjIscGmrtw/oY5Qi8vTB6Xho5VWgBUdV BDUaJ4pMnQaZGB0PZ3EjatpsbJpFXbZzyXXJLmZmWc7JyZ//ec73/wcDoSEA w7AwJc3YaIsuW710Yxajy7PS09pINgJj54Ww8wWQM0zVT+nx+SCp5embUCiA wtC2efjsMHTyLeSahfbPBgIMK3C1xxtN9nydRmuhFqWlbl28ZEnkf5plsbGx VJb9tYVKoM06jYFayAs2mjGa9LTBsoKK570ZRpdNaRi7SWum1Dk5dM50WLqa oXdTiTpGZzIZbdSi+MVUTHT0sqX8EZOi02dZzdRmtcFMJVGptMbKqPOp9RY1 n+h/NgDAzHXZtMasTbXoqDgA3gUJIBEowRawHiwHaeBTgIEIIOSpgFAQB3qw COxyyLaQY4J4gUtwSdAvmEBdoqko6EWqcTbag7FeZJT4OCP+nFjIA+KExMvl f+vx3wk0CxlxdGxcwjkItBk9xkXsAYufjfRj9wPoxmMB24eeSZzN/KqH1VLY bT+X52NOZjWnwmUwjk5PzEjRcRiMghlu1TFtz87egiE4Ab8/fvFa5wl3j/s6 qSD0sVsy4yGZmHl5fMh7v/uK/MxA/4lBSN46q02thBVVZXIRe9XiR8pRFO3H HgbQWEDA3kTFkuoWV1/teeiTPvnoBw58qMhSbpdlJOVyBIyDaR1bzuae0l1w 3IBICF/c60KAL6VJTNcoIbny88uPvM4jNc3y1lFJ5y/3hn6C5EjvjrWlVRUH HdPVOMMokoyyS/xaT1j3o8zAHLGfbWe9ksJVRd2lTVa3VBxsy9tdr4tYDVfR quT09TSHwyiSw0bWPL814LvaL9tfYODmpaW9A6Vi/yfZvl553YzDihlVxVXl sBLul64e3v7Xg5GjX/fK+vt8gz4knmQ3zBUHubJkydD5HWuT7euMKvmulE30 Rkgq1f0PbrYMHb8iP337+plbkHzdgbDBSSaA0gPJwTniMbaeFUlqvU4XbCSH lX0fJKTYcrJkGq15K8yAKacML0z3CuZ2lzVXukpI8eShsrqisnBodzCO4nzb zuKdPP8cX3+d0+U8Io8h9lmq9kIHuWJ4ByLR4qd+NHNw18nl7bI1bbh4bHOT wdMZDj0NX7W2HO04ceQCJAe6LTkVfKvKp+FBL5s6ilbzM2UPCpB1Si/hovhR ekgMovNHUcjw3Z+h9Jse3ba9EFaa5B9zT3jTj6ywutHZABukD7ZdUqxV2TYl yW6gDlw0lcuP6MUJVDMRxg48S3zi+G2OeBIdQnckqJy4fTpPVXjAts8qFz8z vw/h7nBY5CyptpEIJ2o7ihvK22C7FDZ82VLj5d/cePfwldZweKHYm9F1tt1d 3+o+d8Z3B35H/vlZH/e2jAsSr+75K/GQpSTXUA2OComrsLOizUaKg417DlvM 4TC3KNNqNGjUhRv4NqAuyygbeQd7yv+CEH46YogutABXEAy3AE8g9ijxEWLl S+JgaVUJLJWqevTferqqa5pk7jGmYh/PV2rdU++udtY66+TjrAAPEiKUz7P7 woOSPRhq4hMqCE7w0svjQVE8RQVhXcDLfFl+v3LEUMkLyXvT6j8IFMoH/CuL LB2sdzpNUgcx/kZg5nitUAjAP2pGWJAKZW5kc3RyZWFtCmVuZG9iago0NiAw IG9iagoxMjU1CmVuZG9iago0NyAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9G aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQ4IDAgUj4+c3RyZWFtCnicfVYN VFRlGr7DzNx7A9TkOlJhc1kXE1PBH1wxawNBNBIkFKSwaUEIRxEQGGFGGGR+ TLn+xPwx4PygYoQGYlzTTOnHn2UrykAq96jUUq66bItt9t7OR3v2u4M67jm7 e86ce+a79/3e9/2e93ne95MQsgBCIpHQCcWaUnV+qfg/WgiTCFMChMelNShV EH6h5I8TcTFF43YFS7hgKRcsa54SNBQCf5wItgmgfZiQSiSVu5sSiku0peqC 9eXhkRnpa2bMnDnL/2buokWLwnO1976EJ+aXqQuKwp/Af7bkFxaXbMovKl8c noCtCwvV68ILCrUl68vCc/Ly8vPEbZk5hfkbw5PUheqSkuIt4ZEJM8LnzZkz dzZ+zEtVb8rVlIWnFBcVh68IT88v0BTmlP7HS4IgHtUWrUspTshPW1paULZ+ Wbl6VUVhzqY14bNeIYiXiJVEIhFFpBERRBIxl3iCWEUsJ1YTzxGRRAaRTMQQ WUQKsYRIJWIJCTGOiCMew4gRMqKCGJWUSX4IiApoDfhVulZ6Vfa8rE9uJRmy mRylXqKD6TL67YdiH/o6MCEwKbAgsFIYHi8Mo9TjgouXdMMzsAhipdAxORFF yBFDag1Gvd5mdLNQTbqtVqfTaNWyySTYBJe8kXTbLI1Og0XLIimpM5j01TaT i/2IRAvQIIqFQfn7D1hQZKURW1hNHraJxCE5Hob4Ej4EQnhoOR7KfA2LhQWK OFI7ZuVm29GQiqwc8+phIZT0WLEvo6WSVUE9eYS3O/Y5aObkgTfa7J1hb3Me 04HKQ1ucpdwmGnFqSluLN9qxGwggXWNJ6Fg1WMjLS8/PTymoWPGCEiexlYc6 eAJnMciHMp3CBiFYkdOR6U3laPTYzFnoETTpZjSE9vZ6O7rZNzz73JyTttXa DMaddQajMiv7+bIEbBnw7Jc/gfSrAQi41p+TuZdlLup215sawxosNg/LdF6n mItuk61GyXRWmQxa1nd2QcNL+nlhQpcU/gzPKGAu3JHbRjX4+GMHxnnP8IOn FjQt4srZKK4iSRSNRtBcGJFHkvic1XrxnC2jGrUfYnG33be7ko0XNFYS5qM7 ct+JBYkvdCAvhQ+EBAUKmTYdTUATb0cCrsXtH2A8TJr+dzSJzZX9dPWp30Yu fCoiYuGV2yODV35kx/ZbeMnHvFQoFfYq1p5cefA5bjm3crMqO+fl4qVcKh1L oTCYgCbAlE96Dp46rTx0sMHF2WmHwVpr3L7TaFZmPJ+1OQnDFjj9Noxj+ygI +n4YpN9dyUzdo9y1td7o5OhGi93Fgoxymez6alOt7m6plvDwJC8R9kG2gnt3 p7fqyPpri7tnYleTpkej8WjyzxEQdh2C32u3G+wG82s7t5vYdRuXaFI4RHCL P6++Q/Myz42+c8PcMDeQtm8OPcbCdB728BJ4mIerGJJFsFUBT5NADg3cuLmw byqL3vRj/OGoJoP0M6ua9NjuYoyUJGyVwR5IoS73rlqWlJAeM1boXFj5DQ/5 mOc4QMTxn/mKrlDmDA7TooAIFam1GhobrDa3EkIpt9FWU200aJUqFAH5FNMN 784gdZZapwiHEtjReOp/ZMJUCxkQQ7rNNn2VGTtgzqAg9Bl1T2WFOHoCJvhF KMQSQzSpqzXW4I0u9ks0NNO30tuNGPHPSZfD6mjcZtWxKAk2k0znCAScPHAy bD/n3Xaw3GLas7Oeoxts9gab2aprZDc3a+xFXBaXVhwVS4+1EYji4bKo6495 +L5rHYwLZYaFFPiLgrnSu3bN4SVhSDZ7NqIRdXMmyPo/ONx7ikUKatnqjGVK 9BBuIr52g1OhyG7uqKujs+2I8zDH09hJ5IcUc+u+JGaTzBX0TIni1kD8jOhn 46Jmx39569bAwM0xjpbC4xANE3EaP/IVJ6HjVCjjEBIFhWL9YVVTOkczSTOW ZCdvdBe1atlWXatpwHTWdMh0qPpQlauUK6cZR2ZyXszvlna+q7RQTFKD0Y7V mywykY3F60qLsVHJ1DktVg/roI6/elrXy9EgHzz79VsV7YX72Y3N+Y6Vlvk2 826NE/va4tzmcj12/OyRga/e3/TK60pm6tbdFmNDmNNix6VzfEExU3F/0CsZ R40BRxir2m0eZN5mr4+XLSIvhRHFLH/FPxz1vDymdrGM8Ihf7Sqwkg7nR5+8 4TrLPdrF7cdtseVeW1RR/vYS6ievCvaQV5efj07NKU/Nuqu1FTwcE3UuBHVJ seLyFU2ifVODj+yZYpuqqfL5YdGT5OrNBcY1WIcR86/BFPYSxV1o/fRE17HO E67z3BDXn/t6Fq2rNzid9Xa38jrlec1aVWXGqq6mVEdXu5/jkrm0clVO1tpN 8VwCHU+heXemQWzPZ+7283eT+SfWZ/RxKbyI6QtBlMd81wEKiqfuT4gBtJ+M 68m+8Q2Qx960Gx2123fsfM2kzC1bqlvF0Uk5b3Wz4IVi6j6F7snjHxAggSMY 40uiOuY/IPBANIRiHmjJ/yJd9nvzbAGpEq4pakxGLZtOYUY0KFtIHyPOUW6T Va+8y8OnwAxzivmQv/LaE3D+RCgzVXhBaFQwDj5H5U4Lm/r0spgcd157Odum OVrzRU2f3mtuqWrVuTZy6+n4pRlRmHdzuPjuHb11+8xWPUfrjQYsTjlVaTU2 NOJwyjcpxpHNXyi7GAbB314c7i4/kX+QLfQUW3/vTLGXWUpcZa6qNq6N/rTn zNXLPaqVe338qzc5w5z1Vjf7I+Uy2/U+NEU8mgF4SRtuT6/CIqmQMvmaECx3 P9DmAvxonCGT0KV5YJVnkQuQNQEu4XH/Xw095OBosLyb/A4c15FDPjb/6nzk HkN9RET9/v0BAkc9/wf1MVx5SOThET6kn4cLuMeOD2V0wsLJf/OPeqZqNXjJ vmXvR72aXK1drdy23WzmttG1VoNj995du/YqLx9otRzl6EtnNrzEJlJpTYX1 L2MGT1yQFsMyp5/9eM2NvguHzvUoT8qWr8gUx3ySqr37k753fj7xnrn2KPvA Baa/C37ftW4EJPgh9lgZZlG8fxLja8z9uezy3UYcOMVacarjBBn+3LEjLR1h 7YfV61h0ccDPTuaU+P3YhbYDOMuOwxvyWaYe9T9o8LYaOsgLa0+/kLthy4t5 Ss17Gw/8gcvhirTqbN9oaxZ+4x3kJU2QDXGQLYUJk3tIoIUIkI5GyD8l/yR4 5F7/rQJNE7Os1os5f0umj5YgfN2Wp5BINjpllVAivyYWVzTFxY0Qq1OtF6vj FQuCf5AHEYpEtKduR90ObvujVc6afU7LXq9DCdPAJdYcTTwjEYQ4xa+yF3+R keMrvMICL4R4vV7ynUA+6J3gYD54HEH8G/xVqvkKZW5kc3RyZWFtCmVuZG9i ago0OCAwIG9iagoyNTA5CmVuZG9iago0OSAwIG9iago8PC9TdWJ0eXBlL1R5 cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDUwIDAgUj4+c3RyZWFt CnicXVVpVFRHFn6P7rfIKrQPVEJ3YwQEgeBCxO0YkW4QMCRjVAQXdmhtaIZN IdFBGROk0HEnCQytiAsg0AQ1KIiYGJyAsniMoqOeqKNiMihxu69PkTlTr4nJ mfnzTr2q+r5769b33aIpuRVF07RDWLI+LzlHlxjvF2zQJ0lTvqIrLb5lJbrJ EDaY95jzGTcqsmLQDtnKkK386FtjzE5wyxHKHaBgLCWj6Y0lZYsMmflZutS0 HPWUZX9a4T11qu8fM9Nmz56tTsh/s6IOSc7WpWaoPckgL1lvyExPzsiZq15E duv1ukR1qj4/My1bHZ+UlJwkwZbH65PXq7U6vS4z05CnnrLIWz09IGCaH/lM f1+XnpCbrV4an5GtjlRL+f/PDEVRqvyMRENSZnJUSEpWanaOLnfd+g36iIQp 3mo//4Bp0wMpKoaKokKoDygN9SGlpQIoDyqUWkqFUR9Ry6hwajkVQUVS0dQS ypdaRI2hrCmasqccKEfKiVJQzpSaFJGSk007qR9pb7qYfmgVbtUss5LNlxXI QF4kb5PfZyYza5n9zGXmIevKFrAm9hH7hP2VG8vt5lp4BW+AWnuxAxuem8ca aVEpmgQsH3HDNqIbg/1ZWD3SyZRwxVx0clJMYVHprnzlJO5gcVlJBWpAp/Yc 3v9VeUVVVTdkmRXj7UVAB0U/sMkwOnWBGtaC2kXR0kUYR0zkd4BTDHS3nOq9 VLMuQonvkZn/cGCzuBdzwTGZUYlKRctNjmSSAww8BYauB7VMrIRHwhYYP+MW dkU8DvRzx5FYO/g2zASXR7dB+FyFJ7L5GkPmMsSHxHW/bN/fWlGnKq+pLW9G F9HRzPIQniT1hrGBhNxDWOGCeEbAsz0xjTVYO4wpmANBz4GGhRAx5TWeryrF jDBwTuvuuULz3oLo/ufP2/tvqCxEY/wOiu/AGJhpdDpO2AqlE34iejuD2pyO 1biMTbuwqjqMpCp447F4VvChhY0rVIq2FaYruiuuPehsdUMHj61FO+HqWe1k 79hQjSa27+mz1v5+iT6bED+GMaR6373hboEY6ULUv5aQmQa2PqrV0It4cP4Z 7CHoRu6N1HMqxUB7alh9uGsois3QRfFgbRglj9FqNbG9w8OtfRJ5R85rmDQI Dq9p8SDkCaVlaBfagy4UndvclDo0sxPTJOd3fLEcL8YLn7iDH9gN9b2qVWEl WxCXlBWNEtH6ig01m42fHt7ezu8YFPbdaTj5PZFAXYHR8PmG3Xk7U3h7c2UO jBN3wTi6GXxET/CRiRPN+YIHmqVbEhauSfFAJAymTZMva7tC76x7gV6gOye6 ert6vnqFniNgU34J74/om1M3CfGleJwADje98HTsPccT22K7ucMkKb9/DoOd yt6cgsBRzAZHegB84CIJNOAMTSzIUP+Rts7vemufImAQyPVPP+yL6dRWYzk5 HVn3GRkWCMyVA+bbeTgQz1w6DzMqe7hHZDtj8KcX9ENJHVfEI0JQB3us7Isj ZeUl28uUL7k/70gr3Yh4/zVrA1ThC/xvjISBWgy7S+Q6gUAngGpU8S4K0+9q b+YUfXdOnrzz5f6S4kolTOKKSj9Fn6EItDQ+PZhXmF4RMOCMhy/JpT+yXDoR PGyGCS6K26IvYQniFP/ujl99bIkrHjcVO+K5eN4DLIcJXU2VnedVwVx4zBrN 8rRDJwuV2IMtjS/PaEw/nXap4C6Rx6wn10ChIjzfEA68G1NC//lgL+/osODF q3uGfjlztdeiCLCCl2Dl1ErihoMrdpQOMCzuEK2E7cDO6MMepGpu72qxLPWA vjJPVbmxYuv5Api7YrxisKGwrDB34rqkDeGpGXvK8pWfHNh2YNtxsp39G7a+ vwSC0HV0sby5rrnu8DnUgfrTWkIOYk37+KSyLXvRIb6mztimVAz3oBPZpTE8 uQAxbJC+O2rNI8J88CBe8tD69+Ef2Xdb4h/XVu/cW60c4jZtLyrZgviUrQda VXCWdAuoJeX/zNhNlNAjoRMtZpHqz5rT5YSEnIm1GNdmqrTRYixLW9ooNjmL JrLjEadoiVgTHxqVXndZCc8I2pbDNldCgbvWdvRSs1KxMUKKI1ZYovRLUVJG ozxj9YWF6Vu3le7cosRy7lhxw3Yj4u83Nj5Qmbv/CN5hSRHmG+lOCRwLdwXx beLodJKKhvv2HyDgrQwEsXgl/AsiIY7BM1hiJQuKFs3O4CeaGHLFs0fs54j2 DFZLo0Bp5MGC74iJgcnsPdHx9ogjY6mHOcT4WzHM6cJoHFZyjGXhB+IVUo1i 4fpNKMLXGQhl8XVxBnwNPQzWsLgJX2PgGvYhKB/u/zte5+8dr5NQS8REX23L 689m9bqCMAQOMOta7g+p51UpHYvrF6MwFJulW8ZDGQfW+JzQ16bx8o7RaENW 9T4fsjQluGdeaaRhrZQnhxfGYiXCfgj7t2IlkH/+GesOCTqQI/BC4FkP7CuI 49+g7PEqAThY2ApKBH4I/GNBick/78W+wgn1xPLYC2FPHWbdsYSqJUBIBFca 2uEnAVdjV6hmpYKBJw3rwFPAPpi0LNZiDFvxAHkvpA6fJFXyiDlNWIDC18d9 kPDRxgCE3RB2rJh+YtmpsL7ku2gAddV+fan5gvExgvEInD9+oPsmvldrCiL2 YeSN6PiGipQv0vfORz5oXtHcLYaP49NzElEKMlQWNG6qKbqOnqC7e2/vP15+ uuZwM+JHFZM2+JoccqsUfau4SRjZRF6Ylf5c7qzgOGxPOpH0UkpNMB9Y0m0n wmrptdwHjgLuYP/edMj44gY4PGy8gH7mwc3vAfbGXoEzsc82VFRaqISJVewt 05nu75viQuZn6XEAlimx7eyUyL9iF17M+60EcBhkL4nkRTuJepN5pTDiwEaO qBhwYr9sqKs8jfirp6MDg9ZGa97X1V4slt6KHXjsk1nkQnjwffGC9GuPac+w y6q0v+gTVFUwhYEzrH1OlWiS3BBbxYK1NbjbgPU+W1tw329rR1H/BRTK5VoK ZW5kc3RyZWFtCmVuZG9iago1MCAwIG9iagoyMjQ4CmVuZG9iago1MSAwIG9i ago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDUyIDAgUj4+c3RyZWFtCnicnVZpVBtHtm4Z6O4YQhz0NEAgkrJgyPGe4N3Y jrd4A2NMwLERi5AEYpMssRqQhAADKTYhVglLAglkywKz2GCwHfCWedh5HhKv x1lmksxks89k8uyZaqb041Xj4/PeOTO/3p8+3dW3qu797v2+ezmE9wKCw+H4 xstzpepl2xQ5EvZzKRPCYUIXMK97xSHxP5fN7fZ5ndh/0udl4OcF/Lx7Q/2T AuDjV2H/K1C/iPDicIoN9u0KZYlKnpGZL4z4MC7xnSVLlv7vyqr169cLxSUv /gh3SNXyjDzhYvxSKM1RKHOlefkbhduxdU6OPF2YkVOizFQL0yQSqYTdlpCW I80W7pLnyJVKRaEwYvs7wndXrly1DD/ejZHnigvUwjhFblqeMEaxXrhfGC2V yAty//UHQRBvvp+XHq2QKKWxqoxd6sx8+aGCrPjCvUU5abli4bLl70au3YCN iAPEDmI5EUvsJA4Su4hVxCFiNxFOxBN7iA+JvUQkkUDsI1YTicQS4jARTWwj YojtBIfwJ14huASPCCJCiLcwqoQ3UU484URxXJzfFqQv+NZrm9cV71DvRz4f +Nwlt5M68haVQV2ll9Il9L2XVr009tLPC8t8w33rfOt9bb4Tfnw/kd8Jv4uw 0X9OBhwqJ4waYXZZA7hDczsdvBpSAkptH8GFSM30BilIpPJckC7Xlh3VB3OV KphCcYccVGxTfjvoA51Gh+2KaSQIFpADUR0ZoIDmKkGhpiKzjuYOnQCaj8vx i1KFt8CHpKcW6ng/w5q/oRoff2Ya2JnVVs49KIB8KPCCmUwaDx1Sk+NVrRUg jUaTFEir1CfraTWstlOyZq0JDNHQSoGmlra21p5ee0cvoAe7lYcE6AQFZJpS eQ021dopSWNFBzhPwybq24Sr6w+IFLEyvj8Ty8Sc5jjgGzAALvJiVkIOT5Z2 rFwM6Mj472Dof5+5OWU2VeoMgmY9ACCt/sjJ/CFAn++zj8zsvvgeCg1/A72N +H+JgIseXnPduyHw/+cO4JgjHZxn5xknXOE1t4H5O89joMChcu3WKloF/+Sg otoq2sEXNBNDgTsm091m2oGaKZTkyUFJTI4PMqjIu9VmDUikPQoKHNBooyrx Po2DWm8otoB7NJNFwWbPDz79pD9TW+5iolzY/3C4CoZ7wSYml4e4EW+iUPTW L2/DQMh7/BQDKVzyFPEE9Tm8G5Z4tA4tL0o8GFv0CVwMd5ycmhFgzMuvMb7X 4Ad2fFIEXMvC/qOGN9HpaJ5pmTEG9VKiRk0nxo65g7LV1O0TrVVARKN9VOpE rlkEaLRgvRCFodAHEc+m3ebLk4La3/NAdcVxraYov1BXAOgE1e8hF/L6P73h dqmlXeyNKM0Gt1xlFl7Ptgbcxy6ugRGB3K/+T7bb2Gx76iggrtQfrcQp7LNR MY3HreA2Dd+gLib1acYBDb2/fAojBNwnULD1F+QVm5F/MIffIOKBllZzR6e1 p7ejB9BT9gMoEC1SxMZl5fUOl+HbY8vvwANDMNLFYRbDV3npR3JKUoEE5J0s HCw5U+mumaVhM1n9x7LJ7OGsEZE1Hof46toItBgt/noJXPTVpTM/fSZAJriF 1wj9To5eAk5gKTXmNBc3KBoO02WUPwMxe07B/kF4bVDlCPgVR7cBbg3kDkIT vMaDIfUDjeMnv3KN/yd4SHPXQHrpf6GNfO4guq8iP6/uKgU7aU8MxZWBaE1R UjXNHawFFXW6OlwF3zmoTW36VnCXZsq9uWt6uzvc37hTELFfKz2Wz1cXZVXt ADSOD9jhdRiWYQ/4BgoCMcnyWFgPqsmx6nYNSJ8nkbhCl8LCarFTMU3aTjBD w4PUlHPMbWytKm3nc2eVFpO+L2SozzlyQe5O+kiq3J2EoatF4jPQH/p91w9z pvWuAOf3m+DrMAiGyB4Fcn8jmELmTd40+h3FfUyYUxSG9BDku3bPUnlnVq9C 0KO2aCaLNinTpSARiE+W3Mqnuc90+/VZKvFrB+/LMQU3fD/114fRE2H8veTG ohbnaWfPqODCx5PAYRiwBuPjL/T1npt+DYxqTyuc9GZPAg/vv9J3PEsUfyzi PVHvuK2l3dkrwHf/mdHzJi3S5cuLM5KOlpz96WfL0KRgPi/w+gD0tsHFAzgx T+GaQO4T5su5dTzPLRU5W2MpY2lXTIHEct37LO08DmpFU0kHuErDcuq3uiFZ F6JpB/xBRZYgMjMzHJdgGcV9NtTZ9smPnx7PdPF7VO3Krv20HZMzWGMrdDPr 3AXWgP5fIf9xINcNf4KPeNxQGFZAVZdVn9CCalDRUNpMc3Pas/KbCkJW7ole u+ec6G+pgj/kOlUgm5bkHkveKbrwXSFfQXLdaL2DarcZWlpBMzDWtdX0a6d1 TkD/cHPmL19IxiLOCz44pXCAAdrtdAz39esKe/i2ovYSUwo9L6tzflbO7AtZ leCYUbyanNC3VAIx7Wn5/8pqRqPGxMpq/bysJsiKDiby/eG3zOpxzh32ohu4 9JbBKBUZszo9eW88rZxCD6m9Y+mzt0dPf32Or2ovkpaWF4Jgha57VACv/Ez5 QxewMeus9+EK1l3sKlu82NVxfaseuzpfvFWVIh2+v9JOZTZru8AwvZP5By81 MzMt2Z01Pj7gHh+TD6ayOlPsZrDSrHMVWwPGIQdWQ18sM0wxo+DB3Fyq6lhl 5XGgB7rGAiPNfWJOyjZIQ1Dous0o4L2p/dA3TnA7+/s0+zGQGLzrSPLmgx85 Lkn5yqFy9/HP6TwETpEGh7HVDIygvban6vLxoaoxXBARv/4JBtwX3d93RoDC 724YLXCAi8Ez54f/cOF8sewsfyDTnGfdy6aE2WPnfPYiIY81vDGTvemzlpkW LLgpDZiSYzT0IJGaulzToQWpNDpLZWUV6hSAFpdZPxHAH1GsmjpXadSzbbGZ eu9y4jdTg+bLN1j4UYqL+budhTAOvnydPb+TRTFZTX7y/DBPHpVQlp9VrGlp a25sMbTx28xN7aCNPq20Z8tUqozYG+KvZ6f7Lzn5ljPGYfApvXVuJy9VjgE+ k3VhbHBgbCyTBXhuBXAwCTYYaeVAA1zjhR8v8cD7Ot1qttnNOahIg64NPKAZ OwVfqZkSdSNf+hRZB0U+nidkLRL5nCK7oe/UBFzURLPtzMZss3OYEtbXJViu 6jqqgBroakqrSrajvUGbYEqVpc4ADMHA1NbiaGgAxnpjPW1HjWqqt9ZQa9A3 1E+Gm8XQD10K6iNhJCO0jBuNrsZgfPYS91yyg9MI3/oa+8m8xlzjgTtdpvts +32mor6qtZaDD2nPNBVdrEpWlnRajI2G1g5+h6nRCEz0qHxQIsuSS8XO5JF8 fl/5qH4UZ1p47wF8C4Mge+73XCLrd4iaHKpprwT5QKuR5Wwqk1QWauUV52o7 Cu8VzVY5QSswtzUPN2KvNWpqpKb+Y8seQ3HQB2iL+pbeVmU50RWs+Fx3BnRi M6OzCZup1FTfiabq/j0wwrMwyE7CV+HN39BNn14SrmDCzENGY19zMMsa+xxt 59xmky1m2R2nJgdrzSVANs9u2fEiee1zymTVl1rAKIs3E+0KcMDFiAuDIQ35 gdxZJvcWr6Kitrb24xMguLyq1SyAXdQft0wjfz53CPlsObxVbFedG3XaB7qq O7Vmgb6tFueDtjnNgzf6lDH8bRTyzThSJFPR3NnU3EJ56msxk8m3rk9YL1/l tx/uKb4ExoDLPHyORonXecqcIq0a0LmF/aM3zp//0oahvIfHv1V2zhfPafGc GukvhoLqdu0LAdA9715VrADoWAFgtcpgtnS22czdLd2AHjHlH5jXKrFOI2MD 12DTJixrz02bWdOe7nnTYZM6dt40TaeVsqZ6PC026DpYAj6fFuOk+fsS+bk3 M+37wX4gUkoPsPzF+u5iwq7AfdYALHV4bgoP5F6CGSz2CayyYrlKpz1PO6hH 1ybEZ0svg2AY/NNT+A7kb36MvI7Kjktkgjjv7jGr2Q3oGdduFCjgliF+7t59 aUrXRUzjRsxkuAXSHDgKR3moBtGwhsTLuAJW8kRSSfLRs7LJi8NDE5PSkfnm DGAwEw1JDpyGoV6MCmbw1GTedm11GJ5glpB4DFn+6P7gbfAg+B+bHyDio6NF GZl8iaRIrthKO0nXzJDzChgH7uKejI5CowJXcEpxfPaRw1GZaXj2WUnnM5EU e4kNvgK9mFWY8lYYxg7NRh6zcyMVuxn9B9q4Z8WBpcHIB9ajt2EYfPsm9KKQ +HdISkIpvOwzv50xwdc5zDG260aSKUjl4yAtt+y2q5hR6SQehM/6/IKj/FYD o/BcG8XBs9O/iRbOeouk0uQjZ2UXJ4eH8dowRqDIyqRZYaKVdC+EQl+3288P Cnv9XiaI/wFvtuQYCmVuZHN0cmVhbQplbmRvYmoKNTIgMCBvYmoKMzI4MQpl bmRvYmoKMjQgMCBvYmoKPDwvQmFzZUZvbnQvWEdYV1lNK1RURTFDOEU0MzB0 MDAvRm9udERlc2NyaXB0b3IgMjMgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFy IDEvTGFzdENoYXIgMTgvV2lkdGhzWyA2NjcgNjE3IDk1NCA1OTQgNjQwIDQx NiAyOTMgNDU0IDY0MCA2MzcgNDU0IDM2MyA2MzcgNjM3IDYzNwo2MzcgNjM3 IDYzN10KL0VuY29kaW5nIDUzIDAgUi9TdWJ0eXBlL1RydWVUeXBlPj4KZW5k b2JqCjUzIDAgb2JqCjw8L1R5cGUvRW5jb2RpbmcvQmFzZUVuY29kaW5nL1dp bkFuc2lFbmNvZGluZy9EaWZmZXJlbmNlc1sKMS9DL28vbS9lL24vdC9zcGFj ZS9icmFja2V0bGVmdC9oL29uZS9icmFja2V0cmlnaHQvY29sb24vdHdvL3Ro cmVlL2ZvdXIvZml2ZS9zaXgvc2V2ZW5dPj4KZW5kb2JqCjExIDAgb2JqCjw8 L0Jhc2VGb250L0hBSUhXRCtUaW1lcy1Sb21hbi9Gb250RGVzY3JpcHRvciAx MCAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIyL1dp ZHRoc1sKMjUwIDAgNDA4IDUwMCAwIDAgMCAxODAgMzMzIDMzMyAwIDU2NCAy NTAgMzMzIDI1MCAyNzgKNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDI3OCAwIDAgMCA1NjQgNDQ0CjkyMSA3MjIgNjY3IDY2NyA3 MjIgNjExIDU1NiA3MjIgNzIyIDMzMyAzODkgNzIyIDYxMSA4ODkgNzIyIDcy Mgo1NTYgNzIyIDY2NyA1NTYgNjExIDcyMiA3MjIgOTQ0IDAgNzIyIDAgMzMz IDAgMzMzIDAgMAowIDQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAg Mjc4IDI3OCA1MDAgMjc4IDc3OCA1MDAgNTAwCjUwMCA1MDAgMzMzIDM4OSAy NzggNTAwIDUwMCA3MjIgNTAwIDUwMCA0NDRdCi9FbmNvZGluZy9XaW5BbnNp RW5jb2RpbmcvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoxMyAwIG9iago8PC9C YXNlRm9udC9WTk9HVFMrSGVsdmV0aWNhL0ZvbnREZXNjcmlwdG9yIDEyIDAg Ui9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjIvV2lkdGhz WwoyNzggMCAzNTUgNTU2IDAgMCAwIDE5MSAzMzMgMzMzIDAgMCAyNzggMzMz IDI3OCAyNzgKNTU2IDU1NiA1NTYgNTU2IDAgNTU2IDU1NiA1NTYgNTU2IDU1 NiAyNzggMCAwIDAgMCA1NTYKMCA2NjcgNjY3IDcyMiA3MjIgNjY3IDYxMSA3 NzggMCAyNzggNTAwIDY2NyA1NTYgODMzIDcyMiA3NzgKNjY3IDAgNzIyIDY2 NyA2MTEgNzIyIDY2NyA5NDQgMCA2NjcgMCAyNzggMCAyNzggMCAwCjAgNTU2 IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMjIyIDUwMCAyMjIg ODMzIDU1NiA1NTYKNTU2IDU1NiAzMzMgNTAwIDI3OCA1NTYgNTAwIDcyMiA1 MDAgNTAwIDUwMF0KL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9TdWJ0eXBl L1R5cGUxPj4KZW5kb2JqCjE1IDAgb2JqCjw8L0Jhc2VGb250L1BOWUNWTStI ZWx2ZXRpY2EtT2JsaXF1ZS9Gb250RGVzY3JpcHRvciAxNCAwIFIvVHlwZS9G b250Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTE2L1dpZHRoc1sKMjc4IDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAw IDAgMjc4IDAgMCAwIDAgMAowIDY2NyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAKMCAwIDcyMiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAw IDUwMCAwIDU1NiAwIDU1NiA1NTYgMjIyIDAgMCAwIDAgMCAwCjAgMCAwIDUw MCAyNzhdCi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvU3VidHlwZS9UeXBl MT4+CmVuZG9iagozNiAwIG9iago8PC9CYXNlRm9udC9HQ05LWEkrQ291cmll ci9Gb250RGVzY3JpcHRvciAzNSAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIg MzIvTGFzdENoYXIgMTIxL1dpZHRoc1sKNjAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCA2MDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MAowIDAgMCA2MDAgMCA2MDAgMCA2MDAgMCAwIDAgMCAwIDYwMCAwIDAKNjAw IDAgMCA2MDAgMCAwIDAgNjAwIDAgMCAwIDAgMCAwIDAgNjAwCjAgNjAwIDAg NjAwIDAgNjAwIDAgNjAwIDYwMCA2MDAgMCAwIDYwMCA2MDAgNjAwIDYwMAow IDAgNjAwIDYwMCA2MDAgMCAwIDYwMCAwIDYwMF0KL0VuY29kaW5nL1dpbkFu c2lFbmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjIyIDAgb2JqCjw8 L0Jhc2VGb250L0hFTFVUVitIZWx2ZXRpY2EtQm9sZC9Gb250RGVzY3JpcHRv ciAyMSAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIx L1dpZHRoc1sKMjc4IDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMCAzMzMg Mjc4IDAKNTU2IDU1NiA1NTYgMCAwIDU1NiAwIDAgMCAwIDAgMCAwIDAgMCAw CjAgMCAwIDAgNzIyIDAgMCAwIDAgMCAwIDcyMiAwIDAgMCA3NzgKMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgNjExIDU1NiA2MTEgNTU2 IDMzMyA2MTEgMCAyNzggMjc4IDU1NiAyNzggMCA2MTEgNjExCjYxMSAwIDM4 OSA1NTYgMzMzIDYxMSAwIDc3OCAwIDU1Nl0KL0VuY29kaW5nL1dpbkFuc2lF bmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjkgMCBvYmoKPDwvQmFz ZUZvbnQvSFdDQ0FXK1RpbWVzLUJvbGQvRm9udERlc2NyaXB0b3IgOCAwIFIv VHlwZS9Gb250Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTE5L1dpZHRoc1sK MjUwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDMzMyAyNTAgMAowIDAgNTAw IDAgNTAwIDAgMCA1MDAgMCAwIDMzMyAwIDAgMCAwIDAKMCA3MjIgMCAwIDAg MCA2MTEgMCAwIDAgNTAwIDAgMCA5NDQgMCAwCjYxMSAwIDAgNTU2IDY2NyAw IDAgMCAwIDAgMCAwIDAgMCAwIDAKMCA1MDAgNTU2IDQ0NCA1NTYgNDQ0IDAg NTAwIDU1NiAyNzggMzMzIDAgMjc4IDgzMyA1NTYgNTAwCjU1NiAwIDQ0NCAz ODkgMzMzIDU1NiA1MDAgNzIyXQovRW5jb2RpbmcvV2luQW5zaUVuY29kaW5n L1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMjMgMCBvYmoKPDwvVHlwZS9Gb250 RGVzY3JpcHRvci9Gb250TmFtZS9YR1hXWU0rVFRFMUM4RTQzMHQwMC9Gb250 QkJveFswIC0xOTEgODkyIDc1OV0vRmxhZ3MgNAovQXNjZW50IDc1OQovQ2Fw SGVpZ2h0IDc1OQovRGVzY2VudCAtMTkxCi9JdGFsaWNBbmdsZSAwCi9TdGVt ViAxMzMKL01pc3NpbmdXaWR0aCAxMDAwCi9Gb250RmlsZTIgMzkgMCBSPj4K ZW5kb2JqCjEwIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5h bWUvSEFJSFdEK1RpbWVzLVJvbWFuL0ZvbnRCQm94Wy03MCAtMjE4IDkzMiA2 ODhdL0ZsYWdzIDQKL0FzY2VudCA2ODgKL0NhcEhlaWdodCA2ODgKL0Rlc2Nl bnQgLTIxOAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTM5Ci9NaXNzaW5nV2lk dGggMjUwCi9DaGFyU2V0KC90d28vTC9BL3kvbi9jL2dyZWF0ZXIvdGhyZWUv TS9CL3ovby9kL3F1ZXN0aW9uL1kvZm91ci9OL0MvcC9lL2F0L2ZpdmUvTy9E L3EvZi9icmFja2V0bGVmdC9zaXgvUC9FL3IvZy9zZXZlbi9RL0Yvcy9oL2Jy YWNrZXRyaWdodC9laWdodC9SL0cvdC9pL25pbmUvUy9IL3Uvai9jb2xvbi9U L0kvdi9rL1UvSi93L2wvYS9WL0sveC9xdW90ZXNpbmdsZS9tL2IvVy9wYXJl bmxlZnQvcGFyZW5yaWdodC9wbHVzL3NwYWNlL2NvbW1hL2h5cGhlbi9xdW90 ZWRibC9wZXJpb2QvbnVtYmVyc2lnbi9zbGFzaC96ZXJvL29uZSkvRm9udEZp bGUzIDQxIDAgUj4+CmVuZG9iagoxMiAwIG9iago8PC9UeXBlL0ZvbnREZXNj cmlwdG9yL0ZvbnROYW1lL1ZOT0dUUytIZWx2ZXRpY2EvRm9udEJCb3hbLTE4 IC0yMTggOTI5IDc0MV0vRmxhZ3MgNAovQXNjZW50IDc0MQovQ2FwSGVpZ2h0 IDc0MQovRGVzY2VudCAtMjE4Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAxMzkK L01pc3NpbmdXaWR0aCAyNzgKL0NoYXJTZXQoL3R3by9ML0EveS9uL2MvdGhy ZWUvTS9CL3ovby9kL3F1ZXN0aW9uL1kvTi9DL3AvZS9maXZlL08vRC9xL2Yv YnJhY2tldGxlZnQvc2l4L1AvRS9yL2cvc2V2ZW4vRi9zL2gvYnJhY2tldHJp Z2h0L2VpZ2h0L1IvRy90L2kvbmluZS9TL3Uvai9jb2xvbi9UL0kvdi9rL1Uv Si93L2wvYS9WL0sveC9xdW90ZXNpbmdsZS9tL2IvVy9wYXJlbmxlZnQvcGFy ZW5yaWdodC9zcGFjZS9jb21tYS9oeXBoZW4vcXVvdGVkYmwvcGVyaW9kL251 bWJlcnNpZ24vc2xhc2gvemVyby9vbmUpL0ZvbnRGaWxlMyA0MyAwIFI+Pgpl bmRvYmoKMTQgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFt ZS9QTllDVk0rSGVsdmV0aWNhLU9ibGlxdWUvRm9udEJCb3hbMCAtMjE4IDc3 MCA3MjldL0ZsYWdzIDQKL0FzY2VudCA3MjkKL0NhcEhlaWdodCA3MjkKL0Rl c2NlbnQgLTIxOAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTE1Ci9NaXNzaW5n V2lkdGggMjc4Ci9DaGFyU2V0KC9BL2MvZS9nL3MvaC9SL3QvaS9jb2xvbi9z cGFjZSkvRm9udEZpbGUzIDQ1IDAgUj4+CmVuZG9iagozNSAwIG9iago8PC9U eXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0dDTktYSStDb3VyaWVyL0Zv bnRCQm94Wy0xMiAtMTg2IDYxMiA2MjddL0ZsYWdzIDUKL0FzY2VudCA2MjcK L0NhcEhlaWdodCA2MjcKL0Rlc2NlbnQgLTE4NgovSXRhbGljQW5nbGUgMAov U3RlbVYgOTEKL0F2Z1dpZHRoIDYwMAovTWF4V2lkdGggNjAwCi9NaXNzaW5n V2lkdGggNjAwCi9DaGFyU2V0KC95L24vYy9NL28vQy9lL1AvRS9yL2cvcy9o L0cvdC9pL1MvdW5kZXJzY29yZS93L2wvYS9tL1cvc3BhY2UvY29tbWEpL0Zv bnRGaWxlMyA0NyAwIFI+PgplbmRvYmoKMjEgMCBvYmoKPDwvVHlwZS9Gb250 RGVzY3JpcHRvci9Gb250TmFtZS9IRUxVVFYrSGVsdmV0aWNhLUJvbGQvRm9u dEJCb3hbMCAtMjE5IDc2NiA3NDFdL0ZsYWdzIDQKL0FzY2VudCA3NDEKL0Nh cEhlaWdodCA3NDEKL0Rlc2NlbnQgLTIxOQovSXRhbGljQW5nbGUgMAovU3Rl bVYgMTE0Ci9NaXNzaW5nV2lkdGggMjc4Ci9DaGFyU2V0KC90d28veS9uL2Mv by9kL3AvZS9maXZlL08vRC9mL3IvZy9zL3QvaS91L2ovay93L2wvSy9iL3Bh cmVubGVmdC9wYXJlbnJpZ2h0L3NwYWNlL2h5cGhlbi9wZXJpb2QvemVyby9v bmUpL0ZvbnRGaWxlMyA0OSAwIFI+PgplbmRvYmoKOCAwIG9iago8PC9UeXBl L0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0hXQ0NBVytUaW1lcy1Cb2xkL0Zv bnRCQm94Wy01NyAtMjA2IDkyMSA2OTJdL0ZsYWdzIDQKL0FzY2VudCA2OTIK L0NhcEhlaWdodCA2OTIKL0Rlc2NlbnQgLTIwNgovSXRhbGljQW5nbGUgMAov U3RlbVYgMTM4Ci9NaXNzaW5nV2lkdGggMjUwCi9DaGFyU2V0KC90d28vQS9u L2MvTS9vL2QvZm91ci9wL2UvUC9yL2cvc2V2ZW4vRi9zL2gvdC9pL1MvdS9q L2NvbG9uL1Qvdi9KL3cvbC9hL20vYi9zcGFjZS9oeXBoZW4vcGVyaW9kKS9G b250RmlsZTMgNTEgMCBSPj4KZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVjZXIo R1BMIEdob3N0c2NyaXB0IDguMTUpCi9DcmVhdGlvbkRhdGUoRDoyMDEwMDcx ODE3MzMxNCkKL01vZERhdGUoRDoyMDEwMDcxODE3MzMxNCkKL1RpdGxlKE1p Y3Jvc29mdCBXb3JkIC0gVG93YXJkLXJlc29sdmluZy1BcHBsZXMtSlBTMi1j b21tZW50cy00LXRocnUtNy5kb2MpCi9DcmVhdG9yKFBTY3JpcHQ1LmRsbCBW ZXJzaW9uIDUuMi4yKQovQXV0aG9yKFRvbSBIYXN0aW5ncyk+PmVuZG9iagp4 cmVmCjAgNTQKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDI5MTI4IDAwMDAw IG4gCjAwMDAwNjI3MTAgMDAwMDAgbiAKMDAwMDAyOTAzOSAwMDAwMCBuIAow MDAwMDI4MzkzIDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAw Njc5NCAwMDAwMCBuIAowMDAwMDI5MTc2IDAwMDAwIG4gCjAwMDAwNjI0MDAg MDAwMDAgbiAKMDAwMDA1OTkyNiAwMDAwMCBuIAowMDAwMDYwNTMyIDAwMDAw IG4gCjAwMDAwNTc4MTQgMDAwMDAgbiAKMDAwMDA2MTA0MCAwMDAwMCBuIAow MDAwMDU4MzA3IDAwMDAwIG4gCjAwMDAwNjE1MjEgMDAwMDAgbiAKMDAwMDA1 ODc4NiAwMDAwMCBuIAowMDAwMDI5MjE3IDAwMDAwIG4gCjAwMDAwMjkyNDcg MDAwMDAgbiAKMDAwMDAyODU1MyAwMDAwMCBuIAowMDAwMDA2ODE0IDAwMDAw IG4gCjAwMDAwMTc0MDkgMDAwMDAgbiAKMDAwMDA2MjA3OSAwMDAwMCBuIAow MDAwMDU5NTI0IDAwMDAwIG4gCjAwMDAwNjAzMjQgMDAwMDAgbiAKMDAwMDA1 NzQyNiAwMDAwMCBuIAowMDAwMDI5MzEwIDAwMDAwIG4gCjAwMDAwMjkzNDAg MDAwMDAgbiAKMDAwMDAyODcxNSAwMDAwMCBuIAowMDAwMDE3NDMxIDAwMDAw IG4gCjAwMDAwMjQ0NjUgMDAwMDAgbiAKMDAwMDAyOTQwNSAwMDAwMCBuIAow MDAwMDI5NDM1IDAwMDAwIG4gCjAwMDAwMjg4NzcgMDAwMDAgbiAKMDAwMDAy NDQ4NiAwMDAwMCBuIAowMDAwMDI4MzcyIDAwMDAwIG4gCjAwMDAwNjE3NzIg MDAwMDAgbiAKMDAwMDA1OTE0MSAwMDAwMCBuIAowMDAwMDI5NDg5IDAwMDAw IG4gCjAwMDAwMjk1MTkgMDAwMDAgbiAKMDAwMDAyOTU4MiAwMDAwMCBuIAow MDAwMDM1MjU2IDAwMDAwIG4gCjAwMDAwMzUyNzcgMDAwMDAgbiAKMDAwMDA0 Mjg5NyAwMDAwMCBuIAowMDAwMDQyOTE4IDAwMDAwIG4gCjAwMDAwNDc2ODQg MDAwMDAgbiAKMDAwMDA0NzcwNSAwMDAwMCBuIAowMDAwMDQ5MDQ2IDAwMDAw IG4gCjAwMDAwNDkwNjcgMDAwMDAgbiAKMDAwMDA1MTY2MiAwMDAwMCBuIAow MDAwMDUxNjgzIDAwMDAwIG4gCjAwMDAwNTQwMTcgMDAwMDAgbiAKMDAwMDA1 NDAzOCAwMDAwMCBuIAowMDAwMDU3NDA1IDAwMDAwIG4gCjAwMDAwNTc2NDkg MDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSA1NCAvUm9vdCAxIDAgUiAvSW5m byAyIDAgUgovSUQgWyiN7om1i5mVuSSI8WV6clb8KSiN7om1i5mVuSSI8WV6 clb8KV0KPj4Kc3RhcnR4cmVmCjYyOTU0CiUlRU9GCg== ------=_NextPart_000_009B_01CB269F.BCC60260 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp ------=_NextPart_000_009B_01CB269F.BCC60260-- From ipp-bounces@pwg.org Sun Jul 18 18:53:30 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DA933A69C7 for ; Sun, 18 Jul 2010 18:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 SfOUAIs2RsBR for ; Sun, 18 Jul 2010 18:53:14 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 6BC553A6833 for ; Sun, 18 Jul 2010 18:53:14 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 65A49792E4; Sun, 18 Jul 2010 21:52:56 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by pwg.org (Postfix) with ESMTP id 49F54792E1 for ; Sun, 18 Jul 2010 21:52:45 -0400 (EDT) Received: from FamilyRoom ([unknown] [173.60.208.25]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L5S007SG7VIN6B0@vms173003.mailsrvcs.net> for ipp@pwg.org; Sun, 18 Jul 2010 20:52:40 -0500 (CDT) From: "Tom Hastings" To: , , "'Michael R Sweet'" , "'Paul Tykodi'" , "'Ira McDonald'" References: Date: Sun, 18 Jul 2010 18:52:29 -0700 Message-id: <99F0D23E60E741F8887E8F7B04908A4A@FamilyRoom> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-index: Acsmkxcchw5KazPoQxemxyenFdQB9AAFWo5QAA7wTlA= In-reply-to: X-pwg-MailScanner: Found to be clean, Found to be clean Cc: 'Gary Brown' , 'Daniel Manchala' , 'Daniel Bell' Subject: [IPP] RESEND: Toward resolving Apple's IPP WG Last Call comment on changing the JPS2 units for "font-size-requested" from points to decipoints X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tom.hastings@alum.mit.edu List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1030033592==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 65A49792E4.AA9B8 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============1030033592== Content-type: multipart/alternative; boundary="----=_NextPart_000_00AA_01CB26AA.647583F0" This is a multi-part message in MIME format. ------=_NextPart_000_00AA_01CB26AA.647583F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Since email with attachments is blocked by the IPP reflector (even small ones), the attachment that I refer to below is also posted at: ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JSP2-comment-on-uni ts-for-font-size-requested.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JSP2-comment-on-uni ts-for-font-size-requested.doc This is RESEND 1 or 2 for tomorrow's IPP WG telecon, July 19. (Yes, the "S" and "P" are switched in the file name, sorry). Tom _____ From: Tom Hastings [mailto:tom.hastings@verizon.net] Sent: Sunday, July 18, 2010 12:56 To: ipp@pwg.org; 'Michael R Sweet'; 'Paul Tykodi'; 'Ira McDonald' Cc: Daniel Bell; Gary Brown; Daniel Manchala; Peter Zehler; 'Tom Hastings' Subject: Toward resolving Apple's IPP WG Last Call comment on changing the units for "font-size-requested" from points to decipoints Since the font, highlighting, and indentation will be smashed when this mail message is turned to plain text, I've attached a 47 KB .pdf which is much more readable, complete with line numbers to make it easier to discuss at the telecon. For the IPP WG telecon, tomorrow, Monday, July 19, here is input for the agenda topic: > (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July > - > ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-cl > ean.pdf > (ended Monday 12 July 2010) > > (6) Next Steps > - IPP WG - Monday 26 July > - IPP JPS2 into PWG Last Call? Apple had made the following IPP WG Last Call comment: 2. The "font-size-requested" attribute uses points as the units, however it should probably use a higher-precision unit (at least decipoints, or 1/720th of an inch) to avoid issues with getting common fixed-width font spacing right (e.g. 17 characters per inch with a standard Courier font would need a point size of 5.293...) [And apologies for the late notice on this - I haven't read through the older material in a while...] I had the action item to contact Xerox about whether or not it had implemented the "font-size-requested" based on the draft submitted to the PWG in 2002. I had suggested the following possible alternatives to Xerox: If Xerox hasn't really implemented the "font-size-requested" Job Template attribute, Xerox should just agree to make the units be decipoints. However, if Xerox has implemented the "font-size-requested" Job Template attribute, what should the PWG do? Alternatives: 1. Xerox could argue that for real printing, the font size is specified in the document data, NOT in the IPP protocol. In the document data, the size of the font can be specified in finer units than points. So as the description says, this attribute is only used with 'text/plain', or 'text/html' (when there is no font size specified in the html), so the need for higher precision is not really needed. 2. Xerox could change its implementation. 3. Xerox could keep its implementation and ignore the PWG IPP standard in this respect. 4. Xerox could make it an installation option or configurable setting whether the Printer uses points or decipoints for this attribute. 5. Add a Printer attribute to the PWG spec that says what the units are for "font-size-requested", say, "font-size-requested-units" (type2 keyword) = 'points', 'decipoints'. If "font-size-requested-units" is NOT supported, clients MUST assume the units are: 'decipoints'. 6. Add a Printer attribute to the PWG spec that says what the units are for "font-size-requested", say, "font-size-requested-units" (type2 keyword) = 'points', 'decipoints'. If "font-size-requested-units" is NOT supported, clients MUST assume the units are: 'points'. Any other suggestions? The IPP WG Last Call comment period has been extended from June 21 (today), to Friday July 9, so we have a little time to decide what to do and what to recommend to the PWG. Thanks, Tom Dan Bell responded that Xerox had a long standing implementation and would be unlikely to change its implementation. He indicated his alternatives in order of decreasing desirability, including adding an additional suggestion #3 below: Tom, Thanks for the insights. Xerox HAS implemented support for "font-size-requested", and it's been in existence for a long time. I don't know how extensively it's used, but it's there. I would say it's highly unlikely that Xerox would be willing to change its long-time existing implementation at this point. For the proposed options of adding a "font-size-requested-units" attribute, another option would be to make it a job-template attribute and have it passed in the job along with "font-size-requested". Then a "font-size-requested-units-supported" attribute could advertise what the printer supports. And if a job is submitted with no "font-size-requested-units" then either the device assumes it's points, or uses the "font-size-requested-units-default" value. In my opinion the acceptable options, in order of preference, would be: 1. Xerox could argue that for real printing, the font size is specified in the document data, NOT in the IPP protocol. In the document data, the size of the font can be specified in finer units than points. So as the description says, this attribute is only used with 'text/plain', or 'text/html' (when there is no font size specified in the html), so the need for higher precision is not really needed. 2. Add a Printer attribute to the PWG spec that says what the units are for "font-size-requested", say, "font-size-requested-units" (type2 keyword) = 'points', 'decipoints'. If "font-size-requested-units" is NOT supported, clients MUST assume the units are: 'points'. 3. Add a Job template attribute to the PWG spec that what the units are for "font-size-requested" for the job, say, "font-size-requested-units" (type2 keyword) = 'points', 'decipoints'. If "font-size-requested-units-supported" is NOT supported on the Printer, clients MUST assume the units are: 'points'. If the job does not contain "font-size-requested-units", the Printer's default value is used. 4. Xerox could keep its implementation and ignore the PWG IPP standard in this respect. To further support alternative #1, I urge the IPP WG to remember that the very few "xxx-requested" Job Template attributes are ones that request the Printer to do something, as long as the document data is silent on that feature. If the document data does specify something, then the document data takes precedence. The "font-size-requested" is one of the 3 Job Template attributes whose precedence is lower than the document data. Others are "font-name-requested" [JPS2] and "orientation-requested" [RFC2911]. So the question is how likely is it that an application generates document data in which it can supply font size in the data but fails to do so? Or how likely is it that a user (1) received such a document or (2) received a plain text document from somewhere that the user wants to specify the font to a size more precisely than one point? Here is the current full text of the "font-size-requested" Job Template attribute which clearly describes these lower precedence attributes which are intended only for text/plain and text/html document formats or situations where the application could not or did not include the font size in the document data: 7.3 font-size-requested (integer (1:MAX)) 7.3.1 font-size-requested-default (integer (1:MAX)) 7.3.2 font-size-requested-supported (1setOf rangeOfInteger (1:MAX)) The OPTIONAL "font-size-requested" Job Template attribute enables an IPP client to specify what default font size the printer MUST use to print a job if the document data is in a format that does not have inherent font information (e.g., 'text/plain'). For document formats which have inherent font information (such as PostScript), this attribute will be ignored and will NOT override that information. For some document formats (such as 'application/postscript'), the desired default font size of the print-stream pages is specified within the document data. This information is generated by a device driver prior to the submission of the print job. Other document formats (such as 'text/plain') do not include the notion of desired font size within the document data. In the latter case it is possible for the Printer object to bind the desired font size to the document data after it has been submitted. It is expected that a Printer object would only support "font-size-requested" for some document formats (e.g., 'text/plain' or 'text/html') but not others (e.g., 'application/postscript'). This PDL-dependent behavior is no different than any other Job Template attribute since a Printer object may support or not support any Job Template attribute based on the document format supplied by the client. However, a special mention is made here since it is very likely that a Printer object will support "font-size-requested" for only a subset of the supported document formats. The "font-size-requested" units are points, equivalent to 1/72nd of an inch. This attribute can be specified as a Document Override that affects the Input-Document. The use of this attribute on a Page override basis is not supported since changing the font characteristics can affect the pagination. NOTE: The use of the "xxx-requested" pattern for attribute names indicates that the value of the attribute is to be used ONLY in the case when a value for the attribute is not contained within the source document. This value will override the printer's default value but will not override the source document's value. See the description of the "orientation-requested" Job Template attribute in [RFC2911]. At the meeting tomorrow and/or on the mail list, the IPP WG needs to consider the alternatives for resolving Apple's IPP WG Last Call comment. Thanks, Tom -----Original Message----- From: Ira McDonald [mailto:blueroofmusic@gmail.com] Sent: Sunday, July 18, 2010 09:06 To: ipp@pwg.org; Michael R Sweet; Paul Tykodi; Tom Hastings; Ira McDonald Subject: Re: IPP Agenda - 4pm EDT Monday 19 July 2010 Hi, REMINDER of tomorrow's IPP WG telecon Cheers, - Ira On Mon, Jul 12, 2010 at 4:12 PM, Ira McDonald wrote: > Hi, > > [rescheduled from 12 July - apologies for missing agenda posting] > > Reminder of our next IPP WG call: > > Monday 19 July - 1-2pm PDT / 4-5pm EDT > > Call-in toll-free number (US/Canada): 1-866-469-3239 > Call-in toll number (US/Canada): 1-650-429-3300 (Primary) > Call-in toll number (US/Canada): 1-408-856-9570 (Backup) > > Attendee Access Code: *******# > Attendee ID Code: # (empty) > > If you need the Attendee Access code, please email me a request. > > > *** Main Objective - move IPP JPS2 into PWG Last Call *** > > Agenda: > > (1) PWG IP Policy and Minute Taker > - Mike? > > (2) Approve IPP minutes from last meeting > - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20100621.pdf > > (3) Status of IPP Version 2.0 Second Edition (Ira) > - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100527-rev.pdf > (or later draft if available) > > (4) Status of PWG Formal Vote on IPP Everywhere Charter (Mike/Ira) > - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeverywhere-charter-20100610.pdf > (ended Monday 12 July 2010) > > (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July > - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-clean.pd f > (ended Monday 12 July 2010) > > (6) Next Steps > - IPP WG - Monday 26 July > - IPP JPS2 into PWG Last Call? > > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Co-Chair - TCG Hardcopy WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music/High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto:blueroofmusic@gmail.com > winter: > 579 Park Place Saline, MI 48176 > 734-944-0094 > summer: > PO Box 221 Grand Marais, MI 49839 > 906-494-2434 > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_NextPart_000_00AA_01CB26AA.647583F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since email with attachments is blocke= d by the IPP reflector (even small ones), the attachment that I refer to below is also posted at:

 

ftp://ftp.pwg.org/pub/pwg/ipp/wd/= Toward-resolving-Apples-JSP2-comment-on-units-for-font-size-requested.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/wd/= Toward-resolving-Apples-JSP2-comment-on-units-for-font-size-requested.doc

 

This is RESEND 1 or= 2 for tomorrow’s IPP WG telecon, July 19.  (Yes, the “S” a= nd “P” are switched in the file name, sorry).

 

Tom

 


From: Tom Hast= ings [mailto:tom.hastings@verizon.net]
Sent: Sunday, July 18, 2010 = 12:56
To: ipp@pwg.org; 'Michael R Sweet'; 'Paul Tykodi'; 'Ira McDonald'
Cc: Daniel Bell; Gary Brown;= Daniel Manchala; P= eter Zehler; 'Tom Hastings'
Subject: Toward resolving Ap= ple's IPP WG Last Call comment on changing the units for "font-size-requested" from points to decipoints

 

Since the font, highlighting, and indentation will be smashed when this mail message is tur= ned to plain text, I’ve attached a 47 KB .pdf which is much more readable, complete with line numbers to make it easier to discuss at the telecon.

 

For the IPP WG tele= con, tomorrow, Monday, July 19, here is input for the agenda topic:

 

> (5) Status of IPP WG Last Call on IPP JPS2 = (Tom) - ends Monday 12 July

>  -

> ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-cl=

> ean.pdf

>   (ended Monday 12 July 2010)

> 

> (6) Next Steps

>  - IPP WG - Monday 26 July<= /span>

>  - IPP JPS2 into PWG Last Call?

 

Apple had made the following IPP WG Last Call comment:

 

2. The "font-size-requested" attribute= uses points as the units, however it should probably use a higher-precision unit= (at least decipoints, or 1/720th of an inch) to avoid issues with getting common fixed-width font spacing right (e.g. 17 characters per inch with a standard Courier font would need a point size of 5.293...) [And apologies for the la= te notice on this - I haven't read through the older material in a while...]

 

 

I had the action it= em to contact Xerox about whether or not it had implemented the “font-size-requested” based on the draft submitted to the PWG in 2002.  I had suggested the following possible alternatives to Xerox:

 

If Xerox hasn’t really implemented the “font-size-requested”= Job Template attribute, Xerox should just agree to make the units be decipoints= .

<= o:p> 

H= owever, if Xerox has implemented the “font-size-requested” Job Template attribute, what should the PWG do?  Alternatives:

<= o:p> 

1.      = Xerox could argue that for real printing, the= font size is specified in the document data, NOT in the IPP protocol.  In t= he document data, the size of the font can be specified in finer units than points.  So as the description says, this attribute is only used with ‘text/plain’, or ‘text/html’ (when there is no font size specified in the html), so the need for higher precision is not really needed. =

<= o:p> 

2.      = Xerox could change its implementation.=

<= o:p> 

3.      = Xerox could keep its implementation and ignore the PWG IPP standard in this respect. <= o:p>

<= o:p> 

4.      = Xerox could make it an installation option or configurable setting whether the Printer uses points or decipoints for this attribute.

 

5.      = Add a Printer attribute to the PWG spec that = says what the units are for “font-size-requested”, say, “font-size-requested-units” (type2 keyword) =3D ‘points&#= 8217;, ‘decipoints’.  If “font-size-requested-units” = is NOT supported, clients MUST assume the units are: ‘decipoints’.=

<= o:p> 

6.      = Add a Printer attribute to the PWG spec that = says what the units are for “font-size-requested”, say, “font-= size-requested-units” (type2 keyword) =3D ‘points’, ‘decipoints’.  If “font-size-requested-units” is NOT supported, clients MUST assu= me the units are: ‘points’. <= o:p>

 

A= ny other suggestions?<= /font>

 

The IPP WG Last Call comment period has been extended from June 21 (today), to Friday July 9, so we have a little time = to decide what to do and what to recommend to the PWG.

 

Thanks,<= /span>

Tom

 

 

 

Dan Bell responded = that Xerox had a long standing implementation and would be unlikely to change its implementation.  He indicated his alternatives in order of decreasing desirability, including adding an additional suggestion #3 below:

 

Tom,

 

Thanks for the insi= ghts.

 

Xerox HAS implement= ed support for “font-size-requested”, and it’s been in exist= ence for a long time.  I don’t know how extensively it’s used, = but it’s there.

 

I would say it̵= 7;s highly unlikely that Xerox would be willing to change its long-time existing implementation at this point.

 

For the proposed op= tions of adding a “font-size-requested-units” attribute, another opti= on would be to make it a job-template attribute and have it passed in the job along with “font-size-requested”.  Then a “font-size-requested-units-supported” attribute could advertise what the printer supports.  And if a job is submitted with no “f= ont-size-requested-units” then either the device assumes it’s points, or uses the “font-size-requested-units-default” value.

 

In my opinion the acceptable options, in order of preference, would be:

 

1.      = Xerox could argue that for real printing, the font size is specified in the document data, NOT in the IPP protocol. = In the document data, the size of the font can be specified in finer units than points.  So as the description says, this attribute is only used with ‘text/plain’, or ‘text/html’ (when there is no font size specified in the html), so the need for higher precision is not really needed. =

2.      = Add a Printer attribute to the PWG spec that = says what the units are for “font-size-requested”, say, “font-size-requested-units” (type2 keyword) =3D ‘points&#= 8217;, ‘decipoints’.  If “font-size-requested-units” = is NOT supported, clients MUST assume the units are: ‘points’.

3.      = Add a Job template attribute to the PWG spec that what the units are for “font-size-requested” for the job, = say, “font-size-requested-units” (type2 keyword) =3D ‘points&#= 8217;, ‘decipoints’.  If “font-size-requested-units-supported” is NOT supported on the Printer, clients MUST assume the units are: ‘points’.  If = the job does not contain “font-size-requested-units”, the Printer’s default value is used.

4.      = Xerox could keep its implementation and ignore the PWG IPP standard in this respect. <= o:p>

 

 

 

To further support alternative #1, I urge the IPP WG to remember that the very few “xxx-requested” Job Template attributes are ones that request t= he Printer to do something, as long as the document data is silent on that feature.  If the document data does specify something, then the docume= nt data takes precedence.  The “font-size-requested” is one of the 3 Job Template attributes whose precedence is lower than the document data.  Others are “font-name-requested” [JPS2] and “orientation-requested” [RFC2911]. 

 

So the question is = how likely is it that an application generates document data in which it can su= pply font size in the data but fails to do so?

Or how likely is it= that a user (1) received such a document or (2) received a plain text document f= rom somewhere that the user wants to specify the font to a size more precisely = than one point?

 

Here is the current= full text of the “font-size-requested” Job Template attribute which = clearly describes these lower precedence attributes which are intended only for text/plain and text/html document formats or situations where the applicati= on could not or did not include the font size in the document data:

7.3             font-size-requested  (integer (1:MAX))

7.3.1       font-size-requested-defaul= t  (integer (1:MAX))

7.3.2       font-size-requested-suppor= ted  (1setOf rangeOfInteger (1:MAX))

The OPTIONAL "font-size-requested" Job Template attribute enables an IPP client to specify what default font size = the printer MUST use to print a job if the document data is in a format that does not h= ave inherent font information (e.g., ‘text/plain’).  For docum= ent formats which have inherent font information (such as PostScript), this attribute will be ignored and will NOT override that information.

For some document formats (such as 'application/postscript'), the desired default font size of the print-stream pages is specified within the document data.  This information is generated by a device driver prior to the submission of the print job.  Other document formats (such as 'text/plain') do not include the notion of desired font size within the document data.  In the latter case it is possible for the Printer object to bind the desired font size to the docume= nt data after it has been submitted.  It is expected that a Printer object would only support "font-size-requested" for some document formats (e.g., 'text/plain' or 'text/html') but not others (e.g., 'application/postscript').  This PDL-dependent behavior is no different than any other Job Template attribute since a Printer object may support or= not support any Job Template attribute based on the document format supplied by= the client.  However, a special mention is made here since it is very like= ly that a Printer object will support "font-size-requested" for only= a subset of the supported document formats.

The “font-size-requested” units are points, equivalent to 1/72nd of an inch.

This attribute can be specified as a Document Ov= erride that affects the Input-Document.  The use of this attribute on a Page override basis is not supported since changing the font characteristics can affect the pagination.

NOTE:  The use of the “xxx-requested&= #8221; pattern for attribute names indicates that the value of the attribute is to= be used ONLY in the case when a value for the attribute is not contained within the source document.  This value will override the printer’s def= ault value but will not override the source document’s value.  See the description of the “orientation-requested” Job Template attribu= te in [RFC2911].

At the meeting tomo= rrow and/or on the mail list, the IPP WG needs to consider the alternatives for resolving Apple’s IPP WG Last Call comment.<= /p>

 

Thanks,<= /span>

Tom

 

 

 

-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic@gmail.com]
Sent: Sunday, July 18, 2010 09:06
To: ipp@pwg.org; Michael R Sweet; Paul Tykodi; Tom Hastings; Ira McDonald
Subject: Re: IPP Agenda - 4pm EDT Monday 19 July 2010

 

Hi,

 

REMINDER of tomorrow's IPP WG telecon

 

Cheers,

- Ira

 

On Mon, Jul 12, 2010 at 4:12 PM, Ira McDonald <blueroofmusic@gmail.com> wrote:

> Hi,

> 

> [rescheduled from 12 July - apologies for missing agenda posti= ng]

> 

> Reminder of our next IPP WG call:

> 

>  Monday 19 July - 1-2pm PDT / 4-5pm EDT=

> 

>  Call-in toll-free number (US/Canada): 1-866-469-3239

>  Call-in toll number (US/Canada): 1-650-429-3300 (Primary= )

>  Call-in toll number (US/Canada): 1-408-856-9570 (Backup)=

> 

>  Attendee Access Code: *******#<= /p>

>  Attendee ID Code: # (empty)

> 

> If you need the Attendee Access code, please email me a reques= t.

> 

> 

> *** Main Objective - move IPP JPS2 into PWG Last Call ***=

> 

> Agenda:

> 

> (1) PWG IP Policy and Minute Taker

>  - Mike?

> 

> (2) Approve IPP minutes from last meeting

>  - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-mi= nutes-20100621.pdf

> 

> (3) Status of IPP Version 2.0 Second Edition (Ira)<= /span>

>  - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100527-rev= .pdf

>   (or later draft if available)<= /p>

> 

> (4) Status of PWG Formal Vote on IPP Everywhere Charter (Mike/= Ira)

>  - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeverywhere-charter-20100610.pdf=

>   (ended Monday 12 July 2010)

> 

> (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday= 12 July

>  - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10= -v28-20100606-clean.pdf

>   (ended Monday 12 July 2010)

> 

> (6) Next Steps

>  - IPP WG - Monday 26 July

>  - IPP JPS2 into PWG Last Call?<= /p>

> 

> Ira McDonald (Musician / Software Architect)=

> Chair - Linux Foundation Open Printing WG

> Co-Chair - TCG Hardcopy WG

> IETF Designated Expert - IPP & Printer MIB

> Blue Roof Music/High North Inc

> http://sites.google.com/site/blueroofmusic

> http://sites.google.com/site/highnorthinc

> mailto:blueroofmusic@gmail.com

> winter:

>   579 Pa= rk Place  Saline, MI  48176

>   734-944-0094

> summer:

>   PO Box 221  Grand Marais, MI 49839

>   906-494-2434

> 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_NextPart_000_00AA_01CB26AA.647583F0-- --===============1030033592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1030033592==-- From ipp-bounces@pwg.org Sun Jul 18 18:57:39 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1003A69C2 for ; Sun, 18 Jul 2010 18:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 331tcE8fHuf1 for ; Sun, 18 Jul 2010 18:57:22 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 18FF73A679F for ; Sun, 18 Jul 2010 18:57:22 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 11DB9792F5; Sun, 18 Jul 2010 21:57:04 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by pwg.org (Postfix) with ESMTP id B2302792E4 for ; Sun, 18 Jul 2010 21:56:52 -0400 (EDT) Received: from FamilyRoom ([unknown] [173.60.208.25]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L5S00EK982C6JC0@vms173005.mailsrvcs.net> for ipp@pwg.org; Sun, 18 Jul 2010 20:56:42 -0500 (CDT) From: "Tom Hastings" To: References: <8A7AC5E37CBD47739FFCFB03327849CC@FamilyRoom> Date: Sun, 18 Jul 2010 18:56:35 -0700 Message-id: <94B58C53D28947BBBD73C0B1067B0E79@FamilyRoom> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-index: Acsm2k5n2AHqgvP7SyqmdDTDN7cMowACkuFw In-reply-to: <8A7AC5E37CBD47739FFCFB03327849CC@FamilyRoom> X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] {Disarmed} RESEND: Toward resolving Apple's IPP WG Last Call JPS2 comments 4 thru 7 - for Mon, Jul 19, IPP WG telecon X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tom.hastings@alum.mit.edu List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1774729212==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 11DB9792F5.A96C3 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============1774729212== Content-type: multipart/alternative; boundary="----=_NextPart_000_00B1_01CB26AA.F4925E40" This is a multi-part message in MIME format. ------=_NextPart_000_00B1_01CB26AA.F4925E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Since email with attachments is blocked by the IPP reflector (even small ones), the attachment that I refer to below is also posted at: ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JPS2-comments-4-thr u-7.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JPS2-comments-4-thr u-7.doc This is RESEND 2 or 2 for tomorrow's IPP WG telecon, July 19. Tom _____ From: Tom Hastings [mailto:tom.hastings@verizon.net] Sent: Sunday, July 18, 2010 17:36 To: ipp@pwg.org; 'Michael R Sweet'; 'Paul Tykodi'; 'Ira McDonald' Cc: 'Tom Hastings' Subject: Toward resolving Apple's IPP WG Last Call JPS2 comments 4 thru 7 - for Mon, Jul 19, IPP WG telecon For the IPP WG telecon, tomorrow, Monday, July 19, here is 2 or 2 input for the agenda topic: Since the font, highlighting, and indentation will be smashed when this mail message is turned to plain text, I've attached a 63 KB .pdf which is much more readable, complete with line numbers to make it easier to discuss at the telecon. I've also down loaded v30 of JPS2 .doc and .pdf (without hot links). If Pete Zehler can update the .pdf that would be good, but he may be on vacation. So the following 6 documents are in the wd sub-folder for the IPP WG telecon tomorrow, Monday, July 19: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v30-20100718.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v30-20100718.doc and the following two documents that attempt to resolve Apple's IPP WG Last Call comments (same as I attached to this and the previous email): ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JPS2-comments-4-thr u-7.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JPS2-comments-4-thr u-7.doc and: ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JSP2-comment-on-uni ts-for-font-size-requested.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-JSP2-comment-on-uni ts-for-font-size-requested.doc (Yes, the S and P are switched in this last file name by mistake). For the IPP WG telecon, tomorrow, Monday, July 19, here is 2 or 2 input for the agenda topic: > (5) Status of IPP WG Last Call on IPP JPS2 (Tom) - ends Monday 12 July > - > ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-cl > ean.pdf > (ended Monday 12 July 2010) > > (6) Next Steps > - IPP WG - Monday 26 July > - IPP JPS2 into PWG Last Call? File: Toward-resolving-Apples-JPS2-comments-4-thru-7.doc From: ipp-bounces@pwg.org on behalf of Michael Sweet [msweet@apple.com] Sent: Monday, June 21, 2010 12:58 To: ipp@pwg.org Subject: [IPP] Apple has reviewed the JPS2 specification and has comments Attachments: ATT02705.txt Comments: 1. The document date is wrong in the headers. TH> Updated to today's date. 2. The "font-size-requested" attribute uses points as the units, however it should probably use a higher-precision unit (at least decipoints, or 1/720th of an inch) to avoid issues with getting common fixed-width font spacing right (e.g. 17 characters per inch with a standard Courier font would need a point size of 5.293...) [And apologies for the late notice on this - I haven't read through the older material in a while...] TH> See separate email thread and attached .pdf more readable version for this issue and possible alternatives for resolution. 3. Question: do we need the PWG process reference at the beginning of section 3? Do we need to explain why we organize our standards documents this way? TH> Need IPP WG input here. 4. On line 372 of the -rev document you say "these features are useful in the "light production printing" environments, but we don't define what "light production printing" is, just "production printing". TH> Just remove the clause entirely, OK? 5. Line 427 - I think Close-Job is Owner + Operator, per RFC 2911's description of Send-Document and the Close-Job references in JPS2: Access Rights: The authenticated user (see section 8.3) performing this operation must either be the job owner (as determined in the Create-Job operation) or an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return: 'client-error-forbidden', 'client- error-not-authenticated', or 'client-error-not-authorized' as appropriate. TH> Added: Access Rights: The authenticated user (see [RFC2911] section 8.3) performing this operation must either be the job owner (as determined in the Create-Job operation) or an operator or administrator of the Printer object (see [RFC2911] Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return: 'client-error-forbidden', 'client-error-not-authenticated', or 'client-error-not-authorized' as appropriate. 6. Line 567-568: The definition says up to 255 characters for job-password and job-password-supported, but here we say 127 octets. TH> Fixed 7. a: Section 10.5 (job-spooling-supported) - shouldn't this be a 1setOf? b: Also, lines 580-581 basically says that the values are implementation-dependent regardless of whether the attribute is supported or not. :) c: Based on the current description I think we need to specify when the value is 1setOf and when it is not (i.e. a Get-Printer-Attributes request with a document-format would return the value for that format, otherwise you'd get the value for the default format or a 1setOf if the answer can't be made definitively without a format...) d: This will also affect the registration info on line 1073. TH> Apple's 4 suggestions (which I've labeled a thru d) are that a Printer implementation MAY vary the spooling strategy based on the document format. For example, a document format that might have backward references would require the Printer to spool, while one that cannot, the Printer might stream. Therefore, even though there is no way for the client to dictate to the Printer which strategy to use, since there isn't a Job Template attribute to recommend/require the spooling strategy (unless we want to add one), the Printer could support more than one value of "job-spooling-supported", depending on the document format(s) of the document(s) in the submitted job. I've taken a stab at clarifying that "job-spooling-supported" can depend on the document format supplied in the job, as suggested by Apple comment #7: 10.5 job-spooling-supported (1setOf[th1] <> type2 keyword)[th2] <> This attribute indicates whether or not jobs are spooled before the document data is interpreted (RIPped). In other words, this attribute indicates when jobs are processed by the Printer with respect to when the Printer receives and returns responses to Job Creation requests (i.e., Print-Job, Print-URI), receives and returns responses to Document Creation requests (i.e., Send-Document and Send-Uri requests) and "receives" or "fetches" such document data. The value of this attribute returned in a Get-Printer-Attributes response MAY depend on the "document-format" [th3] <> attribute supplied in the Get-Printer-Attributes request (see [RFC2911] Section 3.2.5.1 and 6.2).[th4] <> [th5] <> If the Printer supports this attribute, the value supported depend on implementation. If the Printer does not support this attribute, then the spooling behavior is implementation dependent. The Get-Printer-Supported-Values operation (see description in [RFC3380]) returns a '1setOf type2 keyword' so that all possible values that the implementation is capable of supporting are indicated.[th6] <> The standard keyword values are: Keyword Description 'spool' The Printer starts processing a job until the Printer has (1) accepted and responded to the Job Creation request and all Document Creation requests (for a multi-document job) and (2) has "received" or "fetched" all document data for the job, i.e., spool rather than stream. 'stream' The Printer starts processing a job (1) before the Printer has accepted all Document Creation requests and (2) before the Printer has "received" or "fetched" all document data, i.e., stream rather than spool 'automatic' The Printer chooses whether to process a job before or after the Printer has accepted all Document Creation requests and has "received" or "fetched" all document data, i.e., the Printer MAY spool and/or stream depending on policy and other factors, such as the size of the job, and the document format[th7] <> , including a combination of spooling and streaming. TH> However, I don't think we need to get into the details about Get-Printer-Attributes vs. Get-Printer-Attributes-Supported, since it is now clear that multiple values MAY be returned in either or both operations, depending on implementation. [RFC2911] Section 3.2.5.1 Get-Printer-Attributes goes into gory detail about attributes whose values are affected by "document-format" supplied in the Get-Printer-Attributes requests: "document-format" (mimeMediaType): The client OPTIONALLY supplies this attribute. The Printer object MUST support this attribute. This attribute is useful for a Printer object to determine the set of supported attribute values that relate to the requested document format. The Printer object MUST return the attributes and values that it uses to validate a job on a create or Validate-Job operation in which this document format is supplied. The Printer object SHOULD return only (1) those attributes that are supported for the specified format and (2) the attribute values that are supported for the specified document format. By specifying the document format, the client can get the Printer object to eliminate the attributes and values that are not supported for a specific document format. For example, a Printer object might have multiple interpreters to support both 'application/postscript' (for PostScript) and 'text/plain' (for text) documents. However, for only one of those interpreters might the Printer object be able to support "number-up" with values of '1', '2', and '4'. For the other interpreter it might be able to only support "number-up" with a value of '1'. Thus a client can use the Get-Printer-Attributes operation to obtain the attributes and values that will be used to accept/reject a create job operation. If the Printer object does not distinguish between different sets of supported values for each different document format when validating jobs in the create and Validate-Job operations, it MUST NOT distinguish between different document formats in the Get-Printer-Attributes operation. If the Printer object does distinguish between different sets of supported values for each different document format specified by the client, this specialization applies only to the following Printer object attributes: - Printer attributes that are Job Template attributes ("xxx-default" "xxx-supported", and "xxx-ready" in the Table in Section 4.2), - "pdl-override-supported", - "compression-supported", - "job-k-octets-supported", - "job-impressions-supported, - "job-media-sheets-supported" - "printer-driver-installer", - "color-supported", and - "reference-uri-schemes-supported" The values of all other Printer object attributes (including "document-format-supported") remain invariant with respect to the client supplied document format (except for new Printer description attribute as registered according to section 6.3). If the client omits this "document-format" operation attribute, the Printer object MUST respond as if the attribute had been supplied with the value of the Printer object's "document-format-default" attribute. It is RECOMMENDED that the client always supply a value for "document-format", since the Printer object's "document-format-default" may be 'application/octet-stream', in which case the returned attributes and values are for the union of the document formats that the Printer can automatically sense. For more details, see the description of the 'mimeMediaType' attribute syntax in section 4.1.9. If the client supplies a value for the "document-format" Operation attribute that is not supported by the Printer, i.e., is not among the values of the Printer object's "document-format-supported" attribute, the Printer object MUST reject the operation and return the 'client-error-document-format-not-supported' status code. ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _____ ISSUE: OK to add "1setOf" to "job-spooling-supported" as suggested by Apple's IPP WG Last Call Comment #7a? ISSUE: Comment made during the June 21 telecon: Add: "job-spooling-configured" (type2 keyword). But there is no mention in the minutes. Also with the Apple's Comment #7 suggestion that the spooling strategy could depend on the document-format in the submitted job, configuring for a single strategy wouldn't work. OK NOT to add "job-spooling-configured"? ISSUE: OK to add that the spooling used MAY depend on the document format as suggested by Apple's Comment #7 and allowed by [RFC2911] Section 3.2.5.1 as long as explicitly called out in the definition as indicated in [RFC2911] Section 6.2? ISSUE: OK to add that the spooling used MAY depend on the document format as suggested by Apple's Comment #7c, but refer to RFC 2911 Section 3.2.5.1 for the details about what is returned in Get-Printer-Attributes response depending on whether or not the client supplies "document-format: in the request? ISSUE: OK to remove this sentence as suggested by Apple's Comment #7b? ISSUE: OK to remove this paragraph as suggested by Apple's Comment 7c? ISSUE: OK to add that "document-format" could be an example that causes the Printer to vary the spooling strategy as suggested by Apple's Comment #7c? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_NextPart_000_00B1_01CB26AA.F4925E40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since email with attachments is blocke= d by the IPP reflector (even small ones), the attachment that I refer to below is also posted at:

 

ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-= JPS2-comments-4-thru-7.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-= JPS2-comments-4-thru-7.doc

 

This is RESEND 2 or= 2 for tomorrow’s IPP WG telecon, July 19.

 

Tom

 

 


From: Tom Hast= ings [mailto:tom.hastings@verizon.net]
Sent: Sunday, July 18, 2010 = 17:36
To: ipp@pwg.org; 'Michael R Sweet'; 'Paul Tykodi'; 'Ira McDonald'
Cc: 'Tom Hastings'
Subject: Toward resolving Ap= ple's IPP WG Last Call JPS2 comments 4 thru 7 - for Mon, Jul 19, IPP WG telecon

 

For the IPP WG tele= con, tomorrow, Monday, July 19, here is 2 or 2 input for the agenda topic:<= /o:p>

 

Since the font, highlighting, and indentation will be smashed when this mail message is tur= ned to plain text, I’ve attached a 63 KB .pdf which is much more readable, complete with line numbers to make it easier to discuss at the telecon.&nbs= p; I’ve also down loaded v30 of JPS2 .doc and .pdf (without hot links).  If Pete Zehler can update the .pdf that would be good, but he= may be on vacation.  So the following 6 documents are in the wd sub-folder= for the IPP WG telecon tomorrow, Monday, July 19:

 

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v30-20100718.p= df

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v30-20100718.d= oc

 

and the following t= wo documents that attempt to resolve Apple’s IPP WG Last Call comments (= same as I attached to this and the previous email):

 

ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-= JPS2-comments-4-thru-7.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/wd/Toward-resolving-Apples-= JPS2-comments-4-thru-7.doc

 

and:

 

ftp://ftp.pwg.org/pub/pwg/ipp/wd/T= oward-resolving-Apples-JSP2-comment-on-units-for-font-size-requested.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/wd/T= oward-resolving-Apples-JSP2-comment-on-units-for-font-size-requested.doc

 

(Yes, the S and P a= re switched in this last file name by mistake).

 

 

For the IPP WG tele= con, tomorrow, Monday, July 19, here is 2 or 2 input for the agenda topic:<= /o:p>

 

> (5) Status of IPP WG Last Call on IPP JPS2 = (Tom) - ends Monday 12 July

>  -

> ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v28-20100606-cl=

> ean.pdf

>   (ended Monday 12 July 2010)

> 

> (6) Next Steps

>  - IPP WG - Monday 26 July<= /span>

>  - IPP JPS2 into PWG Last Call?

 

File: Toward-resolving-Apples-JPS2-comments-4-thru-7.doc=

 =

From: ipp-bounces@pwg.org on behalf of Michael Sweet<= /st1:PersonName> [msweet@apple.com]
Sent: Monday, June 21, 2010 = 12:58
To: ipp@pwg.org
Subject: [IPP] Apple has rev= iewed the JPS2 specification and has comments

Attachments: ATT02705.txt

Comments:

 

1. The document date is wrong in the headers.

TH> Updated to today's date.

 

2. The "font-size-requested" attribute uses points as the units, however it should probably use a higher-precision unit (at least decipoints, or 1/720th of an inch) to avoid issues with getting common fixed-width font spacing right (e.g. 17 characters per inch with a standard Courier font would need a point size of 5.293...) [And apologies for the la= te notice on this - I haven't read through the older material in a while...]

TH> See separate email thread and attached .pdf more readable version for this issue and possible alternatives for resolution.

 

3. Question: do we need the PWG process reference at the beginning = of section 3? Do we need to explain why we organize our standards documents th= is way?

TH> Need IPP WG input here.

 

4. On line 372 of the -rev document you say "these features are useful in the "light production printing" environments, but we do= n't define what "light production printing" is, just "production printing".

TH> Just remove the clause entirely= , OK?

 

5. Line 427 - I think Close-Job is Owner + Operator, per RFC 2911's description of Send-Document and the Close-Job references in JPS2:

 

   Access Rights: The authenticated user = (see section 8.3) performing

   this operation must either be the job owner= (as determined in the

   Create-Job operation) or an operator or administrator of the Printer

   object (see Sections 1 and 8.5).  Otherwise, the IPP object MUST

   reject the operation and return: 'client-error-forbidden', 'client-

   error-not-authenticated', or 'client-error-not-authorized' as

   appropriate.

TH> Added:

Access Rights: The authenticated user = (see [RFC2911] section 8.3) performing this operation must either be the job own= er (as determined in the Create-Job operation) or an operator or administrator= of the Printer object (see [RFC2911] Sections 1 and 8.5).  Otherwise, the= IPP object MUST reject the operation and return: 'client-error-forbidden', 'client-error-not-authenticated', or 'client-error-not-authorized' as appropriate.  

 

6. Line 567-568: The definition says up to 255 characters for job-password and job-password-supported, but here we say 127 octets.

TH> Fixed

 

7. a: Section 10.5 (job-spooling-supported) - shouldn't this be a 1setOf?

 

b: Also, lines 580-581 basically says that the values are implementation-dependent regardless of whether the attribute is supported or not. :)

 

c: Based on the current description I think we need to specify when= the value is 1setOf and when it is not (i.e. a Get-Printer-Attributes request w= ith a document-format would return the value for that format, otherwise you'd g= et the value for the default format or a 1setOf if the answer can't be made de= finitively without a format...)

 

d: This will also affect the registration info on line 1073.

 

TH> Apple's 4 suggestions (which I've labeled a thru d) are that= a Printer implementation MAY vary the spooling strategy based on the document format.  For example, a document format that might have backward references would require the Printer to spool, while one that cannot, the Printer might stream.  Therefore, even though there is no way for the client to dictate to the Printer which strategy to use, since there isn't a= Job Template attribute to recommend/require the spooling strategy (unless we wa= nt to add one), the Printer could support more than one value of  "job-spooling-supported", depending on the document format(s) of = the document(s) in the submitted job.

 

I've taken a stab at clarifying that "job-spooling-supported&q= uot; can depend on the document format supplied in the job, as suggested by Apple comment #7:

 

10.5    job-spo= oling-supported  (1setOf[th1] = <= font size=3D1 color=3Dred face=3DArial>  type2 keyword= )[th2]  

This attribute indicates whether or not jobs are spooled before the document data is interpreted (RIPped).  In other wo= rds, this attribute indicates when jobs are processed by the Printer with respec= t to when the Printer receives and returns responses to Job Creation requests (i= .e., Print-Job, Print-URI), receives and returns responses to Document Creation requests (i.e., Send-Document and Send-Uri requests) and "receives&quo= t; or "fetches" such document data.

= The value of this attribute returned i= n a Get-Printer-Attributes response MAY depend on the "document-format&quo= t; [th3]  <= /u>attribute supplied in the Get-Printer-Attributes request (see [RFC2911] Section 3.2.5.1 and 6.2).[th4]  <= /u>

[th5]  If the Printer supports this attribute, the value supp= orted depend on implementation.  If the Printer does not support this attribute, then= the spooling behavior is implementation dependent.

The Get-Printer-Supported-Values oper= ation (see description in [RFC3380]) returns a '1setOf type2 keyword' so that all possible values that the implementation is capable of supporting are indica= ted.[th6]  =

The standard keyword values are:

Keyword

 

Description

'spool'

 

The Printer starts processing a job until the Printer has (1) accepted and re= sponded to the Job Creation request and all Document Creation requests (for a multi-document job) and (2) has "received" or "fetched&quo= t; all document data for the job, i.e., spool rather than stream.=

'stream'

 

The Printer starts processing a job (1) before the Printer has accepted all Document Creation requests and (2) before the Printer has "received" or "fetched" all document data, i.e., stre= am rather than spool

'automatic'

 

The Printer chooses whether to process a job before or after the Printer has accepted= all Document Creation requests and has "received" or "fetched" all document data, i.e., the Printer MAY spool and/or stream depending on policy and other factors, such as the size of the job= , and the document format= [th7]  , including a combination of spooling and streaming.

 

 

TH> However, I don't think we need to get into the details about Get-Printer-Attributes vs. Get-Printer-Attributes-Supported, since it is no= w clear that multiple values MAY be returned in either or both operations, dependin= g on implementation.  [RFC2911] Section 3.2.5.1 Get-Printer-Attributes goes into gory detail about attributes whose values are affected by "document-format" supplied in the Get-Printer-Attributes requests= :

 

"document-format" (mimeMediaType):

The client OPTIONALLY supplies this attribute.&n= bsp; The Printer object MUST support this attribute.  This attribute is useful for a Printer object to determine the set of supported attribute values that relate to the requested document format.  The Printer object MUST return the attributes and values that it uses to validate a job on a create or Validate-Job operation in which this document format is supplied. The Printer object SHOULD return only (1) those attributes that are supported f= or the specified format and (2) the attribute values that are supported for the specified document format.  By specifying the document format, the cli= ent can get the Printer object to eliminate the attributes and values that are = not supported for a specific document format.  For example, a Printer obje= ct might have multiple interpreters to support both 'application/postscript' (= for PostScript) and 'text/plain' (for text) documents.  However, for only = one of those interpreters might the Printer object be able to support "number-up" with values of '1', '2', and '4'.  For the other interpreter it might be able to only support "number-up" with a v= alue of '1'. Thus a client can use the Get-Printer-Attributes operation to obtain the attributes and values that will be used to accept/reject a create job operation.

 

If the Printer object does not distinguish betwe= en different sets of supported values for each different document format when validating jobs in the create and Validate-Job operations, it MUST NOT distinguish between differe= nt document formats in the Get-Printer-Attributes operation. If the Printer ob= ject does distinguish between different sets of supported values for each differ= ent document format specified by the client, this specialization applies only to the following Printer object attributes:

 

<= font size=3D3 face=3D"Times New Roman">- Printer attributes that are Job Template attributes ("xxx-default" "xxx-supported", and "xxx-ready" in the Table in Section 4.2),

<= font size=3D3 face=3D"Times New Roman">- "pdl-override-supported",

<= font size=3D3 face=3D"Times New Roman">- "= compression-supported",

<= font size=3D3 face=3D"Times New Roman">- "job-k-octets-supported",

<= font size=3D3 face=3D"Times New Roman">- "job-impressions-supported,

<= font size=3D3 face=3D"Times New Roman">- "job-media-sheets-supported"

<= font size=3D3 face=3D"Times New Roman">- "printer-driver-installer",

<= font size=3D3 face=3D"Times New Roman">- "color-supported", and

<= font size=3D3 face=3D"Times New Roman">- "reference-uri-schemes-supported"

<= font size=3D3 face=3D"Times New Roman">&nb= sp;

The values of all other Printer object attribute= s (including "document-format-supported") remain invariant with respect to the client supplied document format (except for new Printer description attribu= te as registered according to section 6.3).

 

If the client omits this "document-format&q= uot; operation attribute, the Printer object MUST respond as if the attribute had been supplied with the value of the Printer object's "document-format-default" attribute.  It is RECOMME= NDED that the client always supply a value for "document-format", since the Printer object's "document-format-default" may be 'application/octet-stream', in which case the returned attributes and values are for the union of the document formats that the Printer can automatically sense.  For more details, see the description of the 'mimeMediaType' attribute syntax in section 4.1.9.

 

If the client supplies a value for the "document-format" Operation attribute that is not supported by the Printer, i.e., is not among the values of the Printer object's "document-format-supported" attribute, the Printer object MUST reject the operation and return= the 'client-error-document-format-not-supported' status code.=

 

 

_______________________________________________________= _________________

Michael Sweet<= /st1:PersonName>, Senior Printing System E= ngineer, PWG Chair

 

 =

 


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

 

 

 


 ISSUE: OK= to add "1setOf" to "job-spooling-supported" as suggested by Apple's IPP WG Last Call Comment #7a?

 ISSUE: Co= mment made during the June 21 telecon:

 

Add: "job-spooling-configured" (type2 keyword)= .

 

But there is no mention in the minutes.

 

Also with the Apple's Comment #7 suggestion that the spooling strategy could depend on the document-format in the submitted job, configuring for a single strategy wouldn't work.

 

OK NOT to add "job-spooling-configured"?

 ISSUE: OK= to add that the spooling used MAY depend on the document format as suggested by Apple's Comment #7 and allowed by = [RFC2911] Section 3.2.5.1 as long as explicitly called out in the definition as indic= ated in [RFC2911] Section 6.2?

 ISSUE: OK= to add that the spooling used MAY depend on the document format as suggested by Apple's Comment #7c, but refer to = RFC 2911 Section 3.2.5.1 for the details about what is returned in Get-Printer-Attributes response depending on whether or not the client supp= lies "document-format: in the request?

 ISSUE: OK= to remove this sentence as suggested = by Apple's Comment #7b?

 ISSUE: OK= to remove this paragraph as suggested by Apple's Comment 7c?

 ISSUE: OK= to add that "document-format" could be an example that causes the Printe= r to vary the spooling strategy as suggested by Apple's Comment #7c?


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_NextPart_000_00B1_01CB26AA.F4925E40-- --===============1774729212== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1774729212==-- From ipp-bounces@pwg.org Mon Jul 19 04:51:38 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D6F3A68AF for ; Mon, 19 Jul 2010 04:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 JZG0UmqL7JLl for ; Mon, 19 Jul 2010 04:51:37 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 160863A6359 for ; Mon, 19 Jul 2010 04:51:37 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id D3E9179303; Mon, 19 Jul 2010 07:51:42 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from wvmler2.mail.xerox.com (wvmler2.mail.xerox.com [13.8.138.217]) by pwg.org (Postfix) with ESMTP id DB8B879302 for ; Mon, 19 Jul 2010 07:51:39 -0400 (EDT) Received: from wvmlir2.mail.xerox.com (wvmlir2.mail.xerox.com [13.147.8.222]) by wvmler2.mail.xerox.com (8.14.4/8.13.8) with ESMTP id o6JBpchP006549 for ; Mon, 19 Jul 2010 04:51:39 -0700 Received: from wvmlir2.mail.xerox.com (localhost [127.0.0.1]) by wvmlir2.mail.xerox.com (8.14.4/8.13.6) with ESMTP id o6JBpcep018714 for ; Mon, 19 Jul 2010 04:51:38 -0700 Received: from USA0300GW002.na.xerox.net (usa0300gw002.na.xerox.net [13.135.210.15]) by wvmlir2.mail.xerox.com (8.14.4/8.13.6) with ESMTP id o6JBpPrN018190 for ; Mon, 19 Jul 2010 04:51:37 -0700 X-XeroxINT-Source-Ip: 13.135.210.15 X-XeroxINT-Source-Name: usa0300gw002.na.xerox.net X-XeroxINT-Reported-Name: USA0300GW002.na.xerox.net Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA0300GW002.na.xerox.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 07:51:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jul 2010 04:51:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LiveMeeting information for 7/19 teleconference Thread-Index: AcsnOLZyX9djGqTCTCKf2+tqdM8IeA== From: "Zehler, Peter" To: X-OriginalArrivalTime: 19 Jul 2010 11:51:26.0722 (UTC) FILETIME=[B7E71E20:01CB2738] X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] LiveMeeting information for 7/19 teleconference X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0906524295==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: D3E9179303.A8ECE X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============0906524295== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2738.B7354835" This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2738.B7354835 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Attendee: Join the meeting. =20=20 >=20 First Time Users:=20 To save time before the meeting, check your system to make sure it is ready to use Microsoft Office Live Meeting.=20 Troubleshooting Unable to join the meeting? Follow these steps:=20 =20 1. Copy this address and paste it into your web browser:=20 https://www.livemeeting.com/cc/xerox/join=20 2. Copy and paste the required information:=20 Meeting ID: PwgIpp719=20 Entry Code: LetMeIn=20 Location: https://www.livemeeting.com/cc/xerox=20 =20 =20 =20 =20 =20 =20 Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@Xerox.com =20 Voice: (585) 265-8755 FAX: (585) 265-7441 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701=20 =20 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------_=_NextPart_001_01CB2738.B7354835 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Attendee:

Join the meeting.
<https://www.livemeeting.com/cc/xerox/join?id=3DPwgIpp7= 19&role=3Dattend&pw=3DLetMeIn>

First Time Users:
T= o save time before the meeting, check your system to make sure it is ready = to use Microsoft Office Live Meeting.
Troubleshooting
U= nable to join the meeting? Follow these steps:

 

1.      Copy this addr= ess and paste it into your web browser:
https://www.livemeeting.= com/cc/xerox/join

2.      Copy and paste= the required information:
M= eeting ID: PwgIpp719
E= ntry Code: LetMeIn
L= ocation: https://www.livemeeting.co= m/cc/xerox

 <= /span>

 

 

 

 

 =

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------_=_NextPart_001_01CB2738.B7354835-- --===============0906524295== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0906524295==-- From ipp-bounces@pwg.org Mon Jul 19 14:14:12 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6CA3A696F for ; Mon, 19 Jul 2010 14:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ga80gqvAKo-m for ; Mon, 19 Jul 2010 14:14:10 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id B89F53A693B for ; Mon, 19 Jul 2010 14:14:10 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 9B0F279306; Mon, 19 Jul 2010 17:14:20 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by pwg.org (Postfix) with ESMTP id 6A35979300 for ; Mon, 19 Jul 2010 17:14:15 -0400 (EDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 2610C9E68BE9 for ; Mon, 19 Jul 2010 14:14:15 -0700 (PDT) X-AuditID: 11807134-b7b53ae000005755-5c-4c44c0261335 Received: from msweet.apple.com (msweet.apple.com [17.197.41.43]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id B1.92.22357.720C44C4; Mon, 19 Jul 2010 14:14:15 -0700 (PDT) From: Michael Sweet Date: Mon, 19 Jul 2010 14:14:14 -0700 To: ipp@pwg.org Message-Id: <3785E51A-F70F-4C21-9B44-08FF607FD91D@apple.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAQAAAZE= X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Minutes posted for today's IPP telecon X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0018687586==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 9B0F279306.A8FBC X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0018687586== Content-Type: multipart/alternative; boundary=Apple-Mail-1-619144270 --Apple-Mail-1-619144270 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii All, I've posted the minutes from today's IPP teleconference call at: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20100719.pdf Please let me know if I've missed anything... ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Apple-Mail-1-619144270 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii All,

I'= ve posted the minutes from today's IPP teleconference call at:

Please= let me know if I've missed anything...

___________________= _____________________________________________________
Michael Swe= et, Senior Printing System Engineer, PWG Chair





--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Apple-Mail-1-619144270-- --===============0018687586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0018687586==-- From detractnk718@sloth.org Wed Jul 21 02:02:50 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1851B3A6A41; Wed, 21 Jul 2010 02:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -39.102 X-Spam-Level: X-Spam-Status: No, score=-39.102 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FORGED_AMAZON=3, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_RHS_DOB=1.083, 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 AXOYyKMzbSPw; Wed, 21 Jul 2010 02:02:49 -0700 (PDT) Received: from 83-244-217-76.cust-83.exponential-e.net (83-244-217-66.cust-83.exponential-e.net [83.244.217.66]) by core3.amsl.com (Postfix) with ESMTP id 2E71C3A69FF; Wed, 21 Jul 2010 02:02:45 -0700 (PDT) Message-ID: <000d01cb28b3$83b8bb50$6400a8c0@detractnk718> From: "Amazon.com" To: Subject: Your Amazon.com Order (D42-2654216-8434467) Date: Wed, 21 Jul 2010 10:02:58 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_002_000F_01CB28B3.83B8BB50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_002_000F_01CB28B3.83B8BB50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Thanks for your order, ipdvb-archive@megatron.ietf.org Did you know you can view and edit your orders online, 24 hours= a=20 day? Visit Your=20 Account=2E =20 =20 =20 =20 Order=20 Information: =20 =20 =20 =20 E-mail Address:  ipdvb-archive@megatron.ietf.org =20 =20 =20 =20 =20 =20 =20 =20 Order Grand Total: $=20 76.99=20 =20 =20 Earn 3% rewards=20 on your Amazon.com orders with the Amazon Visa Card. Lear= n More=20 =20 =20 =20 =20 =20 Order=20 Summary: =20 =20 =20 Details: =20 =20 =20 Order=20 #: D94-8751828-4815700 =20 Subtotal=20 of items:=20 $ 65.99=20 =20 =20 =20 ------ =20 Total=20 before tax:=20 $ 46.99=20 =20 =20 Sales=20 Tax:=20 $ 0.00=20 =20 =20 =20 ------ =20 Total=20 for this Order:=20 $=20 94.99 The following=20 item was ordered:=20 =20 =20 =20 =20 Click here and see=20 items, Price: $ 55.99By: Click here Sold by:=20 Amazon Digital Services, Inc=2E =20 =20 =20 The charge for this order will appear on your credit card=20 statement from the merchant 'AMZN Payment Services.' You can review your orders in Your Account. If you've=20 explored the links on that page but still have a question, plea= se=20 visit our online Help=20 Department=2E Please note: This e-mail was sent from a notification-only=20 address that cannot accept incoming e-mail. Please do not reply= to=20 this message=2E Thanks again for shopping with us=2E Amazon.comEarth's=20 Biggest Selection =20 Prefer not to receive HTML mail? Click=20 here ------=_NextPart_002_000F_01CB28B3.83B8BB50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"Amazon.com=20 3D"your
------=_NextPart_002_000F_01CB28B3.83B8BB50-- From nerdiestyn955@schwacke.ru Wed Jul 21 05:31:24 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761513A69CC; Wed, 21 Jul 2010 05:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.572 X-Spam-Level: X-Spam-Status: No, score=-22.572 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FORGED_AMAZON=3, 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 zSHdt0vlKaQK; Wed, 21 Jul 2010 05:31:19 -0700 (PDT) Received: from host86-153-10-235.range86-153.btcentralplus.com (host86-153-10-235.range86-153.btcentralplus.com [86.153.10.235]) by core3.amsl.com (Postfix) with ESMTP id 810A43A6A13; Wed, 21 Jul 2010 05:31:13 -0700 (PDT) Message-ID: <000d01cb28d0$8a2c2a90$6400a8c0@nerdiestyn955> From: "Amazon.com" To: Subject: Your Amazon.com Order (D24-6238989-6164115) Date: Wed, 21 Jul 2010 13:30:44 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_002_000F_01CB28D0.8A2C2A90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_002_000F_01CB28D0.8A2C2A90 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Thanks for your order, issll-archive@lists.ietf.org Did you know you can view and edit your orders online, 24 hours= a=20 day? Visit Your=20 Account=2E =20 =20 =20 =20 Order=20 Information: =20 =20 =20 =20 E-mail Address:  issll-archive@lists.ietf.org =20 =20 =20 =20 =20 =20 =20 =20 Order Grand Total: $=20 49.99=20 =20 =20 Earn 3% rewards=20 on your Amazon.com orders with the Amazon Visa Card. Lear= n More=20 =20 =20 =20 =20 =20 Order=20 Summary: =20 =20 =20 Details: =20 =20 =20 Order=20 #: D83-8537460-9836165 =20 Subtotal=20 of items:=20 $ 20.99=20 =20 =20 =20 ------ =20 Total=20 before tax:=20 $ 65.99=20 =20 =20 Sales=20 Tax:=20 $ 0.00=20 =20 =20 =20 ------ =20 Total=20 for this Order:=20 $=20 92.99 The following=20 item was ordered:=20 =20 =20 =20 =20 Click here and see=20 items, Price: $ 86.99By: Click here Sold by:=20 Amazon Digital Services, Inc=2E =20 =20 =20 The charge for this order will appear on your credit card=20 statement from the merchant 'AMZN Payment Services.' You can review your orders in Your Account. If you've=20 explored the links on that page but still have a question, plea= se=20 visit our online Help=20 Department=2E Please note: This e-mail was sent from a notification-only=20 address that cannot accept incoming e-mail. Please do not reply= to=20 this message=2E Thanks again for shopping with us=2E Amazon.comEarth's=20 Biggest Selection =20 Prefer not to receive HTML mail? Click=20 here ------=_NextPart_002_000F_01CB28D0.8A2C2A90 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thanks for your order, ipdvb-archive@megatron.ietf.org

Did you know you can view and edit your orders online, 24 ho= urs a=20 day? Visit Your= =20 Account.

Order=20 Information:

E-mail Address:  ipdvb-archive@megatron.ie= tf.org

Order Grand T= otal: $=20 76.99
Earn 3% = rewards=20 on your Amazon.com orders with the Amazon Visa Card. Learn More=20

Order=20 Summary:
Details:
<= B>Order=20 #: D94-8751828-= 4815700
S= ubtotal=20 of items: $ 65.99=20
------
T= otal=20 before tax: $ 46.99=20
S= ales=20 Tax: $ 0.00=20
------
<= B>Total=20 for this Order: $=20 94.99

The follow= ing=20 item was ordered:=20
Click here a= nd see=20 items, Price: $ 55.99
By: Click here
Sold by:=20 Amazon Digital Services, Inc.


The charge for this order will appear on your credit card=20 statement from the merchant 'AMZN Payment Services.'

You can review your orders in Your Account. = If you've=20 explored the links on that page but still have a question, plea= se=20 visit our online Help=20 Department.

Please note: This e-mail was sent from a notification-only=20 address that cannot accept incoming e-mail. Please do not reply= to=20 this message.

Thanks again for shopping with us.

Amazon.com=
Earth's=20 Biggest Selection

3D"unsubscribe=20 Prefer not to receive HTML mail? Click=20 here

=20 3D"your
------=_NextPart_002_000F_01CB28D0.8A2C2A90-- From ipp-bounces@pwg.org Thu Jul 22 13:17:28 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3491A3A67CC for ; Thu, 22 Jul 2010 13:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.109 X-Spam-Level: * X-Spam-Status: No, score=1.109 tagged_above=-999 required=5 tests=[AWL=-1.294, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, MIME_HTML_MOSTLY=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 GIFrAsu5qLi2 for ; Thu, 22 Jul 2010 13:17:13 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id D233C3A68F1 for ; Thu, 22 Jul 2010 13:17:12 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 8298F79326; Thu, 22 Jul 2010 16:16:13 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from wbmler6.mail.xerox.com (wbmler6.mail.xerox.com [13.13.138.231]) by pwg.org (Postfix) with ESMTP id 38D927947D; Thu, 22 Jul 2010 14:48:36 -0400 (EDT) Received: from wbmlir1.mail.xerox.com (wbmlir1.mail.xerox.com [13.131.8.221]) by wbmler6.mail.xerox.com (8.14.4/8.13.8) with ESMTP id o6MImTjJ006609; Thu, 22 Jul 2010 14:48:29 -0400 Received: from wbmlir1.mail.xerox.com (localhost [127.0.0.1]) by wbmlir1.mail.xerox.com (8.14.4/8.13.6) with ESMTP id o6MImSFV010941; Thu, 22 Jul 2010 14:48:28 -0400 Received: from USA7061GW002.na.xerox.net (usa7061gw002.na.xerox.net [13.151.210.15]) by wbmlir1.mail.xerox.com (8.14.4/8.13.6) with ESMTP id o6MImLxj010476; Thu, 22 Jul 2010 14:48:28 -0400 X-XeroxINT-Source-Ip: 13.151.210.15 X-XeroxINT-Source-Name: usa7061gw002.na.xerox.net X-XeroxINT-Reported-Name: USA7061GW002.na.xerox.net Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA7061GW002.na.xerox.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 11:48:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jul 2010 11:48:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Attributes needed for Cloud Printing and definition inconsistencies Thread-Index: AcspxRRVo4ExmexOQvqGozc+7BuVQQ== From: "Zehler, Peter" To: , X-OriginalArrivalTime: 22 Jul 2010 18:48:27.0951 (UTC) FILETIME=[78F4EBF0:01CB29CE] X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] Attributes needed for Cloud Printing and definition inconsistencies X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1990111138==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 8298F79326.AB58C X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============1990111138== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB29CE.78D5BF7B" This is a multi-part message in MIME format. ------_=_NextPart_001_01CB29CE.78D5BF7B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Job Identifiers: *existing* job-id (SM: JobId): The identifier for a job with a local scope. That is the ID is unique within the service. The ID may be reused in other instance of a Printer (i.e. Print Service) or for jobs in other types of services (e.g. Copy Service). Datatype: abstract:int32, IPP:integer, SM:xs:int =20 *new* job-uuid (SM:JobUuid): The identifier for a job with a global scope. The identifier is unique for a Job across all service instances of any service type. The UUID URN namespace is specified in rfc4122. The format used for "job-uuid" is the string representation of a UUID as a URN. An example is "urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3". The version (aka subtype) used is implementation specific. Version 1 (i.e. time based) is recommended. Datatype: abstract:char[64], IPP:uri MaxLength=3D64, SM:xs:anyURI maxLen=3D64 =20 Note: I do not believe the IPP attribute "job-uri" is applicable as a globally unique identifier. 1) RFC2911 states "Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.". All uses of the uri syntax is really a URL syntax. 2) URL implies not only a specific protocol binding but also a location. 3) Locations can be specified using an IP address that need not be locally unique (e.g. 192.168.1.1, localhost)=20 4) Regarding the "job-uri" RFC2911 further states that "This URI is then used by clients as the target for subsequent Job operations.". The globally unique identifier for a job should not specify a transport endpoint for a specific protocol.=20=20=20 5) The globally unique identifier for a Job, Printer or Service should be a URN. It should be protocol independent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping. 6) The globally unique identifier for a Job, Printer or Service should require no central authority to administrate them. Generation of a unique identifier should be simple from an administrative point of view and preferably automated. =20 Note: Both the local and global identifiers should be mandated. For legacy protocol mappings (e.g. IPP 1.1, WS-Print, LPR) the local identifier MUST still be maintained. It is possible to use the time_low portion of the Timestamp in the version 1 UUID as the local identifier. The implementation may then keep only the 128 bit local representation of the UUID and use it to create the appropriate protocol values. =20 Printer Identifiers: *existing (Service Monitoring MIB)* applIndex (SM: Id i.e. PrinterId): The service identifier with a local scope. That is the ID is unique across the service instances collocated on a host. Datatype: abstract:int32, MIB:integer, SM:xs:int =20 *new* printer-uuid (SM:ServiceUuid): The identifier for a Printer with a global scope. The identifier is unique across all service instances of any service type. The UUID URN namespace is specified in rfc4122. The format used for "job-uuid" is the string representation of a UUID as a URN. An example is "urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3". The version (aka subtype) used is implementation specific. Version 1 (i.e. time based) is recommended. Datatype: abstract:char[64], IPP:uri, SM:xs:anyURI maxLen=3D64 =20 Note: I do not believe the IPP attribute "printer-uri" is applicable as a globally unique identifier.=20=20 1) RFC2911 states "Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.". All uses of the uri syntax is really a URL syntax. 2) URL implies not only a specific protocol binding but also a location. 3) Locations can be specified using an IP address that need not be locally unique (e.g. 192.168.1.1, localhost)=20 4) The printer may have multiple "printer-uri" values as enumerated in the "printer-uris-supported" attribute. There should be only a single identifier for a printer. 5) The globally unique identifier for a Job, Printer or Service should be a URN. It should be protocol independent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping. 6) The globally unique identifier for a Job, Printer or Service should require no central authority to administrate them. Generation of a unique identifier should be simple from an administrative point of view and preferably automated. =20 =20 Note: The local instance id in the MIB and SM are artifacts of the model's data binding and are insufficient for use as an identifier. IPP's printer-uri, the URL for Web Service bindings (e.g. WS-Print) and the IP address for legacy protocols such as LPR and Port 9100 are also insufficient. They need not be globally unique. Nonroutable IP addresses may be used.=20=20 =20 Printer Location: *existing* printer-location (SM: ServiceLocation): Identifies the location of the device that this Printer represents. (Example: Pete's Office) This is helpful for a human but is pretty much useless for geolocation since the content is implementation specific. Datatype: abstract:char[127], IPP:string MaxLength=3D127, SM:xs:int =20 *new* printer-geo-location (SM:ServiceGeoLocation): This identifies the location of the associated device using the World Geodetic System 1984(WGS84). The means for expressing the location information is the same as used in DNS (rfc1876) Datatype: abstract:class, IPP:collection, SM:sequence =20 *new* size (SM:Size): Diameter of the bounding sphere containing the device expressed in centimeters. Datatype: abstract: int32, IPP:integer, SM:xs:int =20 *new* horizontal-precision (SM: HorizontalPrecision): The horizontal precision expressed as the diameter of the "circle of error" (i.e. twice the +- error value) The units are centimeters. Datatype: abstract: int32, IPP:integer, SM:xs:int =20 *new* vertical-precision (SM: VerticalPrecision): The vertical precision expressed as the diameter of the "circle of error" (i.e. twice the +- error value) The units are centimeters. Datatype: abstract:integer, IPP: int32, SM:xs:int =20 *new* latitude (SM:Latitude): The latitude of the center of the sphere described by the size attribute. Expressed in thousandths of a second of arc. The value 2147483648 (231) represents the equator. Values above that are north and below are south. Datatype: abstract: int32, IPP:integer, SM:xs:int =20 *new* longitude (SM:Latitude): The longitude of the center of the sphere described by the size attribute. Expressed in thousandths of a second of arc. The value 2147483648 (231) represents the prime meridian. Values above that are east and below are south. The value is rounded away from the prime meridian Datatype: abstract: int32, IPP:integer, SM:xs:int =20 *new* altitude (SM:Altitude): The altitude of the center of the sphere described by the size attribute. Expressed in centimeters from a base of 100,000m below the reference spheroid used by GPS [WGS 84]. Altitude above (or below) sea level may be used as an approximation of altitude relative to the [WGS 84] spheroid, though due to the Earth's surface not being a perfect spheroid, there will be differences. Datatype: abstract: int32, IPP:integer, SM:xs:int =20 Note: There is disagreement on the semantics for all the attributes between what is posted on and what I have in the definition above. I took the definition directly from rfc1876 (I think). See included text from rfc1876 and the location example below.=20=20 =20 =20 =20 Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@Xerox.com =20 Voice: (585) 265-8755 FAX: (585) 265-7441 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701=20 =20 =20 =46rom rfc1876 section 2 =20 =20 SIZE The diameter of a sphere enclosing the described entity, in centimeters, expressed as a pair of four-bit unsigned integers, each ranging from zero to nine, with the most significant four bits representing the base and the second number representing the power of ten by which to multiply the base. This allows sizes from 0e0 (<1cm) to 9e9 (90,000km) to be expressed. This representation was chosen such that the hexadecimal representation can be read by eye; 0x15 =3D 1e5. Four-bit values greater than 9 are undefined, as are values with a base of zero and a non-zero exponent. =20 Since 20000000m (represented by the value 0x29) is greater than the equatorial diameter of the WGS 84 ellipsoid (12756274m), it is therefore suitable for use as a "worldwide" size. =20 HORIZ PRE The horizontal precision of the data, in centimeters, expressed using the same representation as SIZE. This is the diameter of the horizontal "circle of error", rather than a "plus or minus" value. (This was chosen to match the interpretation of SIZE; to get a "plus or minus" value, divide by 2.) =20 VERT PRE The vertical precision of the data, in centimeters, expressed using the sane representation as for SIZE. This is the total potential vertical error, rather than a "plus or minus" value. (This was chosen to match the interpretation of SIZE; to get a "plus or minus" value, divide by 2.) Note that if altitude above or below sea level is used as an approximation for altitude relative to the [WGS 84] ellipsoid, the precision value should be adjusted. =20 LATITUDE The latitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandths of a second of arc. 2^31 represents the equator; numbers above that are north latitude. =20 LONGITUDE The longitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandths of a second of arc, rounded away from the prime meridian. 2^31 represents the prime meridian; numbers above that are east longitude. =20 ALTITUDE The altitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in centimeters, from a base of 100,000m below the [WGS 84] reference spheroid used by GPS (semimajor axis a=3D6378137.0, reciprocal flattening rf=3D298.257223563). Altitude above (or below) sea level may be used as an approximation of altitude relative to the the [WGS 84] spheroid, though due to the Earth's surface not being a perfect spheroid, there will be differences. (For example, the geoid (which sea level approximates) for the continental US ranges from 10 meters to 50 meters below the [WGS 84] spheroid. Adjustments to ALTITUDE and/or VERT PRE will be necessary in most cases. The Defense Mapping Agency publishes geoid height values relative to the [WGS 84] ellipsoid. =20 =20 =20 =20 =20 =20 =20 2-Dimmensional Location of my office printer Google Map URL: http://maps.google.com/maps?f=3Dq&source=3Ds_q&hl=3Den&geocode=3D&q=3D800+p= hillips +rd+webster+ny+14580&sll=3D37.0625,-95.677068&sspn=3D62.226996,106.962891&ie =3DUTF8&hq=3D&hnear=3D800+Phillips+Rd,+Webster,+Monroe,+New+York+14580&ll= =3D43.2 20973,-77.417162&spn=3D0.001781,0.003264&t=3Dh&z=3D19=20 Location representations: Decimal Degrees (WGS84) Latitude Longitude=20 43.220973 -77.417162=20 Degrees, Minutes & Seconds Latitude Longitude=20 N43 13 15 W77 25 01=20 GPS Latitude Longitude=20 N 43 13.258 W 77 25.030=20 UTM X Y=20 18N 303685 4788191=20 =20 My office elevation: 12800 centimeters (419 feet) above sea level Size of Printer: 91 centimeter (3 feet) Margin of error 183 centimeter (6 feet) =20 PrinterGeoLocation (RFC1876) Size =3D 258 (0x0102) (encoded centimeter) HorizontalPrecision =3D 514 (0x0202) (encoded centimeter) VerticalPrecision =3D 514 (0x0202) (encoded centimeter) Latitude =3D 2303079151 (thousandths of a second of arc, 231 represent equater) ( (DecimalDegreeLatitude*60*60*1000)+2147483648 ) Longitude =3D 1868781865 (thousandths of a second of arc, 231 represent prime meridian) ( 2147483648-(DecimalDegreeLongitude*60*60*1000) ) Altitude =3D 10012800 (centimeter) (OfficeElevation+10000000) =20 =20 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------_=_NextPart_001_01CB29CE.78D5BF7B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Job Identifiers:

*existing*

job-id (SM: JobId): The identifier for a job with a lo= cal scope.  That is the ID is unique within the service.  The ID may = be reused in other instance of a Printer (i.e. Print Service)  or for job= s in other types of services (e.g. Copy Service).  Datatype: abstract:int32, IPP:integer, SM:xs:int

 

*new*

job-uuid (SM:JobUuid):  The identifier for a job = with a global scope.  The identifier is unique for a Job across all service instances of any service type.    The UUID URN namespace is = specified in rfc4122.  The format used for “job-uuid” is the string representation of a UUID as a URN.  An example is “urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3”.  The version (aka subtype) used is implementation specific.  Version 1 (i.e. time based) is recommended.   Datatype: abstract:char[64], IPP:uri MaxLength=3D64, SM:xs:anyURI maxLen=3D64

 

Note:  I do not believe the IPP attribute “job-uri” is applicable as a globally unique identifier.

1)&n= bsp;     RFC2911 states “Since every URL is a speciali= zed form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific not= ion of URL as well.”.   All uses of the uri syntax is really a = URL syntax.

2)&n= bsp;     URL implies not only a specific protocol binding but also a location.

3)&n= bsp;     Locations can be specified using an IP address that need not be locally unique (e.g. 192.168.1.1, localhost)

4)&n= bsp;     Regarding the “job-uri” RFC2911  further states that “This URI is then used by clients as the target f= or subsequent Job operations.”.  The globally unique identifier for= a job should not specify a transport endpoint for a specific protocol.  

5)&n= bsp;     The globally unique identifier for a Job, Printer or Service should be a URN.  It should be protocol independent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping.

6)&n= bsp;     The  globally unique identifier for a Job, Pri= nter or Service should require no central authority to administrate them.  Generation of a unique identifier should be simple from an administrative p= oint of view and preferably automated.

 

Note: Both the local and global identifiers should be mandated.  For legacy protocol mappings (e.g. IPP 1.1, WS-Print, LPR) = the local identifier MUST still be maintained.  It is possible to use the = time_low portion of the Timestamp in the version 1 UUID as the local identifier.&nbs= p; The implementation may then keep only the 128 bit local representation of t= he UUID and use it to create the appropriate protocol values.

 

Printer Identifier= s:

*existing (Service Monitoring MIB)*<= /p>

applIndex (SM: <service>Id i.e. PrinterId): The service identifier with a local scope.  That is the ID is unique across the service instances collocated on a host.  Datatype: abstract:int32, MIB:integer, SM:xs:int

 

*new*

printer-uuid (SM:ServiceUuid):  The identifier fo= r a Printer with a global scope.  The identifier is unique across all service instances of any service type.    The UUID URN namespace is specified in rfc4122.  The format used for “job-uuid” is t= he string representation of a UUID as a URN.  An example is “urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3”.  The version (aka subtype) used is implementation specific.  Version 1 = (i.e. time based) is recommended.   Datatype: abstract:char[64], IPP:ur= i, SM:xs:anyURI maxLen=3D64

 

Note:  I do not believe the IPP attribute “= printer-uri” is applicable as a globally unique identifier. 

1)&n= bsp;     RFC2911 states “Since every URL is a speciali= zed form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific not= ion of URL as well.”.   All uses of the uri syntax is really a = URL syntax.

2)&n= bsp;     URL implies not only a specific protocol binding but also a location.

3)&n= bsp;     Locations can be specified using an IP address that need not be locally unique (e.g. 192.168.1.1, localhost)

4)&n= bsp;     The printer may have multiple “printer-uri= 221; values as enumerated in the “printer-uris-supported” attribute.=   There should be only a single  identifier for a printer.

5)&n= bsp;     The globally unique identifier for a Job, Printer or Service should be a URN.  It should be protocol independent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping.

6)&n= bsp;     The  globally unique identifier for a Job, Pri= nter or Service should require no central authority to administrate them.  Generation of a unique identifier should be simple from an administrative p= oint of view and preferably automated.

 

 

Note: The local instance id in the MIB and SM are arti= facts of the model’s data binding and are insufficient for use as an identi= fier.  IPP’s printer-uri, the URL for Web Service bindings (e.g. WS-Print) a= nd the IP address for legacy protocols such as LPR and Port 9100 are also insufficient.  They need not be globally unique.  Nonroutable IP addresses may be used. 

 

Printer Location:<= o:p>

*existing*

printer-location (SM: ServiceLocation): Identifies the location of the device that this Printer represents.  (Example: Pete’s Office)  This is helpful for a human but is pretty much u= seless for geolocation since the content is implementation specific.   D= atatype: abstract:char[127], IPP:string MaxLength=3D127, SM:xs:int

 

*new*

printer-geo-location (SM:ServiceGeoLocation):  Th= is identifies the location of the associated device using the World Geodetic System 1984(WGS84).  The means for expressing the location information= is the same as used in DNS (rfc1876)  Datatype: abstract:class, IPP:colle= ction, SM:sequence

 

*new*

size (SM:Size):  Diame= ter of the bounding sphere containing the device expressed in centimeters.  &= nbsp; Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new*

horizontal-precision (SM: H= orizontalPrecision):  The horizontal precision expressed as the diameter of the “circle of error” (i.e. twice the +- error value)  The units are centimeter= s.    Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new*

vertical-precision (SM: Ver= ticalPrecision):  The vertical precision expressed as the diameter of the “circle of er= ror” (i.e. twice the +- error value)  The units are centimeters.  &nbs= p; Datatype: abstract:integer, IPP: int32, SM:xs:int

 

*new*

latitude (SM:Latitude):&nbs= p; The latitude of the center of the sphere described by the size attribute.  Expressed in thousandths of a second of arc.  The value 2147483648 &nb= sp;(231) represents the equator.  Values above that are north and below are sou= th.   Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new*

longitude (SM:Latitude):&nb= sp; The longitude of the center of the sphere described by the size attribute.  Expressed in thousandths of a second of arc.  The value 2147483648 &nb= sp;(231) represents the prime meridian.  Values above that are east and below a= re south.  The value is rounded away from the prime meridian   Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new*

altitude (SM:Altitude):&nbs= p; The altitude of the center of the sphere described by the size attribute.  Expresse= d in centimeters from a base of 100,000m below the reference spheroid used by GPS [WGS 84].  Altitude above (or below) sea level may be used as an approximation of altitude relative to the [WGS 84] spheroid, though due to = the Earth's surface not being a perfect spheroid, there will be differences. &n= bsp;  Datatype: abstract: int32, IPP:integer, SM:xs:int

 

Note:  There is disagreement on the semantics for= all the attributes between what is posted on <http://pwg-wiki.wikispa= ces.com/Geolocation>  and what I have in the definition above.  I took the definition directly from rfc1876 (I think).  See included text from rfc1876 and t= he location example below. 

 

 

 =

Peter Zehler

Xerox Research Center Webster
Email: Pete= r.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

 

 =

From rfc1876 section 2 &= lt;http://www.rfc-editor.or= g/rfc/rfc1876.txt>

 =

SIZE         The diameter of a sphere enclosing the described entity, in

           &nbs= p; centimeters, expressed as a pair of four-bit unsigned

           &nbs= p; integers, each ranging from zero to nine, with the most

           &nbs= p; significant four bits representing the base and the second

           &nbs= p; number representing the power of ten by which to multiply=

             the base.  This allows sizes from 0e0 (<1cm) to 9e9

           &nbs= p; (90,000km) to be expressed.  This representation was chosen=

           &nbs= p; such that the hexadecimal representation can be read by

           &nbs= p; eye; 0x15 =3D 1e5.  Four-bit values greater than 9 are

           &nbs= p; undefined, as are values with a base of zero and a non-zero

           &nbs= p; exponent.

 

           &nbs= p; Since 20000000m (represented by the value 0x29) is greater

           &nbs= p; than the equatorial diameter of the WGS 84 ellipsoid

             (12756274m), it is therefore suitable for use= as a

           &nbs= p; "worldwide" size.

 

HORIZ PRE    The horizontal precision of the data, in centimeters,=

           &nbs= p; expressed using the same representation as SIZE.  This is

           &nbs= p; the diameter of the horizontal "circle of error", rather

           &nbs=
p; than a "plus or minus" value.  (This was chosen to match<=
o:p>
         =
    the interpretation of SIZE; to get a "plus or minus=
" value,
      &nbs=
p;      divide by 2.)
&n=
bsp;
VERT PRE     The vertical precisio=
n of the data, in centimeters,
    =
;         expressed using the sane =
representation as for SIZE.  This
  &nb=
sp;          is the total pote=
ntial vertical error, rather than a "plus
 &=
nbsp;           or minus&=
quot; value.  (This was chosen to match the
 =
;            interpr=
etation of SIZE; to get a "plus or minus" value,
=
           &nbs=
p; divide by 2.)  Note that if altitude above or below sea<=
/pre>
           =
;  level is used as an approximation for altitude relative to
          &n=
bsp;  the [WGS 84] ellipsoid, the precision value should be=
           &nb=
sp; adjusted.
 
LATITUD=
E     The latitude of the center of the sphere describe=
d by the
       &nb=
sp;     SIZE field, expressed as a 32-bit integer, most=
 significant
       =
;      octet first (network standard byte order), =
in thousandths
      &nb=
sp;      of a second of arc.  2^31 represents=
 the equator; numbers
     &n=
bsp;       above that are north latitude.
 
LONGITUDE    T=
he longitude of the center of the sphere described by the
<= pre>            = ; SIZE field, expressed as a 32-bit integer, most significant
           &=
nbsp; octet first (network standard byte order), in thousandths<=
/pre>
           =
;  of a second of arc, rounded away from the prime meridian.
          &nb=
sp;  2^31 represents the prime meridian; numbers above that are
          =
   east longitude.
 
ALTITUDE     The altitude of the center of the spher= e described by the
      =
;       SIZE field, expressed as a 32-bit int=
eger, most significant
     &=
nbsp;       octet first (network standard byt=
e order), in centimeters,
    &nbs=
p;        from a base of 100,000m below =
the [WGS 84] reference
     &=
nbsp;       spheroid used by GPS (semimajor a=
xis a=3D6378137.0,
      =
;       reciprocal flattening rf=3D298.257223=
563).  Altitude above
    &nb=
sp;        (or below) sea level may be u=
sed as an approximation of
    &nb=
sp;        altitude relative to the the =
[WGS 84] spheroid, though due
    =
         to the Earth's surface not=
 being a perfect spheroid, there
   &nb=
sp;         will be differences.&nb=
sp; (For example, the geoid (which sea
  &nb=
sp;          level approximate=
s) for the continental US ranges from 10
  &=
nbsp;          meters to 50 me=
ters below the [WGS 84] spheroid.
   &n=
bsp;         Adjustments to ALTITUD=
E and/or VERT PRE will be necessary
   =
          in most cases. =
 The Defense Mapping Agency publishes geoid
 &nbs=
p;           height value=
s relative to the [WGS 84] ellipsoid.
 

 

 =

 =

 

 =

 =

2-Dimmensional Location of my office printer<= /b>

Google Map = URL:

http://maps.google.com= /maps?f=3Dq&source=3Ds_q&hl=3Den&geocode=3D&q=3D800+phillip= s+rd+webster+ny+14580&sll=3D37.0625,-95.677068&sspn=3D62.226996,106= .962891&ie=3DUTF8&hq=3D&hnear=3D800+Phillips+Rd,+Webster,+Monro= e,+New+York+14580&ll=3D43.220973,-77.417162&spn=3D0.001781,0.003264= &t=3Dh&z=3D19

Location representations:

Decimal Deg= rees (WGS84)

Latitude Longitude =
43.220973 -77.417162

Degrees, Mi= nutes & Seconds

Latitude Longitude =
N43 13 15 W77 25 01

GPS

Latitude Longitude =
N 43 13.258 W 77 25.030

UTM

 X Y

18N 303685 4788191 =

 

My office elevation:

12800 centimeters (= 419 feet) above sea level

Size of Printer:

91 centimeter (3 fe= et)

Margin of error

183 centimeter (6 f= eet)

 

PrinterGeoLocation (RFC1876)

Size =3D 258 (0x010= 2) (encoded centimeter)
HorizontalPrecision =3D 514 (0x0202)  (encoded centimeter)
VerticalPrecision =3D 514 (0x0202)  (encoded centimeter)

Latitude =3D 230307= 9151 (thousandths of a second of arc, 231 represent equater)  ( = (DecimalDegreeLatitude*60*60*1000)+2147483648 )

Longitude =3D 18687= 81865 (thousandths of a second of arc, 231 represent prime meridian) <= span style=3D'font-size:10.0pt'>( 2147483648-(DecimalDegreeLongitude*60*60*1000)= )
Altitude =3D 10012800 (centimeter)  (OfficeElevation+10000000)<= o:p>

 

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------_=_NextPart_001_01CB29CE.78D5BF7B-- --===============1990111138== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1990111138==-- From aviderhh048@roxullakustik.com Fri Jul 23 14:36:15 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFF1F3A6831 for ; Fri, 23 Jul 2010 14:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.365 X-Spam-Level: X-Spam-Status: No, score=-31.365 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_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_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 BU9hUAMYYnJW for ; Fri, 23 Jul 2010 14:36:13 -0700 (PDT) Received: from 173-14-87-113-naples.hfc.comcastbusiness.net (173-14-87-113-naples.hfc.comcastbusiness.net [173.14.87.113]) by core3.amsl.com (Postfix) with ESMTP id 4CFDD3A67D4 for ; Fri, 23 Jul 2010 14:36:13 -0700 (PDT) Received: from 40816.amazon.com [173.14.87.113] (port=7582 helo=716678.amazon.com) by rockmx03.rockwool.com with asmtp id 8B60AA-000838-34; for ; Fri, 23 Jul 2010 17:35:30 -0500 Date: Fri, 23 Jul 2010 17:35:30 -0500 From: "Amazon.com" To: Message-ID: <000d01cb2aae$f9082dd0$6400a8c0.JavaMail.correios@na-mm-relay.amazon.com> Subject: Your Amazon.com Order (D41-7715538-7144041) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_997097_48015890.3176333574471" Bounces-to: E58B069D602A66C5D2CE365E38C5AEC2E5B319DD507E27@bounces.amazon.com X-AMAZON-MAIL-RELAY-TYPE: notification X-AMAZON-RTE-VERSION: 2.0 ------=_Part_997097_48015890.3176333574471 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Amazon.com Thanks for your order, ipoib-archive@megatron.ietf.org Did you know you can view and edit your orders online, 24 hours a day? Visit Your Account. Order Information: E-mail Address:  ipoib-archive@megatron.ietf.org Order Grand Total: $ 87.99 Earn 3% rewards on your Amazon.com orders with the Amazon Visa Card. Learn More Order Summary: Details: Order #: D50-0280779-3479175 Subtotal of items: $ 60.99 ------ Total before tax: $ 85.99 Sales Tax: $ 0.00 ------ Total for this Order: $ 69.99 The following item was ordered: Click here and see items, Price: $ 98.99By: Click here Sold by: Amazon Digital Services, Inc. The charge for this order will appear on your credit card statement from the merchant 'AMZN Payment Services.' You can review your orders in Your Account. If you've explored the links on that page but still have a question, please visit our online Help Department. Please note: This e-mail was sent from a notification-only address that cannot accept incoming e-mail. Please do not reply to this message. Thanks again for shopping with us. Amazon.comEarth's Biggest Selection Prefer not to receive HTML mail? Click here ------=_Part_997097_48015890.3176333574471 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Amazon.com

Thanks for your order, issll-archive@lists.ietf.org

Did you know you can view and edit your orders online, 24 ho= urs a=20 day? Visit Y= our=20 Account.

Order=20 Information:

E-mail Address:  issll-archive@lists.ietf.= org

Order Grand T= otal: $=20 49.99
Earn 3% = rewards=20 on your Amazon.com orders with the Amazon Visa Card. Learn Mor= e=20

Order=20 Summary:
Details:
<= B>Order=20 #: D83-85374= 60-9836165
S= ubtotal=20 of items: $ 20.99=20
------
T= otal=20 before tax: $ 65.99=20
S= ales=20 Tax: $ 0.00=20
------
<= B>Total=20 for this Order: $=20 92.99

The follow= ing=20 item was ordered:=20
Click her= e and see=20 items, Price: $ 86.99
By: Click her= e
Sold by:=20 Amazon Digital Services, Inc.


The charge for this order will appear on your credit card=20 statement from the merchant 'AMZN Payment Services.'

You can review your orders in Your Account. If you've=20 explored the links on that page but still have a question, plea= se=20 visit our online Help=20 Department.

Please note: This e-mail was sent from a notification-only=20 address that cannot accept incoming e-mail. Please do not reply= to=20 this message.

Thanks again for shopping with us.

Amazon.com<= /B>
Earth's=20 Biggest Selection

3D"unsubscribe=20 Prefer not to receive HTML mail? Click=20 here

3D"Amazon.com=20 3D"your
------=_Part_997097_48015890.3176333574471-- From prvs=info=81407ce70@info.net Sat Jul 24 04:57:43 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8283A69D3; Sat, 24 Jul 2010 04:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_WEOFFER=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 xNZG6diy83GQ; Sat, 24 Jul 2010 04:57:42 -0700 (PDT) Received: from guardian.iesi.com (guardian.iesi.com [76.77.158.130]) by core3.amsl.com (Postfix) with ESMTP id 6938F3A6847; Sat, 24 Jul 2010 04:57:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,252,1278306000"; d="scan'208";a="16746549" Received: from mail.iesi.com ([76.77.158.129]) by guardian.iesi.com with ESMTP; 24 Jul 2010 06:57:58 -0500 Received: from mail.iesi.com (localhost [127.0.0.1]) by mail.iesi.com (Postfix) with ESMTP id 3520312BA8; Sat, 24 Jul 2010 06:58:22 -0500 (CDT) Received: from 116.206.169.40 (SquirrelMail authenticated user rowlett) by mail.iesi.com with HTTP; Sat, 24 Jul 2010 06:58:22 -0500 (CDT) Message-ID: <9586.116.206.169.40.1279972702.squirrel@mail.iesi.com> Date: Sat, 24 Jul 2010 06:58:22 -0500 (CDT) Subject: Hello From: "p finance" Reply-To: pfinance@msn.com User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; Another opportunity is here for your financial advancement this year.With Prudential and Mortgage Loan Corporation, your thirst for cheap and legitimate loan is over.We give loan at the lowest percentage rate of 2% annually. We offer all kinds of loan to anybody who is interested.Send the following informations:(pfinance@msn.com) Amount needed.... Duration... Phone number: Fried Eric From pwg-announce-bounces@pwg.org Sat Jul 24 22:05:11 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E28F3A68C0 for ; Sat, 24 Jul 2010 22:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.554 X-Spam-Level: X-Spam-Status: No, score=-100.554 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, 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 JI2xnn0ns7WU for ; Sat, 24 Jul 2010 22:05:10 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id CD2273A683A for ; Sat, 24 Jul 2010 22:05:09 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 72E8979254; Sun, 25 Jul 2010 01:05:18 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by pwg.org (Postfix) with ESMTP id C84CF79211; Sun, 25 Jul 2010 01:05:12 -0400 (EDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id CF110A526301; Sat, 24 Jul 2010 22:05:11 -0700 (PDT) X-AuditID: 11807136-b7cc9ae000004162-7d-4c4bc606ef77 Received: from [17.151.96.154] (Unknown_Domain [17.151.96.154]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id B5.5C.16738.706CB4C4; Sat, 24 Jul 2010 22:05:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Michael Sweet Date: Sat, 24 Jul 2010 22:05:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6678F362-B089-467B-8FFE-43E1DEEE90D4@apple.com> To: pwg-announce@pwg.org X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAQAAAZE= X-pwg-MailScanner: Found to be clean, Found to be clean Cc: ipp@pwg.org Subject: [Pwg-Announce] New Cloud Printing mailing list now available X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 72E8979254.ABF00 X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org All, We now have a Cloud Printing mailing list setup on the PWG server. The add= ress is "cloud@pwg.org". You can subscribe from the following page: https://www.pwg.org/mailman/listinfo/cloud I've also updated the Cloud Printing wiki with this information: http://pwg-wiki.wikispaces.com/Cloud+Printing ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce From ipp-bounces@pwg.org Sat Jul 24 22:05:17 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4932D3A68C0 for ; Sat, 24 Jul 2010 22:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.577 X-Spam-Level: X-Spam-Status: No, score=-101.577 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, 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 aDacZtAEE2FO for ; Sat, 24 Jul 2010 22:05:16 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id BF0483A683A for ; Sat, 24 Jul 2010 22:05:14 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 08A487922D; Sun, 25 Jul 2010 01:05:18 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by pwg.org (Postfix) with ESMTP id C84CF79211; Sun, 25 Jul 2010 01:05:12 -0400 (EDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id CF110A526301; Sat, 24 Jul 2010 22:05:11 -0700 (PDT) X-AuditID: 11807136-b7cc9ae000004162-7d-4c4bc606ef77 Received: from [17.151.96.154] (Unknown_Domain [17.151.96.154]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id B5.5C.16738.706CB4C4; Sat, 24 Jul 2010 22:05:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Michael Sweet Date: Sat, 24 Jul 2010 22:05:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6678F362-B089-467B-8FFE-43E1DEEE90D4@apple.com> To: pwg-announce@pwg.org X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAQAAAZE= X-pwg-MailScanner: Found to be clean, Found to be clean Cc: ipp@pwg.org Subject: [IPP] New Cloud Printing mailing list now available X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 08A487922D.A7A40 X-pwg-MailScanner-From: ipp-bounces@pwg.org All, We now have a Cloud Printing mailing list setup on the PWG server. The add= ress is "cloud@pwg.org". You can subscribe from the following page: https://www.pwg.org/mailman/listinfo/cloud I've also updated the Cloud Printing wiki with this information: http://pwg-wiki.wikispaces.com/Cloud+Printing ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From saltyax388@xeminhdung.com Sun Jul 25 04:53:10 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D471C3A6912; Sun, 25 Jul 2010 04:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.927 X-Spam-Level: X-Spam-Status: No, score=-4.927 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SXLIFE=1.07, STOX_REPLY_TYPE=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, 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 tgx26bGdc95A; Sun, 25 Jul 2010 04:53:08 -0700 (PDT) Received: from www.beamtele.com (unknown [124.123.88.87]) by core3.amsl.com (Postfix) with ESMTP id A410B3A6880; Sun, 25 Jul 2010 04:53:07 -0700 (PDT) Received: from [124.123.88.87] (port=2681 helo=rajuc1f88a3b2c) by p.nsm.ctmail.com with asmtp id 8115A9-0005D2-77 for ; Sun, 25 Jul 2010 04:53:25 -0800 Message-ID: <183E30D6E15C49E0852F4AA3FC2793DA@rajuc1f88a3b2c> From: To: Subject: Experience safer, longer and more enjoyable sex or have your money back.. (Though its never happened before) Date: Sun, 25 Jul 2010 04:53:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Mras: Ok Fulfill your partner(s) sexual fantasies with a harder, longer and straightened erection http://shopperz.ru From ineffectuallylo4@sfbi.com Sun Jul 25 11:54:40 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175863A687B; Sun, 25 Jul 2010 11:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.449 X-Spam-Level: X-Spam-Status: No, score=-23.449 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, 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 YWGg3VQ5o2A5; Sun, 25 Jul 2010 11:54:39 -0700 (PDT) Received: from 89.189.136.172.dynamic.ufanet.ru (89.189.136.172.dynamic.ufanet.ru [89.189.136.172]) by core3.amsl.com (Postfix) with ESMTP id 6D9573A68B8; Sun, 25 Jul 2010 11:54:38 -0700 (PDT) Received: from 200.amazon.com [89.189.136.172] (port=4311 helo=68565719.amazon.com) by tmbbaking.com.inbound15.mxlogic.net with asmtp id 4e2ff5-0009b0-09; for ; Mon, 26 Jul 2010 00:54:48 +0500 Date: Mon, 26 Jul 2010 00:54:48 +0500 From: "Amazon.com" To: Message-ID: <000d01cb2c2a$dafe2b50$6400a8c0.JavaMail.correios@na-mm-relay.amazon.com> Subject: Your Amazon.com Order (D00-5144549-3664180) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_222937_36676905.4801737432078" Bounces-to: 94be153a27e3bcb9ff794db59662b3c0abff81d010a91a@bounces.amazon.com X-AMAZON-MAIL-RELAY-TYPE: notification X-AMAZON-RTE-VERSION: 2.0 ------=_Part_222937_36676905.4801737432078 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Amazon.com Thanks for your order, ipdvb-archive@megatron.ietf.org Did you know you can view and edit your orders online, 24 hours a day? Visit Your Account. Order Information: E-mail Address:  ipdvb-archive@megatron.ietf.org Order Grand Total: $ 86.99 Earn 3% rewards on your Amazon.com orders with the Amazon Visa Card. Learn More Order Summary: Details: Order #: D26-1139533-0634011 Subtotal of items: $ 17.99 ------ Total before tax: $ 15.99 Sales Tax: $ 0.00 ------ Total for this Order: $ 27.99 The following item was ordered: Click here and see items, Price: $ 77.99By: Click here Sold by: Amazon Digital Services, Inc. The charge for this order will appear on your credit card statement from the merchant 'AMZN Payment Services.' You can review your orders in Your Account. If you've explored the links on that page but still have a question, please visit our online Help Department. Please note: This e-mail was sent from a notification-only address that cannot accept incoming e-mail. Please do not reply to this message. Thanks again for shopping with us. Amazon.comEarth's Biggest Selection Prefer not to receive HTML mail? Click here ------=_Part_222937_36676905.4801737432078 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Amazon.com

Thanks for your order, ipoib-archive@megatron.ietf.org

Did you know you can view and edit your orders online, 24 ho= urs a=20 day? Visit Your=20 Account.

Order=20 Information:

E-mail Address:  ipoib-archive@megatron.ie= tf.org

Order Grand T= otal: $=20 87.99
Earn 3% = rewards=20 on your Amazon.com orders with the Amazon Visa Card. Learn More=20

Order=20 Summary:
Details:
<= B>Order=20 #: D50-0280779-3479175
S= ubtotal=20 of items: $ 60.99=20
------
T= otal=20 before tax: $ 85.99=20
S= ales=20 Tax: $ 0.00=20
------
<= B>Total=20 for this Order: $=20 69.99

The follow= ing=20 item was ordered:=20
Click here and see=20 items, Price: $ 98.99
By: Click here
Sold by= :=20 Amazon Digital Services, Inc.


The charge for this order will appear on your credit card=20 statement from the merchant 'AMZN Payment Services.'

You can review your orders in Your Account. If you've=20 explored the links on that page but still have a question, plea= se=20 visit our online Help=20 Department.

Please note: This e-mail was sent from a notification-only=20 address that cannot accept incoming e-mail. Please do not reply= to=20 this message.

Thanks again for shopping with us.

Amazon.com
Earth's= =20 Biggest Selection

3D"unsubscribe=20 Prefer not to receive HTML mail? Click=20 here

3D"Amazon.com=20 3D"your
------=_Part_222937_36676905.4801737432078-- From ipp-bounces@pwg.org Sun Jul 25 15:01:31 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4663A677C for ; Sun, 25 Jul 2010 15:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.46 X-Spam-Level: ** X-Spam-Status: No, score=2.46 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_FONT_SIZE_HUGE=0.057, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, MIME_HTML_MOSTLY=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 YTYVVeCWJmGm for ; Sun, 25 Jul 2010 15:01:15 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id C5D5F3A6405 for ; Sun, 25 Jul 2010 15:01:14 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id E60AA792B3; Sun, 25 Jul 2010 18:01:00 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by pwg.org (Postfix) with ESMTP id 2580179254; Sun, 25 Jul 2010 18:00:49 -0400 (EDT) Received: from FamilyRoom ([unknown] [108.13.218.174]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L6400FNXVSYQKL3@vms173003.mailsrvcs.net>; Sun, 25 Jul 2010 17:00:39 -0500 (CDT) From: "Tom Hastings" To: "'Zehler, Peter'" , , References: Subject: RE: [IPP] Attributes needed for Cloud Printing and definition inconsistencies [typo in definition of "longitude": "south" should be "west"] Date: Sun, 25 Jul 2010 15:00:34 -0700 Message-id: <635BB61A4ADF4275A596527E4743727C@FamilyRoom> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcspxRRVo4ExmexOQvqGozc+7BuVQQCeyIEA X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-reply-to: X-pwg-MailScanner: Found to be clean, Found to be clean Cc: X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tom.hastings@alum.mit.edu List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0591385149==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: E60AA792B3.A936C X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============0591385149== Content-type: multipart/alternative; boundary="----=_NextPart_000_00AC_01CB2C0A.23EBEB70" This is a multi-part message in MIME format. ------=_NextPart_000_00AC_01CB2C0A.23EBEB70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Pete, I assume that there is a typo in the definition of "longitude". The sentence: Values above that are east and below are south should be: Values above that are east and below are west Here are the two descriptions of the two new attributes for "latitude" and "longitude": *new* latitude (SM:Latitude): The latitude of the center of the sphere described by the size attribute. Expressed in thousandths of a second of arc. The value 2147483648 (231) represents the equator. Values above that are north and below are south. Datatype: abstract: int32, IPP:integer, SM:xs:int *new* longitude (SM:Latitude): The longitude of the center of the sphere described by the size attribute. Expressed in thousandths of a second of arc. The value 2147483648 (231) represents the prime meridian. Values above that are east and below are south. The value is rounded away from the prime meridian Datatype: abstract: int32, IPP:integer, SM:xs:int Tom _____ From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Zehler, Peter Sent: Thursday, July 22, 2010 11:48 To: ipp@pwg.org; mfd@pwg.org Subject: [IPP] Attributes needed for Cloud Printing and definitioninconsistencies Job Identifiers: *existing* job-id (SM: JobId): The identifier for a job with a local scope. That is the ID is unique within the service. The ID may be reused in other instance of a Printer (i.e. Print Service) or for jobs in other types of services (e.g. Copy Service). Datatype: abstract:int32, IPP:integer, SM:xs:int *new* job-uuid (SM:JobUuid): The identifier for a job with a global scope. The identifier is unique for a Job across all service instances of any service type. The UUID URN namespace is specified in rfc4122. The format used for "job-uuid" is the string representation of a UUID as a URN. An example is "urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3". The version (aka subtype) used is implementation specific. Version 1 (i.e. time based) is recommended. Datatype: abstract:char[64], IPP:uri MaxLength=64, SM:xs:anyURI maxLen=64 Note: I do not believe the IPP attribute "job-uri" is applicable as a globally unique identifier. 1) RFC2911 states "Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.". All uses of the uri syntax is really a URL syntax. 2) URL implies not only a specific protocol binding but also a location. 3) Locations can be specified using an IP address that need not be locally unique (e.g. 192.168.1.1, localhost) 4) Regarding the "job-uri" RFC2911 further states that "This URI is then used by clients as the target for subsequent Job operations.". The globally unique identifier for a job should not specify a transport endpoint for a specific protocol. 5) The globally unique identifier for a Job, Printer or Service should be a URN. It should be protocol independent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping. 6) The globally unique identifier for a Job, Printer or Service should require no central authority to administrate them. Generation of a unique identifier should be simple from an administrative point of view and preferably automated. Note: Both the local and global identifiers should be mandated. For legacy protocol mappings (e.g. IPP 1.1, WS-Print, LPR) the local identifier MUST still be maintained. It is possible to use the time_low portion of the Timestamp in the version 1 UUID as the local identifier. The implementation may then keep only the 128 bit local representation of the UUID and use it to create the appropriate protocol values. Printer Identifiers: *existing (Service Monitoring MIB)* applIndex (SM: Id i.e. PrinterId): The service identifier with a local scope. That is the ID is unique across the service instances collocated on a host. Datatype: abstract:int32, MIB:integer, SM:xs:int *new* printer-uuid (SM:ServiceUuid): The identifier for a Printer with a global scope. The identifier is unique across all service instances of any service type. The UUID URN namespace is specified in rfc4122. The format used for "job-uuid" is the string representation of a UUID as a URN. An example is "urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3". The version (aka subtype) used is implementation specific. Version 1 (i.e. time based) is recommended. Datatype: abstract:char[64], IPP:uri, SM:xs:anyURI maxLen=64 Note: I do not believe the IPP attribute "printer-uri" is applicable as a globally unique identifier. 1) RFC2911 states "Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.". All uses of the uri syntax is really a URL syntax. 2) URL implies not only a specific protocol binding but also a location. 3) Locations can be specified using an IP address that need not be locally unique (e.g. 192.168.1.1, localhost) 4) The printer may have multiple "printer-uri" values as enumerated in the "printer-uris-supported" attribute. There should be only a single identifier for a printer. 5) The globally unique identifier for a Job, Printer or Service should be a URN. It should be protocol independent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping. 6) The globally unique identifier for a Job, Printer or Service should require no central authority to administrate them. Generation of a unique identifier should be simple from an administrative point of view and preferably automated. Note: The local instance id in the MIB and SM are artifacts of the model's data binding and are insufficient for use as an identifier. IPP's printer-uri, the URL for Web Service bindings (e.g. WS-Print) and the IP address for legacy protocols such as LPR and Port 9100 are also insufficient. They need not be globally unique. Nonroutable IP addresses may be used. Printer Location: *existing* printer-location (SM: ServiceLocation): Identifies the location of the device that this Printer represents. (Example: Pete's Office) This is helpful for a human but is pretty much useless for geolocation since the content is implementation specific. Datatype: abstract:char[127], IPP:string MaxLength=127, SM:xs:int *new* printer-geo-location (SM:ServiceGeoLocation): This identifies the location of the associated device using the World Geodetic System 1984(WGS84). The means for expressing the location information is the same as used in DNS (rfc1876) Datatype: abstract:class, IPP:collection, SM:sequence *new* size (SM:Size): Diameter of the bounding sphere containing the device expressed in centimeters. Datatype: abstract: int32, IPP:integer, SM:xs:int *new* horizontal-precision (SM: HorizontalPrecision): The horizontal precision expressed as the diameter of the "circle of error" (i.e. twice the +- error value) The units are centimeters. Datatype: abstract: int32, IPP:integer, SM:xs:int *new* vertical-precision (SM: VerticalPrecision): The vertical precision expressed as the diameter of the "circle of error" (i.e. twice the +- error value) The units are centimeters. Datatype: abstract:integer, IPP: int32, SM:xs:int *new* latitude (SM:Latitude): The latitude of the center of the sphere described by the size attribute. Expressed in thousandths of a second of arc. The value 2147483648 (231) represents the equator. Values above that are north and below are south. Datatype: abstract: int32, IPP:integer, SM:xs:int *new* longitude (SM:Latitude): The longitude of the center of the sphere described by the size attribute. Expressed in thousandths of a second of arc. The value 2147483648 (231) represents the prime meridian. Values above that are east and below are south. The value is rounded away from the prime meridian Datatype: abstract: int32, IPP:integer, SM:xs:int *new* altitude (SM:Altitude): The altitude of the center of the sphere described by the size attribute. Expressed in centimeters from a base of 100,000m below the reference spheroid used by GPS [WGS 84]. Altitude above (or below) sea level may be used as an approximation of altitude relative to the [WGS 84] spheroid, though due to the Earth's surface not being a perfect spheroid, there will be differences. Datatype: abstract: int32, IPP:integer, SM:xs:int Note: There is disagreement on the semantics for all the attributes between what is posted on and what I have in the definition above. I took the definition directly from rfc1876 (I think). See included text from rfc1876 and the location example below. Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@Xerox.com Voice: (585) 265-8755 FAX: (585) 265-7441 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 >From rfc1876 section 2 SIZE The diameter of a sphere enclosing the described entity, in centimeters, expressed as a pair of four-bit unsigned integers, each ranging from zero to nine, with the most significant four bits representing the base and the second number representing the power of ten by which to multiply the base. This allows sizes from 0e0 (<1cm) to 9e9 (90,000km) to be expressed. This representation was chosen such that the hexadecimal representation can be read by eye; 0x15 = 1e5. Four-bit values greater than 9 are undefined, as are values with a base of zero and a non-zero exponent. Since 20000000m (represented by the value 0x29) is greater than the equatorial diameter of the WGS 84 ellipsoid (12756274m), it is therefore suitable for use as a "worldwide" size. HORIZ PRE The horizontal precision of the data, in centimeters, expressed using the same representation as SIZE. This is the diameter of the horizontal "circle of error", rather than a "plus or minus" value. (This was chosen to match the interpretation of SIZE; to get a "plus or minus" value, divide by 2.) VERT PRE The vertical precision of the data, in centimeters, expressed using the sane representation as for SIZE. This is the total potential vertical error, rather than a "plus or minus" value. (This was chosen to match the interpretation of SIZE; to get a "plus or minus" value, divide by 2.) Note that if altitude above or below sea level is used as an approximation for altitude relative to the [WGS 84] ellipsoid, the precision value should be adjusted. LATITUDE The latitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandths of a second of arc. 2^31 represents the equator; numbers above that are north latitude. LONGITUDE The longitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandths of a second of arc, rounded away from the prime meridian. 2^31 represents the prime meridian; numbers above that are east longitude. ALTITUDE The altitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in centimeters, from a base of 100,000m below the [WGS 84] reference spheroid used by GPS (semimajor axis a=6378137.0, reciprocal flattening rf=298.257223563). Altitude above (or below) sea level may be used as an approximation of altitude relative to the the [WGS 84] spheroid, though due to the Earth's surface not being a perfect spheroid, there will be differences. (For example, the geoid (which sea level approximates) for the continental US ranges from 10 meters to 50 meters below the [WGS 84] spheroid. Adjustments to ALTITUDE and/or VERT PRE will be necessary in most cases. The Defense Mapping Agency publishes geoid height values relative to the [WGS 84] ellipsoid. 2-Dimmensional Location of my office printer Google Map URL: http://maps.google.com/maps?f=q &source=s_q&hl=en&geocode=&q=800+phillips+rd+webster+ny+14580&sll=37.0625,-9 5.677068&sspn=62.226996,106.962891&ie=UTF8&hq=&hnear=800+Phillips+Rd,+Webste r,+Monroe,+New+York+14580&ll=43.220973,-77.417162&spn=0.001781,0.003264&t=h& z=19 Location representations: Decimal Degrees (WGS84) Latitude Longitude 43.220973 -77.417162 Degrees, Minutes & Seconds Latitude Longitude N43 13 15 W77 25 01 GPS Latitude Longitude N 43 13.258 W 77 25.030 UTM X Y 18N 303685 4788191 My office elevation: 12800 centimeters (419 feet) above sea level Size of Printer: 91 centimeter (3 feet) Margin of error 183 centimeter (6 feet) PrinterGeoLocation (RFC1876) Size = 258 (0x0102) (encoded centimeter) HorizontalPrecision = 514 (0x0202) (encoded centimeter) VerticalPrecision = 514 (0x0202) (encoded centimeter) Latitude = 2303079151 (thousandths of a second of arc, 231 represent equater) ( (DecimalDegreeLatitude*60*60*1000)+2147483648 ) Longitude = 1868781865 (thousandths of a second of arc, 231 represent prime meridian) ( 2147483648-(DecimalDegreeLongitude*60*60*1000) ) Altitude = 10012800 (centimeter) (OfficeElevation+10000000) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_NextPart_000_00AC_01CB2C0A.23EBEB70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pete,

 

I assume that there is a typo in the definition of “longitude”.  The sentence:

 

Values above that are east and below are south

should be:

Values above that are east and below are west

 

Here are the two descriptions of the t= wo new attributes for “latitude” and “longitude”:=

 

*new<= /b>*

latitude (SM:Latitude):  The latitude of the center of the sphere described by the size attribute.  Expressed in thousandths of a second of arc.  The value 2147483648  (231<= /sup>) represents the equator.  Values above that are north and below are sou= th.   Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new<= /b>*

longitude (SM:Latitude):  The longitude of = the center of the sphere described by the size attribute.  Expressed in thousandths of a second of arc.  The value 2147483648  (231<= /sup>) represents the prime meridian.  Values above that are east and below a= re south.  The value is rounded away = from the prime meridian   Datatype: abstract: int32, IPP:integer, SM:x= s:int

 

Tom

 


From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Zehler, Peter
Sent: Thursday, July 22, 2010 11:48
To: ipp@pwg.org; mfd@pwg.org=
Subject: [IPP] Attributes ne= eded for Cloud Printing and definitioninconsistencies

 

Job Identifiers:

*existing*

job-id (SM: JobId): The identifier for a job with a local scope.  That is the= ID is unique within the service.  The ID may be reused in other instance = of a Printer (i.e. Print Service)  or for jobs in other types of services (= e.g. Copy Service).  Datatype: abstract:int32, IPP:integer, SM:xs:int<= /o:p>

 

*new*

job-uuid (SM:JobUuid):  The identifier for a job with a global scope.  The identifier is unique for a Job across all service instances of any service = type.    The UUID URN namespace is specified in rfc4122.  The format used for “job-uuid” is the string representation of a UUID as a URN.&nbs= p; An example is “= urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3”.  The version (aka subtype) use= d is implementation specific.  Version 1 (i.e. time based) is recommended.   Datatype: abstract:char[64], IPP:uri MaxLength=3D6= 4, SM:xs:anyURI maxLen=3D64

 

Note:  I do not believe the IPP attribute “job-uri” is applicable as a globally unique identifier.

1)      RFC2911 states “Since ev= ery URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover t= he more specific notion of URL as well.”.   All uses of the uri syntax is really a URL syntax.

2)      URL implies not only a specific protocol binding but also a location.

3)      Locations can be specified usi= ng an IP address that need not be locally unique (e.g. 192.168.1.1, localhost)=

4)      Regarding the “job-uri” RFC2911  further states that “This URI is = then used by clients as the target for subsequent Job operations.”.  = The globally unique identifier for a job should not specify a transport endpoint for a specific protocol.  

5)      The globally unique identifier= for a Job, Printer or Service should be a URN.  It should be protocol inde= pendent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping.

6)      The  globally unique identifier for a Job, Printer or Service should require no central authorit= y to administrate them.  Generation of a unique identifier should be simple from an administrative point of view and preferably automated.

 

Note: Both the local and global identifiers should be mandated.  For legacy protocol mappings (e.g. IPP 1.1, WS-Print, LPR) the local identifier MUST s= till be maintained.  It is possible to use the time_low portion of the Timestamp in the version 1 UUID as the local identifier.  The implementation may then keep only the 128 bit local representation of the U= UID and use it to create the appropriate protocol values.

 

Printer Identifiers:

*existing (Service Monitoring MIB)*

applIndex (SM: <service>Id i.e. PrinterId): The service identifier with a local scope.  That is the ID is unique across the service instances collocat= ed on a host.  Datatype: abstract:int32, MIB:integer, SM:xs:int

 

*new*

printer-uuid (SM:ServiceUuid):  The identifier for a Printer with a global scope.&n= bsp; The identifier is unique across all service instances of any service type.    The UUID URN namespace is specified in rfc4122.&nbs= p; The format used for “job-uuid” is the string representation of a UUID as a URN.  An example is “urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3”.  The version (aka subtype) used is implementation specific.  Version 1 (i.e. time based) is recommended.   Datatype: abstract:char[64], IPP:uri, SM:xs:anyURI maxLen=3D64

 

Note:  I do not believe the IPP attribute “printer-uri” is applicable = as a globally unique identifier. 

1)      RFC2911 states “Since ev= ery URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover t= he more specific notion of URL as well.”.   All uses of the uri syntax is really a URL syntax.

2)      URL implies not only a specific protocol binding but also a location.

3)      Locations can be specified usi= ng an IP address that need not be locally unique (e.g. 192.168.1.1, localhost)=

4)      The printer may have multiple “printer-uri” values as enumerated in the “printer-uris-supported” attribute.  There should be only a single  identifier for a printer.

5)      The globally unique identifier= for a Job, Printer or Service should be a URN.  It should be protocol independent so that a product that supports multiple protocols should have = the same identifiers regardless of the protocol mapping.

6)      The  globally unique identifier for a Job, Printer or Service should require no central authorit= y to administrate them.  Generation of a unique identifier should be simple from an administrative point of view and preferably automated.

 

 

Note: The local instance id in the MIB and SM are artifacts of the model’s = data binding and are insufficient for use as an identifier.  IPP’s printer-uri, the URL for Web Service bindings (e.g. WS-Print) and the IP address for legacy protocols such as LPR and Port 9100 are also insufficien= t.  They need not be globally unique.  Nonroutable IP addresses may be used. 

 

Printer Location:

*existing*

printer-location (SM: ServiceLocation): Identifies the location of the device that this Prin= ter represents.  (Example: Pete’s Office)  This is helpful for a human but is pretty much useless for geolocation since the content is implementation specific.   Datatype: abstract:char[127], IPP:stri= ng MaxLength=3D127, SM:xs:int

 

*new*

printer-geo-location (SM:ServiceGeoLocation):  This identifies the location of the associat= ed device using the World Geodetic System 1984(WGS84).  The means for expressing the location information is the same as used in DNS (rfc1876)  Datatype: abstract:class, IPP:collection, SM:sequence

 

*new<= /b>*

size (SM:Size):  Diameter of the bounding s= phere containing the device expressed in centimeters.    Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new<= /b>*

horizontal-precision (SM: HorizontalPrecision):&= nbsp; The horizontal precision expressed as the diameter of the “circle of error” (i.e. twice the +- error value)  The units are centimeters.    Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new<= /b>*

vertical-precision (SM: VerticalPrecision): = ; The vertical precision expressed as the diameter of the “circle of error” (i.e. twice the +- error value)  The units are centimeters.    Datatype: abstract:integer, IPP: int32, SM:xs:int

 

*new<= /b>*

latitude (SM:Latitude):  The latitude of the center of the sphere described by the size attribute.  Expressed in thousandths of a second of arc.  The value 2147483648  (231<= /sup>) represents the equator.  Values above that are north and below are sou= th.   Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new<= /b>*

longitude (SM:Latitude):  The longitude of = the center of the sphere described by the size attribute.  Expressed in thousandths of a second of arc.  The value 2147483648  (231<= /sup>) represents the prime meridian.  Values above that are east and below a= re south.  The value is rounded away from the prime meridian   Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new<= /b>*

altitude (SM:Altitude):  The altitude of the center of the sphere described by the size attribute.  Expressed in centimeters from a base of 100,000m below the reference spheroid used by GPS [WGS 84].  Altitude above (or below) sea level may be used as an approximation of altitude relative to the [WGS 84] spheroid, though due to = the Earth's surface not being a perfect spheroid, there will be differences.    Datatype: abstract: int32, IPP:integer, SM:xs:int

 

Note:  There is disagreement on the semantics for all the attributes between what = is posted on <http:/= /pwg-wiki.wikispaces.com/Geolocation>  and what I have in the definition above.  I took the definition directly from rfc1876 (I think).  See included text from rfc1876 and t= he location example below. 

 

 

 

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com<= /font>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701 <= /p>

 

 

From rfc1876 section 2 <http://www.rfc-editor.or= g/rfc/rfc1876.txt> <= /p>

 

SIZE       &n= bsp; The diameter of a sphere enclosing the described entity, in

        =      centimeters, expressed as a pair of four-bit unsigned

        =      integers, each ranging from zero to nine, with the most

        =      significant four bits representing the base and the second

        =      number representing the power of ten by which to multiply=

             the base.  This allows sizes from 0e0 (<1cm) to 9e9

        =      (90,000km) to be expressed.  This representation was chosen=

        =      such that the hexadecimal representation can be read by

        =      eye; 0x15 =3D 1e5.  Four-bit values greater than 9 are

        =      undefined, as are values with a base of zero and a non-zero

        =      exponent.

 

        =      Since 20000000m (represented by the value 0x29) is greater

        =      than the equatorial diameter of the WGS 84 ellipsoid

             (12756274m), it is therefore suitable for use= as a

        =      "worldwide" size.

 

HORIZ PRE    The horizontal preci= sion of the data, in centimeters,

        =      expressed using the same representation as SIZE.  This is

        =      the diameter of the horizontal "circle of error", rather

&=
nbsp;            tha=
n a "plus or minus" value.  (This was chosen to match
  =
           the interpreta=
tion of SIZE; to get a "plus or minus" value,
  =
           divide by 2.)<=
o:p>
 <=
/o:p>
VERT PRE&nbs=
p;    The vertical precision of the data, in centimeters,
  =
           expressed usin=
g the sane representation as for SIZE.  This<=
/pre>
  =
           is the total p=
otential vertical error, rather than a "plus<=
/pre>
  =
           or minus"=
 value.  (This was chosen to match the
<= pre>  =            interpretation= of SIZE; to get a "plus or minus" value,
  =
           divide by 2.)&=
nbsp; Note that if altitude above or below sea
  =
           level is used =
as an approximation for altitude relative to
=
  =
           the [WGS 84] e=
llipsoid, the precision value should be
=
  =
           adjusted.=
 <=
/o:p>
LATITUDE&nbs=
p;    The latitude of the center of the sphere described by =
the
  =
           SIZE field, ex=
pressed as a 32-bit integer, most significant
  =
           octet first (n=
etwork standard byte order), in thousandths
<= pre>  =            of a second of= arc.  2^31 represents the equator; numbers
  =
           above that are=
 north latitude.
 <=
/o:p>
LONGITUDE&nb=
sp;   The longitude of the center of the sphere described by the<=
o:p>
  =
           SIZE field, ex=
pressed as a 32-bit integer, most significant
  =
           octet first (n=
etwork standard byte order), in thousandths
<= pre>  =            of a second of= arc, rounded away from the prime meridian.
<= pre>  =            2^31 represent= s the prime meridian; numbers above that are
=
  =
           east longitude=
.
 <=
/o:p>
ALTITUDE&nbs=
p;    The altitude of the center of the sphere described by =
the
  =
           SIZE field, ex=
pressed as a 32-bit integer, most significant
  =
           octet first (n=
etwork standard byte order), in centimeters,
=
  =
           from a base of=
 100,000m below the [WGS 84] reference
<=
font
size=3D2 face=3D"Courier New">  =
           spheroid used =
by GPS (semimajor axis a=3D6378137.0,
  =
           reciprocal fla=
ttening rf=3D298.257223563).  Altitude above<=
/pre>
  =
           (or below) sea=
 level may be used as an approximation of
  =            altitude relat= ive to the the [WGS 84] spheroid, though due
=
  =
           to the Earth's=
 surface not being a perfect spheroid, there
=
  =
           will be differ=
ences.  (For example, the geoid (which sea
  =
           level approxim=
ates) for the continental US rang=
es from 10
  =
           meters to 50 m=
eters below the [WGS 84] spheroid.
  =
           Adjustments to=
 ALTITUDE and/or VERT PRE will be necessary
<= pre>  =            in most cases.=   The Defense Mapping Agency publishes geoid<= /pre>
  =
           height values =
relative to the [WGS 84] ellipsoid.
 <=
/o:p>

 

 

 

 

 

 

2-Dimmensi= onal Location of my office printer

Google Map URL:

http://maps.google.com= /maps?f=3Dq&source=3Ds_q&hl=3Den&geocode=3D&q=3D800+phillip= s+rd+webster+ny+14580&sll=3D37.0625,-95.677068&sspn=3D62.226996,106= .962891&ie=3DUTF8&hq=3D&hnear=3D800+Phillips+Rd,+Webster,+Monro= e,+New+York+14580&ll=3D43.220973,-77.417162&spn=3D0.001781,0.003264= &t=3Dh&z=3D19

Location representations:=

Decimal Degrees (WGS84)

Latitude Longitude
43.220973 -77.417162

Degrees, Minutes & Seconds

Latitude Longitude
N43 13 15 W77 25 01

GPS

Latitude Longitude
N 43 13.258 W 77 25.030

UTM

 X Y

18N 303685 4788191

 

My office elevation:

12800 centimeters (419 feet) above sea level

Size of Pr= inter:

91 centimeter (3 feet)<= /p>

Margin of = error

183 centimeter (6 feet)=

 

PrinterGeo= Location (RFC1876)

Size =3D 258 (0x0102) (encoded centimeter)
HorizontalPrecision =3D 514 (0x0202)  (encoded centimeter)
VerticalPrecision =3D 514 (0x0202)  (encoded centimeter)

Latitude =3D 2303079151 (thousandths of a second= of arc, 231 represent equater)  ( (DecimalDegreeLatitude*60*60*1000)+2147483648 )

Longitude =3D 1868781865 (thousandths of a secon= d of arc, 231 represent prime meridian) = ( 2147483648-(DecimalDegreeLongitude*60*60*1000)= )
Altitude =3D 10012800 (centimeter)  (OfficeElevation+100= 00000)

 

 


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_NextPart_000_00AC_01CB2C0A.23EBEB70-- --===============0591385149== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0591385149==-- From ipp-bounces@pwg.org Sun Jul 25 22:11:51 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A3CD3A685F for ; Sun, 25 Jul 2010 22:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.46 X-Spam-Level: ** X-Spam-Status: No, score=2.46 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_FONT_SIZE_HUGE=0.057, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, MIME_HTML_MOSTLY=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 w+0dVilO8U+u for ; Sun, 25 Jul 2010 22:11:30 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 6FBDA3A69C2 for ; Sun, 25 Jul 2010 22:11:29 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id E0DEE792CD; Mon, 26 Jul 2010 01:11:05 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by pwg.org (Postfix) with ESMTP id E27AD792A2; Mon, 26 Jul 2010 01:10:51 -0400 (EDT) Received: from FamilyRoom ([unknown] [108.13.218.174]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L6500JG7FPZMF36@vms173011.mailsrvcs.net>; Mon, 26 Jul 2010 00:10:51 -0500 (CDT) From: "Tom Hastings" To: "'Zehler, Peter'" , , , References: Subject: RE: [IPP] Attributes needed for Cloud Printing and definition inconsistencies [4 questions about the representation of the values] Date: Sun, 25 Jul 2010 22:10:47 -0700 Message-id: MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcspxRRVo4ExmexOQvqGozc+7BuVQQCg2cfw X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-reply-to: X-pwg-MailScanner: Found to be clean, Found to be clean Cc: X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tom.hastings@alum.mit.edu List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1937388964==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: E0DEE792CD.A9119 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============1937388964== Content-type: multipart/alternative; boundary="----=_NextPart_000_00EE_01CB2C46.3CCFDF20" This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01CB2C46.3CCFDF20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Pete, I have 4 questions about your proposed IPP attributes for Geo Location for Cloud Printing: 1. The representation of the values of your proposed IPP "size", "horizontal-precision", and "vertical-precision" attributes are completely different from the representation of the same attributes in RFC1876. If this difference is intentional, it would be good to explain the difference and why and to indicate this intended difference in the spec? As I read RFC 1876, the representation of the SIZE, HORIZ PRE, and VERT PRE attributes are all using this funny SIZE representation as a pair of four-bit unsigned integers, where the most significant 4-bit unsigned integer represents the base and the second 4-bit integer represents the power of 10 by which to multiple the base, sort of a compressed floating point representation, but using power of 10, not power of 2. The reason give in RFC 1876 is so that the value is more easily human readable. HORIZ PRE and VERT PRE attributes defined in RFC 1876, say: expressed using the same representation as SIZE i.e., using this same 8-bit "floating point" representation. BTW, the VERT PRE attribute has an ironic Freudian slip typo in RFC 1876, since I don't find this representation very sane :-(: expressed using the sane representation as for SIZE 2. The definitions on the appear to be part of the PWG Semantic Model: This page proposes an IPP collection representing the DNS LOC data defined in RFC 1876 . printer-geo-location (collection) The "printer-geo-location" attribute provides the physical location of the printer. The collection has the following member attributes. size (integer (0:MAX)) Diameter of enclosing sphere for printer in centimeters. 0 represents any size less than one centimeter. horizontal-precision (integer (0:MAX)) The circle of error of the latitude and longitude measurement in centimeters. 0 represents an error of less than one centimeter. vertical-precision (integer(0:MAX)) The circle of error of the altitude measurement in centimeters. 0 represents an error of less than one centimeter. latitude (integer(-324000000:324000000)) The latitude in thousandths of arc seconds from the equator. 0 represents the equator, positive values represent locations North of the equator, and negative values represent locations South of the equator. longitude (integer(-648000000:648000000)) The longitude in thousandths of arc seconds from the prime meridian. 0 represents the prime meridian, positive values represent locations East of the meridian, and negative values represent locations West of the meridian. altitude (integer(-100000:MAX)) The distance in centimeters from the WGS-84 ellipsoid to the center of the enclosing sphere defined by the "side" member attribute. 0 represents the WGS-84 ellipsoid height, positive values represent locations above the ellipsoid, and negative values represent locations below the ellipsoid. The PWG SM definitions appear to use signed 32-bit integer notation and description which have the same bit representation as the unsigned 32-bit integer notation and description in RFC 1876, right? Why change to use the unsigned integer notation and descriptions, when the rest of the SM and IPP use signed integer notations and descriptions? 3. What is the relationship between Cloud Printing (which these definitions are proposed for) and IPP Everywhere? 4. I like the idea used in IPP and the SM to have the data type indicate the range of values in the definition of the attribute name and attribute syntax, i.e., latitude (integer(-324000000:324000000)). Why isn't this technique of specifying the data type and the data type range used in your proposal for attributes needed for Cloud Printing? Tom _____ From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Zehler, Peter Sent: Thursday, July 22, 2010 11:48 To: ipp@pwg.org; mfd@pwg.org Subject: [IPP] Attributes needed for Cloud Printing and definition inconsistencies Job Identifiers: *existing* job-id (SM: JobId): The identifier for a job with a local scope. That is the ID is unique within the service. The ID may be reused in other instance of a Printer (i.e. Print Service) or for jobs in other types of services (e.g. Copy Service). Datatype: abstract:int32, IPP:integer, SM:xs:int *new* job-uuid (SM:JobUuid): The identifier for a job with a global scope. The identifier is unique for a Job across all service instances of any service type. The UUID URN namespace is specified in rfc4122. The format used for "job-uuid" is the string representation of a UUID as a URN. An example is "urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3". The version (aka subtype) used is implementation specific. Version 1 (i.e. time based) is recommended. Datatype: abstract:char[64], IPP:uri MaxLength=64, SM:xs:anyURI maxLen=64 Note: I do not believe the IPP attribute "job-uri" is applicable as a globally unique identifier. 1) RFC2911 states "Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.". All uses of the uri syntax is really a URL syntax. 2) URL implies not only a specific protocol binding but also a location. 3) Locations can be specified using an IP address that need not be locally unique (e.g. 192.168.1.1, localhost) 4) Regarding the "job-uri" RFC2911 further states that "This URI is then used by clients as the target for subsequent Job operations.". The globally unique identifier for a job should not specify a transport endpoint for a specific protocol. 5) The globally unique identifier for a Job, Printer or Service should be a URN. It should be protocol independent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping. 6) The globally unique identifier for a Job, Printer or Service should require no central authority to administrate them. Generation of a unique identifier should be simple from an administrative point of view and preferably automated. Note: Both the local and global identifiers should be mandated. For legacy protocol mappings (e.g. IPP 1.1, WS-Print, LPR) the local identifier MUST still be maintained. It is possible to use the time_low portion of the Timestamp in the version 1 UUID as the local identifier. The implementation may then keep only the 128 bit local representation of the UUID and use it to create the appropriate protocol values. Printer Identifiers: *existing (Service Monitoring MIB)* applIndex (SM: Id i.e. PrinterId): The service identifier with a local scope. That is the ID is unique across the service instances collocated on a host. Datatype: abstract:int32, MIB:integer, SM:xs:int *new* printer-uuid (SM:ServiceUuid): The identifier for a Printer with a global scope. The identifier is unique across all service instances of any service type. The UUID URN namespace is specified in rfc4122. The format used for "job-uuid" is the string representation of a UUID as a URN. An example is "urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3". The version (aka subtype) used is implementation specific. Version 1 (i.e. time based) is recommended. Datatype: abstract:char[64], IPP:uri, SM:xs:anyURI maxLen=64 Note: I do not believe the IPP attribute "printer-uri" is applicable as a globally unique identifier. 1) RFC2911 states "Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.". All uses of the uri syntax is really a URL syntax. 2) URL implies not only a specific protocol binding but also a location. 3) Locations can be specified using an IP address that need not be locally unique (e.g. 192.168.1.1, localhost) 4) The printer may have multiple "printer-uri" values as enumerated in the "printer-uris-supported" attribute. There should be only a single identifier for a printer. 5) The globally unique identifier for a Job, Printer or Service should be a URN. It should be protocol independent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping. 6) The globally unique identifier for a Job, Printer or Service should require no central authority to administrate them. Generation of a unique identifier should be simple from an administrative point of view and preferably automated. Note: The local instance id in the MIB and SM are artifacts of the model's data binding and are insufficient for use as an identifier. IPP's printer-uri, the URL for Web Service bindings (e.g. WS-Print) and the IP address for legacy protocols such as LPR and Port 9100 are also insufficient. They need not be globally unique. Nonroutable IP addresses may be used. Printer Location: *existing* printer-location (SM: ServiceLocation): Identifies the location of the device that this Printer represents. (Example: Pete's Office) This is helpful for a human but is pretty much useless for geolocation since the content is implementation specific. Datatype: abstract:char[127], IPP:string MaxLength=127, SM:xs:int *new* printer-geo-location (SM:ServiceGeoLocation): This identifies the location of the associated device using the World Geodetic System 1984(WGS84). The means for expressing the location information is the same as used in DNS (rfc1876) Datatype: abstract:class, IPP:collection, SM:sequence *new* size (SM:Size): Diameter of the bounding sphere containing the device expressed in centimeters. Datatype: abstract: int32, IPP:integer, SM:xs:int *new* horizontal-precision (SM: HorizontalPrecision): The horizontal precision expressed as the diameter of the "circle of error" (i.e. twice the +- error value) The units are centimeters. Datatype: abstract: int32, IPP:integer, SM:xs:int *new* vertical-precision (SM: VerticalPrecision): The vertical precision expressed as the diameter of the "circle of error" (i.e. twice the +- error value) The units are centimeters. Datatype: abstract:integer, IPP: int32, SM:xs:int *new* latitude (SM:Latitude): The latitude of the center of the sphere described by the size attribute. Expressed in thousandths of a second of arc. The value 2147483648 (231) represents the equator. Values above that are north and below are south. Datatype: abstract: int32, IPP:integer, SM:xs:int *new* longitude (SM:Latitude): The longitude of the center of the sphere described by the size attribute. Expressed in thousandths of a second of arc. The value 2147483648 (231) represents the prime meridian. Values above that are east and below are south. The value is rounded away from the prime meridian Datatype: abstract: int32, IPP:integer, SM:xs:int *new* altitude (SM:Altitude): The altitude of the center of the sphere described by the size attribute. Expressed in centimeters from a base of 100,000m below the reference spheroid used by GPS [WGS 84]. Altitude above (or below) sea level may be used as an approximation of altitude relative to the [WGS 84] spheroid, though due to the Earth's surface not being a perfect spheroid, there will be differences. Datatype: abstract: int32, IPP:integer, SM:xs:int Note: There is disagreement on the semantics for all the attributes between what is posted on and what I have in the definition above. I took the definition directly from rfc1876 (I think). See included text from rfc1876 and the location example below. Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@Xerox.com Voice: (585) 265-8755 FAX: (585) 265-7441 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 >From rfc1876 section 2 SIZE The diameter of a sphere enclosing the described entity, in centimeters, expressed as a pair of four-bit unsigned integers, each ranging from zero to nine, with the most significant four bits representing the base and the second number representing the power of ten by which to multiply the base. This allows sizes from 0e0 (<1cm) to 9e9 (90,000km) to be expressed. This representation was chosen such that the hexadecimal representation can be read by eye; 0x15 = 1e5. Four-bit values greater than 9 are undefined, as are values with a base of zero and a non-zero exponent. Since 20000000m (represented by the value 0x29) is greater than the equatorial diameter of the WGS 84 ellipsoid (12756274m), it is therefore suitable for use as a "worldwide" size. HORIZ PRE The horizontal precision of the data, in centimeters, expressed using the same representation as SIZE. This is the diameter of the horizontal "circle of error", rather than a "plus or minus" value. (This was chosen to match the interpretation of SIZE; to get a "plus or minus" value, divide by 2.) VERT PRE The vertical precision of the data, in centimeters, expressed using the sane representation as for SIZE. This is the total potential vertical error, rather than a "plus or minus" value. (This was chosen to match the interpretation of SIZE; to get a "plus or minus" value, divide by 2.) Note that if altitude above or below sea level is used as an approximation for altitude relative to the [WGS 84] ellipsoid, the precision value should be adjusted. LATITUDE The latitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandths of a second of arc. 2^31 represents the equator; numbers above that are north latitude. LONGITUDE The longitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandths of a second of arc, rounded away from the prime meridian. 2^31 represents the prime meridian; numbers above that are east longitude. ALTITUDE The altitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in centimeters, from a base of 100,000m below the [WGS 84] reference spheroid used by GPS (semimajor axis a=6378137.0, reciprocal flattening rf=298.257223563). Altitude above (or below) sea level may be used as an approximation of altitude relative to the the [WGS 84] spheroid, though due to the Earth's surface not being a perfect spheroid, there will be differences. (For example, the geoid (which sea level approximates) for the continental US ranges from 10 meters to 50 meters below the [WGS 84] spheroid. Adjustments to ALTITUDE and/or VERT PRE will be necessary in most cases. The Defense Mapping Agency publishes geoid height values relative to the [WGS 84] ellipsoid. 2-Dimmensional Location of my office printer Google Map URL: http://maps.google.com/maps?f=q &source=s_q&hl=en&geocode=&q=800+phillips+rd+webster+ny+14580&sll=37.0625,-9 5.677068&sspn=62.226996,106.962891&ie=UTF8&hq=&hnear=800+Phillips+Rd,+Webste r,+Monroe,+New+York+14580&ll=43.220973,-77.417162&spn=0.001781,0.003264&t=h& z=19 Location representations: Decimal Degrees (WGS84) Latitude Longitude 43.220973 -77.417162 Degrees, Minutes & Seconds Latitude Longitude N43 13 15 W77 25 01 GPS Latitude Longitude N 43 13.258 W 77 25.030 UTM X Y 18N 303685 4788191 My office elevation: 12800 centimeters (419 feet) above sea level Size of Printer: 91 centimeter (3 feet) Margin of error 183 centimeter (6 feet) PrinterGeoLocation (RFC1876) Size = 258 (0x0102) (encoded centimeter) HorizontalPrecision = 514 (0x0202) (encoded centimeter) VerticalPrecision = 514 (0x0202) (encoded centimeter) Latitude = 2303079151 (thousandths of a second of arc, 231 represent equater) ( (DecimalDegreeLatitude*60*60*1000)+2147483648 ) Longitude = 1868781865 (thousandths of a second of arc, 231 represent prime meridian) ( 2147483648-(DecimalDegreeLongitude*60*60*1000) ) Altitude = 10012800 (centimeter) (OfficeElevation+10000000) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_NextPart_000_00EE_01CB2C46.3CCFDF20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pete,

 

I have 4 questions about your proposed= IPP attributes for Geo Location for Cloud Printing:

 

1. The representation of the values of your proposed IPP “size”, “horizontal-precision”, and “vertical-precision” = attributes are completely different from the representation of the same attributes in RFC1876.

 

If this difference is intentional, it would be good to explain the difference and why and to indicate this intend= ed difference in the spec?

 

As I read RFC 1876, the representation= of the SIZE, HORIZ PRE, and VERT PRE attributes are all using this funny SIZE representation as a pair of four-bit unsigned integers, where the most significant 4-bit unsigned integer represents the base and the second 4-bit integer represents the power of 10 by which to multiple the base, sort of a compressed floating point representation, but using power of 10, not power = of 2.  The reason give in RFC 1876 is so that the value is more easily hu= man readable.  HORIZ PRE and VERT PRE attributes defined in RFC 1876, say:=

 

expressed using the same representation as SIZE<=
o:p>

i.e., using this same 8-bit “floating point” representation.

 

BTW, the VERT PRE attribute has an ironic Fre=
udian slip typo in RFC 1876, since I don’t find this representation v=
ery sane L:
expressed using the sane representation as for SIZE

 

 

2. The definitions on the <http://pwg-wiki.wikispa= ces.com/Geolocation> appear to be part of the PWG Semantic Model:

 

This page proposes= an IPP collection representing the DNS LOC data defined in RFC 1876 .
printer-geo-location (collection)
The "printer-geo-location" attribute provides the physical locati= on of the printer. The collection has the following member attributes.
<= font size=3D5 face=3D"Times New Roman">size (integer (0:MAX))

Diameter of enclos= ing sphere for printer in centimeters. 0 represents any size less than one centimeter.
<= font size=3D5 face=3D"Times New Roman">horizontal-precision (integer (0:MAX))<= /font>

The circle of erro= r of the latitude and longitude measurement in centimeters. 0 represents an erro= r of less than one centimeter.
<= font size=3D5 face=3D"Times New Roman">vertical-precision (integer(0:MAX))

The circle of erro= r of the altitude measurement in centimeters. 0 represents an error of less than= one centimeter.
<= font size=3D5 face=3D"Times New Roman">latitude (integer(-324000000:324000000))

The latitude in thousandths of arc seconds from the equator. 0 represents the equator, posi= tive values represent locations North of the equator, and negative values repres= ent locations South of the equator.
<= font size=3D5 face=3D"Times New Roman">longitude (integer(-648000000:648000000))

The longitude in thousandths of arc seconds from the prime meridian. 0 represents the prime meridian, positive values represent locations East of the meridian, and negative values represent locations West of the meridian.
<= font size=3D5 face=3D"Times New Roman">altitude (integer(-100000:MAX))
<= /b>

The distance in centimeters from the WGS-84 ellipsoid to the center of the enclosing sphere defined by the "side" member attribute. 0 represents the WGS-84 ellipsoid height, positive values represent locations above the ellipsoid, = and negative values represent locations below the ellipsoid. =

 

The PWG SM definitions appear to use signed 32-bit integer notation and description which have the same bit representation as the unsigned 32-bit integer notation and description in R= FC 1876, right?  Why change to use the unsigned integer notation and descriptions, when the rest of the SM and IPP use signed integer notations = and descriptions?

 

 

3. What is the relationship between Cl= oud Printing (which these definitions are proposed for) and IPP Everywhere?

 

 

4. I like the idea used in IPP and the= SM to have the data type indicate the range of values in the definition of the attribute name and attribute syntax, i.e., latitude (integer(-324000000:324000000)).  Why isn’t this technique of sp= ecifying the data type and the data type range used in your proposal for attributes needed for Cloud Printing?

 

Tom


From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Zehler, Peter
Sent: Thursday, July 22, 2010 11:48
To: ipp@pwg.org; mfd@pwg.org=
Subject: [IPP] Attributes ne= eded for Cloud Printing and definition inconsistencies

 

Job Identifiers:

*existing*

job-id (SM: JobId): The identifier for a job with a local scope.  That is the= ID is unique within the service.  The ID may be reused in other instance = of a Printer (i.e. Print Service)  or for jobs in other types of services (= e.g. Copy Service).  Datatype: abstract:int32, IPP:integer, SM:xs:int<= /o:p>

 

*new*

job-uuid (SM:JobUuid):  The identifier for a job with a global scope.  The identifier is unique for a Job across all service instances of any service type.    The UUID URN namespace is specified in rfc4122.&nbs= p; The format used for “job-uuid” is the string representation of a UUID as a URN.  An example is “urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3”.  The version (aka subtype) used is implementation specific.  Version 1 (i.e. time based) is recommended.   Datatype: abstract:char[64], IPP:uri MaxLength=3D64, SM:xs:anyURI maxLen=3D64

 

Note:  I do not believe the IPP attribute “job-uri” is applicable as a globally unique identifier.

1)      RFC2911 states “Since ev= ery URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover t= he more specific notion of URL as well.”.   All uses of the uri syntax is really a URL syntax.

2)      URL implies not only a specific protocol binding but also a location.

3)      Locations can be specified usi= ng an IP address that need not be locally unique (e.g. 192.168.1.1, localhost)=

4)      Regarding the “job-uri” RFC2911  further states that “This URI is = then used by clients as the target for subsequent Job operations.”.  = The globally unique identifier for a job should not specify a transport endpoint for a specific protocol.  

5)      The globally unique identifier= for a Job, Printer or Service should be a URN.  It should be protocol independent so that a product that supports multiple protocols should have = the same identifiers regardless of the protocol mapping.

6)      The  globally unique identifier for a Job, Printer or Service should require no central authorit= y to administrate them.  Generation of a unique identifier should be simple from an administrative point of view and preferably automated.

 

Note: Both the local and global identifiers should be mandated.  For legacy protocol mappings (e.g. IPP 1.1, WS-Print, LPR) the local identifier MUST s= till be maintained.  It is possible to use the time_low portion of the Timestamp in the version 1 UUID as the local identifier.  The implemen= tation may then keep only the 128 bit local representation of the UUID and use it = to create the appropriate protocol values.

 

Printer Identifiers:

*existing (Service Monitoring MIB)*

applIndex (SM: <service>Id i.e. PrinterId): The service identifier with a local scope.  That is the ID is unique across the service instances collocat= ed on a host.  Datatype: abstract:int32, MIB:integer, SM:xs:int

 

*new*

printer-uuid (SM:ServiceUuid):  The identifier for a Printer with a global scope.&n= bsp; The identifier is unique across all service instances of any service type.    The UUID URN namespace is specified in rfc4122.&nbs= p; The format used for “job-uuid” is the string representation of a UUID as a URN.  An example is “urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3”.  The version (aka subtype) used is implementation specific.  Version 1 (i.e. time based) is recommended.   Datatype: abstract:char[64], IPP:uri, SM:xs:anyURI maxLen=3D64

 

Note:  I do not believe the IPP attribute “printer-uri” is applicable = as a globally unique identifier. 

1)      RFC2911 states “Since ev= ery URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover t= he more specific notion of URL as well.”.   All uses of the ur= i syntax is really a URL syntax.

2)      URL implies not only a specific protocol binding but also a location.

3)      Locations can be specified usi= ng an IP address that need not be locally unique (e.g. 192.168.1.1, localhost)=

4)      The printer may have multiple “printer-uri” values as enumerated in the “printer-uris-supported” attribute.  There should be only a single  identifier for a printer.

5)      The globally unique identifier= for a Job, Printer or Service should be a URN.  It should be protocol inde= pendent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping.

6)      The  globally unique identifier for a Job, Printer or Service should require no central authorit= y to administrate them.  Generation of a unique identifier should be simple from an administrative point of view and preferably automated.

 

 

Note: The local instance id in the MIB and SM are artifacts of the model’s = data binding and are insufficient for use as an identifier.  IPP’s pr= inter-uri, the URL for Web Service bindings (e.g. WS-Print) and the IP address for leg= acy protocols such as LPR and Port 9100 are also insufficient.  They need = not be globally unique.  Nonroutable IP addresses may be used.  =

 

Printer Location:

*existing*

printer-location (SM: ServiceLocation): Identifies the location of the device that this Prin= ter represents.  (Example: Pete’s Office)  This is helpful for a human but is pretty much useless for geolocation since the content is implementation specific.   Datatype: abstract:char[127], IPP:stri= ng MaxLength=3D127, SM:xs:int

 

*new*

printer-geo-location (SM:ServiceGeoLocation):  This identifies the location of the associat= ed device using the World Geodetic System 1984(WGS84).  The means for expressing the location information is the same as used in DNS (rfc1876)  Datatype: abstract:class, IPP:collection, SM:sequence

 

*new<= /b>*

size (SM:Size):  Diameter of the bounding s= phere containing the device expressed in centimeters.    Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new<= /b>*

horizontal-precision (SM: HorizontalPrecision):&= nbsp; The horizontal precision expressed as the diameter of the “circle of error” (i.e. twice the +- error value)  The units are centimeters.    Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new<= /b>*

vertical-precision (SM: VerticalPrecision): = ; The vertical precision expressed as the diameter of the “circle of error” (i.e. twice the +- error value)  The units are centimeters.    Datatype: abstract:integer, IPP: int32, SM:xs:int

 

*new<= /b>*

latitude (SM:Latitude):  The latitude of the center of the sphere described by the size attribute.  Expressed in thousandths of a second of arc.  The value 2147483648  (231<= /sup>) represents the equator.  Values above that are north and below are sou= th.   Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new<= /b>*

longitude (SM:Latitude):  The longitude of = the center of the sphere described by the size attribute.  Expressed in thousandths of a second of arc.  The value 2147483648  (231<= /sup>) represents the prime meridian.  Values above that are east and below a= re south.  The value is rounded away from the prime meridian   Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new<= /b>*

altitude (SM:Altitude):  The altitude of the center of the sphere described by the size attribute.  Expressed in centimeters from a base of 100,000m below the reference spheroid used by GPS [WGS 84].  Altitude above (or below) sea level may be used as an approximation of altitude relative to the [WGS 84] spheroid, though due to = the Earth's surface not being a perfect spheroid, there will be differences.    Datatype: abstract: int32, IPP:integer, SM:xs:int

 

Note:  There is disagreement on the semantics for all the attributes between what = is posted on <http:/= /pwg-wiki.wikispaces.com/Geolocation>  and what I have in the definition above.  I took the definition directly from rfc1876 (I think).  See included text from rfc1876 and t= he location example below. 

 

 

 

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com<= /font>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701 <= /p>

 

 

From rfc1876 section 2 <http://www.rfc-editor.or= g/rfc/rfc1876.txt> <= /p>

 

SIZE       &n= bsp; The diameter of a sphere enclosing the described entity, in

        =      centimeters, expressed as a pair of four-bit unsigned

        =      integers, each ranging from zero to nine, with the most

        =      significant four bits representing the base and the second

        =      number representing the power of ten by which to multiply=

             the base.  This allows sizes from 0e0 (<1cm) to 9e9

        =      (90,000km) to be expressed.  This representation was chosen=

        =      such that the hexadecimal representation can be read by

        =      eye; 0x15 =3D 1e5.  Four-bit values greater than 9 are

        =      undefined, as are values with a base of zero and a non-zero

        =      exponent.

 

        =      Since 20000000m (represented by the value 0x29) is greater

        =      than the equatorial diameter of the WGS 84 ellipsoid

             (12756274m), it is therefore suitable for use= as a

        =      "worldwide" size.

 

HORIZ PRE    The horizontal preci= sion of the data, in centimeters,

        =      expressed using the same representation as SIZE.  This is

        =      the diameter of the horizontal "circle of error", rather

&=
nbsp;            tha=
n a "plus or minus" value.  (This was chosen to match
  =
           the interpreta=
tion of SIZE; to get a "plus or minus" value,
  =
           divide by 2.)<=
o:p>
 <=
/o:p>
VERT PRE&nbs=
p;    The vertical precision of the data, in centimeters,
  =
           expressed usin=
g the sane representation as for SIZE.  This<=
/pre>
  =
           is the total p=
otential vertical error, rather than a "plus<=
/pre>
  =
           or minus"=
 value.  (This was chosen to match the
<= pre>  =            interpretation= of SIZE; to get a "plus or minus" value,
  =
           divide by 2.)&=
nbsp; Note that if altitude above or below sea
  =
           level is used =
as an approximation for altitude relative to
=
  =
           the [WGS 84] e=
llipsoid, the precision value should be
=
  =
           adjusted.=
 <=
/o:p>
LATITUDE&nbs=
p;    The latitude of the center of the sphere described by =
the
  =
           SIZE field, ex=
pressed as a 32-bit integer, most significant
  =
           octet first (n=
etwork standard byte order), in thousandths
<= pre>  =            of a second of= arc.  2^31 represents the equator; numbers
  =
           above that are=
 north latitude.
 <=
/o:p>
LONGITUDE&nb=
sp;   The longitude of the center of the sphere described by the<=
o:p>
  =
           SIZE field, ex=
pressed as a 32-bit integer, most significant
  =
           octet first (n=
etwork standard byte order), in thousandths
<= pre>  =            of a second of= arc, rounded away from the prime meridian.
<= pre>  =            2^31 represent= s the prime meridian; numbers above that are
=
  =
           east longitude=
.
 <=
/o:p>
ALTITUDE&nbs=
p;    The altitude of the center of the sphere described by =
the
  =
           SIZE field, ex=
pressed as a 32-bit integer, most significant
  =
           octet first (n=
etwork standard byte order), in centimeters,
=
  =
           from a base of=
 100,000m below the [WGS 84] reference
<=
font
size=3D2 face=3D"Courier New">  =
           spheroid used =
by GPS (semimajor axis a=3D6378137.0,
  =
           reciprocal fla=
ttening rf=3D298.257223563).  Altitude above<=
/pre>
  =
           (or below) sea=
 level may be used as an approximation of
  =            altitude relat= ive to the the [WGS 84] spheroid, though due
=
  =
           to the Earth's=
 surface not being a perfect spheroid, there
=
  =
           will be differ=
ences.  (For example, the geoid (which sea
  =
           level approxim=
ates) for the continental US rang=
es from 10
  =
           meters to 50 m=
eters below the [WGS 84] spheroid.
  =
           Adjustments to=
 ALTITUDE and/or VERT PRE will be necessary
<= pre>  =            in most cases.=   The Defense Mapping Agency publishes geoid<= /pre>
  =
           height values =
relative to the [WGS 84] ellipsoid.
 <=
/o:p>

 

 

 

 

 

 

2-Dimmensi= onal Location of my office printer

Google Map URL:

http://maps.google.com= /maps?f=3Dq&source=3Ds_q&hl=3Den&geocode=3D&q=3D800+phillip= s+rd+webster+ny+14580&sll=3D37.0625,-95.677068&sspn=3D62.226996,106= .962891&ie=3DUTF8&hq=3D&hnear=3D800+Phillips+Rd,+Webster,+Monro= e,+New+York+14580&ll=3D43.220973,-77.417162&spn=3D0.001781,0.003264= &t=3Dh&z=3D19

Location representations:=

Decimal Degrees (WGS84)

Latitude Longitude
43.220973 -77.417162

Degrees, Minutes & Seconds

Latitude Longitude
N43 13 15 W77 25 01

GPS

Latitude Longitude
N 43 13.258 W 77 25.030

UTM

 X Y

18N 303685 4788191

 

My office elevation:

12800 centimeters (419 feet) above sea level

Size of Pr= inter:

91 centimeter (3 feet)<= /p>

Margin of = error

183 centimeter (6 feet)=

 

PrinterGeo= Location (RFC1876)

Size =3D 258 (0x0102) (encoded centimeter)
HorizontalPrecision =3D 514 (0x0202)  (encoded centimeter)
VerticalPrecision =3D 514 (0x0202)  (encoded centimeter)

Latitude =3D 2303079151 (thousandths of a second= of arc, 231 represent equater)  ( (DecimalDegreeLatitude*60*60*1000)+2147483648 )

Longitude =3D 1868781865 (thousandths of a secon= d of arc, 231 represent prime meridian) = ( 2147483648-(DecimalDegreeLongitude*60*60*1000)= )
Altitude =3D 10012800 (centimeter)  (OfficeElevation+100= 00000)

 

 


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_NextPart_000_00EE_01CB2C46.3CCFDF20-- --===============1937388964== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1937388964==-- From ipp-bounces@pwg.org Mon Jul 26 04:54:57 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EEB83A6802 for ; Mon, 26 Jul 2010 04:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.756 X-Spam-Level: * X-Spam-Status: No, score=1.756 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, MIME_HTML_MOSTLY=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 S3Bfzj043fex for ; Mon, 26 Jul 2010 04:54:35 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 630163A686E for ; Mon, 26 Jul 2010 04:54:35 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 371B5792F6; Mon, 26 Jul 2010 07:53:12 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from wbmler3.mail.xerox.com (wbmler3.mail.xerox.com [13.13.138.218]) by pwg.org (Postfix) with ESMTP id BC794792B8; Mon, 26 Jul 2010 07:52:58 -0400 (EDT) Received: from wbmlir2.mail.xerox.com (wbmlir2.mail.xerox.com [13.131.8.222]) by wbmler3.mail.xerox.com (8.14.4/8.13.8) with ESMTP id o6QBqvP7002502; Mon, 26 Jul 2010 07:52:57 -0400 Received: from wbmlir2.mail.xerox.com (localhost [127.0.0.1]) by wbmlir2.mail.xerox.com (8.14.4/8.13.6) with ESMTP id o6QBqnbU014843; Mon, 26 Jul 2010 07:52:49 -0400 Received: from USA0300GW002.na.xerox.net (usa0300gw002.na.xerox.net [13.135.210.15]) by wbmlir2.mail.xerox.com (8.14.4/8.13.6) with ESMTP id o6QBqmtG014830; Mon, 26 Jul 2010 07:52:48 -0400 X-XeroxINT-Source-Ip: 13.135.210.15 X-XeroxINT-Source-Name: usa0300gw002.na.xerox.net X-XeroxINT-Reported-Name: USA0300GW002.na.xerox.net Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA0300GW002.na.xerox.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 07:52:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [IPP] Attributes needed for Cloud Printing and definition inconsistencies [4 questions about the representation of the values] Date: Mon, 26 Jul 2010 04:52:46 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPP] Attributes needed for Cloud Printing and definition inconsistencies [4 questions about the representation of the values] Thread-Index: AcspxRRVo4ExmexOQvqGozc+7BuVQQCg2cfwABiLfGA= References: From: "Zehler, Peter" To: , , , X-OriginalArrivalTime: 26 Jul 2010 11:52:48.0709 (UTC) FILETIME=[11A99750:01CB2CB9] X-pwg-MailScanner: Found to be clean, Found to be clean Cc: X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1496505575==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 371B5792F6.A9EC9 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============1496505575== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2CB9.10DE0B95" This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2CB9.10DE0B95 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My comments are inline below =20 =20 Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@Xerox.com Voice: (585) 265-8755 FAX: (585) 265-7441 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701=20 =20 From: Tom Hastings [mailto:tom.hastings@verizon.net]=20 Sent: Monday, July 26, 2010 1:11 AM To: Zehler, Peter; ipp@pwg.org; mfd@pwg.org; cloud@pwg.org Subject: RE: [IPP] Attributes needed for Cloud Printing and definition inconsistencies [4 questions about the representation of the values] =20 Pete, =20 I have 4 questions about your proposed IPP attributes for Geo Location for Cloud Printing: =20 1. The representation of the values of your proposed IPP "size", "horizontal-precision", and "vertical-precision" attributes are completely different from the representation of the same attributes in RFC1876. I made a mistake in my values. I used 8 bit unsigned integers instead of 4 bit. The values should be; Size=3D 18 (0x12), HorizontalPrecision=3D34 (0x22), VerticalPrecision=3D34 (0x22). (This is why I really don't like this representation. That and the fact that for the dimensions associated with MFDs it is not as precise a expressing it in simple centimeters) =20 If this difference is intentional, it would be good to explain the difference and why and to indicate this intended difference in the spec? =20 As I read RFC 1876, the representation of the SIZE, HORIZ PRE, and VERT PRE attributes are all using this funny SIZE representation as a pair of four-bit unsigned integers, where the most significant 4-bit unsigned integer represents the base and the second 4-bit integer represents the power of 10 by which to multiple the base, sort of a compressed floating point representation, but using power of 10, not power of 2. The reason give in RFC 1876 is so that the value is more easily human readable. HORIZ PRE and VERT PRE attributes defined in RFC 1876, say: =20 expressed using the same representation as SIZE i.e., using this same 8-bit "floating point" representation. =20 BTW, the VERT PRE attribute has an ironic Freudian slip typo in RFC 1876, since I don't find this representation very sane L: expressed using the sane representation as for SIZE =20 =20 2. The definitions on the appear to be part of the PWG Semantic Model: =20 This page proposes an IPP collection representing the DNS LOC data defined in RFC 1876 . printer-geo-location (collection) The "printer-geo-location" attribute provides the physical location of the printer. The collection has the following member attributes. size (integer (0:MAX)) Diameter of enclosing sphere for printer in centimeters. 0 represents any size less than one centimeter. horizontal-precision (integer (0:MAX)) The circle of error of the latitude and longitude measurement in centimeters. 0 represents an error of less than one centimeter. vertical-precision (integer(0:MAX)) The circle of error of the altitude measurement in centimeters. 0 represents an error of less than one centimeter. latitude (integer(-324000000:324000000)) The latitude in thousandths of arc seconds from the equator. 0 represents the equator, positive values represent locations North of the equator, and negative values represent locations South of the equator. longitude (integer(-648000000:648000000)) The longitude in thousandths of arc seconds from the prime meridian. 0 represents the prime meridian, positive values represent locations East of the meridian, and negative values represent locations West of the meridian. altitude (integer(-100000:MAX)) The distance in centimeters from the WGS-84 ellipsoid to the center of the enclosing sphere defined by the "side" member attribute. 0 represents the WGS-84 ellipsoid height, positive values represent locations above the ellipsoid, and negative values represent locations below the ellipsoid.=20 =20 The PWG SM definitions appear to use signed 32-bit integer notation and description which have the same bit representation as the unsigned 32-bit integer notation and description in RFC 1876, right? Why change to use the unsigned integer notation and descriptions, when the rest of the SM and IPP use signed integer notations and descriptions? To the best of my knowledge printer-geo-location is not part of the PWG semantic model yet. I put out this mail note to test my understanding of the proposal on the wiki site. I want to be sure the semantics and syntax are well defined and the mapping to rfc1876 is clear. =20 =20 3. What is the relationship between Cloud Printing (which these definitions are proposed for) and IPP Everywhere? Cloud Printing can be implemented without IPP Everywhere. The initial implementations will not be using IPP or IPP Everywhere. It will be cobbled together with existing technologies used in Web Services, messaging protocols, standard document formats and print driver related technologies. IPP could play a role in this environment but I believe it is most critical to obtain semantic alignment between IPP and the emerging Cloud Printing technologies. IPP Everywhere addresses a number of IPP shortcomings such as printer discovery, common document formats, and interoperable security. IPP Everywhere could apply to Cloud Printing but would require some extensions to accommodate intervening firewalls. =20 =20 4. I like the idea used in IPP and the SM to have the data type indicate the range of values in the definition of the attribute name and attribute syntax, i.e., latitude (integer(-324000000:324000000)). Why isn't this technique of specifying the data type and the data type range used in your proposal for attributes needed for Cloud Printing? Added to definitions below. =20 Tom ________________________________ From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Zehler, Peter Sent: Thursday, July 22, 2010 11:48 To: ipp@pwg.org; mfd@pwg.org Subject: [IPP] Attributes needed for Cloud Printing and definition inconsistencies =20 Job Identifiers: *existing* job-id (SM: JobId): The identifier for a job with a local scope. That is the ID is unique within the service. The ID may be reused in other instance of a Printer (i.e. Print Service) or for jobs in other types of services (e.g. Copy Service). Datatype: abstract:int32, IPP:integer, SM:xs:int =20 *new* job-uuid (SM:JobUuid): The identifier for a job with a global scope. The identifier is unique for a Job across all service instances of any service type. The UUID URN namespace is specified in rfc4122. The format used for "job-uuid" is the string representation of a UUID as a URN. An example is "urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3". The version (aka subtype) used is implementation specific. Version 1 (i.e. time based) is recommended. Datatype: abstract:char[64], IPP:uri MaxLength=3D64, SM:xs:anyURI maxLen=3D64 =20 Note: I do not believe the IPP attribute "job-uri" is applicable as a globally unique identifier. 1) RFC2911 states "Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.". All uses of the uri syntax is really a URL syntax. 2) URL implies not only a specific protocol binding but also a location. 3) Locations can be specified using an IP address that need not be locally unique (e.g. 192.168.1.1, localhost)=20 4) Regarding the "job-uri" RFC2911 further states that "This URI is then used by clients as the target for subsequent Job operations.". The globally unique identifier for a job should not specify a transport endpoint for a specific protocol.=20=20=20 5) The globally unique identifier for a Job, Printer or Service should be a URN. It should be protocol independent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping. 6) The globally unique identifier for a Job, Printer or Service should require no central authority to administrate them. Generation of a unique identifier should be simple from an administrative point of view and preferably automated. =20 Note: Both the local and global identifiers should be mandated. For legacy protocol mappings (e.g. IPP 1.1, WS-Print, LPR) the local identifier MUST still be maintained. It is possible to use the time_low portion of the Timestamp in the version 1 UUID as the local identifier. The implementation may then keep only the 128 bit local representation of the UUID and use it to create the appropriate protocol values. =20 Printer Identifiers: *existing (Service Monitoring MIB)* applIndex (SM: Id i.e. PrinterId): The service identifier with a local scope. That is the ID is unique across the service instances collocated on a host. Datatype: abstract:int32, MIB:integer, SM:xs:int =20 *new* printer-uuid (SM:ServiceUuid): The identifier for a Printer with a global scope. The identifier is unique across all service instances of any service type. The UUID URN namespace is specified in rfc4122. The format used for "job-uuid" is the string representation of a UUID as a URN. An example is "urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3". The version (aka subtype) used is implementation specific. Version 1 (i.e. time based) is recommended. Datatype: abstract:char[64], IPP:uri, SM:xs:anyURI maxLen=3D64 =20 Note: I do not believe the IPP attribute "printer-uri" is applicable as a globally unique identifier.=20=20 1) RFC2911 states "Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.". All uses of the uri syntax is really a URL syntax. 2) URL implies not only a specific protocol binding but also a location. 3) Locations can be specified using an IP address that need not be locally unique (e.g. 192.168.1.1, localhost)=20 4) The printer may have multiple "printer-uri" values as enumerated in the "printer-uris-supported" attribute. There should be only a single identifier for a printer. 5) The globally unique identifier for a Job, Printer or Service should be a URN. It should be protocol independent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping. 6) The globally unique identifier for a Job, Printer or Service should require no central authority to administrate them. Generation of a unique identifier should be simple from an administrative point of view and preferably automated. =20 =20 Note: The local instance id in the MIB and SM are artifacts of the model's data binding and are insufficient for use as an identifier. IPP's printer-uri, the URL for Web Service bindings (e.g. WS-Print) and the IP address for legacy protocols such as LPR and Port 9100 are also insufficient. They need not be globally unique. Nonroutable IP addresses may be used.=20=20 =20 Printer Location: *existing* printer-location (SM: ServiceLocation): Identifies the location of the device that this Printer represents. (Example: Pete's Office) This is helpful for a human but is pretty much useless for geolocation since the content is implementation specific. Datatype: abstract:char[127], IPP:string MaxLength=3D127, SM:xs:int =20 *new* printer-geo-location (SM:ServiceGeoLocation): This identifies the location of the associated device using the World Geodetic System 1984(WGS84). The means for expressing the location information is the same as used in DNS (rfc1876) Datatype: abstract:class, IPP:collection, SM:sequence =20 *new*(modified) size (SM:Size) (0x00 to 0x99): Diameter of the bounding sphere containing the device expressed in centimeters. Datatype: abstract: int32, IPP:integer, SM:xs:int (Note: representation is 2 encoded 4 bit integers(0-9). Most significant represents the base and the least significant represents the power of 10.)=20=20 =20 *new*(modified) horizontal-precision (SM: HorizontalPrecision) (0x00 to 0x99): The horizontal precision expressed as the diameter of the "circle of error" (i.e. twice the +- error value) The units are centimeters. Datatype: abstract: int32, IPP:integer, SM:xs:int(Note: representation is 2 encoded 4 bit integers(0-9). Most significant represents the base and the least significant represents the power of 10.)=20=20 =20 *new*(modified) vertical-precision (SM: VerticalPrecision) (0x00 to 0x99): The vertical precision expressed as the diameter of the "circle of error" (i.e. twice the +- error value) The units are centimeters. Datatype: abstract:integer, IPP: int32, SM:xs:int(Note: representation is 2 encoded 4 bit integers(0-9). Most significant represents the base and the least significant represents the power of 10.)=20=20 =20 *new* (modified) latitude (SM:Latitude(1823483648 to 4618967296): ): The latitude of the center of the sphere described by the size attribute. Expressed in thousandths of a second of arc. The value 2147483648 (231) represents the equator. Values above that are north and below are south. Datatype: abstract: int32, IPP:integer, SM:xs:int =20 *new* (corrected) (modified) longitude (SM:Latitude) (1499483648 to 4942967296) The longitude of the center of the sphere described by the size attribute. Expressed in thousandths of a second of arc. The value 2147483648 (231) represents the prime meridian. Values above that are east and below are west. The value is rounded away from the prime meridian Datatype: abstract: int32, IPP:integer, SM:xs:int =20 *new* (modified) altitude (SM:Altitude) (0 to MAX): The altitude of the center of the sphere described by the size attribute. Expressed in centimeters from a base of 100,000m below the reference spheroid used by GPS [WGS 84]. Altitude above (or below) sea level may be used as an approximation of altitude relative to the [WGS 84] spheroid, though due to the Earth's surface not being a perfect spheroid, there will be differences. Datatype: abstract: int32, IPP:integer, SM:xs:int =20 Note: There is disagreement on the semantics for all the attributes between what is posted on and what I have in the definition above. I took the definition directly from rfc1876 (I think). See included text from rfc1876 and the location example below.=20=20 =20 =20 =20 Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@Xerox.com =20 Voice: (585) 265-8755 FAX: (585) 265-7441 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701=20 =20 =20 =46rom rfc1876 section 2 =20 =20 SIZE The diameter of a sphere enclosing the described entity, in centimeters, expressed as a pair of four-bit unsigned integers, each ranging from zero to nine, with the most significant four bits representing the base and the second number representing the power of ten by which to multiply the base. This allows sizes from 0e0 (<1cm) to 9e9 (90,000km) to be expressed. This representation was chosen such that the hexadecimal representation can be read by eye; 0x15 =3D 1e5. Four-bit values greater than 9 are undefined, as are values with a base of zero and a non-zero exponent. =20 Since 20000000m (represented by the value 0x29) is greater than the equatorial diameter of the WGS 84 ellipsoid (12756274m), it is therefore suitable for use as a "worldwide" size. =20 HORIZ PRE The horizontal precision of the data, in centimeters, expressed using the same representation as SIZE. This is the diameter of the horizontal "circle of error", rather than a "plus or minus" value. (This was chosen to match the interpretation of SIZE; to get a "plus or minus" value, divide by 2.) =20 VERT PRE The vertical precision of the data, in centimeters, expressed using the sane representation as for SIZE. This is the total potential vertical error, rather than a "plus or minus" value. (This was chosen to match the interpretation of SIZE; to get a "plus or minus" value, divide by 2.) Note that if altitude above or below sea level is used as an approximation for altitude relative to the [WGS 84] ellipsoid, the precision value should be adjusted. =20 LATITUDE The latitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandths of a second of arc. 2^31 represents the equator; numbers above that are north latitude. =20 LONGITUDE The longitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandths of a second of arc, rounded away from the prime meridian. 2^31 represents the prime meridian; numbers above that are east longitude. =20 ALTITUDE The altitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in centimeters, from a base of 100,000m below the [WGS 84] reference spheroid used by GPS (semimajor axis a=3D6378137.0, reciprocal flattening rf=3D298.257223563). Altitude above (or below) sea level may be used as an approximation of altitude relative to the the [WGS 84] spheroid, though due to the Earth's surface not being a perfect spheroid, there will be differences. (For example, the geoid (which sea level approximates) for the continental US ranges from 10 meters to 50 meters below the [WGS 84] spheroid. Adjustments to ALTITUDE and/or VERT PRE will be necessary in most cases. The Defense Mapping Agency publishes geoid height values relative to the [WGS 84] ellipsoid. =20 =20 =20 =20 =20 =20 =20 2-Dimmensional Location of my office printer Google Map URL: http://maps.google.com/maps?f=3Dq&source=3Ds_q&hl=3Den&geocode=3D&q=3D800+p= hillips +rd+webster+ny+14580&sll=3D37.0625,-95.677068&sspn=3D62.226996,106.962891&ie =3DUTF8&hq=3D&hnear=3D800+Phillips+Rd,+Webster,+Monroe,+New+York+14580&ll= =3D43.2 20973,-77.417162&spn=3D0.001781,0.003264&t=3Dh&z=3D19=20 Location representations: Decimal Degrees (WGS84) Latitude Longitude=20 43.220973 -77.417162=20 Degrees, Minutes & Seconds Latitude Longitude=20 N43 13 15 W77 25 01=20 GPS Latitude Longitude=20 N 43 13.258 W 77 25.030=20 UTM X Y=20 18N 303685 4788191=20 =20 My office elevation: 12800 centimeters (419 feet) above sea level Size of Printer: 91 centimeter (3 feet) Margin of error 183 centimeter (6 feet) =20 PrinterGeoLocation (RFC1876) (Corrected) Size =3D 18 (0x12) (encoded centimeter) (corrected) HorizontalPrecision =3D 34 (0x22) (encoded centimeter) (corrected) VerticalPrecision =3D 34 (0x22) (encoded centimeter) (corrected) Latitude =3D 2303079151 (thousandths of a second of arc, 231 represent equater) ( (DecimalDegreeLatitude*60*60*1000)+2147483648 ) Longitude =3D 1868781865 (thousandths of a second of arc, 231 represent prime meridian) ( 2147483648-(DecimalDegreeLongitude*60*60*1000) ) Altitude =3D 10012800 (centimeter) (OfficeElevation+10000000) =20 =20 --=20 This message has been scanned for viruses and=20 dangerous content by MailScanner , and is believed to be clean.=20 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------_=_NextPart_001_01CB2CB9.10DE0B95 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My comments are  in= line below

 =

 =

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@X= erox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

 =

From: Tom Hastings [mailto:tom.hastings@verizon.net]
Sent: Monday, July 26, 2010 1:11 AM
To: Zehler, Peter; ipp@pwg.org; mfd@pwg.org; cloud@pwg.org
Subject: RE: [IPP] Attributes needed for Cloud Printing and definiti= on inconsistencies [4 questions about the representation of the values]

 

Pete,

 

I have 4 questions about your proposed IPP attributes for Geo Location for Cloud Printing:

 

1. The representation of the values of your proposed IPP “size”, “horizontal-pr= ecision”, and “vertical-precision” attributes are completely different from the representation of the same attributes in RFC1876.

<PZ>I made a mistake in my values.  I us= ed 8 bit unsigned integers instead of 4 bit.  The values should be; Size=3D= 18 (0x12), HorizontalPrecision=3D34 (0x22), VerticalPrecision=3D34 (0x22).  (This= is why I really don’t like this representation.  That and the fact that= for the dimensions associated with MFDs it is not as precise a expressing it in= simple centimeters)</PZ>

 

If this difference is intentional, it would be good to explain = the difference and why and to indicate this intended difference in the spec?

 

As I read RFC 1876, the representation of the SIZE, HORIZ PRE, = and VERT PRE attributes are all using this funny SIZE representation as a pair = of four-bit unsigned integers, where the most significant 4-bit unsigned integ= er represents the base and the second 4-bit integer represents the power of 10= by which to multiple the base, sort of a compressed floating point representat= ion, but using power of 10, not power of 2.  The reason give in RFC 1876 is= so that the value is more easily human readable.  HORIZ PRE and VERT PRE = attributes defined in RFC 1876, say:

 

expressed using the same representation as =
SIZE

i.e., using this same 8-bit “floating point” representation.

 

BTW, the V=
ERT PRE attribute has an ironic Freudian slip typo in RFC 1876, since I don=
’t find this representation very sane L:
expres=
sed using the sane representation as for SIZE

 

 

2. The definitions on the <= ;http://pwg-wiki.wikispa= ces.com/Geolocation> appear to be part of the PWG Semantic Model:

 

This page proposes an IPP collection representing the DNS LOC data defined in RFC 1876 .
printer-ge= o-location (collection)
The "printer-geo-location" attribute provides the physical locati= on of the printer. The collection has the following member attributes.
size (inte= ger (0:MAX))

Diameter of enclosing sphere for pri= nter in centimeters. 0 represents any size less than one centimeter.
horizontal= -precision (integer (0:MAX))

The circle of error of the latitude = and longitude measurement in centimeters. 0 represents an error of less than one centimeter.
vertical-p= recision (integer(0:MAX))

The circle of error of the altitude measurement in centimeters. 0 represents an error of less than one centimet= er.
latitude (integer(-324000000:324000000))

The latitude in thousandths of arc seconds from the equator. 0 represents the equator, positive values represe= nt locations North of the equator, and negative values represent locations Sou= th of the equator.
longitude (integer(-648000000:648000000))

The longitude in thousandths of arc seconds from the prime meridian. 0 represents the prime meridian, positive values represent locations East of the meridian, and negative values repres= ent locations West of the meridian.
altitude (integer(-100000:MAX))

The distance in centimeters from the WGS-84 ellipsoid to the center of the enclosing sphere defined by the "side" member attribute. 0 represents the WGS-84 ellipsoid height, positive values represent locations above the ellipsoid, and negative value= s represent locations below the ellipsoid.

 

The PWG SM definitions appear to use signed 32-bit integer nota= tion and description which have the same bit representation as the unsigned 32-b= it integer notation and description in RFC 1876, right?  Why change to use the unsigned integer notation and descriptions, when the rest of the SM and= IPP use signed integer notations and descriptions?

<PZ>To the best of my knowledge printer-geo-l= ocation  is not part of the PWG semantic model yet.  I put out this mail note to test my understanding of the proposal on the wiki site.  I want to be = sure the semantics and syntax are well defined and the mapping to rfc1876 is clear.</PZ>

 

 

3. What is the relationship between Cloud Printing (which these definitions are proposed for) and IPP Everywhere?

<PZ>Cloud Printing can be implemented without= IPP Everywhere.  The initial implementations will not be using IPP or IPP Everywhere.  It will be cobbled together with existing technologies us= ed in Web Services, messaging protocols, standard document formats and print driver related technologies.  IPP could play a role in this environment but I believe it is most critical to obtain semantic alignment between IPP = and the emerging Cloud Printing technologies.  IPP Everywhere addresses a number of IPP shortcomings such as printer discovery, common document forma= ts, and interoperable security.  IPP Everywhere could apply to Cloud Print= ing but would require some extensions to accommodate intervening firewalls.<= /PZ>

 

 

4. I like the idea used in IPP and the SM to have the data type indicate the range of values in the definition of the attribute name and attribute syntax, i.e., latitude (integer(-324000000:324000000)).  Why isn’t this technique of specifying the data type and the data type ra= nge used in your proposal for attributes needed for Cloud Printing?<= /span>

<PZ>Added to defin= itions below.</PZ>

 

Tom


From: ipp-bounces@p= wg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Zehler, Peter
Sent: Thursday, July 22, 2010 11:48
To: ipp@pwg.org; mfd@pwg.org
Subject: [IPP] Attributes needed for Cloud Printing and definition inconsistencies

 

Job Identifiers:

*existing*

job-id (SM: JobId): The identifier for a job with a lo= cal scope.  That is the ID is unique within the service.  The ID may = be reused in other instance of a Printer (i.e. Print Service)  or for job= s in other types of services (e.g. Copy Service).  Datatype: abstract:int32, IPP:integer, SM:xs:int

 

*new*

job-uuid (SM:JobUuid):  The identifier for a job = with a global scope.  The identifier is unique for a Job across all service instances of any service type.    The UUID URN namespace is specified in rfc4122.  The format used for “job-uuid” is t= he string representation of a UUID as a URN.  An example is “urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3”.  The version (aka subtype) used is implementation specific.  Version 1 (i.e. time based) is recommended.   Datatype: abstract:char[64], IPP:uri MaxLength=3D64, SM:xs:anyURI maxLen=3D64

 

Note:  I do not believe the IPP attribute “job-uri” is applicable as a globally unique identifier.

1)&n= bsp;     RFC2911 states “Since every URL is a speciali= zed form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific not= ion of URL as well.”.   All uses of the uri syntax is really a = URL syntax.

2)&n= bsp;     URL implies not only a specific protocol binding but also a location.

3)&n= bsp;     Locations can be specified using an IP address that need not be locally unique (e.g. 192.168.1.1, localhost)

4)&n= bsp;     Regarding the “job-uri” RFC2911  f= urther states that “This URI is then used by clients as the target for subsequent Job operations.”.  The globally unique identifier for= a job should not specify a transport endpoint for a specific protocol.  

5)&n= bsp;     The globally unique identifier for a Job, Printer or Service should be a URN.  It should be protocol independent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping.

6)&n= bsp;     The  globally unique identifier for a Job, Pri= nter or Service should require no central authority to administrate them.  Generation of a unique identifier should be simple from an administrative p= oint of view and preferably automated.

 

Note: Both the local and global identifiers should be mandated.  For legacy protocol mappings (e.g. IPP 1.1, WS-Print, LPR) = the local identifier MUST still be maintained.  It is possible to use the time_low portion of the Timestamp in the version 1 UUID as the local identifier.  The implementation may then keep only the 128 bit local representation of the UUID and use it to create the appropriate protocol values.

 

Printer Identifier= s:

*existing (Service Monitoring MIB)*<= /p>

applIndex (SM: <service>Id i.e. PrinterId): The service identifier with a local scope.  That is the ID is unique across the service instances collocated on a host.  Datatype: abstract:int32, MIB:integer, SM:xs:int

 

*new*

printer-uuid (SM:ServiceUuid):  The identifier fo= r a Printer with a global scope.  The identifier is unique across all serv= ice instances of any service type.    The UUID URN namespace is specified in rfc4122.  The format used for “job-uuid” is t= he string representation of a UUID as a URN.  An example is “urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3”.  The version (aka subtype) used is implementation specific.  Version 1 (i.e. time based) is recommended.   Datatype: abstract:char[64], IPP:uri, SM:xs:anyURI maxLen=3D64

 

Note:  I do not believe the IPP attribute “printer-uri” is applicable as a globally unique identifier.&nb= sp;

1)&n= bsp;     RFC2911 states “Since every URL is a speciali= zed form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific not= ion of URL as well.”.   All uses of the uri syntax is really a = URL syntax.

2)&n= bsp;     URL implies not only a specific protocol binding but also a location.

3)&n= bsp;     Locations can be specified using an IP address that need not be locally unique (e.g. 192.168.1.1, localhost)

4)&n= bsp;     The printer may have multiple “printer-uri= 221; values as enumerated in the “printer-uris-supported” attribute.  There should be only a single  identifier for a print= er.

5)&n= bsp;     The globally unique identifier for a Job, Printer or Service should be a URN.  It should be protocol independent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping.

6)&n= bsp;     The  globally unique identifier for a Job, Pri= nter or Service should require no central authority to administrate them.  Generation of a unique identifier should be simple from an administrative p= oint of view and preferably automated.

 

 

Note: The local instance id in the MIB and SM are arti= facts of the model’s data binding and are insufficient for use as an identifier.  IPP’s printer-uri, the URL for Web Service bindings (e.g. WS-Print) and the IP address for legacy protocols such as LPR and Port 9100 are also insufficient.  They need not be globally unique.  Nonroutable IP addresses may be used. 

 

Printer Location:<= o:p>

*existing*

printer-location (SM: ServiceLocation): Identifies the location of the device that this Printer represents.  (Example: Pete’s Office)  This is helpful for a human but is pretty much useless for geolocation since the content is implementation specific.   Datatype: abstract:char[127], IPP:string MaxLength=3D127, SM:xs:int

 

*new*

printer-geo-location (SM:ServiceGeoLocation):  Th= is identifies the location of the associated device using the World Geodetic System 1984(WGS84).  The means for expressing the location information= is the same as used in DNS (rfc1876)  Datatype: abstract:class, IPP:collection, SM:sequence

 

*new*(modified)

size (SM:Size) (0x00 to 0x99):  Diameter of the bound= ing sphere containing the device expressed in centimeters.    Datatype: abstract: int32, IPP:integer, SM:xs:int  (Note: representation is 2 encoded 4 bit int= egers(0-9).  Most significant represents the base and the least significant represents t= he power of 10.)  

 

*new*(modified)

horizontal-precision (SM: HorizontalPrecision) (0x00 to 0x99):&n= bsp; The horizontal precision expressed as the diameter of the “circle of error” (i.e. twice the +- error value)  The units are centimeters.    Datatype: abstract: int32, IPP:integer, SM:xs:int(Note: representation is 2 encoded 4= bit integers(0-9).  Most significant represents the base and the least significant represents the power of 10.)  

 

*new*(modified)

vertical-precision (SM: VerticalPrecision) (0x00 to 0x99):&nbs= p; The vertical precision expressed as the diameter of the “circle of error” (i.e. twice the +- error value)  The units are centimeters.    Datatype: abstract:integer, IPP: int32, SM:xs:int(Note: representation is 2 encoded 4= bit integers(0-9).  Most significant represents the base and the least significant represents the power of 10.)  

 

*new* (modified)

latitude (SM:Latitude(1823483648 to 4618967296): ):  The latitude of the center of the sphere described by the size attribute.  Expressed in thousandths of a second of arc.  The value 2147483648  (231) represents the equator.  Values above that are north and below are south.   Datatype: abstract: int32, IPP:integ= er, SM:xs:int

 

*new* (corrected) (modified)

longitude (SM:Latitude) (1499483648  to 4942967296) The longit= ude of the center of the sphere described by the size attribute.  Expressed in thousandths of a second of arc.  The value 2147483648  (231<= /sup>) represents the prime meridian.  Values above that are east and below a= re west.  The value is rounded away from t= he prime meridian   Datatype: abstract: int32, IPP:integer, SM:xs:in= t

 

*new* (modified)

altitude (SM:Altitude) (0 to MAX):  The altitude of the cente= r of the sphere described by the size attribute.  Expressed in centimeters = from a base of 100,000m below the reference spheroid used by GPS [WGS 84].  Altitude above (or below) sea level may be used as an approximation of alti= tude relative to the [WGS 84] spheroid, though due to the Earth's surface not be= ing a perfect spheroid, there will be differences.    Datatype: abstract: int32, IPP:integer, SM:xs:int

 

Note:  There is disagreement on the semantics for= all the attributes between what is posted on <http://pwg-wiki.wikispa= ces.com/Geolocation>  and what I have in the definition above.  I took the definition directly from rfc1876 (I think).  See included text from rfc1876 and t= he location example below. 

 

 

 =

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xe= rox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

 =

 =

From rfc1876 section 2 &= lt;http://www.rfc-editor.or= g/rfc/rfc1876.txt>

 =

SIZE         The diameter of a sphere enclosing the described entity, in

           &nbs= p; centimeters, expressed as a pair of four-bit unsigned

           &nbs= p; integers, each ranging from zero to nine, with the most

           &nbs= p; significant four bits representing the base and the second

           &nbs= p; number representing the power of ten by which to multiply=

             the base.  This allows sizes from 0e0 (<1cm) to 9e9

           &nbs= p; (90,000km) to be expressed.  This representation was chosen=

           &nbs= p; such that the hexadecimal representation can be read by

           &nbs= p; eye; 0x15 =3D 1e5.  Four-bit values greater than 9 are

           &nbs= p; undefined, as are values with a base of zero and a non-zero

           &nbs= p; exponent.

 

           &nbs= p; Since 20000000m (represented by the value 0x29) is greater

           &nbs= p; than the equatorial diameter of the WGS 84 ellipsoid

             (12756274m), it is therefore suitable for use= as a

           &nbs= p; "worldwide" size.

 

HORIZ PRE    The horizontal precision of the data, in centimeters,=

           &nbs= p; expressed using the same representation as SIZE.  This is

           &nbs= p; the diameter of the horizontal "circle of error", rather

           &nbs=
p; than a "plus or minus" value.  (This was chosen to match<=
o:p>
         =
    the interpretation of SIZE; to get a "plus or minus=
" value,
      &nbs=
p;      divide by 2.)
&n=
bsp;
VERT PRE     The vertical precisio=
n of the data, in centimeters,
    =
;         expressed using the sane =
representation as for SIZE.  This
  &nb=
sp;          is the total pote=
ntial vertical error, rather than a "plus
 &=
nbsp;           or minus&=
quot; value.  (This was chosen to match the
 =
;            interpr=
etation of SIZE; to get a "plus or minus" value,
=
           &nbs=
p; divide by 2.)  Note that if altitude above or below sea<=
/pre>
           =
;  level is used as an approximation for altitude relative to
          &n=
bsp;  the [WGS 84] ellipsoid, the precision value should be=
           &nb=
sp; adjusted.
 
LATITUD=
E     The latitude of the center of the sphere describe=
d by the
       &nb=
sp;     SIZE field, expressed as a 32-bit integer, most=
 significant
       =
;      octet first (network standard byte order), =
in thousandths
      &nb=
sp;      of a second of arc.  2^31 represents=
 the equator; numbers
     &n=
bsp;       above that are north latitude.
 
LONGITUDE    T=
he longitude of the center of the sphere described by the
<= pre>            = ; SIZE field, expressed as a 32-bit integer, most significant
           &=
nbsp; octet first (network standard byte order), in thousandths<=
/pre>
           =
;  of a second of arc, rounded away from the prime meridian.
          &nb=
sp;  2^31 represents the prime meridian; numbers above that are
          =
   east longitude.
 
ALTITUDE     The altitude of the center of the spher= e described by the
      =
;       SIZE field, expressed as a 32-bit int=
eger, most significant
     &=
nbsp;       octet first (network standard byt=
e order), in centimeters,
    &nbs=
p;        from a base of 100,000m below =
the [WGS 84] reference
     &=
nbsp;       spheroid used by GPS (semimajor a=
xis a=3D6378137.0,
      =
;       reciprocal flattening rf=3D298.257223=
563).  Altitude above
    &nb=
sp;        (or below) sea level may be u=
sed as an approximation of
    &nb=
sp;        altitude relative to the the =
[WGS 84] spheroid, though due
    =
         to the Earth's surface not=
 being a perfect spheroid, there
   &nb=
sp;         will be differences.&nb=
sp; (For example, the geoid (which sea
  &nb=
sp;          level approximate=
s) for the continental US ranges from 10
  &=
nbsp;          meters to 50 me=
ters below the [WGS 84] spheroid.
   &n=
bsp;         Adjustments to ALTITUD=
E and/or VERT PRE will be necessary
   =
          in most cases. =
 The Defense Mapping Agency publishes geoid
 &nbs=
p;           height value=
s relative to the [WGS 84] ellipsoid.
 

 

 =

 =

 =

 =

 =

2-Dimmensional Location of my office printer<= /b>

Google Map = URL:

http://maps.google.com= /maps?f=3Dq&source=3Ds_q&hl=3Den&geocode=3D&q=3D800+phillip= s+rd+webster+ny+14580&sll=3D37.0625,-95.677068&sspn=3D62.226996,106= .962891&ie=3DUTF8&hq=3D&hnear=3D800+Phillips+Rd,+Webster,+Monro= e,+New+York+14580&ll=3D43.220973,-77.417162&spn=3D0.001781,0.003264= &t=3Dh&z=3D19

Location representations:

Decimal Deg= rees (WGS84)

Latitude Longitude =
43.220973 -77.417162

Degrees, Mi= nutes & Seconds

Latitude Longitude =
N43 13 15 W77 25 01

GPS

Latitude Longitude =
N 43 13.258 W 77 25.030

UTM

 X Y

18N 303685 4788191 =

 

My office elevation:

12800 centimeters (= 419 feet) above sea level

Size of Printer:

91 centimeter (3 fe= et)

Margin of error

183 centimeter (6 f= eet)

 

PrinterGeoLocation (RFC1876) (Correct= ed)

Size =3D 18 (0x12) (encoded centimeter) (corrected)
HorizontalPrecision =3D 34 (0x22)  (encoded centimeter) (corrected)=
VerticalPrecision =3D 34 (0x22)  = (encoded centimeter) (corrected)

Latitude =3D 230307= 9151 (thousandths of a second of arc, 231 represent equater)  ( (DecimalDegreeLatitude*60*60*1000)+2147483648 )

Longitude =3D 18687= 81865 (thousandths of a second of arc, 231 represent prime meridian) <= span style=3D'font-size:10.0pt'>( 2147483648-(DecimalDegreeLongitude*60*60*1000)= )
Altitude =3D 10012800 (centimeter)  (OfficeElevation+10000000)<= o:p>

 

 


--
This message has been scanned for viruses and
dangerous content by MailScanne= r, and is
believed to be clean.


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------_=_NextPart_001_01CB2CB9.10DE0B95-- --===============1496505575== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1496505575==-- From ipp-bounces@pwg.org Mon Jul 26 08:58:21 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C0F3A6AC8 for ; Mon, 26 Jul 2010 08:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.771 X-Spam-Level: X-Spam-Status: No, score=0.771 tagged_above=-999 required=5 tests=[AWL=0.769, BAYES_50=0.001, 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 oZmXSIGGSGjQ for ; Mon, 26 Jul 2010 08:58:18 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id E8E733A6C3A for ; Mon, 26 Jul 2010 08:58:15 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 52AFD792FA; Mon, 26 Jul 2010 11:58:31 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from wvmler5.mail.xerox.com (wvmler5.mail.xerox.com [13.8.138.230]) by pwg.org (Postfix) with ESMTP id 677C2792F6 for ; Mon, 26 Jul 2010 11:58:28 -0400 (EDT) Received: from wvmlir1.mail.xerox.com (wvmlir1.mail.xerox.com [13.147.8.221]) by wvmler5.mail.xerox.com (8.14.4/8.13.8) with ESMTP id o6QFwRJ1025269 for ; Mon, 26 Jul 2010 08:58:27 -0700 Received: from wvmlir1.mail.xerox.com (localhost.localdomain [127.0.0.1]) by wvmlir1.mail.xerox.com (8.14.4/8.13.6) with ESMTP id o6QFwP6T015659 for ; Mon, 26 Jul 2010 08:58:25 -0700 Received: from USA7061GW002.na.xerox.net (usa7061gw002.na.xerox.net [13.151.210.15]) by wvmlir1.mail.xerox.com (8.14.4/8.13.6) with ESMTP id o6QFwMnN015531 for ; Mon, 26 Jul 2010 08:58:25 -0700 X-XeroxINT-Source-Ip: 13.151.210.15 X-XeroxINT-Source-Name: usa7061gw002.na.xerox.net X-XeroxINT-Reported-Name: USA7061GW002.na.xerox.net Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA7061GW002.na.xerox.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 08:58:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Jul 2010 08:58:18 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LiveMeeting information for 7/19 teleconference Thread-Index: Acss212FxyrhmYnkQNaUduBOqcPM8w== From: "Zehler, Peter" To: X-OriginalArrivalTime: 26 Jul 2010 15:58:19.0789 (UTC) FILETIME=[5E1203D0:01CB2CDB] X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] LiveMeeting information for 7/19 teleconference X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1649355670==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 52AFD792FA.A9735 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============1649355670== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2CDB.5E1D1B4C" This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2CDB.5E1D1B4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Attendee: Join the meeting. =20=20 =20 First Time Users:=20 To save time before the meeting, check your system to make sure it is ready to use Microsoft Office Live Meeting.=20 Troubleshooting Unable to join the meeting? Follow these steps:=20 =20 1. Copy this address and paste it into your web browser:=20 https://www.livemeeting.com/cc/xerox/join=20 2. Copy and paste the required information:=20 Meeting ID: PwgIpp726=20 Entry Code: LetMeIn=20 Location: https://www.livemeeting.com/cc/xerox=20 =20 =20 =20 =20 =20 =20 Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@Xerox.com Voice: (585) 265-8755 FAX: (585) 265-7441 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701=20 =20 =20 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------_=_NextPart_001_01CB2CDB.5E1D1B4C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Attendee:

= Join the meeting.
<https://www.livemeeting.com/cc/xerox/join?id=3D= PwgIpp726&role=3Dattend&pw=3DLetMeIn>

First Time Users:
T= o save time before the meeting, check your system to make sure it is ready to use Microsoft Office Live Meeti= ng.
Troubleshooting
U= nable to join the meeting? Follow these steps:

 

1.      Copy this addr= ess and paste it into your web browser:
https://www.livemeeting.= com/cc/xerox/join

2.      Copy and paste= the required information:
M= eeting ID: PwgIpp726
E= ntry Code: LetMeIn
L= ocation: https://www.livemeeting.co= m/cc/xerox

 <= /span>

 

 

 

 

 =

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@X= erox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

 

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------_=_NextPart_001_01CB2CDB.5E1D1B4C-- --===============1649355670== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1649355670==-- From ipp-bounces@pwg.org Mon Jul 26 09:54:41 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7163A6A12 for ; Mon, 26 Jul 2010 09:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.272 X-Spam-Level: X-Spam-Status: No, score=0.272 tagged_above=-999 required=5 tests=[AWL=-2.129, BAYES_50=0.001, J_CHICKENPOX_28=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=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 xvPlPDxM4aiq for ; Mon, 26 Jul 2010 09:54:39 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id C79323A68C0 for ; Mon, 26 Jul 2010 09:54:38 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id BE69979303; Mon, 26 Jul 2010 12:54:48 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-vw0-f46.google.com (mail-vw0-f46.google.com [209.85.212.46]) by pwg.org (Postfix) with ESMTP id 1586D79303; Mon, 26 Jul 2010 12:54:38 -0400 (EDT) Received: by vws3 with SMTP id 3so2755325vws.5 for ; Mon, 26 Jul 2010 09:54: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:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MesG1IA/NPceM+NnLGKZfxhX2jZsJ+8XwxXx7z+o2Gw=; b=KU+3kioAvj0MnyPddHCu8pYfEGdi8OL8BBky32A3142t8sj0qK9N9EGOQZQwOy5DrQ 8nOQdWjFlIH2gn2fafuR0NXrkUuPni5ovNc0TyvU5NGse7u1k7fbh6a81bOrn/ueKxlL VjJRNGbfjiK0qJnrG3KkSRByKAsPMrY9qU7AI= 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=x9OuSzeVDOgD22XK/UUtLE5UrSjTH6PS4Y+hNaqhZxJOXd64crPJEGnUAES2CTmnCH alCCmlI8Iz9SG9Xd/rhiR+M3qdmKbdaSptNNe3bLgSG0cFpoqS8+wyinyw4wlE0aXZ9h JPGrIK7PEYth3T+VmlhkYhJQ8005LYKj+Adnw= MIME-Version: 1.0 Received: by 10.220.95.199 with SMTP id e7mr4358607vcn.278.1280163278100; Mon, 26 Jul 2010 09:54:38 -0700 (PDT) Received: by 10.220.78.25 with HTTP; Mon, 26 Jul 2010 09:54:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Jul 2010 12:54:37 -0400 Message-ID: Subject: Re: [MFD] RE: [IPP] Attributes needed for Cloud Printing and definition inconsistencies [4 questions about the representation of the values] From: Ira McDonald To: "Zehler, Peter" , Ira McDonald Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-pwg-MailScanner: Found to be clean, Found to be clean Cc: ipp@pwg.org, cloud@pwg.org, mfd@pwg.org X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: BE69979303.A9D5C X-pwg-MailScanner-From: ipp-bounces@pwg.org Hi, The "printer-geo-location" attributes on that Wiki were written by Mike Sweet and intended *specifically* for the IPP Everywhere project. They can certainly be added to PWG SM XML Schema and used for Cloud Printing, but *in IPP specs* they'll be documented in the single IPP Everywhere Protocol spec (*after* we complete the IPP Everywhere Requirements spec mandated by our project charter). Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - TCG Hardcopy WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com winter: =A0 579 Park Place=A0 Saline, MI=A0 48176 =A0 734-944-0094 summer: =A0 PO Box 221=A0 Grand Marais, MI 49839 =A0 906-494-2434 On Mon, Jul 26, 2010 at 7:52 AM, Zehler, Peter wro= te: > My comments are =A0inline below > > > > > > Peter Zehler > > Xerox Research Center Webster > Email: Peter.Zehler@Xerox.com > Voice: (585) 265-8755 > FAX: (585) 265-7441 > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > M/S 128-25E > Webster NY, 14580-9701 > > > > From: Tom Hastings [mailto:tom.hastings@verizon.net] > Sent: Monday, July 26, 2010 1:11 AM > To: Zehler, Peter; ipp@pwg.org; mfd@pwg.org; cloud@pwg.org > Subject: RE: [IPP] Attributes needed for Cloud Printing and definition > inconsistencies [4 questions about the representation of the values] > > > > Pete, > > > > I have 4 questions about your proposed IPP attributes for Geo Location for > Cloud Printing: > > > > 1. The representation of the values of your proposed IPP =93size=94, > =93horizontal-precision=94, and =93vertical-precision=94 attributes are c= ompletely > different from the representation of the same attributes in RFC1876. > > I made a mistake in my values.=A0 I used 8 bit unsigned integers inst= ead > of 4 bit.=A0 The values should be; Size=3D 18 (0x12), HorizontalPrecision= =3D34 > (0x22), VerticalPrecision=3D34 (0x22).=A0 (This is why I really don=92t l= ike this > representation.=A0 That and the fact that for the dimensions associated w= ith > MFDs it is not as precise a expressing it in simple centimeters) > > > > If this difference is intentional, it would be good to explain the > difference and why and to indicate this intended difference in the spec? > > > > As I read RFC 1876, the representation of the SIZE, HORIZ PRE, and VERT P= RE > attributes are all using this funny SIZE representation as a pair of > four-bit unsigned integers, where the most significant 4-bit unsigned > integer represents the base and the second 4-bit integer represents the > power of 10 by which to multiple the base, sort of a compressed floating > point representation, but using power of 10, not power of 2.=A0 The reason > give in RFC 1876 is so that the value is more easily human readable.=A0 H= ORIZ > PRE and VERT PRE attributes defined in RFC 1876, say: > > > > expressed using the same representation as SIZE > > i.e., using this same 8-bit =93floating point=94 representation. > > > > BTW, the VERT PRE attribute has an ironic Freudian slip typo in RFC 1876, > since I don=92t find this representation very sane L: > > expressed using the sane representation as for SIZE > > > > > > 2. The definitions on the > appear to be part of the PWG Semantic Model: > > > > This page proposes an IPP collection representing the DNS LOC data defined > in RFC 1876 . > printer-geo-location (collection) > The "printer-geo-location" attribute provides the physical location of the > printer. The collection has the following member attributes. > size (integer (0:MAX)) > > Diameter of enclosing sphere for printer in centimeters. 0 represents any > size less than one centimeter. > horizontal-precision (integer (0:MAX)) > > The circle of error of the latitude and longitude measurement in > centimeters. 0 represents an error of less than one centimeter. > vertical-precision (integer(0:MAX)) > > The circle of error of the altitude measurement in centimeters. 0 represe= nts > an error of less than one centimeter. > latitude (integer(-324000000:324000000)) > > The latitude in thousandths of arc seconds from the equator. 0 represents > the equator, positive values represent locations North of the equator, and > negative values represent locations South of the equator. > longitude (integer(-648000000:648000000)) > > The longitude in thousandths of arc seconds from the prime meridian. 0 > represents the prime meridian, positive values represent locations East of > the meridian, and negative values represent locations West of the meridia= n. > altitude (integer(-100000:MAX)) > > The distance in centimeters from the WGS-84 ellipsoid to the center of the > enclosing sphere defined by the "side" member attribute. 0 represents the > WGS-84 ellipsoid height, positive values represent locations above the > ellipsoid, and negative values represent locations below the ellipsoid. > > > > The PWG SM definitions appear to use signed 32-bit integer notation and > description which have the same bit representation as the unsigned 32-bit > integer notation and description in RFC 1876, right?=A0 Why change to use= the > unsigned integer notation and descriptions, when the rest of the SM and I= PP > use signed integer notations and descriptions? > > To the best of my knowledge printer-geo-location=A0 is not part of th= e PWG > semantic model yet.=A0 I put out this mail note to test my understanding = of > the proposal on the wiki site.=A0 I want to be sure the semantics and syn= tax > are well defined and the mapping to rfc1876 is clear. > > > > > > 3. What is the relationship between Cloud Printing (which these definitio= ns > are proposed for) and IPP Everywhere? > > Cloud Printing can be implemented without IPP Everywhere.=A0 The init= ial > implementations will not be using IPP or IPP Everywhere.=A0 It will be co= bbled > together with existing technologies used in Web Services, messaging > protocols, standard document formats and print driver related technologie= s. > IPP could play a role in this environment but I believe it is most critic= al > to obtain semantic alignment between IPP and the emerging Cloud Printing > technologies.=A0 IPP Everywhere addresses a number of IPP shortcomings su= ch as > printer discovery, common document formats, and interoperable security.= =A0 IPP > Everywhere could apply to Cloud Printing but would require some extensions > to accommodate intervening firewalls. > > > > > > 4. I like the idea used in IPP and the SM to have the data type indicate = the > range of values in the definition of the attribute name and attribute > syntax, i.e., latitude (integer(-324000000:324000000)).=A0 Why isn=92t th= is > technique of specifying the data type and the data type range used in your > proposal for attributes needed for Cloud Printing? > > Added to definitions below. > > > > Tom > > ________________________________ > > From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Zehle= r, > Peter > Sent: Thursday, July 22, 2010 11:48 > To: ipp@pwg.org; mfd@pwg.org > Subject: [IPP] Attributes needed for Cloud Printing and definition > inconsistencies > > > > Job Identifiers: > > *existing* > > job-id (SM: JobId): The identifier for a job with a local scope.=A0 That = is > the ID is unique within the service.=A0 The ID may be reused in other ins= tance > of a Printer (i.e. Print Service)=A0 or for jobs in other types of servic= es > (e.g. Copy Service).=A0 Datatype: abstract:int32, IPP:integer, SM:xs:int > > > > *new* > > job-uuid (SM:JobUuid):=A0 The identifier for a job with a global scope.= =A0 The > identifier is unique for a Job across all service instances of any service > type.=A0=A0=A0 The UUID URN namespace is specified in rfc4122.=A0 The for= mat used > for =93job-uuid=94 is the string representation of a UUID as a URN.=A0 An= example > is =93urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3=94.=A0 The version (a= ka > subtype) used is implementation specific.=A0 Version 1 (i.e. time based) = is > recommended.=A0=A0 Datatype: abstract:char[64], IPP:uri MaxLength=3D64, > SM:xs:anyURI maxLen=3D64 > > > > Note:=A0 I do not believe the IPP attribute =93job-uri=94 is applicable a= s a > globally unique identifier. > > 1)=A0=A0=A0=A0=A0 RFC2911 states =93Since every URL is a specialized form= of a URI, even > though the more generic term URI is used throughout the rest of this > document, its usage is intended to cover the more specific notion of URL = as > well.=94.=A0=A0 All uses of the uri syntax is really a URL syntax. > > 2)=A0=A0=A0=A0=A0 URL implies not only a specific protocol binding but al= so a > location. > > 3)=A0=A0=A0=A0=A0 Locations can be specified using an IP address that nee= d not be > locally unique (e.g. 192.168.1.1, localhost) > > 4)=A0=A0=A0=A0=A0 Regarding the =93job-uri=94 RFC2911=A0 further states t= hat =93This URI is > then used by clients as the target for subsequent Job operations.=94.=A0 = The > globally unique identifier for a job should not specify a transport endpo= int > for a specific protocol. > > 5)=A0=A0=A0=A0=A0 The globally unique identifier for a Job, Printer or Se= rvice should > be a URN.=A0 It should be protocol independent so that a product that sup= ports > multiple protocols should have the same identifiers regardless of the > protocol mapping. > > 6)=A0=A0=A0=A0=A0 The=A0 globally unique identifier for a Job, Printer or= Service should > require no central authority to administrate them.=A0 Generation of a uni= que > identifier should be simple from an administrative point of view and > preferably automated. > > > > Note: Both the local and global identifiers should be mandated.=A0 For le= gacy > protocol mappings (e.g. IPP 1.1, WS-Print, LPR) the local identifier MUST > still be maintained.=A0 It is possible to use the time_low portion of the > Timestamp in the version 1 UUID as the local identifier.=A0 The implement= ation > may then keep only the 128 bit local representation of the UUID and use it > to create the appropriate protocol values. > > > > Printer Identifiers: > > *existing (Service Monitoring MIB)* > > applIndex (SM: Id i.e. PrinterId): The service identifier with a > local scope.=A0 That is the ID is unique across the service instances > collocated on a host.=A0 Datatype: abstract:int32, MIB:integer, SM:xs:int > > > > *new* > > printer-uuid (SM:ServiceUuid):=A0 The identifier for a Printer with a glo= bal > scope.=A0 The identifier is unique across all service instances of any se= rvice > type.=A0=A0=A0 The UUID URN namespace is specified in rfc4122.=A0 The for= mat used > for =93job-uuid=94 is the string representation of a UUID as a URN.=A0 An= example > is =93urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3=94.=A0 The version (a= ka > subtype) used is implementation specific.=A0 Version 1 (i.e. time based) = is > recommended.=A0=A0 Datatype: abstract:char[64], IPP:uri, SM:xs:anyURI max= Len=3D64 > > > > Note:=A0 I do not believe the IPP attribute =93printer-uri=94 is applicab= le as a > globally unique identifier. > > 1)=A0=A0=A0=A0=A0 RFC2911 states =93Since every URL is a specialized form= of a URI, even > though the more generic term URI is used throughout the rest of this > document, its usage is intended to cover the more specific notion of URL = as > well.=94.=A0=A0 All uses of the uri syntax is really a URL syntax. > > 2)=A0=A0=A0=A0=A0 URL implies not only a specific protocol binding but al= so a > location. > > 3)=A0=A0=A0=A0=A0 Locations can be specified using an IP address that nee= d not be > locally unique (e.g. 192.168.1.1, localhost) > > 4)=A0=A0=A0=A0=A0 The printer may have multiple =93printer-uri=94 values = as enumerated in > the =93printer-uris-supported=94 attribute.=A0 There should be only a sin= gle > =A0identifier for a printer. > > 5)=A0=A0=A0=A0=A0 The globally unique identifier for a Job, Printer or Se= rvice should > be a URN.=A0 It should be protocol independent so that a product that sup= ports > multiple protocols should have the same identifiers regardless of the > protocol mapping. > > 6)=A0=A0=A0=A0=A0 The=A0 globally unique identifier for a Job, Printer or= Service should > require no central authority to administrate them.=A0 Generation of a uni= que > identifier should be simple from an administrative point of view and > preferably automated. > > > > > > Note: The local instance id in the MIB and SM are artifacts of the model= =92s > data binding and are insufficient for use as an identifier.=A0 IPP=92s > printer-uri, the URL for Web Service bindings (e.g. WS-Print) and the IP > address for legacy protocols such as LPR and Port 9100 are also > insufficient.=A0 They need not be globally unique.=A0 Nonroutable IP addr= esses > may be used. > > > > Printer Location: > > *existing* > > printer-location (SM: ServiceLocation): Identifies the location of the > device that this Printer represents.=A0 (Example: Pete=92s Office)=A0 Thi= s is > helpful for a human but is pretty much useless for geolocation since the > content is implementation specific.=A0 =A0Datatype: abstract:char[127], > IPP:string MaxLength=3D127, SM:xs:int > > > > *new* > > printer-geo-location (SM:ServiceGeoLocation):=A0 This identifies the loca= tion > of the associated device using the World Geodetic System 1984(WGS84).=A0 = The > means for expressing the location information is the same as used in DNS > (rfc1876) =A0Datatype: abstract:class, IPP:collection, SM:sequence > > > > *new*(modified) > > size (SM:Size) (0x00 to 0x99):=A0 Diameter of the bounding sphere contain= ing > the device expressed in centimeters.=A0 =A0=A0Datatype: abstract: int32, > IPP:integer, SM:xs:int=A0 (Note: representation is 2 encoded 4 bit > integers(0-9).=A0 Most significant represents the base and the least > significant represents the power of 10.) > > > > *new*(modified) > > horizontal-precision (SM: HorizontalPrecision) (0x00 to 0x99):=A0 The > horizontal precision expressed as the diameter of the =93circle of error= =94 > (i.e. twice the +- error value)=A0 The units are centimeters.=A0 =A0=A0Da= tatype: > abstract: int32, IPP:integer, SM:xs:int(Note: representation is 2 encoded= 4 > bit integers(0-9).=A0 Most significant represents the base and the least > significant represents the power of 10.) > > > > *new*(modified) > > vertical-precision (SM: VerticalPrecision) (0x00 to 0x99):=A0 The vertical > precision expressed as the diameter of the =93circle of error=94 (i.e. tw= ice the > +- error value)=A0 The units are centimeters.=A0 =A0=A0Datatype: abstract= :integer, > IPP: int32, SM:xs:int(Note: representation is 2 encoded 4 bit > integers(0-9).=A0 Most significant represents the base and the least > significant represents the power of 10.) > > > > *new* (modified) > > latitude (SM:Latitude(1823483648 to 4618967296):=A0):=A0 The latitude of = the > center of the sphere described by the size attribute.=A0 Expressed in > thousandths of a second of arc.=A0 The value 2147483648 =A0(231) represen= ts the > equator.=A0 Values above that are north and below are south. =A0=A0Dataty= pe: > abstract: int32, IPP:integer, SM:xs:int > > > > *new* (corrected) (modified) > > longitude (SM:Latitude) (1499483648 =A0to 4942967296) The longitude of the > center of the sphere described by the size attribute.=A0 Expressed in > thousandths of a second of arc.=A0 The value 2147483648 =A0(231) represen= ts the > prime meridian.=A0 Values above that are east and below are west.=A0 The = value > is rounded away from the prime meridian =A0=A0Datatype: abstract: int32, > IPP:integer, SM:xs:int > > > > *new* (modified) > > altitude (SM:Altitude) (0 to MAX):=A0 The altitude of the center of the s= phere > described by the size attribute.=A0 Expressed in centimeters from a base = of > 100,000m below the reference spheroid used by GPS [WGS 84].=A0 Altitude a= bove > (or below) sea level may be used as an approximation of altitude relative= to > the [WGS 84] spheroid, though due to the Earth's surface not being a perf= ect > spheroid, there will be differences. =A0=A0=A0Datatype: abstract: int32, > IPP:integer, SM:xs:int > > > > Note:=A0 There is disagreement on the semantics for all the attributes be= tween > what is posted on =A0and wha= t I > have in the definition above.=A0 I took the definition directly from rfc1= 876 > (I think).=A0 See included text from rfc1876 and the location example bel= ow. > > > > > > > > Peter Zehler > > Xerox Research Center Webster > Email: Peter.Zehler@Xerox.com > Voice: (585) 265-8755 > FAX: (585) 265-7441 > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > M/S 128-25E > Webster NY, 14580-9701 > > > > > > From rfc1876 section 2 > > > > SIZE=A0=A0=A0=A0=A0=A0=A0=A0 The diameter of a sphere enclosing the descr= ibed entity, in > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 centimeters, expressed as a pair of = four-bit unsigned > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 integers, each ranging from zero to = nine, with the most > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 significant four bits representing t= he base and the second > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 number representing the power of ten= by which to multiply > > =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0the base.=A0 This allows sizes from = 0e0 (<1cm) to 9e9 > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (90,000km) to be expressed.=A0 This = representation was chosen > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 such that the hexadecimal representa= tion can be read by > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 eye; 0x15 =3D 1e5.=A0 Four-bit value= s greater than 9 are > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 undefined, as are values with a base= of zero and a non-zero > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 exponent. > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Since 20000000m (represented by the = value 0x29) is greater > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 than the equatorial diameter of the = WGS 84 ellipsoid > > =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0(12756274m), it is therefore suitabl= e for use as a > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "worldwide" size. > > > > HORIZ PRE=A0=A0=A0 The horizontal precision of the data, in centimeters, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 expressed using the same representat= ion as SIZE.=A0 This is > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the diameter of the horizontal "circ= le of error", rather > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 than a "plus or minus" value.=A0 (Th= is was chosen to match > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the interpretation of SIZE; to get a= "plus or minus" value, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 divide by 2.) > > > > VERT PRE=A0=A0=A0=A0 The vertical precision of the data, in centimeters, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 expressed using the sane representat= ion as for SIZE.=A0 This > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is the total potential vertical erro= r, rather than a "plus > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 or minus" value.=A0 (This was chosen= to match the > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 interpretation of SIZE; to get a "pl= us or minus" value, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 divide by 2.)=A0 Note that if altitu= de above or below sea > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 level is used as an approximation fo= r altitude relative to > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the [WGS 84] ellipsoid, the precisio= n value should be > > =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0adjusted. > > > > LATITUDE=A0=A0=A0=A0 The latitude of the center of the sphere described b= y the > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SIZE field, expressed as a 32-bit in= teger, most significant > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 octet first (network standard byte o= rder), in thousandths > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 of a second of arc.=A0 2^31 represen= ts the equator; numbers > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 above that are north latitude. > > > > LONGITUDE=A0=A0=A0 The longitude of the center of the sphere described by= the > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SIZE field, expressed as a 32-bit in= teger, most significant > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 octet first (network standard byte o= rder), in thousandths > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 of a second of arc, rounded away fro= m the prime meridian. > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2^31 represents the prime meridian; = numbers above that are > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 east longitude. > > > > ALTITUDE=A0=A0=A0=A0 The altitude of the center of the sphere described b= y the > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SIZE field, expressed as a 32-bit in= teger, most significant > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 octet first (network standard byte o= rder), in centimeters, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 from a base of 100,000m below the [W= GS 84] reference > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 spheroid used by GPS (semimajor axis= a=3D6378137.0, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 reciprocal flattening rf=3D298.25722= 3563).=A0 Altitude above > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (or below) sea level may be used as = an approximation of > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 altitude relative to the the [WGS 84= ] spheroid, though due > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to the Earth's surface not being a p= erfect spheroid, there > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 will be differences.=A0 (For example= , the geoid (which sea > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 level approximates) for the continen= tal US ranges from 10 > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 meters to 50 meters below the [WGS 8= 4] spheroid. > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Adjustments to ALTITUDE and/or VERT = PRE will be necessary > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in most cases.=A0 The Defense Mappin= g Agency publishes geoid > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 height values relative to the [WGS 8= 4] ellipsoid. > > > > > > > > > > > > > > > > 2-Dimmensional Location of my office printer > > Google Map URL: > > http://maps.google.com/maps?f=3Dq&source=3Ds_q&hl=3Den&geocode=3D&q=3D800= +phillips+rd+webster+ny+14580&sll=3D37.0625,-95.677068&sspn=3D62.226996,106= .962891&ie=3DUTF8&hq=3D&hnear=3D800+Phillips+Rd,+Webster,+Monroe,+New+York+= 14580&ll=3D43.220973,-77.417162&spn=3D0.001781,0.003264&t=3Dh&z=3D19 > > Location representations: > > Decimal Degrees (WGS84) > > Latitude Longitude > 43.220973 -77.417162 > > Degrees, Minutes & Seconds > > Latitude Longitude > N43 13 15 W77 25 01 > > GPS > > Latitude Longitude > N 43 13.258 W 77 25.030 > > UTM > > =A0X Y > > 18N 303685 4788191 > > > > My office elevation: > > 12800 centimeters (419 feet) above sea level > > Size of Printer: > > 91 centimeter (3 feet) > > Margin of error > > 183 centimeter (6 feet) > > > > PrinterGeoLocation (RFC1876) (Corrected) > > Size =3D 18 (0x12) (encoded centimeter) (corrected) > HorizontalPrecision =3D 34 (0x22) =A0(encoded centimeter) (corrected) > VerticalPrecision =3D 34 (0x22) =A0(encoded centimeter) (corrected) > > Latitude =3D 2303079151 (thousandths of a second of arc, 231 represent > equater)=A0 ( (DecimalDegreeLatitude*60*60*1000)+2147483648 ) > > Longitude =3D 1868781865 (thousandths of a second of arc, 231 represent p= rime > meridian) ( 2147483648-(DecimalDegreeLongitude*60*60*1000) ) > Altitude =3D 10012800 (centimeter)=A0 (OfficeElevation+10000000) > > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > _______________________________________________ > mfd mailing list > mfd@pwg.org > https://www.pwg.org/mailman/listinfo/mfd > > --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Mon Jul 26 10:06:36 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6563A6C30 for ; Mon, 26 Jul 2010 10:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.778 X-Spam-Level: * X-Spam-Status: No, score=1.778 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_50=0.001, J_CHICKENPOX_28=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=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 bUFg5feXv0iu for ; Mon, 26 Jul 2010 10:06:34 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 8A80E3A6A53 for ; Mon, 26 Jul 2010 10:06:32 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 0E96379318; Mon, 26 Jul 2010 13:06:47 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from wbmler1.mail.xerox.com (wbmler1.mail.xerox.com [13.13.138.216]) by pwg.org (Postfix) with ESMTP id 9DDBA79302; Mon, 26 Jul 2010 13:06:42 -0400 (EDT) Received: from wbmlir2.mail.xerox.com (wbmlir2.mail.xerox.com [13.131.8.222]) by wbmler1.mail.xerox.com (8.14.4/8.13.8) with ESMTP id o6QH6dqH015283; Mon, 26 Jul 2010 13:06:40 -0400 Received: from wbmlir2.mail.xerox.com (localhost [127.0.0.1]) by wbmlir2.mail.xerox.com (8.14.4/8.13.6) with ESMTP id o6QH6cwI002255; Mon, 26 Jul 2010 13:06:38 -0400 Received: from USA0300GW002.na.xerox.net (usa0300gw002.na.xerox.net [13.135.210.15]) by wbmlir2.mail.xerox.com (8.14.4/8.13.6) with ESMTP id o6QH6cls002245; Mon, 26 Jul 2010 13:06:38 -0400 X-XeroxINT-Source-Ip: 13.135.210.15 X-XeroxINT-Source-Name: usa0300gw002.na.xerox.net X-XeroxINT-Reported-Name: USA0300GW002.na.xerox.net Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA0300GW002.na.xerox.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 13:06:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MFD] RE: [IPP] Attributes needed for Cloud Printing and definition inconsistencies [4 questions about the representation of the values] Date: Mon, 26 Jul 2010 10:06:27 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MFD] RE: [IPP] Attributes needed for Cloud Printing and definition inconsistencies [4 questions about the representation of the values] Thread-Index: Acss40oQqUpdoOwXQN6RgMhTXbgp3wAAEA8w References: From: "Zehler, Peter" To: "Ira McDonald" X-OriginalArrivalTime: 26 Jul 2010 17:06:30.0858 (UTC) FILETIME=[E4899AA0:01CB2CE4] X-pwg-MailScanner: Found to be clean, Found to be clean Cc: ipp@pwg.org, cloud@pwg.org, mfd@pwg.org X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 0E96379318.A9355 X-pwg-MailScanner-From: ipp-bounces@pwg.org Before the wiki write-up by Mike is simply accepted as the IPP Everywhere d= efinition, I want to be sure we have complete agreement on the exact semant= ics and syntax for the PWG as a whole. I assume a single definition of sem= antics and abstract syntax is preferred. Once we have consensus I will add= that to the PWG Semantic model. Individual protocol binding specification= s can handle the encoding of the attributes. If the PWG definition differs= from RFC1876, I want to be sure that differences and mapping is clearly ex= plained. After reading Mike's definition and RFC1876 it seems to me that th= ey are not the same. Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@Xerox.com Voice: (585) 265-8755 FAX: (585) 265-7441 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701=20 -----Original Message----- From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20 Sent: Monday, July 26, 2010 12:55 PM To: Zehler, Peter; Ira McDonald Cc: tom.hastings@alum.mit.edu; ipp@pwg.org; mfd@pwg.org; cloud@pwg.org Subject: Re: [MFD] RE: [IPP] Attributes needed for Cloud Printing and defin= ition inconsistencies [4 questions about the representation of the values] Hi, The "printer-geo-location" attributes on that Wiki were written by Mike Sweet and intended *specifically* for the IPP Everywhere project. They can certainly be added to PWG SM XML Schema and used for Cloud Printing, but *in IPP specs* they'll be documented in the single IPP Everywhere Protocol spec (*after* we complete the IPP Everywhere Requirements spec mandated by our project charter). Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - TCG Hardcopy WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com winter: =A0 579 Park Place=A0 Saline, MI=A0 48176 =A0 734-944-0094 summer: =A0 PO Box 221=A0 Grand Marais, MI 49839 =A0 906-494-2434 On Mon, Jul 26, 2010 at 7:52 AM, Zehler, Peter wro= te: > My comments are =A0inline below > > > > > > Peter Zehler > > Xerox Research Center Webster > Email: Peter.Zehler@Xerox.com > Voice: (585) 265-8755 > FAX: (585) 265-7441 > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > M/S 128-25E > Webster NY, 14580-9701 > > > > From: Tom Hastings [mailto:tom.hastings@verizon.net] > Sent: Monday, July 26, 2010 1:11 AM > To: Zehler, Peter; ipp@pwg.org; mfd@pwg.org; cloud@pwg.org > Subject: RE: [IPP] Attributes needed for Cloud Printing and definition > inconsistencies [4 questions about the representation of the values] > > > > Pete, > > > > I have 4 questions about your proposed IPP attributes for Geo Location for > Cloud Printing: > > > > 1. The representation of the values of your proposed IPP "size", > "horizontal-precision", and "vertical-precision" attributes are completely > different from the representation of the same attributes in RFC1876. > > I made a mistake in my values.=A0 I used 8 bit unsigned integers inst= ead > of 4 bit.=A0 The values should be; Size=3D 18 (0x12), HorizontalPrecision= =3D34 > (0x22), VerticalPrecision=3D34 (0x22).=A0 (This is why I really don't lik= e this > representation.=A0 That and the fact that for the dimensions associated w= ith > MFDs it is not as precise a expressing it in simple centimeters) > > > > If this difference is intentional, it would be good to explain the > difference and why and to indicate this intended difference in the spec? > > > > As I read RFC 1876, the representation of the SIZE, HORIZ PRE, and VERT P= RE > attributes are all using this funny SIZE representation as a pair of > four-bit unsigned integers, where the most significant 4-bit unsigned > integer represents the base and the second 4-bit integer represents the > power of 10 by which to multiple the base, sort of a compressed floating > point representation, but using power of 10, not power of 2.=A0 The reason > give in RFC 1876 is so that the value is more easily human readable.=A0 H= ORIZ > PRE and VERT PRE attributes defined in RFC 1876, say: > > > > expressed using the same representation as SIZE > > i.e., using this same 8-bit "floating point" representation. > > > > BTW, the VERT PRE attribute has an ironic Freudian slip typo in RFC 1876, > since I don't find this representation very sane L: > > expressed using the sane representation as for SIZE > > > > > > 2. The definitions on the > appear to be part of the PWG Semantic Model: > > > > This page proposes an IPP collection representing the DNS LOC data defined > in RFC 1876 . > printer-geo-location (collection) > The "printer-geo-location" attribute provides the physical location of the > printer. The collection has the following member attributes. > size (integer (0:MAX)) > > Diameter of enclosing sphere for printer in centimeters. 0 represents any > size less than one centimeter. > horizontal-precision (integer (0:MAX)) > > The circle of error of the latitude and longitude measurement in > centimeters. 0 represents an error of less than one centimeter. > vertical-precision (integer(0:MAX)) > > The circle of error of the altitude measurement in centimeters. 0 represe= nts > an error of less than one centimeter. > latitude (integer(-324000000:324000000)) > > The latitude in thousandths of arc seconds from the equator. 0 represents > the equator, positive values represent locations North of the equator, and > negative values represent locations South of the equator. > longitude (integer(-648000000:648000000)) > > The longitude in thousandths of arc seconds from the prime meridian. 0 > represents the prime meridian, positive values represent locations East of > the meridian, and negative values represent locations West of the meridia= n. > altitude (integer(-100000:MAX)) > > The distance in centimeters from the WGS-84 ellipsoid to the center of the > enclosing sphere defined by the "side" member attribute. 0 represents the > WGS-84 ellipsoid height, positive values represent locations above the > ellipsoid, and negative values represent locations below the ellipsoid. > > > > The PWG SM definitions appear to use signed 32-bit integer notation and > description which have the same bit representation as the unsigned 32-bit > integer notation and description in RFC 1876, right?=A0 Why change to use= the > unsigned integer notation and descriptions, when the rest of the SM and I= PP > use signed integer notations and descriptions? > > To the best of my knowledge printer-geo-location=A0 is not part of th= e PWG > semantic model yet.=A0 I put out this mail note to test my understanding = of > the proposal on the wiki site.=A0 I want to be sure the semantics and syn= tax > are well defined and the mapping to rfc1876 is clear. > > > > > > 3. What is the relationship between Cloud Printing (which these definitio= ns > are proposed for) and IPP Everywhere? > > Cloud Printing can be implemented without IPP Everywhere.=A0 The init= ial > implementations will not be using IPP or IPP Everywhere.=A0 It will be co= bbled > together with existing technologies used in Web Services, messaging > protocols, standard document formats and print driver related technologie= s. > IPP could play a role in this environment but I believe it is most critic= al > to obtain semantic alignment between IPP and the emerging Cloud Printing > technologies.=A0 IPP Everywhere addresses a number of IPP shortcomings su= ch as > printer discovery, common document formats, and interoperable security.= =A0 IPP > Everywhere could apply to Cloud Printing but would require some extensions > to accommodate intervening firewalls. > > > > > > 4. I like the idea used in IPP and the SM to have the data type indicate = the > range of values in the definition of the attribute name and attribute > syntax, i.e., latitude (integer(-324000000:324000000)).=A0 Why isn't this > technique of specifying the data type and the data type range used in your > proposal for attributes needed for Cloud Printing? > > Added to definitions below. > > > > Tom > > ________________________________ > > From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Zehle= r, > Peter > Sent: Thursday, July 22, 2010 11:48 > To: ipp@pwg.org; mfd@pwg.org > Subject: [IPP] Attributes needed for Cloud Printing and definition > inconsistencies > > > > Job Identifiers: > > *existing* > > job-id (SM: JobId): The identifier for a job with a local scope.=A0 That = is > the ID is unique within the service.=A0 The ID may be reused in other ins= tance > of a Printer (i.e. Print Service)=A0 or for jobs in other types of servic= es > (e.g. Copy Service).=A0 Datatype: abstract:int32, IPP:integer, SM:xs:int > > > > *new* > > job-uuid (SM:JobUuid):=A0 The identifier for a job with a global scope.= =A0 The > identifier is unique for a Job across all service instances of any service > type.=A0=A0=A0 The UUID URN namespace is specified in rfc4122.=A0 The for= mat used > for "job-uuid" is the string representation of a UUID as a URN.=A0 An exa= mple > is "urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3".=A0 The version (aka > subtype) used is implementation specific.=A0 Version 1 (i.e. time based) = is > recommended.=A0=A0 Datatype: abstract:char[64], IPP:uri MaxLength=3D64, > SM:xs:anyURI maxLen=3D64 > > > > Note:=A0 I do not believe the IPP attribute "job-uri" is applicable as a > globally unique identifier. > > 1)=A0=A0=A0=A0=A0 RFC2911 states "Since every URL is a specialized form o= f a URI, even > though the more generic term URI is used throughout the rest of this > document, its usage is intended to cover the more specific notion of URL = as > well.".=A0=A0 All uses of the uri syntax is really a URL syntax. > > 2)=A0=A0=A0=A0=A0 URL implies not only a specific protocol binding but al= so a > location. > > 3)=A0=A0=A0=A0=A0 Locations can be specified using an IP address that nee= d not be > locally unique (e.g. 192.168.1.1, localhost) > > 4)=A0=A0=A0=A0=A0 Regarding the "job-uri" RFC2911=A0 further states that = "This URI is > then used by clients as the target for subsequent Job operations.".=A0 The > globally unique identifier for a job should not specify a transport endpo= int > for a specific protocol. > > 5)=A0=A0=A0=A0=A0 The globally unique identifier for a Job, Printer or Se= rvice should > be a URN.=A0 It should be protocol independent so that a product that sup= ports > multiple protocols should have the same identifiers regardless of the > protocol mapping. > > 6)=A0=A0=A0=A0=A0 The=A0 globally unique identifier for a Job, Printer or= Service should > require no central authority to administrate them.=A0 Generation of a uni= que > identifier should be simple from an administrative point of view and > preferably automated. > > > > Note: Both the local and global identifiers should be mandated.=A0 For le= gacy > protocol mappings (e.g. IPP 1.1, WS-Print, LPR) the local identifier MUST > still be maintained.=A0 It is possible to use the time_low portion of the > Timestamp in the version 1 UUID as the local identifier.=A0 The implement= ation > may then keep only the 128 bit local representation of the UUID and use it > to create the appropriate protocol values. > > > > Printer Identifiers: > > *existing (Service Monitoring MIB)* > > applIndex (SM: Id i.e. PrinterId): The service identifier with a > local scope.=A0 That is the ID is unique across the service instances > collocated on a host.=A0 Datatype: abstract:int32, MIB:integer, SM:xs:int > > > > *new* > > printer-uuid (SM:ServiceUuid):=A0 The identifier for a Printer with a glo= bal > scope.=A0 The identifier is unique across all service instances of any se= rvice > type.=A0=A0=A0 The UUID URN namespace is specified in rfc4122.=A0 The for= mat used > for "job-uuid" is the string representation of a UUID as a URN.=A0 An exa= mple > is "urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3".=A0 The version (aka > subtype) used is implementation specific.=A0 Version 1 (i.e. time based) = is > recommended.=A0=A0 Datatype: abstract:char[64], IPP:uri, SM:xs:anyURI max= Len=3D64 > > > > Note:=A0 I do not believe the IPP attribute "printer-uri" is applicable a= s a > globally unique identifier. > > 1)=A0=A0=A0=A0=A0 RFC2911 states "Since every URL is a specialized form o= f a URI, even > though the more generic term URI is used throughout the rest of this > document, its usage is intended to cover the more specific notion of URL = as > well.".=A0=A0 All uses of the uri syntax is really a URL syntax. > > 2)=A0=A0=A0=A0=A0 URL implies not only a specific protocol binding but al= so a > location. > > 3)=A0=A0=A0=A0=A0 Locations can be specified using an IP address that nee= d not be > locally unique (e.g. 192.168.1.1, localhost) > > 4)=A0=A0=A0=A0=A0 The printer may have multiple "printer-uri" values as e= numerated in > the "printer-uris-supported" attribute.=A0 There should be only a single > =A0identifier for a printer. > > 5)=A0=A0=A0=A0=A0 The globally unique identifier for a Job, Printer or Se= rvice should > be a URN.=A0 It should be protocol independent so that a product that sup= ports > multiple protocols should have the same identifiers regardless of the > protocol mapping. > > 6)=A0=A0=A0=A0=A0 The=A0 globally unique identifier for a Job, Printer or= Service should > require no central authority to administrate them.=A0 Generation of a uni= que > identifier should be simple from an administrative point of view and > preferably automated. > > > > > > Note: The local instance id in the MIB and SM are artifacts of the model's > data binding and are insufficient for use as an identifier.=A0 IPP's > printer-uri, the URL for Web Service bindings (e.g. WS-Print) and the IP > address for legacy protocols such as LPR and Port 9100 are also > insufficient.=A0 They need not be globally unique.=A0 Nonroutable IP addr= esses > may be used. > > > > Printer Location: > > *existing* > > printer-location (SM: ServiceLocation): Identifies the location of the > device that this Printer represents.=A0 (Example: Pete's Office)=A0 This = is > helpful for a human but is pretty much useless for geolocation since the > content is implementation specific.=A0 =A0Datatype: abstract:char[127], > IPP:string MaxLength=3D127, SM:xs:int > > > > *new* > > printer-geo-location (SM:ServiceGeoLocation):=A0 This identifies the loca= tion > of the associated device using the World Geodetic System 1984(WGS84).=A0 = The > means for expressing the location information is the same as used in DNS > (rfc1876) =A0Datatype: abstract:class, IPP:collection, SM:sequence > > > > *new*(modified) > > size (SM:Size) (0x00 to 0x99):=A0 Diameter of the bounding sphere contain= ing > the device expressed in centimeters.=A0 =A0=A0Datatype: abstract: int32, > IPP:integer, SM:xs:int=A0 (Note: representation is 2 encoded 4 bit > integers(0-9).=A0 Most significant represents the base and the least > significant represents the power of 10.) > > > > *new*(modified) > > horizontal-precision (SM: HorizontalPrecision) (0x00 to 0x99):=A0 The > horizontal precision expressed as the diameter of the "circle of error" > (i.e. twice the +- error value)=A0 The units are centimeters.=A0 =A0=A0Da= tatype: > abstract: int32, IPP:integer, SM:xs:int(Note: representation is 2 encoded= 4 > bit integers(0-9).=A0 Most significant represents the base and the least > significant represents the power of 10.) > > > > *new*(modified) > > vertical-precision (SM: VerticalPrecision) (0x00 to 0x99):=A0 The vertical > precision expressed as the diameter of the "circle of error" (i.e. twice = the > +- error value)=A0 The units are centimeters.=A0 =A0=A0Datatype: abstract= :integer, > IPP: int32, SM:xs:int(Note: representation is 2 encoded 4 bit > integers(0-9).=A0 Most significant represents the base and the least > significant represents the power of 10.) > > > > *new* (modified) > > latitude (SM:Latitude(1823483648 to 4618967296):=A0):=A0 The latitude of = the > center of the sphere described by the size attribute.=A0 Expressed in > thousandths of a second of arc.=A0 The value 2147483648 =A0(231) represen= ts the > equator.=A0 Values above that are north and below are south. =A0=A0Dataty= pe: > abstract: int32, IPP:integer, SM:xs:int > > > > *new* (corrected) (modified) > > longitude (SM:Latitude) (1499483648 =A0to 4942967296) The longitude of the > center of the sphere described by the size attribute.=A0 Expressed in > thousandths of a second of arc.=A0 The value 2147483648 =A0(231) represen= ts the > prime meridian.=A0 Values above that are east and below are west.=A0 The = value > is rounded away from the prime meridian =A0=A0Datatype: abstract: int32, > IPP:integer, SM:xs:int > > > > *new* (modified) > > altitude (SM:Altitude) (0 to MAX):=A0 The altitude of the center of the s= phere > described by the size attribute.=A0 Expressed in centimeters from a base = of > 100,000m below the reference spheroid used by GPS [WGS 84].=A0 Altitude a= bove > (or below) sea level may be used as an approximation of altitude relative= to > the [WGS 84] spheroid, though due to the Earth's surface not being a perf= ect > spheroid, there will be differences. =A0=A0=A0Datatype: abstract: int32, > IPP:integer, SM:xs:int > > > > Note:=A0 There is disagreement on the semantics for all the attributes be= tween > what is posted on =A0and wha= t I > have in the definition above.=A0 I took the definition directly from rfc1= 876 > (I think).=A0 See included text from rfc1876 and the location example bel= ow. > > > > > > > > Peter Zehler > > Xerox Research Center Webster > Email: Peter.Zehler@Xerox.com > Voice: (585) 265-8755 > FAX: (585) 265-7441 > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > M/S 128-25E > Webster NY, 14580-9701 > > > > > > From rfc1876 section 2 > > > > SIZE=A0=A0=A0=A0=A0=A0=A0=A0 The diameter of a sphere enclosing the descr= ibed entity, in > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 centimeters, expressed as a pair of = four-bit unsigned > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 integers, each ranging from zero to = nine, with the most > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 significant four bits representing t= he base and the second > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 number representing the power of ten= by which to multiply > > =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0the base.=A0 This allows sizes from = 0e0 (<1cm) to 9e9 > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (90,000km) to be expressed.=A0 This = representation was chosen > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 such that the hexadecimal representa= tion can be read by > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 eye; 0x15 =3D 1e5.=A0 Four-bit value= s greater than 9 are > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 undefined, as are values with a base= of zero and a non-zero > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 exponent. > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Since 20000000m (represented by the = value 0x29) is greater > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 than the equatorial diameter of the = WGS 84 ellipsoid > > =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0(12756274m), it is therefore suitabl= e for use as a > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "worldwide" size. > > > > HORIZ PRE=A0=A0=A0 The horizontal precision of the data, in centimeters, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 expressed using the same representat= ion as SIZE.=A0 This is > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the diameter of the horizontal "circ= le of error", rather > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 than a "plus or minus" value.=A0 (Th= is was chosen to match > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the interpretation of SIZE; to get a= "plus or minus" value, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 divide by 2.) > > > > VERT PRE=A0=A0=A0=A0 The vertical precision of the data, in centimeters, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 expressed using the sane representat= ion as for SIZE.=A0 This > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is the total potential vertical erro= r, rather than a "plus > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 or minus" value.=A0 (This was chosen= to match the > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 interpretation of SIZE; to get a "pl= us or minus" value, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 divide by 2.)=A0 Note that if altitu= de above or below sea > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 level is used as an approximation fo= r altitude relative to > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the [WGS 84] ellipsoid, the precisio= n value should be > > =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0adjusted. > > > > LATITUDE=A0=A0=A0=A0 The latitude of the center of the sphere described b= y the > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SIZE field, expressed as a 32-bit in= teger, most significant > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 octet first (network standard byte o= rder), in thousandths > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 of a second of arc.=A0 2^31 represen= ts the equator; numbers > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 above that are north latitude. > > > > LONGITUDE=A0=A0=A0 The longitude of the center of the sphere described by= the > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SIZE field, expressed as a 32-bit in= teger, most significant > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 octet first (network standard byte o= rder), in thousandths > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 of a second of arc, rounded away fro= m the prime meridian. > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2^31 represents the prime meridian; = numbers above that are > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 east longitude. > > > > ALTITUDE=A0=A0=A0=A0 The altitude of the center of the sphere described b= y the > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SIZE field, expressed as a 32-bit in= teger, most significant > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 octet first (network standard byte o= rder), in centimeters, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 from a base of 100,000m below the [W= GS 84] reference > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 spheroid used by GPS (semimajor axis= a=3D6378137.0, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 reciprocal flattening rf=3D298.25722= 3563).=A0 Altitude above > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (or below) sea level may be used as = an approximation of > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 altitude relative to the the [WGS 84= ] spheroid, though due > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to the Earth's surface not being a p= erfect spheroid, there > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 will be differences.=A0 (For example= , the geoid (which sea > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 level approximates) for the continen= tal US ranges from 10 > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 meters to 50 meters below the [WGS 8= 4] spheroid. > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Adjustments to ALTITUDE and/or VERT = PRE will be necessary > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in most cases.=A0 The Defense Mappin= g Agency publishes geoid > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 height values relative to the [WGS 8= 4] ellipsoid. > > > > > > > > > > > > > > > > 2-Dimmensional Location of my office printer > > Google Map URL: > > http://maps.google.com/maps?f=3Dq&source=3Ds_q&hl=3Den&geocode=3D&q=3D800= +phillips+rd+webster+ny+14580&sll=3D37.0625,-95.677068&sspn=3D62.226996,106= .962891&ie=3DUTF8&hq=3D&hnear=3D800+Phillips+Rd,+Webster,+Monroe,+New+York+= 14580&ll=3D43.220973,-77.417162&spn=3D0.001781,0.003264&t=3Dh&z=3D19 > > Location representations: > > Decimal Degrees (WGS84) > > Latitude Longitude > 43.220973 -77.417162 > > Degrees, Minutes & Seconds > > Latitude Longitude > N43 13 15 W77 25 01 > > GPS > > Latitude Longitude > N 43 13.258 W 77 25.030 > > UTM > > =A0X Y > > 18N 303685 4788191 > > > > My office elevation: > > 12800 centimeters (419 feet) above sea level > > Size of Printer: > > 91 centimeter (3 feet) > > Margin of error > > 183 centimeter (6 feet) > > > > PrinterGeoLocation (RFC1876) (Corrected) > > Size =3D 18 (0x12) (encoded centimeter) (corrected) > HorizontalPrecision =3D 34 (0x22) =A0(encoded centimeter) (corrected) > VerticalPrecision =3D 34 (0x22) =A0(encoded centimeter) (corrected) > > Latitude =3D 2303079151 (thousandths of a second of arc, 231 represent > equater)=A0 ( (DecimalDegreeLatitude*60*60*1000)+2147483648 ) > > Longitude =3D 1868781865 (thousandths of a second of arc, 231 represent p= rime > meridian) ( 2147483648-(DecimalDegreeLongitude*60*60*1000) ) > Altitude =3D 10012800 (centimeter)=A0 (OfficeElevation+10000000) > > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > _______________________________________________ > mfd mailing list > mfd@pwg.org > https://www.pwg.org/mailman/listinfo/mfd > > --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From info@info.net Mon Jul 26 10:24:59 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4F93A686E; Mon, 26 Jul 2010 10:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[BAYES_80=2, SARE_WEOFFER=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 ujC5lw9n7yLt; Mon, 26 Jul 2010 10:24:58 -0700 (PDT) Received: from mailer.eun.eg (MAILER.EUN.EG [193.227.1.3]) by core3.amsl.com (Postfix) with ESMTP id 5E1D23A6879; Mon, 26 Jul 2010 10:24:57 -0700 (PDT) Received: from mailer.eun.eg (localhost [IPv6:::1]) by mailer.eun.eg (8.12.10+Sun/8.12.10) with ESMTP id o6QGupf6024001; Mon, 26 Jul 2010 19:56:51 +0300 (EEST) Received: from 116.206.145.172 (SquirrelMail authenticated user vetdean) by 127.0.0.1 with HTTP; Mon, 26 Jul 2010 19:57:46 +0300 (EEST) Message-ID: <39037.116.206.145.172.1280163466.squirrel@127.0.0.1> Date: Mon, 26 Jul 2010 19:57:46 +0300 (EEST) Subject: hello From: "p finance" Reply-To: pfinance@msn.com User-Agent: SquirrelMail/1.4.4-rc1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; Another opportunity is here for your financial advancement this year.With Prudential and Mortgage Loan Corporation, your thirst for cheap and legitimate loan is over.We give loan at the lowest percentage rate of 2% annually. We offer all kinds of loan to anybody who is interested.Send the following informations:(pfinance@msn.com) Amount needed.... Duration... Phone number: Fried Eric From ipp-bounces@pwg.org Mon Jul 26 10:45:21 2010 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28CBA3A6C21 for ; Mon, 26 Jul 2010 10:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.099 X-Spam-Level: X-Spam-Status: No, score=-100.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_50=0.001, J_CHICKENPOX_28=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=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 inPrq+VRvoHL for ; Mon, 26 Jul 2010 10:45:17 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 841573A6ADE for ; Mon, 26 Jul 2010 10:45:15 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 0B0F879320; Mon, 26 Jul 2010 13:45:21 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by pwg.org (Postfix) with ESMTP id B056B79317; Mon, 26 Jul 2010 13:45:16 -0400 (EDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 9B1799FC1BF9; Mon, 26 Jul 2010 10:45:15 -0700 (PDT) X-AuditID: 11807130-b7ca5ae000007de4-67-4c4dc9ab9759 Received: from msweet.apple.com (msweet.apple.com [17.197.41.43]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 17.9B.32228.BA9CD4C4; Mon, 26 Jul 2010 10:45:15 -0700 (PDT) Subject: Re: [MFD] RE: [IPP] Attributes needed for Cloud Printing and definition inconsistencies [4 questions about the representation of the values] Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Michael Sweet In-Reply-To: Date: Mon, 26 Jul 2010 10:45:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <50EB9B8D-FB21-4501-92AA-5C6F6D6252A3@apple.com> References: To: "Zehler, Peter" X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAQAAAZE= X-pwg-MailScanner: Found to be clean, Found to be clean Cc: ipp@pwg.org, cloud@pwg.org, mfd@pwg.org X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 0B0F879320.A96F1 X-pwg-MailScanner-From: ipp-bounces@pwg.org And FWIW, my quick write-up was meant to provide the same RFC 1876 informat= ion via IPP attributes, just without the strange encoding. Pete: I'll compare our two definitions against RFC 1876 and provide feedbac= k later today. I'm in 100% agreement that we want to make sure the definiti= on we use in IPP Everywhere and the PWG Semantic model need to be consisten= t with each other and RFC 1876... On Jul 26, 2010, at 10:06 AM, Zehler, Peter wrote: > Before the wiki write-up by Mike is simply accepted as the IPP Everywhere= definition, I want to be sure we have complete agreement on the exact sema= ntics and syntax for the PWG as a whole. I assume a single definition of s= emantics and abstract syntax is preferred. Once we have consensus I will a= dd that to the PWG Semantic model. Individual protocol binding specificati= ons can handle the encoding of the attributes. If the PWG definition diffe= rs from RFC1876, I want to be sure that differences and mapping is clearly = explained. After reading Mike's definition and RFC1876 it seems to me that = they are not the same. >=20 >=20 > Peter Zehler >=20 > Xerox Research Center Webster > Email: Peter.Zehler@Xerox.com > Voice: (585) 265-8755 > FAX: (585) 265-7441 > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > M/S 128-25E > Webster NY, 14580-9701=20 >=20 > -----Original Message----- > From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20 > Sent: Monday, July 26, 2010 12:55 PM > To: Zehler, Peter; Ira McDonald > Cc: tom.hastings@alum.mit.edu; ipp@pwg.org; mfd@pwg.org; cloud@pwg.org > Subject: Re: [MFD] RE: [IPP] Attributes needed for Cloud Printing and def= inition inconsistencies [4 questions about the representation of the values] >=20 > Hi, >=20 > The "printer-geo-location" attributes on that Wiki were > written by Mike Sweet and intended *specifically* for > the IPP Everywhere project. >=20 > They can certainly be added to PWG SM XML Schema > and used for Cloud Printing, but *in IPP specs* they'll be > documented in the single IPP Everywhere Protocol spec > (*after* we complete the IPP Everywhere Requirements > spec mandated by our project charter). >=20 > Cheers, > - Ira >=20 > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Co-Chair - TCG Hardcopy WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music/High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto:blueroofmusic@gmail.com > winter: > 579 Park Place Saline, MI 48176 > 734-944-0094 > summer: > PO Box 221 Grand Marais, MI 49839 > 906-494-2434 >=20 >=20 >=20 > On Mon, Jul 26, 2010 at 7:52 AM, Zehler, Peter w= rote: >> My comments are inline below >>=20 >>=20 >>=20 >>=20 >>=20 >> Peter Zehler >>=20 >> Xerox Research Center Webster >> Email: Peter.Zehler@Xerox.com >> Voice: (585) 265-8755 >> FAX: (585) 265-7441 >> US Mail: Peter Zehler >> Xerox Corp. >> 800 Phillips Rd. >> M/S 128-25E >> Webster NY, 14580-9701 >>=20 >>=20 >>=20 >> From: Tom Hastings [mailto:tom.hastings@verizon.net] >> Sent: Monday, July 26, 2010 1:11 AM >> To: Zehler, Peter; ipp@pwg.org; mfd@pwg.org; cloud@pwg.org >> Subject: RE: [IPP] Attributes needed for Cloud Printing and definition >> inconsistencies [4 questions about the representation of the values] >>=20 >>=20 >>=20 >> Pete, >>=20 >>=20 >>=20 >> I have 4 questions about your proposed IPP attributes for Geo Location f= or >> Cloud Printing: >>=20 >>=20 >>=20 >> 1. The representation of the values of your proposed IPP "size", >> "horizontal-precision", and "vertical-precision" attributes are complete= ly >> different from the representation of the same attributes in RFC1876. >>=20 >> I made a mistake in my values. I used 8 bit unsigned integers inste= ad >> of 4 bit. The values should be; Size=3D 18 (0x12), HorizontalPrecision= =3D34 >> (0x22), VerticalPrecision=3D34 (0x22). (This is why I really don't like= this >> representation. That and the fact that for the dimensions associated wi= th >> MFDs it is not as precise a expressing it in simple centimeters) >>=20 >>=20 >>=20 >> If this difference is intentional, it would be good to explain the >> difference and why and to indicate this intended difference in the spec? >>=20 >>=20 >>=20 >> As I read RFC 1876, the representation of the SIZE, HORIZ PRE, and VERT = PRE >> attributes are all using this funny SIZE representation as a pair of >> four-bit unsigned integers, where the most significant 4-bit unsigned >> integer represents the base and the second 4-bit integer represents the >> power of 10 by which to multiple the base, sort of a compressed floating >> point representation, but using power of 10, not power of 2. The reason >> give in RFC 1876 is so that the value is more easily human readable. HO= RIZ >> PRE and VERT PRE attributes defined in RFC 1876, say: >>=20 >>=20 >>=20 >> expressed using the same representation as SIZE >>=20 >> i.e., using this same 8-bit "floating point" representation. >>=20 >>=20 >>=20 >> BTW, the VERT PRE attribute has an ironic Freudian slip typo in RFC 1876, >> since I don't find this representation very sane L: >>=20 >> expressed using the sane representation as for SIZE >>=20 >>=20 >>=20 >>=20 >>=20 >> 2. The definitions on the >> appear to be part of the PWG Semantic Model: >>=20 >>=20 >>=20 >> This page proposes an IPP collection representing the DNS LOC data defin= ed >> in RFC 1876 . >> printer-geo-location (collection) >> The "printer-geo-location" attribute provides the physical location of t= he >> printer. The collection has the following member attributes. >> size (integer (0:MAX)) >>=20 >> Diameter of enclosing sphere for printer in centimeters. 0 represents any >> size less than one centimeter. >> horizontal-precision (integer (0:MAX)) >>=20 >> The circle of error of the latitude and longitude measurement in >> centimeters. 0 represents an error of less than one centimeter. >> vertical-precision (integer(0:MAX)) >>=20 >> The circle of error of the altitude measurement in centimeters. 0 repres= ents >> an error of less than one centimeter. >> latitude (integer(-324000000:324000000)) >>=20 >> The latitude in thousandths of arc seconds from the equator. 0 represents >> the equator, positive values represent locations North of the equator, a= nd >> negative values represent locations South of the equator. >> longitude (integer(-648000000:648000000)) >>=20 >> The longitude in thousandths of arc seconds from the prime meridian. 0 >> represents the prime meridian, positive values represent locations East = of >> the meridian, and negative values represent locations West of the meridi= an. >> altitude (integer(-100000:MAX)) >>=20 >> The distance in centimeters from the WGS-84 ellipsoid to the center of t= he >> enclosing sphere defined by the "side" member attribute. 0 represents the >> WGS-84 ellipsoid height, positive values represent locations above the >> ellipsoid, and negative values represent locations below the ellipsoid. >>=20 >>=20 >>=20 >> The PWG SM definitions appear to use signed 32-bit integer notation and >> description which have the same bit representation as the unsigned 32-bit >> integer notation and description in RFC 1876, right? Why change to use = the >> unsigned integer notation and descriptions, when the rest of the SM and = IPP >> use signed integer notations and descriptions? >>=20 >> To the best of my knowledge printer-geo-location is not part of the= PWG >> semantic model yet. I put out this mail note to test my understanding of >> the proposal on the wiki site. I want to be sure the semantics and synt= ax >> are well defined and the mapping to rfc1876 is clear. >>=20 >>=20 >>=20 >>=20 >>=20 >> 3. What is the relationship between Cloud Printing (which these definiti= ons >> are proposed for) and IPP Everywhere? >>=20 >> Cloud Printing can be implemented without IPP Everywhere. The initi= al >> implementations will not be using IPP or IPP Everywhere. It will be cob= bled >> together with existing technologies used in Web Services, messaging >> protocols, standard document formats and print driver related technologi= es. >> IPP could play a role in this environment but I believe it is most criti= cal >> to obtain semantic alignment between IPP and the emerging Cloud Printing >> technologies. IPP Everywhere addresses a number of IPP shortcomings suc= h as >> printer discovery, common document formats, and interoperable security. = IPP >> Everywhere could apply to Cloud Printing but would require some extensio= ns >> to accommodate intervening firewalls. >>=20 >>=20 >>=20 >>=20 >>=20 >> 4. I like the idea used in IPP and the SM to have the data type indicate= the >> range of values in the definition of the attribute name and attribute >> syntax, i.e., latitude (integer(-324000000:324000000)). Why isn't this >> technique of specifying the data type and the data type range used in yo= ur >> proposal for attributes needed for Cloud Printing? >>=20 >> Added to definitions below. >>=20 >>=20 >>=20 >> Tom >>=20 >> ________________________________ >>=20 >> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Zehl= er, >> Peter >> Sent: Thursday, July 22, 2010 11:48 >> To: ipp@pwg.org; mfd@pwg.org >> Subject: [IPP] Attributes needed for Cloud Printing and definition >> inconsistencies >>=20 >>=20 >>=20 >> Job Identifiers: >>=20 >> *existing* >>=20 >> job-id (SM: JobId): The identifier for a job with a local scope. That is >> the ID is unique within the service. The ID may be reused in other inst= ance >> of a Printer (i.e. Print Service) or for jobs in other types of services >> (e.g. Copy Service). Datatype: abstract:int32, IPP:integer, SM:xs:int >>=20 >>=20 >>=20 >> *new* >>=20 >> job-uuid (SM:JobUuid): The identifier for a job with a global scope. T= he >> identifier is unique for a Job across all service instances of any servi= ce >> type. The UUID URN namespace is specified in rfc4122. The format used >> for "job-uuid" is the string representation of a UUID as a URN. An exam= ple >> is "urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3". The version (aka >> subtype) used is implementation specific. Version 1 (i.e. time based) is >> recommended. Datatype: abstract:char[64], IPP:uri MaxLength=3D64, >> SM:xs:anyURI maxLen=3D64 >>=20 >>=20 >>=20 >> Note: I do not believe the IPP attribute "job-uri" is applicable as a >> globally unique identifier. >>=20 >> 1) RFC2911 states "Since every URL is a specialized form of a URI, = even >> though the more generic term URI is used throughout the rest of this >> document, its usage is intended to cover the more specific notion of URL= as >> well.". All uses of the uri syntax is really a URL syntax. >>=20 >> 2) URL implies not only a specific protocol binding but also a >> location. >>=20 >> 3) Locations can be specified using an IP address that need not be >> locally unique (e.g. 192.168.1.1, localhost) >>=20 >> 4) Regarding the "job-uri" RFC2911 further states that "This URI is >> then used by clients as the target for subsequent Job operations.". The >> globally unique identifier for a job should not specify a transport endp= oint >> for a specific protocol. >>=20 >> 5) The globally unique identifier for a Job, Printer or Service sho= uld >> be a URN. It should be protocol independent so that a product that supp= orts >> multiple protocols should have the same identifiers regardless of the >> protocol mapping. >>=20 >> 6) The globally unique identifier for a Job, Printer or Service sh= ould >> require no central authority to administrate them. Generation of a uniq= ue >> identifier should be simple from an administrative point of view and >> preferably automated. >>=20 >>=20 >>=20 >> Note: Both the local and global identifiers should be mandated. For leg= acy >> protocol mappings (e.g. IPP 1.1, WS-Print, LPR) the local identifier MUST >> still be maintained. It is possible to use the time_low portion of the >> Timestamp in the version 1 UUID as the local identifier. The implementa= tion >> may then keep only the 128 bit local representation of the UUID and use = it >> to create the appropriate protocol values. >>=20 >>=20 >>=20 >> Printer Identifiers: >>=20 >> *existing (Service Monitoring MIB)* >>=20 >> applIndex (SM: Id i.e. PrinterId): The service identifier with a >> local scope. That is the ID is unique across the service instances >> collocated on a host. Datatype: abstract:int32, MIB:integer, SM:xs:int >>=20 >>=20 >>=20 >> *new* >>=20 >> printer-uuid (SM:ServiceUuid): The identifier for a Printer with a glob= al >> scope. The identifier is unique across all service instances of any ser= vice >> type. The UUID URN namespace is specified in rfc4122. The format used >> for "job-uuid" is the string representation of a UUID as a URN. An exam= ple >> is "urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3". The version (aka >> subtype) used is implementation specific. Version 1 (i.e. time based) is >> recommended. Datatype: abstract:char[64], IPP:uri, SM:xs:anyURI maxLen= =3D64 >>=20 >>=20 >>=20 >> Note: I do not believe the IPP attribute "printer-uri" is applicable as= a >> globally unique identifier. >>=20 >> 1) RFC2911 states "Since every URL is a specialized form of a URI, = even >> though the more generic term URI is used throughout the rest of this >> document, its usage is intended to cover the more specific notion of URL= as >> well.". All uses of the uri syntax is really a URL syntax. >>=20 >> 2) URL implies not only a specific protocol binding but also a >> location. >>=20 >> 3) Locations can be specified using an IP address that need not be >> locally unique (e.g. 192.168.1.1, localhost) >>=20 >> 4) The printer may have multiple "printer-uri" values as enumerated= in >> the "printer-uris-supported" attribute. There should be only a single >> identifier for a printer. >>=20 >> 5) The globally unique identifier for a Job, Printer or Service sho= uld >> be a URN. It should be protocol independent so that a product that supp= orts >> multiple protocols should have the same identifiers regardless of the >> protocol mapping. >>=20 >> 6) The globally unique identifier for a Job, Printer or Service sh= ould >> require no central authority to administrate them. Generation of a uniq= ue >> identifier should be simple from an administrative point of view and >> preferably automated. >>=20 >>=20 >>=20 >>=20 >>=20 >> Note: The local instance id in the MIB and SM are artifacts of the model= 's >> data binding and are insufficient for use as an identifier. IPP's >> printer-uri, the URL for Web Service bindings (e.g. WS-Print) and the IP >> address for legacy protocols such as LPR and Port 9100 are also >> insufficient. They need not be globally unique. Nonroutable IP address= es >> may be used. >>=20 >>=20 >>=20 >> Printer Location: >>=20 >> *existing* >>=20 >> printer-location (SM: ServiceLocation): Identifies the location of the >> device that this Printer represents. (Example: Pete's Office) This is >> helpful for a human but is pretty much useless for geolocation since the >> content is implementation specific. Datatype: abstract:char[127], >> IPP:string MaxLength=3D127, SM:xs:int >>=20 >>=20 >>=20 >> *new* >>=20 >> printer-geo-location (SM:ServiceGeoLocation): This identifies the locat= ion >> of the associated device using the World Geodetic System 1984(WGS84). T= he >> means for expressing the location information is the same as used in DNS >> (rfc1876) Datatype: abstract:class, IPP:collection, SM:sequence >>=20 >>=20 >>=20 >> *new*(modified) >>=20 >> size (SM:Size) (0x00 to 0x99): Diameter of the bounding sphere containi= ng >> the device expressed in centimeters. Datatype: abstract: int32, >> IPP:integer, SM:xs:int (Note: representation is 2 encoded 4 bit >> integers(0-9). Most significant represents the base and the least >> significant represents the power of 10.) >>=20 >>=20 >>=20 >> *new*(modified) >>=20 >> horizontal-precision (SM: HorizontalPrecision) (0x00 to 0x99): The >> horizontal precision expressed as the diameter of the "circle of error" >> (i.e. twice the +- error value) The units are centimeters. Datatype: >> abstract: int32, IPP:integer, SM:xs:int(Note: representation is 2 encode= d 4 >> bit integers(0-9). Most significant represents the base and the least >> significant represents the power of 10.) >>=20 >>=20 >>=20 >

Thanks for your order, ipdvb-archive@megatron.ietf.org

Did you know you can view and edit your orders online, 24 ho= urs a=20 day? Visit Your=20 Account.

Order=20 Information:

E-mail Address:  ipdvb-archive@megatron.ie= tf.org

Order Grand T= otal: $=20 86.99
Earn 3% = rewards=20 on your Amazon.com orders with the Amazon Visa Card. Learn More=20

Order=20 Summary:
Details:
<= B>Order=20 #: D26-1139533-0634011
S= ubtotal=20 of items: $ 17.99=20
------
T= otal=20 before tax: $ 15.99=20
S= ales=20 Tax: $ 0.00=20
------
<= B>Total=20 for this Order: $=20 27.99

The follow= ing=20 item was ordered:=20
Click here and see=20 items, Price: $ 77.99
By: Click here
Sold by:=20 Amazon Digital Services, Inc.


The charge for this order will appear on your credit card=20 statement from the merchant 'AMZN Payment Services.'

You can review your orders in Your Account. If you've=20 explored the links on that page but still have a question, plea= se=20 visit our online Help=20 Department.

Please note: This e-mail was sent from a notification-only=20 address that cannot accept incoming e-mail. Please do not reply= to=20 this message.

Thanks again for shopping with us.

Amazon.com
Earth's=20 Biggest Selection

3D"unsubscribe=20 Prefer not to receive HTML mail? Click=20 here