From owner-ietf-fax@mail.imc.org Sun Jun 9 18:29:18 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08348 for ; Sun, 9 Jun 2002 18:29:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g59M9qR25314 for ietf-fax-bks; Sun, 9 Jun 2002 15:09:52 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g59M9pn25304 for ; Sun, 9 Jun 2002 15:09:51 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KIQ8ZOXFO00000F4@mauve.mrochek.com> for ietf-fax@imc.org; Sun, 09 Jun 2002 15:09:42 -0700 (PDT) Date: Sun, 09 Jun 2002 13:45:01 -0700 (PDT) From: ned.freed@mrochek.com Subject: AD review comments on draft-ietf-fax-esmtp-conneg-01.txt To: ietf-fax@imc.org, dcrocker@brandenburg.com, ktoyoda@rdmg.mgcs.mei.co.jp Cc: ned.freed@mrochek.com, paf@cisco.com Message-id: <01KIQC1AOP6S0000F4@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Let's start with an obvious document issue, easily fixed: The IANA considerations section. It currently says "This memo is not intended to create any new issues for IANA." However, the document's primary goal is to define an ESMTP extension, and registration of ESMTP extensions is an IANA activity. As such, I suggest this section be changed to read "On publicatioj of this document by the RFC Editor the IANA shall register the Content_Negotiation ESMTP extension defined in section 2." Another minor document issue is that the RFC Editor has a new policy that references must be separated into normative and informative groups. In this case I think there is effectively no separation: All three of the references here appear normative to me. So the thing to do is change the title of section 9 to "NORMATIVE REFERENCES". Another document issue is that this document begins with a SUMMARY but has no ABSTRACT or INTRODUCTION. The RFC Editor wants to see a separate ABSTRACT and INTRODUCTION section in all new RFCs. I would suggest keeping the current SUMMARY as the ABSTRACT and writing a new INTRODUCTION, reiterating the ABSTRACT but adding some additional background information if possible. On to security considerations. What's there seems entirely appropriate. However, there's are two other security considerations I believe deserve mention: The possibility that a vulnerability will be disclosed by the mechanism and the possibility of tampering with the result the mechanism returns. The first specific case that concerns me is that of a capability that is typically handled by, say, a plugin that has been found to contain a security vulnerability. Disclosure of support for this capability becomes tantamount to disclosing a vulnerability. The second case is one where a man in the middle changes the capabilities associated with a given recipient. Here's a somewhat fanciful example: Suppose the sender knows the recipient has the ability to view color documents so they mark some things in red in what is otherwise a black and white document. But someone interferes with the returned capabilities, making them say the recipient only supports black and white. The document is duly downgraded, with the result that the recipient doesn't see what the sender marked. (Of course the man in the middle could have tampered with the document itself, but modifying a document on the fly is a much more difficult proposition.) I'm not suggesting that this facility be changed to address these issues, merely that they be mentioned in the security considerations section. Next up is failure modes. The model defined here seems simple enough: Client asks server for capabilities for a given recipient and the server either returns those capabilities or fails with a CONNEG-specific error code. I wonder, however, if this isn't too simple. A server may have no trouble delivering mail to a given recipient but might be unable to return that recipient's capabilities. And this could be either a temporary or permanent failure: The directory containing this information could be offline, or it could be the case that this information simply isn't available for this particular recipient. Of course a client that receives a 504 can always retry the recipient without the CONNEG parameter if it is willing to operate in the absence of capability information. But it may want to take different actions depending on whether the failure is temporary or permanent: I could easily see sending some sort of default for a permanent failure while waiting to retry in the even of a temporary failure. I therefore suggest that an additional 404 status code be defined that can be returned when the server experiences a temporary failure getting capability information. The unconditional use of a failure code when capabilities aren't available also concerns me. While it is true the client can simply reissue the RCPT TO without the CONNEG parameter, handling this case effectively stalls the SMTP dialogue. (That is, the client has to wait for the response to the RCPT TO before it knows how to proceed.) And dialogue stalls are a significant operational issue in practice. I therefore suggest that the mechanism be changed to allow a CONNEG parameter value. The value would be, say, either REQUIRED or OPTIONAL. The REQUIRED value would result in the same behavior currently described in the document. The OPTIONAL case, however, would instruct the server to proceed normally and return a _success_ status when the capabilities aren't available. A corresponding 2xx code would need to be defined for this case. This document also fails to specify what enhanced status code should be returned in the event the server is unable to return capabilities information. Looking at the list in RFC 1893 I'd say one possibility is x.3.3, system not capable of selected feature. I also note in passing that there are no examples of CONNEG failures in the examples section. Some examples of this sort need to be added. Another interesting case that could arise in practice is where a server is configured to require authentication, integrity, or privacy services before capability information can be returned. I think the document needs to discuss this case, saying that if such requirements have not been met the CONNEG extension should not be offered in the EHLO response. (Note that successful security negotiation already involves repeating EHLO.) Although several examples of returned capabilities are shown, the document isn't very specific about how capabilities have to be formatted. In particular, I'd expect to see capabilities often stored as a single string without any line breaks. Some advice on how to take such a string and format it for inclusion in the reponse seems warranted. According to this document the only capabilities that can be returned are those defined in RFC 2879, which is FAX-specific. I realize this document is a product of the FAX WG, but is this really appropriate? Should more general capabilites return be allowed? And if not, shouldn't this extension be called FAXCONNEG or something similar? Finally, this document makes passing reference to "use in relay scenarios". I think some elaboration of this might be in order. In particular, I see at least two scenarios that involve relaying: One where a server knows it will subsequently relay the message but offers up capability information by proxy, and another where the client is an intermediary service with message downgrading capabilities. That's it! Ned From owner-ietf-fax@mail.imc.org Mon Jun 10 00:38:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13515 for ; Mon, 10 Jun 2002 00:38:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5A4NtN12542 for ietf-fax-bks; Sun, 9 Jun 2002 21:23:55 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5A4Nsn12538 for ; Sun, 9 Jun 2002 21:23:54 -0700 (PDT) Received: by bulls.mei.co.jp (8.12.2/3.7W/kings) with ESMTP id g5A4NVaL014597; Mon, 10 Jun 2002 13:23:31 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) with SMTP id g5A4NVX13703; Mon, 10 Jun 2002 13:23:31 +0900 (JST) Received: from no.name.available by m-bb.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 10 Jun 2002 04:23:32 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0-1.mgcs.mei.co.jp (8.12.2/3.7W-HUB) with ESMTP id g5A4KtZ6005373; Mon, 10 Jun 2002 13:20:55 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id NAA29560; Mon, 10 Jun 2002 13:23:31 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.12.2/3.7W-RDMG) with SMTP id g5A4N1lI025906; Mon, 10 Jun 2002 13:23:01 +0900 (JST) Message-Id: <200206100430.AA01336@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Mon, 10 Jun 2002 13:30:53 +0900 To: ned.freed@mrochek.com Cc: ietf-fax@imc.org, dcrocker@brandenburg.com, paf@cisco.com Subject: Re: AD review comments on draft-ietf-fax-esmtp-conneg-01.txt In-Reply-To: <01KIQC1AOP6S0000F4@mauve.mrochek.com> References: <01KIQC1AOP6S0000F4@mauve.mrochek.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.12 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Freed-san, Thank you for checking document and clarify issues. I will study issues and respond next week. ned.freed@mrochek.com wrote: > >Let's start with an obvious document issue, easily fixed: The IANA >considerations section. It currently says "This memo is not intended to create >any new issues for IANA." However, the document's primary goal is to define an >ESMTP extension, and registration of ESMTP extensions is an IANA activity. As >such, I suggest this section be changed to read "On publicatioj of this >document by the RFC Editor the IANA shall register the Content_Negotiation >ESMTP extension defined in section 2." > >Another minor document issue is that the RFC Editor has a new policy that >references must be separated into normative and informative groups. In this >case I think there is effectively no separation: All three of the references >here appear normative to me. So the thing to do is change the title of section >9 to "NORMATIVE REFERENCES". > >Another document issue is that this document begins with a SUMMARY but has no >ABSTRACT or INTRODUCTION. The RFC Editor wants to see a separate ABSTRACT and >INTRODUCTION section in all new RFCs. I would suggest keeping the current >SUMMARY as the ABSTRACT and writing a new INTRODUCTION, reiterating the >ABSTRACT but adding some additional background information if possible. > >On to security considerations. What's there seems entirely appropriate. >However, there's are two other security considerations I believe deserve >mention: The possibility that a vulnerability will be disclosed by the >mechanism and the possibility of tampering with the result the mechanism >returns. > >The first specific case that concerns me is that of a capability that is >typically handled by, say, a plugin that has been found to contain a security >vulnerability. Disclosure of support for this capability becomes tantamount to >disclosing a vulnerability. > >The second case is one where a man in the middle changes the capabilities >associated with a given recipient. Here's a somewhat fanciful example: Suppose >the sender knows the recipient has the ability to view color documents so they >mark some things in red in what is otherwise a black and white document. But >someone interferes with the returned capabilities, making them say the >recipient only supports black and white. The document is duly downgraded, with >the result that the recipient doesn't see what the sender marked. (Of course >the man in the middle could have tampered with the document itself, but >modifying a document on the fly is a much more difficult proposition.) > >I'm not suggesting that this facility be changed to address these issues, >merely that they be mentioned in the security considerations section. > >Next up is failure modes. The model defined here seems simple enough: Client >asks server for capabilities for a given recipient and the server either >returns those capabilities or fails with a CONNEG-specific error code. > >I wonder, however, if this isn't too simple. A server may have no trouble >delivering mail to a given recipient but might be unable to return that >recipient's capabilities. And this could be either a temporary or permanent >failure: The directory containing this information could be offline, or it >could be the case that this information simply isn't available for this >particular recipient. > >Of course a client that receives a 504 can always retry the recipient without >the CONNEG parameter if it is willing to operate in the absence of capability >information. But it may want to take different actions depending on whether the >failure is temporary or permanent: I could easily see sending some sort of >default for a permanent failure while waiting to retry in the even of a >temporary failure. > >I therefore suggest that an additional 404 status code be defined that can be >returned when the server experiences a temporary failure getting capability >information. > >The unconditional use of a failure code when capabilities aren't available also >concerns me. While it is true the client can simply reissue the RCPT TO without >the CONNEG parameter, handling this case effectively stalls the SMTP dialogue. >(That is, the client has to wait for the response to the RCPT TO before it >knows how to proceed.) And dialogue stalls are a significant operational issue >in practice. I therefore suggest that the mechanism be changed to allow a >CONNEG parameter value. The value would be, say, either REQUIRED or OPTIONAL. >The REQUIRED value would result in the same behavior currently described in the >document. The OPTIONAL case, however, would instruct the server to proceed >normally and return a _success_ status when the capabilities aren't available. >A corresponding 2xx code would need to be defined for this case. > >This document also fails to specify what enhanced status code should be >returned in the event the server is unable to return capabilities information. >Looking at the list in RFC 1893 I'd say one possibility is x.3.3, system not >capable of selected feature. I also note in passing that there are no examples >of CONNEG failures in the examples section. Some examples of this sort need to >be added. > >Another interesting case that could arise in practice is where a server is >configured to require authentication, integrity, or privacy services before >capability information can be returned. I think the document needs to discuss >this case, saying that if such requirements have not been met the CONNEG >extension should not be offered in the EHLO response. (Note that successful >security negotiation already involves repeating EHLO.) > >Although several examples of returned capabilities are shown, the document >isn't very specific about how capabilities have to be formatted. In particular, >I'd expect to see capabilities often stored as a single string without any line >breaks. Some advice on how to take such a string and format it for inclusion in >the reponse seems warranted. > >According to this document the only capabilities that can be returned are those >defined in RFC 2879, which is FAX-specific. I realize this document is a >product of the FAX WG, but is this really appropriate? Should more general >capabilites return be allowed? And if not, shouldn't this extension be called >FAXCONNEG or something similar? > >Finally, this document makes passing reference to "use in relay scenarios". I >think some elaboration of this might be in order. In particular, I see at least >two scenarios that involve relaying: One where a server knows it will >subsequently relay the message but offers up capability information by proxy, >and another where the client is an intermediary service with message >downgrading capabilities. > >That's it! > > Ned > Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Mon Jun 10 13:41:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15700 for ; Mon, 10 Jun 2002 13:41:55 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5AHQ9o20207 for ietf-fax-bks; Mon, 10 Jun 2002 10:26:09 -0700 (PDT) Received: from umbriel.eastgw.xerox.com (umbriel.xerox.com [208.140.33.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AHQ8n20202 for ; Mon, 10 Jun 2002 10:26:08 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by umbriel.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id NAA06707; Mon, 10 Jun 2002 13:25:47 -0400 (EDT) Received: from mercury.adoc.xerox.com (mercury [13.242.100.20]) by godzilla.ADOC.xerox.com (8.8.8+Sun/8.8.8/ADOC-HUB-1.7) with ESMTP id KAA11389; Mon, 10 Jun 2002 10:26:07 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2654.89) id ; Mon, 10 Jun 2002 10:26:06 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE0D912A50@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'ned.freed@mrochek.com'" , ietf-fax@imc.org Subject: RE: AD review comments on draft-ietf-fax-esmtp-conneg-01.txt Date: Mon, 10 Jun 2002 10:26:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ned, Thank you for your attention and feedback on draft-ietf-fax-esmtp-conneg-01.txt and previously draft-ietf-fax-tiff-fx-regbis-04.txt. There, however, appears to be some oversight as draft-ietf-fax-tiff-fx-reg-01.txt was last called at the same time or before these drafts yet it has not received any feedback. This is concerning because tiff-fx-reg and tiff-fx were identified by you and John Klensin as deserving of priority to try and realize a mid-September 02 approval by IESG as Draft Standards. Given that we are approaching mid-June it is now questionable whether end-of-2002 is possible for approval by IESG as Draft Standards. Please comment. Lloyd > -----Original Message----- > From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] > Sent: Sunday, June 09, 2002 1:45 PM > To: ietf-fax@imc.org; dcrocker@brandenburg.com; > ktoyoda@rdmg.mgcs.mei.co.jp > Cc: ned.freed@mrochek.com; paf@cisco.com > Subject: AD review comments on draft-ietf-fax-esmtp-conneg-01.txt > > > > Let's start with an obvious document issue, easily fixed: The IANA > considerations section. It currently says "This memo is not > intended to create > any new issues for IANA." However, the document's primary > goal is to define an > ESMTP extension, and registration of ESMTP extensions is an > IANA activity. As > such, I suggest this section be changed to read "On > publicatioj of this > document by the RFC Editor the IANA shall register the > Content_Negotiation > ESMTP extension defined in section 2." > > Another minor document issue is that the RFC Editor has a new > policy that > references must be separated into normative and informative > groups. In this > case I think there is effectively no separation: All three of > the references > here appear normative to me. So the thing to do is change the > title of section > 9 to "NORMATIVE REFERENCES". > > Another document issue is that this document begins with a > SUMMARY but has no > ABSTRACT or INTRODUCTION. The RFC Editor wants to see a > separate ABSTRACT and > INTRODUCTION section in all new RFCs. I would suggest keeping > the current > SUMMARY as the ABSTRACT and writing a new INTRODUCTION, > reiterating the > ABSTRACT but adding some additional background information if > possible. > > On to security considerations. What's there seems entirely > appropriate. > However, there's are two other security considerations I > believe deserve > mention: The possibility that a vulnerability will be disclosed by the > mechanism and the possibility of tampering with the result > the mechanism > returns. > > The first specific case that concerns me is that of a > capability that is > typically handled by, say, a plugin that has been found to > contain a security > vulnerability. Disclosure of support for this capability > becomes tantamount to > disclosing a vulnerability. > > The second case is one where a man in the middle changes the > capabilities > associated with a given recipient. Here's a somewhat fanciful > example: Suppose > the sender knows the recipient has the ability to view color > documents so they > mark some things in red in what is otherwise a black and > white document. But > someone interferes with the returned capabilities, making them say the > recipient only supports black and white. The document is duly > downgraded, with > the result that the recipient doesn't see what the sender > marked. (Of course > the man in the middle could have tampered with the document > itself, but > modifying a document on the fly is a much more difficult proposition.) > > I'm not suggesting that this facility be changed to address > these issues, > merely that they be mentioned in the security considerations section. > > Next up is failure modes. The model defined here seems simple > enough: Client > asks server for capabilities for a given recipient and the > server either > returns those capabilities or fails with a CONNEG-specific error code. > > I wonder, however, if this isn't too simple. A server may > have no trouble > delivering mail to a given recipient but might be unable to > return that > recipient's capabilities. And this could be either a > temporary or permanent > failure: The directory containing this information could be > offline, or it > could be the case that this information simply isn't > available for this > particular recipient. > > Of course a client that receives a 504 can always retry the > recipient without > the CONNEG parameter if it is willing to operate in the > absence of capability > information. But it may want to take different actions > depending on whether the > failure is temporary or permanent: I could easily see sending > some sort of > default for a permanent failure while waiting to retry in the > even of a > temporary failure. > > I therefore suggest that an additional 404 status code be > defined that can be > returned when the server experiences a temporary failure > getting capability > information. > > The unconditional use of a failure code when capabilities > aren't available also > concerns me. While it is true the client can simply reissue > the RCPT TO without > the CONNEG parameter, handling this case effectively stalls > the SMTP dialogue. > (That is, the client has to wait for the response to the RCPT > TO before it > knows how to proceed.) And dialogue stalls are a significant > operational issue > in practice. I therefore suggest that the mechanism be > changed to allow a > CONNEG parameter value. The value would be, say, either > REQUIRED or OPTIONAL. > The REQUIRED value would result in the same behavior > currently described in the > document. The OPTIONAL case, however, would instruct the > server to proceed > normally and return a _success_ status when the capabilities > aren't available. > A corresponding 2xx code would need to be defined for this case. > > This document also fails to specify what enhanced status code > should be > returned in the event the server is unable to return > capabilities information. > Looking at the list in RFC 1893 I'd say one possibility is > x.3.3, system not > capable of selected feature. I also note in passing that > there are no examples > of CONNEG failures in the examples section. Some examples of > this sort need to > be added. > > Another interesting case that could arise in practice is > where a server is > configured to require authentication, integrity, or privacy > services before > capability information can be returned. I think the document > needs to discuss > this case, saying that if such requirements have not been met > the CONNEG > extension should not be offered in the EHLO response. (Note > that successful > security negotiation already involves repeating EHLO.) > > Although several examples of returned capabilities are shown, > the document > isn't very specific about how capabilities have to be > formatted. In particular, > I'd expect to see capabilities often stored as a single > string without any line > breaks. Some advice on how to take such a string and format > it for inclusion in > the reponse seems warranted. > > According to this document the only capabilities that can be > returned are those > defined in RFC 2879, which is FAX-specific. I realize this > document is a > product of the FAX WG, but is this really appropriate? Should > more general > capabilites return be allowed? And if not, shouldn't this > extension be called > FAXCONNEG or something similar? > > Finally, this document makes passing reference to "use in > relay scenarios". I > think some elaboration of this might be in order. In > particular, I see at least > two scenarios that involve relaying: One where a server knows it will > subsequently relay the message but offers up capability > information by proxy, > and another where the client is an intermediary service with message > downgrading capabilities. > > That's it! > > Ned > From owner-ietf-fax@mail.imc.org Mon Jun 10 13:58:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16452 for ; Mon, 10 Jun 2002 13:58:19 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5AHj3f21222 for ietf-fax-bks; Mon, 10 Jun 2002 10:45:03 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AHj2n21217 for ; Mon, 10 Jun 2002 10:45:02 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KIQNCMHO400000F4@mauve.mrochek.com> for ietf-fax@imc.org; Mon, 10 Jun 2002 10:45:03 -0700 (PDT) Date: Mon, 10 Jun 2002 10:43:18 -0700 (PDT) From: ned.freed@mrochek.com Subject: RE: AD review comments on draft-ietf-fax-esmtp-conneg-01.txt In-reply-to: "Your message dated Mon, 10 Jun 2002 10:26:05 -0700" <51B8ABCE456FD111899900805F6FD6EE0D912A50@mercury.ADOC.xerox.com> To: "McIntyre, Lloyd" Cc: "'ned.freed@mrochek.com'" , ietf-fax@imc.org Message-id: <01KIRH2J32LS0000F4@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <51B8ABCE456FD111899900805F6FD6EE0D912A50@mercury.ADOC.xerox.com> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Thank you for your attention and feedback on > draft-ietf-fax-esmtp-conneg-01.txt and previously > draft-ietf-fax-tiff-fx-regbis-04.txt. There, however, appears to be some > oversight as draft-ietf-fax-tiff-fx-reg-01.txt was last called at the same > time or before these drafts yet it has not received any feedback. That's because there was no feedback to give. This document is still on the IESG's plate. Ned From owner-ietf-fax@mail.imc.org Mon Jun 10 17:43:15 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26919 for ; Mon, 10 Jun 2002 17:43:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5ALQcI09715 for ietf-fax-bks; Mon, 10 Jun 2002 14:26:38 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ALQan09699 for ; Mon, 10 Jun 2002 14:26:37 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26260; Mon, 10 Jun 2002 17:26:05 -0400 (EDT) Message-Id: <200206102126.RAA26260@ietf.org> To: IETF-Announce: ; Cc: ietf-fax@imc.org From: The IESG SUBJECT: Last Call: Guideline of optional services for Internet FAX Gateway to Informational Reply-to: iesg@ietf.org Date: Mon, 10 Jun 2002 17:26:05 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Internet Fax Working Group to consider Guideline of optional services for Internet FAX Gateway as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 24, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-options-05.txt From owner-ietf-fax@mail.imc.org Tue Jun 11 11:59:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00357 for ; Tue, 11 Jun 2002 11:59:55 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5BFgLa12202 for ietf-fax-bks; Tue, 11 Jun 2002 08:42:21 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BFgKn12197 for ; Tue, 11 Jun 2002 08:42:20 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29585; Tue, 11 Jun 2002 11:41:42 -0400 (EDT) Message-Id: <200206111541.LAA29585@ietf.org> To: IETF-Announce: ; Cc: ietf-fax@imc.org From: The IESG SUBJECT: Last Call: A Simple Mode of Facsimile Using Internet Mail to Draft Standard Reply-to: iesg@ietf.org Date: Tue, 11 Jun 2002 11:41:42 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Internet Fax Working Group to consider A Simple Mode of Facsimile Using Internet Mail as a Draft Standard. This document will obsolete RFC2305, currently a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 24, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fax-service-v2-05.txt Implementation Report is available at: http://www.ietf.org/IESG/Implementations/RFC2305-Implementation.txt From owner-ietf-fax@mail.imc.org Tue Jun 11 16:35:31 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11840 for ; Tue, 11 Jun 2002 16:35:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5BKKVG25123 for ietf-fax-bks; Tue, 11 Jun 2002 13:20:31 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BKKUn25119 for ; Tue, 11 Jun 2002 13:20:30 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10798; Tue, 11 Jun 2002 16:19:56 -0400 (EDT) Message-Id: <200206112019.QAA10798@ietf.org> To: IETF-Announce: ; Cc: ietf-fax@imc.org From: The IESG SUBJECT: Last Call: Internet FAX Gateway Functions to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 11 Jun 2002 16:19:56 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Internet Fax Working Group to consider Internet FAX Gateway Functions as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 24, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-protocol-08.txt From owner-ietf-fax@mail.imc.org Thu Jun 13 17:21:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00522 for ; Thu, 13 Jun 2002 17:21:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DL6Ug09808 for ietf-fax-bks; Thu, 13 Jun 2002 14:06:30 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DL6Sn09801 for ; Thu, 13 Jun 2002 14:06:29 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00027; Thu, 13 Jun 2002 17:05:54 -0400 (EDT) Message-Id: <200206132105.RAA00027@ietf.org> To: IETF-Announce: ; Cc: ietf-fax@imc.org From: The IESG SUBJECT: Last Call: Internet FAX Gateway Functions to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 13 Jun 2002 17:05:54 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Internet Fax Working Group to consider Internet FAX Gateway Functions as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 24, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-protocol-08.txt From owner-ietf-fax@mail.imc.org Fri Jun 14 01:50:14 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12341 for ; Fri, 14 Jun 2002 01:50:14 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5E5Wb920416 for ietf-fax-bks; Thu, 13 Jun 2002 22:32:37 -0700 (PDT) Received: from mail6.triad.rr.com (fe6.southeast.rr.com [24.93.67.53]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5E5Wan20412 for ; Thu, 13 Jun 2002 22:32:36 -0700 (PDT) Received: from mail pickup service by mail6.triad.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 00:58:37 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.triad.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 17:42:55 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5ALgtIa026562; Mon, 10 Jun 2002 17:42:55 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id RAA08358 for ietf-123-outbound.05@ietf.org; Mon, 10 Jun 2002 17:35:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id RAA08283 for ; Mon, 10 Jun 2002 17:26:38 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26260; Mon, 10 Jun 2002 17:26:05 -0400 (EDT) Message-Id: <200206102126.RAA26260@ietf.org> To: IETF-Announce: ; Cc: ietf-fax@imc.org From: The IESG SUBJECT: Last Call: Guideline of optional services for Internet FAX Gateway to Informational Reply-to: iesg@ietf.org Date: Mon, 10 Jun 2002 17:26:05 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Internet Fax Working Group to consider Guideline of optional services for Internet FAX Gateway as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 24, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-options-05.txt From owner-ietf-fax@mail.imc.org Fri Jun 14 04:17:20 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22851 for ; Fri, 14 Jun 2002 04:17:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5E83NW08379 for ietf-fax-bks; Fri, 14 Jun 2002 01:03:23 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5E83Ln08375 for ; Fri, 14 Jun 2002 01:03:21 -0700 (PDT) Received: by bulls.mei.co.jp (8.12.2/3.7W/kings) with ESMTP id g5E82tAp028272; Fri, 14 Jun 2002 17:02:55 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/bluejays) with SMTP id g5E82td13281; Fri, 14 Jun 2002 17:02:55 +0900 (JST) Received: from no.name.available by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 14 Jun 2002 08:02:55 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0-1.mgcs.mei.co.jp (8.12.2/3.7W-HUB) with ESMTP id g5E80Cxh011394; Fri, 14 Jun 2002 17:00:12 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id RAA12705; Fri, 14 Jun 2002 17:02:55 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.12.2/3.7W-RDMG) with SMTP id g5E82IlI010953; Fri, 14 Jun 2002 17:02:18 +0900 (JST) Message-Id: <200206140810.AA01361@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Fri, 14 Jun 2002 17:10:18 +0900 To: ned.freed@mrochek.com Cc: dcrocker@brandenburg.com, ietf-fax@imc.org, paf@cisco.com Subject: Revised draft -02 according to AD review comments on draft-ietf-fax-esmtp-conneg-01.txt MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.12 Content-Type: multipart/mixed; boundary="--------------------8325246997229265" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is multipart message. ----------------------8325246997229265 Content-Type: text/plain; charset=us-ascii Freed-san, Dave-san and I revised a ESMTP-CONNEG draft according to your suggestion. I comment in the following text and attach the revised draft. Would you comment and suggest us? ned.freed@mrochek.com wrote: >Let's start with an obvious document issue, easily fixed: The IANA >considerations section. It currently says "This memo is not intended to create >any new issues for IANA." However, the document's primary goal is to define an >ESMTP extension, and registration of ESMTP extensions is an IANA activity. As >such, I suggest this section be changed to read "On publicatioj of this >document by the RFC Editor the IANA shall register the Content_Negotiation >ESMTP extension defined in section 2." We changed this section according to the suggestion above . > >Another minor document issue is that the RFC Editor has a new policy that >references must be separated into normative and informative groups. In this >case I think there is effectively no separation: All three of the references >here appear normative to me. So the thing to do is change the title of section >9 to "NORMATIVE REFERENCES". We changed the title of this section according to the suggestion above . > >Another document issue is that this document begins with a SUMMARY but has no >ABSTRACT or INTRODUCTION. The RFC Editor wants to see a separate ABSTRACT and >INTRODUCTION section in all new RFCs. I would suggest keeping the current >SUMMARY as the ABSTRACT and writing a new INTRODUCTION, reiterating the >ABSTRACT but adding some additional background information if possible. We kept SUMMARY as the ABSTRACT and wrote a new INTRODUCTION. > >On to security considerations. What's there seems entirely appropriate. >However, there's are two other security considerations I believe deserve >mention: The possibility that a vulnerability will be disclosed by the >mechanism and the possibility of tampering with the result the mechanism >returns. > >The first specific case that concerns me is that of a capability that is >typically handled by, say, a plugin that has been found to contain a security >vulnerability. Disclosure of support for this capability becomes tantamount to >disclosing a vulnerability. We added some text for this section. > >The second case is one where a man in the middle changes the capabilities >associated with a given recipient. Here's a somewhat fanciful example: Suppose >the sender knows the recipient has the ability to view color documents so they >mark some things in red in what is otherwise a black and white document. But >someone interferes with the returned capabilities, making them say the >recipient only supports black and white. The document is duly downgraded, with >the result that the recipient doesn't see what the sender marked. (Of course >the man in the middle could have tampered with the document itself, but >modifying a document on the fly is a much more difficult proposition.) We added the paragraph above into the security considerations section. > >I'm not suggesting that this facility be changed to address these issues, >merely that they be mentioned in the security considerations section. > >Next up is failure modes. The model defined here seems simple enough: Client >asks server for capabilities for a given recipient and the server either >returns those capabilities or fails with a CONNEG-specific error code. > >I wonder, however, if this isn't too simple. A server may have no trouble >delivering mail to a given recipient but might be unable to return that >recipient's capabilities. And this could be either a temporary or permanent >failure: The directory containing this information could be offline, or it >could be the case that this information simply isn't available for this >particular recipient. > >Of course a client that receives a 504 can always retry the recipient without >the CONNEG parameter if it is willing to operate in the absence of capability >information. But it may want to take different actions depending on whether the >failure is temporary or permanent: I could easily see sending some sort of >default for a permanent failure while waiting to retry in the even of a >temporary failure. > >I therefore suggest that an additional 404 status code be defined that can be >returned when the server experiences a temporary failure getting capability >information. We defined 404 status code in the first paragraph of chapter 4.3. > >The unconditional use of a failure code when capabilities aren't available also >concerns me. While it is true the client can simply reissue the RCPT TO without >the CONNEG parameter, handling this case effectively stalls the SMTP dialogue. >(That is, the client has to wait for the response to the RCPT TO before it >knows how to proceed.) And dialogue stalls are a significant operational issue >in practice. I therefore suggest that the mechanism be changed to allow a >CONNEG parameter value. The value would be, say, either REQUIRED or OPTIONAL. >The REQUIRED value would result in the same behavior currently described in the >document. The OPTIONAL case, however, would instruct the server to proceed >normally and return a _success_ status when the capabilities aren't available. >A corresponding 2xx code would need to be defined for this case. We defined "REQUIRED" and "OPTIONAL" as the parameter value in chapter 4.1. In the case of "OPTIONAL", I defined the target action as below. This is the third paragraph in chapter 4.3. If the client specifies "CONNEG = OPTIONAL" in the RCPT-TO, the target MUST process the address and message as if the requested CONNEG capabilities had not been specified. > >This document also fails to specify what enhanced status code should be >returned in the event the server is unable to return capabilities information. >Looking at the list in RFC 1893 I'd say one possibility is x.3.3, system not >capable of selected feature. I also note in passing that there are no examples >of CONNEG failures in the examples section. Some examples of this sort need to >be added. We defined enhanced status code in the case of false return to RCPT-TO CONNEG. The paragrapg below is the fifth one in chapter 4.3. If the SMTP server supports ENHANCEDSTATUSCODES, the response strings for a success are "250-2.1.5 CONNEG" and "250 2.1.5 CONNEG". The response strings for indicating a permanent failure are "504-5.3.3 CONNEG" and "504 5.3.3 CONNEG". The response strings for a temporary failure are "404-4.3.3 CONNEG" and "404 5.3.3 CONNEG". And some examples of CONNEG failure are added to chapter 6. > >Another interesting case that could arise in practice is where a server is >configured to require authentication, integrity, or privacy services before >capability information can be returned. I think the document needs to discuss >this case, saying that if such requirements have not been met the CONNEG >extension should not be offered in the EHLO response. (Note that successful >security negotiation already involves repeating EHLO.) We added the paragraph above into the security considerations section. > >Although several examples of returned capabilities are shown, the document >isn't very specific about how capabilities have to be formatted. In particular, >I'd expect to see capabilities often stored as a single string without any line >breaks. Some advice on how to take such a string and format it for inclusion in >the reponse seems warranted. We defined how capabilities have to be formatted in the sixth paragraph of chapter 4.3. Line breaks should not been inserted if CONNEGFAX lines is less than 512. I changed the sample according this rule. > >According to this document the only capabilities that can be returned are those >defined in RFC 2879, which is FAX-specific. I realize this document is a >product of the FAX WG, but is this really appropriate? Should more general >capabilites return be allowed? And if not, shouldn't this extension be called >FAXCONNEG or something similar? We believe that the mechanisms is quite general and that we should encourage its use for more than facscimile over the Internet. So we changed the requirement in section 4 for more general use of SMTP CONNEG as below. The contents of the capability listing MUST conform to [RFC2506], [RFC2533] and [RFC2534], and MAY be used to emulate services, such as the facsimile start-of-session capabilities negotiation as described in "Content Feature Schema for Internet Fax". [RFC2879] > >Finally, this document makes passing reference to "use in relay scenarios". I >think some elaboration of this might be in order. In particular, I see at least >two scenarios that involve relaying: One where a server knows it will >subsequently relay the message but offers up capability information by proxy, >and another where the client is an intermediary service with message >downgrading capabilities. We've added a small amount of text to the last sentence in the abstract and the last sentence in section 1. The text describes "direct" use. This should make the idea of relaying work as an extension to direct exchange. We believe that the document does not need more about "use in relay scenarios". Best regards, Kiyoshi Toyoda ----------------------8325246997229265 Content-Type: application/octet-stream; name="draft-ietf-fax-esmtp-conneg-02.txt" Content-Disposition: attachment; filename="draft-ietf-fax-esmtp-conneg-02.txt" Content-Transfer-Encoding: base64 DQoNCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgIEsuIFRv eW9kYSwgTUdDUw0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAgIEQuIENy b2NrZXIsIEJyYW5kZW5idXJnDQogIERSQUZULUlFVEYtRkFYLUVTTVRQLUNPTk5FRy0wMi5U WFQgICAgICAgICAgIEp1bmUgICAgIDIwMDINCkV4cGlyZXM6IERlY2VtYmVyIDIwMDINCg0K DQoNCiAgICAgICAgICAgICAgICAgICBTTVRQIFNlcnZpY2UgRXh0ZW5zaW9uDQogICAgICAg ICAgIGZvciBDb250ZW50IE5lZ290aWF0aW9uIG9mIEludGVybmV0IEZheA0KICAgICANCiAg ICAgDQogICAgIA0KICAgICBTVEFUVVMgT0YgVEhJUyBNRU1PDQogICAgIA0KICAgICBUaGlz IGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBpbiBmdWxsDQogICAgIGNv bmZvcm1hbmNlIHdpdGggYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZg0KICAgICBS RkMyMDI2LiBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZQ0K ICAgICBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFz LCBhbmQNCiAgICAgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0IG90aGVyIGdyb3Vw cyBtYXkgYWxzbw0KICAgICBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVy bmV0LURyYWZ0cy4NCiAgICAgDQogICAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9j dW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0NCiAgICAgb2Ygc2l4IG1vbnRocyBhbmQgbWF5 IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvcg0KICAgICBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9j dW1lbnRzIGF0IGFueSB0aW1lLiAgSXQgaXMNCiAgICAgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbg0KICAgICBwcm9ncmVzcy4iDQogICAgIA0K ICAgICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNz ZWQgYXQNCiAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0 cy50eHQNCiAgICAgDQogICAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBE aXJlY3RvcmllcyBjYW4gYmUNCiAgICAgYWNjZXNzZWQgYXQNCiAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KICAgICANCiAgICAgQ09QWVJJR0hUIE5PVElD RQ0KICAgICANCiAgICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAw MSkuICBBbGwgUmlnaHRzDQogICAgIFJlc2VydmVkLg0KICAgICANCiAgICAgQUJTVFJBQ1QN CiAgICAgDQogICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIGNvbnRlbnQgbmVnb3RpYXRp b24gU01UUA0KICAgICBzZXJ2aWNlIGV4dGVuc2lvbiBbRVNNVFAxLCBFU01UUDJdIHdoZXJl YnkgYW4gU01UUA0KICAgICBjbGllbnQgbWF5IHJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQg Y29udGVudA0KICAgICBjYXBhYmlsaXRpZXMgb2YgdGhlIHRhcmdldCBkZXZpY2Ugb3Igc3lz dGVtIHRoYXQgaXMNCiAgICAgc2VydmljZWQgYnkgYW4gU01UUCBzZXJ2ZXIuICBUaGUgU01U UCBzZXJ2ZXIgbWF5IHJlcG9ydA0KICAgICB0aGUgdGFyZ2V0J3MgY29udGVudCBjYXBhYmls aXRpZXMgYmFjayB0byB0aGUgY2xpZW50Lg0KICAgICBUaGlzIHByb2Nlc3MgZW11bGF0ZXMg YSBjbGFzc2ljIGZhY3NpbWlsZSBzdGFydC1vZi0NCiAgICAgc2Vzc2lvbiBjYXBhYmlsaXRp ZXMgbmVnb3RpYXRpb24uICBUaGlzIHNlcnZpY2UNCiAgICAgZXh0ZW5zaW9uIGlzIHByaW1h cmlseSBpbnRlbmRlZCBmb3IgImRpcmVjdCIgU01UUA0KICAgICB0cmFuc2ZlcnMsIGFsdGhv dWdoIHJlbGF5ZWQgc2NlbmFyaW9zIGFyZSBwZXJtaXR0ZWQuDQoNCg0KMS4gICBJTlRST0RV Q1RJT04NCiAgICAgICAgVGhlIHZvaWNlIG92ZXIgSVAgaW4gSW50cmFuZXQgb2YgZW50ZXJw cmlzZSBjYW4gY29tbXVuaWNhdGUNCiAgICAgZGlyZWN0cnkgZWFjaCBvdGhlci4gSW50ZXJu ZXQgRmF4IGNhbiBhbHNvIGRpcmVjdHJ5IGNvbW11bmljYXRlIA0KICAgICBlYWNoIG90aGVy IGluIHN1Y2ggYSBuZXR3b3JrIGVudmlyb25tZW50LiBCdXQsIEludGVybmV0IEZheCANCiAg ICAgY2FuIG5vdCBuZWdvdGlhdGUgY2FwYWJpbGl0aWVzIGJlY2F1c2UgdGhlcmUgYXJlIG5v IG1ldGhvZCBpbiANCiAgICAgU01UUCBzZXJ2aWNlIGN1cnJlbnRseS4gDQogICAgICAgICBU aGlzIGRvY3VtZW50IGRlZmluZXMgYSBjb250ZW50IG5lZ290aWF0aW9uIFNNVFANCiAgICAg c2VydmljZSBleHRlbnNpb24gW0VTTVRQMSwgRVNNVFAyXSB3aGVyZWJ5IGFuIFNNVFANCiAg ICAgY2xpZW50IG1heSByZXF1ZXN0IGluZm9ybWF0aW9uIGFib3V0IGNvbnRlbnQNCiAgICAg Y2FwYWJpbGl0aWVzIG9mIHRoZSB0YXJnZXQgZGV2aWNlIG9yIHN5c3RlbSB0aGF0IGlzDQog ICAgIHNlcnZpY2VkIGJ5IGFuIFNNVFAgc2VydmVyLiAgVGhlIFNNVFAgc2VydmVyIG1heSBy ZXBvcnQNCiAgICAgdGhlIHRhcmdldCdzIGNvbnRlbnQgY2FwYWJpbGl0aWVzIGJhY2sgdG8g dGhlIGNsaWVudC4NCiAgICAgVGhpcyBwcm9jZXNzIGVtdWxhdGVzIGEgY2xhc3NpYyBmYWNz aW1pbGUgc3RhcnQtb2YtDQogICAgIHNlc3Npb24gY2FwYWJpbGl0aWVzIG5lZ290aWF0aW9u LiAgVGhpcyBzZXJ2aWNlDQogICAgIGV4dGVuc2lvbiBpcyBwcmltYXJpbHkgaW50ZW5kZWQg Zm9yICJkaXJlY3QiIFNNVFANCiAgICAgdHJhbnNmZXJzLCBhbHRob3VnaCByZWxheWVkIHNj ZW5hcmlvcyBhcmUgcGVybWl0dGVkLg0KDQoNCjIuICAgQ09OVkVOVElPTlMNCiAgICAgDQog ICAgIEluIGV4YW1wbGVzLCAiQzoiIGFuZCAiUzoiIGluZGljYXRlIGxpbmVzIHNlbnQgYnkg dGhlDQogICAgIGNsaWVudCBhbmQgc2VydmVyIHJlc3BlY3RpdmVseS4NCiAgICAgDQogICAg IFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRA0K ICAgICBOT1QiLCBhbmQgIk1BWSIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJw cmV0ZWQNCiAgICAgYXMgZGVmaW5lZCBpbiAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0 byBJbmRpY2F0ZQ0KICAgICBSZXF1aXJlbWVudCBMZXZlbHMiIFtLRVlXT1JEU10uDQoNCg0K DQozLiAgIENPTlRFTlQgTkVHT1RJQVRJT04gU0VSVklDRSBFWFRFTlNJT04NCiAgICAgDQog ICAgICgxKSAgVGhlIG5hbWUgb2YgdGhlIFNNVFAgc2VydmljZSBleHRlbnNpb24gaXMNCiAg ICAgICAgICAiRmF4X2NvbnRlbnRfTmVnb3RpYXRpb24iDQoNCiAgICAgKDIpICBUaGUgRUhM TyBrZXl3b3JkIHZhbHVlIGFzc29jaWF0ZWQgd2l0aCB0aGlzIGV4dGVuc2lvbg0KICAgICAg ICAgIGlzICJGQVhDT05ORUciDQoNCiAgICAgKDMpICBBIHBhcmFtZXRlciB1c2luZyB0aGUg a2V5d29yZCAiRkFYQ09OTkVHIiBpcyBhZGRlZCB0byB0aGUNCiAgICAgICAgICBSQ1BULVRP IGNvbW1hbmQNCg0KICAgICAoNCkgIFRoZSBzZXJ2ZXIgcmVzcG9uZHMgd2l0aCBhIHJlcG9y dCBvZiB0aGUgY29udGVudA0KICAgICAgICAgIGNhcGFiaWxpdGllcyBvZiB0aGUgZGV2aWNl IG9yIHN5c3RlbSB0aGF0IGVtYm9kaWVzIHRoZQ0KICAgICAgICAgIHRhcmdldCBSQ1BULVRP IGFkZHJlc3MuDQoNCg0KDQo0LiAgIEZBWENPTk5FRyBQQVJBTUVURVIgVE8gUkNQVC1UTw0K ICAgICANCjQuMSAgUGFyYW1ldGVyDQoNCiAgICAgS2V5d29yZDoNCiAgICAgICAgICANCiAg ICAgICAgICBGQVhDT05ORUcNCiAgICAgDQogICAgIEFyZ3VtZW50Og0KICAgICAgICAgIA0K ICAgICAgICAgIFJFUVVJUkVEDQogICAgICAgICAgICBUaGUgY2xpZW50IG5lZWQgdGhlIGNh cGFiaWxpdHkuIA0KICAgICAgICAgICAgdGhlIHRhcmdldCBkb2VzIG5vdCBzdXBwb3J0IHRo ZSBGQVhDT05ORUcgcGFyYW1ldGVyLCB0aGUNCiAgICAgICAgICAgIHRhcmdldCBNVVNUIHJl amVjdCB0aGUgUkNQVC1UTyBjb21tYW5kIHdpdGggYSA1MDQgcmVwbHkuDQoNCiAgICAgICAg ICAgIElmIHRoZSB0YXJnZXQgY2FuIG5vdCByZXR1cm4gdGhlIGNhcGFiaWxpdHkgYnkgdGVt cG9yYXJ5DQogICAgICAgICAgICBmYWlsdXJlLCBpdCBNVVNUIHJlamVjdCB0aGUgUkNQVC1U TyBjb21tYW5kIHdpdGggYSA0MDQgDQogICAgICAgICAgICByZXBseS4gDQoNCiAgICAgICAg ICBPUFRJT05BTA0KICAgICAgICAgICAgVGhlIGNsaWVudCB3b3VsZCBsaWtlIHRvIGdldCB0 aGUgY2FwYWJpbGl0eS4gDQogICAgICAgICAgICBJZiB0aGUgdGFyZ2V0IGNhbiBub3QgcmV0 dXJuIHRoZSBjYXBhYmlsaXR5IGJ5IHRlbXBvcmFyeSANCiAgICAgICAgICAgIG9yIHBhcm1h bmVudCBmYWlsdXJlLCB0aGUgdGFyZ2V0IE1VU1QgcmV0dXJuIDI1MCBjb2RlIA0KICAgICAg ICAgICAgd3RpdGhvdXQgRkFYQ09OTkVHIGNhcGFiaWxpdGllcy4NCiAgICAgICAgICAgIA0K ICAgICAgICAgIElmIHRoZSBhcmd1bWVudCBkb2VzIG5vdCBleGlzdCwgdGhlIGRlZmF1bHQg aXMgIlJFUVVJUkVEIi4NCg0KICAgICAgICAgICAgDQo0LjIgQ2xpZW50IEFjdGlvbjoNCiAg ICAgICAgICANCiAgICAgICAgICBJZiB0aGUgc2VydmVyIGlzc3VlZCBhIDI1MC1GQVhDT05O RUcsIGFzIHBhcnQgb2YgaXRzDQogICAgIEVITE8gcmVzcG9uc2UgZm9yIHRoZSBjdXJyZW50 IHNlc3Npb24sIHRoZSBjbGllbnQgTUFZDQogICAgIGlzc3VlIHRoZSBGQVhDT05ORUcgcGFy YW1ldGVyIHdpdGggUkNQVC1UTy4NCiAgICAgICAgICANCiAgICAgICAgICBJZiB0aGUgY2xp ZW50IGlzc3VlcyB0aGUgRkFYQ09OTkVHIHBhcmFtZXRlciB3aXRoDQogICAgIFJDUFQtVE8s IHRoZW4gaXQgTVVTVCBob25vciB0aGUgY2FwYWJpbGl0aWVzIHNwZWNpZmllZA0KICAgICBp biB0aGUgRkFYQ09OTkVHIFJDUFQtVE8gcmVwbHksIGFuZCB0cmFuc2Zvcm0gZGF0YSB0aGF0 IGlzDQogICAgIHNlbnQsIHNvIHRoYXQgdGhlIHRhcmdldCBjYW4gYWNjZXB0IHRoZSBkYXRh LiBUaGUNCiAgICAgY2xpZW50IFNIT1VMRCB0cmFuc2Zvcm0gdGhlIGRhdGEgdG8gdGhlICJo aWdoZXN0IiBsZXZlbA0KICAgICBvZiBjYXBhYmlsaXR5IG9mIHRoZSB0YXJnZXQuDQoNCiAg ICAgICAgICBJZiB0aGUgc2VydmVyIHJlamVjdHMgdGhlIFJDUFQtVE8gY29tbWFuZCB3aXRo IGEgNDA0IA0KICAgICByZXBseSwgdGhlIGNsaWVudCBtYXkgcmVpc3N1ZSB0aGUgUkNQVC1U TyB3aXRoIHRoZSBGQVhDT05ORUcgDQogICAgIHBhcmFtZXRlciBhZnRlciBnZXR0aW5nIGEg NDA0IHJlcGx5IGJ5IHRoZSB0YXJnZXQuDQoNCiAgICAgICAgICBJZiB0aGUgc2VydmVyIHJl dHVybnMgMjUwIGNvZGUgd3RpdGhvdXQgRkFYQ09OTkVHIGNhcGFiaWxpdGllcywNCiAgICAg dGhlIGNsaWVudCBNVVNUIHdvcmsgYXMgImEgU2ltcGxlIE1vZGUgb2YgRmFjc2ltaWxlIFVz aW5nIA0KICAgICBJbnRlcm5ldCBNYWlsIiBbUkZDMjMwNV0uDQoNCiAgICAgDQo0LjMgU2Vy dmVyIEFjdGlvbjoNCiAgICAgICAgICANCiAgICAgICAgICBJZiB0aGUgY2xpZW50IHNwZWNp ZmllcyAiRkFYQ09OTkVHID0gUkVRVUlSRUQiIGluIHRoZSBSQ1BULVRPLCANCiAgICAgYnV0 IHRoZSB0YXJnZXQgZG9lcyBub3Qgc3VwcG9ydCB0aGUgRkFYQ09OTkVHIHBhcmFtZXRlciwg dGhlIHRhcmdldA0KICAgICBNVVNUIHJlamVjdCB0aGUgUkNQVC1UTyBjb21tYW5kIHdpdGgg YSA1MDQgcmVwbHkuIElmIHRoZSB0YXJnZXQgDQogICAgc3VwcG9ydCB0aGUgRkFYQ09OTkVH IHBhcmFtZXRlciwgYnV0IGl0IGNhbiBub3QgcmV0dXJuIHRoZSANCiAgICByZWNlaXBpZW50 J3MgY2FwYWJpbGl0eSB0ZW1wb3JhcmlseSwgdGhlIHRhcmdldCBNVVNUIHJlamVjdCB0aGUg DQogICAgUkNQVC1UTyBjb21tYW5kIHdpdGggYSA0MDQgcmVwbHkuIEZvciBleGFtcGxlLCBp ZiB0aGUgdGFyZ2V0IGdldCANCiAgICB0aGUgY2FwYWJpbGl0eSBpbmZvcm1hdGlvbiBmcm9t IGEgZGlyZWN0b3J5LCBidXQgaXRzIGNvbm5lY3Rpb24gDQogICAgaXMgb2ZmbGluZSwgdGhl IHRhcmdldCBNVVNUIHJlamVjdCB0aGUgUkNQVC1UTyBjb21tYW5kIHdpdGggYSANCiAgICA0 MDQgcmVwbHkuIA0KDQogICAgICAgICAgSWYgdGhlIGNsaWVudCBzcGVjaWZpZXMgIkZBWENP Tk5FRyA9IE9QVElPQU5MIiBpbiB0aGUgUkNQVC1UTywNCiAgICB0aGUgdGFyZ2V0IE1VU1Qg cmV0dXJuIDI1MCBjb2RlIHd0aXRob3V0IEZBWENPTk5FRyBjYXBhYmlsaXRpZXMgDQogICAg bmV2ZXJ0aGVsZXNzIHRoZSBmYWlsdXJlIGlzIHRlbXBvcmFyeSBvciBwYXJtYW5lbnQuDQoN CiAgICAgICAgICBSZWdhcmRsZXNzIG9mIHRoZSB2YWx1ZSBvZiBwYXJhbWV0ZXIsIGlmIHRo ZSB0YXJnZXQgZG9lcyANCiAgICAgc3VwcG9ydCB0aGUgRkFYQ09OTkVHIHBhcmFtZXRlciwg dGhlbiBpdCBNVVNUIGlzc3VlIGEgMjUwIHJlcGx5LCANCiAgICAgZm9sbG93ZWQgYnkgaXRz IGNhcGFiaWxpdGllcyBvZiB0aGUgdGFyZ2V0IHRoYXQgaXMgc3BlY2lmaWVkIGJ5IA0KICAg ICB0aGUgUkNQVC1UTyBhZGRyZXNzLiBTdWNjZXNzZnVsIHJlc3BvbnNlcyB0byBGQVhDT05O RUcgUkNQVC1UTyANCiAgICAgcmVxdWVzdHMgd2lsbCBhbHdheXMgYmUgbXVsdGlwbGUgU01U UCBsaW5lcy4gIFRoZSBmaXJzdCBsaW5lIA0KICAgICBpcyB0aGUgbm9ybWFsIFJDUFQtVE8g cmVzcG9uc2UsIGFuZCBzdWJzZXF1ZW50IGxpbmVzIGJlZ2lubmluZyANCiAgICAgd2l0aCB0 aGUgZXhhY3Qgc3RyaW5nICIyNTAtRkFYQ09OTkVHICIgYW5kICIyNTAgRkFYQ09OTkVHICIg YXJlIHRoZSANCiAgICBGQVhDT05ORUcgcmVzcG9uc2VzLiBUaGUgbGFzdCBsaW5lIGJlZ2lu cyB3aXRoICIyNTAgRkFYQ09OTkVHICIuICANCg0KICAgICAgICAgICBpZiB0aGUgU01UUCBz ZXJ2ZXIgc3VwcG9ydHMgRU5IQU5DRURTVEFUVVNDT0RFUywgdGhlIGV4YWN0IA0KICAgICBz dHJpbmdzIG9mIHN1Y2Nlc3NmdWwgcmVzcG9uc2VzIGFyZSAiMjUwLTIuMS41IEZBWENPTk5F RyAiIGFuZCANCiAgICAgIjI1MCAyLjEuNSBGQVhDT05ORUcgIi4gVGhlIGV4YWN0IHN0cmlu Z3Mgb2YgcGFybWFuZW50IGZhaWx1cmUgDQogICAgIHJlc3BvbnNlcyBhcmUgIjUwNC01LjMu MyBGQVhDT05ORUciIGFuZCAiNTA0IDUuMy4zIEZBWENPTk5FRyIuIA0KICAgICBUaGUgZXhh Y3Qgc3RyaW5ncyBvZiB0ZW1wb3JhcnkgZmFpbHVyZSByZXNwb25zZXMgYXJlIA0KICAgICI0 MDQtNC4zLjMgRkFYQ09OTkVHIiBhbmQgIjQwNCA1LjMuMyBGQVhDT05ORUciLg0KDQogICAg ICAgICBBbGwgRkFYQ09OTkVHLWNhcGFibGUgY2xpZW50cyBhbmQgRkFYQ09OTkVHLWNhcGFi bGUgc2VydmVycyBNVVNUDQogICAgIGJlIGFibGUgdG8gc3VjY2Vzc2Z1bGx5IHByb2Nlc3Mg RkFYQ09OTkVHIGxpbmVzIHRoYXQgYXJlIHVwIHRvIDUxMg0KICAgICBjaGFyYWN0ZXJzIGxv bmcsIGFzIHJlcXVpcmVkIGJ5IFJGQzI4MjEuIElmIHRoZSBsZW5ndGggb2YgRkFYQ09OTkVH DQogICAgIGxpbmVzIGlzIGdyZWF0ZXIgdGhhbiA1MTIgY2hhcmFjdGVycywgdGhlIHNlcnZl ciBNVVNUIGluc2VydA0KICAgICBsaW5lIGJyZWFrcyBhbmQgbWFrZSBuZXh0IEZBWENPTk5F RyBsaW5lLiANCiAgICAgICAgICANCiAgICAgICAgICBUaGUgY29udGVudHMgb2YgdGhlIGNh cGFiaWxpdHkgbGlzdGluZyBNVVNUIGNvbmZvcm0gdG8gDQogICAgIHRoZSBzcGVjaWZpY2F0 aW9ucyBpbiAiQ29udGVudCBGZWF0dXJlIFNjaGVtYSBmb3IgSW50ZXJuZXQgRmF4Ii4gDQog ICAgIFtSRkMyODc5XQ0KDQoNCg0KDQo1LiAgIFNZTlRBWA0KICAgICANCiAgICAgQ29tbWFu ZCB3aXRoICJGQVhDT05ORUciOg0KICAgICAgIlJDUFQgVE86IiAoIjxQb3N0bWFzdGVyQCIg ZG9tYWluICI+IiAvICI8UG9zdG1hc3Rlcj4iDQogICAgICAgICAgICAgICAgICAgLyBGb3J3 YXJkLVBhdGgpIChTUCAiRkFYQ09OTkVHID0iICgiUkVRVUlSRUQiIC8NCiAgICAgICAgICAg ICAgICAgIk9QVElPQU5MIikgQ1JMRg0KDQogICAgIFJlcGx5Og0KICAgICAgKCAoIjI1MC0i IENSTEYpICooIjI1MC1GQVhDT05ORUciIGNhcGFiaWxpdHkgQ1JMRikNCiAgICAgICAgKCIy NTAgRkFYQ09OTkVHIiBjYXBhYmlsaXR5IENSTEYpICkvDQogICAgICAoICgiMjUwLTIuMS41 IiBDUkxGKSANCiAgICAgICAgICAqKCIyNTAtMi4xLjUgRkFYQ09OTkVHIiBjYXBhYmlsaXR5 IENSTEYpDQogICAgICAgICAgICgiMjUwIDIuMS41IEZBWENPTk5FRyIgY2FwYWJpbGl0eSBD UkxGKSApLw0KICAgICAgKCI1MDQiIENSTEYpIC8NCiAgICAgICgiNTA0IDUuMy4zIiBDUkxG KSAvDQogICAgICAoIjQwNCIgQ1JMRikgLw0KICAgICAgKCI0MDQgNC4zLjMiIENSTEYpIC8N Cg0KDQogICAgICBjYXBhYmlsaXR5ICA9ICA8PGFzIHBlciBbUkZDMjg3OV0+Pg0KDQoNCg0K Ni4gICBFWEFNUExFDQoNCiAgICAgQW4gZXhhbXBsZSBvZiBFU01UUCBzZXF1ZW5jZSB3aXRo IHN1Y2Nlc2VmdWwgUkNQVC1UTyByZXNwb25zZQ0KDQogICAgIFM6IDIyMCBpZmF4MS5qcCBJ RkFYDQogICAgIA0KICAgICBDOiBFSExPIGlmYXgxLmpwDQogICAgIA0KICAgICBTOiAyNTAt aWZheDEuanANCiAgICAgUzogMjUwLURTTg0KICAgICBTOiAyNTAgRkFYQ09OTkVHDQogICAg IA0KICAgICBDOiBNQUlMIEZST006PE1heUBpZmF4Mi5qcD4NCiAgICAgDQogICAgIFM6IDI1 MCA8TWF5QGlmYXgyLmpwPiBzZW5kZXIgb2sNCiAgICAgDQogICAgIEM6IFJDUFQgVE86PEp1 bmVAaWZheDEuanA+IEZBWENPTk5FRyA9IFJFUVVJUkVEDQogICAgIA0KICAgICBTOiAyNTAt PEp1bmVAaWZheDEuanA+IHJlY2lwaWVudCBvaw0KICAgICBTOiAyNTAgRkFYQ09OTkVHICgm KGltYWdlLWZpbGUtc3RydWN0dXJlPVRJRkYtbWluaW1hbCkNCiAgICAgUzogKE1SQy1tb2Rl PTApKGNvbG9yPUJpbmFyeSkofCgmKGRwaT0yMDQpDQogICAgIFM6IChkcGkteHlyYXRpbz1b MjA0Lzk4LDIwNC8xOTZdKSApKCYoZHBpPTIwMCkNCiAgICAgUzogKGRwaS14eXJhdGlvPVsy MDAvMTAwLDFdKSApKCYoZHBpPTQwMCkNCiAgICAgUzogKGRwaS14eXJhdGlvPTEpICkgKSh8 KGltYWdlLWNvZGluZz1bTUgsTVIsTU1SXSkNCiAgICAgUzogKCYoaW1hZ2UtY29kaW5nPUpC SUcpKGltYWdlLWNvZGluZy1jb25zdHJhaW50PUpCSUctVDg1KQ0KICAgICBTOiAoSkJJRy1z dHJpcGUtc2l6ZT0xMjgpICkgKShwYXBlci1zaXplPVtsZXR0ZXIsQTQsQjRdKQ0KICAgICBT OiAodWEtbWVkaWE9c3RhdGlvbmVyeSkgKQ0KICAgICANCiAgICAgQzogREFUQQ0KICAgICAN CiAgICAgUzogMzU0IG9rYXksIHNlbmQgZGF0YQ0KICAgICANCiAgICAgQzogPDxSRkMgMjgy MiBtZXNzYWdlIHdpdGggTUlNRSBDb250ZW50LVR5cGU6VElGRi1GWA0KICAgICAgICAgIFBl cjoNCiAgICAgICAgICAoICBpbWFnZS1maWxlLXN0cnVjdHVyZT1USUZGLW1pbmltYWwNCiAg ICAgICAgICAgICBkcGk9NDAwDQogICAgICAgICAgICAgaW1hZ2UtY29kaW5nPUpCSUcNCiAg ICAgICAgICAgICBzaXplLXg9MjE1MA0KICAgICAgICAgICApDQogICAgICAgID4+DQogICAg IA0KICAgICBTOiAyNTAgbWVzc2FnZSBhY2NlcHRlZA0KICAgICANCiAgICAgQzogUVVJVA0K ICAgICANCiAgICAgUzogMjIxIGdvb2RieWUNCg0KDQogICAgIEFuIGV4YW1wbGUgb2Ygc3Vj Y2VzZWZ1bCBSQ1BULVRPIHJlc3BvbnNlIHdoZW4gdGhlIGxlbmd0aCBvZiANCiAgICAgY2Fw YWJpbGl0eSBpcyBncmVhdGVyIHRoYW4gNTEyIGNoYXJhY3RlcnMuIA0KDQogICAgIFM6IDI1 MC0yLjEuNTxKdW5lQGlmYXgxLmpwPiByZWNpcGllbnQgb2sNCiAgICAgUzogMjUwLTIuMS41 IEZBWENPTk5FRyAoJihpbWFnZS1maWxlLXN0cnVjdHVyZT1USUZGLW1pbmltYWwpIC4uLg0K ICAgICBTOiAyNTAtMi4xLjUgRkFYQ09OTkVHICAgLi4uLi4NCiAgICAgUzogMjUwIDIuMS41 IEZBWENPTk5FRyAgIChjb2xvcj1CaW5hcnkpDQoNCg0KICAgICBBbiBleGFtcGxlIG9mIHN1 Y2Nlc2VmdWwgUkNQVC1UTyByZXNwb25zZSB3aGVuIEZBWENPTk5FRy1jYXBhYmxlIA0KICAg ICBzZXJ2ZXIgc3VwcG9ydHMgRU5IQU5DRURTVEFUVVNDT0RFUy4NCg0KICAgICBTOiAyNTAt Mi4xLjU8SnVuZUBpZmF4MS5qcD4gcmVjaXBpZW50IG9rDQogICAgIFM6IDI1MCAyLjEuNSBG QVhDT05ORUcgKCYoaW1hZ2UtZmlsZS1zdHJ1Y3R1cmU9VElGRi1taW5pbWFsKQ0KICAgICBT OiAoTVJDLW1vZGU9MCkoY29sb3I9QmluYXJ5KSh8KCYoZHBpPTIwNCkNCiAgICAgUzogKGRw aS14eXJhdGlvPVsyMDQvOTgsMjA0LzE5Nl0pICkoJihkcGk9MjAwKQ0KICAgICBTOiAoZHBp LXh5cmF0aW89WzIwMC8xMDAsMV0pICkoJihkcGk9NDAwKQ0KICAgICBTOiAoZHBpLXh5cmF0 aW89MSkgKSApKHwoaW1hZ2UtY29kaW5nPVtNSCxNUixNTVJdKQ0KICAgICBTOiAoJihpbWFn ZS1jb2Rpbmc9SkJJRykoaW1hZ2UtY29kaW5nLWNvbnN0cmFpbnQ9SkJJRy1UODUpDQogICAg IFM6IChKQklHLXN0cmlwZS1zaXplPTEyOCkgKSApKHBhcGVyLXNpemU9W2xldHRlcixBNCxC NF0pDQogICAgIFM6ICh1YS1tZWRpYT1zdGF0aW9uZXJ5KSApDQoNCg0KICAgICBBbiBleGFt cGxlIG9mIEVTTVRQIHNlcXVlbmNlIHdpdGggcGFybWFuZW50IGZhaWx1cmUgUkNQVC1UTyAN CiAgICAgcmVzcG9uc2UuIA0KDQogICAgIFM6IDIyMCBpZmF4MS5qcCBJRkFYDQogICAgIA0K ICAgICBDOiBFSExPIGlmYXgxLmpwDQogICAgIA0KICAgICBTOiAyNTAtaWZheDEuanANCiAg ICAgUzogMjUwLURTTg0KICAgICANCiAgICAgQzogTUFJTCBGUk9NOjxNYXlAaWZheDIuanA+ DQogICAgIA0KICAgICBTOiAyNTAgPE1heUBpZmF4Mi5qcD4gc2VuZGVyIG9rDQogICAgIA0K ICAgICBDOiBSQ1BUIFRPOjxKdW5lQGlmYXgxLmpwPiBGQVhDT05ORUcgPSBSRVFVSVJFRA0K ICAgICANCiAgICAgUzogNTA0IDxKdW5lQGlmYXgxLmpwPiByZWNpcGllbnQgb2sNCg0KICAg ICBDOiBRVUlUDQogICAgIA0KICAgICBTOiAyMjEgZ29vZGJ5ZQ0KDQoNCg0KICAgICBBbiBl eGFtcGxlIG9mIEVTTVRQIHNlcXVlbmNlIHdpdGggdGVtcG9yYXJ5IGZhaWx1cmUgUkNQVC1U TyANCiAgICAgcmVzcG9uc2WBQHdoZW4gdGhlIHZhbHVlIG9mIHBhcmFtZXRlciBpcyAiUkVR VUlSRUQiDQoNCiAgICAgUzogMjIwIGlmYXgxLmpwIElGQVgNCiAgICAgDQogICAgIEM6IEVI TE8gaWZheDEuanANCiAgICAgDQogICAgIFM6IDI1MC1pZmF4MS5qcA0KICAgICBTOiAyNTAt RFNODQogICAgIFM6IDI1MCBGQVhDT05ORUcNCiAgICAgDQogICAgIEM6IE1BSUwgRlJPTTo8 TWF5QGlmYXgyLmpwPg0KICAgICANCiAgICAgUzogMjUwIDxNYXlAaWZheDIuanA+IHNlbmRl ciBvaw0KICAgICANCiAgICAgQzogUkNQVCBUTzo8SnVuZUBpZmF4MS5qcD4gRkFYQ09OTkVH ID0gUkVRVUlSRUQNCiAgICAgDQogICAgIFM6IDQwNCA8SnVuZUBpZmF4MS5qcD4gcmVjaXBp ZW50IG9rDQoNCiAgICAgQzogUVVJVA0KICAgICANCiAgICAgUzogMjIxIGdvb2RieWUNCiAg ICAgLg0KICAgICAuDQogICAgIC4NCiAgICAgcmV0cnkgYWNjb3JkaW5nIHRvIGltcGxlbWVu dGF0aW9uDQoNCg0KDQogICAgIEFuIGV4YW1wbGUgb2YgRVNNVFAgc2VxdWVuY2Ugd2l0aCB0 ZW1wb3JhcnkgZmFpbHVyZSBSQ1BULVRPIA0KICAgICByZXNwb25zZSB3aGVuIHRoZSB2YWx1 ZSBvZiBwYXJhbWV0ZXIgaXMgIk9QVElPTkFMIg0KDQogICAgIFM6IDIyMCBpZmF4MS5qcCBJ RkFYDQogICAgIA0KICAgICBDOiBFSExPIGlmYXgxLmpwDQogICAgIA0KICAgICBTOiAyNTAt aWZheDEuanANCiAgICAgUzogMjUwLURTTg0KICAgICBTOiAyNTAgRkFYQ09OTkVHDQogICAg IA0KICAgICBDOiBNQUlMIEZST006PE1heUBpZmF4Mi5qcD4NCiAgICAgDQogICAgIFM6IDI1 MCA8TWF5QGlmYXgyLmpwPiBzZW5kZXIgb2sNCiAgICAgDQogICAgIEM6IFJDUFQgVE86PEp1 bmVAaWZheDEuanA+IEZBWENPTk5FRyA9IE9QVElPTkFMDQogICAgIA0KICAgICBTOiAyNTAg PEp1bmVAaWZheDEuanA+IHJlY2lwaWVudCBvaw0KICAgICANCiAgICAgQzogREFUQQ0KICAg ICANCiAgICAgUzogMzU0IG9rYXksIHNlbmQgZGF0YQ0KICAgICANCiAgICAgQzogPDxSRkMg MjgyMiBtZXNzYWdlIHdpdGggTUlNRSBDb250ZW50LVR5cGU6VElGRi1GWA0KICAgICAgICAg IFBlciAiQSBTaW1wbGUgTW9kZSBvZiBGYWNzaW1pbGUgVXNpbmcgSW50ZXJuZXQgTWFpbCIN CiAgICAgICAgICBSRkMyMzA1DQogICAgICAgID4+DQogICAgIA0KICAgICBTOiAyNTAgbWVz c2FnZSBhY2NlcHRlZA0KICAgICANCiAgICAgQzogUVVJVA0KICAgICANCiAgICAgUzogMjIx IGdvb2RieWUNCg0KDQoNCjcuICAgSUFOQSBDT05TSURFUkFUSU9OUw0KICAgICANCiAgICAg T24gcHVibGljYXRpb2ogb2YgdGhpcyBkb2N1bWVudCBieSB0aGUgUkZDIEVkaXRvciB0aGUg SUFOQSANCiAgICAgc2hhbGwgcmVnaXN0ZXIgdGhlIENvbnRlbnRfTmVnb3RpYXRpb24gRVNN VFAgZXh0ZW5zaW9uIGRlZmluZWQgDQogICAgIGluIHNlY3Rpb24gMy4NCg0KDQo4LiAgIFNF Q1VSSVRZIENPTlNJREVSQVRJT05TDQogICAgIA0KICAgICBUaGlzIEVTTVRQIG9wdGlvbiBj YWxscyBmb3IgYSByZXNwb25kZW50IHRvIGRpc2Nsb3NlDQogICAgIGl0cyBjYXBhYmlsaXRp ZXMuICBNZWNoYW5pc21zIGZvciBkZXRlcm1pbmluZyB0aGUNCiAgICAgcmVxdWVzdG9yJ3Mg YXV0aGVudGljYXRlZCBpZGVudGl0eSBhcmUgb3V0c2lkZSB0aGUNCiAgICAgc2NvcGUgb2Yg dGhpcyBzcGVjaWZpY2F0aW9uLiAgSXQgaXMgaW50ZW5kZWQgdGhhdCB0aGlzDQogICAgIG1l Y2hhbmlzbSBwZXJtaXQgZGlzY2xvc3VyZSBvZiBwdWJsaWMgaW5mb3JtYXRpb247DQogICAg IGhlbmNlIHRoZXJlIGlzIG5vIHBhcnRpY3VsYXIgbmVlZCBmb3Igc2VjdXJpdHkNCiAgICAg bWVhc3VyZXMuDQogICAgIA0KICAgICBIb3dldmVyIHRoZXJlIGlzIG5vdGhpbmcgdG8gcHJl dmVudCBkaXNjbG9zdXJlIG9mDQogICAgIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiB0aGF0IHNo b3VsZCByZWNlaXZlIHJlc3RyaWN0ZWQNCiAgICAgZGlzdHJpYnV0aW9uLiAgSXQgaXMsIHRo ZXJlZm9yZSwgdGhlIHJlc3BvbnNpYmlsaXR5IG9mDQogICAgIHRoZSBkaXNjbG9zaW5nIEVT TVRQIHNlcnZlciB0byBkZXRlcm1pbmUgd2hldGhlcg0KICAgICBhZGRpdGlvbmFsIHNlY3Vy aXR5IG1lYXN1cmVzIHNob3VsZCBiZSBhcHBsaWVkIHRvIHRoZQ0KICAgICB1c2Ugb2YgdGhp cyBFU01UUCBvcHRpb24uDQoNCiAgICAgQSBtYW4gaW4gdGhlIG1pZGRsZSBtaWdodCBjaGFu Z2UgdGhlIGNhcGFiaWxpdGllcyBhc3NvY2lhdGVkIA0KICAgICB3aXRoIGEgZ2l2ZW4gcmVj aXBpZW50LiBIZXJlJ3MgYSBzb21ld2hhdCBleGFtcGxlOiBTdXBwb3NlDQogICAgIHRoZSBz ZW5kZXIga25vd3MgdGhlIHJlY2lwaWVudCBoYXMgdGhlIGFiaWxpdHkgdG8gdmlldyBjb2xv ciANCiAgICAgZG9jdW1lbnRzIHNvIHRoZXkgbWFyayBzb21lIHRoaW5ncyBpbiByZWQgaW4g d2hhdCBpcyBvdGhlcndpc2UgDQogICAgIGEgYmxhY2sgYW5kIHdoaXRlIGRvY3VtZW50LiBC dXQgc29tZW9uZSBpbnRlcmZlcmVzIHdpdGggdGhlIA0KICAgICByZXR1cm5lZCBjYXBhYmls aXRpZXMsIG1ha2luZyB0aGVtIHNheSB0aGUgcmVjaXBpZW50IG9ubHkgDQogICAgIHN1cHBv cnRzIGJsYWNrIGFuZCB3aGl0ZS4gVGhlIGRvY3VtZW50IGlzIGR1bHkgZG93bmdyYWRlZCwg DQogICAgIHdpdGggdGhlIHJlc3VsdCB0aGF0IHRoZSByZWNpcGllbnQgZG9lc24ndCBzZWUg d2hhdCB0aGUgc2VuZGVyIA0KICAgICBtYXJrZWQuIEJ1dCBtb2RpZnlpbmcgYSBkb2N1bWVu dCBvbiB0aGUgZmx5IGlzIGEgbXVjaCBtb3JlIA0KICAgICBkaWZmaWN1bHQgcHJvcG9zaXRp b24uDQoNCg0KDQoNCjkuICAgQUNLTk9XTEVER0VNRU5UUw0KICAgICANCiAgICAgR3JhaGFt IEtseW5lIHByb3ZpZGVkIHVzZWZ1bCBzdWdnZXN0aW9ucyB0byBhbiBlYXJsaWVyDQogICAg IGRyYWZ0Lg0KDQoNCg0KMTAuICAgTk9STUFUSVZFIFJFRkVSRU5DRVMNCiAgICAgDQogICAg IFtFU01UUDFdICBLbGVuc2luLCBKLiwgRnJlZWQsIE4uLCBSb3NlLCBNLiwgU3RlZmZlcnVk LA0KICAgICAgICAgICAgICAgRS4gYW5kIEQuIENyb2NrZXIsICJTTVRQIFNlcnZpY2UgRXh0 ZW5zaW9ucyIsDQogICAgICAgICAgICAgICBSRkMgMTg2OSwgTm92ZW1iZXIgMTk5NQ0KICAg ICANCiAgICAgW0VTTVRQMl0gIEtsZW5zaW4sIEouLCAiU2ltcGxlIE1haWwgVHJhbnNmZXIg UHJvdG9jb2wiLA0KICAgICAgICAgICAgICAgUkZDIDI4MjEsIEFwcmlsIDIwMDEuDQogICAg IA0KICAgICBbUkZDMjg3OV0gTWNJbnR5cmUsIEwuIGFuZCBHLiBLbHluZSwgIkNvbnRlbnQg RmVhdHVyZQ0KICAgICAgICAgICAgICAgU2NoZW1hIGZvciBJbnRlcm5ldCBGYXgiLCBSRkMg MjUzMSwgQXVndXN0DQogICAgICAgICAgICAgICAyMDAwDQoNCiAgICAgW1JGQzIzMDVdIFRv eW9kYSwgSy4sIE9obm8sIEguLCBNdXJhaSwgSi4gYW5kICBELiBXaW5nLCANCiAgICAgICAg ICAgICAgICJBIFNpbXBsZSBNb2RlIG9mIEZhY3NpbWlsZSBVc2luZyBJbnRlcm5ldCBNYWls IiwgDQogICAgICAgICAgICAgIFJGQyAyMzA1LCBNYXJjaCAxOTk4Lg0KDQoNCg0KDQoxMS4g IEFVVEhPUlMnIEFERFJFU1NFUw0KICAgICANCiAgICAgS2l5b3NoaSBUb3lvZGENCiAgICAg TWF0c3VzaGl0YSBHcmFwaGljIENvbW11bmljYXRpb24gU3lzdGVtcyxJbmMNCiAgICAgMi0z LTggU2hpbW9tZWd1cm8sIE1lZ3Vyby1LdQ0KICAgICBUb2t5byAxNTMgIEpBUEFODQogICAg IA0KICAgICArODEuMy41NDM0LjcxNjENCiAgICAga3RveW9kYUByZG1nLm1nY3MubWVpLmNv LmpwDQogICAgIA0KICAgICANCiAgICAgRGF2ZSBDcm9ja2VyDQogICAgIEJyYW5kZW5idXJn IEludGVybmV0V29ya2luZw0KICAgICA2NzUgU3BydWNlIERyaXZlDQogICAgIFN1bm55dmFs ZSwgQ0EgIDk0MDg2ICBVU0ENCiAgICAgDQogICAgICsxLjQwOC4yNDYuODI1Mw0KICAgICBk Y3JvY2tlckBicmFuZGVuYnVyZy5jb20NCg0KDQoNCjEyLiAgICAgICBGVUxMIENPUFlSSUdI VCBTVEFURU1FTlQNCiAgICAgDQogICAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNv Y2lldHkgKDIwMDEpLiAgQWxsIFJpZ2h0cw0KICAgICBSZXNlcnZlZC4NCiAgICAgDQogICAg IFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFu ZA0KICAgICBmdXJuaXNoZWQgdG8gb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0 IGNvbW1lbnQNCiAgICAgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQgb3IgYXNzaXN0IGlu IGl0cw0KICAgICBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGllZCwgcHVi bGlzaGVkIGFuZA0KICAgICBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0 aG91dCByZXN0cmljdGlvbg0KICAgICBvZiBhbnkga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUg YWJvdmUgY29weXJpZ2h0IG5vdGljZQ0KICAgICBhbmQgdGhpcyBwYXJhZ3JhcGggYXJlIGlu Y2x1ZGVkIG9uIGFsbCBzdWNoIGNvcGllcyBhbmQNCiAgICAgZGVyaXZhdGl2ZSB3b3Jrcy4g IEhvd2V2ZXIsIHRoaXMgZG9jdW1lbnQgaXRzZWxmIG1heQ0KICAgICBub3QgYmUgbW9kaWZp ZWQgaW4gYW55IHdheSwgc3VjaCBhcyBieSByZW1vdmluZyB0aGUNCiAgICAgY29weXJpZ2h0 IG5vdGljZSBvciByZWZlcmVuY2VzIHRvIHRoZSBJbnRlcm5ldCBTb2NpZXR5DQogICAgIG9y IG90aGVyIEludGVybmV0IG9yZ2FuaXphdGlvbnMsIGV4Y2VwdCBhcyBuZWVkZWQgZm9yDQog ICAgIHRoZSBwdXJwb3NlIG9mIGRldmVsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdo aWNoDQogICAgIGNhc2UgdGhlIHByb2NlZHVyZXMgZm9yIGNvcHlyaWdodHMgZGVmaW5lZCBp biB0aGUNCiAgICAgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZSBmb2xsb3dl ZCwgb3IgYXMNCiAgICAgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGludG8gbGFuZ3VhZ2Vz IG90aGVyIHRoYW4NCiAgICAgRW5nbGlzaC4NCiAgICAgDQogICAgIFRoZSBsaW1pdGVkIHBl cm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBhbmQNCiAgICAgd2lsbCBu b3QgYmUgcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMNCiAgICAgc3Vj Y2Vzc29ycyBvciBhc3NpZ25zLg0KICAgICANCiAgICAgVGhpcyBkb2N1bWVudCBhbmQgdGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMNCiAgICAgcHJvdmlkZWQgb24gYW4g IkFTIElTIiBiYXNpcyBhbmQgVEhFIElOVEVSTkVUIFNPQ0lFVFkNCiAgICAgQU5EIFRIRSBJ TlRFUk5FVCBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNUyBBTEwNCiAgICAgV0FS UkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVA0KICAgICBM SU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9O DQogICAgIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBM SUVEDQogICAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9S IEENCiAgICAgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCg== ----------------------8325246997229265-- From owner-ietf-fax@mail.imc.org Fri Jun 14 23:09:08 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23079 for ; Fri, 14 Jun 2002 23:09:08 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5F2guf03782 for ietf-fax-bks; Fri, 14 Jun 2002 19:42:56 -0700 (PDT) Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5F2gsn03778 for ; Fri, 14 Jun 2002 19:42:54 -0700 (PDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 22:42:21 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 17:42:55 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5ALgtIa026562; Mon, 10 Jun 2002 17:42:55 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id RAA08358 for ietf-123-outbound.05@ietf.org; Mon, 10 Jun 2002 17:35:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id RAA08283 for ; Mon, 10 Jun 2002 17:26:38 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26260; Mon, 10 Jun 2002 17:26:05 -0400 (EDT) Message-Id: <200206102126.RAA26260@ietf.org> To: IETF-Announce: ; Cc: ietf-fax@imc.org From: The IESG SUBJECT: Last Call: Guideline of optional services for Internet FAX Gateway to Informational Reply-to: iesg@ietf.org Date: Mon, 10 Jun 2002 17:26:05 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Internet Fax Working Group to consider Guideline of optional services for Internet FAX Gateway as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 24, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-options-05.txt From owner-ietf-fax@mail.imc.org Thu Jun 20 00:55:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10972 for ; Thu, 20 Jun 2002 00:55:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5K4ZIQ22064 for ietf-fax-bks; Wed, 19 Jun 2002 21:35:18 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5K4ZGn22057 for ; Wed, 19 Jun 2002 21:35:16 -0700 (PDT) Received: by bulls.mei.co.jp (8.12.2/3.7W/kings) with ESMTP id g5K4YqsZ019823; Thu, 20 Jun 2002 13:34:52 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) with SMTP id g5K4YpZ13347; Thu, 20 Jun 2002 13:34:51 +0900 (JST) Received: from no.name.available by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 20 Jun 2002 04:34:52 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0-1.mgcs.mei.co.jp (8.12.2/3.7W-HUB) with ESMTP id g5K4VwDL022814; Thu, 20 Jun 2002 13:31:58 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id NAA27101; Thu, 20 Jun 2002 13:34:51 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.12.2/3.7W-RDMG) with SMTP id g5K4YClI024652; Thu, 20 Jun 2002 13:34:12 +0900 (JST) Message-Id: <200206200442.AA01385@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Thu, 20 Jun 2002 13:42:23 +0900 To: ned.freed@mrochek.com Cc: dcrocker@brandenburg.com, ietf-fax@imc.org, paf@cisco.com Subject: draft-ietf-fax-esmtp-conneg-02.txt MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.12 Content-Type: multipart/mixed; boundary="--------------------2064483419811763" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is multipart message. ----------------------2064483419811763 Content-Type: text/plain; charset=us-ascii Freed-san, I found that I made a mistake about draft in the e-mail which I sent on 14th June. I attached a premature draft in that e-mail. So, my comments below "--Original Message--" was inconsistent with the attached draft. I am sorry to bother you. Please review the draft which I attached in this e-mail with my comments below. It is the correct one. -----Original Message----- From: "Toyoda, Kiyoshi" To: ned.freed@mrochek.com Cc: dcrocker@brandenburg.com, ietf-fax@imc.org, paf@cisco.com Subject: Revised draft -02 according to AD review comments on draft-ietf-fax-esmtp-conneg-01.txt Date: Fri, 14 Jun 2002 17:10:18 +0900 Freed-san, Dave-san and I revised a ESMTP-CONNEG draft according to your suggestion. I comment in the following text and attach the revised draft. Would you comment and suggest us? ned.freed@mrochek.com wrote: >Let's start with an obvious document issue, easily fixed: The IANA >considerations section. It currently says "This memo is not intended to create >any new issues for IANA." However, the document's primary goal is to define an >ESMTP extension, and registration of ESMTP extensions is an IANA activity. As >such, I suggest this section be changed to read "On publicatioj of this >document by the RFC Editor the IANA shall register the Content_Negotiation >ESMTP extension defined in section 2." We changed this section according to the suggestion above . > >Another minor document issue is that the RFC Editor has a new policy that >references must be separated into normative and informative groups. In this >case I think there is effectively no separation: All three of the references >here appear normative to me. So the thing to do is change the title of section >9 to "NORMATIVE REFERENCES". We changed the title of this section according to the suggestion above . > >Another document issue is that this document begins with a SUMMARY but has no >ABSTRACT or INTRODUCTION. The RFC Editor wants to see a separate ABSTRACT and >INTRODUCTION section in all new RFCs. I would suggest keeping the current >SUMMARY as the ABSTRACT and writing a new INTRODUCTION, reiterating the >ABSTRACT but adding some additional background information if possible. We kept SUMMARY as the ABSTRACT and wrote a new INTRODUCTION. > >On to security considerations. What's there seems entirely appropriate. >However, there's are two other security considerations I believe deserve >mention: The possibility that a vulnerability will be disclosed by the >mechanism and the possibility of tampering with the result the mechanism >returns. > >The first specific case that concerns me is that of a capability that is >typically handled by, say, a plugin that has been found to contain a security >vulnerability. Disclosure of support for this capability becomes tantamount to >disclosing a vulnerability. We added some text for this section. > >The second case is one where a man in the middle changes the capabilities >associated with a given recipient. Here's a somewhat fanciful example: Suppose >the sender knows the recipient has the ability to view color documents so they >mark some things in red in what is otherwise a black and white document. But >someone interferes with the returned capabilities, making them say the >recipient only supports black and white. The document is duly downgraded, with >the result that the recipient doesn't see what the sender marked. (Of course >the man in the middle could have tampered with the document itself, but >modifying a document on the fly is a much more difficult proposition.) We added the paragraph above into the security considerations section. > >I'm not suggesting that this facility be changed to address these issues, >merely that they be mentioned in the security considerations section. > >Next up is failure modes. The model defined here seems simple enough: Client >asks server for capabilities for a given recipient and the server either >returns those capabilities or fails with a CONNEG-specific error code. > >I wonder, however, if this isn't too simple. A server may have no trouble >delivering mail to a given recipient but might be unable to return that >recipient's capabilities. And this could be either a temporary or permanent >failure: The directory containing this information could be offline, or it >could be the case that this information simply isn't available for this >particular recipient. > >Of course a client that receives a 504 can always retry the recipient without >the CONNEG parameter if it is willing to operate in the absence of capability >information. But it may want to take different actions depending on whether the >failure is temporary or permanent: I could easily see sending some sort of >default for a permanent failure while waiting to retry in the even of a >temporary failure. > >I therefore suggest that an additional 404 status code be defined that can be >returned when the server experiences a temporary failure getting capability >information. We defined 404 status code in the first paragraph of chapter 4.3. > >The unconditional use of a failure code when capabilities aren't available also >concerns me. While it is true the client can simply reissue the RCPT TO without >the CONNEG parameter, handling this case effectively stalls the SMTP dialogue. >(That is, the client has to wait for the response to the RCPT TO before it >knows how to proceed.) And dialogue stalls are a significant operational issue >in practice. I therefore suggest that the mechanism be changed to allow a >CONNEG parameter value. The value would be, say, either REQUIRED or OPTIONAL. >The REQUIRED value would result in the same behavior currently described in the >document. The OPTIONAL case, however, would instruct the server to proceed >normally and return a _success_ status when the capabilities aren't available. >A corresponding 2xx code would need to be defined for this case. We defined "REQUIRED" and "OPTIONAL" as the parameter value in chapter 4.1. In the case of "OPTIONAL", I defined the target action as below. This is the third paragraph in chapter 4.3. If the client specifies "CONNEG = OPTIONAL" in the RCPT-TO, the target MUST process the address and message as if the requested CONNEG capabilities had not been specified. > >This document also fails to specify what enhanced status code should be >returned in the event the server is unable to return capabilities information. >Looking at the list in RFC 1893 I'd say one possibility is x.3.3, system not >capable of selected feature. I also note in passing that there are no examples >of CONNEG failures in the examples section. Some examples of this sort need to >be added. We defined enhanced status code in the case of false return to RCPT-TO CONNEG. The paragrapg below is the fifth one in chapter 4.3. If the SMTP server supports ENHANCEDSTATUSCODES, the response strings for a success are "250-2.1.5 CONNEG" and "250 2.1.5 CONNEG". The response strings for indicating a permanent failure are "504-5.3.3 CONNEG" and "504 5.3.3 CONNEG". The response strings for a temporary failure are "404-4.3.3 CONNEG" and "404 5.3.3 CONNEG". And some examples of CONNEG failure are added to chapter 6. > >Another interesting case that could arise in practice is where a server is >configured to require authentication, integrity, or privacy services before >capability information can be returned. I think the document needs to discuss >this case, saying that if such requirements have not been met the CONNEG >extension should not be offered in the EHLO response. (Note that successful >security negotiation already involves repeating EHLO.) We added the paragraph above into the security considerations section. > >Although several examples of returned capabilities are shown, the document >isn't very specific about how capabilities have to be formatted. In particular, >I'd expect to see capabilities often stored as a single string without any line >breaks. Some advice on how to take such a string and format it for inclusion in >the reponse seems warranted. We defined how capabilities have to be formatted in the sixth paragraph of chapter 4.3. Line breaks should not been inserted if CONNEGFAX lines is less than 512. I changed the sample according this rule. > >According to this document the only capabilities that can be returned are those >defined in RFC 2879, which is FAX-specific. I realize this document is a >product of the FAX WG, but is this really appropriate? Should more general >capabilites return be allowed? And if not, shouldn't this extension be called >FAXCONNEG or something similar? We believe that the mechanisms is quite general and that we should encourage its use for more than facscimile over the Internet. So we changed the requirement in section 4 for more general use of SMTP CONNEG as below. The contents of the capability listing MUST conform to [RFC2506], [RFC2533] and [RFC2534], and MAY be used to emulate services, such as the facsimile start-of-session capabilities negotiation as described in "Content Feature Schema for Internet Fax". [RFC2879] > >Finally, this document makes passing reference to "use in relay scenarios". I >think some elaboration of this might be in order. In particular, I see at least >two scenarios that involve relaying: One where a server knows it will >subsequently relay the message but offers up capability information by proxy, >and another where the client is an intermediary service with message >downgrading capabilities. We've added a small amount of text to the last sentence in the abstract and the last sentence in section 1. The text describes "direct" use. This should make the idea of relaying work as an extension to direct exchange. We believe that the document does not need more about "use in relay scenarios". Best regards, Kiyoshi Toyoda ----------------------2064483419811763 Content-Type: application/octet-stream; name="draft-ietf-fax-esmtp-conneg-02.txt" Content-Disposition: attachment; filename="draft-ietf-fax-esmtp-conneg-02.txt" Content-Transfer-Encoding: base64 DQoNCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgIEsuIFRv eW9kYSwgTUdDUw0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAgIEQuIENy b2NrZXIsIEJyYW5kZW5idXJnDQogIERSQUZULUlFVEYtRkFYLUVTTVRQLUNPTk5FRy0wMi5U WFQgICAgICAgICAgIEp1bmUgICAgIDIwMDINCkV4cGlyZXM6IERlY2VtYmVyIDIwMDINCg0K DQoNCiAgICAgICAgICAgICAgICAgICBTTVRQIFNlcnZpY2UgRXh0ZW5zaW9uDQogICAgICAg ICAgICAgICAgICAgZm9yIENvbnRlbnQgTmVnb3RpYXRpb24NCiAgICAgDQogICAgIA0KICAg ICANCiAgICAgU1RBVFVTIE9GIFRISVMgTUVNTw0KICAgICANCiAgICAgVGhpcyBkb2N1bWVu dCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbA0KICAgICBjb25mb3JtYW5j ZSB3aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YNCiAgICAgUkZDMjAyNi4g SW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUNCiAgICAgSW50 ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kDQog ICAgIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFs c28NCiAgICAgZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFm dHMuDQogICAgIA0KICAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2 YWxpZCBmb3IgYSBtYXhpbXVtDQogICAgIG9mIHNpeCBtb250aHMgYW5kIG1heSBiZSB1cGRh dGVkLCByZXBsYWNlZCwgb3INCiAgICAgb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBh dCBhbnkgdGltZS4gIEl0IGlzDQogICAgIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0 LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90 aGVyIHRoYW4gYXMgIndvcmsgaW4NCiAgICAgcHJvZ3Jlc3MuIg0KICAgICANCiAgICAgVGhl IGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQog ICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0DQog ICAgIA0KICAgICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3Jp ZXMgY2FuIGJlDQogICAgIGFjY2Vzc2VkIGF0DQogICAgICAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9zaGFkb3cuaHRtbC4NCiAgICAgDQogICAgIENPUFlSSUdIVCBOT1RJQ0UNCiAgICAg DQogICAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDEpLiAgQWxs IFJpZ2h0cw0KICAgICBSZXNlcnZlZC4NCiAgICAgDQogICAgIEFCU1RSQUNUDQogICAgIA0K ICAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBjb250ZW50IG5lZ290aWF0aW9uIHNlcnZp Y2UNCiAgICAgZXh0ZW5zaW9uIGZvciBTTVRQIFtFU01UUDEsIEVTTVRQMl0gd2hlcmVieSBh biBTTVRQDQogICAgIGNsaWVudCBtYXkgcmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBjb250 ZW50DQogICAgIGNhcGFiaWxpdGllcyBvZiB0aGUgdGFyZ2V0IGRldmljZSBvciBzeXN0ZW0g dGhhdCBpcw0KICAgICBzZXJ2aWNlZCBieSBhbiBTTVRQIHNlcnZlci4gIFRoZSBTTVRQIHNl cnZlciBtYXkgcmVwb3J0DQogICAgIHRoZSB0YXJnZXQncyBjb250ZW50IGNhcGFiaWxpdGll cyBiYWNrIHRvIHRoZSBjbGllbnQuDQogICAgIFRoaXMgcHJvY2VzcyBlbXVsYXRlcyBhIGNs YXNzaWMgZmFjc2ltaWxlIHN0YXJ0LW9mLQ0KICAgICBzZXNzaW9uIGNhcGFiaWxpdGllcyBu ZWdvdGlhdGlvbiwgYWx0aG91Z2ggaXQgY2FuIGJlIHVzZWQgDQogICAgIGZvciBhIGJyb2Fk IHJhbmdlIG9mIGVtYWlsLWJhc2VkIHNjZW5hcmlvcy4gIFRoaXMgc2VydmljZQ0KICAgICBl eHRlbnNpb24gaXMgcHJpbWFyaWx5IGludGVuZGVkIGZvciAiZGlyZWN0Iiwgb25lLWhvcCwN CiAgICAgb3JpZ2luYXRvci9yZWNpcGllbnQgU01UUCB0cmFuc2ZlcnMsIGFsdGhvdWdoIHJl bGF5ZWQgDQogICAgIHNjZW5hcmlvcyB0aHJvdWdoIG11bHRpcGxlIFNNVFAgc2VydmVycyBh cmUgcGVybWl0dGVkLg0KDQoNCjEuICAgSU5UUk9EVUNUSU9ODQoNCiAgICAgV2hlbiBhIGRh dGEgc291cmNlIGFuZCBhIHJlY2VpdmVyIGhhdmUgaW50ZXJhY3RpdmUgYWNjZXNzIHRvIA0K ICAgICBlYWNoIG90aGVyLCB0aGUgcmVjZWl2ZXIgb2Z0ZW4gaW5mb3JtcyB0aGUgc291cmNl IG9mIGl0cyANCiAgICAgY2FwYWJpbGl0aWVzLCB0byBwZXJtaXQgb3B0aW1pemVkIHBlcmZv cm1hbmNlIG9yIGZ1bmN0aW9uYWxpdHkgZm9yIA0KICAgICB0aGUgaW50ZXJhY3Rpb24uICBD bGFzc2ljIHRlbGVwaG9uZS1iYXNlZCBmYWNzaW1pbGUgaXMgYW4gZXhhbXBsZSwgDQogICAg IGFzIGFyZSB2b2ljZSBvdmVyIElQIGFuZCBFU01UUCBhbW9uZyBJbnRlcm5ldCBhcHBsaWNh dGlvbnMuICBUaGUNCiAgICAgc3RvcmUtYW5kLWZvcndhcmQgbmF0dXJlIG9mIEludGVybmV0 IG1haWwgaXMgdXN1YWxseSBhc3N1bWVkIHRvIA0KICAgICBwcmVjbHVkZSBzdWNoIGNhcGFi aWxpdGllcyBleGNoYW5nZXMuICBIb3dldmVyIGRpcmVjdCBlbWFpbC1iYXNlZCANCiAgICAg aW50ZXJhY3Rpb25zIGFyZSBwb3NzaWJsZSB3aXRoIHByb3BlciBjb25maWd1cmF0aW9uIG9m IHRoZSBlbWFpbCANCiAgICAgb3JpZ2luYXRvciBhbmQgcmVjaXBpZW50IHNlcnZlcnMsIHN1 Y2ggYXMgb3ZlciBhbiBpbnRyYW5ldC4gDQogICAgIA0KICAgICBUaGlzIGRvY3VtZW50IGRl ZmluZXMgYW4gU01UUC1iYXNlZCBzZXJ2aWNlIGV4dGVuc2lvbiBbRVNNVFAxLCANCiAgICAg RVNNVFAyXSBmb3IgY29udGVudCBuZWdvdGlhdGlvbiwgd2hlcmVieSBhbiBTTVRQIGNsaWVu dCBtYXkgDQogICAgIHJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgY29udGVudCBjYXBhYmls aXRpZXMgb2YgdGhlIHRhcmdldCANCiAgICAgZGV2aWNlIG9yIHN5c3RlbSB0aGF0IGlzIHNl cnZpY2VkIGJ5IGFuIFNNVFAgc2VydmVyLiAgVGhlIFNNVFAgDQogICAgIHNlcnZlciBtYXkg cmVwb3J0IHRoZSB0YXJnZXQncyBjb250ZW50IGNhcGFiaWxpdGllcyBiYWNrIHRvIHRoZSAN CiAgICAgY2xpZW50LiBUaGlzIHByb2Nlc3MgZW11bGF0ZXMgYSBjbGFzc2ljIGZhY3NpbWls ZSBzdGFydC1vZi1zZXNzaW9uIA0KICAgICBjYXBhYmlsaXRpZXMgbmVnb3RpYXRpb24sIGFs dGhvdWdoIGl0IG1heSBiZSB1c2VkIGZvciBhbnkgZW1haWwtDQogICAgIGJhc2VkIHNlcnZp Y2UuICBUaGlzIGV4dGVuc2lvbiBpcyBwcmltYXJpbHkgaW50ZW5kZWQgZm9yICJkaXJlY3Qi IA0KICAgICBTTVRQIHRyYW5zZmVycywgYWx0aG91Z2ggcmVsYXllZCBzY2VuYXJpb3MgYXJl IHBlcm1pdHRlZCB0aHJvdWdoIGEgDQogICAgIHNlcmllcyBvZiBTTVRQIHNlcnZlcnMuDQoN Cg0KMi4gICBDT05WRU5USU9OUw0KICAgICANCiAgICAgSW4gZXhhbXBsZXMsICJDOiIgYW5k ICJTOiIgaW5kaWNhdGUgbGluZXMgc2VudCBieSB0aGUNCiAgICAgY2xpZW50IGFuZCBzZXJ2 ZXIgcmVzcGVjdGl2ZWx5Lg0KICAgICANCiAgICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJN VVNUIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxEDQogICAgIE5PVCIsIGFuZCAiTUFZIiBpbiB0 aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZA0KICAgICBhcyBkZWZpbmVkIGlu ICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgIFJlcXVpcmVt ZW50IExldmVscyIgW0tFWVdPUkRTXS4NCg0KDQoNCjMuICAgQ09OVEVOVCBORUdPVElBVElP TiBTRVJWSUNFIEVYVEVOU0lPTg0KICAgICANCiAgICAgKDEpICBUaGUgbmFtZSBvZiB0aGUg U01UUCBzZXJ2aWNlIGV4dGVuc2lvbiBpcw0KICAgICAgICAgICJDb250ZW50X05lZ290aWF0 aW9uIg0KDQogICAgICgyKSAgVGhlIEVITE8ga2V5d29yZCB2YWx1ZSBhc3NvY2lhdGVkIHdp dGggdGhpcyBleHRlbnNpb24NCiAgICAgICAgICBpcyAiQ09OTkVHIg0KDQogICAgICgzKSAg QSBwYXJhbWV0ZXIgdXNpbmcgdGhlIGtleXdvcmQgIkNPTk5FRyIgaXMgYWRkZWQgdG8gdGhl DQogICAgICAgICAgUkNQVC1UTyBjb21tYW5kDQoNCiAgICAgKDQpICBUaGUgc2VydmVyIHJl c3BvbmRzIHdpdGggYSByZXBvcnQgb2YgdGhlIGNvbnRlbnQNCiAgICAgICAgICBjYXBhYmls aXRpZXMgb2YgdGhlIGRldmljZSBvciBzeXN0ZW0gdGhhdCBlbWJvZGllcyB0aGUNCiAgICAg ICAgICB0YXJnZXQgUkNQVC1UTyBhZGRyZXNzLg0KDQoNCg0KNC4gICBDT05ORUcgUEFSQU1F VEVSIFRPIFJDUFQtVE8NCiAgICAgDQo0LjEgIFBhcmFtZXRlcg0KDQogICAgIEtleXdvcmQ6 DQogICAgICAgICAgDQogICAgICAgICAgQ09OTkVHDQogICAgIA0KICAgICBBcmd1bWVudDoN CiAgICAgICAgICANCiAgICAgICAgICBSRVFVSVJFRA0KICAgICAgICAgICAgVGhlIGNsaWVu dCByZXF1aXJlcyBzdXBwb3J0IGZvciB0aGUgY2FwYWJpbGl0eS4gSWYgdGhlIA0KICAgICAg ICAgICAgdGFyZ2V0IGRvZXMgbm90IHN1cHBvcnQgdGhlIENPTk5FRyBwYXJhbWV0ZXIsIHRo ZSB0YXJnZXQgDQogICAgICAgICAgICBNVVNUIHJlamVjdCB0aGUgUkNQVC1UTyBjb21tYW5k IHdpdGggYSA1MDQgcmVwbHkuDQoNCiAgICAgICAgICAgIElmIHRoZSB0YXJnZXQgY2FuIG5v dCBzdXBwb3J0IHRoZSBjYXBhYmlsaXR5IGR1ZSB0byBhIA0KICAgICAgICAgICAgdGVtcG9y YXJ5IHByb2JsZW0sIGl0IE1VU1QgcmVqZWN0IHRoZSBSQ1BULVRPIGNvbW1hbmQgd2l0aCAN CiAgICAgICAgICAgIGEgNDA0IHJlcGx5LiANCg0KICAgICAgICAgIE9QVElPTkFMDQogICAg ICAgICAgICBUaGUgY2xpZW50IHJlcXVlc3RzIHRoZSB0YXJnZXQgdG8gdXNlIHRoZSBjYXBh YmlsaXR5LiBJZiANCiAgICAgICAgICAgIHRoZSB0YXJnZXQgY2FuIG5vdCBzdXBwb3J0IHRo ZSBjYXBhYmlsaXR5IGF0IHRoaXMgdGltZSwgdGhlIA0KICAgICAgICAgICAgdGFyZ2V0IE1V U1QgcHJvY2VzcyB0aGUgYWRkcmVzcyBhbmQgbWVzc2FnZSBhcyBpZiB0aGUgDQogICAgICAg ICAgICByZXF1ZXN0ZWQgQ09OTkVHIGNhcGFiaWxpdGllcyBoYWQgbm90IGJlZW4gc3BlY2lm aWVkLg0KICAgICAgICAgICAgDQogICAgICAgICAgSWYgdGhlIGFyZ3VtZW50IGRvZXMgbm90 IGV4aXN0LCB0aGUgZGVmYXVsdCBpcyAiUkVRVUlSRUQiLg0KICAgICAgICAgIA0KICAgICAg ICAgIFdoZW4gYSBjYXBhYmlsaXR5IGlzIFJFUVVJUkVEIGJ5IHRoZSBjbGllbnQgYnV0IGNh biBub3QgDQogICAgICAgICAgY3VycmVudGx5IGJlIHN1cHBvcnRlZCBieSB0aGUgdGFyZ2V0 LCBhbiBlcnJvciByZXNwb25zZSB3aWxsIA0KICAgICAgICAgIGhhdmUgc2lnbmlmaWNhbnQg cGVyZm9ybWFuY2UgaW1wYWN0IHRvIG92ZXJhbGwgU01UUCANCiAgICAgICAgICBwcm9jZXNz aW5nLiAgVXNlIG9mIHRoZSBPUFRJT05BTCBwYXJhbWV0ZXIgd2lsbCBlbnN1cmUgaGlnaCAN CiAgICAgICAgICBTTVRQIHBlcmZvcm1hbmNlLg0KDQogICAgICAgICAgIA0KNC4yIENsaWVu dCBBY3Rpb246DQogICAgICAgICAgDQogICAgIElmIHRoZSBzZXJ2ZXIgaXNzdWVkIGEgMjUw LUNPTk5FRywgYXMgcGFydCBvZiBpdHMNCiAgICAgRUhMTyByZXNwb25zZSBmb3IgdGhlIGN1 cnJlbnQgc2Vzc2lvbiwgdGhlIGNsaWVudCBNQVkNCiAgICAgaXNzdWUgdGhlIENPTk5FRyBw YXJhbWV0ZXIgd2l0aCBSQ1BULVRPLg0KICAgICAgICAgIA0KICAgICBJZiB0aGUgY2xpZW50 IGlzc3VlcyB0aGUgQ09OTkVHIHBhcmFtZXRlciB3aXRoDQogICAgIFJDUFQtVE8sIHRoZW4g aXQgTVVTVCBob25vciB0aGUgY2FwYWJpbGl0aWVzIHNwZWNpZmllZA0KICAgICBpbiB0aGUg Q09OTkVHIFJDUFQtVE8gcmVwbHksIGFuZCB0cmFuc2Zvcm0gZGF0YSB0aGF0IGlzDQogICAg IHNlbnQsIHNvIHRoYXQgdGhlIHRhcmdldCBjYW4gYWNjZXB0IHRoZSBkYXRhLiBUaGUNCiAg ICAgY2xpZW50IFNIT1VMRCB0cmFuc2Zvcm0gdGhlIGRhdGEgdG8gdGhlICJoaWdoZXN0IiBs ZXZlbA0KICAgICBvZiBjYXBhYmlsaXR5IG9mIHRoZSB0YXJnZXQuDQoNCiAgICAgSWYgdGhl IHNlcnZlciByZWplY3RzIHRoZSBSQ1BULVRPIGNvbW1hbmQgd2l0aCBhIDQwNCByZXBseSwg dGhlIA0KICAgICBjbGllbnQgbWF5IGxhdGVyIHJlaXNzdWUgdGhlIFJDUFQtVE8gd2l0aCB0 aGUgQ09OTkVHIHBhcmFtZXRlci4NCg0KICAgICBJZiB0aGUgc2VydmVyIHJldHVybnMgYW4g RUhMTyAyNTAgY29kZSB3aXRob3V0IENPTk5FRyANCiAgICAgY2FwYWJpbGl0aWVzLCB0aGUg Y2xpZW50IE1VU1Qgd29yayBhcyAiYSBTaW1wbGUgTW9kZSBvZiBGYWNzaW1pbGUgDQogICAg IFVzaW5nIEludGVybmV0IE1haWwiIFtSRkMyMzA1XS4NCg0KICAgICANCjQuMyBTZXJ2ZXIg QWN0aW9uOg0KICAgICAgICAgIA0KICAgICBJZiB0aGUgY2xpZW50IHNwZWNpZmllcyAiQ09O TkVHID0gUkVRVUlSRUQiIGluIHRoZSBSQ1BULVRPLCANCiAgICAgYnV0IHRoZSB0YXJnZXQg ZG9lcyBub3Qgc3VwcG9ydCB0aGUgQ09OTkVHIHBhcmFtZXRlciwgdGhlIHRhcmdldA0KICAg ICBNVVNUIHJlamVjdCB0aGUgUkNQVC1UTyBjb21tYW5kIHdpdGggYSA1MDQgcmVwbHkuIA0K ICAgICANCiAgICAgSWYgdGhlIHRhcmdldCBzdXBwb3J0IHRoZSBDT05ORUcgcGFyYW1ldGVy LCBidXQgaXQgY2FuIG5vdCByZXR1cm4gDQogICAgIHRoZSByZWNlcGllbnQncyBjYXBhYmls aXR5IHRlbXBvcmFyaWx5LCB0aGUgdGFyZ2V0IE1VU1QgcmVqZWN0IHRoZSANCiAgICAgUkNQ VC1UTyBjb21tYW5kIHdpdGggYSA0MDQgcmVwbHkuIEZvciBleGFtcGxlLCBpZiB0aGUgdGFy Z2V0IGdldCANCiAgICAgdGhlIGNhcGFiaWxpdHkgaW5mb3JtYXRpb24gZnJvbSBhIGRpcmVj dG9yeSwgYnV0IGl0cyBjb25uZWN0aW9uIGlzIA0KICAgICBvZmZsaW5lLCB0aGUgdGFyZ2V0 IE1VU1QgcmVqZWN0IHRoZSBSQ1BULVRPIGNvbW1hbmQgd2l0aCBhIDQwNCANCiAgICAgcmVw bHkuIA0KDQogICAgIElmIHRoZSBjbGllbnQgc3BlY2lmaWVzICJDT05ORUcgPSBPUFRJT05B TCIgaW4gdGhlIFJDUFQtVE8sIHRoZSANCiAgICAgdGFyZ2V0IE1VU1QgcHJvY2VzcyB0aGUg YWRkcmVzcyBhbmQgbWVzc2FnZSBhcyBpZiB0aGUgcmVxdWVzdGVkIA0KICAgICBDT05ORUcg Y2FwYWJpbGl0aWVzIGhhZCBub3QgYmVlbiBzcGVjaWZpZWQuDQoNCiAgICAgUmVnYXJkbGVz cyBvZiB0aGUgdmFsdWUgb2YgdGhlIHBhcmFtZXRlciwgaWYgdGhlIHRhcmdldCBkb2VzIA0K ICAgICBzdXBwb3J0IHRoZSBDT05ORUcgcGFyYW1ldGVyLCB0aGVuIGl0IE1VU1QgaXNzdWUg YSAyNTAgcmVwbHksIA0KICAgICBmb2xsb3dlZCBieSB0aGUgY2FwYWJpbGl0aWVzIG9mIHRo ZSB0YXJnZXQgdGhhdCBpcyBzcGVjaWZpZWQgYnkgDQogICAgIHRoZSBSQ1BULVRPIGFkZHJl c3MuIFN1Y2Nlc3NmdWwgcmVzcG9uc2VzIHRvIENPTk5FRyBSQ1BULVRPIA0KICAgICByZXF1 ZXN0cyB3aWxsIGFsd2F5cyBiZSBtdWx0aXBsZSBTTVRQIGxpbmVzLiAgVGhlIGZpcnN0IGxp bmUgDQogICAgIGlzIHRoZSBub3JtYWwgUkNQVC1UTyByZXNwb25zZSwgYW5kIHN1YnNlcXVl bnQgbGluZXMgYmVnaW5uaW5nIA0KICAgICB3aXRoIHRoZSBleGFjdCBzdHJpbmcgIjI1MC1D T05ORUcgIiBhbmQgIjI1MCBDT05ORUcgIiBhcmUgDQogICAgIHRoZSBDT05ORUcgcmVzcG9u c2VzLiBUaGUgbGFzdCBsaW5lIGJlZ2lucyB3aXRoICIyNTAgDQogICAgIENPTk5FRyIuICAN Cg0KICAgICBJZiB0aGUgU01UUCBzZXJ2ZXIgc3VwcG9ydHMgRU5IQU5DRURTVEFUVVNDT0RF UywgdGhlIHJlc3BvbnNlIA0KICAgICBzdHJpbmdzIGZvciBhIHN1Y2Nlc3MgYXJlICIyNTAt Mi4xLjUgQ09OTkVHIiBhbmQgIjI1MCAyLjEuNSANCiAgICAgQ09OTkVHIi4gVGhlIHJlc3Bv bnNlIHN0cmluZ3MgZm9yIGluZGljYXRpbmcgYSBwZXJtYW5lbnQgDQogICAgIGZhaWx1cmUg YXJlICI1MDQtNS4zLjMgQ09OTkVHIiBhbmQgIjUwNCA1LjMuMyBDT05ORUciLiANCiAgICAg VGhlIHJlc3BvbnNlIHN0cmluZ3MgZm9yIGEgdGVtcG9yYXJ5IGZhaWx1cmUgYXJlICI0MDQt NC4zLjMgDQogICAgIENPTk5FRyIgYW5kICI0MDQgNS4zLjMgQ09OTkVHIi4NCg0KICAgICBB bGwgQ09OTkVHLWNhcGFibGUgY2xpZW50cyBhbmQgQ09OTkVHLWNhcGFibGUgc2VydmVycyBN VVNUDQogICAgIGJlIGFibGUgdG8gc3VjY2Vzc2Z1bGx5IHByb2Nlc3MgQ09OTkVHIGxpbmVz IHRoYXQgYXJlIHVwIHRvIDUxMg0KICAgICBjaGFyYWN0ZXJzIGxvbmcsIGFzIHJlcXVpcmVk IGJ5IFJGQzI4MjEuIElmIHRoZSBsZW5ndGggb2YgQ09OTkVHDQogICAgIGxpbmVzIGlzIGdy ZWF0ZXIgdGhhbiA1MTIgY2hhcmFjdGVycywgdGhlIHNlcnZlciBNVVNUIGluc2VydA0KICAg ICBsaW5lIGJyZWFrcyBhbmQgbWFrZSBuZXh0IENPTk5FRyBsaW5lLiANCiAgICAgICAgICAN CiAgICAgVGhlIGNvbnRlbnRzIG9mIHRoZSBjYXBhYmlsaXR5IGxpc3RpbmcgTVVTVCBjb25m b3JtIHRvDQogICAgIFtSRkMyNTA2XSwgW1JGQzI1MzNdIGFuZCBbUkZDMjUzNF0sIGFuZCBN QVkgYmUgdXNlZCB0byBlbXVsYXRlDQogICAgIHNlcnZpY2VzLCBzdWNoIGFzIHRoZSBmYWNz aW1pbGUgc3RhcnQtb2Ytc2Vzc2lvbiBjYXBhYmlsaXRpZXMNCiAgICAgbmVnb3RpYXRpb24g YXMgZGVzY3JpYmVkIGluICJDb250ZW50IEZlYXR1cmUgU2NoZW1hIGZvcg0KICAgICBJbnRl cm5ldCBGYXgiLiBbUkZDMjg3OV0NCg0KDQoNCg0KNS4gICBTWU5UQVgNCiAgICAgDQogICAg IENvbW1hbmQgd2l0aCAiQ09OTkVHIjoNCiAgICAgICJSQ1BUIFRPOiIgKCI8UG9zdG1hc3Rl ckAiIGRvbWFpbiAiPiIgLyAiPFBvc3RtYXN0ZXI+Ig0KICAgICAgICAgICAgICAgICAgIC8g Rm9yd2FyZC1QYXRoKSAoU1AgIkNPTk5FRyA9IiAoIlJFUVVJUkVEIiAvDQogICAgICAgICAg ICAgICAgICJPUFRJT0FOTCIpIENSTEYNCg0KICAgICBSZXBseToNCiAgICAgICggKCIyNTAt IiBDUkxGKSAqKCIyNTAtQ09OTkVHIiBjYXBhYmlsaXR5IENSTEYpDQogICAgICAgICgiMjUw IENPTk5FRyIgY2FwYWJpbGl0eSBDUkxGKSApLw0KICAgICAgKCAoIjI1MC0yLjEuNSIgQ1JM RikgDQogICAgICAgICAgKigiMjUwLTIuMS41IENPTk5FRyIgY2FwYWJpbGl0eSBDUkxGKQ0K ICAgICAgICAgICAoIjI1MCAyLjEuNSBDT05ORUciIGNhcGFiaWxpdHkgQ1JMRikgKS8NCiAg ICAgICgiNTA0IiBDUkxGKSAvDQogICAgICAoIjUwNCA1LjMuMyIgQ1JMRikgLw0KICAgICAg KCI0MDQiIENSTEYpIC8NCiAgICAgICgiNDA0IDQuMy4zIiBDUkxGKSAvDQoNCg0KICAgICAg Y2FwYWJpbGl0eSA9IDw8YXMgcGVyIFtSRkMyNTA2XSwgW1JGQzI1MzNdLCBbUkZDMjUzNF0N CiAgICAgICAgICAgICAgICAgICAgYW5kIFtSRkMyODc5XSA+Pg0KDQoNCg0KNi4gICBFWEFN UExFDQoNCiAgICAgQW4gZXhhbXBsZSBvZiBFU01UUCBzZXF1ZW5jZSB3aXRoIHN1Y2Nlc3Nm dWwgUkNQVC1UTyByZXNwb25zZQ0KDQogICAgIFM6IDIyMCBpZmF4MS5qcCBJRkFYDQogICAg IA0KICAgICBDOiBFSExPIGlmYXgxLmpwDQogICAgIA0KICAgICBTOiAyNTAtaWZheDEuanAN CiAgICAgUzogMjUwLURTTg0KICAgICBTOiAyNTAgQ09OTkVHDQogICAgIA0KICAgICBDOiBN QUlMIEZST006PE1heUBpZmF4Mi5qcD4NCiAgICAgDQogICAgIFM6IDI1MCA8TWF5QGlmYXgy LmpwPiBzZW5kZXIgb2sNCiAgICAgDQogICAgIEM6IFJDUFQgVE86PEp1bmVAaWZheDEuanA+ IENPTk5FRyA9IFJFUVVJUkVEDQogICAgIA0KICAgICBTOiAyNTAtPEp1bmVAaWZheDEuanA+ IHJlY2lwaWVudCBvaw0KICAgICBTOiAyNTAgQ09OTkVHICgmKGltYWdlLWZpbGUtc3RydWN0 dXJlPVRJRkYtbWluaW1hbCkNCiAgICAgUzogKE1SQy1tb2RlPTApKGNvbG9yPUJpbmFyeSko fCgmKGRwaT0yMDQpDQogICAgIFM6IChkcGkteHlyYXRpbz1bMjA0Lzk4LDIwNC8xOTZdKSAp KCYoZHBpPTIwMCkNCiAgICAgUzogKGRwaS14eXJhdGlvPVsyMDAvMTAwLDFdKSApKCYoZHBp PTQwMCkNCiAgICAgUzogKGRwaS14eXJhdGlvPTEpICkgKSh8KGltYWdlLWNvZGluZz1bTUgs TVIsTU1SXSkNCiAgICAgUzogKCYoaW1hZ2UtY29kaW5nPUpCSUcpKGltYWdlLWNvZGluZy1j b25zdHJhaW50PUpCSUctVDg1KQ0KICAgICBTOiAoSkJJRy1zdHJpcGUtc2l6ZT0xMjgpICkg KShwYXBlci1zaXplPVtsZXR0ZXIsQTQsQjRdKQ0KICAgICBTOiAodWEtbWVkaWE9c3RhdGlv bmVyeSkgKQ0KICAgICANCiAgICAgQzogREFUQQ0KICAgICANCiAgICAgUzogMzU0IG9rYXks IHNlbmQgZGF0YQ0KICAgICANCiAgICAgQzogPDxSRkMgMjgyMiBtZXNzYWdlIHdpdGggTUlN RSBDb250ZW50LVR5cGU6VElGRi1GWA0KICAgICAgICAgIFBlcjoNCiAgICAgICAgICAoICBp bWFnZS1maWxlLXN0cnVjdHVyZT1USUZGLW1pbmltYWwNCiAgICAgICAgICAgICBkcGk9NDAw DQogICAgICAgICAgICAgaW1hZ2UtY29kaW5nPUpCSUcNCiAgICAgICAgICAgICBzaXplLXg9 MjE1MA0KICAgICAgICAgICApDQogICAgICAgID4+DQogICAgIA0KICAgICBTOiAyNTAgbWVz c2FnZSBhY2NlcHRlZA0KICAgICANCiAgICAgQzogUVVJVA0KICAgICANCiAgICAgUzogMjIx IGdvb2RieWUNCg0KDQogICAgIEFuIGV4YW1wbGUgb2Ygc3VjY2Vzc2Z1bCBSQ1BULVRPIHJl c3BvbnNlIHdoZW4gdGhlIGxlbmd0aCBvZiANCiAgICAgY2FwYWJpbGl0eSBpcyBncmVhdGVy IHRoYW4gNTEyIGNoYXJhY3RlcnMuIA0KDQogICAgIFM6IDI1MC0yLjEuNTxKdW5lQGlmYXgx LmpwPiByZWNpcGllbnQgb2sNCiAgICAgUzogMjUwLTIuMS41IENPTk5FRyAoJihpbWFnZS1m aWxlLXN0cnVjdHVyZT1USUZGLW1pbmltYWwpIC4uLg0KICAgICBTOiAyNTAtMi4xLjUgQ09O TkVHICAgLi4uLi4NCiAgICAgUzogMjUwIDIuMS41IENPTk5FRyAgIChjb2xvcj1CaW5hcnkp DQoNCg0KICAgICBBbiBleGFtcGxlIG9mIHN1Y2Nzc2Z1bCBSQ1BULVRPIHJlc3BvbnNlIHdo ZW4gQ09OTkVHLWNhcGFibGUgDQogICAgIHNlcnZlciBzdXBwb3J0cyBFTkhBTkNFRFNUQVRV U0NPREVTLg0KDQogICAgIFM6IDI1MC0yLjEuNTxKdW5lQGlmYXgxLmpwPiByZWNpcGllbnQg b2sNCiAgICAgUzogMjUwIDIuMS41IENPTk5FRyAoJihpbWFnZS1maWxlLXN0cnVjdHVyZT1U SUZGLW1pbmltYWwpDQogICAgIFM6IChNUkMtbW9kZT0wKShjb2xvcj1CaW5hcnkpKHwoJihk cGk9MjA0KQ0KICAgICBTOiAoZHBpLXh5cmF0aW89WzIwNC85OCwyMDQvMTk2XSkgKSgmKGRw aT0yMDApDQogICAgIFM6IChkcGkteHlyYXRpbz1bMjAwLzEwMCwxXSkgKSgmKGRwaT00MDAp DQogICAgIFM6IChkcGkteHlyYXRpbz0xKSApICkofChpbWFnZS1jb2Rpbmc9W01ILE1SLE1N Ul0pDQogICAgIFM6ICgmKGltYWdlLWNvZGluZz1KQklHKShpbWFnZS1jb2RpbmctY29uc3Ry YWludD1KQklHLVQ4NSkNCiAgICAgUzogKEpCSUctc3RyaXBlLXNpemU9MTI4KSApICkocGFw ZXItc2l6ZT1bbGV0dGVyLEE0LEI0XSkNCiAgICAgUzogKHVhLW1lZGlhPXN0YXRpb25lcnkp ICkNCg0KDQogICAgIEFuIGV4YW1wbGUgb2YgRVNNVFAgc2VxdWVuY2Ugd2l0aCBwYXJtYW5l bnQgZmFpbHVyZSBSQ1BULVRPIA0KICAgICByZXNwb25zZS4gDQoNCiAgICAgUzogMjIwIGlm YXgxLmpwIElGQVgNCiAgICAgDQogICAgIEM6IEVITE8gaWZheDEuanANCiAgICAgDQogICAg IFM6IDI1MC1pZmF4MS5qcA0KICAgICBTOiAyNTAtRFNODQogICAgIA0KICAgICBDOiBNQUlM IEZST006PE1heUBpZmF4Mi5qcD4NCiAgICAgDQogICAgIFM6IDI1MCA8TWF5QGlmYXgyLmpw PiBzZW5kZXIgb2sNCiAgICAgDQogICAgIEM6IFJDUFQgVE86PEp1bmVAaWZheDEuanA+IENP Tk5FRyA9IFJFUVVJUkVEDQogICAgIA0KICAgICBTOiA1MDQgPEp1bmVAaWZheDEuanA+IHJl Y2lwaWVudCBvaw0KDQogICAgIEM6IFFVSVQNCiAgICAgDQogICAgIFM6IDIyMSBnb29kYnll DQoNCg0KDQogICAgIEFuIGV4YW1wbGUgb2YgYW4gRVNNVFAgc2VxdWVuY2Ugd2l0aCB0ZW1w b3JhcnkgZmFpbHVyZSBSQ1BULVRPIA0KICAgICByZXNwb25zZSB3aGVuIHRoZSB2YWx1ZSBv ZiBwYXJhbWV0ZXIgaXMgIlJFUVVJUkVEIjoNCg0KICAgICBTOiAyMjAgaWZheDEuanAgSUZB WA0KICAgICANCiAgICAgQzogRUhMTyBpZmF4MS5qcA0KICAgICANCiAgICAgUzogMjUwLWlm YXgxLmpwDQogICAgIFM6IDI1MC1EU04NCiAgICAgUzogMjUwIENPTk5FRw0KICAgICANCiAg ICAgQzogTUFJTCBGUk9NOjxNYXlAaWZheDIuanA+DQogICAgIA0KICAgICBTOiAyNTAgPE1h eUBpZmF4Mi5qcD4gc2VuZGVyIG9rDQogICAgIA0KICAgICBDOiBSQ1BUIFRPOjxKdW5lQGlm YXgxLmpwPiBDT05ORUcgPSBSRVFVSVJFRA0KICAgICANCiAgICAgUzogNDA0IDxKdW5lQGlm YXgxLmpwPiByZWNpcGllbnQgb2sNCg0KICAgICBDOiBRVUlUDQogICAgIA0KICAgICBTOiAy MjEgZ29vZGJ5ZQ0KICAgICAuDQogICAgIC4NCiAgICAgLg0KICAgICByZXRyeSBhY2NvcmRp bmcgdG8gaW1wbGVtZW50YXRpb24NCg0KDQoNCiAgICAgQW4gZXhhbXBsZSBvZiBhbiBFU01U UCBzZXF1ZW5jZSB3aXRoIHRlbXBvcmFyeSBmYWlsdXJlIFJDUFQtVE8gDQogICAgIHJlc3Bv bnNlIHdoZW4gdGhlIHZhbHVlIG9mIHBhcmFtZXRlciBpcyAiT1BUSU9OQUwiOg0KDQogICAg IFM6IDIyMCBpZmF4MS5qcCBJRkFYDQogICAgIA0KICAgICBDOiBFSExPIGlmYXgxLmpwDQog ICAgIA0KICAgICBTOiAyNTAtaWZheDEuanANCiAgICAgUzogMjUwLURTTg0KICAgICBTOiAy NTAgQ09OTkVHDQogICAgIA0KICAgICBDOiBNQUlMIEZST006PE1heUBpZmF4Mi5qcD4NCiAg ICAgDQogICAgIFM6IDI1MCA8TWF5QGlmYXgyLmpwPiBzZW5kZXIgb2sNCiAgICAgDQogICAg IEM6IFJDUFQgVE86PEp1bmVAaWZheDEuanA+IENPTk5FRyA9IE9QVElPTkFMDQogICAgIA0K ICAgICBTOiAyNTAgPEp1bmVAaWZheDEuanA+IHJlY2lwaWVudCBvaw0KICAgICANCiAgICAg QzogREFUQQ0KICAgICANCiAgICAgUzogMzU0IG9rYXksIHNlbmQgZGF0YQ0KICAgICANCiAg ICAgQzogPDxSRkMgMjgyMiBtZXNzYWdlIHdpdGggTUlNRSBDb250ZW50LVR5cGU6VElGRi1G WA0KICAgICAgICAgIFBlciAiQSBTaW1wbGUgTW9kZSBvZiBGYWNzaW1pbGUgVXNpbmcgSW50 ZXJuZXQgTWFpbCINCiAgICAgICAgICBSRkMyMzA1DQogICAgICAgID4+DQogICAgIA0KICAg ICBTOiAyNTAgbWVzc2FnZSBhY2NlcHRlZA0KICAgICANCiAgICAgQzogUVVJVA0KICAgICAN CiAgICAgUzogMjIxIGdvb2RieWUNCg0KDQoNCjcuICAgSUFOQSBDT05TSURFUkFUSU9OUw0K ICAgICANCiAgICAgT24gcHVibGljYXRpb20gb2YgdGhpcyBkb2N1bWVudCBieSB0aGUgUkZD IEVkaXRvciwgdGhlIElBTkEgDQogICAgIHNoYWxsIHJlZ2lzdGVyIHRoZSBDb250ZW50X05l Z290aWF0aW9uIEVTTVRQIGV4dGVuc2lvbiBkZWZpbmVkIA0KICAgICBpbiBzZWN0aW9uIDMu DQoNCg0KOC4gICBTRUNVUklUWSBDT05TSURFUkFUSU9OUw0KICAgICANCiAgICAgVGhpcyBF U01UUCBvcHRpb24gY2FsbHMgZm9yIGEgcmVzcG9uZGVudCB0byBkaXNjbG9zZQ0KICAgICBp dHMgY2FwYWJpbGl0aWVzLiAgTWVjaGFuaXNtcyBmb3IgZGV0ZXJtaW5pbmcgdGhlDQogICAg IHJlcXVlc3RvcidzIGF1dGhlbnRpY2F0ZWQgaWRlbnRpdHkgYXJlIG91dHNpZGUgdGhlDQog ICAgIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gIEl0IGlzIGludGVuZGVkIHRoYXQg dGhpcw0KICAgICBtZWNoYW5pc20gcGVybWl0IGRpc2Nsb3N1cmUgb2YgcHVibGljIGluZm9y bWF0aW9uOw0KICAgICBoZW5jZSB0aGVyZSBpcyBubyBwYXJ0aWN1bGFyIG5lZWQgZm9yIHNl Y3VyaXR5DQogICAgIG1lYXN1cmVzLg0KICAgICANCiAgICAgSG93ZXZlciB0aGVyZSBpcyBu b3RoaW5nIHRvIHByZXZlbnQgZGlzY2xvc3VyZSBvZg0KICAgICBzZW5zaXRpdmUgaW5mb3Jt YXRpb24gdGhhdCBzaG91bGQgcmVjZWl2ZSByZXN0cmljdGVkDQogICAgIGRpc3RyaWJ1dGlv bi4gIEl0IGlzLCB0aGVyZWZvcmUsIHRoZSByZXNwb25zaWJpbGl0eSBvZg0KICAgICB0aGUg ZGlzY2xvc2luZyBFU01UUCBzZXJ2ZXIgdG8gZGV0ZXJtaW5lIHdoZXRoZXINCiAgICAgYWRk aXRpb25hbCBzZWN1cml0eSBtZWFzdXJlcyBzaG91bGQgYmUgYXBwbGllZCB0byB0aGUNCiAg ICAgdXNlIG9mIHRoaXMgRVNNVFAgb3B0aW9uLg0KDQogICAgIEEgbWFuLWluLXRoZS1taWRk bGUgYXR0YWNrIG1pZ2h0IGNoYW5nZSB0aGUgY2FwYWJpbGl0aWVzIHJlcG9ydGVkIA0KICAg ICBmb3IgYSBnaXZlbiByZWNpcGllbnQuIEZvciBleGFtcGxlOiBTdXBwb3NlIHRoZSBzZW5k ZXIga25vd3MgdGhlIA0KICAgICByZWNpcGllbnQgaGFzIHRoZSBhYmlsaXR5IHRvIHZpZXcg Y29sb3IgZG9jdW1lbnRzIHNvIHRoZXkgbWFyayANCiAgICAgc29tZSB0aGluZ3MgaW4gcmVk IGluIHdoYXQgaXMgb3RoZXJ3aXNlIGEgYmxhY2sgYW5kIHdoaXRlIA0KICAgICBkb2N1bWVu dC4gQnV0IHNvbWVvbmUgaW50ZXJmZXJlcyB3aXRoIHRoZSByZXR1cm5lZCBjYXBhYmlsaXRp ZXMsIA0KICAgICBpbmRpY2F0aW5nIHRoYXQgdGhlIHJlY2lwaWVudCBvbmx5IHN1cHBvcnRz IGJsYWNrIGFuZCB3aGl0ZS4gVGhlIA0KICAgICBkb2N1bWVudCBpcyBkdWx5IGRvd25ncmFk ZWQsIHdpdGggdGhlIHJlc3VsdCB0aGF0IHRoZSByZWNpcGllbnQgDQogICAgIGRvZXNuJ3Qg c2VlIHdoYXQgdGhlIHNlbmRlciBtYXJrZWQuIA0KICAgICANCiAgICAgQW4gaW5kaXJlY3Qg ZXhwb3N1cmUgY2FuIG9jY3VyIHdoZW4gdGhlIHJlcG9ydCBvZiBhIGNhcGFiaWxpdHkgDQog ICAgIGltcGxpZXMgdXNlIG9mIHNwZWNpZmljIHNvZnR3YXJlLiAgSWYgdGhhdCBzb2Z0d2Fy ZSBpcyBrbm93biB0byANCiAgICAgaGF2ZSBzZWN1cml0eSB3ZWFrbmVzc2VzLCB0aGUgY2Fw YWJpbGl0aWVzIHJlcG9ydCBlZmZlY3RpdmVseSANCiAgICAgYWR2ZXJ0aXNlcyB0aGUgYXNz b2NpYXRlZCBvcHBvcnR1bml0eSB0byBleHBsb2l0IHRoZSBzZWN1cml0eSANCiAgICAgd2Vh a25lc3MuDQogICAgIA0KICAgICBGb3IgdGFyZ2V0IFNNVFAgc2VydmVycyB0aGF0IHJlcXVp cmUgc2VjdXJpdHkgbWVjaGFuaXNtcyB0byBiZSBpbiANCiAgICAgZm9yY2UgYXQgdGhlIHN0 YXJ0IG9mIHRoZSBzZXNzaW9uLCB0aGUgdGFyZ2V0IFNIT1VMRCByZWZyYWluIGZyb20gDQog ICAgIGluY2x1ZGluZyB0aGUgQ09OTkVHIHBhcmFtZXRlciBpbiBhbiBFSExPIHJlc3BvbnNl IHVudGlsIHRoZSANCiAgICAgcmVxdWlzaXRlIHNlY3VyaXR5IG1lY2hhbmlzbXMgYXJlIGlu IGZvcmNlLg0KDQoNCg0KDQo5LiAgIEFDS05PV0xFREdFTUVOVFMNCiAgICAgDQogICAgIEdy YWhhbSBLbHluZSBwcm92aWRlZCB1c2VmdWwgc3VnZ2VzdGlvbnMgdG8gYW4gZWFybGllcg0K ICAgICBkcmFmdC4NCg0KDQoNCjEwLiAgIE5PUk1BVElWRSBSRUZFUkVOQ0VTDQogICAgIA0K ICAgICBbRVNNVFAxXSAgS2xlbnNpbiwgSi4sIEZyZWVkLCBOLiwgUm9zZSwgTS4sIFN0ZWZm ZXJ1ZCwNCiAgICAgICAgICAgICAgIEUuIGFuZCBELiBDcm9ja2VyLCAiU01UUCBTZXJ2aWNl IEV4dGVuc2lvbnMiLA0KICAgICAgICAgICAgICAgUkZDIDE4NjksIE5vdmVtYmVyIDE5OTUN CiAgICAgDQogICAgIFtFU01UUDJdICBLbGVuc2luLCBKLiwgIlNpbXBsZSBNYWlsIFRyYW5z ZmVyIFByb3RvY29sIiwNCiAgICAgICAgICAgICAgIFJGQyAyODIxLCBBcHJpbCAyMDAxLg0K ICAgICANCiAgICAgW1JGQzI4NzldIE1jSW50eXJlLCBMLiBhbmQgRy4gS2x5bmUsICJDb250 ZW50IEZlYXR1cmUNCiAgICAgICAgICAgICAgIFNjaGVtYSBmb3IgSW50ZXJuZXQgRmF4Iiwg UkZDIDI1MzEsIEF1Z3VzdA0KICAgICAgICAgICAgICAgMjAwMA0KDQogICAgIFtSRkMyMzA1 XSBUb3lvZGEsIEsuLCBPaG5vLCBILiwgTXVyYWksIEouIGFuZCAgRC4gV2luZywgDQogICAg ICAgICAgICAgICAiQSBTaW1wbGUgTW9kZSBvZiBGYWNzaW1pbGUgVXNpbmcgSW50ZXJuZXQg TWFpbCIsIA0KICAgICAgICAgICAgICAgUkZDIDIzMDUsIE1hcmNoIDE5OTguDQoNCiAgICAg W1JGQzI1MDZdIEhvbHRtYW4sIEsuLCBNdXR6LCBBLiBhbmQgVC4gSGFyZGllLCAiTWVkaWEg RmVhdHVyZQ0KICAgICAgICAgICAgICAgVGFnIFJlZ2lzdHJhdGlvbiBQcm9jZWR1cmUiLCBS RkMgMjUwNiwgTWFyY2ggMTk5OS4NCg0KICAgICBbUkZDMjUzM10gS2x5bmUsIEcuLCAiQSBz eW50YXggZm9yIGRlc2NyaWJpbmcgbWVkaWEgZmVhdHVyZSANCiAgICAgICAgICAgICAgIHNl dHMiLCBSRkMgMjUzMywgTWFyY2ggMTk5OS4NCg0KICAgICBbUkZDMjUzNF0gTWFzaW50ZXIs IEwuLCBIb2x0bWFuLCBLLiwgTXV0eiwgQS4gYW5kIEQuIFdpbmcsICINCiAgICAgICAgICAg ICAgIE1lZGlhIEZlYXR1cmVzIGZvciBEaXNwbGF5LCBQcmludCwgYW5kIEZheCIsIA0KICAg ICAgICAgICAgICAgUkZDIDI1MzQsIE1hcmNoIDE5OTkuDQoNCg0KMTEuICBBVVRIT1JTJyBB RERSRVNTRVMNCiAgICAgDQogICAgIEtpeW9zaGkgVG95b2RhDQogICAgIE1hdHN1c2hpdGEg R3JhcGhpYyBDb21tdW5pY2F0aW9uIFN5c3RlbXMsSW5jDQogICAgIDItMy04IFNoaW1vbWVn dXJvLCBNZWd1cm8tS3UNCiAgICAgVG9reW8gMTUzICBKQVBBTg0KICAgICANCiAgICAgKzgx LjMuNTQzNC43MTYxDQogICAgIGt0b3lvZGFAcmRtZy5tZ2NzLm1laS5jby5qcA0KICAgICAN CiAgICAgDQogICAgIERhdmUgQ3JvY2tlcg0KICAgICBCcmFuZGVuYnVyZyBJbnRlcm5ldFdv cmtpbmcNCiAgICAgNjc1IFNwcnVjZSBEcml2ZQ0KICAgICBTdW5ueXZhbGUsIENBICA5NDA4 NiAgVVNBDQogICAgIA0KICAgICArMS40MDguMjQ2LjgyNTMNCiAgICAgZGNyb2NrZXJAYnJh bmRlbmJ1cmcuY29tDQoNCg0KDQoxMi4gICAgICAgRlVMTCBDT1BZUklHSFQgU1RBVEVNRU5U DQogICAgIA0KICAgICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAx KS4gIEFsbCBSaWdodHMNCiAgICAgUmVzZXJ2ZWQuDQogICAgIA0KICAgICBUaGlzIGRvY3Vt ZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQNCiAgICAgZnVy bmlzaGVkIHRvIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50DQog ICAgIG9uIG9yIG90aGVyd2lzZSBleHBsYWluIGl0IG9yIGFzc2lzdCBpbiBpdHMNCiAgICAg aW1wbGVtZW50YXRpb24gbWF5IGJlIHByZXBhcmVkLCBjb3BpZWQsIHB1Ymxpc2hlZCBhbmQN CiAgICAgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBhcnQsIHdpdGhvdXQgcmVzdHJp Y3Rpb24NCiAgICAgb2YgYW55IGtpbmQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlIGNvcHly aWdodCBub3RpY2UNCiAgICAgYW5kIHRoaXMgcGFyYWdyYXBoIGFyZSBpbmNsdWRlZCBvbiBh bGwgc3VjaCBjb3BpZXMgYW5kDQogICAgIGRlcml2YXRpdmUgd29ya3MuICBIb3dldmVyLCB0 aGlzIGRvY3VtZW50IGl0c2VsZiBtYXkNCiAgICAgbm90IGJlIG1vZGlmaWVkIGluIGFueSB3 YXksIHN1Y2ggYXMgYnkgcmVtb3ZpbmcgdGhlDQogICAgIGNvcHlyaWdodCBub3RpY2Ugb3Ig cmVmZXJlbmNlcyB0byB0aGUgSW50ZXJuZXQgU29jaWV0eQ0KICAgICBvciBvdGhlciBJbnRl cm5ldCBvcmdhbml6YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvcg0KICAgICB0aGUgcHVy cG9zZSBvZiBkZXZlbG9waW5nIEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGljaA0KICAgICBj YXNlIHRoZSBwcm9jZWR1cmVzIGZvciBjb3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlDQogICAg IEludGVybmV0IFN0YW5kYXJkcyBwcm9jZXNzIG11c3QgYmUgZm9sbG93ZWQsIG9yIGFzDQog ICAgIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFu DQogICAgIEVuZ2xpc2guDQogICAgIA0KICAgICBUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBn cmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kDQogICAgIHdpbGwgbm90IGJlIHJldm9r ZWQgYnkgdGhlIEludGVybmV0IFNvY2lldHkgb3IgaXRzDQogICAgIHN1Y2Nlc3NvcnMgb3Ig YXNzaWducy4NCiAgICAgDQogICAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaGVyZWluIGlzDQogICAgIHByb3ZpZGVkIG9uIGFuICJBUyBJUyIgYmFz aXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZDQogICAgIEFORCBUSEUgSU5URVJORVQgRU5H SU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTVMgQUxMDQogICAgIFdBUlJBTlRJRVMsIEVY UFJFU1MgT1IgSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QNCiAgICAgTElNSVRFRCBUTyBB TlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTg0KICAgICBIRVJF SU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KICAgICBX QVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBDQogICAgIFBB UlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQoNCg== ----------------------2064483419811763-- From owner-ietf-fax@mail.imc.org Thu Jun 20 14:00:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08564 for ; Thu, 20 Jun 2002 14:00:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5KHf1b21992 for ietf-fax-bks; Thu, 20 Jun 2002 10:41:01 -0700 (PDT) Received: from sharplabs.com (keymaster.sharplabs.com [216.65.151.107]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KHexn21984 for ; Thu, 20 Jun 2002 10:40:59 -0700 (PDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by sharplabs.com (8.9.1/8.9.2) with ESMTP id KAA00418 for ; Thu, 20 Jun 2002 10:34:59 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 10:41:32 -0700 Message-ID: <116DB56CD7DED511BC7800508B2CA5370A1A3F@mailsrvnt02.enet.sharplabs.com> From: "McDonald, Ira" To: ietf-fax@imc.org Subject: FW: IFX> Portland topics [PWG 27/28 June 2002] Date: Thu, 20 Jun 2002 10:41:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi folks, FYI - the agenda for next week's IEEE/ISTO PWG (Printer Working Group) sessions on IPPFAX (realtime Fax over IPP). Gail Songer just sent me the plaintext for the (originally) MS Word attachments, so I've pasted them onto the end of her note below. Please see the PWG archives or subscribe to the PWG IFX mailing list if you are interested in more information about the IPPFAX project. http://www.pwg.org Cheers, - Ira McDonald High North Inc -----Original Message----- From: Gail Songer [mailto:gsonger@peerless.com] Sent: Monday, June 17, 2002 1:48 PM To: ifx@pwg.org Subject: IFX> Portland topics Hi, I've gone back through the past couple months of emails and tried to get the highlights of the issues raised on the mailing list. We can use these as a starting point for our discussions. I've also drawn up a short agenda; the topics are in no particular order. Gail (See attached file: RoyaltyQuestions.doc)(See attached file: PDFQuestions.doc)(See attached file: Requirements.doc)(See attached file: Agenda.doc) -----Plaintext of Attachments----- [Agenda] * Requirement check * Required Formats o PDF * Questions for Adobe o TIFF FX o IPP Solution - Docs from RonB ---------- [Royalty Questions] From: Harry Lewis (harryl@us.ibm.com) Date: Mon May 13 2002 - 18:19:22 EDT Scott, thanks for getting back to us. Are you saying Adobe would have no objection (licensing or otherwise) to the IEEE ISTO PWG basing IPP FAX on PDF? Are we talking explicitly PDF/X-3 (a pre-press data interchange subset), another subset (t.b.d.?) or full blown PDF? ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- From: don@lexmark.com Date: Tue May 14 2002 - 17:12:37 EDT Scott: Just to clarify.... On the adobe website at: http://partners.adobe.com/asn/developer/legalnotices.html Adobe agrees to royalty free licensing of - 5,634,064 - 5,737,599 - 5,781,785 - 5,819,301 - 6,028,583 for producing, consuming and interpreting PDF and - 5,860,074 only for producing (not consuming or interpreting) PDF. We know that for PDF 1.4 there are additional patents including but not limited to: - 6,289,364 for such things as transparency, etc. Now the question...... will all the patents necessary for PDF 1.4 also be available on RF terms? From: Scott Foshee (sfoshee@adobe.com) Date: Tue Jun 04 2002 - 18:44:40 EDT Hi Harry, I can not speak for Adobe on this point. My understanding is that we would offer a license on Adobe's PDF on the same terms as those we offer TC130 in their development of PDF/X. One of our reps to the Portland meeting is tasked with sorting this out for IEEE. tx....Scott --------------------------------- [PDF Questions] From: John Pulera (jpulera@minolta-mil.com) Date: Wed Jun 05 2002 - 16:44:16 EDT In regard to using PDF as the data format for IPPFAX, I remember someone raising the concern that the data format is not very streamable. According to the spec (section 5.17) an incremental update at the very end of a big PDF file can change the way the first page is rendered. Is this still a concern of the group? This would be an issue for small-footprint implementations of IPPFAX. Can the IPPFAX spec be written to expressly require or forbid certain features of PDF? John From: McDonald, Ira (imcdonald@sharplabs.com) Date: Wed Jun 05 2002 - 18:12:49 EDT Hi John, Yes, the IPPFAX spec can expressly require or forbid certain PDF features. In particular (I sincerely hope), IPPFAX can specifically cite and require (for minimum conformance) exactly ONE of the profiles of PDF in the ISO PDF/X standards. That way we get a stable/tested profile from the pre-press industry. Cheers, - Ira McDonald High North Inc From: Hastings, Tom N (hastings@cp10.es.xerox.com) Date: Wed Jun 05 2002 - 19:36:32 EDT Does anyone know whether one of the ISO PDF/X standards rules out the PDF construct that causes the streaming problem? If no one responds to the reflector, be sure to ask the Adobe representative at the meeting. Tom -------------- [IPPFAX Requirements] From: Wagner,William (wwagner@netsilicon.com) Date: Wed May 15 2002 - 15:30:16 EDT Lee more concisely expressed the gist of my comment. As a starting point, I suggest that the intent of IFX is to provide for the secure, verifiable internet transmission of information necessary to generate a precise facsimile of an original document (hardcopy or soft) at one or more authenticated destinations. There are associated functions related to determining the limits of precision (resolution, color, size, media.) There are associated functions dealing with notification and verification of delivery. There is an intent to use the IPP protocol. From: Harry Lewis (harryl@us.ibm.com) Date: Wed May 15 2002 - 15:39:52 EDT In light of our full day plenary, I would amend only by adding... ... with the desire to evaluate the use of the web services Print Services Interface. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- From: Hastings, Tom N (hastings@cp10.es.xerox.com) Date: Wed Jun 05 2002 - 20:06:20 EDT Bill, I wonder whether the "term" facsimile brings along with it that the sender is starting with paper and is re-creating some thing with identical appearance at the other end? If so, that sort of means scanning. But IPPFAX (or whatever we want to call it), doesn't require the client to scan anything. However, maybe your ("hardcopy or soft)" means that either the sending document and/or the receiving document can be soft copy. Perhaps this could be made clearer in our requirements. Otherwise, this statement of requirements seem good to me. Perhaps an additional requirement is that the sender is able to determine the receiver's capabilities, although maybe that is a "how" to achieving your requirements. Tom ----------------- From owner-ietf-fax@mail.imc.org Thu Jun 20 14:01:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08642 for ; Thu, 20 Jun 2002 14:01:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5KHmNS23031 for ietf-fax-bks; Thu, 20 Jun 2002 10:48:23 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KHmMn23014 for ; Thu, 20 Jun 2002 10:48:22 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJ5EZB2BGG001X4B@mauve.mrochek.com> for ietf-fax@imc.org; Thu, 20 Jun 2002 10:48:12 -0700 (PDT) Date: Thu, 20 Jun 2002 10:39:51 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: draft-ietf-fax-esmtp-conneg-02.txt In-reply-to: "Your message dated Thu, 20 Jun 2002 13:42:23 +0900" <200206200442.AA01385@d23n59.rdmg.mgcs.mei.co.jp> To: "Toyoda, Kiyoshi" Cc: ned.freed@mrochek.com, dcrocker@brandenburg.com, ietf-fax@imc.org, paf@cisco.com Message-id: <01KJ5G3VS12W001X4B@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > I found that I made a mistake about draft in the e-mail which I > sent on 14th June. I attached a premature draft in that e-mail. > So, my comments below "--Original Message--" was inconsistent > with the attached draft. I am sorry to bother you. That's OK -- it was still on my to-do list. > Please review the draft which I attached in this e-mail with > my comments below. It is the correct one. I've reviewed it, and I believe all the technical points I raised have been addressed. There are some wording changes I'd like to see done but that can be handled during the last call. So please go ahead a post the revised draft. I will then ask for it to be last called. Ned From owner-ietf-fax@mail.imc.org Mon Jun 24 00:18:41 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12006 for ; Mon, 24 Jun 2002 00:18:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5O3wYp26127 for ietf-fax-bks; Sun, 23 Jun 2002 20:58:34 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5O3wTw26121 for ; Sun, 23 Jun 2002 20:58:29 -0700 (PDT) Received: by bulls.mei.co.jp (8.12.2/3.7W/jazz) with ESMTP id g5O3vit3006834; Mon, 24 Jun 2002 12:57:44 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) with SMTP id g5O3viK10769; Mon, 24 Jun 2002 12:57:44 +0900 (JST) Received: from no.name.available by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 24 Jun 2002 03:57:44 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0-1.mgcs.mei.co.jp (8.12.2/3.7W-HUB) with ESMTP id g5O3sjSG013110; Mon, 24 Jun 2002 12:54:45 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id MAA16201; Mon, 24 Jun 2002 12:57:43 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.12.2/3.7W-RDMG) with SMTP id g5O3v2l8007742; Mon, 24 Jun 2002 12:57:02 +0900 (JST) Message-Id: <200206240405.AA01396@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Mon, 24 Jun 2002 13:05:21 +0900 To: ned.freed@mrochek.com Cc: dcrocker@brandenburg.com, ietf-fax@imc.org, paf@cisco.com Subject: Re: draft-ietf-fax-esmtp-conneg-02.txt In-Reply-To: <01KJ5G3VS12W001X4B@mauve.mrochek.com> References: <01KJ5G3VS12W001X4B@mauve.mrochek.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.12 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Freed-san, Thank you very much for your review. I posted the revised draft just now. ned.freed@mrochek.com wrote: >> I found that I made a mistake about draft in the e-mail which I >> sent on 14th June. I attached a premature draft in that e-mail. >> So, my comments below "--Original Message--" was inconsistent >> with the attached draft. I am sorry to bother you. > >That's OK -- it was still on my to-do list. > >> Please review the draft which I attached in this e-mail with >> my comments below. It is the correct one. > >I've reviewed it, and I believe all the technical points I raised have >been addressed. There are some wording changes I'd like to see done but >that can be handled during the last call. > >So please go ahead a post the revised draft. I will then ask for it >to be last called. > > Ned > Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Wed Jun 26 04:14:53 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07367 for ; Wed, 26 Jun 2002 04:14:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5Q7u4r14386 for ietf-fax-bks; Wed, 26 Jun 2002 00:56:04 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5Q7u2w14382 for ; Wed, 26 Jun 2002 00:56:03 -0700 (PDT) Date: Wed, 26 Jun 2002 09:55:40 +0100 To: ietf-fax@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: WG slot MOVED TO TUESDAY MORNING at 9.00 !! Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please check the final schedule. We have been moved from monday evening sesion to TUESDAY MORNING AT 9.00 (2.5 hours). ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Project Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09 From owner-ietf-fax@mail.imc.org Wed Jun 26 06:58:37 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11602 for ; Wed, 26 Jun 2002 06:58:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5QAifx29603 for ietf-fax-bks; Wed, 26 Jun 2002 03:44:41 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QAiew29597 for ; Wed, 26 Jun 2002 03:44:40 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11085; Wed, 26 Jun 2002 06:43:57 -0400 (EDT) Message-Id: <200206261043.GAA11085@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-fax@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-fax-esmtp-conneg-02.txt Date: Wed, 26 Jun 2002 06:43:57 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : SMTP Service Extension for Content Negotiation Author(s) : K. Toyoda, D. Crocker Filename : draft-ietf-fax-esmtp-conneg-02.txt Pages : Date : 25-Jun-02 This document defines a content negotiation service extension for SMTP [ESMTP1, ESMTP2] whereby an SMTP client may request information about content capabilities of the target device or system that is serviced by an SMTP server. The SMTP server may report the target's content capabilities back to the client. This process emulates a classic facsimile start-of- session capabilities negotiation, although it can be used for a broad range of email-based scenarios. This service extension is primarily intended for 'direct', one-hop, originator/recipient SMTP transfers, although relayed scenarios through multiple SMTP servers are permitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-esmtp-conneg-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-esmtp-conneg-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-esmtp-conneg-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020625142250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-esmtp-conneg-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-esmtp-conneg-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020625142250.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Wed Jun 26 11:21:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23023 for ; Wed, 26 Jun 2002 11:21:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5QF4Qt14832 for ietf-fax-bks; Wed, 26 Jun 2002 08:04:26 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QF4Ow14828 for ; Wed, 26 Jun 2002 08:04:24 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5QF3hg15528; Wed, 26 Jun 2002 11:03:44 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 11:03:42 -0400 Message-ID: From: "Glenn Parsons" To: vpim@lists.neystadt.org Cc: ietf-fax@imc.org, "'um@snowshore.com'" Subject: Draft Agenda for VPIM Date: Wed, 26 Jun 2002 11:03:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21D21.40C8A414" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21D21.40C8A414 Content-Type: text/plain; charset="iso-8859-1" Folks, As you may recall from IETF 53, we have agreed to meet jointly at IETF 54 and likely future IETF meetings until we wrap up. The slot we have been assigned is: TUESDAY, July 16, 2002 0900-1130 Morning Sessions APP fax&vpim Internet Fax WG & Voice Profile for Internet Mail WG Anyway, on the meeting agenda, I would propose FAX goes first and that VPIM progresses in a similar order of events as we have done previously: VPIMv2 - status of publication (MDN & DSN dependency) VPIM Directory - schema status - ENUM status IVM - status of last calls - review of IVM base spec Addenda - status of last calls - IMAP channel, Client Behaviour, Caller-ID, SNAP,... We can discuss which of the Addenda items we think should roll into LEMONADE, if any... BTW, LEMONADE meets on Thursday: THURSDAY, July 18, 2002 1530-1730 Afternoon Sessions II APP lemonade License to Enhance Messaging Oriented Network Access for Diverse Endpoints BOF Let me know if there is anything else you think we should cover or would like to discuss at the meeting. I will send out a more detailed agenda (with draft names) closer to the meeting. Cheers, Glenn. ------_=_NextPart_001_01C21D21.40C8A414 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Draft Agenda for VPIM

