Document 65
Filed 04/28/2008
Page 1 of 14
IN THE UNITED STATES DISTRICT COURT FOR THE DISTRICT OF DELAWARE INOVIS USA, INC., Plaintiff, v. CLASSIFIED INFORMATION, INC. and DISTANCE DIGITAL LLC, Defendants. ) ) ) ) ) ) ) ) ) )
C.A. No. 07-459-GMS
PLAINTIFF INOVIS USA, INC.'S OPENING BRIEF IN SUPPORT OF ITS MOTION TO STAY ALL PROCEEDINGS PENDING DETERMINATION OF ITS FILED REQUEST FOR REEXAMINATION
MORRIS, NICHOLS, ARSHT & TUNNELL LLP Jack B. Blumenfeld, Esquire (#1014) Julia Heaney, Esquire (#3052) 1201 North Market Street P.O. Box 1347 Wilmington, DE 19899-1347 (302) 658-9200 [email protected] [email protected] Attorneys for Plaintiff Inovis USA, Inc.
OF COUNSEL: David J. Wolfsohn Erich M. Falke Jordan L. Jonas WOODCOCK WASHBURN LLP Cira Centre, 12th Floor 2929 Arch Street Philadelphia, PA 19104 (215) 568-3100 Dated: April 28, 2008
Case 1:07-cv-00459-GMS
Document 65
Filed 04/28/2008
Page 2 of 14
TABLE OF CONTENTS TABLE OF AUTHORITIES .......................................................................................................... ii NATURE AND STAGE OF THE PROCEEDINGS ..................................................................... 1 SUMMARY OF THE ARGUMENT ............................................................................................. 1 STATEMENT OF FACTS AND PTO REEXAMINATION PROCEDURE................................ 2 ARGUMENT.................................................................................................................................. 4 I. Because Classified Only Asserted Its Counterclaim Two Months Ago And Only Began Discovery Last Week, A Stay Would Not Unduly Prejudice Or Present A Clear Tactical Disadvantage To It ...................................................................................... 5 A Stay Would Greatly Simplify The Issues, Promote Settlement, And, If Trial Is Necessary, Shorten It .......................................................................................................... 6 The Benefits Of The Proposed Stay Are Not Outweighed By The Stage Of This Case..................................................................................................................................... 7
II. III.
CONCLUSION............................................................................................................................... 9
i
Case 1:07-cv-00459-GMS
Document 65
Filed 04/28/2008
Page 3 of 14
TABLE OF AUTHORITIES FEDERAL CASES Abbott Diabetes Care, Inc. v. DexCom, Inc., C.A. No. 06-514 GMS, 2007 U.S. Dist. LEXIS 73198 (D. Del. Sept. 30, 2007)..............4, 5, 6 Abbott Diabetes Care, Inc. v. DexCom, Inc., C.A. No. 05-590 GMS, 2006 U.S. Dist. LEXIS 57469 (D. Del. Aug. 16, 2006)..........4, 6, 7, 8 Alloc, Inc. v. Unilin Decor N.V., No. 03-253-GMS , 2003 U.S. Dist. LEXIS 11917 (D. Del. July 11, 2003) ..............................4 Echostar Techs. Corp. v. TiVo, Inc., No. 5:05-CV-81 (DF), 2006 U.S. Dist. LEXIS 48431 (E.D. Tex. July 14, 2006).....................4 eSoft, Inc. v. Blue Coat Sys., Inc., 505 F. Supp. 2d 784, (D. Col. 2007)..........................................................................................4 Ethicon, Inc. v. Quigg, 849 F.2d 1422 (Fed. Cir. 1988)..............................................................................................3, 4 Gioello Enterprises Ltd. v. Mattel, Inc., No. 99-375 GMS, 2001 U.S. Dist. LEXIS 26158......................................................1, 4, 5, 7, 8 Gould v. Control Laser Corp. 705 F.2d 1340 (Fed. Cir. 1983)..................................................................................................6 KSR International Co. v. Teleflex Inc., 127 S. Ct. 1727 (2007)...............................................................................................................6 Middleton, Inc. v. Minnesota Mining & Manufacturing Co., No. 4:03-cv-40493, 2004 U.S. Dist. LEXIS 16812 (S.D. Iowa Oct. 24, 2004) ........................4 Pegasus Dev. Corp. v. DirectTV, Inc., No. 00-1020-GMS, 2003 U.S. Dist. LEXIS 8052 (D. Del. May 14, 2003).................4, 6, 7, 8, Rohm and Haas Co. v. Brotech Corp., No. 90-109-SLR, 1992 U.S. Dist. LEXIS 3252 (D. Del. 1992) ................................................4 Softview Computer Products Corp. v. Haworth, Inc., No. 97 Civ. 8815 KMW HBP, 2000 U.S. Dist. LEXIS 11274, 2000 WL 1134471 (S.D.N.Y. Aug. 10, 2000) ..........................................................................................................7 FEDERAL STATUTES 35 U.S.C. § 301................................................................................................................................3
ii
Case 1:07-cv-00459-GMS
Document 65
Filed 04/28/2008
Page 4 of 14
35 U.S.C. § 302................................................................................................................................3 35 U.S.C. § 303(a) ...........................................................................................................................3 35 U.S.C. § 304................................................................................................................................3 35 U.S.C. § 305................................................................................................................................3 35 U.S.C. § 307................................................................................................................................3
iii
Case 1:07-cv-00459-GMS
Document 65
Filed 04/28/2008
Page 5 of 14
NATURE AND STAGE OF THE PROCEEDINGS On February 19, 2008, Classified filed a Counterclaim against Inovis for infringement of U.S. Patent No. 5,812,669 ("the 669 Patent"). (D.I. 48). On March 10, 2008, Inovis moved to dismiss Classified's Counterclaim for lack of subject matter jurisdiction. (D.I. 50). Classified filed its opposition brief on April 2 (D.I. 57), and Inovis' reply brief was filed on April 24, 2008 (D.I. 61). That motion is currently pending before this Court. On April 14, 2008--less than two months after Classified filed its Counterclaim for patent infringement-- Inovis filed a Request for Reexamination with the United States Patent and Trademark Office ("PTO") of the 669 Patent based on prior art recently discovered by Inovis and not disclosed by the alleged inventors of the 669 Patent to the PTO. This motion seeks to stay the case in its entirety until the PTO determines whether it will grant the reexamination request and, if the PTO grants the request for reexamination, to stay the case until the PTO completes its reexamination.1 SUMMARY OF THE ARGUMENT It is well-accepted that, where a defendant files for reexamination of the patent-in-suit, a stay of the proceedings in district court is appropriate. This is because a stay usually will result in substantial savings of time for the Court, and time and expense for the parties, as well as clarify issues if the patent survives reexamination. The stay requested here will provide multiple benefits. The PTO is highly likely to grant reexamination since it is granting reexamination in over 95% of applications. The PTO is also likely to invalidate the 669 Patent because the prior art submitted overwhelmingly supports that conclusion. If that occurs, the entire course of the
1
If the PTO grants Inovis' request for reexamination, Inovis respectfully requests that the Court consider the PTO's actions and stay the entire case until the PTO completes its reexamination. See Gioello Enters. Ltd. v. Mattel, Inc., No. 99-375 GMS, 2001 U.S. Dist. LEXIS 26158, at *1-2 & n.1 (D. Del. Jan. 29, 2001) (considering the PTO's grant of defendant's request for reexamination even though defendant filed its motion to stay before the PTO granted the request). 1
Case 1:07-cv-00459-GMS
Document 65
Filed 04/28/2008
Page 6 of 14
litigation of Classified's Counterclaim would be avoided, since the Counterclaim was just filed two months ago, and discovery has just started, with Classified having served its first set of discovery requests only last week. The Court would not have to hold a Markman hearing, construe the pertinent claim terms, consider cross motions for summary judgment on infringement and invalidity, hold a trial, or decide post-trial motions. Even if the PTO only narrows one or more of the 669 Patent claims, the Court could take advantage of any changes to the patent claim scope that will most likely occur during the reexamination process. Any such changes in claim scope will affect the liability and damages issues for trial. Moreover, the Court will have the benefit of the PTO's thinking on the prior art presented to it during the reexamination proceedings. Because Classified did not file its Counterclaim until February 19, 2008 (D.I. 48), began written discovery only a few days ago, and because trial is not scheduled until nearly one year from now, Classified would not be prejudiced by a stay. Indeed, the filing of the reexamination request and of this motion have occurred much earlier in the life-cycle of a patent litigation than in many cases in which a stay was granted. Accordingly, Inovis' motion to stay the case should be granted. STATEMENT OF FACTS Inovis has recently discovered prior art that was not cited to the examiner by the alleged inventors of the 669 Patent during prosecution of that patent. On March 20, 2008, Inovis notified Classified that it intended to file a request for reexamination with the PTO based on this newly discovered prior art. (Ex. A). On April 14, 2008, Inovis filed a request for reexamination of all claims of the 669 Patent. (Ex. B). This reexamination is based on six new pieces of prior art.
2
Case 1:07-cv-00459-GMS
Document 65
Filed 04/28/2008
Page 7 of 14
The Patent Statute permits any person to request the PTO to reexamine an issued patent. 35 U.S.C. § 302. Within three months of the filing date of a request for reexamination, the PTO must determine if the request raises "a substantial new question of patentability affecting any claim of the patent" and, if the request does, the PTO must grant the reexamination. 35 U.S.C. §§ 303(a), 304. During reexamination, the PTO limits its reexamination to validity issues based upon printed publications and issued patents. 35 U.S.C. § 301. Patent owners may amend the patent claims or add new claims, so long as they do not enlarge the original claim scope. 35 U.S.C. § 305. At the conclusion of the reexamination proceeding, the PTO issues a reexamination certificate canceling any claim determined to be unpatentable, confirming patentable claims, if any, and incorporating any amended or new claims. 35 U.S.C. § 307. The intent of a reexamination procedure "is to `start over' in the PTO . . . and to reexamine the [original] claims, and to examine new or amended claims, as they would have been considered if they had been originally examined in light of all the prior art of record in the reexamination proceeding." Ethicon, Inc. v. Quigg, 849 F.2d 1422, 1427 (Fed. Cir. 1988) (citations omitted; emphasis in original). According to the PTO, 2,511 ex parte reexamination requests were filed between fiscal years 2002 and 2007, of which 2,389 determinations on these requests were made, and in 2,284 of those requests--or 95.6%--the PTO granted the request for reexamination. (Ex. C, "USPTO Performance and Accountability Report for Fiscal Year 2007" Table 13(a), available at http://www.uspto.gov/web/offices/com/annual/2007/50313a_table13a.html). In 2007, the PTO granted about 97% of the ex parte reexamination requests on which determinations were made. (Id.). There is therefore a very high probability that Inovis' reexamination requests will be granted and that the PTO will review the patentability of the 669 Patent claims.
3
Case 1:07-cv-00459-GMS
Document 65
Filed 04/28/2008
Page 8 of 14
ARGUMENT A district court has the inherent power and broad discretion to stay a patent infringement action pending reexamination proceedings. Ethicon, 849 F.2d at 1426-27; Abbott Diabetes Care, Inc. v. DexCom, Inc., C.A. No. 06-514 GMS, 2007 U.S. Dist. LEXIS 73198, at *12 (D. Del. Sept. 30, 2007). In exercising this authority, courts usually stay a patent litigation pending the decision of the PTO in a reexamination proceeding. See, e.g., Abbott, 2007 U.S. Dist. LEXIS 73198, at *12-17 (granting motion to stay proceeding pending reexamination of patents-in-suit); eSoft, Inc. v. Blue Coat Sys., Inc., 505 F. Supp. 2d 784, 786 (D. Col. 2007) ("Courts frequently note that `[t]he legislative history surrounding the establishment of the reexamination proceeding evinces congressional approval of district courts liberally granting stays.'") (citations omitted); Abbott Diabetes Care, Inc. v. DexCom, Inc., C.A. No. 05-590 GMS, 2006 U.S. Dist. LEXIS 57469, at *17-21 (D. Del. Aug. 16, 2006) (granting motion to stay proceeding pending reexamination of patents-in-suit); Echostar Techs. Corp. v. TiVo, Inc., No. 5:05-CV-81 (DF), 2006 U.S. Dist. LEXIS 48431 (E.D. Tex. July 14, 2006) (granting stay where reexamination requests were filed before a Markman and summary judgment ruling); Middleton, Inc. v. Minnesota Mining & Mfg Co., No. 4:03-cv-40493, 2004 U.S. Dist. LEXIS 16812 (S.D. Iowa Oct. 24, 2004); Alloc, Inc. v. Unilin Decor N.V., 03-253-GMS, 2003 U.S. Dist. LEXIS 11917 (D. Del. July 11, 2003); Pegasus Dev. Corp. v. DirectTV, Inc., 00-1020-GMS, 2003 U.S. Dist. LEXIS 8052 (D. Del. May 14, 2003) (granting motion to stay); Gioello, 2001 U.S. Dist. LEXIS 26158; Rohm and Haas Co. v. Brotech Corp., No. 90-109-SLR, 1992 U.S. Dist. LEXIS 3252 (D. Del. 1992). Courts are guided by the following factors in determining whether a stay is appropriate: "(i) whether a stay would unduly prejudice or present a clear tactical disadvantage to the non-moving party; (ii) whether a stay will simplify the issues in question and trial of the case; 4
Case 1:07-cv-00459-GMS
Document 65
Filed 04/28/2008
Page 9 of 14
and (iii) whether discovery is complete and whether a trial date has been set." Abbott, 2007 U.S. Dist. LEXIS 73198, at *13 (citations omitted). I. Because Classified Only Asserted Its Counterclaim Two Months Ago And Only Began Discovery Last Week, A Stay Would Not Unduly Prejudice Or Present A Clear Tactical Disadvantage To It Although Classified accused certain Inovis customers of allegedly infringing the 669 Patent as early as the summer of 2006, Classified has never moved for a preliminary injunction. Classified has therefore implicitly admitted that it is not being irreparably harmed by Inovis' alleged infringement and that it can be adequately compensated by money damages. Moreover, Classified delayed filing its Counterclaim for patent infringement, initially filing a motion to dismiss for lack of subject matter jurisdiction and then, after discovery was conducted on that motion, abruptly withdrawing it before the Court could rule. (D.I. 45). After that delay of Classified's own making, it finally filed a counterclaim on February 19, 2008. (D.I. 48). Classified then did nothing to begin discovery for over two months. Indeed, it was not until last week that Classified finally sent out its first set of document requests and interrogatories relating to patent infringement. (D.I. 63). Because discovery has only just started and because this case is in its infancy, Classified itself would undoubtedly save substantial resources in terms of the time and fees required to conduct discovery, expert discovery, summary judgment briefing, the Markman hearing, a trial, post-trial motions, and an appeal. If the PTO invalidates the 669 Patent, Classified will have saved all of that time and expense. But if one or more claims survive reexamation, Classified will still benefit from the PTO's review and analysis of the prior art submitted by Inovis. Gioello, 2001 U.S. Dist. LEXIS 26158, at *2-3.
5
Case 1:07-cv-00459-GMS
Document 65
Filed 04/28/2008
Page 10 of 14
II.
A Stay Would Greatly Simplify The Issues, Promote Settlement, And, If Trial Is Necessary, Shorten It The second factor--whether a stay will simplify the issues in question and trial of
the case--weighs greatly in favor of granting the stay. "`One purpose of the reexamination procedure is to eliminate trial of that issue (when the claim is canceled) or to facilitate trial of that issue by providing the district court with the expert view of the PTO (when a claim survives the reexamination proceeding).'" Abbott, 2007 U.S. Dist. LEXIS 73198, at *15 (quoting Gould v. Control Laser Corp. 705 F.2d 1340, 1342 (Fed. Cir. 1983)). A stay will present an opportunity for the Court to consider the PTO's views concerning the validity of the 669 Patent. Within three months, the PTO will make a formal determination whether the prior art relied upon by Inovis raises a substantial new question of patentability with respect to some or all of the 50 asserted claims of the 669 Patent under KSR. See KSR Int'l Co. v. Teleflex Inc., 127 S. Ct. 1727, 1734 (2007). The reasons presented by the PTO for the grant of a reexamination request may provide valuable insight as to the validity of the asserted patent claims. The Court can consider the PTO's views in considering any further proceedings in this action. The reexamination process could also result in other numerous efficiencies: (1) many discovery problems relating to the prior art may be alleviated; (2) the record of the reexamination likely would be entered at trial, reducing the complexity and length of the litigation; (3) the issues, defenses, and evidence will be more easily limited in pre-trial conferences following a reexamination; (4) the outcome of the reexamination process may encourage a settlement without further involvement of the court; and (5) if the patent is declared invalid, the suit likely will be dismissed as to that patent. These efficiencies will result in a reduced cost of litigation for the parties and more effective utilization of the limited resources of the court. Pegasus, 2003 U.S. Dist. LEXIS 8052, at *5-6 (internal citations omitted). Many issues in the litigation could become moot if the PTO determines that one or more of the claims of the 669 Patent are invalid. See Abbott, 2006 U.S. Dist. LEXIS 57469, at *19 ("[I]f the PTO determines
6
Case 1:07-cv-00459-GMS
Document 65
Filed 04/28/2008
Page 11 of 14
that some or all of the claims of the four patents undergoing reexamination are invalid, then many of the issues in the litigation will become moot."); Pegasus Dev. Corp, 2003 U.S. Dist. LEXIS 8052, at *6 ("[A] stay may result in a simplification or reduction of issues for the court's consideration, or it may dispense with the litigation entirely."). Finally, by staying the case, "the court would not run the risk of inconsistent rulings or issuing advisory opinions." Abbott, 2006 U.S. Dist. LEXIS 57469, at *20. The PTO cannot stay a reexamination once the request has been granted, thus, "the court's issuance of a stay is the only way to avoid the potential for conflict." Gioello, 2001 U.S. Dist. LEXIS 26158, at *5. Granting a stay "`will maximize the likelihood that neither the Court [sic] nor the parties expend their assets addressing invalid claims.'" Id. at *4 (quoting Softview Computer Prods. Corp. v. Haworth, Inc., No. 97 Civ. 8815 KMW HBP, 2000 U.S. Dist. LEXIS 11274, 2000 WL 1134471, at *3 (S.D.N.Y. Aug. 10, 2000)). III. The Benefits Of The Proposed Stay Are Not Outweighed By The Stage Of This Case The third factor, whether discovery is complete and whether a trial date has been set, does not outweigh the benefits that will flow from the proposed stay. In fact, this factor greatly favors granting a stay. As noted, although Classified threatened Inovis' customers with patent infringement as early as August 2006, it did not file a claim for infringement until February 19, 2008. (D.I. 48). Classified only began written discovery last week, and no depositions related to Classified's patent-infringement counterclaim have been conducted. Fact discovery is not due to close until August 8, 2008. (D.I. 25; January 15, 2008 Order). The Markman hearing is not scheduled until June 24, 2008. (Id.). Trial is not scheduled to start until March 23, 2009. (Id.). Because discovery is in the very earliest stage and trial is scheduled more than eleven months from now, the benefits discussed above are not even close to being
7
Case 1:07-cv-00459-GMS
Document 65
Filed 04/28/2008
Page 12 of 14
outweighed by the stage of the case. See Abbott, 2006 U.S. Dist. LEXIS 57469, at *20 (granting stay when fact discovery was scheduled to close six months after date of order and trial was scheduled to begin more than one year after date of order); Pegasus, 2003 U.S. Dist. LEXIS 8052, at *7 (in granting stay, "the court note[d] that discovery is not complete, and the trial, although scheduled, is some nine months in the future."); Gioello, 2001 U.S. Dist. LEXIS 26158, at *1-4 (stay granted where there were pending summary judgment motions on invalidity and infringement; defendant waited 17 months to file for reexamination; trial scheduled only 2 ½ months after decision granting stay). Indeed, this case is at a much earlier stage than other cases in which a stay has been granted. For example, in Pegasus, the case had been pending for two and a half years before the request for reexamination was filed, and summary judgment briefing on invalidity and non-infringement had already been submitted by the parties. Pegusus, 2003 U.S. Dist. LEXIS 8052, at *2, 4. In Gioello, the defendant did not file its request for reexamination until 17 months after the complaint was filed, and until motions for summary judgment on noninfringement and invalidity had been filed. Gioello, 2001 U.S. Dist. LEXIS 26158, at *1, 4. Inovis has acted much more promptly than the defendants in these cases. Accordingly, Classified will suffer no prejudice--much less "undue prejudice"--and the savings to the parties and the Court will be much greater.
8
Case 1:07-cv-00459-GMS
Document 65
Filed 04/28/2008
Page 13 of 14
CONCLUSION Granting a stay will conserve judicial resources, the parties' resources, avoid inconsistent rulings, and promote settlement. Accordingly, Inovis respectfully requests that the Court stay this case until the PTO determines whether to grant Inovis' request for reexamination of the 669 Patent and, if the PTO grants the request, until the PTO completes its reexamination.
MORRIS, NICHOLS, ARSHT & TUNNELL LLP
/s/ Julia Heaney
_________________________________________ Jack B. Blumenfeld, Esquire (#1014) Julia Heaney, Esquire (#3052) 1201 North Market Street P.O. Box 1347 Wilmington, DE 19899-1347 (302) 658-9200 [email protected] [email protected] Attorneys for Plaintiff Inovis USA, Inc.
OF COUNSEL: David J. Wolfsohn Erich M. Falke Jordan L. Jonas WOODCOCK WASHBURN LLP Cira Centre, 12th Floor 2929 Arch Street Philadelphia, PA 19104 (215) 568-3100 Dated: April 28, 2008
2308741
9
Case 1:07-cv-00459-GMS
Document 65
Filed 04/28/2008
Page 14 of 14
CERTIFICATE OF SERVICE I, the undersigned, hereby certify that on 28th day of April, 2008, I electronically filed the foregoing with the Clerk of the Court using CM/ECF which will send notification of such filing to the following: M. Duncan Grant, Esquire PEPPER HAMILTON LLP
and that copies were caused to be served upon the following individuals in the manner indicated: ELECTRONIC MAIL M. Duncan Grant, Esquire PEPPER HAMILTON LLP 1313 North Market Street, Suite 5100 P. O. Box 1790 Wilmington, DE 19899-1790 Michael A. Lee Vineet Bhatia, Esquire Susman Godfrey LLP 1000 Louisiana Street, Suite 5100 Houston, TX 77002-5096
/s/ Julia Heaney
Julia Heaney (#3052) [email protected]
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 1 of 122
EXHIBIT B-2
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 2 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 3 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 4 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 5 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 6 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 7 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 8 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 9 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 10 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 11 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 12 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 13 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 14 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 15 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 16 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 17 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 18 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 19 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 20 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 21 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 22 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 23 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 24 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 25 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 26 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 27 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 28 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 29 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 30 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 31 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 32 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 33 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 34 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 35 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 36 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 37 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 38 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 39 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 40 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 41 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 42 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 43 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 44 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 45 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 46 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 47 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 48 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 49 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 50 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 51 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 52 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 53 of 122
EXHIBIT B-3
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 54 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 55 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 56 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 57 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 58 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 59 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 60 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 61 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 62 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 63 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 64 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 65 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 66 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 67 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 68 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 69 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 70 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 71 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 72 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 73 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 74 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 75 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 76 of 122
EXHIBIT B-4
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 77 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 78 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 79 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 80 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 81 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 82 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 83 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 84 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 85 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 86 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 87 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 88 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 89 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 90 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 91 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 92 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 93 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 94 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 95 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 96 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 97 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 98 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 99 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 100 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 101 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 102 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 103 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 104 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 105 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 106 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 107 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 108 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 109 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 110 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 111 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 112 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 113 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 114 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 115 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 116 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 117 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 118 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 119 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 120 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 121 of 122
Case 1:07-cv-00459-GMS
Document 65-3
Filed 04/28/2008
Page 122 of 122
Case 1:07-cv-00459-GMS
Document 65-4
Filed 04/28/2008
Page 1 of 48
EXHIBIT B-5
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, R. ... Page 1 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 2 of 48
RFC 1505
Network Working Group Request for Comments: 1505 Obsoletes: 1154
A. Costanzo AKC Consulting D. Robinson Computervision Corporation R. Ullmann August 1993
Encoding Header Field for Internet Messages Status of this Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. IESG Note Note that a standards-track technology already exists in this area [11]. Abstract This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages. It replaces RFC 1154 [1]. Table of Contents 1. 2. 2.1 2.2 2.3 2.3.1 2.4 3. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 Introduction . . . . . . The Encoding Field . . . Format of the Encoding
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, R. ... Page 2 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 3 of 48
Costanzo, Robinson & Ullmann
[Page 1]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, R. ... Page 3 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 4 of 48
RFC 1505 Encoding Header Field August 1993
3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 4. 4.1 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.2.7 4.2.8 4.2.9 4.2.10 4.2.11 4.2.12 4.2.13 4.3 4.3.1 4.3.2 5. 5.1 5.2 5.3 5.3.1 5.3.2 6. 7. 8. 9. 10.
UUENCODE . . . . . . . . . . . . . . . . PEM and PEM-Clear . . . . . . . . . . . PGP . . . . . . . . . . . . . . . . . . Signature . . . . . . . . . . . . . . . TAR . . . . . . . . . . . . . . . . . . PostScript . . . . . . . . . . . . . . . SHAR . . . . . . . . . . . . . . . . . . Uniform Resource Locator . . . . . . . . Registering New Keywords . . . . . . . . FS (File System) Object Encoding . . . . . Sections . . . . . . . . . . . . . . . . Directory . . . . . . . . . . . . . . Entry . . . . . . . . . . . . . . . . File . . . . . . . . . . . . . . . . . Segment . . . . . . . . . . . . . . . Data . . . . . . . . . . . . . . . . . Attributes . . . . . . . . . . . . . . . Display . . . . . . . . . . . . . . . Comment . . . . . . . . . . . . . . . Type . . . . . . . . . . . . . . . . . Created . . . . . . . . . . . . . . . Modified . . . . . . . . . . . . . . . Accessed . . . . . . . . . . . . . . . Owner . . . . . . . . . . . . . . . . Group . . . . . . . . . . . . . . . . ACL . . . . . . . . . . . . . . . . . Password . . . . . . . . . . . . . . . Block . . . . . . . . . . . . . . . . Record . . . . . . . . . . . . . . . . Application . . . . . . . . . . . . . Date Field . . . . . . . . . . . . . . . Syntax . . . . . . . . . . . . . . . . Semantics . . . . . . . . . . . . . . LZJU90: Compressed Encoding . . . . . . . Overview . . . . . . . . . . . . . . . . Specification of the LZJU90 compression The Decoder . . . . . . . . . . . . . . An example of an Encoder . . . . . . . Example LZJU90 Compressed Object . . . Alphabetical Listing of Defined Encodings Security Considerations . . . . . . . . . References . . . . . . . . . . . . . . . . Acknowledgements . . . . . . . . . . . . . Authors' Addresses . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . 7 . . 8 . . 8 . 10 . 10 . 10 . 10 . 10 . 11 . 11 . 12 . 12 . 13 . 13 . 13 . 14 . 14 . 14 . 15 . 15 . 15 . 15 . 15 . 15 . 16 . 16 . 16 . 16 . 17 . 17 . 17 . 17 . 17 . 18 . 18 . 19 . 21 . 27 . 33 . 34 . 34 . 34 . 35 . 36
Costanzo, Robinson & Ullmann
[Page 2]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, R. ... Page 4 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 5 of 48
RFC 1505 Encoding Header Field August 1993
1.
Introduction STD 11, RFC 822 [2] defines an electronic mail message to consist of two parts, the message header and the message body, separated by a blank line. The Encoding header field permits the message body itself to be further broken up into parts, each part also separated from the next by a blank line. Thus, conceptually, a message has a header part, followed by one or more body parts, all separated by apparently blank lines. Each body part has an encoding type. The default (no Encoding field in the header) is a one part message body of type "Text". The purpose of Encoding is to be descriptive of the content of a mail message without placing constraints on the content or requiring additional structure to appear in the body of the message that will interfere with other processing. A similar message format is used in the network news facility, and posted articles are often transferred by gateways between news and mail. The Encoding field is perhaps even more useful in news, where articles often are uuencoded or shar'd, and have a number of different nested encodings of graphics images and so forth. In news in particular, the Encoding header keeps the structural information within the (usually concealed) article header, without affecting the visual presentation by simple news-reading software.
2.
The Encoding Field The Encoding field consists of one or more subfields, separated by commas. Each subfield corresponds to a part of the message, in the order of that part's appearance. A subfield consists of a line count and a keyword or a series of nested keywords defining the encoding. The line count is optional in the last subfield.
2.1
Format of the Encoding Field The format of the Encoding field is: [
where:
Costanzo, Robinson & Ullmann
[Page 3]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, R. ... Page 5 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 6 of 48
RFC 1505 Encoding Header Field August 1993
2.2
2.3
2.3.1
Nested Keywords
Nested keywords are a series of keywords defining a multi-encoded message part. The encoding keywords may either be an actual series of encoding steps the encoder used to generate the message part or may merely be used to more precisely identify the type of encoding (as in the use of the keyword "Signature"). Nested keywords are parsed and generated from left to right. The order is significant. A decoding application would process the list from left to right, whereas, an encoder would process the Internet message and generate the nested keywords in the reverse order of the actual encoding process. Encoding: 458 uuencode LZW tar (Unix binary object) 2.4 Comments Comments enclosed in parentheses may be inserted anywhere in the encoding field. Mail reading systems may pass the comments to their clients. Comments must not be used by mail reading systems for content interpretation. Other parameters defining the type of encoding must be contained within the body portion of the Internet message or be implied by a keyword in the encoding field.
Costanzo, Robinson & Ullmann
[Page 4]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, R. ... Page 6 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 7 of 48
RFC 1505 Encoding Header Field August 1993
3.
Encodings This section describes some of the defined encodings used. alphabetical listing is provided in Section 6. An
As with the other keyword-defined parts of the header format standard, new keywords are expected and welcomed. Several basic principles should be followed in adding encodings. The keyword should be the most common single word name for the encoding, including acronyms if appropriate. The intent is that different implementors will be likely to choose the same name for the same encoding. Keywords should not be too general: "binary" would have been a bad choice for the "hex" encoding. The encoding should be as free from unnecessary idiosyncracies as possible, except when conforming to an existing standard, in which case there is nothing that can be done. The encoding should, if possible, use only the 7 bit ASCII printing characters if it is a complete transformation of a source document (e.g., "hex" or "uuencode"). If it is essentially a text format, the full range may be used. If there is an external standard, the character set may already be defined. Keywords beginning with "X-" are permanently reserved to implementation-specific use. No standard registered encoding keyword will ever begin with "X-". New encoding keywords which are not reserved for implementationspecific use must be registered with the Internet Assigned Numbers Authority (IANA). Refer to section 3.17 for additional information. 3.1 Text This indicates that the message is in no particular encoded format, but is to be presented to the user as-is. The text is ISO-10646-UTF-1 [3]. As specified in STD 10, RFC 821 [10], the message is expected to consist of lines of reasonable length (less than or equal to 1000 characters). On some older implementations of mail and news, only the 7 bit subset of ISO-10646-UTF-1 can be used. This is identical to the ASCII 7 bit code. On some mail transports that are not compliant with STD 10, RFC 821 [10], line length may be restricted by the service. Text may be followed by a nested keyword to define the encoded part further, e.g., "signature": Encoding: 496 Text, 8 Text Signature
Costanzo, Robinson & Ullmann
[Page 5]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, R. ... Page 7 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 8 of 48
RFC 1505 Encoding Header Field August 1993
An automated file sending service may find this useful, for example, to differentiate between and ignore the signature area when parsing the body of a message for file requests. 3.2 Message This encoding indicates that the body part is itself in the format of an Internet message, with its own header part and body part(s). A "message" body part's message header may be a full Internet message header or it may consist only of an Encoding field. Using the message encoding on returned mail makes it practical for a mail reading system to implement a reliable automatic resending function, if the mailer generates it when returning contents. It is also useful in a "copy append" MUA (mail user agent) operation. MTAs (mail transfer agents) returning mail should generate an Encoding header. Note that this does not require any parsing or transformation of the returned message; the message is simply appended un-modified; MTAs are prohibited from modifying the content of messages. Encoding: 7 Text (Return Reason), Message (Returned Mail) 3.3 Hex The encoding indicates that the body part contains binary data, encoded as 2 hexadecimal digits per byte, highest significant nibble first. Lines consist of an even number of hexadecimal digits. Blank lines are not permitted. The decode process must accept lines with between 2 and 1000 characters, inclusive. The Hex encoding is provided as a simple way of providing a method of encoding small binary objects. 3.4 EVFU EVFU (electronic vertical format unit) specifies that each line begins with a one-character "channel selector". The original purpose was to select a channel on a paper tape loop controlling the printer. This encoding is sometimes called "FORTRAN" format. It is the default output format of FORTRAN programs on a number of computer systems.
Costanzo, Robinson & Ullmann
[Page 6]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, R. ... Page 8 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 9 of 48
RFC 1505 Encoding Header Field August 1993
The legal characters are '0' to '9', '+', '-', and space. These correspond to the 12 rows (and absence of a punch) on a printer control tape (used when the control unit was electromechanical). The channels that have generally agreed definitions are: 1 0 + (space) 3.5 advances to the first print line on the next page skip a line, i.e., double-space over-print the preceeding line skip 2 lines, i.e., triple-space print on the next line, single-space
EDI-X12 and EDIFACT The EDI-X12 and EDIFACT keywords indicate that the message or part is a EDI (Electronic Document Interchange) business document, formatted according to ANSI X12 or the EDIFACT standard. A message containing a note and 2 X12 purchase orders might have an encoding of: Encoding: 17 TEXT, 146 EDI-X12, 69 EDI-X12
3.6
FS The FS (File System) keyword specifies a section consisting of encoded file system objects. This encoding method (defined in section 4) allows the moving of a structured set of files from one environment to another while preserving all common elements.
3.7
LZJU90 The LZJU90 keyword specifies a section consisting of an encoded binary or text object. The encoding (defined in section 5) provides both compression and representation in a text format.
3.8
LZW The LZW keyword specifies a section consisting of the data produced by the Unix compress program.
3.9
UUENCODE The uuencode keyword specifies a section consisting of the output of the uuencode program supplied as part of uucp.
Costanzo, Robinson & Ullmann
[Page 7]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, R. ... Page 9 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 10 of 48
RFC 1505 Encoding Header Field August 1993
3.10
PEM and PEM-Clear
The PEM and PEM-Clear keywords indicate that the section is encrypted with the methods specified in RFCs 1421-1424 [4,5,6,7] or uses the MIC-Clear encapsulation specified therein. A simple text object encrypted with PEM has the header: Encoding: PEM Text Note that while this indicates that the text resulting from the PEM decryption is ISO-10646-UTF-1 text, the present version of PEM further restricts this to only the 7 bit subset. A future version of PEM may lift this restriction. If the object resulting from the decryption starts with Internet message header(s), the encoding is: Encoding: PEM Message This is useful to conceal both the encoding within and the headers not needed to deliver the message (such as Subject:). PEM does not provide detached signatures, but rather provides the MIC-Clear mode to send messages with integrity checks that are not encrypted. In this mode, the keyword PEM-Clear is used: Encoding: PEM-Clear EDIFACT The example being a non-encrypted EDIFACT transaction with a digital signature. With the proper selection of PEM parameters and environment, this can also provide non-repudiation, but it does not provide confidentiality. Decoders that are capable of decrypting PEM treat the two keywords in the same way, using the contained PEM headers to distinguish the mode. Decoders that do not understand PEM can use the PEM-Clear keyword as a hint that it may be useful to treat the section as text, or even continue the decode sequence after removing the PEM headers. When Encoding is used for PEM, the RFC934 [9] encapsulation specified in RFC1421 is not used. 3.11 PGP
The PGP keyword indicates that the section is encrypted using the Pretty Good Privacy specification, or is a public key block, keyring, or detached signature meaningful to the PGP program. (These objects
Costanzo, Robinson & Ullmann
[Page 8]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, ... Page 10 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 11 of 48
RFC 1505 Encoding Header Field August 1993
are distinguished by internal information.) The keyword actually implies 3 different transforms: a compression step, the encryption, and an ASCII encoding. These transforms are internal to the PGP encoder/decoder. A simple text message encrypted with PGP is specified by: Encoding: PGP Text An EDI transaction using ANSI X12 might be: Encoding: 176 PGP EDI-X12 Since an evesdropper can still "see" the nested type (Text or EDI in these examples), thus making information available to traffic analysis which is undesirable in some applications, the sender may prefer to use: Encoding: PGP Message As discussed in the description of the Message keyword, the enclosed object may have a complete header or consist only of an Encoding: header describing its content. When PGP is used to transmit an encoded key or keyring, with no object significant to the mail user agent as a result of the decoding (e.g., text to display), the keyword is used by itself. Another case of the PGP keyword occurs in "clear-signing" a message. That is, sending an un-encrypted message with a digital signature providing authentication and (in some environments) non-deniability. Encoding: 201 Text, 8 PGP Signature, 4 Text Signature This example indicates a 201 line message, followed by an its encoded form) PGP detached signature. The processing section is expected (in this example) to result in a text is to be treated by the receiver as a signature, possibly like: [PGP signed [email protected] Robert L Ullmann 8 line (in of the PGP object that something
VALID/TRUSTED]
Note that the PGP signature algorithm is applied to the encoded form of the clear-text section, not the object(s) before encoding. (Which would be quite difficult for encodings like tar or FS). Continuing the example, the PGP signature is then followed by a 4 line "ordinary" signature section.
Costanzo, Robinson & Ullmann
[Page 9]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, ... Page 11 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 12 of 48
RFC 1505 Encoding Header Field August 1993
3.12
Signature
The signature keyword indicates that the section contains an Internet message signature. An Internet message signature is an area of an Internet message (usually located at the end) which contains a single line or multiple lines of characters. The signature may comprise the sender's name or a saying the sender is fond of. It is normally inserted automatically in all outgoing message bodies. The encoding keyword "Signature" must always be nested and follow another keyword. Encoding: 14 Text, 3 Text Signature A usenet news posting program should generate an encoding showing which is the text and which is the signature area of the posted message. 3.13 TAR
The tar keyword specifies a section consisting of the output of the tar program supplied as part of Unix. 3.14 PostScript
The PostScript keyword specifies a section formatted according to the PostScript [8] computer program language definition. PostScript is a registered trademark of Adobe Systems Inc. 3.15 SHAR
The SHAR keyword specifies a section encoded in shell archive format. Use of shar, although supported, is not recommended. WARNING: Because the shell archive may contain commands you may not want executed, the decoder should not automatically execute decoded shell archived statements. This warning also applies to any future types that include commands to be executed by the receiver. 3.16 Uniform Resource Locator
The URL keyword indicates that the section consists of zero or more references to resources of some type. URL provides a facility to include by reference arbitrary external resources from various sources in the Internet. The specification of URL is a work in progress in the URI working group of the IETF.
Costanzo, Robinson & Ullmann
[Page 10]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, ... Page 12 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 13 of 48
RFC 1505 Encoding Header Field August 1993
3.17
Registering New Keywords
New encoding keywords which are not reserved for implementationspecific use must be registered with the Internet Assigned Numbers Authority (IANA). IANA acts as a central registry for these values. IANA may reject or modify the keyword registration request if it does not meet the criteria as specified in section 3. Keywords beginning with "X-" are permanently reserved to implementation-specific use. IANA will not register an encoding keyword that begins with "X-". Registration requests should be sent via electronic mail to IANA as follows: To: [email protected] Subject: Registration of a new EHF-MAIL Keyword The mail message must specify the keyword for the encoding and acronyms if appropriate. Documentation defining the keyword and its proposed purpose must be included. The documentation must either reference an external non-Internet standards document or an existing or soon to be RFC. If applicable, the documentation should contain a draft version of the future RFC. The draft must be submitted as a RFC according to the normal procedure within a reasonable amount of time after the keyword's registration has been approved. 4. FS (File System) Object Encoding The file system encoding provides a standard, transportable encoding of file system objects from many different operating systems. The intent is to allow the moving of a structured set of files from one environment to another while preserving common elements. At the same time, files can be moved within a single environment while preserving all attributes. The representations consist of a series of nested sections, with attributes defined at the appropriate levels. Each section begins with an open bracket "[" followed by a directive keyword and ends with a close bracket "]". Attributes are lines, beginning with a keyword. Lines which begin with a LWSP (linear white space) character are continuation lines. Any string-type directive or attribute may be a simple string not starting with a quotation mark ( " ) and not containing special characters (e.g. newline) or LWSP (space and tab). The string name begins with the first non-LWSP character on the line following the attribute or directive keyword and ends with the last non-LWSP character.
Costanzo, Robinson & Ullmann
[Page 11]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, ... Page 13 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 14 of 48
RFC 1505 Encoding Header Field August 1993
Otherwise, the character string name is enclosed in quotes. The string itself contains characters in ISO-10646-UTF-1 but is quoted and escaped at octet level (as elsewhere in RFC822 [2]). The strings begin and end with a quotation mark ( " ). Octets equal to quote in the string are escaped, as are octets equal to the escape characters (\" and \\). The escaped octets may be part of a UTF multi-octet character. Octets that are not printable are escaped with \nnn octal representation. When an escape (\) occurs at the end of a line, the escape, the end of the line, and the first character of the next line, which must be one of the LWSP characters, are removed (ignored). [ file Simple-File.Name [ file " Long file name starting with spaces and having a couple\ [sic] of nasties in it like this newline\012near the end." Note that in the above example, there is one space (not two) between "couple" and "[sic]". The encoder may choose to use the nnn sequence for any character that might cause trouble. Refer to section 5.1 for line length recommendations. 4.1 Sections A section starts with an open bracket, followed by a keyword that defines the type of section. The section keywords are: directory entry file segment data The encoding may start with either a file, directory or entry. A directory section may contain zero or more file, entry, and directory sections. A file section contains a data section or zero or more segment sections. A segment section contains a data section or zero or more segment sections. 4.1.1 Directory There is one parameter, the
This indicates the start of a directory. entry name of the directory:
Costanzo, Robinson & Ullmann
[Page 12]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, ... Page 14 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 15 of 48
RFC 1505 Encoding Header Field August 1993
[ directory foo ... ] 4.1.2 Entry
The entry keyword represents an entry in a directory that is not a file or a sub-directory. Examples of entries are soft links in Unix, or access categories in Primos. A Primos access category might look like this: [ entry SYS.ACAT type ACAT created 27 Jan 1987 15:31:04.00 acl SYADMIN:* ARIEL:DALURWX $REST: ] 4.1.3 File
The file keyword is followed by the entry name of the file. The section then continues with attributes, possibly segments, and then data. [ file MY.FILE created 27 Feb 1987 12:10:20.07 modified 27 Mar 1987 16:17:03.02 type DAM [ data LZJU90 * LZJU90 ... ]] 4.1.4 Segment
This is used to define segments of a file. It should only be used when encoding files that are actually segmented. The optional parameter is the number or name of the segment. When encoding Macintosh files, the two forks of the file are treated as segments:
Costanzo, Robinson & Ullmann
[Page 13]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, ... Page 15 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 16 of 48
RFC 1505 Encoding Header Field August 1993
[ file A.MAC.FILE display "A Mac File" type MAC comment "I created this myself" ... [ segment resource [ data ... ... ]] [ segment data [ data ... ... ]]] 4.1.5 Data
The data section contains the encoded data of the file. The encoding method is defined in section 5. The data section must be last within the containing section. 4.2 Attributes Attributes may occur within file, entry, directory, and segment sections. Attributes must occur before sub-sections. The attribute directives are: display type created modified accessed owner group acl password block record application 4.2.1 Display
This indicates the display name of the object. Some systems, such as the Macintosh, use a different form of the name for matching or uniqueness.
Costanzo, Robinson & Ullmann
[Page 14]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, ... Page 16 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 17 of 48
RFC 1505 Encoding Header Field August 1993
4.2.2
Comment The Macintosh
This contains an arbitrary comment on the object. stores this attribute with the file. 4.2.3 Type
The type of an object is usually of interest only to the operating system that the object was created on. Types are: ACAT CAM DAM FIXED FLAT ISAM LINK MAC SAM SEGSAM SEGDAM TEXT VAR 4.2.4 Created Dates are in the format access category (Primos) contiguous access method (Primos) direct access method (Primos) fixed length records (VMS) `flat file', sequence of bytes (Unix, DOS, default) indexed-sequential access method (VMS) soft link (Unix) Macintosh file sequential access method (Primos) segmented direct access method (Primos) segmented sequential access method (Primos) lines of ISO-10646-UTF-1 text ending with CR/LF variable length records (VMS)
Indicates the creation date of the file. defined in section 4.3. 4.2.5 Modified
Indicates the date and time the file was last modified or closed after being open for write. 4.2.6 Accessed
Indicates the date and time the file was last accessed on the original file system. 4.2.7 Owner
The owner directive gives the name or numerical ID of the owner or creator of the file.
Costanzo, Robinson & Ullmann
[Page 15]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, ... Page 17 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 18 of 48
RFC 1505 Encoding Header Field August 1993
4.2.8
Group
The group directive gives the name(s) or numerical IDs of the group or groups to which the file belongs. 4.2.9 ACL
This directive specifies the access control list attribute of an object (the ACL attribute may occur more than once within an object). The list consist of a series of pairs of IDs and access codes in the format: user-ID:access-list
There are four reserved IDs: $OWNER $GROUP $SYSTEM $REST the owner or creator a member of the group or groups a system administrator everyone else
The access list is zero or more single letters: A D L P R U W X * 4.2.10 Password add (create file) delete list (read directory) change protection read use write execute all possible access
The password attribute gives the access password for this object. Since the content of the object follows (being the raison d'etre of the encoding), the appearance of the password in plain text is not considered a security problem. If the password is actually set by the decoder on a created object, the security (or lack) is the responsibility of the application domain controlling the decoder as is true of ACL and other protections. 4.2.11 Block
The block attribute gives the block size of the file as a decimal number of bytes.
Costanzo, Robinson & Ullmann
[Page 16]
http://rfc.dotsrc.org/rfc/rfc1505.html
4/14/2008
RFC 1505 - Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, ... Page 18 of 39 Case 1:07-cv-00459-GMS Document 65-4 Filed 04/28/2008 Page 19 of 48
RFC 1505 Encoding Header Field August 1993
4.2.12
Record
The record attribute gives the record size of the file as a decimal number of bytes. 4.2.13 Application
This specifies the application that the file was created with or belongs to. This is of particular interest for Macintosh files. 4.3 Date Field Various attributes have a date and time subsequent to and associated with them. 4.3.1 Syntax
The syntax of the date field is a combination of date, time, and timezone: DD Mon YYYY HH:MM:SS.FFFFFF [+-]HHMMSS Date := DD := Mon := DD Mon YYYY Day Month 1 or 2 Digits " " 3 Alpha " " 4 Digits e.g. "08", " 8", "8" "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec" 2 Digits ":" 2 Dig
United States Free Forms
Canada Free Forms
United Kingdom Free Forms
Australia Free Forms