Folks,

As you may recall = from IETF 53, we have agreed to meet jointly at IETF 54 and likely = future IETF meetings until we wrap up.  The slot we have been = assigned is:

TUESDAY, July 16, 2002
0900-1130 Morning Sessions
APP     = fax&vpim  Internet Fax WG & Voice Profile for Internet = Mail WG=A0

Anyway, on the = meeting agenda, I would propose FAX goes first and that VPIM progresses = in a similar order of events as we have done previously:

=A0=A0=A0=A0=A0=A0=A0 VPIMv2=20
=A0 - status of = publication (MDN & DSN dependency)

=A0=A0=A0=A0=A0=A0=A0 VPIM Directory=20
=A0 - schema status=20
=A0 - ENUM status

=A0=A0=A0=A0=A0=A0=A0 IVM=20
=A0 - status of last = calls
=A0 - review of IVM base spec=20

=A0=A0=A0=A0=A0=A0=A0 Addenda=20
=A0 - status of last calls=20
=A0 - IMAP channel, Client = Behaviour, Caller-ID, SNAP,...  =

We can discuss which of the = Addenda items we think should roll into LEMONADE, if any...  = BTW,  LEMONADE meets on Thursday:

THURSDAY, July 18, 2002
1530-1730 Afternoon Sessions = II
APP     = lemonade  License to Enhance Messaging Oriented Network Access for = Diverse Endpoints BOF

Let me know if there is = anything else you think we should cover or would like to discuss at the = meeting.=A0 I will send out a more detailed agenda (with draft names) = closer to the meeting.

Cheers,
Glenn.


------_=_NextPart_001_01C21D21.40C8A414-- From owner-ietf-fax@mail.imc.org Wed Jun 26 19:12:03 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15125 for ; Wed, 26 Jun 2002 19:12:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5QMtqt04849 for ietf-fax-bks; Wed, 26 Jun 2002 15:55:52 -0700 (PDT) Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QMtow04844 for ; Wed, 26 Jun 2002 15:55:50 -0700 (PDT) Received: from azteca.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.74]) by mail.notes.ricoh.co.jp (8.11.6/3.7W) id g5QMtcr31225; Thu, 27 Jun 2002 07:55:38 +0900 Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by azteca.isd.ricoh.co.jp (Mirapoint) with ESMTP id ACY67360; Thu, 27 Jun 2002 07:55:37 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id HAA17130; Thu, 27 Jun 2002 07:51:24 +0900 (JST) To: gparsons@nortelnetworks.com Cc: vpim@lists.neystadt.org, ietf-fax@imc.org, um@snowshore.com Subject: Re: Draft Agenda for VPIM In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020627075755F.tamura@toda.ricoh.co.jp> Date: Thu, 27 Jun 2002 07:57:55 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Glenn, > TUESDAY, July 16, 2002 > 0900-1130 Morning Sessions > APP fax&vpim Internet Fax WG & Voice Profile for Internet Mail WG > > Anyway, on the meeting agenda, I would propose FAX goes first and that VPIM > progresses in a similar order of events as we have done previously: Your proposal for FAX WG going first is ok for me. I live in Yokohama! But, some FAX WG members do not stay at hotels and go there directly from their home. Dear Japanese FAX WG members: If you take the first train in the morning and cannot go there, please let us know very soon. Regarding FAX WG agenda, I will let you know the next Tuesday, maybe. The issues are mainly confirmation of status of I-Ds that FAX WG finished, TIFF-FX, ESMTP CONNEG, Claudio's I-D, FAX in ENUM and ITU. Please wait. Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Fri Jun 28 15:56:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18192 for ; Fri, 28 Jun 2002 15:56:54 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5SJbIY29642 for ietf-fax-bks; Fri, 28 Jun 2002 12:37:18 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SJbDw29604 for ; Fri, 28 Jun 2002 12:37:17 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16951; Fri, 28 Jun 2002 15:36:28 -0400 (EDT) Message-Id: <200206281936.PAA16951@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ietf-fax@imc.org From: The IESG Subject: Protocol Action: Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration to Proposed Standard Date: Fri, 28 Jun 2002 15:36:28 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration' as a Proposed Standard. This document is the product of the Internet Fax Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom. Technical Summary This document describes the registration of the MIME sub-type image/tiff, used to indicate the use of the Tag Image File Format (TIFF) defined by Adobe. This document refines an earlier sub-type registration in RFC 1528 [TPC.INT] and supersedes RFC 2302. Working Group Summary The group came to consensus on the documents as written. Moreover, these documents are also to a large degree agreed to by the ITU study group that is defining similar functionality in the ITU protocol suite. Protocol Quality The specification was reviewed for the IESG by Ned Freed.